Estruturando um documento

Construir um site com os padrões Web significa tomar as providências necessárias para que cada documento no site conforme-se às especificações do formato em que é servido e a especificações adicionais de auxílio ao uso do mesmo. Isso implica em não somente ter um documento que atenda à letra das especificações mas que também seja estruturado apropriadamente.

O W3C, que é o órgão gestor da maioria dos padrões importantes da Web, define quatro princípios que devem ser aplicados à criação de um site de modo os documentos nele contidos sejam completamente utilizáveis. Um site deve ser:

Perceptível

Isso significa que o conteúdo presente no site deve ser apresentado de uma forma que é perceptível para qualquer pessoa, ou seja, o site deve ser capaz de degradar graciosamente sob as mais rigorosas condições.

Operável

Isso significa que os elementos de interface presentes em um site devem ser operáveis por qualquer pessoa, ou seja, o site deve facilitar a navegação e a orientação através do conteúdo do mesmo.

Inteligível

Isso significa que o site deve tornar fácil a identificação de seu conteúdo e dos seus controles acessórios, ou seja, o site deve ser auto-evidente e não colocar nenhum ônus sobre usuários menos experimentados ou com dificuldades de acesso.

Robusto

Isso significa que o site deve usar tecnologias que maximizam a compatibilidade de sua estrutura com navegadores atuais e futuros, tecnologias de acessibilidade e outros programas, ou seja, o site deve ser capaz de preservar a sua integridade tecnológica.

Embora esses princípios se refiram basicamente à acessibilidade se um site, eles também formam uma boa base para os critérios que dever nortear o desenvolvimento de um site segundo os padrões Web de maneira mais geral.

A primeira etapa, então, no desenvolvimento desse tipo de sites, é estruturar os documentos que formam o conteúdo do mesmo. Essa estruturação envolve alguns passos distintos que serão explicados, analisados e exemplificados abaixo.

Escolhendo o formato

O primeiro passo na estruturação de um documento hipertexto é escolher o formato em que ele será servido. Hoje em dia, a maioria dos documentos Web pode ser encontrada em dois formatos de amplo uso: o HTML e o XHTML.

Cada um desses formatos possui suas vantagens e desvantagens e cabe ao desenvolvedor escolher o que mais lhe interesse e seja útil na implementação de seus sites.

Como explicado no primeiro artigo, o XHTML é na verdade o sucessor intencionado do HTML. Apesar desse alvo, o suporte a este novo formato é ainda um tanto ou quanto deficiente na maioria dos navegadores atuais e vai demorar um certo tempo até que ele se transforme no formato padrão de fato para documentos hipertexto. Entretanto, o W3C já deixou bem claro que a especificação HTML 4.01 é a última a ser aprovada para o padrão HTML. Isso quer dizer que somente a especificação XHTML será desenvolvida nos próximos anos. Obviamente o suporte a HTML será mantido indefinidamente nos navegadores em existência e em quaisquer outros que venham a ser criados em um futuro próximo, mas nenhuma nova funcionalidade será acrescentada ao mesmo. Por exemplo, a nova geração de formulários Web, XForms, está vinculado ao padrão XHTML. Sites futuros, querendo aproveitar o suporte a essa tecnologia que será implementado (espera-se) em um tempo não muito distante nos navegadores em desenvolvimento atualmente, terão que converter os seus sites para XHTML. Assim, a utilização do XHTML hoje já prepara um site para a compatibilidade com padrões e implementações futuras.

Surpreendentemente, tanto o HTML como o XHTML compartilham um ancestral: o padrão SGML. A diferença é que o HTML é um descendente direto do SGML com regras mais liberais que inclusive foram a causa da sua ampla adoção. O XHTML, por outro lado, é uma aplicação do padrão XML, que também veio do SGML, mas que algumas acrescenta regras mais rígidas quanto à formatação dos documentos para facilitar a estruturação dos documentos e o desenvolvimento de ferramentas de maniputação do mesmo. Apesar dessa rigidez, o XHTML possui mais suporte à extensão dos documentos através de espaços de nomes que podem acrescentar novos itens à especificação sem interferir no suporte ao mesmo nas ferramentas existentes. Essa extensibilidade ainda não é aproveitada em nenhum dos navegadores existentes mas é possível que no futuro ela venha a ser implementada efetivamente. Enquanto isso, ela vem sendo bem aproveitada em outros formatos baseados no XML.

A diferença mais visível entre o HTML e o XHTML está na sintaxe. Isso ocorre por que o XHTML foi implementado, em termos de especificação, com base no HTML, ou seja, os elementos da especificação HTML mais recente, a 4.01, foram portados para o formato XML, com algumas correções, e chamados de XHTML. Isso manteve a compatibilidade para trás do novo padrão permitindo que ele fosse adotado sem que suporte específico e imediato tivesse que ser implementado nos navegadores em existência na época. Com o passar do tempo, um suporte mais efetivo foi adicionado aos navegadores permitindo um maior aproveitamento do padrão. Como dito anteriormente, ainda há uma longa estrada a percorrer, mas as sementes para o futuro desses dois padrões já foram lançadas.

Por uma questão da forma como a maioria dos navegadores foi implementada inicialmente, um site atual pode servir os seus documentos em XHTML e tê-los interpretados sem problemas por navegadores que somente entendem HTML. Isso vem do fato de que a maioria dos navegadores processam um documento HTML da forma mais aberta possível, automaticamente corrigindo erros cometidos pelo criador do documento. Entretanto, isso causa uma série de problemas. Primeiro, esse tratamento automático de erros deixa os criadores de documentos mais relapsos, sem se preocupar com a correção do que produzem. Segundo, ele torna a implementação de um navegador muito mais complexa já que os desenvolvedores do mesmo precisam codificar as situações de erro. Terceiro, ele torna as implementações do padrão discrepantes já que cada navegador implementa sua própria forma desse tratamento. Por fim, ele aumenta a complexidade da manutenção dos documentos já que cada um deles acaba sendo feito sem preocupações com a forma.

O XHTML corrige o problema acima exigindo que um documento nesse padrão obedeça a regras estritas de sintaxe. Um processador XML, que como vimos é a base do XHTML, pode (e deve) interromper o leitura e uso de um documento no primeiro erro encontrado, como definido na especificação. Isso torna a implementação dos mesmos mais simples colocando o ônus da correção sob o criador do documento. Entretanto, pela forma como os navegadores estão implementados, eles normalmente tendem a interpretar um documento XHTML falho como se fosse um documento HTML. Esse procedimento, embora necessário por questões de compatibilidade, também pode levar os criadores de documentos a serem menos cuidadosos e é algo que deve ser mantido em mente quando da construção de um site com os padrões Web.

Dito isso, é necessário entender dois conceitos chave relativos à linguagens de marcação. Ambos os conceitos são válidos tanto para o HTML como para o XHTML, embora sejam mais visíveis neste último por estarem explicitados na especificação.

O primeiro desses conceito é a boa-formação (uma tradução livre de well-formedness). Esse conceito refere-se ao fato de um documento conformar-se a algumas regras básicas. Se qualquer dessas regras for violada durante o processamento de um documento, o mesmo deve ser interrompido imediatamente. As mais importantes dessas regras de boa-formação exigem que:

Essas regras são explicadas de maneira mais formal na especificação do padrão e você pode referir-se à mesma para mais informações e também as outras regras necessárias.

O conceito de validação, por outro lado, refere-se ao fato de que um documento possui uma DTD e conformar-se às limitações expressas na mesma. Uma DTD, que significa Document Type Declaration -- ou declaração de tipo de documento -- é uma compilação das regras que definem a estrutura de um documento. Essa declaração pode ser expressa diretamente no corpo do documento ou estar contida em um arquivo externo que é referenciado por meio de uma instrução de processamento no cabeçalho do documento. A DTD define quais são os elementos permissíveis no documento, quais são os seus atributos e valores permitidos, as condições de aninhamento dos elementos e as condições de ocorrência dos mesmos. Um documento só é válido quanto ele atende a todas as condições impostas em sua DTD e qualquer erro no processo de validação deve causar uma interrupção neste processeamento, como definido na especificação. Obviamente, um documento só pode ser válido se também for bem-formado. Entretanto, ao contrário da boa-formação, que deve ser exigida por qualquer processador SGML ou XML, a validação é opcional e serve mais como um verificação estrutural do documento. A maioria dos navegadores não verifica a validade de um documento embora verifique a boa-formação se o conteúdo é detectado como sendo XHTML. Isso, é claro, não exclui o desenvolvedor da necessidade de validar os documentos que cria para garantir o seu correto funcionamento e interpretação pelos agentes envolvidos.

Um exemplo de validação no caso do XHTML e HTML, por exemplo, é a regra na DTD dos mesmos que impede que elementos de bloco, como o elemento p, sejam aninhados em documentos em linha, como o elemento em. Assim, o seguinte fragmento XHTML é bem-formado, mas não é válido:

<em>Fragmento bem-formado, mas <p>inválido</p></em>

Como as regras do HTML são mais relaxadas, o seguinte fragmento HTML é tanto bem-formado como válido:

<p>Este é um fragmento HTML válido.<br>Sim, é.
<p>Este é um fragmento HTML válido.<br>Sim, é.

Ao contrário do HTML, o XHTML não permite que o tag de fechamento de alguns elementos seja omitido e nem que elementos vazios sejam declarados com o fechamento implícito. Assim, o fragmento acima, para ser convertido em XHTML bem-formado e válido, teria que ser transformado no seguinte:

<p>Este é um fragmento XHTML válido.<br />Sim, é.</p>
<p>Este é um fragmento XHTML válido.<br />Sim, é.</p>

Tanto a boa-formação quanto a validade de um documento pode ser verificados por programas especiais chamados apropriadamente de validadores. Existem vários validadores, grátis e comerciais, disponíveis no mercado. Como nós vimos no artigo anterior, alguns desses podem ser diretamente integrados ao navegador permitindo uma maior facilidade de uso. O principal validador HTML/XHTML em existência hoje é do próprio site do W3C. Este validador permite verificar um documento contra as especificações HTML e XHTML e reporta os erros encontrados usando um processador SGML que não tem como requerimento parar no primeiro erro encontrado. Lembrando que tanto o HTML como o XHTML descendem do SGML, este é um processo seguro e eficiente. Uma regra básica no desenvolvimento de qualquer site é validar os documentos presentes no mesmo após a sua criação. Isso garante que os documentos serão manipulados na maneira intencionada pela especificação nos navegadores. Obviamente existem problemas de implementação em qualquer navegador. A validade dos documentos é uma das maneiras de minimizar o impacto desses erros de implementação.

Cabe aqui uma aviso: a escolha de um formato determina os elementos e atributos que você pode usar no seu documento. Por exemplo, o atributo bgcolor do elemento body não existe no formato XHTML e somente pode ser obtido via CSS. A validação do documento irá detectar esses erros mas é preferível que você saiba de antemão o que você pode usar. Você pode obter essas informações no site do W3C nas páginas de cada especificação.

Atualmente, para o máximo de compatibilidade, eu recomendo a escolha do HTML 4.01 como o padrão para a criação de documento. A não ser que você queira manter-se na frente tecnológica em relação a esses padrões e lidar com os problemas decorrentes disso, o HTML é a escolha mais segura. Um exemplo disso é o fato do Opera não suporta JavaScript em documentos XHTML. Embora o XHTML permita um caminho mais simples para o suporte aos padrões futuros, a migração de um formato para o outro não é excessivamente complexa, embora seja trabalhosa. Considerando que essa migração não é uma necessidade imediata, o HTML se torna uma escolha ainda mais óbvia.

Escolhendo um DOCTYPE

Uma vez que o formato em que os documentos serão servidos tenha sido escolhido é hora de escolher um DOCTYPE apropriado. O DOCTYPE é nada menos que a indicação da DTD escolhida para o documento. Assim, em outras palavras, é hora de escolher contra qual DTD o documento será validado.

Como vimos acima, uma DTD especifica as capacidades de um determinado padrão ou formato. Essas informações são utilizadas por um navegador ou qualquer outra aplicação que processe o formato para tomar decisões sobre como ele deve ser manipulado. Como existe uma DTD separada para cada versão e variação de um padrão, elas permitem um controle mais granulado sobre o modo como um documento é tratado naquele formato.

No caso do HTML e XHTML, além da validação, uma DTD atende a dois outros objetivos distintos.

O primeiro objetivo é manter a compatibilidade entre as várias versões desses padrões. Isso atende a alguns problemas na implementação dos diversos navegadores em uso atualmente. Devido ao tempo que uma especificação demora para ser aprovada, a maioria das empresas que criam navegadores costuma introduzir características de versões futuras nos seus navegadores de produção criando problemas de compatibilidade que precisam ser resolvidos em especificações próximas. Além disso, no caso de grandes mudanças em uma especificação, é interessante permitir que os criadores sejam capazes de fazer uma migração gradual de seus documentos para novas versões de um padrões ou para padrões sucessores. Para isto, tanto o HTML quanto o XHTML providenciam três DTDs: Transitional, Strict and Frameset. Em qualquer dos dois padrões, a DTD Transitional permite que um documento utilize alguns recursos deprecados na nova versão mas que ainda são úteis para suportar navegadores mais antigos. Um exemplo é o uso de elementos que podem ser completamente substituídos por regras de estilo. A DTD Strict, por outro lado, é DTD que contém a definição formal da especificação tal como ela deve ser usada. A DTD Frameset inclui os elementos necessários para o uso de frames, que nem sempre são necessárias em um site. A escolha da DTD deve ser feita de acordo com os recursos que um site precisa usar. Embora uma DTD mais estrita seja o ideal, algumas vezes é necessário fazer um compromisso para que um site renderize de maneira adequada em todas as plataformas.

O segundo objetivo é indicar a um navegador o tipo de renderização que deve ser efetuada. À medida que os navegadores conformam-se aos padrões mais modernos, alguns problemas surgem quanto ao suporte dos padrões mais antigos. Páginas antigas, feitas para contornar os problemas de implementação existentes na época em que foram criadas, acabam sendo renderizadas de maneira incorreta em versões mais novas dos navegadores onde os problemas já foram corrigidos. Para lidar com essa dificuldade, a maioria dos navegadores modernos é capaz de funcionar em dois modos diferentes: um modo de renderização que se conforma aos padrões (standards-compliant mode) e um outro modo de renderização que emula os problemas existentes em versões anteriores (quirks mode). No caso do Mozilla, por exemplo, dependendo do modo como o HTML é escrito, ele tenta emular o modo de renderização do Netscape 4, permitindo que páginas criadas para este navegador continuem sendo exibidas corretamente mesmo quando usam uma marcação inválida para os padrões atuais. O uso de uma DTD permite então que um navegador detecte de maneira mais simples em qual modo o documento deve ser renderizado. A ausência de uma DTD normalmente joga o navegador no modo de emulação de problemas, impedindo que um site aproveite os recursos mais modernos presentes em um padrão. A diferença na renderização chega a ser impressionante em alguns casos. No Internet Explorer, por exemplo, a implementação CSS usada muda de acordo com o DOCTYPE escolhido, afetando completamente a exibição do documento.

Uma vez determinada, então, a DTD que o documento vai utilizar, de acordo com as capacidades requeridas, é hora de introduzi-la no documento.

As DTDs acima mencionada são:

HTML 4.01 Strict, Transitional, Frameset
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
	"http://www.w3.org/TR/html4/strict.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
	"http://www.w3.org/TR/html4/loose.dtd">
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN"
	"http://www.w3.org/TR/html4/frameset.dtd">
XHTML 1.0 Strict, Transitional, Frameset
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN""
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
	"http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
XHTML 1.1 DTD
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

Cada DTD dessas irá automaticamente informar ao navegador que a renderização deve ser feita de acordo com o padrão especificada na mesmo. Uma DTD deve especificar uma URL absoluta. O uso de uma URL relativa ao site indica que a DTD é específica ao documento e, como o navegador não tem como detectar se ela é exatamente igual ao padrão, o modo de emulação de problemas será usado para o documento. No caso do Mozilla, o uso de uma DTD Transitional ou Frameset irá fazer o navegador entrar em um modo em que alguns dos problemas são emulados embora na maior parte o modo de renderização em completa conformação com os padrões seja usado (almost standards-compliant mode). Você pode encontrar mais informações sobre o assunto nas páginas específicas sobre os modos de renderização do Mozilla e os modos de renderização do Internet Explorer.

A declaração do DOCTYPE deve aparecer na primeira linha do documento. No caso específico do XHTML, já que o mesmo é baseado no XML, instruções de processamento podem aparecer antes -- como o prólogo, no exemplo abaixo:

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
	"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">

A única ressalva aqui é que, no Internet Explorer 6, o prólogo impede a utilização do modo de suporte aos padrões. Como o prólogo é opcional, ele pode ser deixado de lado no caso específico do XHTML. Entrentanto, note que, como mostrado no exemplo acima, o prólogo especifica a codificação do documento. Caso você remova o prólogo, você terá que usar um elemento meta em substituição, como exemplificado abaixo:

<meta http-equiv="Content-Type"
	content="application/xhtml+xml; charset=iso-8859-1" />

Como na escolha do formato, a escolha de um DOCTYPE também afeta os elementos e recursos que podem ser usados em um documento e deve ser feita com cuidado. Atualmente eu recomendo o uso de um DOCTYPE mais estrito a menos que o seu site possua uma apresentação muito complexa. A maioria dos sites, entretanto, consegue não só passar pela validação mas também ser exibidos tranqüilamente com um DOCTYPE assim.

Usando marcação significativa

Com o formato escolhido, você sabe quais são as regras a seguir no uso dos elementos. Com o DOCTYPE escolhido, você sabe quais elementos pode usar e como eles podem ser combinados. O próximo passo agora, na estruturação do documento, é usar uma marcação que seja significativa, ou seja, que descreva realmente o conteúdo do documento de maneira apropriada. Eu estou evitando propositadamente o termo marcação semântica pois o HTML ou o XHTML, mesmo sendo formatos estruturais, ainda não são capazes de descrever um documento semanticamente. Para isso seria necessário um formato XML puro, pertinente ao domínio que ele descreve. Ainda assim é possível conseguir estruturar um documento de modo que a informação contida seja descrita o mais corretamento possível.

A primeira parte desse processo é identificar as divisões do documento. Vamos usar com exemplo uma página que contenha um cabeçalho, o conteúdo em si, um menu de navegação e um rodapé. Você poderia então dividir o documento em quatro partes principais na sua ordem lógica, como ilustrado abaixo:

<body>

<div id="header">
</div>

<div id="body">

  <div id="content">
  </div>

  <div id="menu">
  </div>

</div>

<div id="footer">
</div>

</body>

A estruturação acima deixa bem clara a função de cada parte do documento e permite uma integração perfeita com uma folha de estilo. O elemento div está sendo usado para delimitar as partes que constituem o documento e o atributo id especifica qual é o objetivo daquela parte. A div que possui o id body está sendo usada para deixar ainda mais clara a divisão e facilitar a utilização de regras de estilo que serão aplicadas no documento posteriormente. Note que o atributo id foi usado porque, pela especificação, ele deve ser único. Assim, ele indica que esse elemento é o único em sua função e estabelece claramente, pelo seu valor, essa função. O atributo class deve ser usado em casos que vários elementos compartilham características comuns. Por exemplo, tanto a div header quanto a div footer poderiam eventualmente compartilhar um atributo class associado a uma regra CSS que diga que ambos devem ocupar 100% da largura da página, não ter margens e mostrar o texto centralizado. Outra coisa a notar no documento acima é que o menu vem depois do conteúdo. Isso serve para aumentar a acessibilidade do documento, permitindo que o conteúdo, que é mais importante, seja usado primeiramente em navegadores ou aplicações que não reconhecem CSS (como sintetizadores de fala, por exemplo). No caso de navegadores que reconhecem CSS, é possível usar regras que colocaram o menu em qualquer posição necessária, seja no topo da página ou em uma das laterais. Em artigos futuros serão demonstradas técnicas para converter a marcação acima em um layout posicionado qualquer.

A marcação acima ainda permite evitar praticamente qualquer necessidade de tabelas para o posicionamento das partes de um documento. Em alguns casos raros, por questões de falhas na implementação CSS, pode ser necessário o uso desses elementos. Geralmente, entretanto, as tabelas devem ser deixadas para a função que foram criadas: mostrar dados tabulados. Algumas pessoas defendem a eliminação total de tabelas de um layout. Eu concordo no caso de tabelas usadas para posicionamento. Entretanto, para tipos de dados apropriados -- como calendários e listas comparativas, por exemplo -- o uso de tabelas é plenamente justificado.

A próxima parte é identificar os níveis de conteúdo e usar a marcação apropriada para os mesmos. Isso inclui o uso dos elementos de cabeçalho, texto e listas. Por exemplo, se você olhar o código fonte deste documento, você verá que os elementos h1, h2 e h3 estão sendo usado para indicar as seções principais do documento. O elemento h1 está sendo usado para o título do documento, o elemento h2 para as seções principais e o elemento h3 para subseções específicas. Caso mais subseções fosse necessárias, os elementos h4, h5 e h6 seria eventualmente utilizados. A versão 2 da especificação XHTML define um mecanismo mais genérico para isso através dos elementos h e section e uma boa maneira de preparar o seu documento para esses novas elementos é usar seus equivalentes atuais. Um exemplo de marcação atual seria:

<h1>Documento</h1>

<p>Conteúdo do primeiro nível.</p>
<p>Conteúdo do primeiro nível.</p>

<h2>Primeira seção</h2>

<p>Conteúdo da primeira seção.</p>
<p>Conteúdo da primeira seção.</p>

<h2>Segunda seção</h2>

<p>Conteúdo da segunda seção.</p>
<p>Conteúdo da segunda seção.</p>

<h2>Conclusão</h2>

<p>Conteúdo da conclusão.</p>
<p>Conteúdo da conclusão.</p>

Novamente, com o uso de CSS é possível criar uma apresentação visual para o fragmento acima sem sacrificar a sua accessibilidade e legibilidade. É possível, por exemplo, substituir os cabeçalhos por imagens e esconder o texto em navegadores que suportam CSS sem impactar os navegadores e aplicações que não suportam esse padrões. Essas técnicas também serão demonstradas em artigos futuros.

Como exibido no exemplo acima, o elemento p deve ser usado para separar os parágrafos -- o que é exatamente sua função. De maneira alguma deve-se usar coleções de elementos br encadeados para forçar as quebras de linha. Qualquer tipo de margem ou espaçamento necessários podem ser conseguidos por CSS sem violar a estrutura do documento.

Continuando na identificação da maneira apropriada de representar o conteúdo, listas devem ser representadas com os elementos apropriados já existentes no padrão, novamente deixando a apresentação por conta de CSS. Muitas pessoas ainda acreditam que as listas continuam a ser limitadas como nos dias iniciais do HTML e que a única apresentação possível é a que se via naquela época. Por causa disso, essas pessoas acabam emulando a apresentação na própria estrutura do documento usando imagens e quebras de linha forçadas que resultam em um documento pouco ou nada acessível. É comum por exemplo, ver marcação assim:

<img src="seta.gif" />Item 1<br />
<img src="seta.gif" />Item 2<br />
<img src="seta.gif" />Item 3<br />

Além de não expressar adequadamente o fato de que os itens pertencem a uma lista, a marcação acima ainda prejudica a acessibilidade do texto em aplicações que dependem da informação estrutural como um guia de renderização ou vocalização. O modo apropriado de representar a lista acima seria:

<ul>
  <li>Item 1</li>
  <li>Item 2</li>
  <li>Item 3</li>
</ul>

No caso de uma lista ordenada, o elemento ol deveria ser usado. Mais uma vez, com o uso de CSS é possível não só colocar as margens pedidas pelo layout criado para a página como também inserir a imagem requerida sem prejudicar a estrutura da página. É possível também criar listas horizontais, como imagens de fundo e tamanho fixo, através de CSS, usando esses elementos. Essa técnica também será demonstrada em um artigo futuro.

Um outro elemento que não é muito usado nessa área e normalmente é emulado como tabelas é o elemento de listas de definicação, dl. Esse elemento permite a criação de listas pareadas de rótulo/explicação que podem ser renderizadas de qualquer maneira necessária e que ajudam imensamente a estruturação do documento. O exemplo abaixo mostra como esse elemento poderia ser usado nos termos de um glossário ou dicionário:

<dl>
  <dt>CSS</dt>
  <dd>Cascading Style Sheets</dd>
  <dt>HTML</dt>
  <dd>Hypertext Markup Language</dd>
</dl>

Esse tipo de lista é extremamente útil por que pode usar múltiplos rótulos para uma única definição e vice-versa.

Igualmente importante na estruturação do documento são os elementos que definem partes do texto. Esses elementos normalmente são ignorados mas constituem um auxílio fundamental na compreensão e apresentação de um documento. Alguns exemplos:

em, strong

Esses dois elementos são usados respectivamente para indicar ênfase e maior ênfase. Ao contrário dos elementos i e b, eles indicam a função do texto e não a sua apresentação. Novamente, como o uso de CSS é possível especificar qualquer tipo de apresentação necessária para essas funções sem comprometer o documento.

cite, abbr, acronym

Esses elementos são usados respectivamente para criar indicar citações, abreviaturas e acrônimos. São principalmente úteis para ajudar na acessibilidade de um documento.

q, blockquote

Esses elementos são usados para citações no meio do texto e citações que compreendem vários parágrafos, respectivamente. Esses são dois elementos normalmente desprezados mas que podem ser muito úteis nos contextos apropriados.

Obviamente existem outros elementos e uma consulta à especificação para explicações mais amplas e exemplos é recomendada. Ao consultar as especificações mantenha em mente o fato de que os exemplo acima são XHTML. Os tags equivalente em HTML usam maiúsculas.

O uso apropriado da marcação, além das vantagens mostradas no primeiro artigo e acima, ainda ajuda a reduzir o tamanho de um documento. Recentemente eu li sobre um exemplo em que a página HTML inicial foi reduzida de 47 KB para dois arquivos (um HTML e um CSS) de 10 KB e 4 KB respectivamente. Somente em marcação posicional a página original desperdiçava quase 40 KB. Imagine esse documento servido milhares de vezes em um mês e você pode facilmente visualizar o ganho na redução do custo de transmissão do mesmo. Além disso, como um único documento CSS geralmente pode ser usado para várias ou todas as páginas de um site, os ganhos podem ser ainda maiores.

Você deve ter notado a ausência de quaisquer referências ao elemento font nos exemplos acima. O fato é que o uso deste elemento é tornado totalmente desnecessário pela aplicação de CSS. Inclusive, o CSS permite um controle ainda mais granulado dos tipos em uma página, ajudando também na acessibilidade.

Um outro elemento que muitas vezes é substituído por imagens em detrimento da estrutura do documento é o elemento hr. No caso deste elemento, os problemas com as implementações CSS da maioria dos navegadores impede sua utilização mais adequada em muitos casos. Entretanto, existem várias opções tanto para aproveitá-lo na estrutura do documento sem exibi-lo diretamente, como outras para exibi-lo ou simulá-lo de maneira apropriada.

Para um visão mais detalhada dos conceitos apresentados acima, o código fonte deste documento serve com um exemplo. Você pode observar o uso de elementos div para marcar as divisões e verificar que a posição em que eles são exibidos é totalmente independente da ordem em que aparecem no documento. Tomando um caso específico, um dos elementos div, marcado pelo id breadcrumbs, aparece em último lugar no documento, mas é posicionado no topo da página, antes de qualquer outro conteúdo. Você pode verificar no documento também o uso dos elementos de cabeçalho para identificar as seções do conteúdo e o uso de listas tanto no conteúdo como no menu para agrupar os elementos de acordo com o necessário. Observe também o uso de CSS para esconder elementos da página que não são necessários em um navegador que renderize o documento visualmente mas que são úteis em outras aplicações onde o texto é tudo o que pode ser usado.

Conclusão

Como pode ser percebido nas explicações acima, existem dois focos principais na estruturação de um documento: simplicar a estrutura do mesmo de modo que ele se torne mais legível e de manutenção mais fácil e aumentar a acessibilidade do documento. O resultado é um site muito melhor e mais compatível com os navegadores em uso atualmente e muito mais fácil de ser usado pelos seus usuário. Esses são resultado que compensam plenamente qualquer dificuldade eventual no uso dos padrões.

No próximo artigo introduziremos o CSS, analisando a composição de uma folha de estilos e os diversos conceitos envolvidos na criação das regras que foram a mesma. Esse artigo servirá como base para outros mostrando idéias de uso mais específicas.

Quaisquer comentários, dúvidas, correções, sugestões ou adições poder ser encaminhados para o email mtblog@reflectivesurface.com, ou, no caso desse artigo específico, comentados na entrada correspondente em meu weblog.