La raison pour laquelle le World Wide Web Consortium (W3C) a récemment annoncé deux spécifications HTML 5 est le résultat d'une approche différente des problèmes et des échecs auxquels le W3C a dû faire face dans le passé. Le W3C prévoit de s'éloigner de la méthode « évier de cuisine » qu'il qualifie de monolithique et qui a consisté surtout à accumuler des fonctionnalités. Pour dépasser cette méthode, le Consortium veut s'appuyer davantage sur la modularité pour éviter justement les échecs et les retards. « La méthodologie monolithique actuelle, tente de combiner les travaux des groupes Decision Policy (il est chargé de traiter toutes les demandes de Dernier Appel), Accessibility A11y Task Force (il s'emploie à ce que les spécifications du HTML5 prennent en compte les besoins des personnes avec un handicap) plus le processus d'Objection Formelle, a conduit à un nombre important d'objections et aux difficultés actuelles rencontrées pour parvenir à un consensus », indique le document du Worldwide Web Consortium.

A l'origine, le HTML5 comportait beaucoup de portions qui ont été transformées dans leurs propres spécifications, y compris Web Storage, les Web Workers et le Protocole WebSocket. Cette approche va permettre au W3C de déplacer les éléments instables dans la spécification de code HTML 5.1, limitant ainsi le contenu du HTML5. Ainsi, le W3C va pouvoir se concentrer à rendre les caractéristiques actuelles du HTML5 interopérables entre les navigateurs et les stabiliser - ce sur quoi les équipes du Consortium ont travaillé depuis un certain temps. « Le fractionnement des spécifications particulières de ces technologies va permettre aux communautés respectives qui en ont la charge d'avancer et de mettre en oeuvre des approches de développement plus productives qui pourraient éventuellement rassembler un plus large consensus », fait encore valoir le Worldwide Web Consortium.

Le fait de répartir les éléments initialement prévus dans le HTML 5.0 entre une version HTML 5.0 et une version HTML 5.1, va considérablement recentrer l'attention sur les problèmes et les bogues qu'il faut résoudre à échéance du HTML 5.0 :

Pour les bogues: créer un nouveau composant Bugzilla pour aboutir à une version stable des spécifications d'HTML 5.0 /Candidate Recommandation (CR), et ne traiter et n'inclure dans cette composante que les bogues en rapport avec les questions d'interopérabilité ou ceux pouvant être résolus sans modifier substantiellement la spécification.

Pour les problèmes: en premier lieu, il faut que le texte descriptif de la spécification telle qu'elle se présente actuellement soit publié sous forme d'extension de spécifications. Ensuite, seulement quand le texte collera aux critères de sortie pour une CR, il faudra envisager d'inclure le résultat dans la spécification de base. Pour éviter toute confusion inutile, il faudra abandonner toute indication explicite faisant valoir que l'extension donnée est obsolète dès lors que cette spécification existe et a été publiée en tant que première version de travail public ou First Public Working Draft (FPWD). Les questions concernant les problèmes d'interopérabilité seront examinées dans le cadre du calendrier prévu pour le HTML 5.0. Toutes les autres questions seront prises en compte selon l'échéancier défini pour le code HTML 5.1. Au besoin, le code qui fait débat ou le code instable sera déplacé dans l'extension de spécifications.

Le document du W3C comporte ensuite une liste détaillée des propositions, point par point.

- Vérifier auprès de ceux qui sont à l'origine des 11 objections formelles actuelles s'ils maintiennent ou non leurs objections.

- Clore les objections qu'il est possible de clore, et envoyer celles qui restent pour examen immédiat au Directeur de la W3C Team. Nous invitons le Directeur à privilégier la modularité à chaque fois que cela s'avère possible.

- Une fois que ces objections sont traitées, valider immédiatement le CR sur HTML 5.0.

- Il est probable que le Groupe de travail apportera des changements de fond à ce document après examen de ces recommandations en vue de la libération d'une CR. Par conséquent, en conformité avec le processus du W3C, nous ferons brièvement un dernier appel ou Last Call Working Draft avant de demander le passage aux Recommandations Proposées ou Proposed Recommendation.

- Laisser les spécifications avancer à leur propre rythme. Par exemple : HTML/XHTML Compatibility Authoring Guidelines, le contexte 2D de l'élément Canvas HTML, et HTML Microdata.

Si son plan est approuvé, le W3C estime que le HTML5 devrait atteindre son statut de Candidate Recommandation, c'est-à-dire un pas de plus de plus vers la standardisation, au cours du dernier trimestre de cette année.

Â