Rafael Marin

Conheço muita, muita gente - principalmente clientes - que ainda estão felizes navegando na Web usando o Internet Explorer 6. Embora já faça um tempinho, o lançamento do Internet Explorer 7 trouxe dois lados distintos para nós, desenvolvedores Web. Talvez quem não conheça os padrões Web, a maneira correta de desenvolver, não tenha se importado muito. Mas nós, fiéis adeptos dos bons costumes, nos deparamos com mais um incômodo.

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

O departamento de produções audiovisuais tem a honra de aprensentar o primeiro screencast feito por mim, o que é sinônimo de que está bem travado, mal-feito e mal-editado. Direto do CamStudio para o Codeshow Videos da Visie.

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

Não é necessário saber muito de inglês para concluir que, provavelmente, o elemento address do XHTML sirva para marcar endereços. Na verdade, nem só endereços: address também marca qualquer tipo de informação de contato. Todos conhecem, certo? Certo (ou quase todos). Todos usam? Na verdade não. Geralmente o pessoal apela pela tag soup.

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.

[update] O autor do 456 Berea Street fez algumas reconsiderações sobre o artigo Help keep accessibility and semantics in HTML (em suma, traduzido, a seguir) no artigo que publicou hoje, Another look at HTML 5. Explica que parte dos tópicos que citou anteriormente podem ter sido fruto de mal entendimento. Em Another look at HTML 5, reitera o conteúdo do artigo Help keep accessibility and semantics in HTML, detalhando mais sua posição quanto ao assunto. Leitura importante.

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.