Esta é minha lista de artigos com a tag "W3C"

Web Standards? E agora José?

Por: Henrique Costa PereiraTuesday 27 January 2009 às 19:27

Eventualmente converso com algumas pessoas “das antigas” sobre os famosos padrões web, sobre boas práticas de XHTML e CSS e sempre fico me perguntando onde chegamos e para onde estamos indo. Este texto é uma reflexão sobre isso. O que já alcançamos e o que está pela frente.

O passado

Não vou contar de novo a mesma história mas vou resumi-la. A primeira grande guerra dos browsers transformava a vida dos desenvolvedores em um inferno, onde para fazer um site rodar no maior número possível de versões de navegadores era necessário muitas gambiarras, trechos de códigos redundantes etc. Tudo para deixar o mesmo site o mais igual em diferentes navegadores. Esta foi a forma humana mais básica de sentir na pele a necessidade de padrões de desenvolvimento para a internet. Se você não viveu esta época como desenvolvedor, agradeça!

Naquela época desenvolver sites usando tabelas era o caminho mais fácil para fazer um site ser renderizado de forma mais parecida possível em vários navegadores. A popularização e o refinamento das ferramentas visuais de desenvolvimento de HTML ou os chamados editores WYSIWYG também foram outro fator que contribuiu para a popularização do HTML e do desenvolvimento fora dos padrões, visto que estes editores priorizavam a aparência do site renderizado no navegador em oposição a qualidade do código gerado. Esta foi a época do design pelo design.

A virada

A história mostrou para aqueles vovôs da internet na pele algo que doía muito. Gastar tempo e esforço criando códigos redundantes por causa da indústria dos browsers. As pessoas das gerações seguintes, muitas delas, aderiram ao movimentos dos web standards e começaram a desenvolver de forma criativa seguindo os padrões de HTML e CSS da W3C. Surgia uma nova era.

Várias referências na web ficaram conhecidas pelos esforços em popularizar o desenvolvimento seguindo os padrões como o A List Apart, Web Standards Project, Jeffrey Zeldman, Dave Shea, Molly Holzschlag além de Tantek Çelik e Eric Meyer também conhecidos a pouco pelos avanços em Microformats, dentre vários outros. No Brasil os mais populares foram o site do Maujor e o Tableless. No geral o papel que eles tiveram foi o de pressionar a indústria (funcionou apenas em partes) ao chamar a atenção para técnicas de desenvolvimento em CSS, evitando hacks (sim evitando) e usando HTML de forma semântica, em oposição as infames tabelas. O principal valor que todas estas referências tiveram foi o de influenciar e o de liderar essa influência através do ensino de HTML e CSS de forma simples e prática.

Hoje, agradeça aos mecanismos de busca (sic)

Hoje a situação é infinitamente melhor do que a 5 ou 7 anos atrás. Antes era comum pessoas torcerem o nariz ao ouvirem “desenvolver código na mão“. Hoje isso é compreensível. A principal razão da popularização dos web standards foram os mecanismos de busca, mais especificamente o Google e a corrida de ouro que se tornou o SEO. Um site com melhor semântica de HTML ganha pontos nos primeiros resultados de busca.

Sem a popularização dos mecanismos de busca, o mundo inteiro estaria alguns passos atrás em relação aos padrões web. Eu não vejo nenhum outro fator decisivo nessa popularização. As ferramentas de codificação não ficaram semânticas e simples o suficiente para que um garoto de 7 anos consiga fazer uma página válida. Houve avanços é claro, mas desenvolver HTML de forma decente ainda exige saber o que se está fazendo. Pouquíssimos editores de HTML podem ser chamados de “bons”. Então não dá para atribuir a popularização dos padrões web a eles.

Desculpe também não atribuir estes avanços aquelas pessoas que bravamente lutaram em seus blogs para divulgar os padrões web (até mesmo porque me coloco nessa lista), mas o Google foi fundamental para este processo. Obviamente o papel dos blogs foi importante. Importante porque eles praticamente são a fonte de estudo da grande maioria dos desenvolvedores. Mas o papel do Google foi o de mostrar na prática (na pele e no bolso) para quem tem dinheiro (empresas e chefes empresários) os benefícios de estar nos primeiros resultados.

Como nós só seguimos algo pelo benefício que aquilo pode trazer ou pelo medo da coerção, medo da punição, ficar para trás nos mecanismos de busca é sinônimo de “perder dinheiro”. A ditadura dos primeiros 10 resultados impulsionou a popularização dos web standards. A relação custo x benefício deixou muito claro para muitas empresas as vantagens de se desenvolver sites semânticos. E isto está além de validação como os primeiros xiitas acreditavam.

Como está o Brasil nessa história?

A W3C possui um escritório no Brasil e procura estar presentes em eventos como o Campus Party. Essa proximidade é em partes a valorização e a popularização dos padrões no Brasil. Principalmente porque somos o segundo país do mundo em tempo de conexão e o segundo mais presente em redes sociais. Por mais que nem todos os portais sejam 100% semânticos (no sentido estrito do HTML), é difícil encontrar portais desenvolvidos em tabelas nos nossos dias. Argumento suficiente para a mudança de cenário certo?

Acho que nosso desafio em um futuro próximo mais latente e imediato deve ser a acessibilidade. Desenvolvedores experientes sabem que é possível ter um site bem indexado, otimizado para mecanismos de buscas e ainda sim com problemas de acessibilidade. Neste cenário falta pouco é claro, mas pode melhorar. Esse passo é algo mais complicado e precisaria de muita educação e um pouco de coerção.

Começando pela coerção, eu sugiro que o governo brasileiro pudesse punir todos os órgãos públicos que tivessem problemas com acessibilidade. Não vou entrar em detalhes dessa sugestão, é assunto muito complexo, mas já mostra um caminho. E essa punição deveria ser severa. O passo seguinte seria levar essa “lei” para sites de interesse público, turismo, etc. Algo mais difícil. Mas só isso seria suficiente para estimular empresas a quererem desenvolver de modo acessível, girando a economia daquelas empresas capazes de desenvolver com acessibilidade, e estimulando as periferias a fazer o mesmo. Só uma pincelada do que poderia ser feito.

Na Campus Party, a Lêda Spelta do Acesso Digital e Vagner Diniz, gerente do escritório da W3C no Brasil, apresentaram um painel sobre acessibilidade (veja foto abaixo). A palestra em si é o que muitos estão cansados de saber. Não adianta esperar nada de novo. Não existe nada novo para ser visto. O papel deles é o de popularizar o que já existe, a boa e velha acessibilidade. E se todos soubessem o que eles falaram no painel talvez o foco deles hoje seria bem diferente.

Alguma tendência?

Hoje eu arrisco algumas coisas que os desenvolvedores deveriam se preocupar e algumas tendências que na verdade não são “novidades”, e sim caminhos que já se mostram verdes. São sugestões que eu acredito que contribuem para a evolução da web.

• Não pare de estimular os padrões web. Ainda tem gente que nunca ouviu falar de SEO e acessibilidade;
• Use RDF, Microformats, Geo feeds, KML e outros padrões XML based, não por que eles são o futuro definitivo, mas porque esses padrões fazem parte da revolução;
• Não se esqueça especificamente da acessibilidade. Você ainda vai ganhar dinheiro com isso se souber o que está fazendo.
• Popularizar os padrões web de forma simples e compreensível para aquelas pessoas que não colocam a mão no HTML diretamente, como os analistas de sistemas, programadores que pegam o HTML pronto, arquitetos da informação, marketeiros, atendimento e comercial, etc.
• Desenvolvimento mobile. Comece com XHTML-MP!
• Leia sobre usabilidade na web. Está intimamente relacionado com acessibilidade.
• Desinstale o Internet Explorer 6 da máquina de usuários comuns, (valeu o convite Dulça, este texto em partes é uma resposta ao seu convite!). Quanto menos pessoas usarem esse browser obsoleto melhor para o mundo inteiro.

Texto grande, como a muito tempo eu não escrevia. Mas eu não queria picar esta reflexão em mais de uma parte. Alguma consideração?

Convite de lançamento do escritório da W3C aberto ao público

Por: Henrique Costa PereiraWednesday 28 May 2008 às 07:28

Dia 4 de junho próximo haverá um evento de lançamento aberto ao público do escritório da W3C no Brasil. O evento ocorrerá em São Paulo, no Centro de Convenções Fecomércio na Rua Plínio Barreto, 285 – Bela Vista, São Paulo/SP. O evento é gratuito, entretanto é necessário o credenciamento com antecedência.

Veja abaixo o press release completo enviado a alguns sites para divulgação.

O Consórcio W3C, entidade internacional com a missão de definir orientações
e padrões para a Web e responsável pela evolução do HTML, XML, CSS, tem a
honra de convidar o público em geral para o lançamento de seu Escritório no
Brasil.

O evento de lançamento acontecerá no dia 4 de junho de 2.008, quarta-feira,
às 11h. A participação, além de aberta ao público, será gratuita,
exigindo-se apenas o credenciamento prévio pela internet a partir do endereço
http://www.w3c.br/2008/lancamento/cadastro.html.

Apesar de não poder estar presente, Tim Berners-Lee, grava mensagem em vídeo
especialmente para a ocasião.

O evento será prestigiado com a participação de representantes
internacionais do W3C: Jose Manoel Alonso, líder da iniciativa eGov do
W3C/CTIC, falará sobre “O uso adequado da Web para se chegar ao Governo
Eletrônico 2.0″; Daniel Dardailler, diretor de relações internacionais; e
Stéphane Boyera, líder da iniciativa Web Móvel, participarão do painel
internacional “Internet & Web: passado, presente e futuro”. Essas duas
atividades fazem parte do evento de lançamento

Demi Getschko, diretor-presidente do NIC.br e conselheiro do Comitê Gestor da
Internet no Brasil, participará também do painel “Internet & Web: passado,
presente e futuro”

O evento de lançamento acontecerá integrado ao 14º Congresso de Inovação
na Gestão Pública e será realizado no Centro de Convenções Fecomércio, na
Rua Plínio Barreto, 285, Bela Vista, São Paulo, SP (ao lado da Av. 9 de Julho
e da Fundação Getúlio Vargas). Mapa de localização pode ser visto em
http://wiki.conip.com.br/Conip2008/InformacoesGerais.

O W3C Escritório Brasil é uma iniciativa do NIC.br e do CGI.br

Outras informações podem ser obtidas em http://www.w3c.br/2008/lancamento/

W3C anuncia escritório no Brasil

Por: Henrique Costa PereiraWednesday 31 October 2007 às 11:31

O Consórcio World Wide Web (W3C) tem a satisfação de anunciar a inauguração do primeiro escritório W3C na América do Sul, o W3C Escritório Brasil, abrigado no NIC.br (Núcleo de Informação e Coordenação do Ponto BR), em São Paulo, Brasil. W3C deseja aumentar a interação com a comunidade de língua portuguesa com a instalação deste escritório, principalmente porque o status da arte do ambiente tecnológico no Brasil está em perfeita sintonia com as tendências no W3C, tais como mobilidade, aplicações e vídeo para o mundo Web.

Leia o restante do texto em português no W3C Brasil.

Language Tags

Por: Henrique Costa PereiraSunday 26 August 2007 às 16:26

Language tags (também conhecidas como language code) são atributos de XHTML, XML e HTML com o objetivo de indicar a linguagem (idioma) utilizada em um texto/documento ou até mesmo em um trecho de documento. Language tags é um assunto da W3C Internationalization (i18n) Activity, uma força tarefa da W3C específica para assegurar a implementação de tecnologias da web em diferentes linguagens. Existem várias dicas sobre isto entretanto este texto vai tratar especificamente sobre as language tags. Se você pretende trabalhar ou desenvolver aplicações e web sites multilíngua, em mais de um idioma ao mesmo tempo, este texto pode te ajudar.

Language tags, bem como feeds e microformats, enfrentou e/ou enfrentam a mesma situação que nos remete a questão do ovo e da galinha. Quem deve vir primeiro, a implementação por parte dos desenvolvedores ou os dispositivos específicos, implementações, adaptações etc, fabricados pela indústria? Não estou dizendo que language tags seja algo novo, mas é um recurso que ainda não foi explorado em todas as suas possibilidades mesmo que já exista algumas aplicações muito úteis.

Language tags é útil como meta-informação utilizada por mecanismos de buscas ou qualquer outro tipo de usar agent, sistemas de classificação, spelling checkers (corretores ortográficos) sistemas multi-língua, acessibilidade etc. Leitores de tela para deficientes visuais como o Jaws já tem implementado nativamente uma detecção automática de language tags que escolhe um sintetizador de voz adequado para a leitura de um documento.

Não confunda

Antes de mais detalhes é importante ressaltar que language tags não está relacionado com codificação de caracteres (character encodings) que eu já escrevi a respeito aqui em uma série de 5 artigos. Por mais que character encodings também seja um assunto do i18n, encodings trata-se da representação de caracteres usada em um documento e language tags trata-se da meta-informação sobre a linguagem humana (idioma) utilizada em um documento.

Abordagem

Há algumas abordagens diferente para se declarar language tags, entretanto a W3C recomenda uma abordagem simples e fácil de ser implementada. Nada mais é do que declarar atributos específicos na tag HTML (que serve para o documento como um todo) e em trechos específicos quando você compartilha trechos em um idioma diferente.

Boas práticas

Abaixo segue algumas boas práticas simples de serem implementadas e fáceis de serem seguidas. Existem outras além dessas, por isso eu aconselho a leitura deste documento.

Utilize o atributo lang e/ou xml:lang na tag HTML

Trata-se de uma forma simples de declarar qual é o idioma do seu site.

Em HTML:

<html  lang="pt-br">

Em XHTML sendo enviado como text/html:

<html  xml:lang="pt-br" lang="pt-br">

Em XML e XHTML enviado como application/xhtml+xml:

<html xml:lang="pt-br" >

Informe alterações de idiomas em trechos específicos com o atributo lang.

O atributo lang pode ser usado em todos os elementos de HTML com exceção dos elementos applet, base, basefont, br, frame, frameset, iframe, param e script. Se não encontrar um elemento mais apropriado para usar este atributo, você pode utilizar a tag <span>. O objetivo é usá-lo onde você for citar trechos em idioma diferente daquele presente no restante do documento.

Os valores destes atributos, ou seja, as language tags, podem ser consultadas no IANA Language Subtag Registry.

Utilize hreflang com CSS

Trata-se de indicar ao usuário e ao user agent qual o idioma do link que você está referenciando. Como pode ver neste texto, os links que páginas onde o conteúdo é em inglês possui um [en] logo a frente. Veja abaixo como fazer:

<p>There is also a page describing <a href="swedish-doc.html" hreflang="sv">
why a DOCTYPE is useful</a>.</p>

a[hreflang]:after { content: " [" attr(hreflang) "] "; }

Acessibilidade e o WCAG Samurai

Por: Henrique Costa PereiraSaturday 18 August 2007 às 20:18

Confesso que escrever sobre acessibilidade e o WCAG Samurai me atrai muito ao mesmo tempo em que acho um pouco nebuloso. Mas nebuloso pelo contexto e não pelo assunto em si. Talvez seja por isso que praticamente nada (com exceção do texto do Ivo Gomes) que está em Portugal) tenha sido escrito em português sobre a errata do WCAG Samurai. Nada. Vamos do início e ver o que acontece…

O WCAG é o acrônimo de Web Content Accessibility Guidelines (Guia de acessibilidade para conteúdo na web) que tem o objetivo que estabelecer padrões e técnicas de acessibilidade para a web. Como a versão do WCAG 1 foi publicado em 1999, recentemente sofreu a revisão para a versão WCAG 2 (2007). Na teoria o WCAG 2 deveria ser a evolução e a substituição do WCAG 1.

O que deveria ser sinal de esperança com o advento do WCAG 2, resultou em grande frustração. O fato é que o WCAG 2 é confusa demais e tem problemas sérios de integridade em relação aos outros padrões da web. Suas recomendações são praticamente inviáveis em vários aspectos. Para se ter uma idéia de algumas contradições, em alguns casos é necessário abrir mão de markup válida para se alcançar algum requisito do WCAG. E isto porque a W3C está por trás tanto do (X)HTML quando do WCAG. Segundo Clark, de lobby até falta de participação de pessoas com alguma deficiência marcaram todo o processo para se alcançar o WCAG 2. E o resultado não poderia ser mais triste.

WCAG Samurai

Ao invés de esperar sentados a boa vontade do WAI, o WCAG Samurai é um grupo de desenvolvedores liderados por Joe Clark (autor do livro “Building Accessible Websites“) que mandaram para o inferno os guidelines do WCAG 2 e criaram um documento de acessibilidade mais realista. Em resumo, ou você desenvolve seus sites seguindo o WCAG 2, ou o WCAG Samurai ou nenhum deles. Leia aqui. Porque não é possível seguir ambos.

O WCAG Samurai é um errata do WCAG 1 e que ignora completamente o WCAG 2. A errata diz quais partes do WCAG 1 você deve ignorar e quais são as corretas. Mais um exemplo de padrões emergindo à margem da W3C, por mãos de pessoas com reconhecimento suficiente ao ponto de serem seguidas, como as iniciativas dos microformats e HTML 5. Mas isso já é outra história.

Veja algumas considerações da errata:

• Termos como “evite utilizar” foram banidos e deram lugar a termos como “utilize” ou “é obrigatório utilizar”.
• Recomendação de ignorar a prioridade 3.
• Seguir as recomendações 1 e 2 com código válido.
• Tabelas para layout e frames foram banidos. Se necessário utilize iframes.
• Banida a utilização de noscript. E se for utilizar Flash ou AJAX eles devem ser acessíveis.
• Todas as páginas que querem se compliant com o WCAG Samurai devem ter (X)HTML válido e semântico.

Neste contexto, muito do que alguns validadores de acessibilidade como o WebXACT e o Cynthia Says apontam como erros devem ser desconsiderados irrelevantes. De fato, validação nunca garantiu e provavelmente nunca vai garantir um site realmente acessível (muito menos semântico), mas agora mais do que nunca, a acessibilidade precisa ser revisitada.

Para se alcançar um bom resultado de acessibilidade, não é necessário produzir markup inválida. Uma coisa deve depender da outra. Este é um ponto crítico em relação ao WCAG e que fomentou o surgimento do WCAG Samurai. Entretanto a situação não é muito clara na prática, browsers continuam violando padrões, a W3C insistiu com o WCAG 2 mesmo que ele viole outros padrões, o que fomenta perda de credibilidade por parte da indústria e assim por diante.

De qualquer maneira recomendo a leitura completa da errata que não é muito grande. Mantenha-se atualizado também com o feed do WCAG Samurai para as constantes atualizações. Seria muito bom a participação de pessoas envolvidas com acessibilidade na divulgação e discussão do WCAG Samurai, incluindo pessoas com deficiência visual. Enquanto todos estão em silencio esperando uma solução de acessibilidade que caia do céu ou apareça pronta no seu editor de HTML, ela só vai ficar cada vez mais distante.

Algumas questões em torno do desenvolvimento de sites para dispositivos móveis

Por: Henrique Costa PereiraSunday 20 May 2007 às 21:20

Provavelmente este texto é mais um início de uma série de reflexões naturais que virão com o tempo sobre desenvolvimento de web sites para dispositivos móveis. Ultimamente tenho lido e estudado mais sobre os diferentes caminhos que podem ser tomados para construir sites acessíveis e bem adaptados para celulares e PDA’s. E o mais importante de tudo é como fazer e tomar essas decisões no contexto de HOJE e não amanhã. Este texto então vai colocar mais minhoca na sua cabeça do que te ensinar algo. Mas já é um começo se você ainda não parou para pensar sobre desenvolvimento para dispositivos móveis.

Este assunto acaba desenterrando outro sobre a guerra em prol dos web standards. Se você acredita que a guerra acabou, devo dizer que você está enganado. Se você está se perguntando o que web standards tem a ver com desenvolvimento de sites com versão mobile, você verá a seguir. Mas o fato é que desenvolvimento para dispositivos móveis está crescendo exponencialmente (como a maioria das novidades em desenvolvimento) e as reflexões giram em torno de duas vertentes basicamente:

1º – De um lado temos as idéias relacionadas com o IDEAL do desenvolvimento da web e como as coisas DEVERIAM ser.

2º – De outro temos a realidade de COMO AS COISAS SÃO HOJE e quais as melhores soluções para o presente.

Por mais que as duas vertentes sejam tratadas como antagônicas o objetivo do texto não é fazer você escolher uma delas e sim levantar uma discussão sobre prós e contras. Dividi este texto em 4 principais campos de problemas. Dentro do desenvolvimento para dispositivos móveis nós temos problemas que envolvem a linguagem de marcação a ser utilizada, sobre a melhor solução de design, arquitetura da informação, versões,TLD’s etc.

XHTML-MP, XHTML ou HTML?

A era do WML se foi. Sem comentários sobre isto. A linguagem de marcação proposta para dispositivos móveis atualmente é o XHTML-MP (Extensible Hypertext Markup Language – Mobile Profile), um subset do XHTML inspirado no XHTML Basic 1.0 desenvolvido pela OMA (Open Mobile Alliance) e ouvi dizer que tem a beção da W3C Mobile Web Initiative. Veja aqui uma quadro comparativo entre XHTML-MP e XHTML Basic 1.0. E considerando o fato de ambas serem muito parecidas, elas estão caminhando para serem uma única especificação.

Há “n” lacunas nessa história toda que nos permite conspirar um pouco. E não estou interessado em fazer isso agora. Nos últimos tempos encontramos por aí várias discussões sobre o futuro das linguagens de marcação nas vertentes de XHTML 2 ou HTML 5. As coisas ainda não estão claras sobre o futuro delas e aminha opinião nem importa sobre isso. A indústria (OMA e dotMobi) estão caminhando em direção ao XHTML Basic 1.0 = XHTML-MP que são derivações do XHTML 1.0. Hoje os dispositivos móveis aceitam o HTML 4 e é possível fazer muita coisa legal desde que o HTML seja bem estruturado (ou seja, sem table layouts). Mas a industria parece caminhar em direção ao XHTML e eles não estão se importando muito com retro-compatibilidade. A maioria dos browsers modernos dos celulares e PDA’s já ignoram o WML. Então até que as coisas estejam sólidas essa filosofia de não a retro-compatibilidade vai permanecer.

Segundo as iniciativas do XHTML-MP, o MIME Type deverá ser o application/xhtml+xml com Character Encoding em UTF-8, código bem estruturado sem utilização de tabelas, documentos well-formed, erros de XML parser caso exista erros de sintaxe (se não acredita em mim leia isso tudo neste manual) etc. Se considerarmos as boas práticas da inciativa da W3C e da OMA, o futuro das linguagens de marcação para dispositivos móveis está enraizado no XHTML.

O design

Web designers vão ter um choque quando iniciarem o desenvolvimento para dispositivos móveis. Desenvolver sites para desktop te permite explorar espaços maiores, imagens mais elaboradas, cores, tamanhos, tipologias, formatos, animações, etc. Agora quando você tem um espaço que varia de 120px a 320px, as soluções de design que você tem que encontrar são muito mais limitadas do que aquela que você está acostumado. Veja a imagem abaixo:

Algumas boas práticas incluem tamanhos de fontes que possam ser lidos em uma tela pequena, conteúdo adaptado, etc. AdSense, banners, animações em flash, imagens grandes, etc só atrapalham a experiência do usuário. Até o conjunto de cores para uma versão assim deve ser bem escolhido. Não importa se você vai adaptar o seu site já existente para dispositivos móveis ou se você vai construir uma versão específica, a solução para o seu design deverá ser consciente em relação ao usuário.

A arquitetura da informação

A arquitetura da informação também terá um papel muito importante no desenvolvimento para dispositivos móveis. O trio usuário, contexto e conteúdo tem um desafio completamente diferente de organizar ambientes de informação feitos para celulares e PDA’s. Isso vai incluir escolher entre features, fluxos de navegação simplificados, escolher por relevância entre qual conteúdo é importante e qual deve ser descartado em relação a versão desktop etc. Veja abaixo a diferença entre um ambiente comum de um site para versão desktop e do lado direito uma estrurua ideal para sites construídos especificamente para dispositivos móveis.

Veja agora na imagem abaixo um mapa de site comum e presente em muitos sites institucionais hoje.

Navegar em uma estrutura assim em um celular pode ser muito frustante e dispendioso. Agora veja uma solução criada especificamente para dispositivos móveis do mesmo site:

O principal conselho é: mantenha as coisas simples, com escolhas limitadas e objetivos para se alcançar a informação desejada mais simplificados.

Uma única versão para diferentes dispositivos ou versões separadas?

Esta escolha também reflete as diferenças entre as duas vertentes do desenvolvimento para dispositivos móveis. A primeira vertente diz que temos que ter um único site que se adapte aos diferentes dispositivos. Do outro lado temos os defensores das versões de sites construídos especificamente para dispositivos móveis e que estão adotando a TLD .mobi. Para tomar essas duas decisões hoje, cada uma delas tem o seu custo e o seu contexto.

Essas escolhas vão depender de “n” fatores que estão muito além do escopo deste texto. Se a escolha for manter um único site que se adapte as duas realidades (desktop e dipositivos móveis) a solução pode incluir handheld style sheets e talvez um pouco de content negotiation. Por que isso? Bom, se você prestou atenção nos textos sobre os problemas de design e arquitetura da informação, você sabe que não faz sentido deixar o usuário fazer o download de tudo o que uma versão desktop possui, como por exemplo banners em flash, publicidades etc. Será que os textos que estão presentes não precisariam ser resumidos? E o fluxo de navegação do usuário é adequado para a versão mobile? Qual o tamanho de cada página que será baixada em um celular? Todas essas considerações devem ser levadas em consideração. Existe ainda uma opção de entregar um site sem nenhuma folha de estilos como se tivesse no CSS Naked Day como neste exemplo. Mas ainda assim o conteúdo e o código seria excessivo ignorando o princípio do usuário, conteúdo e contexto! Veja mais reflexões sobre isso nos textos do Cameron Moll.

Do outro lado nós temos as soluções que optaram por desenvolver versões específicas para celulares e PDA’s. Como o Newsvine, CNN, Google, CNet News, Microsoft, Yahoo dentre vários outros. As coisas parecem caminhar em direção as versões de sites criadas exclusivamente para as versões mobile. Pelo menos HOJE. Se isso será salutar ou não para o desenvolvimento para web como um todo, isso já é outra história. Mas se considerarmos os problemas de design, AI e linguagem de marcação, construir versões separadas parece ser o melhor caminho.

TLD .mobi, sim ou não?

A indústria de celulares investe pesado todo ano em tecnologia e ela tem seus próprios interesses é claro. Várias empresas estão organizadas em torno do grupo dotMobi corresponde a TLD (Top Level Domains) .mobi, criada para indicar especificamente os sites compliance com dispositivos móveis. E esta iniciativa tem história e muita grana por trás. O grupo tem como investidos a Nokia, Google, Microsoft, Sansung, TIM, T-Mobile, Visa dentre outros.

Por trás da iniciativa da TLD .mobi é que vemos bem claro as duas vertentes de desenvolvimento para dispositivos móveis. De um lado aqueles que acreditam que os sites não devem ter TLDs diferentes simplesmente por que o dispositivo que o acessa é diferente. Ou seja, o domínio www.exemplo.com não deve ser www.exemplo.mobi só para indicar que ele é adaptado para dispositivos móveis. Dentre os que se opoem a isso está a própria W3C.

Por outro lado temos as mesmas empresas que fazem parte da W3C e fazem também parte do dotMobi e injetaram uma grana boa no grupo. Principalmente as empresas de celulares. Eles tem a própria defesa da necessidade dessa TLD. O fato é que quando muita publicidade e alguns milhões de dólares estão em jogo, vence o cara que fez o cheque com maior número de zeros!

Todas as imagens deste texto foram retiradas do dotMobi Mobile Web Developers Guide.

10 anos de CSS e o novo CSS Validator

Por: Henrique Costa PereiraTuesday 19 December 2006 às 22:19

O CSS ou Folha de estilos em cascata completa esta semana 10 anos de existência . No dia 17 de dezembro de 1996 a W3C publicava a primeira documentação do CSS 1. Parte dessa comemoração resultou na benfeitoria (e que benfeitoria) do CSS Validator. A W3C que nos últimos meses foi bastante criticada por vários gurus do desenvolvimento para web, mostra sinal de vida com esta comemoração e correções no CSS Validator.

Para comemorar estes 10 anos, a W3C faz um convite a todos os desenvolvedores a enviarem designs baseados em CSS que serão avaliados por Bert Bos e Håkon Lie em quesitos como originalidade, utilidade e estética. As propostas podem ser enviadas até o final de dezembro. Mais detalhes no pressrelease.

O novo CSS Validator tem o apelido de The Fuji CSS Validator” que tem o monte Fuji na perspectiva que pode ser visto no escritório da W3C no Japão, na Universidade de Keio. O novo validador está presente em várias línguas e infelizmente o português não é uma delas. Mas se você quer entrar para história e quiser ajudar a traduzí-lo, basta obter mais informações na Wiki do Validator.

Vida longa ao CSS!