Voilà 20 ans que le web existe et presque 10 ans que le HTML n’a pas évolué et propose toujours la même structure et les mêmes balises. 10 ans c’est beaucoup, c’est la moitié de la “vie” du web. 10 ans c’est beaucoup, surtout lorsque l’on constate les révolutions qui ont eu lieu dans les usages du web ces 5 dernières années (partage de vidéos, réseaux sociaux, infos en temps réel…). Pas étonnant que des technologies propriétaires (Flash) se soient imposées (notamment sur la vidéo et les RIA) et que d’autres s’installent tranquillement pour combler un manque (notamment Google Gears pour l’accès hors ligne).
Bref, il était temps que le marché se réveille et c’est (presque) chose faite avec l’arrivée à maturation de HTML 5 et CSS 3. Pour faire simple, disons que nous avons franchi le point de bascule et que la route qui mène à une adoption de ces nouveaux standards n’est plus si longue. Pourquoi est-ce important de se soucier de ça ? Tout simplement parce que ces nouvelles spécifications vont changer beaucoup de choses dans la façon de concevoir et d’exploiter les interfaces web, des changements qui vont fortement impacter les différents métiers de la profession.
Autant vous prévenir tout de suite : les explications qui vont suivre sont une tentative de l’auteur de résumer et vulgariser un foutoir pas possible (qui provoquent d’innombrables querelles d’experts depuis des années : HTML 5 is a mess. Now what?) sans pour autant prendre partie car de toute façon les choses semblent visiblement s’améliorer. Je ne donne que mon interprétation, vous êtes libre de proposer la votre.
Commençons donc par nous intéresser à cette nouvelle version de HTML et pourquoi s’est-elle imposée face à XHTML (pour une explication plus détaillée c’est ici : XHTML 2 vs. HTML 5, et là : Misunderstanding Markup: XHTML 2/HTML 5 Comic Strip).
HTML vs. XHTML
Au commencement il y avait donc le HTML 4 dont les spécifications ont été publiées en 1997. Une légère évolution a été publiée en 1999 avec le HTML 4.01. Puis le W3C a décidé de miser sur le langage XML (plus sophistiqué et surtout extensible) en proposant une reformulation du HTML avec les balises du XML, à savoir le XHTML 1.0. Tout l’intérêt de cette reformulation est de pouvoir marier la simplicité du HTML avec la puissance du XML (et ses nombreuses possibilités d’évolution).
Sur cette lancée, le W3C a alors lancé le chantier XHTML 2 pour faire une réécriture complète des spécifications et poser de nouvelles bases pour un langage plus puissant, plus robuste, plus évolutif… bref, un langage qui propulserait le web dans une autre dimension sans toutefois assurer de rétro-compatibilité. Hé oui… car il faut bien faire table rase pour pouvoir redémarrer sur des bases saines. Et c’est bien là le problème : ne pas assurer la rétro-compatibilité était inacceptable pour l’industrie (et notamment les éditeurs de navigateurs) qui ont alors décidé de lancer des travaux indépendant sous l’aile du WHATWG (Web Hypertext Application Technology Working Group). Ce groupe de travail a commencé à travailler sur les spécifications des Web Applications.
Après un bras de fer de plusieurs années (et un constat d’échec pour l’équipe de travail sur les spécifications XHTML 2), le W3C a fini par réintroduire les spécifications du WHATWG et de créer un groupe de travail officiel sur le HTML 5 tout en abandonnant l’autre chantier (RIP XHTML 2).
Par élimination il ne reste donc plus qu’un seul prétendant au titre de remplaçant du HTML 4, d’autant plus qu’il a reçu le soutien de qui vous savez (Google Bets Big on HTML 5). Nous sommes donc semble-t-il arriver à un consensus de l’industrie sur des spécifications qui ne sont pas aussi ambitieuses que celles d’XHTML 2 mais qui ont l’énorme mérite de faire avancer les choses (souvenez vous qu’il n’y a pas eu d’évolution en 12 ans).
Qu’est-ce qui va changer avec HTML 5 ?
Pour faire simple disons qu’avec HTML 5 nous allons quitter l’ère du web des documents pour enter dans celle du web des applications. L’ambition de cette nouvelle itération est donc de supprimer les balises obsolètes, d’en remplacer certaines et d’en introduire de nouvelles afin de donner une structure sémantique plus cohérente aux pages web.
De nouvelles API vont ainsi standardiser un certain nombre d’interactions :
- L’accès hors ligne et le stockage sur le disque dur (pour une exploitation en mode déconnecté) ;
- L’édition en ligne, le drag&drop ;
- L’accès à l’historique de navigation…
Bref, tout ce qui nécessitait le recours à javascript ou à des technologies propriétaires sera désormais “livré d’origine”.
La grosse nouveauté est donc de proposer un nouveau schéma de structuration des données qui va venir remplacer les éléments en bloc et en ligne (cf. HTML5 se dévoile) :
Les spécifications manquent de précisions pour se faire une idée de ce nouveau schéma, d’autant plus que de nouvelles balises structurantes comme <template> et <datatemplate> ont été introduites.
Gros changement également avec un jeu de nouvelles balises permettant de mieux définir le contenu : <header>, <nav>, <article>, <aside> et <footer> :
C’est donc une petite révolution puisque ces nouvelles balises vont permettre une structuration beaucoup plus propre des pages, surtout pour les sites avec beaucoup de contenus (blogs, portails…). Plus d’infos ici : HTML5 and The Future of the Web.
Notons enfin l’apparition de balises très intéressantes comme <audio> et <video> pour les éléments multimédias, <canvas> pour les dessins vectoriels ou encore <datagrid> pour les tableaux de données. Ces nouvelles balises permettront de réduire la dépendance à des technologies propriétaires comme Flash. Juste un dernier mot sur les formulaires qui vont avoir de nouveau types de champs <input> comme date, time, number, range, email, url, search, color…
Je pense qu’il n’est pas faux de dire qu’avec HTML 5 la séparation entre contenu, structure et présentation sera encore plus facilement gérable.
Quelles nouvelles possibilités pour CSS 3 ?
Précisions que du côté des feuilles de styles, les travaux autour des nouvelles spécifications CSS 3 sont beaucoup moins perturbés. Cela permet donc d’avancer plus vite. Quoi que… j’ai dans mes archives des articles sur le sujet datant de 2004 et 2005 : Des formulaires standardisés, CSS 3 : des templates pour structurer vos pages web et Formulaires : quand les CSS 3 vous changent la vie.
L’essentiel des travaux autour des CSS 3 a été de standardiser des propriétés pour réaliser des traitements graphiques qui nécessitaient auparavant des astuces :
- Border-radius pour les coins arrondis ;
- Text-shadow pour les ombres portées ;
- Transparency et Opacity pour la transparance ;
- Animation et Transition pour les animations (cf. Nicer Navigation with CSS Transitions, à regarder avec les dernières versions de Safari ou Chrome)…
Bref, il y a beaucoup de nouveautés à découvrir ici : 7 New Essential CSS 3 Techniques Revealed. Tout l’intérêt étant de pouvoir se passer d’images ou d’astuces pour pouvoir réaliser ce que l’on souhaite. Illustration avec ces jolis boutons :
Encore plus intéressant, toutes les propriétés concernant la mise en page et le positionnement : Presentation Levels, Template Layout, Multi-column Layout, Grid Positioning et Flexible Box Layout.
Le changement va être aussi spectaculaire que radical : là où il fallait tout un tas de <div> imbriqués, d’images, de tableaux… pour arriver à la mise en page et au traitement graphique souhaité (donc en alourdissant le code source), nous aurons bientôt une syntaxe bien plus lisible grâce à ces nouvelles propriétés.
Quels bénéfices et pour quand ?
Je vous propose de récapituler ce que nous venons de voir : un contenu mieux structuré et défini, une syntaxe allégée, des traitements graphiques standardisés… tout ceci va permettre d’avoir un code source beaucoup plus propre. Ceci est particulièrement important dans la mesure où les pages ne sont plus faites à la main pour des utilisateurs humains, mais générées par des systèmes de gestion de contenu et exploitées à la fois par des humains et des agents intelligents (via les balises descriptives ou microformats).
C’est donc une authentique révolution à laquelle nous allons assister… dans quelques années ! Hé oui, car même si les spécifications sont là, leur implémentation est fonction du bon vouloir des éditeurs de navigateurs et du taux de renouvellement par les utilisateurs.
Aujourd’hui le marché est encore dominé par un IE qui risque d’aggraver encore son retard avec ces nouvelles spécifications. Vient ensuite Firefox qui évolue vite (grâce à une communauté très active) mais qui est tout de même fortement ralenti par l’inertie des utilisateurs (surtout lorsque les parts de marché dépassent les 30 %).
Il est certain que les choses sont beaucoup plus simples pour Safari, Opera ou encore Chrome qui peuvent avancer à leur rythme (lire à ce sujet : Opera 10, Chrome 4, Firefox 4 : Vers des plateformes sociales et applicatives).
Donc au final, l’impact ne se fera pas ressentir avant quelques années. Sauf si un éditeur trouve le moyen de faire avancer les choses au forcing (au hasard Google avec son futur Wave qui tournera bien mieux sur Chrome).
Par contre, une fois que le parc de navigateurs aura été renouvelé, j’anticipe un gros changement au niveau de l’industrie du web avec une montée en puissance de profils comme les architectes front office (l’équivalent des DBA ou des architectes systèmes) chargés de concevoir des interfaces web cohérentes et surtout performantes (notamment dans la gestion des styles).
De même, j’anticipe une véritable révolution pour les outils de prototypage rapide dont l’intérêt était limité du fait du format de sortie (du HTML de base que ne pouvaient pas exploiter les équipes de production) et qui vont fortement bénéficier de cette épuration du code source et de la séparation structure / contenu /présentation.
Bref, j’ai l’impression de me répéter, le web a de très beaux jours devant lui avec ces nouvelles spécifications qui vont tranquillement nous amener vers des contenus mieux structurés (sémantisés) et des applications en ligne plus performantes et simples à créer / maintenir.
Très bon article. HTML5 n’est malheureusement pas pour aujourd’hui…
tout a fait d’accord avec “Nicolas F.” c’est un tres bon article bien détaillés mais malheuresement pour nous pas pour demain …
deja qu’IE est encore majoritaire en terme d’utilisateur, et qu’il viennes a peine de sortir la version 8 et ne gere toujours pas le css2 a 100% !! donc le css3 …
Ca fait rêver, surtout CSS 3 pour le webdesign !
J’ai l’impression que la limite entre le rôle d’un webdesigner et celui d’un intégrateur/développeur va devenir de plus en plus flou. Déjà que ces 2 là ont du mal à s’entendre… Un intégrateur avec une bonne maitrise des règles d’ergonomie et d’usabilité pourrait quasiment piquer le job d’un webdesigner sur des chartes graphiques modernes, qui sont de plus en plus épurées et allant à l’essentiel.
J’ai hâte !
Ah l’HTML5… L’arlésienne du web, ca me fait un peu penser à ces voitures volantes qu’on devait avoir en l’an 2000…
Ceci dit, ca a l’air au point, pour le web2.0, mais est-ce que ces spécifications ne seront obsolètes avec le web² ?
Pour être toujours adaptées au web, il faudrait faire évoluer tout cela un peu plus vite !
@ Ludovic > Non absolument pas. L’intégrateur est en charge de transformer une maquette graphique (photoshop, fireworks…) en page HTML. Il n’y a donc pas du tout de recouvrement dans les missions de chacuns. Là où l’intégrateur va prendre du galon c’est dans sa capacité à monter une architecture front office cohérente avec notamment les fermes de CSS.
@ Martin > Le Web² repose sur de totue façon sur de l’HTML donc pas d’impact à prévoir, peut-être les applications mobiles de réalité augmentée seront-elles plus simples à créer.
/Fred
Super article.
Pour moi, le futur du web serait le tout “vectoriel” (du moins pour la majorité des designs). A l’heure actuelle, il n’est pas possible sur les navigateurs les plus utilisés d’intégrer des fonds vectoriel en CSS (seul Opera semble l’autoriser).
Un design vectoriel aurait au minimum l’avantage d’être redimensionnable sans cet effet de “flou” que l’on retrouve sur le bitmap. En plus il serait très rapide à charger, et très simple à modifier (vu que rien n’est “aplatit, on peut modifier une couleur ou supprimer une partie de l’image vectorielle sans l’altérer).
En fait, en ajoutant à ça le sprite CSS, on pourrait avoir un tous les éléments graphiques d’un site web sur une seule image vectorielle, qui pèserait seulement une dizaine de kilo-octet.
Excellente synthèse de l’apport de ces deux langages pour les interface de demain ou d’après-demain. Avec html5 la séparation entre forme et contenu devrait pouvoir être mieux assurée, mais on pourrait presque défendre le contraire ^^
Article très clair et bien fait.
je rajouterais aussi la composante sécurité, notamment les problèmes de same-origin policy, et la fonction digest() pour les mots de passe dans les formulaires [1].
Les problèmes restent toujours peu de support des browsers [2] et peu d’applis de blogs ou autre avec des modèles html5 par défaut.
[1] http://www.w3.org/TR/2009/PR-xforms11-20090818/#fn-digest
[2] http://wiki.whatwg.org/wiki/Implementations_in_Web_browsers
Pour répondre aux commentaires,
HTML5 (et CSS3) est déjà là. Si vous naviguez sur firefox 3.5, safari, chrome dernière version, certains sites utilisent déjà certaines balises à notre insu (et pas que labelisez HTML 5 test),
Excellente conclusion notamment, qui laisse bien apparaitre l’émergence de nouveaux métiers du web.
Certains sauront s’adapter face aux nouvelles générations et aux nouvelles idées, d’autres deviendront réellement des dinosaures du web avec l’utilisation de technos obsolète (en espérant que les propriétaires en face partie), comme aujourd’hui quelqu’un qui vous ferait un site trop gifs et tableaux. Mais avec une véritable différence technique derrière et pas seulement conceptrice.
Conradson >> Bonne remarque mais attention le montage à partir d’images vectorielles est adapté pour des créas graphiques de type vectoriel. Le design bitmap est lui adapté pour des créas graphiques de type bitmap (par exemple une interface basée sur des photos de paysages et/ou quoi que ce soit d’autre)
Conclusion : les deux axes existent et vont continuer d’exister, tout dépend ce que l’infographiste produit et fait valider par le client :)
Pour moi, le futur du web serait le tout “vectoriel” (du moins pour IE6-7-8). A l’heure actuelle et ce depuis 1998, il est possible sur les navigateurs de MS® d’intégrer des fonds vectoriel en VML et CSS (seul l’éditeur en ligne PAGEDITORPRO semble l’autoriser). Des vidéos sur le sujet sont visibles sur ce blog http://nitroblog.mediasites.fr ainsi que sur http://www.svg-vml.net.
1- “presque 10 ans que le HTML n’a pas évolué et propose toujours la même structure:”
-> Ce qui est dramatique pour un navigateur comme IE qui en 10 ans ne tient toujours pas correctement la route et qu’il reste LE navigateur le plus utilisé.(j’ai pas pu m’empêcher)
-> ce qui annonce aussi une véritable exploitation de HTML5 et CSS3 pas avant 4-5 ans ou alors avant mais au détriment d’un grand nombre d’utilisateurs
2 – L’intégrateur pur qui s’était vu obligé d’ajouter le développement à son arc il y a quelques années revient effectivement en force.
Il n’y a qu’à constater l’augmentation significative de services d’intégration comme psd2html, psd2markup, gettemplate et autres.
3 – Beaucoup de frustrations en vue, beaucoup de choses qui vont rester dans les placards ou dans les labs le temps que toutes ces belles choses soient supportées par les principaux navigateurs qui sont clairement des preneurs d’otage de l’innovation. (oui, je sais, c’est long d’implémenter des spécifications correctement)
4 – Ca va peut être faire sauter certains au plafond, mais je suis assez favorable à un navigateur unique et open source (même si j’ai également des centaines de raisons d’être contre ma propre idée).
Merci pour cette synthèse claire sur un sujet aussi bouillant.
@ Tijuan > “un navigateur unique et open source” coupons la poire en deux et proposons plutôt un moteur de rendu unique et open source (Gecko ? Webkit ?) que les éditeurs pourraient implémenter avec plus ou moins de fonctionnalités par dessus.
/Fred