Bonjour,

Dans son dernier article Future of the Web, a must-read (en anglais) Daniel Glazman annonce la publication d'un document présentant une prise de position commune de Mozilla Foundation et Opera Software à l'intention du W3C Workshop on Web Applications and Compound Documents :
Position Paper for the W3C Workshop on Web Applications and Compound Documents

Ce document met particulièrement l'accent sur l'importance de la compatibilité ascendante avec les versions HTML anciennes, sur les problèmes que provoquerait le XHTML 2.0 et sur le rôle charnière du HTML 4.01.

Personnellement je trouve cette prise de position très grave. Autant je trouve que faire actuellement du Web sans garder la compatibilité MSIE est stupide, autant là disent dès les premières lignes que faire un nouveau schéma qui n'est pas directement compatible avec un navigateur qui a déjà plusieurs années est mauvais.
Si on ne peut pas imaginer pour le futur des formats qui ne passent pas actuellement sur MSIE on ne fera jamais rien. Ou plutot on peut tout de suite retirer le W3C et déléguer la création des formats à MSIE, parce que ça revient à lui donner un pouvoir de véto sur tout ce qu'il se fait, dre que quelque chose ne peut exister que si MSIE l'a fait auparavant.
Ne pourrait-on pas imaginer enfin un format en cassant la compatibilité ? le XHTML1 n'est même pas encore d'actualité (on en est encore globalement au HTML4) et si on commence aujourd'hui un format refait correctement il ne sera de toutes façons pas d'actualité avant 3 ans (en comptant la rédaction) alors pourquoi tout baser sur les fonctionnalités de MSIE6 (et pourquoi pas sur Mozilla tiens ?) qu'on trouve déjà dépassé actuellement.


Là ils sont en train de demander explicitement un retour à une tolérance aux erreurs. C'est un choix compréhensible, mais contestable.
Par contre comme c'est marqué aussi ils demandent un modèle de gestion d'erreur différent de celui de XML. Alors ça veut dire que soit on jette les formats basés sur XML soit on s'amuse à autoriser du XML qui sera incompatible avec les specs XML, donc potentiellement impossible à interpréter ou faire passer dans les chaines XML existantes et conformes.
Dans les deux cas ça me parait tuer complètement le principe même de XML (une grammaire unique qui sert partout de la même façons pour permettre une compatibilité simple de la grammaire).

Ces deux points sont pour moi un échec complet et un désastre pour l'avenir : on parle sans retenue de créer des XML incompatibles et de ne rien faire qui ne passe pas sur un vieux navigateur connu pour ne pas être à jour au niveau des fonctionnalités actuelles. Chouette, on empeche la création tout en détruisant ce qui existe déjà. Ils ont fumé quoi ?

Sinon dans la suite ils parlent d'applications Web et j'ai l'impression de ne pas retrouver mon HTML. Le HTML est por moi adapté à la description de documents. Pour faire des applications il y a XFORMS, XBL et plein d'autres choses qui peuvent servir de base à un format applicatif, pas besoin de pourrir XHTML.

Et là je ne parle même pas de leur demande de limiter les espaces de nom, ce qui revient grosso modo à revenir sur le concept de sous formats XML qui se mixent entre eux pour apporter des fonctionnalités élémentaires de façon modulaire. (je peux comprendre mais c'est AMHA pas la bonne direction pour l'avenir)

J'ai l'impression que dans l'ensemble ils sont simplement en train de nous pourri XML pour revenir sur quelque chose de plus proche de SGML. Je n'ai rien contre l'idée qu'ils fassent un truc à eux mais qu'ils ne viennent pas pourrir XML avec un truc pseudo compatible qui ne le sera pas (erreurs tolérées, pas d'espace de nom, etc.)


Je sens que je vais faire un article réponse complet tellement ça me semble idiot.

Article très attendu.

C'est en cours, j'ai un premier draft mais j'aimerai bien quelques relecteurs pour faire des commentaires sur la forme et publier quelque chose de correct (avec un peu de chances ça peut être utile donc j'aimerai que ce soit clean).

Si ça intéresse du monde il suffit de me bipper sur ganfset @ dreams4net.com

(Je garde ce post sous le coude)

Bonjour,

En cours de rédaction, un bon résumé de la situation par Benoit (administrateur du forum Geckozone) sur le wiki du projet GeckOzone.

zut, j'ai pas fini mon article, j'avais oublié, bon, je m'y remet.

Non seulement je te bippe sur l'intérêt, mais je t'offre en plus un plateforme pour le diffuser si tu veux.

Daniel Glazman publie un premier billet sur la question, en anglais, mais particulièrement instructif (j'ai vraiment l'impression de commencer à mieux comprendre les enjeux, là )
Voir : Future of HTML and the Web, part 1
Je me suis risqué à résumer (en français) les points qui m'ont paru saillants dans Une de mes notes de lectures

Eric : je n'ai pas encore fait de retour sur ton projet d'article... faute d'avoir encore tout compris Mais en tous cas, tu auras au moins une relecture typo et une critique de "consommateur moyen qui a du mal à comprendre", si ça peut servir...

Ça me va très bien, c'est au contraire des choses que j'attend. Si toi tu ne comprend pas c'est que je me suis mal exprimé et qu'il me faudra reprendre certaines parties.

Normalement je ne touche plus à mon article qui sera publié heu... bientôt

Si vous faites un lien vers le wiki (comme Laurent Denis l'a déjà fait), avertissez-moi si vous voulez que je vous prévienne quand il reçoit une URL définitive.

Moi, moi, m'sieur !
Je veux bien être prévenu pour mettre à jour mon billet

Au passage : re-bravo pour l'article.

"up"

L'article est enfin en ligne ici : http://www.geckozone.org/articles/37

C'est bien beau toutes ces histoires mais moi qui me tue à rendre mes sites conformes au XHTML Strict sans même connaitre le XML, je ne comprend pas vraiment le débat.
Puisque visiblement Le XHTML assure la compatibilité avec le XML et est compatible avec les navigateurs, pourquoi ne pas s'arreter là étant donné que l'interopérabilité des pages et assuré et que donc ces même navigateurs continuent bon gré mal gré de lire les sites un peu ancien.

Effectivement, il n'y a pas de difficultés (majeures) pour faire des pages web, mais les problèmes apparaissent lorsqu'il s'agit de réaliser des applications web avec lesquelles les utilisateurs peuvent interagir.

Le premier endroit où se passe cette interaction, ce sont les formulaires. D'où l'idée du WHATwg de développer une première spécification permettant d'étendre les champs de formulaires HTML en permettant de passer moins souvent par le serveur. Les autres idées sont du même tonneau (meilleure gestion des contrôles comme les boutons et les évènements).