Esta é minha lista de artigos com a tag "text-html"

Doctype – DTD – Document Type Definition

Por: Henrique Costa PereiraWednesday 17 May 2006 às 13:17

Introdução

Um documento de (X)HTML seguindo os padrões à risca nunca é completo sem utilizar uma declaração de tipo de documento corretamente. O Doctype de um documento deve ser o primeiro passo a se considerar antes mesmo de aprender qualquer tipo de sintaxe das linguagens de marcação como XML e XHTML. Porque é a escolha do doctype que vai influenciar no tipo de marcação que você deverá ou não utilizar. Se você quer aprender HTML 4 de forma a seguir corretamente todos os padrões você tem que trilhar um determinado caminho, e se quiser aprender XHTML também seguindo à risca os padrões, você deve seguir outro caminho com algumas diferenças.

Basicamente, tanto para o HTML quanto para o XHTML, você pode trabalhar com 2 tipos de doctypes, o transitional e o strict. Eu vou desconsiderar o frameset intencionalmente. A razão disso é que se alguém nos dias de hoje ainda trabalha com frames, usar um doctype mais ou menos apropriado não vai fazer diferença nenhuma no resultado final do trabalho na minha opinião. Se os frames não estão presentes nas recomendações para um documento strict, o que teoricamente deve apenas ter a sintaxe estrita (strict) de determinada linguagem, não vou considera-lo aqui.

Definição

“Doctype” é o acrônimo de “Document Type”, também conhecido como DTD (Document Type Definition). É o doctype que diz para os user agents qual o tipo de documento que ele tem que interpretar (parsing) e como ele deve renderizar esse documento. A definição de um tipo de documento (doctype) informa quais as regras que os user agents devem utilizar do que é e o que não é permitido em uma determinada versão de um XML e de um (X)HTML. É uma forma de dizer a eles quais são as regras que aquele documento pretende seguir e quais as regras que o browser deve utilizar ao analisar (parsing) o documento.

Diferenças CONCEITUAIS entre doctypes transitional e strict

O nome dos doctypes revelam o que são e para o que servem. O transitional é utilizado para quem está fazendo uma “transição” entre uma forma antiga de marcação para uma mais moderna e mais apropriada. Então se seu site não está livre dos velhos hábitos do passado, se a migração para strict seria muito trabalhosa, se seus documentos não seguem as regras á risca, você pode usar um doctype transitional. Você pode utilizar o doctype transitional enquanto você ainda utiliza muitas tags e marcações de forma inapropriada. Mas seu alvo final com o tempo deve ser escrever um documento que siga 100% os padrões de forma precisa com um doctype strict. Este é o alvo a ser seguido tanto para HTML 4 quanto para o XHTML 1, utilizar um doctype strict.

Para entender isso melhor vamos ver o que está escrito no Document Type Definition do HTML 4:

This is HTML 4.01 Strict DTD, which excludes the presentation attributes and elements that W3C expects to phase out as support for style sheets matures. Authors should use the Strict DTD when possible, but may use the Transitional DTD when support for presentation attribute and elements is required.

Traduzido fica: “Este é o DTD do HTML 4.01 Strict, que exclui atributos apresentacionais e elementos que a W3C presume remover em estágios a medida que o suporte a folhas de estilos amadurece. Os autores devem usar um DTD Strict quando possível, mas utilize o DTD transitional quando precisar manter atributos e elementos apresentacionais.”

A principal razão de ainda existir outros doctypes que não sejam o strict, é porque velhos hábitos ainda persistem no desenvolvimento para web ao colocar sintaxe de apresentação no documento (X)HTML. A recomendação da W3C é que tudo que seja relativo a apresentação seja feito através de uma (ou mais de uma) folha de estilos externa. Se pensarmos em uma linguagem de marcação como o XHTML de forma estrita a seguir os padrões, um doctype transitional não deve nem ser considerado como uma “recomendação” e sim apenas como uma “aceitação” temporária por razões de retro-compatibilidade até o completo amadurecimento do desenvolvedor e da própria web.

Diferenças PRÁTICAS entre doctypes transitional e strict

Na prática, em um documento de HTML 4 com doctype transitional por exemplo, você pode usar uma dezena de tags e atributos como target, bgcolor, align, iframe, center etc mesmo que não sejam mais uma recomendação. Veja uma lista completa do que pode ou o que não pode organizado por doctype. A tag <center> por exemplo serve apenas para centralizar algum elemento. Ela não é uma recomendação da W3C por que trata-se de uma tag apenas para alterar a forma como um elemento deve ser exibido no browser, o que pode ser feito apenas por CSS, e não possui nenhum significado semântico. A tag <strong>, ao contrário do que muitas pessoas pensam, não serve para colocar texto em negrito, o que a caracterizaria como apenas uma tag de apresentação. A tag para negrito era <b> e caiu em desuso. A tag <strong> tem o significado semântico de “grande ênfase” e <em> tem o significado de “ênfase” apenas.

Documentos que utilizam doctypes strict na prática excluem qualquer tipo de tags e atributos com propósitos de apresentação, e doctypes transitional são mais permissivos e tolerantes a utilização de elementos e atributos que não são mais aceitos e recomendados na versão strict da linguagem.

A validação e os doctypes

Se seu documento possuiu algum tipo de sintaxe contrária as regras permitidas para o tipo de doctype que você está utilizando, isso é o que chamamos de “erro de sintaxe”. Óbvio não? Você não esperava outro nome não é mesmo? Ou seja, se você escolheu um doctype strict para seu XHTML, certas coisas que você estava acostumado a aplicar no seu HTML, seja ele strict ou transitional, não poderão ser mais feitas. O critério do validador de HTML da W3C para avaliar um documento é o doctype utilizado. A sintaxe é verificada de acordo com as normas permitidas para cada DTD escolhido. Se você escreveu determinado documento com uma sintaxe correta para XHTML mas utiliza um doctype de HTML 4 Strict, o validador vai acusar erros de sintaxe, mesmo que seu documento esteja 100% exato conforme a versão superior do HTML.

Se seus documentos possuem erros de sintaxe, os browsers vão ignorá-los e tentar renderizar seus documentos da forma em que cada um deles achar mais apropriado. Essa é a única importancia em manter um código válido e sem erros de sintaxe para não deixar nas mãos do browsers a escolha de como ele deve renderizar seu documento. E lembre-se que semântica nada tem haver com validação.

Na década de 90, devidos as implementações que cada nova versão dos browsers recebiam, e por causa da retro-compatibilidade, principalmente do Internet Explorer com as versões anteriores, os browsers foram treinados a renderizar os documentos que encontravam sem doctype a sua própria maneira. Se você não declarar nenhum tipo de doctype no seu documento, cada browser vai renderizá-lo de um forma diferente. Isso permitiu a expansão do HTML como uma tag soup. Isso ainda acontece com o HTML e o XHTML enviados com o mime-type de text/html. Para mais informações sobre mime-types, leia meu texto sobre “XHTML Media Types“. As diferentes formas de renderização são chamadas de “browsers modes”. Leia meu texto “O que é Quirks Mode?” para mais informações.

No caso do XML e do XHTML (enviado com o mime-type de application/xhtml+xml) essas variações de browsers modes não existem. Os browsers que suportam este tipo de mime-type possuem apenas a forma strict de renderização. Apenas duas coisas podem acontecer em documentos enviados como application/xhtml+xml. Ou o documento é exibido corretamente, se estiver tudo certo, ou nada dele é exibido. Se o browser não encontrar nenhum doctype, ele simplesmente não exibe nada. Apenas mostra uma mensagem de parser error na tela. Ele não tenta interpretar o documento a sua própria maneira como acontece com documentos com mime-type de text/html. Em linguagens baseadas no XML você realmente tem que saber o que você está fazendo caso contrário pode ser um completo desastre.

Para finalisar, veja abaixo os doctypes listados que podem ser encontrados nas referências normativas do HTML 4 e do XHTML 1.

Doctypes do HTML 4 :

A referência normativa (http://www.w3.org/TR/html4/sgml/dtd.html) do HTML 4 diz que você pode utilizar 3 tipos de doctype:


<!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">

Doctypes do XHTML 1:

A referência normativa do XHTML diz que você pode utilizar 3 tipos de doctype:


<!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">

Referências:

Comentários: 19

Tags: Browser HTML Semântica Web Validação W3C Web Standards XHTML XML doctype markup media-types mime-type padrões web quirks-mode text-html xhtml+xml

Declarando encodings em XHTML

Por: Henrique Costa PereiraTuesday 11 April 2006 às 13:11

Eu já deixei aqui minha contribuição sobre quais as circunstâncias e quais os mime-types podem ser utilizados ao enviar o XHTML no texto “XHTML Media Types“. Se você ler poderá se livrar da culpa (se ela ainda existe) e enviar seu XHTML 1.0 como text/html (e não necessariamente como application/xhtml+xml), assim como a maioria dos documentos da própria W3C faz o uso do XHTML em seus próprios documentos (se você é um bom observador já deve saber disso). Mas se você resolver enviar seu XHTML como application/xhtml+xml, você deve incluir um passo a mais na forma como declara encodings nos seus documentos. Vamos ver como isso funciona passo-à-passo.

Qual a influência do mime-type?

Há algumas maneiras de informar aos user agents qual o encoding que deverá ser utilizado ao renderizar suas páginas para que você não venha a ter problemas presentes e futuros. Seja usando um mime type onde seu HTML ou XHTML será tratado como HTML puro (ou seja text/html), ou enviando seu XHTML como XML usando o mime-type xhtml+xml. A diferença entre os dois é que documentos de XHTML enviados como XML devem por recomendação conter uma declaração de XML acima do Doctype. Basicamente essa é a difença entre HTML e XHTML na hora de declarar seu encoding.

header HTTP

Utilize o parâmetro charset no content type header do HTTP que é enviado pelo servidor. Há várias formas de se fazer isso dependendo do servidor e da tecnologia que você usa. Você deve verificar qual a melhor maneira de fazer isso em cada contexto. O meu site por exemplo envia um content-type da seguinte maneira:

content-type: application/xhtml+xml; charset=utf-8

Deste modo, as configurações enviadas no header HTTP vão sempre prevalecer sobre as outras formas de declarar encodings, mas isso não exclui a necessidade de cumprir os passos seguintes.

Declaração de XML

Se for um XML que você está enviando (incluindo o XHTML quando enviado com o application/xhtml+xml mime-type), você deve usar o prolog de XML acima do seu doctype da seguinte maneira:

<?xml version="1.0" encoding="utf-8"?>

Meta Tag

Para o HTML e XHTML, independente do mime-type, utilize a meta tag http-equiv da seguinte maneira:

<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />

É muito importante ressaltar que o header HTTP sobrepõe o encoding que você declara na meta tag e na declaração de XML, ou seja, essas três formas de declarar um encoding não são equivalentes. Os user agents vão considerar cada uma dessas formas de informar o encoding superior a outra da seguinte maneira.

Se nenhuma informação sobre o encoding não for enviada via header HTTP, o user agent vai passar a considerar a declaração de XML como a informação correta. Mas se alguma informação for enviada via header, ela vai sobrepor as formas seguintes de declaração. E se nem a declaração de XML for encontrada e nenhuma informação for enviada pelo header, a informação contida no HEAD do seu documento na forma de meta tag será utilizada para informar ao user agent, qual o encoding deve ser utilizado.

Verifique o que é enviado

Por isso é sempre bom saber qual o encoding que seu servidor está enviando para o browser antes de vasculhar seu HTML atrás de erros. Você pode verificar as informações sobre codificação de caracteres enviadas pelo HTTP de um documento, utilizando o Mozilla Web-Sniffer. O documento da W3C “The HTTP charset parameter” ensina como manipular as informações de encodings enviadas pelo seu servidor em diversas tecnologias. Não deixe de ler.

Sempre declare o encoding desejado, através do header HTTP e das declarações no seu documento em si. Se você não declarar as chances dos caracteres do seu site serem renderezidados incorretamente em um cliente ou outro são grandes.

Quirks Mode

A recomendação, é que as três formas de declarar o encoding seja utilizada em um documento de XHTML enviado com mime-type xhtml+xml e para o HTML não é necessário utilizar a declaração de XML acima do doctype. Se usar essa declaração, você deve saber das consequências disso, ao colocar seu documento no modo de renderização quirks e complicar sua vida. A melhor maneira é usar algo como um content-negotiation, para administrar o que é ou não enviado para o Internet Explorer. A não ser que você goste de se divertir desenvolvendo projeto em Quirks.

Referências

O que é quirks Mode: Post que eu escrevi sobre renderização quirks

Standards vs Quirks modes: Leia este interessante documento da W3C.

Content Type: texto muito interessante que eu encontrei no Lachy que dá algumas dicas sobre como tratar charsets no lado do servidor.

HTTP Head: Ferramenta da W3C para você poder ver o header que seu servidor envia aos user agentes e que também te permite verificar qual enconding seu servidor envia.

The HTTP charset parameter: Documento de leitura obrigatória para entender a fundo como ter o controle sobre como seu servidor transmite um charset.

Comentários: 5

Tags: HTTP Internet Explorer User Agent W3C Wasp Web Standards XHTML XML character charset charset-e-encoding encoding media-types mime-type quirks-mode text-html xhtml+xml

Charsets e encodings

Por: Henrique Costa PereiraMonday 10 April 2006 às 13:10

Introdução

Dividi o assunto de charsets e encodings em uma série de artigos que poderão ser acessados (a medida que forem publicados) apenas clicando na tag charset-e-encoding. A lista dos textos em ordem é a seguinte:

Enquanto escrevia este texto, aos poucos ele foi tomando dimensões maiores do que eu esperava. Um hyperlink me levou a um documento, um documento me levava a outro, cada vez mais longe e assim por diante. Vários trechos são traduções pessoais dos documentos originais mesclados com partes de minha própria autoria. Todas as referências foram citadas em seus devidos trechos e a maioria foi comentada no tópico referências, no final de cada artigo.

Espero que nestes artigos você encontre tudo o que precisa saber sobre charsets e encodings em um verdadeiro dossiê sobre o assunto. Sua opinião e seus comentários continuam sendo muito valiosos. Aguardo seu feedback.

Conceitos

Para saber utilizar charsets e encodings de forma mais madura e menos arriscada, é necessário compreender alguns conceitos e definições para poder entender tudo o que precisa sobre codificação de caracteres em linguagens de marcação como o XML e HTML. Então vamos aos conceitos.

Charset

Charset significa “conjunto de caracteres” (character set), e é comumente referênciado apenas como “charset”. Os charsets foram feitos como uma biblioteca de caratecteres que podemos utilizar, para serem utilizados com propósitos gerais em computadores, softwares, browsers etc.

Os charsets mais conhecidos são os da série ISO-8859 (ISO-8859-1, ISO-8859-2, ISO-8859-3, …, ISO-8859-10) e os da família Unicode (UTF-8, UTF-16, UTF-32).

Code Caracter Set (code points)

Em cada conjunto de caracteres (charsets), para cada caractere existe um número único designado para identificação. Essas unidades númericas são chamadas de “code points“. Por exemplo a letra “a” no encoding ISO 8859-1 está na posição de número 65, e assim por diante com cada caractere do conjunto.

Encoding

O “character encoding”, ou apenas “encoding” é a maneira com que os conjuntos de caracteres são mapeados e manipulados pelas máquinas, seja um software, seja um browser etc. Vamos entender como isto funciona.

No encoding ISO 8859-1 a letra “A” está na posição 65º (começando do zero) e pode ser representado no computador usando um único byte com valor de 65. Para o ISO 8859-1 isso nunca muda. Para os encodings da série unicode, as coisas não são tão diretas assim. Embora o code point para a letra “à” no charset unicode seja sempre 255 (em decimal), ele pode ser representado em um computador por 1, 2 ou até 4 bytes, dependendo do encoding utilizado (UTF-8, UTF-16 ou UTF-32). Ou seja, usando o charset unicode, é possível que um caractere seja codificado de formas diferentes dependendo do encoding escolhido.

O XML e o HTML (da versão 4 em diante), foram criados com um modelo lógico na forma como são processados, baseados no Unicode. Isso não significa que todo HTML e todo XML deve ser codificado com algum encoding da série Unicode. Significa entretando que os documentos podem conter somente caracteres definidos pelo unicode. Qualquer caractere pode ser codificado em um documento contanto que ele seja um subconjunto do repertório do unicode. No nosso caso que utilizamos caracteres latinos, uma outra soluções aceitável para ser utilizada no lugar de algum encoding da série unicode seria o ISO-8859-1, onde todos seus caracteres, também fazem parte da série unicode.

Unicode

Unicode é um conjunto de caracteres (”character set” ou apenas “charset”), ou seja um padrão que define em um único conjunto, todos os caracteres necessários para escrever a maioria das línguas atuais em uso em computadores hoje. O unicode tem o objetivo de ser um super conjunto de todos os caracteres já codificados em outros conjuntos.

Existe um consórcio internacional sem fins lucrativos, fundado só para ampliar e promover o uso do unicode no mundo. Leia sobre o consórcio em português para mais informações.

É importante distinguir a diferença entre conjunto de caracteres (”character set” ou apenas “charset”) e codificação de caracteres (”character encoding” ou apenas “encodings”), que justifica o título deste artigo. O unicode é um tipo de charset, ou seja, um tipo de conjunto de caracteres dentre outros, como os da série ISO-8859. E dentro do charset unicode, existem 3 encodings conhecidos como UTF-8, UTF-16, UTF-32 que podem ser utilizados. O encoding UTF-8 da série unicode é a recomendação mais amplamente utilizada.

Todo o jargão necessário para entender charsets e encodings foi definido aqui. Nos próximos textos vamos ver uma aplicação mais prática sobre este assunto e a melhor forma de configurar encodings nos seus projetos.

Referências:

Se você está acostumado a desenvolver user agentes (apenas por diversão) e realmente precisa se aprofundar sobre este assunto o texto UTF-8, a transformation format of ISO 10646 de Yergeau e Character Set considered harmful de Dan Connolly do MIT são dois textos obrigatórios que pode tirar suas noite de sono.

Comentários: 16

Tags: HTTP ISO-8859-1 UTF-8 User Agent W3C XHTML XML ampersand character charset charset-e-encoding encoding entitie mime-type quirks-mode text-html unicode xhtml+xml

XHTML Media Types

Por: Henrique Costa PereiraSunday 19 March 2006 às 19:19

Meses atrás eu passei um longo período tentando entender os media types. Fiz algumas confusões na época, cometi alguns enganos básicos próprios de quem estava começando a entender. Eu quis escrever este texto como uma forma de remir meus erros do passado e deixar registrado aqui um resumo do que a W3C recomenda para os Media Types quase que em um formato de dossiê. Seus comentários sobre meu texto são essenciais como um feedback.

MIME Types

Quando um servidor envia documentos para os user agents (como os browsers ou os mecanismos de busca por exemplo) ele envia um pacote com certas informações que você não vê (meta-informações) sobre o tipo de dados que o documento contêm. Estas informações são enviadas em um campo conhecido como “content-type”, e são expressadas através de um mime-type.

MIME é uma abreviação de Multi-purpose Internet Mail Extensions e inicialmente foi criado para resolver um problema similar de informar os tipos de conteúdo (media-type) anexados em e-mails e reutilizado para o protocolo HTTP. Ou seja, o mime-type indica como o user agent deve tratar o documento que ele recebe.

Veja um exemplo de um content-type de um arquivo de HTML com mime-type “text-html”:


HTTP/1.1 200 OK
Date: Wed, 05 Nov 2003 10:46:04 GMT
Server: Apache/1.3.28 (Unix) PHP/4.2.3
Content-Location: CSS2-REC.en.html
Vary: negotiate,accept-language,accept-charset
TCN: choice
P3P: policyref=http://www.w3.org/2001/05/P3P/p3p.xml
Cache-Control: max-age=21600
Expires: Wed, 05 Nov 2003 16:46:04 GMT
Last-Modified: Tue, 12 May 1998 22:18:49 GMT
ETag: "3558cac9;36f99e2b"
Accept-Ranges: bytes
Content-Length: 10734
Connection: close
Content-Type: text/html; charset=utf-8
Content-Language: en

Como eu disse anteriormente, essas informações você não as vê, são meta-informações (informações sobre as informações) que são enviadas aos user agents para informar que tipo de documento eles estão recebendo. Veja abaixo uma tabela com o resumo das recomendações da W3C do uso correto do mime-type e seus respectivos contextos:

Media types summary for serving XHTML documents
Media type	HTML 4	XHTML 1.0 (HTML compatible)	XHTML 1.0 (other)	XHTML Basic / 1.1	XHTML+MathML
text/html	DEVE	PODE	NÃO DEVE	NÃO DEVE	NÃO DEVE
application/xhtml+xml	NÃO DEVE	DEVE	DEVE	DEVE	DEVE
application/xml	NÃO DEVE	PODE	PODE	PODE	PODE
text/xml	NÃO DEVE	PODE	PODE	PODE	PODE

Eu posso ou não usar “text/html” no meu site em XHTML?

Sim você pode. Só se você estiver usando a versão 1.0 do XHTML. Mas se você quer servir seu XHTML 1.0 como XML você também pode, mas deve usar mime-type “application/xhtml+xml”. Se você ler no “Abstract” do documento XHTML Media Types da W3C, de início traz o seguinte:

“This document summarizes the best current practice for using various Internet media types for serving various XHTML Family documents. In summary, ‘application/xhtml+xml’ SHOULD be used for XHTML Family documents, and the use of ‘text/html’ SHOULD be limited to HTML-compatible XHTML 1.0 documents. ‘application/xml’ and ‘text/xml’ MAY also be used, but whenever appropriate, ‘application/xhtml+xml’ SHOULD be used rather than those generic XML media types.”

Em livre tradução seria o seguinte:

Este documento resume as boas práticas para o uso de vários Internet Media Types para servir vários documentos da família XHTML. Em resumo, “application/xhtml+xml” DEVE ser usado para os documentos da família XHTML, e o uso de “text/html” DEVE ser limitado aos documentos compatíveis com o HTML, ou seja os documentos em XHTML 1.0. Os mime-types “aplplication/xhtml+xml” e “text/xml” PODEM também ser usados, mas quando for mais apropriado, “application/xhtml+xml” DEVEM ser usados preferivelmente do que os media types de XML genéricos.

Não se confunda!

A meta tag http-equiv=”content-type” não determina qual será o media-type que seu servidor vai enviar seu XHTML. Por mais que você possa encontrar o trecho a seguir no código fonte de qualquer site, não é ele que determina se meu site deve ser servido ou não como “text/html” ou como “application/xhtml+xml”:


<meta http-equiv="content-type" content="text/html;
charset=utf-8" />
<meta http-equiv="content-type" content="application/xhtml+xml;
charset=utf-8" />

São as configurações do seu servidor (e não meta tags) que determinam como seu site é servido aos user agents mas elas podem apenas servir como fallback pro user agent, caso não ele não encontre nenhuma outra informação como me lembrou o Bruno.

text/html

O media type “text/html” foi primeiramente criado para o HTML e não para o XHTML. Entretato, como este documento de Dan Connolly diz: “XHTML1 defines a profile of use of XHTML which is compatible with HTML 4.01 and which may also be labeled as text/html.” Ou seja, o XHTML 1.0 pode ser servido como “text/html” e não há discussão para isso.

O famoso e muito citado apêndice C da especificação para o XHTML 1.0 não contradiz estas informações, pelo contrário, no ínicio dele apenas diz que resume para os autores que querem que seus documentos escritos em XHTML sejam renderezados pelos user agents de HTML e em nenhum momento define COMO eles devem ser renderizados e que tipo de media type eles devem usar conforme o trecho:

This appendix is informative.
This appendix summarizes design guidelines for authors who wish their XHTML documents to render on existing HTML user agents. Note that this recommendation does not define how HTML conforming user agents should process HTML documents. Nor does it define the meaning of the Internet Media Type text/html. For these definitions, see [HTML4] and [RFC2854] respectively.

O uso do media-type “text/html” DEVE ser limitado com o propósito de renderizar em um user agent de HTML e DEVE ser limitado ao XHTML 1.0 somente. Usar “text/html” NÃO é apropriado para os documentos da família XHTML principalmente os que utilizam namespaces como o XHTML+MathML. Em resumo, XHTML servido como text/html não é processado como XML e sim como HTML.

E o que o futuro diz?

O maior de todos os problemas, o maior de todos os pesadelos que você que é desenvolvedor poderia ter, se chama Microsoft Internet Explorer. Vou apontar algumas razões.

O Internet Explorer hoje é praticamente o único browsers que não renderiza documentos servidos como “application/html+xml”. Todos os browsers modernos já suportam. Se você tem interesse em servir um site em XHTML servido como XML, você terá que criar soluções dinâmicas para identificar se o browser é o Internet Explorer e servir algo em “text/html” pra ele. Se você pensar em termos comerciais isso é um prejuizo gigantesco e não é questão de “preguiça”. No final, você acaba tendo que criar soluções paliativas para um único browser pela falta de interoperabilidade dele. E considerando a balança de que o Internet Explorer é o browser com muito mais de 80% do mercado, ele acaba impedindo o crescimento e expanção da Web Semântica de forma integral.

Internet Explorer 7

De acordo com o texto The prolog, strict mode, and XHTML in IE, publicado em 15 de setembro de 2005 no Blog oficial do Internet Explorer a versão 7 do browsers azul não vai implementar o mime-type “application/xhtml+xml” no seguinte trecho: “I should say that IE7 will not add support for this MIME type – we will, of course, continue to read XHTML when served as “text/html”, presuming it follows the HTML compatibility recommendations.”

O Internet Explorer 6 foi lançado em outubro de 2001 e se a versão 7 realmente sair este ano, foram ao todo 5 anos entre uma versão e outra. Se tivermos fé e esperança de que pelo menos na versão 8 o Internet Explorer seja capaz de interpretar documentos servidos em “application/xhtml+xml” (vamos dar mais 5 anos para o Bill Gates se interessar em produzir uma outra versão?) e mais alguns 5 anos até que o mundo inteiro esteja utilizando de forma unânime browsers que sejam compatíveis com XHTML 1.1, teremos mais alguns 9 a 10 anos até que comercialmente seja viável investir em alguma tecnologia servida como XML. E como disse o Bruno Torres até lá provavelmente teremos uma versão superior do XHTML 1.1. Quem sabe uma versão 2.0 ou 3.0?