Construindo Sites com Padrões Web

Escrito porJackson F. de A. Mafra

abril 23, 2008

Introdução

Objetivo

Este texto é o primeiro de uma série de artigos e tutoriais sobre a construção de sites usando os padrões Web. A intenção primária desses textos é mostrar que o uso de tais padrões na criação de documentos hipertexto resulta em várias vantagens tanto para os desenvolvedores e produtores dos mesmos como para seus usuários finais. Os artigos vão focar basicamente a construção de sites utilizando HTML (XHTML, mais especificamente) e CSS, mostrando que é possível criar páginas acessíveis, bem estruturadas e válidas sem um esforço excessivo. Nesse sentido, os artigos serão direcionados à estruturação do conteúdo e à aplicação da camada de apresentação aos mesmos sem passar pela parte de criação visual. Obviamente a parte visual é importante; entretanto, para todos os efeitos, ela não pesa muito nas decisões sobre os padrões já que praticamente qualquer tipo de layout criado pode ser igualmente construído através dos padrões Web. Dessa forma, as partes sobre CSS serão voltadas mais para o entendimento do padrão aplicado à apresentação do que para o desenvolvimento da apresentação em si. Apesar disso, os artigos também trarão indicações de como usar o CSS na criação de estruturas visuais chamativas e interessantes.
Os artigos procurarão apresentar o assunto de forma que eles sirvam não só para aqueles com conhecimento e afinidade maiores na área mas também para qualquer pessoa interessada e com disposição para aprender. O único pré-requisito real é entender o que é HTML e como o mesmo funciona e é usado para a criação de sites. Sendo assim, os artigos serão mais voltados para o lado prático, embora também venham a apresentar uma parcela de conteúdo teórico sempre que necessário. Espero que eles sejam úteis para o leitor.

Uma história dos padrões Web

Antes de entrar no assunto propriamente dito é interessante pensar um pouco nas questões envolvidas. Para isto, um mergulho na história dos padrões Web e, na verdade, da própria Web em si é um bom ponto de partida.
Os primeiros pensamentos sobre o que viria a ser a Web surgiram em 1945 quando Vanevar Bush escreveu um artigo descrevendo um aparelho foto-eletro-mecânico chamado Memex (abreviação de memory extension) que poderia criar e seguir links entre documentos armazenados em microfichas. O artigo estava bem à frente do seu tempo e foi somente dezessete anos depois, em 1962, que alguma coisa similar começou a tomar forma. Nesse ano, Doug Engelbart prototipou uma aplicação chamada oNLine System capaz de criar e editar documentos interligados. (Para o propósito de tornar a aplicação mais acessível, ele também inventou o mouse.) Em 1965, Ted Nelson, em um dos seus trabalhos seminais, A File Structure for the Complex, the Changing and the Indeterminate, cunhou a palavra hipertexto para expressar essa categoria de documentos interligados. Dois anos depois, o primeiro sistema baseado em algumas de suas idéias foi criado.
Em 1980, os primeiros esforços na criação de uma estrutura real de informação baseada em documentos hipertextos começam quando Tim Berners-Lee, trabalhando para o CERN, desenvolveu uma aplicação capaz de criar e manipular nós entre documentos arbitrários. Cada nó possuia um título, um tipo, e uma lista de links bidirecionais. Mesmo com essa aplicação a idéia de uma estrutura hipertexto demorou mais nove anos para tomar forma. Em 1989, Tim Berners-Lee circulou uma proposta para o gerenciamento facilitado de informação baseado em documentos hipertextos. A proposta foi recirculada em 1990 e, somente então, Berners-Lee recebeu permissão para criar o sistema. Em outubro desse ano, Berners-Lee começou a escrever a aplicação e a chamou de WorldWideWeb. A aplicação era uma interface visual para a criação e exibição de documentos hipertexto suportando o modo WYSIWYG. Como base na linguagem SGML, Berners-Lee criou o HTML como forma de expressar os documentos estruturados. Ele também resolveu o problema da identificação dos documentos criando o esquema de endereçamento universal conhecido com URL. Em novembro, durante os testes da aplicação, entrou em funcionamento o primeiro servidor Web da história. No final daquele ano, a aplicação estava pronta para demonstração. A Web finalmente nascia.
A partir daí a Web evoluiu rapidamente. No ano seguinte à sua criação, 1991, a aplicação WWW foi disponibilizada para grupos limitados e começou a ser utilizada para aplicações reais. Os primeiros servidores Web externos ao CERN foram criados. A grande revolução, entretanto, veio em 1993, quando o primeiro navegador Web, o NCSA Mosaic, foi liberado para o público geral. Desenvolvido por Marc Andreessen, esse navegador tornou-se o precursor dos navegadores modernos e uma das aplicações mais conhecidas e usadas da Internet. No fim de 1993, o mundo toma conhecimento da Web por meio de várias matérias publicadas em grandes e prestigiosos jornais. Em 1994, a Mosaic Communications Corp. é fundada e o Netscape, o primeiro navegador comercial da história é disponibilizado. A Web é uma realidade.
Com a expansão da Web, as necessidades das pessoas e organizações cresceram também. Por exemplo, os primeiros navegadores, antes do Mosaic, suportavam apenas documentos textos. Em 1993, com a criação do Mosaic e alguns outros navegadores similares, o HTML incorporou também imagens. (Conta-se que Tim Berners-Lee reclamou da adição de imagens dizendo que o recurso seria usado para pornografia. Infelizmente, ele estava absolutamente certo.) Outros elementos foram adicionados também à especificação inicial criada por Berners-Lee para atender às demandas crescentes de estruturação de documentos. O HTML, inicialmente, era apenas uma aplicação do formato SGML, uma metalinguagem cujo propósito é criar linguagens de marcação de documentos. O SGML é muito poderoso e permite a fácil extensão das linguagens criadas com base no mesmo. Isso, por sua vez, permitiu o crescimento rápido do HTML pela adição desses novos elementos e atributos.
O crescimento da Web também trouxe seus problemas. No começo, os elementos contidos na linguagem HTML apenas definiam a estrutura básica de um documento, tais como cabeçalhos, listas, parágrafos, ênfase e similares. Não havia nada na linguagem em si que explicava com tais elementos deviam ser exibidos. Obviamente, cada implementação decidia como fazer isso da sua maneira. Assim, cabeçalhos eram exibidos em fontes maiores e negritados, as ênfases apareciam em itálico, os parágrafos eram separados por linhas em branco e assim por diante. Até aqui, não havia nenhum problema, já que a informação em si era preservada. O conteúdo era distintamente separado da apresentação e poderia ser visto em qualquer navegador sem inconvenientes. Entretanto, o desenvolvimento comercial dos navegadores e a necessidade destes de manter uma vantagem competitiva sobre os concorrentes levou à inclusão de elementos proprietários e/ou de apresentação nas implementações específicas. Elementos como font e center surgiram e as pessoas começaram a usar tais elementos gráficos no lugar dos elementos de estruturação. Assim, ao invés de usar o elemento h1, por exemplo, para a identificação do cabeçalho primário de documentos, as pessoas estavam usando o elemento font para forçar a exibição da maneira visual requerida. O resultado foi que o documento era bem exibido somente nos navegadores que suportavam tais elementos. Como cada navegador implementava seus conjunto de elementos especiais, os truques de apresentação para enganar os renderizadores se tornaram coisa comum, aumentando o tamanho e a falta de estruturação dos documentos e reduzindo o HTML a uma confusão de elementos despadronizados. Nessa época começou a Grande Guerra dos Navegadores que durou vários anos. Qualquer pessoa que tenha lidado com HTML na época poderá atestar a dificuldade de conseguir que um documento qualquer aparecesse bem em todos os navegadores em uso então.
Em 1994, para lidar com essas questões, o Word Wide Web Consortium (W3C) foi criado. Essa organização tem como objetivo guiar a criação de padrões para a utilização em documentos Web. Obviamente, nesse momento a situação já era caótica e mesmo apesar do esforço desenvolvido pela organização nos últimos anos a situação hoje também ainda está longe de ser perfeita. Ainda assim, se o W3C não existisse, hoje seria impossível criar documentos que renderizam de maneira mais ou menos similar nos vários navegadores e sistemas atuais.
O esforço de padronização do HTML, logo depois liderado pelo W3C, começou também em 1994. Uma especificação inicial para a versão 2.0, incluindo muitos dos elementos proprietários e outros necessários, foi criada. Essa especificação foi a primeira a apresentar elementos para formulários e suporte a imagens mapeadas. A especificação foi desenvolvida, transformada em uma RFC e finalmente aprovada no final de 1995. Por esse tempo, a maioria dos navegadores existentes a suportava quase que inteiramente. Essa especificação define as capacidades básicas da maioria dos navegadores em existência hoje.
Enquanto a especificação 2.0 era aprovada, a discussão sobre a expansão do HTML continuava firme da comunidade de usuários do mesmo. No final de 1993, houve uma proposta para o HTML+ que seria um superconjunto do HTML para permitir sua integração gradual nos navegadores de então. A proposta nunca tornou-se uma realidade e transformou-se, em 1995, na proposta para o HTML 3.0. A especificação 3.0 introduzia elementos como tabelas, fluxo do texto ao redor de imagens e a exibição de equações matemáticas. Embora fosse compatível com o HTML 2.0, ela era tão complexa e abrangente que a sua adoção provou-se uma esforço impossível na época e ela eventualmente expirou.
Enquanto a especificação 3.0 estava sendo discutida, os navegadores continuavam a introduzir novos elementos baseados na mesma embora não a implementassem completamente. Para lidar com essa situação, o W3C considerou tornar essas inclusões uma nova especificação para impedir a degradação do padrão. Em 1996, a especificação 3.2 foi anunciada, sendo constituída de várias extensões propostas para a especificação 2.0, algumas características da versão 3.0 já implementadas na época, e um série de atributos proprietários existentes em vários dos navegadores existentes no momento. Essa especificação tornou-se a substituição de facto do HTML 2.0, tanto para os criadores dos navegadores quanto para os criadores de documentos.
À medida que a especificação 3.2 era adotada, o trabalho começou na especificação 4.0. Já no meio de 1996, um rascunho experimental da nova versão apareceu sem muito anúncio no site do W3C. Muitas das capacidades em discussão nas outras especificações, como folhas de estilo, linguagens de scripting, internacionalização e outras extensões foram incluídas na mesma. Sendo mais madura, a especificação demorou mais tempo para ser desenvolvida e só se tornou uma padrão reconhecido no meio de 1999. Infelizmente, ao contrário das especificações anteriores, ela não foi implementada satisfatoriamente nos navegadores e até o presente momento muitas de suas características ainda não são totalmente suportadas nos mecanismos de renderização desses navegadores.
O avanço do HTML e a incorporação de muitos elementos de apresentação aumentaram a complexidade e a dificuldade na criação de documentos estruturados, negando o próprio objetivo do padrão. Para resolver essas questões, duas especificações surgiram em épocas distintas atacando problemas diferentes das implementações já existentes. Essas novas especificações foram o CSS e o XHTML.
Em 1995, os primeiros rascunhos de uma nova especificação de apresentação, o CSS, foram anunciados. O objetivo primário da especificação era separar novamente a estrutura do documento da forma de renderização, como inicialmente intencionado pela linguagem HTML. Os documentos HTML seriam novamente reduzidos a carregar o conteúdo do documento e somente fariam referência a um outro documento, que usaria CSS, para especificar a forma como o documento HTML seria exibido. Em meados de 1996 a primeira especificação CSS tornou-se uma recomendação do W3C. A versão 2 da mesma tornou-se uma recomendação no meio de 1998. A exemplo da especificação HTML 4.0, as especificações CSS foram implementadas de maneira incompleta nos navegadores e até o dia de hoje o suporte às mesmas é relativamente arbitrário.
Em 1998, foi decidido pelas organizações por trás do HTML que a especificação precisava ser repensada. A decisão foi recriá-la como uma aplicação do XML, outra metalinguagem criada a partir do SGML, mas com regras mais estritas. Apesar dessas regras rigorosas, o XML permite que a extensão dos documentos seja feita de maneira mais fácil através de espaços de nomes que eliminam conflitos entre formatos diferentes. A nova especificação foi chamada XHTML e tornou-se uma recomendação W3C em 1999. A partir de então várias especificações adicionais foram criadas focando em aspectos e módulos específicos do padrão. A especificação XHTML 1.0 é basicamente uma estruturação da especificação HTML 4.0 em XML. A criação de uma nova especificação, XHTML 2.0, está em andamento focalizando os problemas existentes na especificacão 1.0 atual. Essa nova especificação é ainda o alvo de muitas discussões veementes entre os vários grupos relacionados na Web. Infelizmente, como no caso do HTML 4.0 e CSS 2.0, o suporte do XHTML nos navegadores é ainda muito incompleto.
Como se pode ver acima, a implementação de padrões Web está longe de ser uma unanimidade entre os criadores de ferramentas para a mesma. Apesar disso, nos últimos dois anos o suporte a esses padrões vem se tornando uma preocupação cada vez maior dos vários grupos envolvidos, embora as implementações estejam longe de oferecerem uma base perfeitamente comum. Na verdade, é possível que isso nunca aconteça totalmente, embora o suporte possa chegar a um nível praticamente idêntico entre as ferramentas. Apesar dessa situação, a adoção dos padrões possui muitas vantagens. Essas vantagens serão analisadas adiantes, juntamente com as desvantagens que ainda existem. Um dos propósitos aqui é mostrar também que as vantagens superam de longe as eventuais desvantagens na adoção dos padrões.

A necessidade dos padrões Web

Embora a situação de implementação dos padrões seja bastante complicada atualmente, a necessidade da adoção dos mesmos é patente. O crescimento exponencial da Web tem criado muitos desafios que somente esses padrões são capazes de responder. Algumas pessoas acreditam que os padrões Web são limitadores. A verdade é que eles removem grande parte da dificuldade do desenvolvimento dando maior flexibidade ao desenvolvedor e produtor Web, permitindo que as pessoas possam realmente exercer a sua criatividade ao mesmo tempo em que forjam elos de comunicação.
Um dos sonhos dos criadores da Web é a Web Semântica, proposta por Tim Berners-Lee, que consiste em documentos organizados de tal forma que facilitem a coleta, pesquisa e cruzamento de informações de maneira automática e baseada no significado real do conteúdo desses documentos ao contrário da simples pesquisa por palavras-chave que é realizada pelas atuais ferramentas de busca. Embora muitas pessoas tenham dúvida quando à criação da Web Semântica, ninguém tem dúvidas de que a mesma dependerá muito da aplicação de padrões compreensíveis tanto para pessoas como para máquinas.
Muitos dos usos da Web hoje só são possíveis por causa da utilização de padrões quer permitem o compartilhamento fácil de informações. Além disso, o futuro obviamente trará muitas outras possibilidades que só serão realizáveis se houver um certo grau de conformidade.

Vantagens dos padrões Web

Existem diversas vantagens na aplicação dos padrões Web. Algumas dessas vantagens estão explicadas e exemplificadas abaixo. Elas não são, de maneira alguma, totalmente inclusivas. Outras vantagens se tornarão evidentes em outros artigos à medida que os aspectos práticos dos padrões forem explorados.
Uniformidade
A primeira vantagem da utilização de padrões é a uniformidade. Isso quer dizer que documentos criados segundo os padrões Web podem utilizar uma estrutura comum, facilitando a manipulações dos mesmos. Uma estrutura comum permite que modificações tais como inserções e remoções de conteúdo ou movimentações estruturais podem ser realizadas de maneira simples, sem a necessidade de aplicações complexas. A uniformidade permite que documentos possam ser manipulados através de um conjunto reduzido de aplicações, transformações e mecanismos de apresentação.
Para um exemplo específico, um site contendo vários documentos pode fazer uso de uma única folha de estilo para formatar os mesmos para exibição. Isso só é possível se os documentos forem o mais uniformes o possível. Um outro exemplo é quando os documentos precisam ser transformados para uso em outro ambiente. A uniformidade permite que isso seja feito em um número reduzido de passos comuns.
Simplicidade
Uma outra vantagem da utilização dos padrões é a simplicação dos documentos. Essa vantagem é muito similar à uniformidade, mas compreende realmente a eliminação de elementos desnecessários. Nesse sentido é um retorno à utilização do HTML para a simples estruturação dos documentos, ignorando inicialmente a apresentação dos mesmos, que pode ser aplicada depois de diversas formas. Documentos criados com os padrões tendem a apresentar uma economia de marcação que permite maior flexibidade na utilização dos mesmos, seja diretamente em navegadores ou na transformação para outros usos. A simplicidade dos documentos também resulta em melhores tempos de acesso, uma necessidade ainda muito premente da Web atual.
Um exemplo próprio das vantagens da simplicidade é quanto aos mecanismos de busca. Documentos simples podem ser indexados mais facilmente e normalmente recebem maior relevância nas buscas.
Liberdade
Os padrões Web permitem também a liberdade de estruturação e inovação por não serem controlados por uma empresa específica. Isso permite que sejam utilizados por qualquer pessoa em qualquer lugar, sem a necessidade de pagar ou fazer algo pelo privilégio. Essa liberdade permite também uma maior facilidade na movimentação de informações e evita que as mesmas se tornem obsoletas. Um documento criado através dos padrões Web, por causa da própria estrutura destes, estará sempre aberto à movimentação na direção de outros padrões e sistemas futuros. Formatos proprietário (especialmente os binários) tornam as pessoas e empresas dependentes das ferramentas que os manipulam e as prendem a essas ferramentas e formatos. Os padrões Web, criados especialmente para o compartilhamento de informações, desencorajam tais práticas e evitam os problemas resultantes das mesmas.
Separação de estrutura e apresentação
Essa é talvez a maior vantagem na utilização dos padrões. A utilização correta dos mesmos permite separar quase que completamente a estrutura da apresentação. Isso significa que o documento fica restrito ao seu conteúdo, sem especificar qualquer forma de apresentação, permitindo que esta seja modificada de acordo com as necessidades. Assim, o documento permanece o mesmo, embora possa ser usado em diferentes ambientes como navegadores, sintetizadores de fala, e geradores de documentos Braille. A correta separação da estrutura da apresentação permite uma maior flexibilidade na utilização do documento.
Por exemplo, um determinado documento pode ser exibido de uma certa forma em um navegador e modificado significativamente para a impressão através da remoção de navegação (denecessária em documentos impressos), expansão de abreviações e links (que não são apropriadamente mapeados nesse tipo de mídia) e execução de outras transformações que permitem que o documento seja mais facilmente utilizado em uma situação diferente. Essa vantagem será melhor ilustrada de maneira prática em artigos posteriores.
Facilidade de criação
O uso de padrões também torna mais fácil a criação dos documentos já que não é necessário preocupar-se inicialmente com a apresentação dos mesmos, livrando o criador do documento para pensar apenas no conteúdo do mesmo. Como dito anteriormente, quase qualquer tipo de layout pode ser criado a partir de CSS e isso permite que essa etapa da construção de sites seja realizada independentemente do desenvolvimento de conteúdo. Obviamente, há cuidados necessários para permitir essa flexibilidade e esses cuidados serão vistos em artigos posteriores. O criador fica, também, livre do peso do uso de editores específicos. O conteúdo pode ser editado em qualquer processador de textos e posteriormente estruturado. Uma vez estruturado ele poderá ser exibido através da formatação apropriada anexada ao mesmo.
Acessibilidade
Outra das grandes vantagens da utilização dos padrões é a acessibilidade. Em termos de padrões Web isso significa não só permitir que pessoas com deficiências físicas tenham acesso à Web, mas também capacitar a utilização das páginas por e em outros tipos de ambientes que não um navegador. Isso inclui navegadores de voz, que lêem páginas Web em voz alta para pessoas com dificuldades ou impossibilidade de visão; navegadores Braille que traduzem as páginas nesse alfabeto; aparelhos com pequeno espaço de exibição e outros aparelhos de saída que não tão usuais. Isso evita a duplicação de conteúdo e facilita a utilização geral dos documentos. A acessibilidade auxilia também pessoas que não possuem deficiências físicas melhorando a manipulação das páginas por teclas de atalho e outros métodos.
Um interessante efeito colateral da acessibilidade, que demonstra a sua vantagem, é visto na simplicação das páginas de modo que um dos maiores usuários de sites Web, que é cego, possa ter um acesso melhor às mesmas. Esse usuário é o Google, o mecanismo de busca mais utilizado atualmente. Páginas acessíveis permitem que o Google indexe melhor as mesmas permitindo que o site ganhe eventualmente um melhor posicionamento em buscas.
Extensibilidade
Uma outra vantagem dos padrões Web, ainda que indireto, é a extensibilidade. Ela permite que documentos criados com os padrões agreguem informações adicionais que podem ser separadas quando não são necessárias. Um dos motivos da criação do XHTML foi justamente esse. Embora os navegadores atuais ainda tenha problema com a especificação, a utilização da mesma atualmente é uma boa maneira de preparar documentos para usos imprevistos no futuro.
Estabilidade
Também uma vantagem da aplicação dos padrões, a estabilidade significa que os documentos feitos sob os mesmos permanecerão compatíveis tanto para frente como para trás. Isso quer dizer que tais documentos serão capazer de "degradar graciosamente" em ambientes com suporte limitado aos padrões produzindo um resultado visual aceitável e completo acesso ao conteúdo. Um exemplo disso são sites que possuem uma rica exibição em navegadores visuais mais modernos, mas podem ser completamente acessados em navegadores de modo texto, como o Lynx, ou navegadores com suporte fraco aos padrões, como o Netscape 4. Sendo também direcionada ao futuro, a estabilidade permite que documentos existentes atualmente permanecerão passíveis de utilização muitos anos no futuro, em ambientes ainda a serem criados.
Outro ganho da estabilidade é na manutenção de documentos. Muitas vezes um determinado site pode passar por várias equipes durante sua vida útil. A estabilidade dos documentos através dos padrões Web permite que um site possa ser compreendido e editado por qualquer grupo necessário sem necessidade de esforços excessivos.

Desvantagens dos padrões Web

Embora as vantagens da adoção dos padrões Web sejam grandes, existem também algumas desvantagens aparentes que podem desencorajar o desenvolvedor Web a torná-los parte de seu arsenal de ferramentas. Algumas dessas desvantagens são apresentadas abaixo juntamente com razões para não levá-las em conta como impedimentos.
Implementações discordantes
A maior dificuldade na utilização dos padrões Web atualmente está na existência de implementações discordantes dos mesmos. Isso aumenta substancialmente a complexidade da criação de documentos que podem ser utilizados indistintamente em qualquer ambiente Web.
O maior problema nesta área está na especificação CSS. O nível de suporte à mesma é absurdamente diferenciado. A maioria dos navegadores suporta a especificação 1.0, embora muitos de maneira parcial. A especificação 2.0 ainda não é suportada completamente em nenhum navegador embora muitas de suas características existam na maioria deles. E a especificação 3.0 — até compreensivelmente, já que não é uma recomendação W3C — só é suportada, e ainda assim parcialmente, em um dos grandes navegadores em uso no mercado. Para piorar a situação, as empresas e grupos desenvolvendo navegadores e ambientes hipertexto hoje dificilmente concordam em como implementar uma determinada característica nos seus produtos. Um determinado atributo CSS normalmente é renderizado de maneira muito diferente em cada um dos navegadores visuais em existência hoje. Um outro grande problema está na diferença entre os modelos de unidade de medição dos elementos entre os navegadores Web que gera um série de complicações na exibição das páginas. Adicionalmente, erros de implementação também atrapalham a vida de desenvolvedores.
O suporte XHTML também é muito incompleto nos navegadores e seu uso ainda é muito restrito por parte dos desenvolvedores. Muitos navegadores, por causa de sua herança, tendem a ler documentos Web como se os mesmos fossem uma sopa de elementos, sem se preocupar com a validade ou ordenação dos mesmos. Esse comportamento tem suas raízes na explosão do uso de ferramentas automatizadas no início da Web para a criação de documentos que permitiam a qualquer pessoa gerar sites sem se preocupar com os padrões envolvidos. Isso forçou os navegadores a lerem qualquer tipo de documento, independentemente de sua validade, para evitar a perda de mercado.
Apesar dessa situação, existem algumas ténicas que limitam os problemas de implementação e permitem uma boa utilização dos padrões. Isso permite ganhar todas as vantagens dos mesmos, embora à custa de algumas dificuldades iniciais. Além disso, o suporte aos padrões tem melhorado cada vez mais e a necessidade de utilizar tais técnicas vem sendo reduzida.
Aumento da complexidade inicial
Uma outra desvantagem da aplicação é o aumento da complexidade inicial na criação dos documentos. Isso pode parecer contraditório em relação à vantagem da simplicidade citada anteriormente, mas na realidade não é. Esse desvantagem só existe inicialmente, quando os criadores de documentos estão fazendo uma transição para o uso de padrões. Assim, mesmo que essa desvantagem desapareça com o tempo ela implica em necessidades de treinamento e esforço inicial. Entretanto, esse custo deve ser pago, direta ou indiretamente, se as vantagens futuras dos uso de padrões são esperadas. Obviamente, a longo prazo as vantagens compensam essa complexidade inicial. Isso é o que deve ser mantido em mente quanto aos padrões.

Ferramentas

Como notado no artigo anterior, existe um certo custo inicial na utilização dos padrões Web. Este custo procede primariamente da curva de aprendizado desses padrões que pode ser um tanto íngreme no começo, especialmente no que tange à mudança de hábitos de desenvolvimento necessária para lidar com os mesmos. Adicionalmente, existe a questão das diferenças entre as implementações dos padrões nos vários navegadores em uso atualmente que também podem complicar um pouco a vida do desenvolvedor. Essas dificuldades, entretanto, são mais do que compensadas pelos benefícios da utilização dos padrões mencionadas também no artigo anterior.
O efeito prático das diferenças de implementação é a necessidade, por parte do desenvolvedor Web, de testar escrupulosamente os sites que construir no maior número possível de navegadores de modo a eliminar eventuais problemas na utilização e visualização desses sites em condições mais problemáticas, como é o caso de alguns navegadores com um suporte extremamente limitado aos padrões.
Este artigo, então, apresenta algumas ferramentas necessárias para ajudar o desenvolvedor a fazer esses testes e também mostra outras ferramentas adicionais que podem ser muito úteis para qualquer desenvolvedor Web, seja este um profissional da área ou não. Essas ferramentas auxiliarão o desenvolvedor tanto no começo da utilização dos padrões, possibilitando um entendimento mais fácil e mais rápido dos mesmos, como também no futuro, simplicando várias etapas da construção dos sites mesmo para desenvolvedores já experimentados.

Navegadores

A primeira necessidade para um desenvolvedor que queira utilizar bem os padrões é contar com vários navegadores para o teste de documentos Web criados. Mesmo para um site simples pessoal é impossível assegurar a correta visualização dos documentos nas diversas plataformas sem testes mínimos nos navegadores mais comuns da atualidade. Um receita certa para complicar a vida de qualquer desenvolvedor é testar um site somente no navegador dominante de hoje, o Internet Explorer, já que, mesmo entre versões desse navegador existem algumas diferenças e problemas no suporte aos padrões que podem causar determinadas falhas em um site. Pode parecer um trabalho adicional, mas é uma necessidade que já existe independentemente da aplicação dos padrões. Os padrões, na verdade, simplificam os testes já que produzem um código mais simples e resumido, com menor possibilidades de erro. Além disso, acostumando-se ao uso dos mesmos o desenvolvedor tenderá a acertar mais facilmente na implementação, reduzindo assim o tempo de criação dos sites.
Atualmente, na minha opinião, um site precisa ser testado pelo menos nas seguintes plataformas:
Mozilla 1.x
Esta plataforma abrange os navegadores Mozilla 1.x no Windows, Linux e Macintosh; o Mozilla Firebird nesses mesmos sistemas; o Netscape 6 e 7, também nesses sistemas; o Galeon sob o Linux e alguns outros navegadores em diversas plataformas que fazem uso do Gecko, o renderizador HTML do Mozilla, para exibição de HTML. Note que eu estou ignorando o Netscape 4. Esse navegador já tem seis anos de idade e já está mais que na hora de aposentá-lo. Além disso, é possível criar sites que degradem graciosamente (esse conceito será explicado melhor mais à frente) de modo a serem usáveis no mesmo.
Internet 5.x e 6.0
Essas são as duas versões mais comuns do Internet Explorer. A versão 4.0, que também existe há seis anos, está caindo no desuso, com exceção de algumas organizações padronizadas sob a plataforma.
Opera 6 e 7
Embora possua uma fatia de mercado muito pequena, o Opera possui um suporte muito bom aos padrões e serve como um teste para a correta implementação dos mesmos. Além disso é um dos mais compactos navegadores existentes.
KHTML
Na verdade, o KHTML é o mecanismo de rederização por trás do Konqueror no Linux e do Safari no Macintosh. Embora seja mais difícil testar sob o mesmo, principalmente no caso de desenvolvedores que não têm acesso direto aos sistemas operacionais onde o mesmo é usado, as diferenças na implementação CSS do KHTML são suficientes para exigir uma verificação.
Lynx
O Lynx é um navegador de modo texto usado basicamente no Linux. Ele serve com um teste para a utilização do site sob condições extremas como em terminais, leitores Braille e sintetizadores de fala. Existe um versão do Lynx para Windows que pode ser baixada pelos usuários desse sistema operacional.
Como exceção do KHTML, todos os outros navegadores podem ser facilmente baixados para o Windows.No caso do Mozilla, não há a necessidade de baixar a aplicação completa; basta baixar o Mozilla Firebird que é uma versão mais leve do componente navegador do projeto. Através da mesma o desenvolvedor pode testar a visualização de um documento verificando como ele será exibido tanto no Windows como no Linux e Macintosh. Existem apenas algumas pequenas diferenças que serão tratadas mais tarde. O suporte aos padrões no Mozilla é o melhor do mercado, atualmente, e serve como uma referência para os demais navegadores.
O versão 6 do Internet Explorer é a última que será desenvolvida como um componente separado do Windows. As próximas versões serão integradas ao mesmo e só poderão ser adquiridas através do upgrade do sistema operacional. Isso significa que pelos próximos cinco a seis anos será necessário testar sites nesse navegador até que a adoção de uma nova versão do Windows esteja suficientemente completa.
Para desenvolvedores profissionais, eu recomendo a utilização do VMWare. Esse produto permite que o seu usuário crie "máquinas virtuais" de sistemas operacionais baseados nos processadores Intel e as execute no seu sistema sem que as mesmas interfiram em qualquer processo do mesmo. Assim o usuário pode criar combinações como Internet Explorer 5.5 no Windows 98, Mozilla no Linux e dezenas de outros para testes rápidos. Isso elimina os custos de manter várias máquinas reais com as combinações necessárias e também a necessidade de formatar e instalar uma nova máquina sempre que uma combinação extra se faz precisa.

Ferramentas adicionais

Além de ser um excelente navegador, o Mozilla possui uma estrutura muito flexível que permite a criação de extensões para o mesmo. Algumas dessas extensões são ferramentas que podem auxiliar o desenvolvedor na criação de sites conformantes com os padrões Web. Infelizmente, essas extensões são somente para este navegador, ou para o Mozilla Firebird, e nenhuma delas existe gratuitamente para o Internet Explorer. É possível encontrar alguns equivalentes comerciais das mesmas para o mesmo, mas essas não são tratadas aqui.
Algumas dessas extensões úteis são:
Checky
Esta extensão cria um ítem de menu adicional no Mozilla que permite a submissão de um documento para diversos serviços de validação dos padrões Web. A validação é o processo de verificação de um documento contra um padrão de modo a determinar se o documento conforma-se à especificação do mesmo. Em relação ao tema que estes artigos estão tratando, as validações mais importantes são as de HTML (ou XHTML), CSS e acessibilidade. O Checky provê acesso a vários validadores desses padrões específicos e a dezenas de outros de interesse para desenvolvedores Web.
PNH Toolbar
Esta extensão cria uma barra de ferramentas adicional no Mozilla com várias funções úteis para o desenvolvedor. Estas funções incluem links diretos para os textos das especificações de alguns padrões e outros documentos de interesse para o desenvolvedor, acesso a alguns serviços de validação e comandos para testes no layout de um documento Web. Um desses comandos, de especial nota para o desenvolvimento CSS, permite a visualização dos blocos que compõem um documento facilitando o teste e a correção de erros na implementação visual do mesmo.
LiveHTTPHeaders
Embora não esteja diretamente relacionado aos padrões que estamos tratando aqui essa ferramenta permite verificar os headers trocados entre o Mozilla e servidores de modo a facilitar a detecção de erros — especialmente em páginas dinâmicas que criam seus próprios headers.
Além dessas extensões o Mozilla ainda conta com um poderoso depurador JavaScript que ajuda enormemente a tarefa de testar a programação cliente de páginas. O Mozilla possui também um visualizador DOM quer permite verificar facilmente a estrutura de uma página e identificar os elementos que a compõem. Essas função é similar à da PNH Toolbar.

Bookmarklets

Embora as extensões acima só existam sob o Mozilla existe uma outra classe de ferramentas que são de interesse para o programador Web: os bookmarklets. Essas ferramentas são uma classe especial de bookmarks que, ao invés de apontarem para documentos Web, implementam funções JavaScript com propósitos específicos. Um exemplo são os bookmarklets para a criação de entradas no MovableType, uma ferramenta para blogs. Esses bookmarklets permitem que o usuário do MovableType selecione texto em um documento Web de seu interesse e, ao clicar o bookmarklet, invoque uma rotina que automaticamente cria uma entrada no seu blog e insere o texto previamente selecionado, com seu endereço, permitindo então a edição da entrada. Isso poupa vários passos para o usuário, facilitando o uso dessa aplicação específica.
No caso do desenvolvimento Web os bookmarklets podem implementar funções de apoio à implementação e teste de um documento. Para um exemplo de um bookmarklet, clique o link abaixo:
Editar estilos deste documento.
O bookmarklet acima invoca um micro-editor CSS que permite que os estilos do documento atual sejam alterados. Isso ajuda a testar modificações no mesmo antes que haja qualquer esforço de codificação. Como é possível ver pela execução desse bookmarklet, eles são ferramentas muito poderosas e úteis para o desenvolvedor. Com o bookmarklet acima é possível, por exemplo, refazer um site visualmente e só depois implementar as mudanças. Obviamente, para que isso funcione o site já deve estar implementado sob os padrões Web no que concerne à sua estrutura.
Como o próprio nome diz, os bookmarklets podem ser guardados nas listas de bookmarks de um navegador. Para isso, arraste os links de bookmarklets que encontrar para os menus ou barras de bookmarks do seu navegador específico, ou use a opção equivalente no menu contextual invocado com o botão direito do mouse.
Para mais bookmarklets, consulte os sites abaixo:

Web Development Bookmarklets

Favelets

Trauwind

Mantenha em mente que alguns bookmarklets funcionam em versões específicas de alguns navegadores. Uma boa parte dos mesmos, porém, funciona sem modificação tanto no Mozilla com no Internet Explorer.

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:

O nome do elemento no tag de abertura seja idêntico ao nome do elemento no tag de fechamento. Cabe aqui uma explicação da distinção entre elemento e tag. Elemento é a entidade especificada como tendo algum valor semântico no documento. Por exemplo, na especificação HTML, parágrafos são representados pelo elemento P ou p. Na especificação XHTML, os mesmos parágrafos são representados pelo elemento p, já que o XML é sensível ao caso. O tag já é a representação textual do elemento em um documento por meio dos sinais >, <, e / englobando o nome do mesmo. Assim, o elemento p é marcado pelo tag de abertura <p> e pelo tag de fechamento </p>;

Um atributo não pode ser repetido em um tag;

O sinal < não pode aparecer no valor de um atributo;

Um documento só pode usar os caracteres legais para o conjunto de caracteres em que se encontra;

Com exceção das entidades amp, lt, gt, apos e quot, qualquer outra entidade deve ser declarada antes de ser usada.

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, é.

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>

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:

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:

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>

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

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

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

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

<h2>Conclusão</h2>

<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:

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>

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

<dd>Cascading Style Sheets</dd>

<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.

Fonte: http://kb.reflectivesurface.com/br/artigos/sitesComPadroesWeb/estruturandoUmDocumento

Geral