Olá pessoal, como estmamos?!
HTML5 é uma tecnologia nova. Como ocorre em qualquer nova tecnologia, há uma certa confusão e alguns mal-entendidos sobre o que ela é e o que ela faz.
Muitas tecnologias que não fazem parte da especificação estão sendo atribuídas a HTML5. Eu mesmo, escrevendo sobre o assunto, acabei incentivando essa confusão (acredito).
No post de hoje, apresento o resultado de alguma pesquisa para determinar o que é, e o que não é, parte da especificação.
SVG não é parte do HTML5
Scalable Vector Graphics (SVG) é uma linguagem que habilita a criação de vetores 2D usando XML. É bem similiar a canvas em sua funcionalidade e propósito.
SVG não é parte do HTML5 . Você pode saber mais sobre SVG acessando http://www.w3.org/TR/SVG.
Web Fonts não é parte do HTML5
Uma dificuldade extremamente percebida por designers e desenvolvedores é a utilização de fontes customizadas. A única alternativa “segura” até então é a criação de imagens com as palavras que desejamos utilizar.
Web fonts resolve este problema pela introdução da regra @font-face no CSS.
Web fonts não é parte do HTML5. É parte do CSS3. Aliás, não se chama mais Web Fonts oficialmente.
Para saber mais sobre Web Fonts acesse http://dev.w3.org/csswg/css3-fonts/.
CSS3 não é parte da HTML5
CSS tem relação com HTML desde 1996. A última versão, CSS3, está em desenvolvimento desde 2005 e ainda não há uma recomendação final do W3C.
O importante é entender que CSS não é parte do HTML, tanto no desenvolvimento quanto no uso. São tecnologias diferentes – uma para apresentação, outra para estrutura e layout – que, por causa da “proximidade” no uso, são estudadas em conjunto.
Para saber mais sobre CSS3, acesse http://www.w3.org/Style/CSS/current-work.
Geolocation não é parte do HTML5
Geolocation é uma API que permite a obtenção da “posição no mundo” de quem está acessando uma página. Já escrevi um post sobre esse assunto.
Geolocation não é parte do HTML5. É uma API para Javascript projetada e implementada por alguns browsers.
Para saber mais sobre Geolocation, acesse http://dev.w3.org/geo/api/spec-source.html.
Web Workers não é parte do HTML5
Web workers é uma tecnologia que permite a execução de cálculos pesados (ou qualquer outro tipo de processamento intenso) em segundo plano sem causar qualquer problema na experiência do usuário.
Web workers é uma API Javascript. Não é parte do HTML5.
Para saber mais sobre Web Workers, acesse http://www.whatwg.org/specs/web-workers/current-work.
Web Sockets não é parte do HTML5
Web Sockets é uma tecnologia que permite comunicação bi-direcional entre um cliente e um servidor. Também é uma API Javascript.
Web Sockets surgiu como parte do HTML5. Entretanto, agora é uma especificação separada.
Para saber mais sobre Web Sockets acesse http://dev.w3.org/html5/websockets.
Era isso!
acazsouza
10/10/2011
Explica também que Canvas não é HTML5 e JavaScript não é HTML5, porque qualquer implementação maluca com JavaScript por aí chega um “sabidão” e fala: “É HTML5″, que ódio quando escuto isso.
elemarjr
11/10/2011
Opa!
Na verdade, canvas faz parte da especificação.
Acaz Souza Pereira
11/10/2011
HTML é linguagem de marcação e Canvas não é marcação, portanto não concordo com isso, JavaScript é o heroi nessa história e não o “HTML 5″.
elemarjr
11/10/2011
Acaz, dá uma olhada no link da especificação que eu recomendei
Leo Balter
11/10/2011
Elemar, existe uma diferença entre o que é só a parte de marcação do HTML 5 e o “pacote” HTML 5. Se pensar apenas como marcação você estaria certíssimo.
O pacote HTML 5 é sim além da marcação com o CSS 3 e varias APIs, dos forms ao indexDB e muito mais, incluindo tudo o que você disse não fazer parte.
Aliás o nome também não é mais HTML 5, mas só HTML. Tudo isso você encontra na w3c também.
elemarjr
11/10/2011
Leonardo,
Estou me referindo, especificamente, a especificação. Se, por acaso, estou apontando algo de forma incorreta, fineza citar suas fontes (como eu fiz)
[]s
Elemar Jr
11/10/2011
O chamado “pacote HTML5″ que o Léo se refere é o mesmo que a própria W3C apresenta http://www.w3.org/html/logo/ e que a Google define em seus slides http://slides.html5rocks.com/#formula-intro-slide
E nele o CSS3 faz parte sim do “HTML5″. Mas é óbvio que CSS não é HTML, independente da versão.
Quando as pessoas dizem que coisas como CSS3 e algumas novas APIs Javascript fazem parte do HTML5, elas se referem a esse pacotão de novas especificações da W3C.
Mas se você considera “HTML5″ apenas como linguagem de marcação única e exclusivamente, então acho melhor trocar o título do post para “O que HTML NÃO É?!”. Já que a WHATWG definiu que “HTML é o novo HTML5″ http://blog.whatwg.org/html-is-the-new-html5
Por fim, segue um trecho da especificação do HTML pela WHATWG:
“…In more length: The term “HTML5″ is widely used as a buzzword to refer to modern Web technologies, many of which (though by no means all) are developed at the WHATWG, in some cases in conjunction with the W3C and IETF.
The WHATWG work is all published in one specification (the one you are reading right now), parts of which are republished in a variety of other forms, including an edition optimized for Web developers (known as HTML5). In addition, two subparts of the specification are republished as separate documents, for ease of reference: WebVTT and WebRTC.
The W3C also publishes parts of this specification as separate documents. One of these parts is called “HTML5″; it is a subset of this specification (the HTML Living Standard)….”
http://www.whatwg.org/specs/web-apps/current-work/multipage/introduction.html#is-this-html5?
elemarjr
11/10/2011
Zeno,
Html5 como buzzword pode descrever o pacote. Entretanto, isso não é verdadeiro com relação ao pacote.
Fineza consultar http://dev.w3.org/html5/spec/Overview.html e constatar que essa especificação não fica na marcação. Perceba que há considerações diversas sobre scripting e ao conjunto de objetos DOM.
11/10/2011
Evidente que há considerações sobre scripting e ao conjunto de objeto DOM. Seria no mínimo estranho achar que eles iriam apenas citar a tag e não explicar quais as APIs Javascript de manipulação disso.
Meu ponto é, “HTML5″ não é só essa especificação que você tanto se refere e sim um conjunto de trabalhos.
“…In 2006, the W3C indicated an interest to participate in the development of HTML5 after all, and in 2007 formed a working group chartered to work with the WHATWG on the development of the HTML5 specification. Apple, Mozilla, and Opera allowed the W3C to publish the specification under the W3C copyright, while keeping a version with the less restrictive license on the WHATWG site.
Since then, both groups have been working together….”
http://www.whatwg.org/specs/web-apps/current-work/#history-1
elemarjr
11/10/2011
Opa Zeno,
Estamos misturando as historias, não?!
Como sabemos, o desenvolvimento da especificação não começou no w3c, que, aliás, estava indo em direção diferente.
Ainda hoje há uma certa confusão sobre quem está ditando as coisas. Entretanto, repare que o texto menciona duas linhas do html5 (especificação formal) não de tecnologias relacionadas.
elemarjr
11/10/2011
A fonte primária para esse post é essa publicação do W3C
http://dev.w3.org/html5/spec/Overview.html
Leo Balter
11/10/2011
Eu estava no iPhone (no meio do trânsito) e foi dureza já digitar todo o outro comentário por ali.
O SVG realmente já existia antes do HTML 5. O que acontece é que o HTML5 permite a incoroporação do SVG em sua marcação: http://dev.w3.org/html5/spec/Overview.html#svg-0
Assim como o Canvas também tem muitos esquemas de sintaxe JS que já existiam antes.
A w3c simplesmente não centralizou a especificação de todo o pacote do HTML5, mas sim manteve todas em separado para dar independencia e não fazer com que cada uma impeça o lançamento da outra. Dessa forma, cada API do pacote fica com data de lançamento diferenciado. Assim como já temos coisas totalmente funcionais, como o @font-face do CSS 3, ou o contentEditable, outras ainda não estão muito prontas e nem tão pouco bem implementadas, como o indexDB, por exemplo.
Como disse anteriormente: no ponto de vista de apenas uma linguagem de marcação, realmente nem faria sentido várias APIs fazerem parte do HTML5. Geolocation, localStorage, WebSockets, WebWorkers, etc nada disso influenciam a marcação.
Veja o WebGL, por exemplo. Ele utiliza o canvas para fazer renderizações em 3D, o que tem na especificação do Canvas é a marcação básica e pouca coisa de API, mesmo que seja só a 2D. Cada peça vem em separado.
Em relação a uma outra frase sua: “Scalable Vector Graphics (SVG) é uma linguagem que habilita a criação de vetores 2D usando XML. É bem similiar a canvas em sua funcionalidade e propósito.”
A funcionalidade e propósito do SVG não tem muita relação com o canvas, a única parte é que se relacionam com gráficos.
Explicando rápidamente:
SVG é para marcação de gráficos vetoriais, que são gráficos flexíveis para diversos tamanhos, pequenos ou grandes, como são renderizados de forma vetorial, eles não perdem “resolução”. O SVG também como é renderizado a partir de marcação permite ser indexado, coisa que o Google já faz é é algo bem bacana.
Canvas é basicamente um espaço do HTML para ser rabiscado via JS, não oferece o esquema “vetorial” e dificilmente consegue ser indexado, pois não é renderizado junto do HTML. O Canvas por ser montado via JS também oferece uma performance incomparável e para certos tipos de gráficos uma renderização mais dinâmica e mais “leve” (menos código). O Canvas também serve pra trabalhar com renderização de objetos em 3D (veja o WebGL).
Os dois são bons, mas não é uma opção de gosto do desenvolvedor, mas sim de utilidade para a necessidade de cada situação.
elemarjr
11/10/2011
Leo,
Como você mesmo diz, são especificações separadas, que é exatamente o que estou dizendo.
Talvez seja mais fácil comunicar o mercado colocando tudo em um “grande pacote”, mas, efetivamente, são coisas separadas, desenvolvidas em paralelo e com ciclo de lançamento separados.
Concorda?!
Leo Balter
11/10/2011
O que discordo é dizer que isso não faz parte do HTML 5.
Acho que isso também é culpa que paramos de chamar esse pacote de web ou até o “dhtml” para chamar de HTML5.
Antes tinhamos a visão de que “web” compreendia as tecnologias HTML, CSS e JS. Porém, chegou uma quantidade absurda de ferramentas, APIs, etc. Não da mais pra dividir nesses três pontos, e as pessoas responsabilizaram realmente o HTML 5 por tudo isso.
Claro que no seu ponto de vista existe razão, muita coisa não faz parte diretamente da especificação, que tenta tratar muito mais da marcação em si.
Mesmo assim, fica muito claro pra mim dizer que “geolocation veio com o HTML5″. Sim, não são features dependentes uma da outra, mas fazem parte do mesmo “grupo”.
elemarjr
11/10/2011
Ok. Entendo seu ponto de vista.
Há algum tempo, quando escrevi uma série sobre HTML5, eu mesmo não “forcei” a distinção.
Mas, por outro lado, essa “tendência” de colocar tudo sob o mesmo “guarda chuva” pode gerar mais confusão do que bons resultados.
Por exemplo, como poderemos indicar se o browser x (ou y) é mais (ou menos) aderente à html5?! Devemos nos prender a especificação ou a buzzword?
Não é a primeira vez que vejo essa “confusão” entre buzzword e especificação/conceito (veja-se o que ocorre com SOA). Se o w3c preferiu fazer essa distinção (formalizando-a) não vejo o porquê de fazermos diferente.
Não acha?
Leo Balter
11/10/2011
Opa, essa é uma outra questão sobre testar funcionalidades ou browser x ou y.
Existe uma filosofia que tem surgido principalmente com toda essa quantidade de APIs e features novas que é “deixar de testar qual é o browser e focar em testar se o browser tem suporte a determinadas features”.
Isso simplesmente torna o desenvolvimento web mais sustentável.
Por exemplo: versões diferentes do Internet Explorer tem suportes diferentes a algumas features. O localStorage, por exemplo que tem um suporte parcial a partir da versão 8, e o geolocation com suporte na versão 9. Invés de ficar vendo qual a versão, veja apenas se o browser suporta aquilo. Nisso o seu produto toma decisões a partir da existência dessas features, pois a indicação é que elas funcionem de uma forma única.
Essa filosofia é facilitada pela ferramenta Modernizr que permite fazer esses testes tanto via JS quanto pelo próprio CSS.
elemarjr
11/10/2011
Estamos falando sobre coisas diferentes.
Concordo que sob o ponto de vista prático seja mais fácil vender todas as apis novas como “html5″. Fica mais fácil de entender. Também concordo que seja mais eficiente testar funcionalidades, no lugar de testar aderência a uma especificação quando estamos desenvolvendo. É mais sensato e seguro.
Entretanto, não concordo em trazer buzzwords para o “mundo das especificações” que é, e precisa ser, mais formal. Da mesma forma, considero que vendors devam ter compromisso com especificações, não com features. (infelizmente, não é assim hoje)
Deixando claro, a especificação formal do w3c para o html5 não trata somente de marcação. Aliás, vai muito além.
11/10/2011
Virou uma discussão que não vai chegar ao fim hehe
O ponto é HTML5 – marcação – de fato não inclui nada do que foi citado.
Já HTML5 funcional (quando você for contruir algo de fato com as novas especificações) depende de outras tecnogias como os outros amigos citaram.
Ruan Carlos
11/10/2011
Estão vendo dois pontos diferente e estão tentando comparar, Rio Grande do Norte não é Rio Grande do Sul.
14/11/2011
Otimo post (como sempre) e com alguns comentarios de usuarios que não leram com muita atenção (como sempre..rs) Forte abraço Elemar!