Acabei de bolar uma nova versão de um velho CSS para formulários semânticos em HTML. A nova versão é muito, muito mais bacana. O HTML é puríssimo e o CSS mínimo, funciona em todos os navegadores modernos e valida! E tem gente que ainda usa tabelas ou -pior ainda- listas pra formulários

O grande truque é colocar os controles do formulário dentro das labels, chamado de label implícito, você sequer precisa declarar um atributo for=”" para especificar o controle relacionado à aquela label. Encontrei a solução desenhando o novo sistema de templates do meu micro-framework, o Base Cube.

Fiz ele em HTML4, mas é facilmente transformável em XHTML, basta apenas mudar pequenos detalhes na sintaxe.

Portanto, recomendo darem uma olhada no meu formulário semântico em HTML e CSS, pode poupar bastante tempo na hora de desenvolver!

O podre, nojento, desprezível, gordurento e mal-cheiroso código que a maioria dos editores visuais gera não é tão ruim assim. O real problema é quando iniciantes tentam utilizar esse tipo de editor sem conhecimento algum de semântica e marcação.

Eu comecei com uma dessas desgraças, o Dreamweaver, na versão 3. Meu primeiro site tinha fundo de espaço sideral e textos em verde, e eu achava o máximo. O código dele eu nunca sequer vi, mas provavelmente era mais sujo do que uma bituca de cigarro jogada em privada de banheiro público.

Hoje eu uso editores visuais menos poderosos, como o TinyMCE e o WYMeditor (ambos web-based) e recentemente notei que o código gerado por eles é bastante limpo e geralmente requer poucas revisões. Bem, o código gerado por eles quando eu escrevo neles. Arrisquei implantar o FCKEditor no no painel de administração de um dos meus clientes e deixar o próprio cliente fazer as alterações nos textos do site. Nem precisa dizer o que houve né?

Após um suave treinamento, o cliente aprendeu como usar o editor e manter o código saudável (expliquei que era importante para manter os rankings nos buscadores) e também manter a identidade visual do site. Antes do treinamento, ele identava os parágrados com espaços, criava colunas com tabelas e insistia em colocar os títulos com cores diferentes em cada página, me senti em uma fábrica de chocolate (nada fantástica).

Ensinar o cliente a mexer em um simples editor visual foi provavelmente menos doloroso do que ensiná-lo HTML ou BBcode, o que prova que é possível fazer uma web com semântica tão ou mais usável do que a atual. Também prova que um desenvolvedor pode usar editores visuais, mas para tirar bom proveito dos mesmos tem que conhecer a semântica do documento que está desenvolvendo.

À partir de hoje, vou procurar incluir editores visuais em mais sites de clientes e testar os resultados antes e depois do treinamento com os mesmos. Pretendo criar um mini-manual de edição semântica visual para leigos, que pode colaborar até com pessoas que escrevem no Microsoft Word (sim, ele tem semântica), o que acham?

Problemas que deveriam ser resolvidos nos Microformatos

1. São um padrão pra incluir dados no HTML, mas não fornecem nenhum padrão para extraí-los.
2. Dificilmente podem ser validados. Você pode até validar um microformato separado, mas se você usar dois microformatos diferentes em conjunto, a coisa complica.
3. Falta de padrões no desenvolvimento dos microformatos: Cada microformato é criado depois de discussões e discussões acerca do problema específico que deve resolver.
4. Você não pode criar seu próprio microformato, afinal, não há maneira padrão de extraí-lo e desenvolvê-lo.

Soluções que o RDFa nos traz em relação aos Microformatos:

1. Há um padrão para incluir dados no XHTML e um padrão para extrair dados do mesmo.
2. Pode ser facilmente validado através de um DTD.
3. “Módulos” são desnecessários no RDFa, há uma metodologia padrão pra descrever qualquer dado.
4. É muito mais simples criar um leitor de RDFa.

Outros problemas que o RDFa nos trás:

1. É construído em XHTML2, que não é suportado pelos navegadores, embora possa ser possível utilizá-lo em outras linguagens de marcação (com poréns).
2. Requer que existam vocabulários RDFS para que se tire proveito da técnica.
3. Sintaxe estranha pra quem está acostumado com HTML normal.

Conclusões

Na dúvida, use os Microformatos. Como eles mesmos (os criadores do padrão) dizem, ele é feito primeiro para humanos e depois para máquinas. Seu uso é bem limitado, mas se você está em dúvida provavelmente não é uma pessoa que vai exigir muito de metainformação entrelaçada. É uma conclusão bem diferente do que o título sugere

Aprenda a enfatizar palavras

• Jamais use as tags <b>, <i> e <u> para enfatizar palavras. Elas são obsoletas.
• Use as tags <strong> e <em>, com cuidado.
• A tag <strong> não significa negrito, a tag <em> não significa itálico.
• A tag <em> tem o mesmo significado da tag <strong>: ênfase. A diferença é que <strong> dá mais ênfase do que <em>.
• Partindo do fato de que <strong> e <em> tem o mesmo significado, fica claro que não devemos utilizá-las juntas.
• Você pode retirar o negrito do <strong> e o itálico do <em> utilizando CSS. Na verdade você pode adicionar qualquer estilo, cor e formatação à essas tags.

Modificando documentos já publicados

Às vezes é necessário alterar documentos e manter informações sobre a alteração. Você pode fazer isso utilizando as tags <del> e <ins>. O texto antigo, que não é mais válido, deve ser colocado dentro da tag <del> e o texto novo, que não existia anteriormente, deve ser colocado dentro da tag <ins>.

• Coloque somente elementos inline, nenhum bloco dentro desses elementos.
• Você pode ocultar o conteúdo anterior ao modificado com CSS e destacar o novo.
• Por padrão, texto excluído fica tachado.

Listando coisas

• Listas não precisam ter necessariamente itens pequenos. Você pode incluir grandes parágrafos e até mesmo títulos dentro de lista. Se algo obedece determinada ordem ou padrão, não hesite em colocá-lo em uma lista.

Você desenvolve usando a filosofia tableless, ótimo. Ela diz que devemos usar os padrões da internet como guia.

Quem conhece os padrões deve saber que existe pra cada tecnologia considerada um padrão uma especificação técnica na página do W3C. Você já leu alguma?

Pois é, chegou a hora de encarar os fatos. Se você não constrói HTML semântico você não está seguindo os padrões.

Chega a ser irônico alguns desenvolvedores seguirem a filosofia tableless e só se preocuparem de fato se devem ou não usar apenas as tabelas, esquecendo que os outros elementos do HTML, principalmente o <div>, também devem obedecer regras e padrões.

Na especificação do HTML você verá que a semântica é importante e devemos respeitar o conteúdo e significado de cada elemento e atributo, e não somente as tabelas.

Se não sabe por onde começar pode dar uma olhada na lista de elementos HTML a cada vez que for usar um deles. Embora seja cansativo é um ótimo exercício didático.

É comum usar o JavaScript pra criar HTML e CSS dinamicamente e dar uma experiência de uso muito melhor para o visitante.A questão é que raramente nos preocupamos com a semântica do código que geramos via JavaScript, afinal, ele não altera o código fonte da página.

Isso com certeza vai mudar, e já existem sinais disso. O Firefox 3 virá com suporte a aplicações web offline, o que significa que ele terá que analisar o JavaScript dessas aplicações e simular as respostas que o servidor gera. Talvez essa seja a primeira de muitas aplicações a considerar aquilo que o JavaScript gera na página e não simplesmente o HTML puro.

No futuro é provável que o JavaScript ganhe muito mais atenção nessa parte do que hoje, principalmente se o Google ou algum grande serviço começar a indexar posts levando em conta o JavaScript das páginas. Inclusive é bem provável que isso aconteça, já que o Mozilla já é utilizado por alguns bots do Google.

Por enquanto não há com o que se preocupar, mas é sempre bom pensar no futuro, não é?

1. Use só em casos de emergência

   Já viu um botão protegido por um vidro com um aviso quebre em caso de emergência? O <div> deveria ter um desses. Use somente quando tiver certeza que não existe elemento melhor.

2. É HTML, não CSS

   Não escravize o HTML, o <div> não existe só pra que você possa usar CSS. Eu insisto muito nesse ponto, crie os ids e classes de maneira descritiva.

3. O <div> é semânticamente neutro

   Na especificação do HTML é dito que os elementos <div> e <span>, em conjunto com os atributos id e class, oferecem um mecanismo genérico para adicionar estrutura aos documentos.

   Isso não significa que ele é completamente sem semântica. Quem dá a semântica pra ele é você usando os atributos id e class.

Além do <div> esses mandamentos servem para o <span> também.

Existem quatro atributos HTML que são praticamente univerais, você pode usar em quase qualquer elemento. São eles o class, id, lang e title.

O class e o id são muito parecidos, inclusive muitas pessoas confundem e usam um no lugar do outro frequentemente. Ambos tem a função de descrever um elemento, sendo o id para identificação e class pra classe (ou grupo).

Pra exemplificar, vou criar um parágrafo sobre mim:

<p id="alexandre-gomes-gaigalas" class="brasileiro">Alexandre é o editor do Acorda pra Web!</p>

Identifique

O id é como um número de RG, não podem existir dois iguais em uma página, por esse motivo eu escolhi colocar meu nome completo e não somente alexandre, dessa maneira eu permito usar ids para outros Alexandres na página.

Classifique

O class classifica o elemento. No caso acima eu utilizei o grupo brasileiro para classificar nacionalidade.

Usando essa classe eu poderia por exemplo colocar um fundo verde e amarelo usando CSS em todos os parágrafos que classificassem brasileiros, ou poderia ocultar todos os parágrafos exceto os brasileiros usando JavaScript e DOM.

É possível ainda utilizar várias classes no mesmo elemento, como veremos abaixo:

<p id="alexandre-gomes-gaigalas" class="brasileiro maior-de-idade programador">Alexandre é o editor do Acorda pra Web!</p>

O exemplo acima é mais rico. As classes brasileiro, maior-de-idade e programador foram colocadas separadas por espaços. Isso me permitiria trabalhar normalmente usando CSS e JavaScript separadamente com cada classe, selecionando apenas brasileiros, apenas programadores ou apenas maiores de idade.

Conclusão

Entendendo a real função dos ids e classes você percebe como é errado colocar uma classe ou id com nome direita, ou vermelho ou mesmo rodapé. Esses são todos nomes que descrevem aspectos visuais, não conteúdo.

Você tem que pensar no motivo que te leva a identificar ou classificar um elemento, e não no resultado visual que deseja atribuir usando CSS. Não escravize o HTML.

Pra finalizar o artigo, vamos criar um exercício mental e colaborativo, e dependendo desse exercício eu crio um mega-exemplo e coloco pra vocês semana que vem:

Como você se classificaria usando classes no HTML?

O framework para aplicações em AJAX Spry, da Adobe, é sem dúvida ágil e organizado na maneira de programar, mas é um assassino da semântica no HTML!

Ao contrário de frameworks muito populares como o Prototype, jQuery e MooTools, que permitem que você crie JavaScript não-obstrutivo, o Spry incentiva uma série de práticas que vão totalmente contra os padrões:

• Novos atributos para elementos HTML (spry:whatever)
• Utilização massiva de onClick, onMouseOver e similares.
• Necessidade de JavaScript para a página funcionar.

Em outras palavras a Adobe pisou na bola. Não recomendo o Spry.

Um problema social no mundo das linguagens pra internet que anda ocorrendo com frequência é a escravização do HTML, mesmo já idoso e com seus anos de experiência. Dá até tema de novela, o irmão que nasceu pra completar o HTML acabou por escravizá-lo: O CSS.

Brincadeiras à parte, isso acabou se tornando mesmo uma realidade. Utilizamos o CSS para duramente escravizar o HTML, alguns exemplos com os quais você pode se identificar:

• O cliente afirma “Quero um site com a lista de links e o campo de busca na coluna da direita” e você prontamente ajeita o chicote do seu CSS e cria um div no HTML chamado “coluna-direita” com tudo que ele quer dentro.
• A direção da empresa mudou e decidem que agora a lista de links fica no rodapé. Rapidamente você pega e coloca o HTML no tronco, criando um div chamado “rodape” e movendo o código do “coluna-direita” pra lá.

Aparentemente não há nada de errado com esses procedimentos, você provavelmente já fez algo parecido antes. Mas e se tivesse um jeito melhor?

A sinhazinha mais famosa na década passada era a tabela, ela jogava o conteúdo pra lá e pra cá só pra atender aos desejos do layout. Esse é um dos piores aspectos da web sem padrões, e ainda continua. A senzala mudou de dono, agora quem manda é o CSS.

E se desde o começo você decidisse que a lista de links entraria no div “lista de links” e quando fosse necessário mudar a posição da mesma, alteraria apenas o CSS? O mesmo para o campo de busca, ele entraria no div “busca”, e assim por diante. Cada elemento da página entraria em um elemento que é capaz de descrevê-lo, e todos os demais seriam eliminados. Isso é semântica!

Esqueça coisas no HTML como “coluna-direita”, “cabeçalho” e “rodape”, crie elementos que realmente mostram o que eles são no conteúdo e não no visual.

O HTML e o CSS tem que ser irmãos, e se respeitar. Layout respeita conteúdo. Há dúvidas de que tudo funciona melhor assim?