15 de maio de 2012

HTML5 nao é apenas HTML5

Recentemente, um aluno me procurou querendo explicações sobre o que exatamente era o HTML5. Parece uma pergunta relativamente simples, mas o cão mora nos detalhes. Lembro que umas semanas antes indiquei um bom livro sobre HTML5 para outro aluno e caí na besteira de indicar um livro sobre o HTML5 que tá na moda, mas ele precisava mesmo era de um livro de HTML, em sua versão mais atualizada.

Este post é direcionado aos puros de coração que jamais (ou quase nunca) viram HTML e vejamos então porque considero que HTML5 não é apenas HTML5.

Esta linguagem é um conjunto de marcações criado a partir da antiga SGML (Standard Generalized Markup Language), uma distinta senhora que deu à luz nossa conhecida XML. Ou seja, a SGML (que Deus a tenha em um bom lugar) e sua cria XML (eXtensible Markup Language) foram concebidas na intenção de se estruturar textos de modo que uma máquina conseguisse conversar com a outra apenas entendendo o formato.

Isso sempre existiu, mas o interessante foi utilizar um formato humanamente legível. Hein? É o seguinte, eu escrevo um texto e salvo em um arquivo com algumas marcações de início e fim do conteúdo:

<dados>
<noticia id=”1″>
<titulo>HTML5 não é apenas HTML5<titulo>
<data>2012-05-14 17:40:10</data>
<chamada>Ei, tu, vem ler esse post “massa” aqui</chamada>
</noticia>
</dados>

Embora eu tenha usado um formato (vou chamar de sintaxe a partir de agora) estranho para um veterinário ornitólogo, certamente ele é capaz de entender (talvez até seus pacientes sejam capazes de entender).

É essa tal de sintaxe que padroniza as coisas. Assim, um documento XML válido é um mero arquivo de texto que segue as regras dessa sintaxe para expor qualquer conteúdo, em qualquer dialeto. Basta que sigamos seus mandamentos:

- O conteúdo é demarcado por tags, também chamadas nós, que são esses nomezinhos cercados por sinais de menor e maior que.

- Toda marcação é encerrada com o  mesmo nome da tag precedido por uma barra. <tag>Conteudo. Também chamado de corpo</tag>

- As tags são fechadas na ordem inversa de abertura. Não deve haver tag interna fechando depois da externa.

- Tudo deve vir contido em uma tag (nó) raiz, conhecida por document element.

- Tags não precisam ter corpo. Quando não têm, usamos uma barra no fim para indicar isso: <tagsemcorpo />

Existem ainda algumas regrinhas 10 centavos menos simples que eu não tô a fim de citar agora.

Pois bem, o HTML é um dialeto oriundo desse conjunto de regras. Quem escreve um documento HTML escreve (ou deveria escrever), em uma sintaxe válida (documento XML bem formado), um conteúdo dentro de tags que os browsers entendem (ou deveriam entender).

O W3C é o consórcio que nasceu no intuito de por ordem na já existente guerra de navegadores na época de Cabral, Colombo, Netscape e Internet Explorer. #FAIL. O W3C nunca conseguiu a utopia de criar um padrão totalmente aceito e devidamente implementado, e por muito tempo, sequer inovou algo neste padrão. Eu gosto de dividir essa história em 4 etapas:

1. Web Conteudeozóica

Nessa era, os browsers eram meros visualizadores de arquivos HTML sem muita preocupação estética. Eu nasci há 10 mil anos atrás e pude presenciar que nesse tempo cunhou-se o termo página, uma vez que o protocolo HTTP havia sido criado para servir uma “folha” de documento por vez. Naquele tempo, a tag <p> significava parágrafo. Simples assim. <p> não siginificava necessariamente que  haveria uma separação de X pixels do parágrafo atual para o próximo conteúdo da página, apenas que era um parágrafo. O uso de tags sem sentido semântico era muito baixo.

2. Parnasianismo Webial

Nessa era, surgiram os ditos “profissionais” de Web. Eram seres bizarros só preocupados em como o tal conteúdo seria exibido no browser (quem disser que eu era um deles está enganado, eu nego tudo com veemência Malufiana).

O formato valia mais do que o conteúdo. Quem se importava com os cegos? Todo mundo enchia as páginas de imagens (como o famigerado spacer.gif) e outros elementos inacessíveis a buscadores.

Esses alquimistas faziam páginas lindas. A partir do mais tosco e grotesco código-fonte saiam as mais finas flores do campo. Reza a lenda que as páginas eram até cheirosas, embora paradas, estáticas … natureza morta.

A fim de tornar as coisas mais vivas, foram adotados novos (nem tanto) artifícios denominados CSS (cascade stylesheet) e Javascript (aluno meu que chamar de Java leva um potó no olho esquerdo). O primeiro com o intuito de aplicar a estética e o segundo para responder a estímulos do usuário e programar algumas pirotecnias e validações de campos de formulários.

Quando o trio foi devidamente apresentado às sociedades da época, o HTML passou a ser chamado de DHTML (Dynamic HTML) e foi aí que começou todo o problema que quero relatar aqui. O HTML sem Javascript ou CSS não tinha cheiro nem sabor, mas juntando tudo, a trinca passou a se chamar DHTML. Estudar DHTML significava estudar as três irmãs metralha.

2.1 Dinastia Explórica

Após o ataque do Alaska a Vladvostok, os exércitos Azuis da Microsoft deram início ao maior império Web de todos os tempos. O Netscape, então absoluto nos tempos românticos da Web conteudozoicamente acadêmica, aqui definhava até o couro e o osso.

Nessa era parnasianamente esteticóidica, o Rei William (Tio Biu para os chegados) ditava as regras e nós, meros trabalhadores havíamos virado escravos de ferramentas esquisitas como o Macromedia Dreamweaver (brincadeirinha… toda brincadeira tem um fundo de verdade, já dizia minha avó) ou o monstro MS Front-Page, este último é melhor falar baixo pra não invocá-lo das trevas.

Cheguei a usar também Adobe Image Ready e até hoje sofro de problemas psicológicos e alucinações com slices.

Era rowspan=25 (isso, sem aspas mesmo) pra lá, bgcolor pra cá e <font> pra todo lado. Tag <b> (“bold”, negrito em aramaico) que abria em uma célula de uma tabela e nem precisava fechar, bastava fechar a célula da tabela que o IE pegava. O Netscape antigo sequer era capaz de renderizar a tabela se esta não estivesse bem montada.

2.2 O fim de uma era sinistra

Todo montador (nós éramos chamados assim pela sociedade da época … puro bulling) usava tag <td> (“t” de table, “d” de célula … isso mesmo, deve ser por causa do aramaico) pra tudo. Layouts eram sempre feitos com tabelas.

Nessa época, a fundação Mozilla trouxe do jogo do Sonic uma raposa que comeu logo 10% do market-share do IE. O Firefox veio para ser um browser rápido (um dia ele foi o mais rápido sim, pode acreditar), com idéias novas (algumas dizem que foram copiadas do Opera, mas tudo bem, foi por uma nobre causa) e capaz de entender algumas das bizarrices explóricas. Paralelo a isso, os montadores ao redor do mundo se organizavam em guetos e planejavam passeatas em defesa do triunvirato: HTML para conteúdo, CSS para estética e Javascript para programação das funcionalidades. Juntos eles formavam o Capitão Planeta.

3. Modernismo HTEmiélico

Finalmente o conteúdo passou a ser mais importante do que a forma. Os cegos começaram timidamente a enxergar a Web e o Google capitaneou uma revolução silenciosa em busca do melhor uso das tags semânticas como <h1>, <h2>, <p>, <th>, <ul>, <ol>, etc.

3.1 A promiscuidade dos browsers

A guerra desenfreada de browsers já havia os transformado em máquinas trituradoras de arquivos bem ou até mal formados.

Chrome e Safari foram dois bólidos montados a partir do mesmo layout engine, o WebKit. Layout Engines, ou simplesmente engenhos são o coração do interpretador HTML do browser. Por exemplo, IE-Trident, Firefox-Gecko, Opera-Presto são como RedBull-Renault ou McLaren-Mercedes da Fórmula 1. O Chrome e o Safari são fabricados até hoje com o mesmo motor WebKit embora com pequenos ajustes pra cada lado.

Diga-se de passagem, a história dos layout engines merecia um capítulo à parte. A assinatura de um Chrome hoje é praticamente o nome de D. Pedro I.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/535.19 (KHTML, like Gecko)Chrome/18.0.1025.168 Safari/535.19 é o nome do Chrome 18 no Mac. Veja nas palavras em negrito a quantidade de menções aos concorrentes.

3.2 A ditadura do W3C

O W3C, tão ovacionado por todos nós até então, resolveu pôr as manguinhas de fora e mostrar que nem era assim tão santo. Acabou com a HTML e seu pseudônimo DHTML e decretou que os browsers a partir dali deviam suportar a XHTML (XML + HTML). O que é isso companheiro? A HTML já não era um dialeto escrito em XML? Todo documento HTML já não seria um documento XML bem formado? A resposta é quase.

O W3C lançou um pacote de austeridade econômica denominado Web Standards. Nele, toda tag de cunho estético foi banida da HTML. O mesmo para certos atributos das tags preexistentes como os cellpadding e cellspacing das tabelas. Aliás, muita gente indevidamente achou que deveria matar as tabelas também, o termo tableless virou cool e muito conteúdo tabular por aí passou a ser montado sobre dezenas de divs. Pura arte cubista que fez os sites precisarem ser testados exaustivamente nos 5 browsers mais populares.

O plano do W3C foi perverso. Todas as furiosas regras XML recaíram sobre incautos documentos HTML. Tags que não possuíam corpo precisavam da barra final. Ex.: <br> deveria ser <br />. Todo atributo deveria ser escrito como nome=”valor entre aspas”, etc. Todo XHTML precisava definir uma marcação inicial denominada DOCTYPE. No XML, DOCTYPEs servem documento validadores do dialeto usado no seu documento XML.

Como diria Virgulino: “Se eu entendi, eu cegue!”

Ora, XMLs são documentos com quaisquer tags, basta que o escritor e o leitor conheçam o dialeto (quais tags podem vir onde e quando) para se dar a comunicação. DOCTYPEs são declarações que apontam para documentos de definição (DTDs). Estes por sua vez dizem: “…essa tag vem aqui, dentro dela só pode ter essa ou essa, primeiro vem aquela, etc e tal…”.

Leitores XML sempre se valeram dos DTDs (mais modernosamente dos XML Schemas) para validar o documento antes de tentar ler. Eles servem de garantia de grafia do documento. Acontece que os escritores dos HTMLs sempre fomos nós e os leitores HTML sempre foram os browsers. As tags sempre foram praticamente as mesmas. Nenhum browser seria maluco de executar uma rotina de validação antes de começar a interpretar nossos documentos para não perder tempo.

No entanto, por um lado, o plano W3Cêico deu certo. O Google agradeceu a melhor organização média das páginas Web que seguiram os Web Standards e os browsers começaram a ser mais rígidos e padronizados. Eles utilizaram os DOCTYPEs não para validar mas para definir seu nível de comportamento. Ou seja, “se um documento vier sem DOCTYPE eu vou ler como eu sempre o li, se ele vier com o DOCTYPE XHTML Transitional eu vou passar a exigir algumas regras de boa formatação, se for XHTML Strict eu vou ligar minha rigorosidade no talo”.

3.3 RIA W3C RIA

Apesar da melhora desta fase da Web, todo mundo estava incomodado com a pobreza dos Web Standards. A DHTML havia trazido mais riqueza em sua época, mas a XHTML focou apenas em rigidez sintática e melhor aplicação semântica das marcações existentes.

Enquanto o W3C dormia em berço esplêndido, o mundo já discutia as novas mágicas Javascrípticas como a AJAX, requisições que os browsers faziam aos servidores Web se atualizar a página. Aliás, o próprio termo página ficou defasado. Os projetos Web agora são programas. O mundo viu emergir os softwares como serviço e a HTML naturalmente deveria ser a linguagem padrão dessa evolução.

O termo RIA (Rich Internet Application) foi exaltado pela Adobe para aplicativos Web que usavam Flash, mas passou também a abranger a trinca XHTML+CSS+Javascript.

Bibliotecas como a jQuery, YUI e ExtJS surgiram e se fortaleceram para simplificar o trabalho muitas vezes tedioso de se constuir RIA usando Javascript. O CSS até que evoluiu e muita coisa melhorou em sua versão 3.

Mesmo assim, dois gigantes ainda hibernavam, o próprio W3C que não inovou praticamente nada e a Microsoft.

Isso mesmo, a Microsoft. Há duas teorias para fato do Internet Explorer ter se tornado o ser mais odiado do planeta. A primeira mais realista é de pura falta de feeling da empresa líder do mercado que achou que nada abalaria seu belo produto. A segunda mais fantasiosa fala até que a Microsoft não queria a evolução da RIA e do software como serviço, pois pense bem, se todo programa rodasse na Web, ela seria a plataforma necessária e não mais o Windows.

4. Semântica pós-moderna

Conspirações à parte, a Mozilla (Gepeto do Firefox), a Opera, a Apple e a Google se cansaram do W3C e fundaram uma sociedade maçônica denominada WhatWG para dominar o mundo. Eles queriam obviamente aumentar seu market-share, fatiando o mercado do IE, mas principalmente, queriam que a Web evoluísse.

As marcações deveriam ser mais semânticas. Ou seja, queremos saber se no meio do conteúdo tem um telefone, um endereço de uma empresa e não apenas que ali é um parágrafo. Isso é muito genérico. Movimentos como os do RDFa e Microformats foram absorvidos no novo Microdata e diversas novas tags surgiram.

4.1 HTML em sua versão 5 e a HTML5

A XHTML não trouxe a semântica almejada, mas sim uma carga de rigidez que tornou os projetos Web mais enfadonhos. Seria interessante diminuir esse rigor. A WhatWG propôs então a ressurreição da HTML. Esta havia morrido na versão 4 para dar lugar à XHTML, então naturalmente sua versão foi chamada de 5.

Ela trouxe novas tags estruturais como <header>, <section>, <article>, <footer>, novas marcações semânticas como <progress>, <meter> e <figure>, suporte sem plugins a áudio e vídeo, suporte a imagens inline vetorias (<svg>) e bitmaps (<canvas>), novos atributos para simplificar tarefas corriqueiras como o placeholder.

Enfim, a HTML em sua versão 5 foi uma revolução HTEmiélica de conteúdo Web.

No entanto, é necessário contextualizar que há muitas gerações que ninguém trabalha apenas com HTML, mas com a tríplice coroa HTML+CSS+Javascript. Como as novidades não vieram apenas na HTML, a CSS já estava em fase avançada de adoção de sua versão 3 pelos browsers e a Javascript há muito que ninguém sabia mais qual a versão exata dela, todo o conjunto de novidades ficou sob o guarda-chuva HTML5.

Em outras palavras, tanto a CSS3 quanto gigantesca melhoria no Javascript (Web Workers, Websockets, geolocation, Session storage, manipulações do canvas, do audio e do vídeo, etc, etc, etc, etc e bote etc nisso) ficaram dentro do assunto HTML5.

Toda essa história foi para dizer que a HTML5 virou padrão W3C, um padrão que deverá ser oficializado em 2014 mas que já é amplamente suportado pelos browsers (até pelo IE, embora ainda estejamos ansiosos para ver o IE 10, uma vez que o 9 deixou muito a desejar).

A nomenclatura HTML5 é hoje dada ao trio e não apenas ao conteúdo HTML.

O aluno que me fez escrever esse texto até as 4:27 da manhã havia me falado sobre um comentário reverberado no encontro Pernambuco.js que ocorreu no mês passado (que infelizmente não pude prestigiar): “Ninguém pode dizer que sabe HTML5 sem saber Javascript”.

Dependendo do ponto de vista, concordo plenamente com a frase, mas isso até atrapalhou esse que então ainda não era meu aluno e o fez pensar em estudar Javascript antes de estudar HTML.

Portanto lembre-se HTML5 não é apenas HTML em sua versão 5.

Deixe um comentário