Premier brouillon de HTML5
Par Laurentj le mercredi, janvier 23 2008, 10:53 - Technologies Web - Lien permanent
Le W3C vient de publier le premier brouillon de la future spécification de HTML5. C'est le résultat d'un travail ardu au W3C, basé sur celui du WHATWG (qui est donc à l'origine de HTML5). Je vous propose une découverte succincte des nouveautés qui sont spécifiées dans ce brouillon.
Avertissement : ce dont je vais parler sont des choses qui sont dans un brouillon. Autrement dit, rien n'est figé dans le marbre, et ce que je décris est susceptible d'évoluer, de changer, dans les mois à venir. Notez aussi que mon billet n'est pas exhaustif.
Rentrons maintenant dans le vif du sujet.
Globalement, HTML5 reprend la majorité des éléments de HTML4. Cependant HTML5 définit aussi nombre de nouveaux éléments, mais aussi d'API qui faciliteront à terme le développement d'applications web modernes.
Structure d'un document
Il y a différentes balises pour découper un document en plusieurs parties :
section,article,aside(encart sur le coté)header(en-tête de section) etfooter(pied de page).- On a aussi
dialogpour les conversations (une sorte dedl),dfnpour les définitions,timepour représenter une date/heure.
Contenu embarqué
Le contenu multimédia envahit les sites web. Il est donc logique que HTML5 fournisse des éléments spécifiques :
figurepour légender du contenu embarqué (si j'ai bien compris)videopour intégrer de la video. J'avais déjà parlé des avantages de la balise video par rapport àobject, dans un billet précédent. Je ne vais pas revenir là-dessus. Sachez que l'implémentation de cette balise est toujours en bonne voie dans Opéra et Firefox (pas sûr cependant que cela prêt à temps pour être intégré dans Firefox 3).audiopour du soncanvaspour afficher/dessiner des graphismes dynamiquement, que vous pouvez d'ores et déjà utiliser dans Firefox 2 mais aussi dans Safari je crois.
Formulaires
Les formulaires dans HTML4 sont particulièrement simplistes. HTML5 remédie à cela en rajoutant des attributs et des possibilités sur l'ensemble des balises de formulaires existantes (form, input etc..). Notez cependant que cette section n'est pas encore écrite dans le brouillon de la spécification de HTML5, mais vous pouvez lire cette partie dans la spec du WHATWG sur les formulaires, ou lire une présentation de ces "web forms 2" que j'avais faite dans un billet il y a un an et demi (possible que ça a évolué, mais mon ancien billet vous donnera au moins une idée de ce qui vous attend :-) ).
Éléments interactifs
HTML5 définit des nouvelles balises qui sont similaires à ce que l'on trouve dans le langage XUL. À savoir des balises pour avoir des éléments d'interfaces riches.
datagrid permet d'afficher un arbre de données, sur plusieurs colonnes si il le faut. C'est l'équivalent de l'élément tree en XUL (mais en plus simple d'utilisation). Et comme en XUL avec les nsITreeView, on peut lui fournir donc un objet javascript qui s'occupera de renvoyer un certain nombre d'informations pour générer le contenu d'un datagrid. Et comme les cellules de la grille peuvent être éditables (comme dans Gecko1.9/FF3 dans tree), on peut se faire un tableur à peu de frais.
On a aussi l'équivalent de progressmeter en XUL : progress pour afficher une barre de progression et meter pour afficher une jauge.
Comme en XUL également, il y a aussi un système de commandes, bien qu'il soit moins évolué en HTML5. On a ainsi un élément command pour déclarer des commandes et un attribut command pour rattacher des éléments à une commande précise.
Vous avez aussi les menus avec menu, qui peuvent se transformer en toolbar avec type="toolbar" ou en menu contextuel avec type="contextmenu". Pour spécifier les items de menus, il faut apparemment réutiliser des éléments html comme li pour les items simples, et select pour les menus déroulants. Pas d'élements spécifiques donc comme menuitem en XUL.
Les templates
Une des choses intéressantes, ce sont les nouvelles balises pour générer dynamiquement des données. Quand j'avais dit que Ajax était obsolète dés ses débuts, parce qu'il existait en XUL un élément template évitant d'écrire des tonnes de lignes de code javascript pour générer dynamiquement du contenu, et qu'il serait bien que cette balise soit en HTML, c'est tout juste si je ne m'étais pas fait traité de con.
Seulement voilà, mon souhait d'avoir cette baliste template est exaucé : HTML5 propose aussi un mécanisme de template, avec la balise datatemplate. Bye bye xmlHttpRequest pour nombres de choses ! Le mécanisme de template de HTML5 est légèrement différent de XUL cependant, mais le principe reste globalement le même :
- avec une balise
datatemplate, on décrit quoi et comment générer le contenu. On a ainsi une baliserulepour spécifier des rêgles, des conditions, et une balisenestpour faire du récursif. - Sur un élément dans lequel on veut générer du contenu dynamiquement, on indique l'url du template dans un attribut
template, et l'url de la source de donnée dans l'attributref. - le template et la source de donnée sont bien sûr séparés, et peuvent être inclus dans le document même ou dans un fichier séparé. Ce qui veut dire par exemple que la génération de la page HTML et des données peut se faire séparément, comme en AJAX donc.
- la source de donnée est un morceau de HTML (et/ou de XML je crois)
Je ne vous donnerez pas d'exemple malheureusement, parce que la spécification est encore vraiment floue sur les templates je trouve. Cela semble cependant très prometteur.
Intéractions avec le navigateur
Bien entendu, ce brouillon spécifie aussi des choses implémentées déjà dans Firefox 2 et 3, et particulièrement intéressantes pour les applications :
- API pour permettre d'exécuter des applications en étant déconnecté, et permettre à ces applications d'être informées de la connexion/déconnexion etc..
- Stockage de données simple en local, sans passer par des cookies, via une API spécifique. (voir la doc sur developer.mozilla.org)
Il ya aussi le stockage de données dans une base de données en local !! C'est à dire que dans une page web, vous pourrez dire au navigateur de créer une base de donnée sur le poste de l'utilisateur, d'y stocker ce que vous voulez, et de faire des requêtes SQL. Bien sûr les données sont persistantes et ne s'effacent pas entre deux pages. Dans Firefox, il y a presque tout pour le faire (puisqu'il embarque SQLite), il manque juste l'API qui permettra de faire la liaison avec Sqlite.
Édition
HTML5 va enfin officialiser l'existence de l'attribut contenteditable, qui permet de rendre éditable une partie d'une page html. Cet attribut existe déjà depuis longtemps dans IE, et depuis peu dans Firefox.
Elle officialise aussi l'api execCommand, utilisée par tout les éditeurs wysiwyg html (TinyMCE, FckEditor et cie), mais aussi l'API pour les sélections. Il y a aussi une API pour gérer les transactions d'éditions, c'est à dire pour gérer les undo/redo.
Une API est aussi spécifiée pour faire du "vrai" drag'n'drop (donc bye bye toutes les "bidouilles" en javascript pour simuler du pseudo drag and drop) : c'est à dire que le document pourra être informé quand l'utilisateur glisse et dépose quelque chose à partir ou vers une autre application desktop. Le document pourra être informé de la même manière quand il y a un copier-coller en provenance du presse papier (clipboard).
Conclusion
C'est un brouillon, mais ce qui avait été promis par le WHATWG (derrière qui il y a Mozilla, Opera, Apple....) est en train de se concrétiser. HTML5 va permettre de faciliter énormément le développement des applications web de demain. On peut remarquer que l'intérêt du XUL diminue vu que HTML5 reprend quelques concepts de XUL. Mais pour le moment, XUL reste quand même très intéressant par d'autres aspects, dont son modèle de boîtes. En effet, nulle part dans la spec de HTML5 il n'est expliqué le modèle de boîte. Mais peut être que cela se fera plus tard.
PS: Enumération détaillée des différences entre HTML4 et HTML5 dans un document du W3C.
Commentaires
On peut compter pouvoir utiliser toutes ces belles choses quand ? d'ici 5 ans ?
Il y a urgence, parce que d'ici là, Microsoft ne va pas attendre les bras croisés... Si jamais WPF/Silverlight atteignent la masse critique, ça craindra pour tous les autres.
Étant donné que Mozilla, Opera &co implémentent tout ça au fur et à mesure, tu peux déjà en utiliser certaines comme je l'ai dit. (ou fait du XUL :-) ).
Pour Silverlight, je doute fortement que ça va remplacer le HTML pour la plupart des sites web. Un exemple : Flash est installé sur quasi 99% des postes, c'est pas pour autant qu'on a une majorité de sites qui ne sont fait qu'en Flash/Flex (je dirais même qu'ils sont rares). Bref, WPF, ça va rester aussi "confidentiel" que Flash/Flex.
Je suppose que ça prendra du temps pour que tous ça soit complètement utilisable. Par contre, il serait intéressant de pouvoir "tester" la disponibilité de certaines de ces fonctionnalités. De cette manière, il serait possible de fournir des versions dégradées en fonction du niveau de support des agents utilisateurs.
Si des mécanismes sont prévus, cela permettra des faire des tests comme en js (if document.getElementById()) et non de revenir à des tests de version de navigateur...
Bonjour,
Et surtout merci pour ce résumé très intéressant. Question "à la c..." mais le html sera-t-il xml-valide ?
Pas d'inclusion de RDFa ? :-/ Retour de la grammaire SGML ? :-/ Malgré toute les avancées, je trouve certains choix étranges. Espérons que des brouillons futurs y remédieront.
Pour répondre à la question "à la c..." à propos de la syntaxe, d'après la doc : http://www.w3.org/TR/2008/WD-html5-diff-20080122/#syntax
On peut choisir sa syntaxe : XML ou SGML
Merci :-)
Intéressant !
Reste à assurer une compatibilité douce avec l'existant... nombre de sites sont codés en utilisant la syntaxe XML, et servis en text/html, afin d'éviter l'erreur de parsing XML... et cela simplement par impossibilité de maîtriser tout le code (ex : un client qui met à jour lui-même son site).
J'avoue que j'ai quelques inquiétudes à ce sujet...
À noter que le support de l'élément video (ainsi qu'audio) est aussi bien avancé dans le Webkit. J'ai testé la chose avec une sortie nocturne : un vrai bonheur. On rêve. À côté notre vieille manière de faire avec les plugins, c'est la préhistoire. À ce moment là ça ne fonctionnait pas encore avec la version Windows du Webkit, peut-être n'est-ce plus le cas ?
http://webkit.org/blog/140/html5-media-support/
Il me semble que le modèle de boîtes concerne plus CSS qu'HTML.
Des évolutions intéressantes pour beaucoup de régressions, aussi... (je ne suis pas fan de ce découpage à la header, footer, section : je me demande ce qui a motivé un tel choix :/)
@cyril : peut être parce que sur 90% (si ce n'est pas 100%) des sites web, il y a un header et un footer ? Rien que sur la page présente ces deux élements pourraient être utilisé, en remplacement des mes divs id="entete" et id="pied"...
En tous cas cette version d'HTML permettra indubitablement d'améliorer l'accessibilité des sites web qui oseront s'en servir. Ainsi dans les quelques années à venir il faudra aussi mettre à jour les WCAG 1.0 et autres RGAA :)
sur le sujet XHML2 vs HTML5 : http://xmlfr.org/actualites/decid/080131-0001
le lien : HTML 5 : les documents deviennent des applications
juste un petit ommentaire pour te dire que tu gagnerai à être reconnnu par tous :)
Article : "A Look at the First HTML 5 Working Draft" Du très bon site infoq.com http://www.infoq.com/news/2008/01/html5draft