Surgiu recentemente no WaSP a idéia de rotular alguns livros que podem ser perigosos para a web, sejam livros antigos ou com conceitos que vão contra acessibilidade e padrões web.

Existem diversos livros que ensinam a estruturar layouts com tabelas, escrever (X)HTML não semântico, construir sites não acessíveis e criar páginas com código proprietário que funcionam apenas em navegadores sem suporte a padrões.

A idéia é orientar que o livro rotulado não é recomendado e que há uma lista de outros muito melhores indicados pelo WaSP (em inglês). Não é simples livrar as bibliotecas públicas e de instituições de livros ruins, mas cada um pode imprimir os rótulos (em inglês), colocar nas devidas obras e evitar que mais mentes inocentes sejam corrompidas por elas.

O objetivo depende totalmente de pessoas dispostas a participarem, isso torna a idéia um pouco utópica e talvez não gere grandes resultados. Mas não deixa de ser uma iniciativa legal. É possível verificar a participação de algumas pessoas por este grupo no Flickr.

Baseado na idéia do Web Standards Project surgiu o Email Standards Project, o objetivo é atingir os clientes de e-mail ao invés dos fabricantes de navegadores para que também sigam algumas recomendações importantes.

Os fundadores colocam que o e-mail em HTML traz mais resultados e oferece uma experiência melhor ao usuário, a importância de estabelecer padrões estaria em criar e-mails com código limpo (assim com carregamento rápido), mais acessíveis e com renderização igual independente de cliente de e-mail.

É um caminho muito longo até que todos os grandes clientes de e-mail se adequem ao Email Acid Test, isso se levarem o projeto a sério. O melhor que podemos fazer para ajudar é divulgar o projeto e apoiar, será um ótimo ganho para a maioria se os objetivos forem alcançados.

Mas o e-mail em HTML ainda me parece bastante distante, ao menos para quem deseja formatações semânticas através de CSS, por enquanto devo me contentar com texto puro, ou então com apenas uma ou duas tags dentro dos e-mails.

A semântica é de extrema importância na web, quando se da um pouco de sentido a informação ela se torna ainda mais poderosa. No caso da internet temos interações entre aplicações, facilidade para achar o conteúdo que procura entre outras inúmeras vantagens. Apesar de dizerem que a Web 3.0 será a web semântica eu prefiro dizer que a nossa web precisa ser semântica.

Apesar de nossas linguagens de marcação ainda serem bem limitadas e estarem evoluindo muito lentamente – XHTML 2 e HTML 5 não me parecem uma realidade muito próxima – existem diversos pontos onde não as aplicamos semântica em nossos documentos atuais, são eles as abreviações e os acrônimos representados pelas tags <abbr> e <acronym> respectivamente.

Sua aplicação é muito simples, sempre que você escrever alguma forma de abreviação em seu documento basta como Av. para Avenida basta colocar em seu código <abbr title="Avenida">Av.</abbr>. Com acrônimos não é muito diferente, quando quiser falar de XML que significa eXtensible Markup Language o código fica <acronym title="eXtensible Markup Language">XML</acronym>.

São coisas simples assim que tornam seu conteúdo mais rico e acessível, quando se acrescenta significado também é acrescentando valor. É seguindo este pensamento que poderemos ter aplicações cada vez mais inteligentes facilitando nossas vidas.

Dica: quem utiliza o Windows Live Writer pode utilizar o Acronyms Plugin, uma mão na roda para não ter que ficar editando código.

Conhecendo meus leitores sei que não faz sentido algum explicar o que é WWW, e nem quero falar de conceitos mas sim de algo que me irrita muito: sites cujo os endereços não funcionam sem o deprecado WWW.

Não há motivo algum para digitar quatro caracteres a mais – o ponto também conta – em cada site que eu queira visitar mas ainda sim a maioria das pessoas digita, apesar disto ser problema delas e não meu. Acontece que o problema passa a ser meu também quando tento acessar um gvt.com.br ou tim.com.br e recebo o desagradável erro 404.

Qualquer hospedagem – ou seja lá quem controle o seu domínio – que se preze deve saber lidar com WWWs e a ausência deles de modo que não haja diferença alguma para o usuário. Os donos de sites devem se preocupar também pois escolher um endereço – com ou sem os dablius - para ser o principal é importante em termos de SEO, e é possível – eu diria obrigatório – redirecionar quem acessa pelo outro.

Os exemplos que citei acima são de empresas arrogantes que não se importam em agradar o cliente, em uma inversão de papéis nós clientes que nos tornamos submissos a elas, logo não espero que mudem nem acredito que venham a perder um cliente por esse motivo, mas nem todas as empresas podem se dar ao luxo de desagradar assim. (Espero não ter deixado muito evidente que não gosto da TIM e que a GVT tem um serviço horrível)

E por curiosidade existe até um movimento sobre o assunto, o no-www onde há inclusive dicas de como corrigir esse problema, não entrarei no assunto pois não domino configurações de DNS e servidores web e nem é esse o foco do blog.

Se você é do período sombrio da web, quando Netscape e Internet Explorer finalmente resolveram implementar o CSS (mesmo que não respeitando padrão algum), não deve ter boas lembraças de como os browsers renderizavam suas páginas. Apenas mais tarde os padrões do W3C ganharam força e os navegadores tiveram de implementá-los.

Surgiu então um problema, com a renderização obedecendo os padrões muitos sites “quebrariam” por serem projetados para navegadores antigos. A solução foi que browsers novos passassem a ter dois modos de renderização: o Quirks mode e o Standards mode, também conhecido por Strict mode (existe ainda o Almost Standards mode, que é uma pequena variação do Standards mode).

Sites antigos continuariam sendo renderizados “corretamente” (do ponto de vista de como foram projetados) através do Quirks mode, que obedece regras sem muito sentido criadas no passado pelos browsers. Enquanto sites novos poderiam usufruir dos padrões criados pelo W3C pois seriam tratados pelo Standards mode. O navegador ficou responsável por escolher o modo apropriado através do Doctype usado (ou ausência de um). Veja uma tabela com possíveis declarações de Doctype e seu resultado em cada navegador.

O Quirks mode hoje é uma dor de cabeça para muitos desenvolvedores, é preciso estar ciente de qual modo de renderização está sendo usado em seu site para evitar problemas “misteriosos”. Muitas vezes o Internet Explorer volta a usar o Quirks mode por detalhes como uma declaração XML ou mesmo um comentário antes do Doctype, se você desenvolve seguindo os padrões isso pode facilmente quebrar seu layout.

(Almost) Standards mode é a melhor opção para seu projeto, embora os browsers novos tenham suporte ao Quirks mode é muito complicado e pouco produtivo trabalhar com ele por não ser realmente padronizado. E mesmo utilizando o Standards mode seu site ainda deve ficar “legível” em navegadores antigos.

Leitura recomendada:

• Quirks mode and strict mode
• What happens in Quirks Mode in web browsers?
• Activating the Right Layout Mode Using the Doctype Declaration
• Mozilla’s DOCTYPE sniffing
• Mozilla Quirks Mode Behavior

Essa é uma questão antiga, muitos gostam de considerar o HTML ultrapassado e usam XHTML por ser “sua versão melhorada”. Esse raciocínio não está errado, mas que a verdade seja dita: seu XHTML provavelmente é interpretado como HTML.

Acha estranho? Quando você declara a seguinte tag: <meta http-equiv="content-type" content="text/html; charset=utf-8" />, está dizendo para seu documento ser interpretado como HTML (por mais que tenha escrito em XHTML).

Não se sita mal, (ainda) não considero viável servir documentos como XHTML real nessa web que está sempre sendo atrasada por alguns. Isso não é motivo para abandonar o XHTML e voltar a escrever HTML, somente para algumas pessoas as quais eu respeito a opinião. É interessante continuar escrevendo e validar seu XHTML, de preferência com o DocType Strict.

Você se educa seguindo as rigorosas normas de criação do XHTML e só tende a ganhar com isso, terá mais chances de escrever um código semântico, limpo e organizado (não que no HTML você não possa, a diferença é que o XHTML praticamente te obriga a isso).

Leitura recomendada: XHTML:

• XHTML: pensando no futuro?;
• XHTML Media Types;
• HTML <!DOCTYPE> tag.

Todos que desenvolvem seguindo os padrões do W3C já estão cansados de ver seus trabalhos ficarem ótimos no Firefox, no Opera e outros navegadores com boa adoção dos padrões. Mas quando chega a hora de testar no Internet Explorer quase sempre surgem problemas para resolvermos.

Partindo do ponto que você implementou o design de seu site por CSS as correções para o IE devem ir também na folha de estilos, então você apela para o uso de hacks que impedem seu código de validar e comprometem seu layout em versões futuras do Internet Explorer. E agora?

Agora você pode esquecer aquele monte de hacks e passar a usar comentários condicionais. Eis um artigo em português bem completo falando deles.

O que quero ensinar é a criar uma folha de estilos exclusiva para o Internet Explorer (por exemplo: ie.css) e incluí-la através dos maravilhosos comentários condicionais da seguinte forma:

<!--[if IE]>
<link rel="stylesheet" type="text/css" href="css/ie.css"></link>
<![endif]-->

Lá você poderá realizar todos os ajustes necessários apenas para o IE sem prejudicar a aparência em outros navegadores e muito menos arruinar a validação de seu código.

Mas ainda há um problema, o Internet Explorer 7 já interpreta corretamente alguns valores mas não o suficiente para não precisar de correções. A solução: como seu ie.css não é examinado pelo validador, você pode usar hacks como colocar _ (underline) antes de cada atributo, exemplo:

margin:10px;
_margin:20px;

Nesse caso o Internet Explorer 7 lê o primeiro atributo e ignora o segundo, e as versões anteriores interpretam os dois, mas aplicam o segundo pois sobrepõem o primeiro. Eu gosto de trabalhar assim, sem misturar as gambiarras de compatibilidade com meu CSS principal.

Vale lembrar que novas versões do Internet Explorer tendem a atender melhor os padrões, então utilize os comentários condicionais e hacks com cautela para que isso não venha a quebrar seu layout em versões futuras.