XHTML: pensando no futuro?
Há algum tempo acompanho a discussão sobre se devemos usar XHTML ou HTML para desenvolver nossos sites hoje. Já discuti com muitas pessoas sobre isso e a conclusão é sempre a mesma, nenhuma.
O principal argumento que se usa para defender o uso do XHTML é que dessa maneira estarÃamos dando um passo a frente, pensando no futuro. Essa afirmação não está errada, XHTML é sim um passo a frente, é uma maneira de se pensar no futuro. Mas, para que isso seja realmente verdadeiro é preciso prestar atenção a alguns detalhes.
Antes que alguém tire conclusões precipitadas, devo dizer que sou a favor do XHTML. Escrevo este post apenas para tentar ajudar a esclarecer alguns pontos que tenho percebido não estar muito claros na cabeça da maioria das pessoas que estão pegando o bonde dos padrões web agora.
XHTML enviado como text/html causa problemas
Ian Hickson já discorreu sobre os problemas de se enviar XHTML como text/html antes mesmo de eu ouvir falar em XHTML pela primeira vez. Este texto é uma leitura quase obrigatória para qualquer um que deseje entender um pouco sobre a maneira como seus documentos são interpretados pelos browsers e pretende realmente desenvolver sites que sejam “future-proof”, ou seja, que causem o mÃnimo de problemas — ou nenhum, preferivelmente — no dia em que a migração completa para XHTML for possÃvel.
Mas, Bruno, como assim? Ainda não é possÃvel migrar totalmente para XHTML? Eu escrevo documentos XHTML e eles funcionam muito bem em qualquer browser. Explica isso direito.
Bom, se você der uma boa lida no texto do Ian Hickson (pode ir lá ler, eu espero…), vai conseguir ter uma boa noção sobre o assunto. Mas se você é preguiçoso ou não sabe inglês, vou tentar explicar brevemente (e não tão bem quanto o Ian) essa coisa toda de XHTML e HTML.
Compatibilidade entre XHTML e HTML e o porquê dos DOCTYPEs
A primeira coisa que você deve saber é que o Internet Explorer 6 (e versões anteriores) não suporta XHTML. Ponto. Na verdade ele nem chega a suportar o HTML completamente. Seu XHTML funciona bem mesmo sendo enviado como se fosse HTML porque você aprendeu a escrever XHTML cumprindo as regras descritas no Apêndice C da especificação do XHTML 1.0, mesmo que inconscientemente.
O apêndice C define as regras de compatibilidade entre XHTML 1.0 e HTML 4.01. São as regras que você deve seguir para poder enviar seus documentos XHTML como text/html e assegurar que os UAs atuais consigam renderizá-lo a contento.
Outra coisa que você precisa colocar na cabeça e não tirar nunca mais é que o DOCTYPE não define, para o user agent, o tipo de documento que está sendo enviado. Quem define isso é o header Content-Type contido na resposta HTTP enviada pelo seu servidor ao UA.
Isso fica bem claro na seção “Why UAs can’t handle XHTML sent as text/html as XML” do texto do Ian Hickson. Se um documento é enviado como text/html, não há maneira confiável de detectar se seu conteúdo é XML ou apenas mera “old-school tag soup”. Nem pelo doctype, nem pelo namespace declarado no elemento html, nem pela declaração XML (que, aliás, deve ser evitada por colocar o IE em quirks mode, explicado mais a frente), nem por qualquer outra maneira que se possa imaginar.
Então para que serve o doctype? Por quê eu preciso declarar o danado do doctype no inÃcio de cada documento que escrevo para a web? Para duas coisas: poder informar a linguagem e versão usadas no documento a uma ferramenta automatizada de verificação de validade (seja o W3C validator ou qualquer outro) e para dizer ao browser qual modo de renderização deve ser usado ao ler seu documento.
Modos de renderização
Devo abrir um parêntese aqui para explicar aos desavisados o que é este modo de renderização. Os browsers modernos (IE 6 incluÃdo) usam um recurso chamado DOCTYPE Switching para decidir como renderizar um dado documento. Se você usa um doctype válido e completo, declarando estar usando qualquer coisa acima de HTML 4.0, os browsers vão renderizar seu documento em um modo chamado strict mode ou standards compliance mode. Neste modo de renderização o browser vai fazer o maior esforço possÃvel para renderizar o documento seguindo as especificações (HTML ou XHTML e CSS 1 e 2). Na ausência de um DOCTYPE, ou na presença de um que seja incompleto, inválido ou que declare uma linguagem mais antiga (como HTML 3.2) o modo usado é o que chamam de quirks mode, onde o browser “emula” a renderização de versões anteriores, que lidavam com as “loucuras” (quirks) dos códigos tag soup tão comuns na web de ontem (e, infelizmente, ainda bem comuns na web de hoje).
Um detalhe sobre o modo de renderização é que, no IE, se houver qualquer coisa antes do doctype — seja uma declaração XML, um comentário, ou mesmo uma linha vazia — ele “chaveia” para quirks mode. Isso é um bug. Alguns desenvolvedores preferem se valer disso para, propositalmente, jogar o IE6 em quirks mode para que ele renderize as páginas da mesma forma que o IE5. Eu prefiro não usar este artifÃcio.
No Opera (versões 7.0 a 7.03), quando uma declaração XML estiver presente e o documento for enviado como text/html, o quirks mode é ativado. Talvez seja um bug também, mas não tenho certeza. A partir da versão 7.1 isso não acontece mais.
Usar ou não usar XHTML. Eis a questão
Bem, voltemos ao ponto central deste texto. XHTML, da forma que é usado hoje, é ou não um passo em direção ao futuro? Os documentos XHTML de hoje garantem compatibilidade futura, com os user agents de amanhã e, mais importante, ganhamos alguma coisa desenvolvendo sites em XHTML hoje, mesmo com o browser lÃder do mercado não tendo suporte?
Vamos voltar ao texto do Ian Hickson. No texto, ele cita as vantagens do XHTML em relação ao HTML. Basicamente as vantagens se resumem a: poder incluir conteúdo marcado em outros namespaces, como MathML, garantir que os documentos sejam bem-formados e poder processá-los com parsers XML, mais simples que os parsers SGML e os que precisam lidar com tag soup.
Se você não envia seus documentos XHTML com o media type correto (application/xhtml+xml), já fica impossÃvel incluir conteúdo de outros namespaces nos seus documentos. Mas você pode ponderar: quem precisa de MathML hoje em dia? Ok. Mas você costuma validar seus documentos XHTML ou pelo menos verificar se são bem formados? Se não, você já invalida as outras duas vantagens do XHTML. Ou seja, não está garantindo a boa formação do documento e não permite que ele possa ser analisado por parsers XML.
Quando você envia seus documentos XHTML com o media type correto, os user agents que suportam esse media type vão capturar imediatamente qualquer falha de boa formação e mostrar um erro de XML. Mais uma vez você me interrompe e diz: eu não quero que meus sites parem de funcionar por causa de um errinho bobo. E eu te pergunto: então por que você usa XHTML?
Ao responder a esta pergunta, a maioria das pessoas diz que usa XHTML porque é a linguagem do futuro da web, porque assim estão dentro dos padrões e porque o XHTML as “força” a escrever documentos semanticamente corretos e bem estruturados.
Ora, semântica e boa estruturação não dependem da linguagem de marcação usada. Dependem somente do desenvolvedor. Quem disse que não é possÃvel escrever documentos semânticos e bem estruturados em HTML? E quem disse que HTML não faz parte dos padrões web?
A última versão do HTML, a 4.01, em sua “versão” strict, consta ainda como uma recomendação da W3C, portanto faz parte dos padrões web sim.
O grande problema de se usar XHTML hoje sem pensar em validação e boa formação é que se amanhã todos os browsers passarem a suportar XHTML e todos que usam essa linguagem decidirem mudar seu media type para application/xhtml+xml, a grande maioria dos sites exibiriam apenas erros de XML.
Algumas pessoas torcem o nariz ao ver um site desenvolvido em HTML, mesmo sendo 4.01 Strict, mas a verdade é que se você não pode garantir a boa formação e validade dos seus documentos XHTML, HTML 4.01 Strict é a melhor opção. Nada nos impede de escrever documentos HTML seguindo as boas práticas de marcação de conteúdo que o XHTML nos ensinou. Nada impede usarmos tag de fechamento em elementos onde ela é opcional (P e LI, por exemplo) excetuando-se, obviamente os elementos vazios (BR, HR, IMG, LINK e META) e descrever elementos em que as tags de abertura e fechamento são opcionais (HTML, BODY e HEAD), por exemplo.
No futuro, migrar de um HTML 4.01 Strict bem estruturado para XHTML 1.0 Strict (ou 1.1) será tão simples ou até mesmo mais simples que migrar de um XHTML 1.0 mal estruturado, mal formado e inválido.
Conclusão
Como eu já disse no inÃcio deste texto, sou a favor do uso do XHTML. Desde que se tome o cuidado de garantir que ele seja, no mÃnimo, bem formado e não vá “quebrar” quando enviado com o media type correto.
O problema é que para poder garantir que sua marcação seja realmente válida — ou pelo menos bem formada — sempre, sem ter que validar cada página criada com uma ferramenta de validação, é necessário trabalhar com ferramentas apropriadas para lidar com XML. Infelizmente os CMS que temos hoje a nossa disposição pecam nesse aspecto. Sistemas legados então nem se fala. Nesses casos, HTML 4.01 pode ser a escolha certa.
Pensar no futuro é importante. Pensar no presente é mais importante ainda. Use a ferramenta certa para que seus documentos funcionem corretamente hoje e, se quiser que eles continuem funcionando bem amanhã, preste atenção à s especificações, tente seguÃ-las o mais fielmente possÃvel.
Se você usa XHTML pensando no futuro, procure garantir que seus documentos continuem funcionando no futuro. Se não fizer isso, você não está de fato pensando no futuro.
Agora, se você pensa que essa história toda de media type é baboseira e não pretende enviar seus documentos XHTML com o media type correto quando todos os user agents o suportarem, bem, desculpe não ter avisado antes, mas este texto é inútil pra você.
Links Interessantes
- Ian Hickson: Sending XHTML as text/html Considered Harmful
- Apêndice C: como compatibilidade entre XHTML e HTML
- Doctype switching do Opera
- Doctype switching do Internet Explorer
- Doctype switching do Mozilla (e browser baseados no Mozilla)
- [update 12/09/2005] Mais links
- Lachlan Hunt: The Future: HTML or XHTML
- Lachlan Hunt: Validation quiz
- Lachlan Hunt: Validation quiz explanation
Compare preços de: jogos de xbox 360, Notebook Rosa, Monitor 22, iPod Touch 8GB, carros volksvagen usados, Câmera Digital Canon, iPod Shuffle, Notebook Intelbras, Notebook Asus Eee PC
10 Set 2005 |
33 comentários... |
Comentar |
|
Em suma, este Content-Type está correto?
<meta http-equiv=”Content-Type” content=”text/html; charset=iso-8859-1″ />
Usado em páginas XHTML 1.0 Transitional…
Desculpa se escrevi besteira aà em cima, mas este texto deixou claro que, embora eu pensasse o contrário, ainda sou um tremendo ignorante no que diz respeito a XHTML, padrões web etc., hehe.
Abraços, e parabéns pelo ótimo artigo!