Pourquoi faut-il autant de temps pour finaliser la spécification HTML 5? [fermé]
25
Je lisais ceci et une phrase a attiré mon attention (soulignement le mien):
Ainsi, Ian Hickson, le plus grand critique de XHTML, a engendré HTML 5, une spécification pour tout-petits orientée vers l'action qui n'atteindra l'âge adulte qu'en 2022 , bien qu'une partie puisse être utilisée aujourd'hui.
Est-ce vrai? Est-ce vraiment le cycle de développement HTML 5? Pourquoi cela prend-t-il autant de temps? Qu'est-ce qui rend la tâche si difficile à réaliser qu'elle ne sera définitive que dans 11 ans?
Avez-vous déjà essayé d'amener un groupe de personnes à s'entendre sur quelque chose?
George Marian
2
@George - Aurait dû en faire une réponse.
Ben L
En passant, avez-vous vu la taille de la spécification et sa complexité?
JB King
@ben Apparemment, j'aurais dû. Je ne pensais pas que c'était assez charnu. :)
George Marian
Réponses:
19
La date mentionnée pour le processus de finalisation a été fixée si loin dans le futur parce que le processus de normalisation pour la spécification HTML a été configuré de manière à garantir une large acceptation de la spécification.
Quelques informations: il existe deux organismes de normalisation qui travaillent sur des ébauches liées à ce que nous appelons communément «HTML5»: le World Wide Web Consortium (W3C) et le Web Hypertext Application Technology Working Group (WHATWG). Avant juillet 2012, les deux groupes travaillaient (principalement) ensemble pour développer le HTML.
Le processus principal consistait à franchir une série de jalons:
Projet de travail: la spécification est en cours d'élaboration et de discussion
Dernier projet de travail (LCWD): la spécification est presque terminée et les implémenteurs ont la possibilité de soulever les dernières objections à la spécification avant qu'elle n'entre dans le processus de finalisation
Recommandation du candidat: la spécification est effectivement finalisée et sûre à utiliser pour les implémenteurs et les auteurs de contenu
Recommandation: deux implémentations indépendantes et entièrement interopérables de la spécification sont terminées
Le jalon LCWD a commencé en 2011 et la phase de recommandation des candidats devrait arriver relativement bientôt en 2014. C'était le dernier jalon, la recommandation, qui nécessitait deux implémentations complètes de la spécification, qui aurait pris plusieurs années et est la raison de la 2022 rendez-vous amoureux.
Dans ce modèle, le premier véritable jalon qui concernait les auteurs de contenu (et non les créateurs d'agent utilisateur, comme les navigateurs) était le LCWD, car la spécification devait être principalement finalisée. Une fois le LCWD terminé, HTML5 aurait atteint le jalon de la recommandation du candidat, et il aurait été une spécification finale dans tout sauf le nom: vous auriez pu le mettre en œuvre en toute impunité, comme le dernier jalon, la recommandation, l'aurait fait n'ont aucun effet sur le contenu de la norme et sont en grande partie sans intérêt pour les auteurs de contenu.
Cependant, en juillet 2012, le W3C et le WHATWG ont officialisé une scission dans la façon dont le projet HTML5 serait développé. Cette scission, qui fonctionnait depuis quelques années, crée deux "pistes" HTML différentes:
Un niveau de vie, développé par le WHATWG et simplement appelé "HTML", dans lequel la spécification n'est jamais complètement complète. Un consensus raisonnable est établi pour la norme, mais il n'est pas nécessaire de tout mettre en œuvre.
Instantanés périodiques et stables de la norme développée par le W3C en tant que spécification HTML5. Depuis septembre 2012, le W3C propose d'atteindre le jalon de recommandation sur «HTML 5.0» en 2014, avec des instantanés ponctuels tous les deux ans (par exemple, «HTML 5.1» en 2016).
En raison de l'ancien, HTML5, comme nous l'avons compris, est maintenant utilisable . Malheureusement, comme il s'agit d'un niveau de vie, son utilisation en tant qu'auteur de contenu nécessite de comprendre la mise en œuvre de chaque agent utilisateur.
Alors que Windows XP détient toujours 60 à 75% du marché et que Win7 (ou Vista) est requis pour qu'IE9 fonctionne, je ne pense pas que l'adoption en 2012 sera supérieure à 20 à 30%. Je veux dire l'adoption d'une solution qui fonctionne à peine, plutôt que quelque chose qui est prêt pour la production, comme HTML4 ou flash.
Slawek
@Slawek, quel que soit le nombre de partages que vous aimeriez croire , plus de la moitié des agents utilisateurs au moment de la recommandation du candidat auront une prise en charge raisonnable, sinon presque complète, pour HTML5.
2
Eh bien, je préfère apprendre de l'histoire plutôt que de faire référence aux prières de certains représentants de Microsoft et au marketing FUD. DOM Level1 - spécification de 1998, aucun support décent dans la version RELEASE du navigateur de Microsoft jusqu'à présent (IE9 le supportera probablement, je n'ai pas vérifié). Je ne dis pas que 75% des navigateurs ne prendront pas en charge HTML5 à cause de WindowsXP, mais 75% des utilisateurs d'IE ne peuvent pas faire fonctionner HTML5. IE Update est si pénible car il est nécessaire de changer de système d'exploitation avant de pouvoir changer de navigateur :) Je ne peux que rire de cela parce que c'est de la folie. Mieux que de parler, ils feraient fonctionner ce putain de DOM.
Slawek
2
Commentaire à un commentaire récent: lorsque nous traiterons des navigateurs Microsoft, nous devrons mourir avec des performances lentes de Mozilla. Je suis une personne très "orientée résultats". Je ne toucherais pas HTML5 (comme Canvas, SVG) dans les 3-4 prochaines années. Fondamentalement, il ne vous donne aucun profit par rapport au flash et vous devez de toute façon coder la même chose en flash afin qu'il soit compatible avec la bonne quantité de navigateurs de votre édition. Vous devez déjà faire face aux HUNDREDS incompatibilités dans IE avec aujourd'hui, plutôt simple HTML4. Je me soucie juste des "résultats" et de l'état d'aujourd'hui, pas du FUD et de l'idéologie.
Slawek
1
+1 pour le paragraphe de conclusion: "pour l'utiliser comme auteur de contenu, il faut comprendre la mise en œuvre de chaque agent utilisateur". Euh ... CAUCHEMAR !!!
L'avantage de la foule de gens qui regardent le design est que tout le groupe trouvera différents aspects auxquels le designer original n'a pas pensé. C'est un plus.
Lorsque le concepteur est une grande foule, ils ont tous des agendas différents et des choses pour animaux de compagnie qu'ils veulent intégrer dans la norme pour une raison quelconque. Parfois, les caractéristiques entrent en conflit les unes avec les autres, parfois il y a des politiques entourant les décisions, etc. Il faut beaucoup de temps pour qu'un grand groupe de personnes parvienne à un accord. C'est un inconvénient.
Pour le meilleur ou pour le pire, le W3C a choisi de développer ses normes de cette manière.
Et puis, au moment où le comité s'est finalement mis d'accord sur quelque chose, l'industrie a déjà pris son projet de spécification, en a mis en œuvre certaines parties et a étendu le reste d'une manière incompatible avec la spécification finale.
Robert Harvey
Oui, ce qui se passe lorsque vous superposez un DIV transparent sur cette toile :) Semble simple, très compliqué à faire.
Slawek
9
Parce qu'il est essentiel que ce soit juste.
Il faut du temps pour bien faire les choses - La norme HTML5, une fois définie, sera en place pendant longtemps. Elle doit être la meilleure possible et elle doit avoir raison. Cela nécessite un débat par des experts, des essais et des erreurs, la contribution des utilisateurs et des développeurs et l'analyse des statistiques
Lorsqu'une norme change, l'application de quelqu'un quelque part se casse - Les normes doivent être correctes la première fois. À chaque changement de norme, l'application de quelqu'un quelque part dans le monde rompt avec la nouvelle version. Cela nous oblige en tant que développeurs à le réparer, ce qui coûte du temps et de l'argent. Elle doit avoir raison la première fois.
L'imprécision doit être supprimée - il est facile de dire que c'est ce que fait la balise canvas lorsqu'il n'y a que la balise canvas sur la page, mais qu'en est-il lorsqu'elle se trouve à l'intérieur d'une autre balise? Qu'en est-il des combinaisons de balises? Comment devraient-ils rendre? Comment doivent-ils être rendus avec des attributs de style X définis dans des combinaisons particulières?
Longue? Il a fallu près de 8 ans à Microsoft pour que le CSS2 simple fonctionne à peine dans IE7, tandis que la prise en charge de DOM1 en javascript est toujours interrompue dans IE8. C'est spec de 1998.
C'est pourquoi vous ne verrez pas une large adoption de HTML5 dans le multimédia dans les 20 prochaines années. C'est très compliqué, inachevé, les performances sont nulles. Même des choses simples comme les Websockets sont désactivées pour des raisons de sécurité.
Certaines choses ne fonctionneront pas en tant que normes ouvertes. Faire des jeux ou MM dans un environnement qui devrait fonctionner sur un client léger et prendre en charge la dégradation complète? C'est de la folie.
EDITÉ: Oui, le premier est la surcompensation. Vous avez un plugin flash qui est le même dans tous les navigateurs et fonctionne de la même manière à chaque fois. C'est une solution simple et efficace. Une seule interface, vous effectuez le changement une fois, recompilez et alto - vous avez un plugin pour tous les navigateurs sur le marché, en utilisant une couche intermédiaire entre le navigateur et le plugin.
De l'autre, vous avez 10 navigateurs et vous souhaitez ajouter par exemple. support multimédia / film. Cela signifie que chaque entreprise devra implémenter un lecteur multimédia à partir de zéro, à côté de tout le monde veut quelque chose de différent. Apple veut H.264 pour que les propriétaires de sites Web leur versent des redevances pour le codec pour la lecture de films, Google et Mozilla veulent VP8 afin qu'ils ne soient pas affectés par les brevets d'Apple, etc.
Donc, cela finit par implémenter des choses que tout le monde veut (alors que VP8 ou H.264 feraient, pour commencer).
Donc, avant de pouvoir surmonter leurs différences, Adobe implémentera H.264 en flash, utilisez leur streaming et pile DRM déjà disponibles et ... c'est prêt. 3-4 mois et vous disposez d'une technologie fonctionnelle avec un taux d'adoption de 98%.
C'est simple, une entreprise décide, de sorte qu'ils peuvent pousser rapidement des changements massifs et n'auront pas à ajouter des «idées» de 20 autres membres de «l'organisme de normalisation». À côté de HTML5, il y a peut-être 10 à 15 ans de retard sur le flash, dans le multimédia. L'écart ne fera que s'agrandir. Dans le dernier MAX avant, vous pouviez voir le support des contrôleurs de jeu et les applications de course 3D en plein écran, fonctionnant sur flash en FPS complet, le support de l'accélération matérielle et ainsi de suite. Pendant ce temps, mozilla peut désormais lire la vidéo H.246 sans planter le navigateur, mais seulement jouer. Toute fonctionnalité supplémentaire (comme le plein écran, le streaming, l'avance rapide) est toujours manquante!
À côté, je pense que le W3C gaspille juste des ressources en essayant de faire de HTML5 une copie à moitié cuite du flash. Cela ne fonctionnera pas ... c'est comme essayer de faire en flash une copie de HTML. Ne fonctionnera pas.
+1 pour une explication assez claire de la politique impliquée.
Michael K
5
Fondamentalement, obtenir un groupe de personnes pour se mettre d'accord sur quelque chose est plutôt difficile. Sans oublier qu'il y a plusieurs problèmes à régler. Par exemple, il y a (était?) Beaucoup de débats sur le codec à utiliser pour la vidéo.
Pour le meilleur ou pour le pire, la plupart des spécifications prennent un certain temps à s'imposer.
Mark Pilgrim en parle dans son "Dive Into HTML5" ici: http://diveintohtml5.org/past.html Il semble que beaucoup de gens n'aiment pas la version du livre parce qu'elle n'est pas assez technique, mais dans cette section, la l'éditorial est assez justifié.
(Edit: je voulais juste fournir une référence pour mon commentaire sur les personnes n'aimant pas la qualité "bavarde" du livre: consultez les critiques sur amazon . J'ai personnellement aimé le lire et je l'ai trouvé informatif, donc le kilométrage peut varier. )
Une partie du problème est que la spécification ne sera pas finalisée tant qu'il n'y aura pas au moins deux implémentations majeures de la spécification - au moins deux navigateurs distincts la supportant entièrement. La spécification doit donc être suffisamment complète pour une implémentation complète, puis elle doit être réellement implémentée, puis elle peut être finalisée.
Le problème classique du poulet / œuf vient à l'esprit ici;)
tcnolan
@tnolan C'est vrai!
Grant Palin
2
Une partie du problème: je veux ogg theora dans le navigateur. Êtes-vous d'accord? Non, vous voulez H.264. Mais suis-je d'accord? Non. C'est le problème entre Google, Mozilla, Microsoft, Apple, Adobe et toutes les entreprises jouant derrière le HTML 5. Ils essaient de maximiser les revenus et d'être le monopole. Sa compétition intense. Il faut donc plus de temps pour terminer.
Réponses:
La date mentionnée pour le processus de finalisation a été fixée si loin dans le futur parce que le processus de normalisation pour la spécification HTML a été configuré de manière à garantir une large acceptation de la spécification.
Quelques informations: il existe deux organismes de normalisation qui travaillent sur des ébauches liées à ce que nous appelons communément «HTML5»: le World Wide Web Consortium (W3C) et le Web Hypertext Application Technology Working Group (WHATWG). Avant juillet 2012, les deux groupes travaillaient (principalement) ensemble pour développer le HTML.
Le processus principal consistait à franchir une série de jalons:
Le jalon LCWD a commencé en 2011 et la phase de recommandation des candidats devrait arriver relativement bientôt en 2014. C'était le dernier jalon, la recommandation, qui nécessitait deux implémentations complètes de la spécification, qui aurait pris plusieurs années et est la raison de la 2022 rendez-vous amoureux.
Dans ce modèle, le premier véritable jalon qui concernait les auteurs de contenu (et non les créateurs d'agent utilisateur, comme les navigateurs) était le LCWD, car la spécification devait être principalement finalisée. Une fois le LCWD terminé, HTML5 aurait atteint le jalon de la recommandation du candidat, et il aurait été une spécification finale dans tout sauf le nom: vous auriez pu le mettre en œuvre en toute impunité, comme le dernier jalon, la recommandation, l'aurait fait n'ont aucun effet sur le contenu de la norme et sont en grande partie sans intérêt pour les auteurs de contenu.
Cependant, en juillet 2012, le W3C et le WHATWG ont officialisé une scission dans la façon dont le projet HTML5 serait développé. Cette scission, qui fonctionnait depuis quelques années, crée deux "pistes" HTML différentes:
Un niveau de vie, développé par le WHATWG et simplement appelé "HTML", dans lequel la spécification n'est jamais complètement complète. Un consensus raisonnable est établi pour la norme, mais il n'est pas nécessaire de tout mettre en œuvre.
Instantanés périodiques et stables de la norme développée par le W3C en tant que spécification HTML5. Depuis septembre 2012, le W3C propose d'atteindre le jalon de recommandation sur «HTML 5.0» en 2014, avec des instantanés ponctuels tous les deux ans (par exemple, «HTML 5.1» en 2016).
En raison de l'ancien, HTML5, comme nous l'avons compris, est maintenant utilisable . Malheureusement, comme il s'agit d'un niveau de vie, son utilisation en tant qu'auteur de contenu nécessite de comprendre la mise en œuvre de chaque agent utilisateur.
la source
La réponse facile: Design by Committee
L'avantage de la foule de gens qui regardent le design est que tout le groupe trouvera différents aspects auxquels le designer original n'a pas pensé. C'est un plus.
Lorsque le concepteur est une grande foule, ils ont tous des agendas différents et des choses pour animaux de compagnie qu'ils veulent intégrer dans la norme pour une raison quelconque. Parfois, les caractéristiques entrent en conflit les unes avec les autres, parfois il y a des politiques entourant les décisions, etc. Il faut beaucoup de temps pour qu'un grand groupe de personnes parvienne à un accord. C'est un inconvénient.
Pour le meilleur ou pour le pire, le W3C a choisi de développer ses normes de cette manière.
la source
Parce qu'il est essentiel que ce soit juste.
Il faut du temps pour bien faire les choses - La norme HTML5, une fois définie, sera en place pendant longtemps. Elle doit être la meilleure possible et elle doit avoir raison. Cela nécessite un débat par des experts, des essais et des erreurs, la contribution des utilisateurs et des développeurs et l'analyse des statistiques
Lorsqu'une norme change, l'application de quelqu'un quelque part se casse - Les normes doivent être correctes la première fois. À chaque changement de norme, l'application de quelqu'un quelque part dans le monde rompt avec la nouvelle version. Cela nous oblige en tant que développeurs à le réparer, ce qui coûte du temps et de l'argent. Elle doit avoir raison la première fois.
L'imprécision doit être supprimée - il est facile de dire que c'est ce que fait la balise canvas lorsqu'il n'y a que la balise canvas sur la page, mais qu'en est-il lorsqu'elle se trouve à l'intérieur d'une autre balise? Qu'en est-il des combinaisons de balises? Comment devraient-ils rendre? Comment doivent-ils être rendus avec des attributs de style X définis dans des combinaisons particulières?
Bonus: jetez un œil à la spécification HTML5 dans sa forme actuelle et vous verrez ce qui s'y trouve.
la source
Longue? Il a fallu près de 8 ans à Microsoft pour que le CSS2 simple fonctionne à peine dans IE7, tandis que la prise en charge de DOM1 en javascript est toujours interrompue dans IE8. C'est spec de 1998.
C'est pourquoi vous ne verrez pas une large adoption de HTML5 dans le multimédia dans les 20 prochaines années. C'est très compliqué, inachevé, les performances sont nulles. Même des choses simples comme les Websockets sont désactivées pour des raisons de sécurité.
Certaines choses ne fonctionneront pas en tant que normes ouvertes. Faire des jeux ou MM dans un environnement qui devrait fonctionner sur un client léger et prendre en charge la dégradation complète? C'est de la folie.
EDITÉ: Oui, le premier est la surcompensation. Vous avez un plugin flash qui est le même dans tous les navigateurs et fonctionne de la même manière à chaque fois. C'est une solution simple et efficace. Une seule interface, vous effectuez le changement une fois, recompilez et alto - vous avez un plugin pour tous les navigateurs sur le marché, en utilisant une couche intermédiaire entre le navigateur et le plugin.
De l'autre, vous avez 10 navigateurs et vous souhaitez ajouter par exemple. support multimédia / film. Cela signifie que chaque entreprise devra implémenter un lecteur multimédia à partir de zéro, à côté de tout le monde veut quelque chose de différent. Apple veut H.264 pour que les propriétaires de sites Web leur versent des redevances pour le codec pour la lecture de films, Google et Mozilla veulent VP8 afin qu'ils ne soient pas affectés par les brevets d'Apple, etc.
Donc, cela finit par implémenter des choses que tout le monde veut (alors que VP8 ou H.264 feraient, pour commencer).
Donc, avant de pouvoir surmonter leurs différences, Adobe implémentera H.264 en flash, utilisez leur streaming et pile DRM déjà disponibles et ... c'est prêt. 3-4 mois et vous disposez d'une technologie fonctionnelle avec un taux d'adoption de 98%.
C'est simple, une entreprise décide, de sorte qu'ils peuvent pousser rapidement des changements massifs et n'auront pas à ajouter des «idées» de 20 autres membres de «l'organisme de normalisation». À côté de HTML5, il y a peut-être 10 à 15 ans de retard sur le flash, dans le multimédia. L'écart ne fera que s'agrandir. Dans le dernier MAX avant, vous pouviez voir le support des contrôleurs de jeu et les applications de course 3D en plein écran, fonctionnant sur flash en FPS complet, le support de l'accélération matérielle et ainsi de suite. Pendant ce temps, mozilla peut désormais lire la vidéo H.246 sans planter le navigateur, mais seulement jouer. Toute fonctionnalité supplémentaire (comme le plein écran, le streaming, l'avance rapide) est toujours manquante!
À côté, je pense que le W3C gaspille juste des ressources en essayant de faire de HTML5 une copie à moitié cuite du flash. Cela ne fonctionnera pas ... c'est comme essayer de faire en flash une copie de HTML. Ne fonctionnera pas.
la source
Fondamentalement, obtenir un groupe de personnes pour se mettre d'accord sur quelque chose est plutôt difficile. Sans oublier qu'il y a plusieurs problèmes à régler. Par exemple, il y a (était?) Beaucoup de débats sur le codec à utiliser pour la vidéo.
Pour le meilleur ou pour le pire, la plupart des spécifications prennent un certain temps à s'imposer.
la source
Mark Pilgrim en parle dans son "Dive Into HTML5" ici: http://diveintohtml5.org/past.html Il semble que beaucoup de gens n'aiment pas la version du livre parce qu'elle n'est pas assez technique, mais dans cette section, la l'éditorial est assez justifié.
(Edit: je voulais juste fournir une référence pour mon commentaire sur les personnes n'aimant pas la qualité "bavarde" du livre: consultez les critiques sur amazon . J'ai personnellement aimé le lire et je l'ai trouvé informatif, donc le kilométrage peut varier. )
la source
Une partie du problème est que la spécification ne sera pas finalisée tant qu'il n'y aura pas au moins deux implémentations majeures de la spécification - au moins deux navigateurs distincts la supportant entièrement. La spécification doit donc être suffisamment complète pour une implémentation complète, puis elle doit être réellement implémentée, puis elle peut être finalisée.
la source
Une partie du problème: je veux ogg theora dans le navigateur. Êtes-vous d'accord? Non, vous voulez H.264. Mais suis-je d'accord? Non. C'est le problème entre Google, Mozilla, Microsoft, Apple, Adobe et toutes les entreprises jouant derrière le HTML 5. Ils essaient de maximiser les revenus et d'être le monopole. Sa compétition intense. Il faut donc plus de temps pour terminer.
la source