A dificuldade para se criar feeds de sites dos outros é inversamente proporcional à qualidade do código (X)HTML do site em questão. O problema é que, em geral, os sites que têm um código mais arrumadinho, com algum cuidado tanto com sintaxe quanto com semântica, muito provavelmente já disponibilizam seus próprios feeds.

Portanto, o que nos sobra são aqueles sites que têm algum conteúdo que nos interessa, mas cujo desenvolvedor, além de não saber ainda o que é um feed, também não faz idéia de como escrever decentemente um documento HTML.

O trabalho consiste basicamente de cinco passos:

1. Pegar o código do site (via HTTP)
2. Analizar o código e identificar onde está o conteúdo que nos interessa:
   • Título
   • Data de publicação
   • Autor
   • Link
   • Sumário e/ou conteúdo
3. Criar expressões regulares para isolar cada um desses dados
4. Preparar os dados para inserção no feed
5. Iterar pelos dados e criar, enfim, o código do feed

Com certeza, os passos mais complicados são o passo 2 e o passo 3. Para eles não há receita de bolo. Cada caso é um caso e alguns casos podem te tirar algumas noites de sono pra resolver.

Vamos passo a passo. Vamos usar um site fictício, sitesemfeed.com:

Comece seu código colocando em uma variável a URL onde se encontra o conteúdo que você deseja transformar em feed:

<?php
$url = "http://semfeed.com/arquivo.html";

Pegar o código do site via HTTP

Esse passo é simples. Há duas maneiras. Uma usando file() (ou file_get_contents()), que só vai funcionar caso seu provedor de hospedagem tenha allow_url_fopen habilitado o que não é muito seguro e a maioria das hospedagens, incluindo a dreamhost, deixam desabilitado, e a outra usando CURL.

Para a primeira opção o código é simples:

Se a sua versão do PHP for menor que 4.3.0, use o seguinte:

$content = file($url);
$content = implode('', $content);

Caso contrário:

$content = file_get_contents($url);

Nesse ponto, o código HTML inteiro retornado pela URL do nosso site está na variável $content.

Pode ser interessante, em alguns casos, remover as quebras de linha do código. Faça assim:

$content = str_replace("\r", "", $content);
$content = str_replace("\n", "", $content);

Se você precisar usar o CURL, aqui está uma funçãozinha simples, tirada do próprio site do PHP:

function open_url($url){
$curl = curl_init();
curl_setopt ($curl, CURLOPT_URL, $url);
curl_setopt($curl, CURLOPT_RETURNTRANSFER, 1);
$content = curl_exec ($curl);
curl_close ($curl);
return $content;
}

Use assim:

$content = open_url($url);

Em qualquer um dos casos, a não ser que o site em questão já esteja em UTF-8, faça:

$content = utf8_encode($content); //se o site for em ISO-8859-1
$content = iconv('windows-1252', 'UTF-8', $content); //caso seja windows-1252

Tente sempre com o primeiro exemplo. Se der algum problema, tente o segundo. Sites em windows-1252 frequentemente aparecem como ISO-8859-1 para os browsers. Mais sobre encodings e a diferença entre ISO-8859-1 e windows-1252.

Analizar o código e identificar onde está o conteúdo que nos interessa

Essa parte vai ser tão difícil quanto mais bizarro for o código do site. Para simplificar o artigo, vamos imaginar que o site tenha apenas título, data, link e um sumário.

Este é o código que marca os títulos:

<tr><td><font face="Verdana" size="3" color="#000FF"><a HREF="001.html">Aqui está o título!</a></td></tr>

Claro, agradeça aos céus se o código que você for trabalhar for tão simples assim, com tags de fechamento, por exemplo. Frequentemente encontramos coisas muito mais bizarras por aí.

Enfim, o que podemos usar como informação única para identificar o título? Talvez a cor da fonte, talvez o tamanho. Você vai precisar olhar o restante do código pra saber o que tem de único nessa marcação. Claro, uma classe já ajudaria muito, mas não conte com isso.

Vamos usar a cor e o tamanho da fonte como nossos "flags" para os títulos.

De quebra temos o link nessa mesma linha. Sorte nossa.

Vamos ao código das datas:

<td><font size="1">11 de novembro de 2006</font></td>

Aqui teríamos um problema. Várias outras informações no site estão em um FONT com tamanho 1 dentro de um TD. Vamos tentar usar o formato da data para identificar as datas para o feed.

Agora o código dos sumários:

<table border=0 cellspacing="0"><tr><font size="2" color="#000000">Este é o sumário do <a href="teste.html">texto</a><br><b>cheio de marcação estranha <i></b>etc e tal<br><br>E por aí vai...</font><td></td></tr></table>

Mais uma vez, temos em diversos outros pontos do site, a mesma fonte, dentro de um TD, etc. Mas, por sorte, podemos usar a tabela com um único TR e um único TD como identificador para nossos sumários.

Claro que, como já disse, não é fácil reproduzir as bizarrices que costumam fazer por aí. Portanto, pode ser que você encontre casos muito mais complicados, quase impossíveis. Mas, nesses casos, seu sucesso vai depender de sua perspicácia. Novamente, não tem receita de bolo…

Criar expressões regulares para isolar cada um desses dados

Para os títulos e links:

preg_match_all("/<tr><td><font face=\".+\" size=\"3\" color=\"#000FF\"><a [Hh][Rr][Ee][Ff]=\"([^\"]+)\">(.+)<\/a><\/td><\/tr>/", $content, $tit_links);

A variável $tit_links é um array contendo os resultados da busca usando a expressão regular. O índice 0 contém a string completa, 1 contém o conteúdo do primeiro parêntese, o 2 o do segundo parêntese e por aí vai.

Não vou explicar aqui como funcionam expressões regulares. Se você não conhece o assunto, vale muito a pena aprender. Há um guia excelente na web e um livro, escritos pelo mesmo autor, Aurélio Marinho Jargas.

Vamos à ER para as datas:

preg_match_all("/<td><font size=\"[0-9]\">([0-9][0-9]? de [A-Za-z]+ de [0-9][0-9][0-9][0-9])<\/font><\/td>/", $content, $dates);

Há meios de se usar expressões mais complexas e menos extensas para este mesmo caso, mas procurei simplificar para tentar facilitar o entendimento.

Agora os sumários:

preg_match_all("/<table border=\"?0\"? cellspacing=\"[0-9]\"><tr><td><font size=\"[0-9]\" color=\"#[0-9]+\">(.+)</font><td><\/td><\/tr><\/table>/", $content, $summaries);

Estou levando em conta que podem, no futuro, resolver mudar o tamanho da fonte, ou colocar aspas nos atributos que não as têm.

Perceba que estou usando um caso fictício, não testado, apenas para exemplificar. Se você não analizar por si mesmo o site e não entender como as expressões regulares funcionam, é melhor nem tentar fazer um feed.

Mas, eu não poderia usar um parser HTML? Talvez sim. Eu já fiz alguns testes e achei mais fácil usar expressões regulares. Se você teve alguma experiência boa usando um parser HTML em PHP, conte pra gente.

Se o cara que fez o site mudar o código, meu feed já era? Yep. Esse é um grande problema de feeds feitos dessa forma. Se o cidadão mudar o código seu feed pára de funcionar. Simples assim.

E quanto ao copyright do site do camarada? Bem, tome cuidado com isso. É melhor consultar o dono do site antes, ou então assumir os riscos, se você tiver cara pra isso…

Criando o feed

Nesse ponto vamos iterar pelos itens coletados com as expressões regulares e criar o código do feed. Vou usar o formato RSS 2.0, que é mais popular.

O passo "preparar os dados para inserção no feed" vai ser feito dentro da iteração.

<?php
header("Content-type: application/xml; charset=utf-8"); //Sem isso, o arquivo será enviado como HTML
echo '<?xml version="1.0" encoding="utf-8"?>' . "\n";
?>
<rss version="2.0">
<channel>
<title>Site Sem Feed</title>
<link><?php echo $url ?></link>
?>
for ($i=0; $i<sizeof($tit_links); $i++): //considerando que todos os arrays tem o mesmo número de índices, não importa muito o tamanho de qual você pega aqui
$title = $tit_links[2][$i];
$link = $tit_links[1][$i];
$tz_offset = -3;
$date = date("D, d M Y H:i:s \G\M\T", strtotime($dates[1][$i]) + ($tz_offset * 3600)); //Isso aqui não vai funcionar, na verdade. Você vai ter que queimar a mufa pra transformar aquela data do exemplo em algo usável. Tô sem saco pra isso agora...
$summary = $summaries[1][$i];
$summary = strip_tags($summary, '<a> <br>
<p>');
?>
<item>
<title><?php echo $title ?></title>
<link><?php echo $link ?></link>
<pubDate><?php echo $date ?></pubDate>
<description><![CDATA[ <?php echo $summary ?> ]]></description>
</item>
<?phpphp endfor; ?>
</channel>
</rss>

E assim está feito nosso feed.

Antes de ter sucesso, você vai provavelmente ter que fazer diversos testes, arrancar alguns cabelos, xingar a mãe do cara que fez aquele site tão bizarro e tudo mais. Mas, quem quis fazer o feed foi você, então agüenta, malandro.

Na época, o FIR foi levado à fogueira e deixou de ser recomendado pelos especialistas no assunto, pois o artifício de se esconder o conteúdo de um SPAN usando display:none esconderia o conteúdo também de leitores de tela, notadamente do JAWS, um dos mais (talvez o mais) usados leitores de tela do mundo.

Como leitores de tela são extremamente difíceis de usar por pessoas que enxergam e como tinha gente importante dizendo que isso funcionava assim e ponto e que tinham testado e etcetera e tal, nunca me preocupei em verificar com minhas próprias mãos (e ouvidos) se isso era realmente verdade.

Acontece que estou desenvolvendo um site para um português, que é cego. Ele me pediu que, em algumas partes do site, usasse uma função em JavaScript para alternar um determinado conteúdo (estilo toggle). Como os conteúdos são pequenos, não precisei usar nada de AJAX, simplesmente deixá-los carregados (e escondidos) no HTML e, de acordo com a ação do usuário, esconder um elemento e mostrar outro. Simples assim.

Fui na onda de que o display:none iria esconder o conteúdo do JAWS…e me dei mal.

O cliente insistia em me dizer que o lance não funcionava e eu não entendia porque. Segundo ele, o leitor de tela (sim, o JAWS) estava lendo todo o conteúdo, mesmo o que deveria estar escondido.

Peguei um café e comecei a pensar. O que poderia estar errado?

Simples, o JAWS ignora, sim, um determinado conteúdo escondido via display:none, a não ser que você declare este display:none apenas para mídias visuais (screen, por exemplo).

Veja bem. Em geral, quando aplicamos uma folha de estilos CSS a um HTML, esquecemos de declarar a(s) mídia(s) (ou media type) a que este CSS deve ser aplicado. Exemplo: <link rel="stylesheet" type="text/css" href="/c/estilo.css">

Usando o código acima, o estilo será aplicado independente da mídia. Se ela tiver suporte a CSS, este será aplicado. Ponto.

O mesmo aconteceria caso usássemos: <style type="text/css">@import url(/c/estilo.css);</style>

O código acima costuma ser usado por aqueles que desejam que seu CSS seja ignorado por browsers antigos, como o Netscape 4, por exemplo.

Só que faz tempo que uso outro artifício para esconder meus CSS das velharias (já que o método acima pode causar o que chamamos de FOUC). Declaro dois media types, separados por uma vírgula e um espaço. Assim: <link rel="stylesheet" type="text/css" href="/c/estilo.css" media="screen, projection">

E era isso que eu estava usando no site a que fiz referência acima. Retirei os media types e, voilà, o JAWS passou a ignorar o conteúdo escondido pelo display:none.

Claro, não quero dizer que você não deva declarar media types ao aplicar um CSS a uma página. Longe disso. O lance é criar um outro CSS, apenas com os display:none que devam ser interpretados por leitores de tela e aplicar ao conteúdo sem declarar a mídia. (Preciso verificar se funcionaria usando a mídia aural).

Se alguém tiver disposição e condições de testar isso em outros leitores de tela, por favor, me conte os resultados para que eu publique aqui como referência.

Voltando ao FIR, acho que ele continua não sendo uma boa forma de image replacement. Não porque torne o conteúdo inacessível para leitores de tela, mas por outros motivos, como não funcionar em situações onde haja suporte a CSS e não haja suporte a imagens.

Moral da história: por mais que especialistas te digam que alguma coisa é assim e ponto final, é sempre bom dar uma olhadinha e fazer os testes você mesmo para verificar. Eles podem estar errados, mesmo que seja apenas em parte.

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

Vou explicar. XHTML é uma linguagem diferente do velho HTML. Na verdade é uma junção de HTML com
XML. Sendo uma linguagem diferente, o XHTML tem seu próprio MIME Type – application/xhtml+xml. Na verdade
não faz sentido usar XHTML se você o envia com o MIME Type de HTML.

Mas qual a vantagem disso?

Na verdade, não há vantagens reais perceptíveis. Pelo menos não pra mim. A única coisa interessante é que,
pelo menos na família Mozilla, um documento XHTML mal-formado não é exibido se o MIME Type correto for especificado.

Mal-formado? Não seria inválido? Não, um documento XHTML bem-formado e inválido será exibido perfeitamente. Ou seja, você precisa que todas as tags estejam devidamente fechadas e perfeitamente aninhadas, mas um id duplicado não
evitará que a página seja exibida. Caracteres como ‘&’, ‘<’, ‘>’ devem ser ser devidamente codificados na
forma de entidades HTML ‘&amp;’, ‘&lt;’, ‘&gt;’, respectivamente. Existem outros caracteres que devem
ser codificados, estou citando apenas os mais comuns.

Mas, se não há grandes vantagens em se usar esse MIME Type, por quê usá-lo? Bem, é uma questão de escolha.
Já que é pra seguir os padrões, vamos tentar seguí-los da melhor forma possível. De acordo com o
W3C, application/xhtml+xml deveria ser usado para servir documentos XHTML para user agents que entendem XHTML e os autores que quiserem suportar user agents XHTML e HTML ao mesmo tempo podem usar negociação de conteúdo (vamos chamar a partir daqui de content negotiation) para servir documentos XHTML como application/xhtml+xml e HTML como text/html.

Como vocês podem ver, não é obrigatório, mas é recomendado.

Dentre os user agents que não entendem XHTML está – adivinhem quem – o, com o perdão da má palavra, Internet Explorer. Ainda sonho com o dia que não vou precisar pensar neste “browser” ao desenvolver sites…

Existem outras complicações ao se servir documentos XHTML como manda o figurino. Por exemplo, os anúncios do google não são exibidos em páginas XHTML, já que a função javascript document.write() não funciona em XML.

Bom, mas vamos ao que interessa.

Content Negotiation

Como eu já havia citado acima, nem todos os user agents – browsers, spiders, leitores de tela, etc – reconhecem o MIME Type application/xhtml+xml. Portanto, para podermos agradar a gregos e troianos, devemos utilizar uma coisa chamada content negotiation para identificar as capacidades do user agent e entregar o conteúdo de forma que ele possa entender.

Para os usuários de PHP, este processo é bastante simples. Basta incluir algumas linhas de código no topo de seus scripts e pronto. Essas linhas eu tirei de um artigo sobre content negotiation que li no site 456 Berea Street. São elas:


<?php
if (stristr($_SERVER['HTTP_ACCEPT'], "application/xhtml+xml") || stristr($_SERVER["HTTP_USER_AGENT"],"W3C_Validator")) {
header("Content-Type: application/xhtml+xml; charset=utf-8");
header("Vary: Accept");
echo("<?xml version=\\"1.0\\" encoding=\\"utf-8\\"?>\\n");
} else {
header("Content-Type: text/html; charset=utf-8");
header("Vary: Accept");
}
?>


Vamos entender este código.

Na primeira linha verificamos se o user agent aceita application/xhtml+xml ou se o user agent ̩ o W3C Validator Рo validator ṇo envia um header ACCEPT, mas reconhece este MIME Type. Caso positivo, enviamos um header HTTP indicando o content-type (MIME Type) application/xhtml+xml, mais um header Vary e escrevemos o prologue XML.

Vary? Sim, é interessante incluir este header para avisar a mecanismos intermediários de cache – como proxies por exemplo – que o content-type pode variar de acordo com o cliente que está fazendo a requisição.

Caso negativo – o user agent não aceita application/xhtml+xml e não é o validator – enviamos um header content-type indicando text/html e o header Vary. Perceba que neste caso não escrevemos o prologue XML, já que ele pode causar problemas, principalmente naquele programinha (o do ícone azul) daquela empresa de Redmond que muitos teimam em chamar de browser.

Este código não é completo. Além de verificar a capacidade do user agent de reconhecer application/xhtml+xml, deveríamos também levar em conta o q-rating. Q-rating é uma forma de o user agent informar suas preferências por MIME Types, charsets, etc. O artigo Content Negotiation, de Tommy Olsson explica passo a passo como reconhecer as capacidades do user agent e, levando em conta o q-rating, servir o conteúdo da forma mais adequada. Vale a pena a leitura.

E se eu tiver, além dos scripts PHP, arquivos XHTML puros? Bom, neste caso ou você deixa que eles sejam servidos como text/html ou então usa um artifício do apache para fazer como que seus arquivos .html sejam interpretados pelo PHP. Ainda tirado do artigo supracitado:


RemoveHandler .html .htm
AddType application/x-httpd-php .html


Isto deve ser incluído dentro do seu arquivo .htaccess. Para que isso funcione, é necessário que o servidor aceite este tipo de configuração nos arquivos .htaccess. Se tiver dúvidas, consulte o administrador.

E o Google Adsense?

Para quem exibe anúncios do google em seu site, servir arquivos XHTML como application/xhtml+xml pode ser uma grande dor de cabeça. Já que o google usa a um javascript, com funções document.write() para escrever o conteúdo de seus anúncios dentro de um <iframe> dentro da sua página e document.write() não funciona em XML e documentos XHTML são XML, os anúncios não são exibidos em páginas servidas com o MIME Type correto.

Mas, felizmente, existe uma maneira de contornar este problema.

O que se deve fazer é criar um documento HTML (servido com o MIME Type text/html) e incluí-lo dentro da sua página utilizando um <object>

Tirado do artigo making AdSense work with XHTML, do site Keystone Websites:

Note que o caractere » marca uma quebra de linha que foi inserida apenas por questões de espaço e deve ser desconsiderada


<?php header("Content-Type: text/html;charset=utf-8"); ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="pt">
  <head>
    <title>Anúncios</title>
    <style type="text/css">
      body { margin: 0; padding: 0; }
    </style>
  </head>
  <body>
    <script type="text/javascript">
      Parâmetros normais do AdSense
    </script>
    <script type="text/javascript" src="http://pagead2.googlesyndication.com/ »
pagead/show_ads.js">
</script>
  </body>
</html>


A primeira linha envia um header content-type text/html. E o restante é HTML comum, com o código que você pega do google para incluir na sua página.

Salve este arquivo, por exemplo, como adsense.php e inclua no local desejado na sua página da seguinte forma:


<object data="/adsense.php" type="text/html"></object>


Se você quiser usar content negotiation, inclua as seguintes linhas, em PHP:


<div class="adsense">
<?php
if($mime == "application/xhtml+xml") {
    print "  <object data=\"/adsense.php\" type=\"text/html\"></object>\n";
} else {
?>
  <script type="text/javascript">
    Parametros normais do AdSense
  </script>
  <script type="text/javascript"
src="http://pagead2.googlesyndication.com/ »
pagead/show_ads.js">
</script>
<?php
}
?>
</div>


Note que usamos uma variável $mime, para verificar o MIME Type. cabe a você usar o que aprendeu neste artigo para atribuir o valor certo a esta variável.

Problema resolvido. Mas tem uma outra questão. Se você usar mais de um bloco de anúncios na sua página, pode acontecer de anúncios que foram exibidos no primeiro bloco, se repetirem nos próximos, já que usando o <object> o google não vai conseguir determinar a ordem dos blocos na sua página. Na verdade ele nem vai conseguir saber que você está usando mais de um bloco. Não é nada demais, mas é bom avisar.

Conclusão

Se você estiver afim de seguir os padrões de verdade, mesmo que não tenha de início nenhuma vantagem aparente, acredito que este artigo pode ajudá-lo bastante nesta tarefa.

Recomendo a leitura dos artigos linkados aqui. Eles são em inglês mas serviram como base para que eu pudesse usar estas técnicas e também para a elaboração deste artigo.

Outras mudanças foram feitas no site além do MIME Type. Agora estou usando UTF-8 ao invés de ISO-8859-1, dei uma enxugada no código XHTML para que ficasse mais legível e mais fácil de manter e também estou usando um esquema de templates e um arquivo PHP apenas para cuidar da manipulação de todas as URLs e gerenciar o conteúdo. Mas explicações sobre estas mudanças ficam para um artigo posterior.

Espero que este artigo os ajude. Infelizmente os comentários ainda estão desabilitados. Esta semana ainda devo reabilitá-los.