Du document à l'application Web
Pour bien comprendre les évolutions d'HTML 5, il convient de remonter un peu dans l'histoire du langage. Jusqu'aux prémices de cette 5ème mouture, qui auront été déterminants dans sa structure et dans la définition de ses spécifications.
En 1997, le W3C élève enfin le HTML 4.0 au rang de recommandation, l'ultime étape au sein du consortium qui transforme une technologie en standard. En 1999, après plusieurs évolutions, plutôt mineures, HTML atteint une version 4.01, qui restera longtemps la dernière version de HTML. Les groupes de travail qui planchent sur le sujet au sein du W3C, conviennent que cette mouture a finalement atteint son but premier, au regard de l'étendue de ses fonctionnalités. Ils estiment surtout que pour aller plus loin, il faut faire évoluer le langage.
On parle alors de concevoir une nouvelle génération de HTML.
C'est partir de ce moment, que la feuille de route de HTML va croiser celle de XML (Extensible Markup langage), un autre descendant du standard SGML, dont l'objectif premier est de simplifier SGML en fournissant une méthode de description de document, à la fois simple et portable. Un tour de force qu'il réalise notamment en structurant le document par le biais d'une arborescence des données, enfermées dans des balises qui peuvent elles-mêmes être définies par l'utilisateur – on parle généralement de méta-langage. En maturation depuis 1996 dans les laboratoires de Sun Microsystems, les premières ébauches de XML sont rédigées cette même année. Avant de devenir une recommandation W3C en 1998. XML 1.0 voit ainsi le jour alors que HTML se cherche un second souffle. C'est ainsi dans ce contexte que le W3C décide que XML pourrait bien devenir le prochain langage du Web et peut-être prendre la succession de HTML.
On retrouve ainsi deux groupes de travail au W3C qui finalement planchent sur deux langages pour un canal, le Web. Oui mais voilà : ces deux langages – XML et HTML donc – sont incompatibles. Le consortium, dont rappelons-le la mission est de standardiser le Web, se voit ainsi confronté à un dilemme et décide qu'une convergence entre les deux serait profitable. Et surtout beaucoup plus cohérent pour les développeurs Web. Le W3C prend la décision de faire évoluer les spécifications HTML pour les rapprocher de XML et de les rendre compatibles : XHTML (Extensible HyperText Markup Language) était alors né. Dans sa version 1.0, XHTML devait ainsi se cantonner à reformuler HTML 4.01 pour le rendre interopérable avec XML. Dans sa mouture 1.1, le langage propose une notion de module pour le rendre plus malléable, comme l'explique les spécifications ratifiées en 2001.
Et c'est là que les affaires se compliquent. Le W3C débute les travaux autour de XHTML 2.0, un standard qui doit livrer la quintessence de la fusion XML et HTML et donner un remplaçant à HTML. Les groupes de travail se mettent en place et les spécifications murissent. Seulement voilà. Cette idée, aussi logique soit-elle, ne recueille pas le soutien de l'ensemble de la communauté, tant du côté des éditeurs de navigateurs – dont le marché commence à se durcir avec l'arrivée d'acteurs comme Mozilla –, que du côté des développeurs Web – qui s'interrogent sur le besoin de réécrire leur code en XHTML. Bref, la communauté se divise. Et le fossé se creuse.
- Sécurité et Réseaux,
- Developpement,
- html ,
- 5 ,
- web
Dites moi si je me trompe mais le HTML n'est pas plutôt une implémentation du SGML? (et non un descendant, le descendant du SGML étant XML, et XHTML une implémentation du XML).
C'est bien joli tout ça, mais tant qu'IE aura plus de 60% de part de marché et que Microsoft continuera à ignorer royalement les normes en vigueur tout cela n'est pas près de changer.
Et il ne faut pas oublier non plus qu'une grande partie des webdesigner sont à la base des graphistes qui se moquent royalement du code HTML sous-jacent quand ils créent la charte graphique d'un site.
Et comme c'est Adobe qui propose à la fois Photoshop, Dreamweaver et Flash, il n'a aucun intérêt à faciliter l'utilisation correcte de ces nouveaux standards Web au détriment de Flash...
Pour ma part, je trouve que le passage de html 4.01 au XHTML a été une excellente chose car elle oblige les développeurs à travailler proprement (en fermant toujours les tags qui ont été ouverts, et surtout en obligeant le développeur à fermer les tags dans l'ordre dans lequel ils ont été ouverts, ...).

Deplus, pour des applications web spécifiques, il est possible de définir ses propres tags (puisque c'est de l'xml) et finalement ca permet d'inclure façilement du code xhtml dans un template xml par exemple sans devoir utiliser de CDATA...
Un développeur qui connait le html, apprenait le xhtml en 30 minutes... et pour ceux qui utilisent des softs comme dreamweaver, go live, etc... il faut simplement changer un paramètre...
De coup je trouve ca dommage de porposer du HTML5 et du XHTML5 au lieu de seulement proposer seulement la version X.
C'est plus de boulot pour les concepteurs de navigateurs, on risque de se retrouver avec un mic-mac de html & xhtml (comme c'est encore bien souvent le cas à l'heure actuelle)... bref porposer 2 versions c'est pas vraiment l'idée que je me fait d'une standardisation !!!
C'est bien joli tout ça, mais tant qu'IE aura plus de 60% de part de marché et que Microsoft continuera à ignorer royalement les normes en vigueur tout cela n'est pas près de changer. Et il ne faut pas oublier non plus qu'une grande partie des webdesigner sont à la base des graphistes qui se moquent royalement du code HTML sous-jacent quand ils créent la charte graphique d'un site. Et comme c'est Adobe qui propose à la fois Photoshop, Dreamweaver et Flash, il n'a aucun intérêt à faciliter l'utilisation correcte de ces nouveaux standards Web au détriment de Flash...
Pour info IE s'améliore à chaque version concernant le suivi des normes W3C, et même les plus réfractaires saluent cet effort de la part de MS... donc mauvaise analyse.
D'autre part, quand il s'agit de standard, je suis assez amusé de voir que tous les navigateurs ont une vision "personnelle" du W3C. Tu as plein de jolis tableaux sur le web qui expliquent ça très bien. Et puis j'ajoute enfin un truc : c'est une demande du quidam que d'avoir de jolis sites avec plein de trucs qui font sapin de noël. Dans l'absolu, un site ça peut se résumer à du HTML brut, sans CSS, sans javascript ni quoi que ce soit. Pourtant, ce n'est pas, mais alors pas du tout conseillé de multiplier les truc exotiques, mais c'est pour ainsi dire la norme. Faut attirer le chaland
Article intéressant, dommage juste que le XHTML 5 n'ait pas été très expliqué.
Ben oui mais le Web ce n'est pas que du texte avec 2 videos et 2 MP3 au milieu...
C'est bien gentil le coté structuré du HTML, mais ça a un peu ses limites parfois. flash et Silverlight n'ont pas grand chose à craindre à ce niveau là. Et on peut très bien faire des choses parfaitements ergonomiques en sortant des préceptes de la structure standard made in HTML
Moi ça, ça me fait penser à une chose: Manque de vision à long terme, et aucune tentative d'anticipation sur du plus long terme.
En gros on se contente d'intégrer video et son, quelques éléments "modifiables" coté client et voilà... 15ans pour en arriver là, cool!
Si déjà on met tellement de temps à définir un standard qui se veut etre le point de départ du WEB d'aujourd'hui et de demain, on ne se contente pas de copier ce que les utilisateurs font aujourd'hui. Mais on essai d'anticiper un minimum les besoins de demains.
Ben oui mais le Web ce n'est pas que du texte avec 2 videos et 2 MP3 au milieu...C'est bien gentil le coté structuré du HTML, mais ça a un peu ses limites parfois. flash et Silverlight n'ont pas grand chose à craindre à ce niveau là. Et on peut très bien faire des choses parfaitements ergonomiques en sortant des préceptes de la structure standard made in HTMLMoi ça, ça me fait penser à une chose: Manque de vision à long terme, et aucune tentative d'anticipation sur du plus long terme. En gros on se contente d'intégrer video et son, quelques éléments "modifiables" coté client et voilà... 15ans pour en arriver là, cool!Si déjà on met tellement de temps à définir un standard qui se veut etre le point de départ du WEB d'aujourd'hui et de demain, on ne se contente pas de copier ce que les utilisateurs font aujourd'hui. Mais on essai d'anticiper un minimum les besoins de demains.
J'étais presque à vouloir te dire "totalement d'accord", sauf que:
- Je suis totalement d'accord avec ce que tu dis sur l'enrichissement du web, et surtout des possibilités offertes par flash et silverlight. Seulement, c'est aussi oublier un problème qui est, aujourd'hui encore, d'actualité: les débits. En effet, c'est joli de coller du flash à gogo, mais cela brime littéralement tous ceux qui ne vivent pas à 500m du DSLAM... Enfin bon, j'espère que cette problématique viendra, à terme, à disparaître. J'ajoute aussi un truc plutôt pénible (côté utilisateur): l'absence d'optimisation des contenus flash! C'est limite écoeurant de se prendre 3Mo dans les dents pour trois blings blings et deux conneries qui sonnent!
- Pour ce qui est de l'évolution et l'anticipation, c'est un débat difficile à mener, notamment pour des raisons élémentaires de technologie. Pourquoi? Parce que, fondamentalement, le HTML était au départ prévu pour "tout" faire en interprété. Or, dès que les technologies sont apparues (Javascript, Java, Flash et j'en passe), le HTML s'est vu affublé de balises lui permettant de "contenir" ces composants, sans pour autant réellement les gérer. C'est donc les navigateurs qui se chargent de recoller les morceaux.
A partir de là, un constat s'impose: le HTML, s'il doit se cantonner à la construction d'une armature disposant de conteneurs, sera alors appelé à très peu évoluer. A contrario, s'il devient de plus en plus riche, il sera nécessaire de repenser fondamentalement le langage, car l'interprété se prête assez mal aux contenus plus complexes. J'ajoute enfin que quiconque prétendant pouvoir voir les mutations du web simplement sur cinq ans risque à 99% de se tromper. La seule chose dont on soit sûr, c'est que nombre de machines n'auront pas changées, que nombre d'entreprises exigeront de vieux navigateurs (pour des questions de compatibilité avec l'existant), ceci bridant d'autant tout changement majeur.
Anticiper, c'est jouer les oracles. Dans les technologies, c'est pire encore, car rien n'interdit l'apparition de nouveaux concepts "révolutionnaires"... donc imprévisibles!
J'étais presque à vouloir te dire "totalement d'accord", sauf que:
- Je suis totalement d'accord avec ce que tu dis sur l'enrichissement du web, et surtout des possibilités offertes par flash et silverlight. Seulement, c'est aussi oublier un problème qui est, aujourd'hui encore, d'actualité: les débits. En effet, c'est joli de coller du flash à gogo, mais cela brime littéralement tous ceux qui ne vivent pas à 500m du DSLAM... Enfin bon, j'espère que cette problématique viendra, à terme, à disparaître. J'ajoute aussi un truc plutôt pénible (côté utilisateur): l'absence d'optimisation des contenus flash! C'est limite écoeurant de se prendre 3Mo dans les dents pour trois blings blings et deux conneries qui sonnent!
Là le problème ce n'est pas Flash ou Silverlight.; Il ets parfaitmeent possible de faire une interface avec ces deux techniques sans que l'utilisateur ai besoin d'une ligne 15Mbit/s pour y accéder. Je ne pense pas que le Flash ai attendu l'apogée du "très haut débit" dans le monde pour faire son chemin et il y a presque 10ans on voyait déjà des sites en Flash qui ne demandaient pourtant pas 15jrs de prechargement.
Apres tout un site lourd et mal optimisé ça peut se faire aussi en HTML, là le standard n'y est absolument pour rien…
(…)
Anticiper, c'est jouer les oracles. Dans les technologies, c'est pire encore, car rien n'interdit l'apparition de nouveaux concepts "révolutionnaires"... donc imprévisibles!
Je parlait surtout d'anticiper les usages, pas les technologies (en réponse à la phrase de l'article que j'ai cité). Justement il s'agit là de mettre en place les technologies qui permettront de nouveaux usages… pas l'inverse.
On peut imaginer pleins de choses quant à l'avenir d'internet, des convergences entre médias… Or là tout ce que je vois c'est un standard qui se contente de faire encore et toujours la même chose depuis 15ans: afficher du texte de manière plus ou moins structurée avec un peu de contenu au milieu. La vrai "révolution" viendra quand on sortira de cette approche purement textuelle (ce que font Flash et Silverlight, et donc ce pourquoi ils n'ont rien à craindre de HTML5 à mon sens) en ne considérant le texte que comme un élément parmi d'autres et non plus comme l'élément principal. Mais pour ça il faudra bien sur commencer par le renommer
Présenté comme ça je peux mieux comprendre tes idées, mais encore une fois je rappelle que Flash et consoeurs sont des compilés à télécharger, et qui nécessitent, quoi qu'il arrive (pour le moment) d'être récupérés dans leur intégralité pour fonctionner; A contrario, un site web avec des images manquantes peut continuer à fonctionner. Merci le code interprété!
Personnellement je ne crois guère à la révolution comme tu l'envisages, ceci simplement du fait que cela sera alors une "bête" surcharge de l'existant, et que je doute que cela apporte réellement un bénéfice aux utilisateurs. N'oublions jamais ceci: une norme n'est pour ainsi dire jamais idiote (car normaliser c'est donner de bonnes méthodes), ce sont les codeurs derrière qui sont des nases.
PS: pour les flash à préchargement pourris, prends tous ceux pour présenter les nouveaux films. La plupart sont des enclumes, et à moins d'avoir du 20Mb chez soi, tu es bon pour une à deux minutes d'attente. Pour moi le web ce n'est pas une barre de progression, ça devrait être de l'instantané!
PS2: En complément de la remarque précédente, c'est aussi pour ça que la plupart des webmails restent disponibles dans des versions ultra légères... pour qu'ils soient accessibles depuis n'importe quel navigateur sans dégueuler littéralement en utilisation de bande passante.
Ils feraient mieux de passer enfin à un format qui sépare proprement le contenu de la mise en page...
Ouaiiis, trop la classe : enfin la possibilité de coder comme un porc sans fermer les tags ouverts !!! Ah, bah non, ça c'était déjà dans le HTML 1.0 et ce, jusqu'à la 4.01... Une vraie évolution.. Enfin non, pour reprendre la propagande des souteneurs du HTML 5, un souhait des éditeurs et des développeurs
...
!
Sinon, heureusement qu'on peut continuer dans la voie du XHTML et heureusement que des navigateurs comme Firefox ou Opera signalent les erreurs de syntaxe dans ce cas (et seulement dans ce cas ; pour les ploucs du code, on ne va pas se fatiguer, hein, on affiche ce qu'on peut et tant pis pour les erreurs d'affichage et autres approximations et de rendu). Quand je pense qu'il y a encore des types qui ne comprennent pas pourquoi leur site s'affiche bien avec un navigateur et mal dans un autre (surtout s'il s'agit de Firefox, Opera ou Safari ; avec les plaignants les plus assidus, même pas besoin d'aller chercher à faire entrer IE dans la danse, de toutes façons s'ils le font c'est soit ils codent pour IE et pas pour les autres, soit l'inverse) ça me fait bien marrer
Bon sinon, on jugera sur pièces pour les nouveautés et la suppression de fait des bons vieux DIV-à-tout-faire... Dans l'immédiat, je me "contente" d'XHTML 1.1, mais avec rétropédalage HTML pour les navigateurs qui ne le prennent pas en charge nativement.
Ils feraient mieux de passer enfin à un format qui sépare proprement le contenu de la mise en page...
C'est le but de base de l'XHTML depuis sa naissance (c'est d'ailleurs le concept même de l'XML) : déléguer la mise en page à des fichiers CSS "externes". Si tu le maitrises, c'est propre. Mais rien n'a jamais empêché qui que ce soit d'intégrer du code CSS dans le code HTML via tags et les attributs dédiés. Idem pour le JavaScript. Si c'est bien fait, ça passe, sinon, c'est vite une porcherie.
C'est clair: le principe de CSS permet en outre d'épurer les formulaires en n'ayant qu'une seule et unique mise en page. A partir de là... si les développeurs sont (comme d'habitude hélas) des gorets, c'est vite un carnage, d'autant que l'interprétation de ces CSS est hyper tributaire des navigateurs.
Pour les sceptiques un petit exemple: vous avez déjà constaté qu'un site était bancal sur un navigateur, et pas sur un autre. Potentiellement, "merci" le javascript. Vous avez aussi constaté des mises en page en vrac, voire des textes allant se loger derrière des zones "blanches". "Merci" l'interprétation des CSS...
Avec la description ici faite de ce futur standard, je n'y vois rien d'excitant. J'en vois pas mal qui se plaigne de flash ici, arguant que c'est lourd et déroutant. Pour votre gouverne, si un site en flash est lourd et déroutant, c'est pas la faute a flash mais à son auteur. Il m'arrive a moi aussi d'attendre bêtement qu'une page se charge (sans barre de progression) pour finalement me retrouver devant un site de m#### ou il me faut 15 minute pour trouver une info élémentaire. Et tout ca en HTML. Faut arrêter de se plaindre des outils quand c'est leur manipulateurs qui sont en cause.
Mais je le fais pas, parce que je respecte les internautes et j'aime le travail propre.

Et pour les motivés qui prétendent que flash c'est pas top parce que c'est pas du web instantané, c'est pas l'html5 qui va y changer grand chose a partir du moment ou il faudra lire une vidéo ou une musique... Je développe en Flash, alors c'est sur je pourrais faire le cochon, ne rien optimiser, importer des images 10x trop grandes dans ma librairie, et publier un site a moitié débugger
Et une dernière chose, pour ceux qui se plaignent du poids, la plupart des mes sites, pèsent entre 100 et 500 ko, habillage compris. Pour ce prix la on a de belles fontes, de belles couleurs et de belles animations...
Alors maintenant c'est sur, le même contenu en html pèsera peut être entre 100 et 200ko, mais PUTAIN, QUEL ENNUI