HTML5 digest - Novembre 2010

Ce billet date de plusieurs années, ses informations peuvent être devenues obsolètes.

Alors que les Américains se préparent à faire tourner la planche à billet, je suis en train de me dire que ça fait un bail que je n'ai pas utilisé mon clavier pour produire autre chose que du code. Il est grand temps d'alimenter la pompe à buzz du moment, j'ai nommé la guerre des devises HTML5 dont une partie des spécifications est toujours en phase d'élaboration. Veuillez noter au passage le doctype HTML 4.01 du lien précédent :) Mais trêve de plaisanteries, on est pas là pour déconner ! Abordons le sujet avec un peu de sérieux, ça changera un peu de la soupe qui nous est servie par la presse IT.

Vue d'ensemble

Je voudrais tout d'abord revenir sur une conférence pas toute jeune donnée dans un cadre universitaire par Henri Sivonen : A Lecture about HTML5. Elle est articulée en 3 parties : l'histoire, les principes du design et les nouveautés d'HTML5. Si vous avez un peu de temps devant vous je vous conseille de regarder ça, car même si on commence à bien cerner les nouveautés du langage, la description de la timeline (de 1997 à 2007) de l'avènement de l'actuel Working Group du W3C est particulièrement intéressante et révélatrice des rapports de force en présence. Je reproduis grossièrement la timeline (en anglais) ci-après :

  • W3C: founded in the 90's after the IETF (which usually make the internet standards) had made HTML 2.0 and when Netscape and Microsoft where engaging in a Browser War and there was a need to bring the different players to a table and it was felt that it was necessary to do it outside the IETF process
  • December 1997: HTML 4.0
  • February 1998: XML (Lower layer)
  • May 1998: No more Non-XML HTML (Shaping the Future of HTML Workshop)
  • August 1999: XHTML Extended Forms Requirements (XForms) "The goal for the next generation of forms are incompatible with preserving backwards compatibility"
  • January 2000: XHTML 1.0 (HTML 4.01 reformulated on top of XML)
  • Work on XHTML 2.0 Starts which was by design not backwards-compatible (Exact start date confidential)
  • August 2001: IE6; team disbanded, work on XAML/Avalon (to become Silverlight)
  • January 2003: First Beta of Safari (Engine forked from KHTML)
  • July 2003: Netscape dies (reborn as Mozilla)
  • September 2003: Apple and Opera blast XForms 1.0 PR (proposed recommandation) in a joint review (too hard, too complex, too many dependencies). Opera working on a backwards compatible alternative, Håkon Wium Lie (Opera CTO)
  • June 2004: THE Workshop: W3C workshop on Web Applications and Compound Documents
  • 2004: At that point:
    1. Adoption Slow: XHTML 1.0 still not implemented in IE (Emperor is naked when not parsed as XML)
    2. Proprietary Threat: flash going stronger than SVG
  • 2004: Mozilla and Opera sent a joint position to the workshop: Design principles for web applications technologies => the proposal was voted down (8 in favor, 14 against)
  • 2 days later : WHATWG unveiled, group founded by individuals of Mozilla, Opera and Apple
  • October 2006: TimBL blogs Reinventing HTML
  • March 2007: W3C HTML WG

Pour ceux qui aiment l'histoire il est conseillé de lire aussi le How Did We Get Here? de Mark Pilgrim.

Ah, et pour finir ce premier point, sachez que Microsoft a annoncé le 1 novembre 2010 (!) que la prochaine version de son navigateur (IE9) supportera le type MIME application/xhtml+xml. Oui c'est vrai, vous pourrez un jour sérialiser votre HTML5 en XHTML5 et ainsi vous exposer à une gestion draconienne des erreurs. 1 vocabulaire, 2 sérialisations pour le même prix dans tous les navigateurs (récents) messieurs dames ! Ah ça, le WHATWG n'avait pas menti :D

Le facteur Hype

Attention au facteur hype ! C'est l'avertissement d'un officiel du W3C publié sur InfoWorld le mois dernier : Hold off on deploying HTML5 in websites. Et ça correspond tout à fait à mon point de vue :) Dans l'état actuel des choses et dans le cadre du développement d'un site web desktop (mobile/tablette) cross-platform, la seule chose à faire un peu sensée est l'utilisation du doctype HTML5. Sinon, c'est direction les hacks et les solutions de fallback. Certains vous diront que la dégradation gracieuse est une feature d'HTML5 et on peut voir ça comme ça : The All-In-One Entirely-Not-Alphabetical No-Bullshit Guide to HTML5 Fallbacks. Maintenant d'un point de vue pratique, la vérité c'est que ça fait deux fois plus de taf et que j'ai croisé très peu de bons développeurs web capable de mettre ça en pratique et de le maintenir. Regardez l'état de la balise <video> pour vous en convaincre.

Flash a encore quelques bons mois devant lui, mais Adobe prépare déjà son avenir et son éventuelle transition : Adobe demos Flash-to-HTML5 conversion tool. Et ce ne sont pas les seuls à commencer à bosser sur des GUI pour faciliter la création d'animations via CSS, HTML et JavaScript. Il y en a qui lèvent des millions de dollars pour développer la même chose. On va finir par développer le web ouvert avec des outils fermés si ça continue :)

Un peu de pratique

Hey, on ne va pas faire que se plaindre. Regardez les efforts que Microsoft est en train de faire au niveau du support CSS, c'est tout de même encourageant. L'avenir du web s'annonce plutôt bien. Avant de terminer, abordons quelques points simples relatifs au balisage HTML.

Une des choses que je n'avais pas remarqué c'est qu'HTML5 autorise l'utilisation de balises de type block à l'intérieur d'une balise <a>. Et ça s'est cool et ça permet d'éviter une soupe de balises <span> :

The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).

Parmi la flopée de nouveaux éléments HTML disponibles il y en a un qui s'appelle <ruby>. Rassurez-vous il n'y a aucun rapport avec le langage de programmation homonyme, donc aucune chance pour vous de virer maxi gayz ;) Le post The HTML5 <ruby> element in words of one syllable or less explique le rôle de cette balise et des balises associées <rt> et <rp> en prenant l'exemple du Japonais : cette balise permet d'afficher des hiraganas au dessus des kanjis. Si vous souhaitez creuser le sujet, le docteur vous en dira davantage.

#1 PIerre

02/11/2010 17:22

Merci pour cet article ! Toujours très intéressants tes petits buzz là :)

Mais heuuuu la balise ruby elle existe depuis longtemps non ? C'est juste qu'elle a jamais été correctement implémentée dans les navigateurs...

cf. http://fr.wikipedia.org/wiki/Ruby_(linguistique)

(j'en sais quelque chose parce que je m'étais un peu penché sur le sujet il y a deux ou trois ans, ça pourrait être drôlement utile pour afficher une translitération au-dessus de sinogrammes si ça fonctionnait bien !)

#2 Kemar

02/11/2010 18:12

@Pierre oui, tu as raison pour la balise ruby, bien vu :)

#3 Alain Couthures

03/11/2010 08:26

Je participe au groupe de travail XForms du W3C en tant qu'expert invité car j'en réalisé une implémentation qui s'appelle XSLTForms.

Voici quelques compléments d'informations que je peux vous apporter.

La grande nouveauté est le support de SVG dans Internet Explorer 9 (sans les animations pour l'instant); ceci est certainement un sale coup pour Flash parce que les autres navigateurs supportent déjà correctement SVG. SVG est une notation XML ce qui veut dire qu'un graphique sera bien plus facile à générer automatiquement y compris sur le navigateur lui-même.

Pour ce qui est de XForms, tout d'abord il faut bien savoir qu'il n'est pas lié à XHTML 1.0 ou XHTML 2.0 mais demande à être intégré dans une notation XML. Ceci veut dire que XHTML5 (HTML5 en notation XML "bien formée") lui convient tout aussi bien. Microsoft a d'ailleurs tout récemment annoncé son support de XHTML5 : XHTML in IE9. En fait, les Web Forms définies dans HTML5 sont bien moins riches que les différents contrôles définis par la recommandation XForms qui, de surcroit, inclus aussi sa propre gestion d'événements et la soumission des données.

Le positionnement actuel de XForms est plutôt côté applications de gestion pour entreprises. Cela veut dire que l'ergonomie est encore "spartiate" (ou "soviétique" à votre convenance) alors que l'on peut faire des générations automatiques de formulaires de saisie uniquement à partir de la description des données (schémas). Beaucoup d'institutionnels et de grands groupes à travers le monde sont en train de franchir le pas.

C'est à opposer aux applications Web pour le grand public où la complexité de l'application est généralement bien moindre mais pour lesquelles l'ergonomie est poussée aux limites (des "Mickeys" animés partout partout !).

En conclusion, HTML5 est une très bonne nouvelle pour mon implémentation XForms qui s'appuyait jusqu'à présent sur beaucoup de Javascript parce que les navigateurs vont être capables de faire plus de choses par eux-mêmes avec l'efficacité d'un programme compilé.

#4 Frank Taillandier

06/11/2010 11:16

ah y'a pas à dire c'est vraiment la crise ;)

Avant WebDev's Digest - Juillet 2010 Après Assouplissons-nous quantitativement

Tag Kemar Joint