FredCavazza.net

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) :

Le "content model" de HTML 5

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> :

Les nouvelles balises de structuration du contenu de HTML5

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 :

De jolis boutons sans image avec CSS 3

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).

Google Wave, une application en ligne taillée pour HTML 5 et 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.

Le W3C vient d’initier une démarche de normalisation pour l’accessibilité des interfaces riches : Roadmap for Accessible Rich Internet Applications, et c’est un très bonne nouvelle.

Le W3C avait déjà initié différents chantiers autour d’AJAX et des interfaces riches (voir à ce sujet mes précédents billets : AJAX en voie d’être légitimé par le W3C ? et Le W3C et les interfaces riches) sans toutefois intégrer de contraintes relatives à l’accessibilité.

Le document est assez long et indigeste à lire, mais il est question des XForms et de XHTML 2.

Et si vous souhaitez approfondir le sujet, je vous recommande également cet article sur la rédaction d’une charte ergonomique pour les applications en ligne : A Framework for Web Application User Interface Design Guidelines.

Demain est un grand jour, c’est la première journée annuelle des naturistes du web : First Annual Naked Day.

Rassurez-vous, il est bien ici question de standards web et de qualité du code. Le principe est le suivant : demain (5 avril), les webmasteurs de la planète sont invités à désactiver leurs feuilles de styles CSS pour afficher une version brute de leur site (uniquement le HTML). L’objectif est de faire prendre conscience aux internautes de l’importance de la sémantique du balisage.

En gros, si vous utilisez une sémantique propre qui respecte les normes du W3C, alors votre site restera parfaitement consultable même sans feuille de styles. Par contre, si vous utilisez une sémantique exotique avec des balises détournées de leur fonction première et tout un tas d’astuces CSS alors vote site sera fortement pénalisé (la grosse honte !).

C’est en quelque sorte une journée porte ouverte où les visiteurs pourront juger de la qualité du code.

Bon, vous voilà prévenu : demain je désactive ma feuille de style. (via Gou Blog)

Visiblement ils ont mangé du lion chez Open-S ce midi à la cantine ! Non seulement ils viennent de publier un ensemble de gabarits HTML / CSS certifiés 100% accessibles, mais en plus ils se lancent dans une campagne de démystification autour de sujets qui fâchent comme les pop-up, les tableaux et javascript.

Saluons ces deux initiatives courageuses :

1. parce qu’il est toujours très délicat de publier des gabarits XHTML / CSS a une communauté de développeurs qui trouvent toujours à redire (du type : mon gabarit est plus accessible que le tien) ;
2. parce qu’il y a beaucoup de fausses idées sur l’accessibilité des mises en page par tableaux imbriqués et du javascript.

Bravo aux équipes d’Open-S pour leur engagement sur le débat de l’accessibilité. Vivement la suite !

Que faites-vous les 2 et 3 février prochain ?

Si vous n’avez rien de prévu et que vous passez par Limoges alors ne ratez surtout pas le Webdesign International Festival. Comme l’édition 2006 est placée sous le signe des dernières tendances et des innovations technologiques, seront abordés des thèmes aussi variés que l’accessibilité, les standards web (XHTML, CSS…), l’utilisabilité, Flash…

Au programme de cette manifestation :

1. Le Webjam Contest où des équipes de designeurs vont s’affronter en live pour réaliser des interfaces web à partir d’un thème imposé ;
2. Les Butterfly Awards où seront récompensés les meilleurs réalisations et créateurs web de l’année ;
3. L’Université du Webdesign qui, comme son nom ne l’indique pas, est une série de conférences sur le thème du design et de la conception web.

Limoges accueillera pour cette occasion de très grand noms du web design comme Joshua Davis ou encore Molly Holzschlag ; mais également des personnalités françaises comme Tristan Nitot, Loïc Le Meur, Amélie Boucher et même notre Elie Sloïm national.

J’ai également la chance de participer à cette manifestation et animerais deux conférences sur l’ergonomie incitative et sur les interfaces riches.

Si vous souhaitez vous inscrire ou avoir plus d’informations, je vous recommande le programme officiel : WIF 2006 (fichier PDF, 1.700 Ko).

Non ceci n’est pas une blague.

Si vous êtes séduit par le principe d’AJAX mais que le XML vous semble un peu trop complexe à manier alors je vous recommande l’AHAH (Asychronous HTML and HTTP). En gros, le principe est très simple : utiliser l’objet XMLHttpRequest pour rapatrier du contenu stocker en XHTML. Et oui, c’est ici que l’astuce réside : plutôt que de rapatrier du XML qu’il faut ensuite transformer en HTML via XSL, et bien on rapatrie directement de l’HTML.

Pour aller plus loin dans l’explication, les auteurs d’AHAH le décrive comme un REST-Enabled XHTML microformat qui serait issu de JAH (Just Asynchronous HTML). Rien de très révolutionnaire mais comme ils proposent des bibliothèques javascript toutes prêtes ça serait dommage de se priver, non ?

Tout ça me donne des idées… je me demande si je ne vais pas publier les premières spécifications de HUM-HUM (HTML and UML Metadata for Human Ubiquitus Model) voir de PIF-POUF (Portal Infrastructure Functionnality for P2P Object Unified Framework). Et vous ?

Le HTML vous connaissez ? Mais si, les pages de texte avec des images où rien ne bouge. Bon et bien le DHTML c’est la même chose mais avec des trucs qui bougent en plus.

Plus sérieusement, je vous propose de découvrir aujourd’hui un projet bien singulier : FACE est un framewok qui permet de faire des petites animations à l’écran sans avoir à utiliser Flash, sans connaître javascript et le tout dans le respect des standards web. Quelle est l’astuce ? Le recours à des propriétés des CSS ainsi qu’à des bouts de javascript le tout dans une syntaxe qui utilise le principe des noeuds :

En résumé : c’est gratuit, c’est compatible W3C, c’est relativement léger, donc : pourquoi pas ! Qui pourrait creuser un peu plus la question et nous donner un avis plus… avisé ?

Je viens de finir le dernier livre de Dan Cederholm qui parle de conception web et des standards W3C : Bulletproof Web Design. Outre le fait que ce livre se lise très bien et que tous les exemples de code sont très bien expliqués, ce qui m’a le plus marqué dans cet ouvrage est l’approche à toutes épreuves que l’auteur y explique.

Le concept est le suivant : que deviendrait la mise en page de votre site si les images ou le code CSS était désactivé ? C’est à partir de cette question que l’auteur nous explique comment concevoir un site et des mises en page qui se dégradent proprement ou qui restent lisibles si l’on double la taille du texte. D’ailleurs à ce sujet le site de l’auteur est un bon exemple : SimpleBits.com.

Conclusion : un livre que je vous recommande vivement.

Oui môsieur, GRDDL comme Gleaning Ressource Descriptions from Dialects of Languages. Pour faire simple, GRDDL est un mécanisme mis au point par le W3C qui sert à extraire les informations présentes sur une page web au format XHTML et les transformer en RDF. Pour avoir une explication plus détaillée, je vous recommande cet article : Sémantique et XHTML.

Un peu complexe tout ça, non ? Effectivement, j’avoue être un peu perdu dans tout ces formats. Néanmoins, il semble que le débat tourne autour des microformats et de RDF. Je cite l’auteur de l’article : XHTML n’est pas fait a-priori pour sémantiser l’information, mais pour la structurer. En d’autres termes, si vous souhaitez donner du sens à vos pages web, la bonne pratique consiste à utiliser des balises descriptives de metadonnées (comme le Dublin Core que j’utilise) ou à associer des éléments RDF beaucoup plus complets… mais plus lourds à implémenter. D’où l’intérêt d’une solution intermédiaire comme GRDDL. (merci à Gauthier pour le lien)

Comme le fait fort justement remarqué Denis Bourdeau, le W3C a publié la semaine dernière un premier jet de spécifications (Working Draft comme ils disent) sur les XFrames.

Et là vous me demandez : c’est quoi les XFrames ? Et là je vous répond : Et bien… heuuuu… c’est un peu comme les iFrames… sauf que en fait ce sont des fichiers XML qui sont utilisés… donc en fait c’est comme les Data Island… mais c’est bien parce que l’on n’a pas besoin de rafraîchir toute la page… un peu comme avec AJAX…

Et là vous êtes perplexes devant une telle débauche d’acronymes et termes techniques. Ceci étant dit, ces nouvelles spécifications représentent un potentiel très intéressant. Et je remercie par avance l’âme charitable qui voudra nous expliquer dans un commentaire la différence entre XFrames, iFrames et Data Island.

En tout cas je peux vous assurer qu’après la lecture de ces spécifications, vous n’allez plus regardez les cadres du même oeil car les XFrames représentent une alternatives plus que valable aux antédiluvienne Frames.