HTML5: Os fatos e os mitos

Você não pode escapar. Todo mundo está falando sobre HTML5. Talvez uma das mais “hyped” tecnologias desde que as pessoas começaram a colocar cantos arredondados em tudo que é lugar e usar gradientes desnecessários. Em fato, muito do que as pessoas chamam de HTML5 é na verdade tecnologia antiga DHTML or AJAX. Misturada com alguma informação ou falta de informação, então aqui, um expecialista em Java Script Remy Sharp e Opera’s Bruce Lawson avaliam alguns mitos e algumas verdades geralmente mau compreendidas.

[Offtopic:A propósito, você já tem sua copia do Smashing Book?]

Primeiro, alguns fatos.

Era uma vez uma linguagem chamada HTML, ela era tão simples que escrever websites com ela era muito fácil. Então, todo mundo fez, e isso transformou a web em várias coleções de links de artigos de física para o que conhecemos e amamos hoje.

Muitas páginas não se adaptavam as simples regras da linguagem( Por que seus autores eram mais preocupados com a mensagem do que outra coisa), então muitos browsers tiveram que perdoar péssimos códigos e fazer o melhor para funcionar da maneira que o autor queria.

Em 1999, a W3C decidiu descontinuar o trabalho com o HTML e moveu o mundo em direção ao XHTML. E isso era bom, antes que algumas pessoas percebecem que trabalhar para fazer o upgrade da linguagem para HTML2 adicionava muito pouco para a web. Sendo XML, a especificação forçava o browser a parar caso ocorresse um erro. E por causa que a W3X estava escrevendo uma linguagem melhor e mais simples que o antigo HTML, substituindo elementos como e .

Um grupo de desenvolvedores do Opera e Mozilla discordaram com a aproximação e apresentação do pápel da W3C em 2004 que argumentava, “Nós consideramos as Aplicações Web uma importante área que não está sendo adequadamente servida pelas tecnologias existentes… Isso é uma constante ameaça ao unico fornecedor de soluções a resolver esse problema antes das especificações desenvolvidas em conjunto.”

O artigo sugeria sete princípios de projeto:

1. Compatibilidade com versões anteriores e caminho claro de migração.
2. Tratamento de erros bem definidos, como CSS ( ou seja, ignorar coisas desconhecidas e seguir em frente), diferente da manipulação XML de erro “Draconianas”
3. Usuários não devem ser expostos a erros dos autores.
4. Praticidade: todo recurso que for nas inserido nas aplicações da web e suas especificações devem ser justificadas com um exemplo prático de uso. O contrario não é necessariamente verdade: cada exemplo prático não necessariamente terá um recurso implantado.
5. Scripts estão aqui para ficar (mas devem ser evitados se declarações e marcações mais convenientes puderem ser usadas).
6. Evitar um perfil especifico de dispositivo.
7. Fazer o processo em código aberto. (A Web foi beneficiada por ser desenvolvida em código abeto. Listas de e-mails, arquivos e rascunhos das especificações devem ser abertas ao público.)

O papel foi rejeitado pela W3X, então Opera e Mozilla, mais tarde se juntaram a Apple, e continuaram uma lista de discussões chamada Web Hypertext Aplication Tecnology Working Group (WHATWG), trabalhando na suas especificações. As especificações do extended HTML4 forms,

The paper was rejected by the W3C, and so Opera and Mozilla, later joined by Apple, continued a mailing list called Web Hypertext Application Technology Working Group (WHATWG), working on their proof-of-concept specification. The spec extended HTML4 forms, até que ele cresceu em uma especificação chamada Web Applications 1.0 sob a direção de Ian Hickson, que deixou o Opera para o Google.

Em 2006, a W3C percebeu que havia cometido um erro e decidiu ressuscitar o HTML, pedindo a WHATWG pelas especificações para usar como base no que hoje é chamado HTML5

Esses são fatos históricos. Agora vamos olhar alguns mitos histéricos.

Os Mitos

“Eu não posso utilizar HTML5 antes de 2012 (ou 2022)”

Isso é uma má-interpretação baseada na data do projeto do HTML5 que irá atingir o estado conhecido na W3C como Candidato a recomendações ou REC. a  WHATWG wiki diz o seguinte:

Para uma especificação ser considerada um REC, nos dias de hoje são necessárias duas completas e inauteradas implementações , e isso é provido através do sucesso de passar literalmente em milhares de testes(20.000 para a especificação inteira provavelmente seria uma estimativa conservadora ). Quando você considerar todo o tempo que leva para escrever e testar e considerar todo o tempo que leva para implementar cada característica você vai começar a entender por que o tempo tão longo.

Então por definição, a especificação não estará terminada antes que você possa usar ela por inteiro, e em dois browsers.

De qualquer forma, o que realmente importa é que um pouco de HTML5 já é  suportado pelos browsers. Qualquer lista será considerada ultrapassada em uma semana por causa da inovação rápida dos browsers. E também, muitas das funções podem ser recriadas em Java Script em browsers que não fornecerem suporte. A propriedade já está presente em todos os browsers modernos e também no Internet Explorer 9, mas também podem ser recriadas em versões anteriores do IE utilizando a função excanvas library. E a propriedade

HTML5 tende a envelhecer elegantemente, então com um JavaScript  inteligente e algumas idéias, todo as propriedades estarão disponíveis em browsers mais antigos.

“Meu browser suporta HTML5, mas o seu não”

Existe um mito que HTML5 é algo único e  indivisível. Não é. É uma coleção de recursos como vimos acima, Então a curto prazo não podemos dizer que um browser suporta todas as especificações. E outro browser não,  isso não importa realmente. Na verdade quando acontecer de um browser suportar todas as especificações do HTML5 nos estaremos muito ocupados esperando as interações do proximo HTML.

Mas que bagunça você pode pensar. Mas considerando que CSS2.1 ainda não está totalmente pronto e mesmo assim nos utilizamos ele todos os dias. Nos usamos CSS3 border-radius também, o que logo logo será suportado em todos os browsers, enquanto alguns aspectos do CSS3 ainda não tem suporte nenhum.

Desconfie de websites de “pontuação” de browsers. Eles muitas vezes testam coisas que não tem nada haver com HTML5, como CSS, SVG e até fontes. O que importa é o que você precisa fazer, você precisa identificar a sua audiência e qual o suporte dos navegadores que eles estão utilizando e utilizar todo o código que você conseguir e utilizar JavaScript para reproduzir o restante.

HTML5 Legaliza a diferença entre Tag.

HTML5 perdoa bem mais  erros de sintaxe que XHTML: Você pode escrever tags em caixa alta, caixa baixa ou misturar as duas. Você não precisa fechar tags unicas como img, então os códigos abaixo são ambos aceitos:

Você não precisa fechar atributos em ampas, então os códigos abaixo são aceitos:

Você pode misturar caixa alta e caixa baixa (ou misturalas), então todas abaixo são aceitas:
 




Na verdade não existe diferença do HTML4, mas isso pode ser um choque se você usa XHTML. Na realidade, se você está escrevendo suas páginas com combinações de texto e HTML, ao invés de XML (e você provavelmente está, por que o IE8 e abaixo não conseguem renderizar XHTML completamente), então isso nunca importou realmente: o browser nunca se importou com barras de fechamento, ampas ou diferenças de caixa alta ou baixa – somente a validação se importa.
Então, enquanto a sintaxe parece mais ser mais flexível, as regras de análise reais são muito mais exigentes. A diferença é que não existe mais diferença entre tags; as especificações descrevem exatamente o que fazer dessa forma não existe mais marcações inválidas dessa forma todos os browsers produzem o mesmo DOM. Se você já escreveu Java Script que tenha que passar pelo DOM, você está ciente dos horrores de um DOM inconsistente podem trazer.
Essa correção de erro não é motivo para começar a fazer código inválido, mas. O DOM que o HTML5 criar para você pode não ser o DOM que você quer, então fazer seu código HTML ser validado ainda é essencial. Com todas essas coisas novas, talvez um pequeno erro faça seu código deixar de funcionar ou fazer seu CSS quebrar, para isso que existe a Validação HTML5 .
Então nada de diferenças entre as tags, HTML5 é bem consistente.
“Eu preciso converter meu XHTML para HTML5”
 
Então a tolerância do HTML5 para diferença entre as tags é a sentença de morte do XHTML? afinal, o grupo de desenvolvimento do XHTML 2 foi dissolvido, certo ?
Verdade, o grupo de desenvolvimento do XHTML 2 foi dissolvido no final de 2009; eles estavam trabalhando em especificações que competiam com o HTML5, então ter 2 grupos era perda de tempo dos recursos da W3C. Mas XHTML 1 tem especificações finalizadas e é bem suportado por todos os browsers então o seu website em XHTML estará seguro.
HTML5 mata XML
De forma nenhuma. se você precisa utilizar XML ao invés de XHTML, você pode utilizar XHTML5, o que inclui todos os recursos do HTML5 mas exige o formato de sintaxe do XHTML (como ampas fechadas, barras no final de tags unicas e tags em caixa baixa).
HTML5 ira eliminar Flash e Plugins
A tag  permite scripts de imagens e animações que reagem as informações do teclado e dessa forma pode competir com algumas caracteristicas basicas do Adobe Flash. HTML5 tem a capacidade de tocar videos e áudio de maneira nativa.
Assim como quando CSS não suportava muitas fontes, Flash utilizou sIFR para preencher as lacunas, Flash também salvou o dia fazendo HTML5 video compativel. Por que HTML é projetado para poder ser “imitado” em browsers antigos, as marcações entre as tags