Postado em 05 de Agosto de 2011 -
As pessoas já escreveram inúmeros artigos a favor (inglês) ou contra (inglês) acabar com o número de versão no HTML. Aqui temos duas visões contrastantes sobre essas posições, apresentadas por Bruce Lawson e John Foliot.
Os fatos
Ian Hickson, editor da especificação do HTML5 anunciou que o HTML é o novo HTML5(inglês), o que significa que WHATWG irá desbancar o número “5″ e chamará seu spec de “HTML”. O HTML será um “living standard”, com uma mistura de recursos vastamente implementados como <canvas> ou <video> e recursos vastamente experimentais, como<device>. O W3C produziu um spec chamado “HTML5″. Ian Hickson (atualmente) edita ambos deles. Eles são diferentes. O W3C cria uma versão dessa tecnologia que está sob a Política de Patentes do W3C Royalty Free (inglês) para fornecer melhor garantia para desenvolvedores contra as patentes. Essa especificação tem a versão de número 5.
TL;DR: nada realmente muda (por Bruce Lawson)
Mas o que isso significa? O que muda para nós, desenvolvedores? Na prática: muito pouco para a maioria de nós. Os browsers processam o que eles conseguem processar, independentemente de em que modo eles estão, de qual “versão” HTML é atual, ou o que o DOCTYPE de um documento requer.
Tome como exemplo um documento contendo um elemento <video>, usando elementos WebM, Ogg, e MP4 <source>, com controles de script usando os elementos de media API,input type=range, e opacidade e transições do CSS3. Com um DOCTYPE do HTML2 (sim, HTML2!), é um ótimo exemplo do vídeo do HTML2.
Se você estiver usando um browser moderno, tudo irá funcionar bem. Seu browser sabe como mostrar essas belezas no HTML5, então ele mostra, independentemente do que o DOCTYPE pede. Qual seria o sentido de um browser procurar quais elementos são parte do HTML2 e se recusar a mostrar o vídeo por que <video> não é parte da lista? Essa mudança na lógica demoraria muito para processar e atrasaria a renderização, em troca de nenhum benefício real.
A única função de um DOCTYPE é manter o browser fora do Quirks Mode. O HTML5 DOCTYPE <!DOCTYPE HTML> é a string mais curta que faz isso de forma confiável. E note que não existe nenhum número de versão nisso.
Se uma versão menor do HTML te surpreender, ela não deveria. É o que o CSS tem usado desde sempre. Nós felizmente usamos alguns módulos do CSS3 sem prefixos vendor (por exemplo, border-radius), enquanto evitamos alguns recursos do CSS2 porque eles não têm suporte. Portanto, o número da versão não tem uso prático e não devemos nos preocupar com isso.
Aqui está um pedaço da entrevista do xhtml.com com Bert Bos em 2008, que co-criou o CSS com Håkon Wium Lie (um dos membros principais do WHATWG):
xhtml.com: Suspeito que muitas pessoas não notaram que o CSS não tem um identificador de versões… O que levou à decisão original de não incluir um identificador de versões e como isso afetou a evolução do spec do CSS?
Bos: O grupo de trabalho reconheceu há muito tempo que números de versões para formatos de documentos (em oposição a softwares) são uma ilusão. O HTML tem números de versões (dentro do DOCTYPE), mas as implementações ou as ignoram, ou as usam para outra coisa (“quirksmode”).
Os formatos podem evoluir e ser estendidos, como o HTML e o CSS, mas as implementações não fornecerão análises diferentes para versões diferentes. Elas apenas implementam a versão atual. A nova versão deve ser compatível com as antigas, senão um desastre acontecerá. Você pode pensar que colocar um número em uma versão pode fazer com que velhas implementações recusem documentos que são muito novos, mas isso não acontece. Nenhum dos browsers escritos nos dias do HTML2 irá se recusar a lidar com um DOCTYPE do HTML4. E nenhum dos browsers do HTML4 irá recusar um documento do HTML5, uma vez que o HTML5 se torna um padrão. Nenhum browser quer admitir que ele não consegue entender algo, e os usuários não querem usar novos recursos que fazem com que todo o arquivo falhe.
O problema básico é que software velho e novo e conteúdo velho e novo têm que co-existir. Não é possível escolher um dia e trocar todo o conteúdo e todo o software do mundo para uma nova versão. E, na web, alguns softwares, e especialmente alguns conteúdos, têm spams de vida muito longa.
Soa familiar, não?
(Não é a história toda. Como mencionei acima, todos os browsers usam DOCTYPE para alternar entre modos de análise. O Quirks mode é acionado por uma linha no HTML, mas ele não altera a análise do HTML – ele muda as análises do CSS entre o modelo quebrado de caixa do IE5 ou o modelo de caixa do W3C. O Internet Explorer também tem seu modo de compatibilidade que permite ao IE simular versões antigas de bugs. Note que eles são chaves para acionar as implementações com bugs: eles não são chaves entre implementações de diferentes versões do CSS ou do HTML. Eu posso estar me prendendo a semânticas aqui).
Portanto, as versões do HTML serão as mesmas do CSS. Com o CSS, que é apenas estilo, sem conteúdo ou funcionalidade, não importa muito se algo falha silenciosamente. Com o HTML5, não temos prefixos vendor como no CSS, mas a maioria (se não todos) dos novos recursos pode ser identificada e poly-filled com JavaScript. Pode não ser bonito, mas é a maneira do mundo, e números de versões não vão mudar isso.
Finalmente, a presença ou não de um número de versão é menos importante do que o fato de que temos um spec que estende o HTML sem comprometer a compatibilidade antiga. Isso é o que eu comemoro na minha Música Nerd Living Standard.
A versão não é para os browsers. É para os autores. (Por John Foliot)
A principal questão, a meu ver, é que os padrões W3C não são lançados estáveis. Eles são construídos com o tempo, o que implica em um outro nível de estabilidade e de comprometimento.
O último commit padronizado no HTML terminou há mais de uma década com o HTML 4.01 (dez., 1999) (e/ou a serialização do XML XHTML em janeiro 2000, revisado em 1º agosto 2002), e o HTML5 (o markup), uma vez finalizado, irá provavelmente continuar a ser o benchmark daqui a uma década. Além disso, ele vai construir um site usando <frames>, e isso iria funcionar, e todos os agentes do usuário iriam saber o que fazer com aquele código. Os membros do time poderiam trabalhar nesse código em um ambiente compartilhado, usando diferentes tipos de ferramentas de edição (incluindo ferramentas WYSIWYG). Esse trabalho poderia atravessar culturas e geografias, uma vez que a especificação foi traduzida para inúmeras línguas e currículos de ensino do mundo inteiro. É esse tipo de permanência e de estabilidade que vem com um Padrão real.
Dê uma olhada em <hgroup>. Onde estamos com isso hoje? Próxima semana? Abril de 2011? Quem sabe? (Eu meio que sei. Existe um bug arquivado, e ele provavelmente será transformado em um problema real no processo de Last Call. O futuro do <hgroup> está em debate atualmente, mas sem uma timeline firme. A questão é que você precisa estar no topo dessas coisas continuamente, uma tarefa que muitos grupos grandes simplesmente não têm tempo ou recursos para fazer). E existe a acessibilidade do <canvas> e do <video> – pontos em que não irei insistir, mas problemas que continuam sendo não-triviais nos dias de hoje. Muito das novas coisas boas na especificação do Draft HTML5 tem muito pouco suporte para browser. Veja a falta de suporte completo para formulários web, ou muitos dos outros elementos recentemente introduzidos. Chegou a um ponto tão ruim, que algumas pessoas menos informadas acham que a solução, hoje, é que todos os browsers deveriam apenas migrar para o WebKit e todos seus problemas seriam resolvidos – uma sugestão até agora removida de qualquer tipo de realidade, sendo até engraçada. A resposta não é migrar para um mecanismo de renderização buscando estabilidade, mas sim todos concordarem em uma especificação firme que funcione em todos os browsers.
Minha maior objeção é em torno da percepção do spec: desenvolvedores que pensam que só porque foi especificado no WHATWG esta semana, que é bom usar, abusar e se lixar para a permanência e para o legado! É uma atitude continuada do “mistura tudo junto” muito distante do mundo real de grandes empresas e governos. No concurso de ser legal e “do momento”, alguns desenvolvedores esquecem que existe um mundo de comércio, e usuários reais “como a mamãe” lá fora que pensam que o último avanço da internet é o Farmville nos seus celulares.
Acho que o lançamento do Drupal 7 é um ótimo exemplo. Depois de quase três anos de intensa colaboração da comunidade com cerca de mil contribuidores, a última versão desse Open Source CMS de grande destaque foi lançado simultaneamente a inúmeros módulos de plug-in reconstruídos para essa nova geração. A conformidade nos padrões foi um grande condutor para essa versão (da mesma maneira que o suporte a acessibilidade), então esse grande número de desenvolvedores precisava trabalhar em direção a um benchmark extremamente estável. Eles não poderiam se apoiar no spec que muda todo mês. Ninguém quer voltar e reescrever o código que eles enviaram quatro meses atrás simplesmente porque a especificação atual do Draft mudou a maneira como as coisas são feitas. Assim, o bulk dos sites do Drupal 7 que eu já vi até hoje (incluindo aqueles com temas customizados) orgulhosamente suportam o seguinte abaixo de seu capuz:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
WHATWG é uma função útil, sem dúvida. Como as Fashion Houses de Paris, Nova York e Londres, eles criam, exploram e vão além das fronteiras. Mas eles também, muitas vezes, se mantêm afastados do mundo do F&F Clothing em Tesco – Tesco sendo um “Patrocinador oficial da Fashion Week de Londres “. Eu realmente acredito que a comunidade web precisa se lembrar desse fato. Um spec envolvente supre a necessidade dos vendedores de browsers, mas ele não é nada amigável para muitos desenvolvedores comerciais, uma vez que ele machuca entidades maiores que precisam compartilhar responsabilidades de autoria.
