11/04/2007 @ 00:16:24: Internet - Le WHATWG offre le HTML 5 au W3C
Le WHATWG, pour ceux qui l'ignorerait, est un consortium fondé il y a 3 ans par Apple, Mozilla et Opera dans le but de proposer une alternative au W3C, jugé trop lent et hors des contraintes du "monde réel". Dans cette optique, ils ont développé, et parfois implémenté dans leur navigateurs respectifs, une série de nouvelles fonctionnalités, dont le HTML 5 fait partie.
Alors qu'il y a peu, le W3C annonçait sa volonté de créer un nouveau groupe de réflexion pour continuer le développement du HTML, parallèlement au XHTML 2, le WHATWG vient de proposer d'offrir les spécifications du HTML 5 comme base pour ce nouveau groupe. Le WHATWG annonce même qu'il renonce aux ayant droit sur ce travail dans le cadre de cette offre.
Si le W3C venait a accepter cette offre, ce pourrait être une bonne nouvelle pour les développeurs de navigateurs tout comme pour les développeurs d'applications web. En effet, pour une fois, le processus de développement d'une spécification W3C serait réalisé en parallèle avec son implémentation sur base de mécanismes connus et déjà docummentés.
L'annonce sur la mailing list: http://lists.w3.org/Archives/Public/public-html/2007Apr/0429.html
Super nouvelle!
Peut être l'arrivée du Canvas alors
Si seulement ils pouvaient aussi penser à des ListView et TreeView dignes de ce nom
100 balles et un mars aussi tant qu'on y est ?
"...Le WHATWG vient de proposer d'offrir les spécification
S du HTML 5..."
Et pourquoi ils se contentent pas de faire évoluer le xhtml ?
Vive la multiplicité des langages...
parce que pourquoi faire simple quand on peut faire compliquer hein ?
parce que le XHTML n'est pas suivi par les developpeurs de web app
parce que le XHTML casse la compatibilite descendante
parce que le XHTML 2 n'est pas compatible avec le XHTML 1
parce que le XHTML 2 a deja plus de 2 ans de retard sur son planning
Donc vive le html qu'on peut écrire comme des porchons...
Puis pour ce que j'en ai vu, le xhtml ne casse pas des masses (pas du tout ?) la compatibilité descendante...
euh, t'as pas tout du comprendre la. Il n'est nul part question d'ecrire comme des porcs, et pour ce qui est de la compatibilite descendante, il suffit de voir que toutes les balises uniques sont incompatibles entre le html et le xhtml, plus tout ce qui est gestion des commentaires, etc...
Ben devoir écrire des balises fermantes a chaque fois c'est p-e pas plus mal...
Le xhtml force un peu les gens à mieux formuler leur littérature achteumélienne.
entièrement d'accord pour les balises fermantes par exemple.
Ben devoir écrire des balises fermantes a chaque fois c'est p-e pas plus mal...
Le xhtml force un peu les gens à mieux formuler leur littérature achteumélienne.
C'est un point de vue, mais le fait est qu'un parseur SGML est incompatible avec un parseur XML, et reciproquement. Ce qui oblige, outre toutes les gestions de tolerance d'erreur, les browser a supporter deux parseurs.
C'est un point de vue, mais le fait est qu'un parseur SGML est incompatible avec un parseur XML, et reciproquement. Ce qui oblige, outre toutes les gestions de tolerance d'erreur, les browser a supporter deux parseurs.
D'accord, mais alors autant switcher vers le langage qui laisse le moins de doutes, non ?
Ce n'est pas si simple. Si tu pars sur un langage "plus strict" ce n'est pas pour autant que les utilisateurs vont te suivre. Et si c'est pour quand meme devoir relacher la contrainte histoire de ne pas faire peter 95% des sites webs, je ne vois pas vraiment le gain. Relacher la contrainte sur un parseur d'un subset du SGML est plus simple que pour un parseur XML