Sim, caros amigos leitores, se já não bastassem algumas incompatibilidades com a versão 6, temos hoje também que nos preocupar com correções de bugs para a versão 7. De certa forma, a empresa de Redmont criou uma preocupação a mais para nós, visto que a migração é algo difícil – especialmente levando em consideração que grande parte dos usuários de Internet mal sabem ligar o computador.

Sei que a notícia já é velha, que o IE8 foi anunciado há algum tempo, e que ele até passa no Acid Test 2. Meu site é bem renderizado no Internet Explorer 8 Beta 1, embora possua algumas pequenas falhas.

Como a Microsoft gosta de criar confusão, não? Vem aí mais um navegador, e mesmo com suporte impecabilíssimo ao CSS, ainda criará problemas de backwards compatibility. Vindo com Standards mode por padrão, boa parte dos sites até então funcionando no IE6 e IE7 provavelmente quebrarão, ou sofrerão pequenas alterações como aconteceu com o meu. Mas ainda é cedo para se preocupar, pois estamos em um estágio Beta.

Atentem para o fato de que sou totalmente a favor da iniciativa da Microsoft em seguir inteiramente as especificações da W3C. Isso é um grande avanço para a Web. Contudo, precisamos acabar de vez com os navegadores antigos, forçando a migração, mesmo que através de atitudes arrogantes. Ainda que existam maneiras de contornar essas incompatibilidades, como CSS hacks, conditional comments, e agora browser version targeting, está na hora de evoluir um pouco e parar de ficar amarrado lá atrás, em 2002.

Leia também

• Beyond DOCTYPE: Web Standards, Forward Compatibility, and IE8 – A List Apart
• Internet Explorer 8 e o modo Super Standard – Pinceladas da Web
• Browser Targeting Version – Tableless

Mesmo assim, é um tutorial básico que ensina a montar o HTML de uma página “tableless”. Em uma próxima oportunidade eu posto a segunda parte, com a camada de apresentação – o CSS.

Link para o vídeo

[update] Link para o HTML do tutorial

Dentro do elemento address você é livre para inserir quaisquer outros elementos inline, como a, span, strong, e por aí vai. Na realidade, é um elemento simples de ser entendido. Vamos a um exemplinho (tirado do código-fonte do site da Visie):

<address>
<a href="http://visie.com.br/" class="logorodape">Visie Treinamentos Web</a>
<span>

Av. Fagundes Filho, 145, Ed. Austin, Conj. 58 <br/>
CEP: 04304-010, Vila Monte Alegre, São Paulo - SP <br/>
T 11 3477.3347 | <a href="http://www.google.com/" title="Como chegar na Visie">Mapa de como chegar</a><br/>

</span>

</address>

Se você reparar, não existe qualquer dificuldade. Jogue lá dentro suas informações de contato. Inclua dentro quaisquer outros elementos inline.

Atributos definidos

Você pode utilizar os seguintes atributos com o elemento address:

• id,class — identificação
• lang,dir — idioma e direção do texto, respectivamente
• title — título do elemento
• style — formatação inline
• onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, onmouseout, onkeypress, onkeydown, onkeyup — eventos instrínsecos

address e o microformato hCard

Hoje em dia, entretanto, a melhor maneira de marcar endereços é através do microformato hCard. Mesmo assim pode-se utilizar o elemento address com um hCard, aumentando ainda mais a sua semântica. Há um exemplo de utilização do elemento address com o microformato hCard, no Wiki do Microformats.org.

Depois do que li no 456 Berea Street, fiquei pasmo com a mente de alguns membros do W3C HTML Working Group. Tem gente por lá dizendo, em outras palavras, que semântica e acessibilidade não são importantes. Veja só:

• Há pessoas contra o valor da semântica e em favor de adicionar mais marcações para controlar a apresentação;
• No Rascunho do HTML 5/Web Applications 1.0, recursos de acessibilidade como os atributos summary, headers, e axis (usados para tornar tabelas de dados mais acessíveis) foram removidas sem qualquer explicação;
• O conhecimento geral sobre acessibilidade dos membros do W3C HTML Working Group é surpreendentemente limitado;
• Alguns dos cabeças são vendedores de browsers que parecem ter uma extrema fobia de fazer qualquer coisa para desencorajar o uso de tag soups inválidas e inacessíveis.

E ai daquele que não ficar indignado. A Web já é uma bagunça. Quando um grupo se mobiliza para reverter a situação, membros do próprio grupo resolvem amarrar o burro e gritar “Voltemos ? era da Internet jurássica”. OK, pode ser um exagero, mas foi assim que soou a notícia quando a li.

Pelo jeito, a nova versão do HTML não trará nenhum benefício. As mudanças só irão beneficiar os fabricantes de “browsers” e web developers ignorantes. E os que restarem ficarão com o HTML 4.01 Strict. E deu pra bola.

O que as novas versões do HTML precisam é de mais semântica e menos apresentação, e o que os browsers precisam é de suporte decente ao CSS.

‘application/xhtml+xml’ SHOULD be used for serving XHTML documents to XHTML user agents. Authors who wish to support both XHTML and HTML user agents MAY utilize content negotiation by serving HTML documents as ‘text/html’ and XHTML documents as ‘application/xhtml+xml’.

Ou seja, o autor que deseja dar suporte tanto para user agents XHTML quanto para HTML, deve utilizar negociação de conteúdo para servir documentos com o MIME Type adequado a situação. Um simples script em PHP resolve o problema:

<?php
if (stristr($_SERVER[HTTP_ACCEPT], "application/xhtml+xml") ||
stristr($_SERVER["HTTP_USER_AGENT"], "W3C Validator")) {
header("Content-Type: application/xhtml+xml; charset=iso-8859-1");
header("Vary: Accept");
echo("<?xml version=\"1.0\" encoding=\"iso-8859-1\" ?>\n");
} else {
header("Content-Type: text/html; charset=iso-8859-1");
header("Vary: Accept");
}
?>


O script verifica se o agente de usuário suporta o application/xhtml+xml, ou se o agente de usuário é o W3C Validator. Caso um deles seja verdadeiro, o documento é servido como application/xhtml+xml, caso contrário, ele é servido como text/html. Além disso, se um deles for verdadeiro, o documento recebe a declaração XML.

O cabeçalho Vary: Accept é enviado para que agentes intermediários de cache, como proxy servers, saibam que o MIME Type varia, de acordo com o suporte que o agente de usuário oferece.

O benefício disso tudo é que em browsers como Firefox e Mozilla, que suportam o MIME Type application/xhtml+xml, o código XHTML é tratado como XML no que se refere a intolerância a erros. Ou seja, se um documento XHTML, com MIME Type application/xhtml+xml possuir erros de sintaxe, estes browsers não irão mostrá-lo, assim como acontece com o XML inválido. Somente serão exibidos os documentos assim que os erros de sintaxe estiverem corrigidos. Assim, nem o W3C Validator é necessário para apontar erros.

Veja também

• Content negotiation – 456 Berea Street
• Content negotiation, AdSense, and comments – 456 Berea Street
• Content negotiation – Japs.etc.br

Muitas vezes não adianta entregar o site 100% compliant e o cliente próprio atualizar o site com o editor que você instalou, e o cliente atualizar sem se importar com o código, fazendo o trabalho ir por água abaixo. Uma solução seria ensinar o cliente a utilizar códigos como BBCode dos fóruns e o Markdown da Wikipedia. Nem pensar, não é?

Neste cenário está se difundindo um editor, o WYMeditor, que segue uma linha conhecida por WYSIWYM (O que você vê é o que você quer dizer). É um editor que se preocupa com a clareza e semântica do código, se concentrando na estruturação do código, e não na sua formatação. O usuário do editor determina apenas parágrafos, links, headings, imagens, ênfases, e tudo o que se refere ? estruturação do código. Nada de cores, fontes e tamanhos. Quem se encarrega disso são as folhas de estilo do site.

Há um demo on-line para quem quiser experimentá-lo. E ele é bastante extensível. É feito com JavaScript simples, suporta skins, é fácil de integrar e é GRÁTIS e OPEN SOURCE.

Ainda há muito para ser feito, mas como ele está ainda no início, muitas atualizações estão por vir. Sugiro a todos que experimentem!

Update: Aproveite também para conhecer outros dois projetos, o WYMstyle, um framework de CSS que pode ajudar no desenvolvimento rápido de layouts (pois é um conjunto de CSSs modulares), e o WYMsite, um CMS 100% compliant (XHTML Strict), feito em PHP 5, URLs amigáveis nativas, com dados baseados em XML, leve e extensível.
Não vou deixar minha opinião sobre estes ainda, pois não fiz grandes testes.

Existem espalhadas pela web algumas cartilhas, ou cheat sheets, que facilitam bastante o trabalho de quem está começando. São grandes tabelas que contém todos os elementos do HTML, CSS, JavaScript e Microformatos, e que quebram um galho enorme algumas vezes quando um elemento ou outro escapa da mente.

Mas, para não dar uma de parasita e consumir a banda dos outros, fiz o upload dos arquivos (que estão em PDF) no meu servidor.

Faça o download

Seguem os links:

• HTML Cheat Sheet, de Liquid City
• CSS Cheat Sheet, de Liquid City
• JavaScript Cheat Sheet, de I Love Jack Daniel’s
• Microformats Cheat Sheet, de Microformats.org

Como em todos as páginas – teoricamente – os parágrafos de texto estão marcados com a tag <p>, fica fácil para os programas que lêem estes documentos reconhecer o significado do conteúdo. O mesmo ocorre com todas as outras tags do HTML e XHTML.

Agora, imagine se em um site X a tag para marcar parágrafos fosse <bbbbb>, em um site Y fosse <aaaaa>, em um site Z fosse <ccccc> (e assim por diante). Como os browsers, indexadores e leitores de tela entenderiam o conteúdo das tags? Impossível, né?

Neste contexto surgem os microformatos (microformats). Eles criaram novos padrões que agregam mais significado ainda ao conteúdo, através de informações que só são vistas no código HTML. Assim como usamos <p> para parágrafos <hx> para títulos, os microformatos utilizam o valores de atributo para padronizar a informação em uma série de situações.

Por exemplo, uma das especificações dos microformatos é o hReview. O hReview é uma especificação dos microformatos destinada ? reviews de produtos, livros, enfim, de tudo o que é possível de se fazer um review. Você cria o seu review utilizando as marcações e valores de atributo que esta especificação definiu. Mecanismos, como o Technorati, fazem a leitura do seu blog/site e lêem estas classes e valores de atributo e sabem que aquilo se trata de um review. E o fazem da mesma maneira como lêem uma tag <p> e sabem que trata-se de um parágrafo.

Existem outras especificações interessantes, como a hCard, para informações pessoais (como um cartão de visita), a hCalendar, para eventos, entre outros que são um pouco distintos e que falarei mais adiante.

Os microformatos vieram para atribuir mais significado ao conteúdo, extendendo ainda mais o HTML. Caso você ainda não tenha pego o fio da meada, tente ler outros artigos que listarei abaixo e ainda, aprofundar um pouco mais o conhecimento dos padrões Web e sua importância.

Existem vários artigos sobre microformatos no Revolução Etc do Henrique, mas no site oficial dos Microformats e no Wiki dele existem mais informações sobre todas as especificações.

Aos poucos vou falando das especificações de forma um pouco mais profunda, mas por enquanto é só.

Round 1: Validação

Muitos pensam pensam que um site validado pelo W3C é o suficiente, principalmente os iniciantes no assunto de Web Standards. É fundamental que o desenvolvedor conheça ao menos qual o papel real do Validador da W3C. Ao validar o código, você apenas verifica que não há nenhum erro de sintaxe, como uma tag que não foi fechada, e coisas do gênero. Só, e nada mais.

Round 2: Semântica

Talvez seja uma das gafes mais comuns cometidas pelos iniciantes confundir validação e semântica. Basicamente, a validação consiste em verificar se não há erros de sintaxe, e semântica é atribuir as tags adequadas de acordo com o conteúdo. Isso significa que usamos as tags <p> para parágrafos, <h1> (e as outras tags h) para títulos, e assim por diante.

O único validador de semântica que existe é você mesmo. Uma máquina não consegue verificar se o texto de uma tag <p> realmente é um parágrafo, ou se é um elemento com uma classe que o torna com a aparência de título.

Cabe exclusivamente a você avaliar se o seu código é semântico – o que exige experiência, e o que eu considero muito mais importante do que a validação. Por isso ? s vezes nem ligo se na validação ficam ainda alguns warnings – claro que tento corrigí-los ao máximo quando possível, mas é algo que não incomoda justamente por que uma das causas destes warnings são as adaptações necessárias para que o site rode tranqüilamente, sem distorções, em diferentes plataformas e browsers.

Ter um código sem erros é ótimo, e para isto (leia-se: SOMENTE para isto) é que serve o validador. Mas um código semântico, onde as tags realmente são usadas para sua devida função, vale muito mais.

Vou citar um exemplo que mostra a diferença entre validação e semântica, antes de encerrar este artigo: a tag <table> é utilizada para criar tabelas de dados, mas nos últimos tempos vêm sido usada por muitos desenvolvedores para estruturar o corpo da página. Isto é correto? Não, não é correto. Não é semanticamente correto, pois a tag <table> não foi planejada para a estruturação do corpo da página.

Mesmo não sendo o propósito da tag <table>, que é o de exibir dados tabulares, mas fazendo a tabela sem erros de HTML, o código será validado pelo validador. O código é válido? Sim, é válido. É semântico? Não.

Mais sobre o assunto

Em outros sites você encontra outras versões – melhores que a minha talvez – para este assunto. O Jader escreveu um bom artigo ? respeito, e o Henrique do Revolução Etc escreveu vários. Ah, o Maujor também escreveu um ótimo artigo.

A tag <q> existe há aproximadamente 9 anos, desde a primeira versão do HTML 4.0. Sua principal função é exibir citações (quotations) curtas e inline, que não necessitem de quebras de parágrafo. A tag <q> é muitas vezes associada com a tag <blockquote>, que é usada para grandes citações, em forma de bloco. Desde a implementação da tag junto ao HTML 4.0, ela nunca foi totalmente compatível com o IE para Windows. Teoricamente, antes e depois conteúdo dentro da tag <q> deveriam ser renderizadas aspas. Mas o IE não o faz. Talvez este seja um dos motivos pelo qual muitos desenvolvedores deixam de usar a tag <q>. Acompanhe o exemplo:

Esta citação está incluída dentro de uma tag q. Em navegadores como o Opera e FF aparecerão as aspas no início e no fim desta citação. Caso esteja usando o IE, elas não aparecerão.

Para resolver este problema, poderíamos usar CSS para deixar a tag <q> em itálico, o que causaria confusão, pois citações curtas e inline ficariam difíceis de reconhecer sem as aspas – além da tag <cite> ser renderizada pelo browser em itálico. Usar JavaScript para renderizar as aspas também não resolveria pois, caso o user-agent não suportasse JavaScript, as aspas não seriam renderizadas. Deixar de usar a tag <q> – o que muitos fazem – também não resolveria o problema, pois o código não ficaria semântico. Usar <blockquote> não seria bom, pois usar a tag incorreta não é a solução. E, finalmente, inserir as suas próprias aspas (o que também não resolveria, pois em browsers que suportam bem a tag <q> seriam geradas aspas duplas). Podemos, todavia, usar generated content no CSS para alterar todos os outros browsers. ao invés de buscar uma solução semanticamente correta para o IE. Acompanhe o exemplo a seguir:

q:before, q:after{
content: "";
}

Como você pode ver, a propriedade content: está em branco, pois isso remove as aspas em todos os browsers. (Lembrando que no IE/Win os pseudo-elementos :before e :after não são reconhecidos, mas não faz diferença pois este truque não é voltado ao IE/Win, e sim a todos os outros browsers).

E então, adicionar aspas você mesmo antes e depois da tag <q>, fora das tags, como no exemplo abaixo:

Segundo Seu Madruga, "<q>A vingança nunca é plena, mata a alma e a envenena.</q>" o que nos leva a concluir que...

OBS: Lembrando de adicionar o código CSS que citei acima.

O que diz a W3C?

Segundo a Especificação W3C HTML 4.01:

Visual user agents must ensure that the content of the q element is rendered with delimiting quotation marks. Authors should not put quotation marks at the beginning and end of the content of a q element.

Ou seja, os autores não devem usar as aspas dentro das tags <q>, pois também estas deveriam ser renderizadas automaticamente com as aspas.

A forma descrita pelo autor do artigo no A List Apart também me soa um pouco mais semanticamente correta, pois não depende de JavaScript, e não desobedece ? s especificações da W3C.

Links relacionados:

• Long live the Q tag – A List Apart – Artigo original no qual me baseei.