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.
?
Texto original disponível em http://html5doctor.com/html5-living-standard/
De 0 a 10, o quanto você recomendaria este artigo para um amigo?