XHTML & HTML

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/> …

[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 …

Já dizia minha avó que os CMS’s não se dão muito bem com os desenvolvedores dentro dos padrões. Como todos nós bem sabemos, isto se deve a presença dos editores WYSIWYG (O que você vê é o que você obtém). É característica vital da maioria deles a geração de um código poluído, confuso e nada semântico. 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á …

Lendo alguns artigos ? respeito de Validação e Semântica, como o artigo que o Henrique do Revolução Etc escreveu sobre o assunto, resolvi criar a minha versão para este assunto. Talvez eu seja o centésimo que esteja escrevendo sobre isto, mas não importa. 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 …

Após ler no A List Apart sobre a tag <q>, resolvi fazer uma versão em português. 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 …