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 <img> e <a>.
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:
- Compatibilidade com versões anteriores e caminho claro de migração.
- Tratamento de erros bem definidos, como CSS ( ou seja, ignorar coisas desconhecidas e seguir em frente), diferente da manipulação XML de erro “Draconianas”
- Usuários não devem ser expostos a erros dos autores.
- 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.
- Scripts estão aqui para ficar (mas devem ser evitados se declarações e marcações mais convenientes puderem ser usadas).
- Evitar um perfil especifico de dispositivo.
- 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 <canvas> 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 <audio> pode ser recriada utilizando Flash em browsers anteriores.
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:
<img src="nice.jpg" /> <img src="nice.jpg">
Você não precisa fechar atributos em ampas, então os códigos abaixo são aceitos:
<img src="nice.jpg"> <img src=nice.jpg>Você pode misturar caixa alta e caixa baixa (ou misturalas), então todas abaixo são aceitas:
<IMG SRC=nice.jpg> <img src=nice.jpg> <iMg SrC=nice.jpg>
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 <canvas> 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 <video> são ignoradas por browser que não entendem HTML5 . dessa forma é possível utilizar as tags antigas <object> e <embed>, como pioneiro temos Kroc Camen e seu artigo “Video for Everybody!” (veja a imagem abaixo)
Mas nem todas as características do Flash são suportados pelo HTML5. Não há maneira de fazer gestão de direitos autorais em HTML5; browsers como Opera, Firefox e Chrome permitem os visitantes salvarem os vídeos em suas maquinas com um clique. Se você precisa prevenir seu vídeo de ser baixado, você vai precisar utilizar plugins. Capturar informações de microfones ou câmeras dos usuários atualmente só é possível utilizando Flash (porém uma tag <device> esta entrando em especificação para “post-5” HTML), então se você está tentando escrever um Chatroullete Killer, HTML5 não é para você.
HTML5 é ruim para acessibilidade
Muita discussão está acontecendo sobre a acessibilidade do HTML5. E isso é bem vindo: com tantas mudanças na linguagem da web, ter certeza de que a web é acessível para pessoas que não podem usar o mouse é vítal. Também é vital construir uma solução, ao invés de perdoa-lo e fazer dele um adendo: De qualquer forma, muitos autores sequer colocam texto alternativo em sua tags de imagem, então criar acessibilidade nativa é melhor que esperar que as pessoas a adicionem.
Isso demostra o por que é ótimo que o HTML5 adicione controles nativos como sliders <input type=range>, atualmente suportado pelo Opera e Browsers Webkit) e coletores de data <input type=date>, suportado somente pelo Opera atualmente (veja : Demostrações de formulários em HTML5 ) antes disso nós tinhamos que criar isso em JavaScript e imagens e depois adicionar suporte ao teclado e WAI-ARIA regras e atributos .
A tag <canvas> já é uma história diferente. É uma invenção da Apple que mudou a forma de desenvolver de outros browsers agregando-se também ao HTML5, então não há acessibilidade nativa. Se você está utilizando somente para embelezar, sem problemas; pense nela como uma imagem, porém sem possibilidade de texto alternativo (algumas sugestões as especificações tem sido sugeridas, mas nada foi implementado ainda.) Então tenha certeza que qualquer informação que você escreva em <canvas> seja também informada em outro local.
Texto em uma tag <canvas> se transforma em pixels, igual a uma imagem, portanto é invisível a assistentes e tecnologias de leitores de tela. Considere usar as tecnologias de graficos da W3C SVG (Scalable Vector Graphics), especialmente para coisas como gráficos dinâmicos e animações de texto. SVG é suportado na maioria dos browsers, incluindo IE9 (IE8 e anteriores não suportam, apesar da biblioteca SVGweb pode imitar SVG com Flash em browsers anteriores).
A situação com as tags <video> e <audio> prometem. Mas ainda não estão totalmente especificadas ( e não são suportadas em nenhum browser), uma nova tag <track> está sendo incluída nas especificações HTML5 permitindo Transcripts (ou legendas de karaoke para surdos ou outras linguas) para ser associado com multi-media. Pode Ser imitado com JavaScript, e ser sincronizado com o video.
“Um mestre de HTML5 irá segurar minha mão na minha primeira vez”
Há se isso fosse verdade. de qualquer forma, os charmosos Paul Irish e Divya Manian irão ser bons para você, com seu HTML5 Boilerplate, que é uma série de arquivos que podem ser usados como templates para os seus projetos. Boilerplate trás o JavaScript necessário para você estilizar os seus elementos para o IE; ele pega JQuery do CND (Google Content Distribution Network), mas irá falhar caso o servidor da CDN venha a cair.
Recursos adicionais
HTML5 é um tópico enorme. Aqui vão alguns links escolhidos a dedo. (em inglês)
- Especificações da W3C HTML5 (Editado para desenvolvedores web)
Somente informações para o pessoal que desenvolvem websites (ao invés de desenvolver browsers). - HTML5 Demostrações e Exemplos
Demostrações de APIs em HTML5 implementado a browsers - HTML5 Doctor
Artivos curtos e focados em “Ajudar você a implementar HTML5 Hoje” - html5-shims
Scripts que imitam HTML5 em browsers antigos
Sobre os autores
Esse post é uma tradução livre feita por Daniel Leal Freitas do post HTML5: The facts and the myths postado originalmente no website Smashing Magazine
Remy e Bruce são dois desenvolvedores que estão brincando com HTML5 desde o natal de 2008: experimentando, participando de listas de discussão e tentando ajudar o desenvolvimento da linguagem aprendendo.
Bruce evangeliza os padrões da web para Opera. Remy é um desenvolvedor, falante, blogger e Autor contribuinte para JQuery Cookbook (O’Reilly). Ele mantem seu desenvolvimento Brighton-based uma compania chamada Left Logic, escrevendo código JavaScript, JQuery, HTML5, CSS, PHP, Perl e tudo o mais que ele consegue colocar a mão. Juntos, eles são os autores do livro Introducing HTML5, O primeiro livro completo de HTML5 (New Riders, Julho de 2010)
