Conférence 2. BasesHTML. PossibilitésHTML5.

1. Historique du développement du langage HTML

En 1989, Tim Berners-Lee a proposé à la direction du Centre international des hautes énergies (CERN) un projet de système hypertexte distribué, qu'il a appelé Mondial Web (WWW), World Wide Web. L'idée originale du système était d'utiliser un système de navigation hypertexte pour combiner toutes les nombreuses ressources d'information du CERN en un seul système d'information.

L'un des composants de la technologie permettant de créer un système hypertexte distribué sur le World Wide Web était le langage de balisage hypertexte. HTML (HyperTexteBalisageLangue- langue balisage hypertexte documents), développé par Tim Berners-Lee sur la base du langage de balisage généralisé standard (SGML). Daniel W. Connolly a écrit une définition de type de document à cet effet - une description formelle de la syntaxe HTML en termes SGML.

Les développeurs HTML ont pu résoudre deux problèmes :

fournir aux concepteurs de bases de données hypertextes un moyen simple de créer des documents ;

rendre cet outil suffisamment puissant pour refléter la compréhension actuelle de l'interface utilisateur des bases de données hypertextes.

Le premier problème a été résolu en choisissant un modèle de balisage pour la description du document. Ce modèle est largement utilisé dans les systèmes de préparation de documents pour l'impression.

Le langage HTML permet de baliser un document électronique affiché à l'écran avec un niveau de conception d'impression ; le document résultant peut contenir une grande variété d'étiquettes, d'illustrations, de fragments audio et vidéo, etc. Le langage comprend des outils développés pour créer différents niveaux de titres, des sélections de polices, diverses listes, tableaux et bien plus encore.

Le deuxième point important qui a influencé le sort du HTML était qu'un fichier texte ordinaire a été choisi comme base.

Ainsi, une base de données hypertexte dans le concept WWW est une collection fichiers texte, balisé en langage HTML, qui définit la forme de présentation de l'information (balisage) et la structure des connexions entre ces fichiers et d'autres ressources d'information (liens hypertextes). Les liens hypertextes, établissant des liens entre des documents texte, ont progressivement commencé à fédérer une grande variété de ressources d'information, notamment sonores et vidéo ; En conséquence, un nouveau concept est apparu : l'hypermédia.

Cette approche présuppose la présence d'un autre composant de la technologie : un interprète de langage. Sur le World Wide Web, les fonctions d'interprétation sont réparties entre le serveur Web de base de données hypertexte et l'interface utilisateur. Le serveur, en plus d'accéder aux documents et de traiter les liens hypertextes, assure le prétraitement des documents, tandis que l'interface utilisateur interprète les constructions linguistiques liées à la présentation des informations.

Versions

HTML 4.01 (changements plus importants qu'il n'y paraît à première vue) - 24 décembre 1999 ;

ISO/IEC 15445:2000 (appelé ISO HTML, basé sur HTML 4.01 Strict) – 15 mai 2000.

HTML 5 - en développement. La fin du développement est prévue pour 2014.

Il n'existe pas de spécification HTML 1.0 officielle. Avant 1995, il existait de nombreuses normes HTML non officielles. Pour rendre la version standard différente d'eux, on lui a immédiatement attribué un deuxième numéro.

La version 3 a été proposée par le Consortium World Wide Web(W3C) en mars 1995 et a fourni de nombreuses nouvelles fonctionnalités, telles que la création de tableaux, l'habillage de texte autour d'images et l'affichage de formules mathématiques complexes, ainsi que la prise en charge du format GIF. Même si ce standard était compatible avec la deuxième version, sa mise en œuvre était difficile pour les navigateurs de l’époque. La version 3.1 n'a jamais été officiellement proposée, et la version suivante du standard HTML était la 3.2, qui omettait de nombreuses innovations de la version 3.0 mais ajoutait des éléments non standard pris en charge par les navigateurs Netscape Navigator et Mosaic.

HTML 4.0 a vu un certain nettoyage de la norme. De nombreux éléments ont été marqués comme obsolètes et obsolètes. obsolète). En particulier, l'élément font, utilisé pour modifier les propriétés de la police, a été marqué comme obsolète (les feuilles de style CSS sont recommandées à la place).

En 1998, le World Wide Web Consortium a commencé à travailler sur un nouveau langage de balisage basé sur HTML 4 mais cohérent avec la syntaxe XML. Par la suite, le nouveau langage a été nommé XHTML. La première version de XHTML 1.0 a été approuvée en tant que recommandation du World Wide Web Consortium le 26 janvier 2000.

La version prévue de XHTML 2.0 était destinée à rompre la compatibilité avec les anciennes versions de HTML et XHTML, mais le 2 juillet 2009, le World Wide Web Consortium a annoncé que le groupe de travail XHTML2 expirerait fin 2009. Ainsi, tout développement ultérieur du standard XHTML 2.0 a été suspendu.

Le World Wide Web Consortium développe actuellement la version HTML 5. Un projet de spécification de langage est apparu sur Internet le 20 novembre 2007.

Contenu : 1. Introduction au langage HTML Introduction au langage HTML. 2. Histoire Création HTML.Historique de la création du HTML. 3. Concepts de base du langage HTMLConcepts de base du langage HTML 4. Structure d'un document Web.Structure d'un document Web. 5. Insérer un commentaire Insérer un commentaire 6. Exemple de document HTML Exemple de document HTML. 7. Balises de formatage du texte. Balises de formatage du texte. 8. Balises pour contrôler l'apparence d'une page Web Balises pour contrôler l'apparence d'une page Web 9. Balise Balise 10. Couleur de fond et de texte Couleur de fond et de texte 11. Listes Listes 12. Page Web avec objets graphiques Page Web avec graphique objets.

Introduction au langage HTML HTML est un langage de balisage de documents dans l'environnement WEB. Ce que vous voyez lorsque vous consultez une page sur Internet est l'interprétation du texte HTML par votre navigateur. Pour que le navigateur affiche correctement le formatage par exemple du texte, c'est-à-dire divisé en paragraphes, citations surlignées, titres, listes, etc. il faut lui dire d'une manière ou d'une autre qu'il s'agit d'un titre, et que ceci est un paragraphe, etc. C'est exactement ce que fait le langage HTML. Pour voir les codes HTML d'une page sur Internet, faites un clic droit sur la page et sélectionnez afficher la source (ou " Vue HTML code"). Sommaire

Historique de la création du HTML (Hyper Text Markup Language) Quelques dates : 1945 : 1945 : le scientifique américain, conseiller scientifique du président Vannevar Bush exprime l'idée de l'hypertexte année : 1968 : Douglas Engelbart démontre le travail des liens hypertextes dans le je les ai créés en traitement de texte. Contenu

Années 1960 : 1960 : les employés d'IBM créent le langage GML (General Markup Language), destiné à être utilisé sur les ordinateurs de la famille IBM. Le langage GML a ensuite été étendu et, dans les années 80, il a été normalisé par l'ISO (Organisation internationale de normalisation). Ce mode de balisage puissant et polyvalent, appelé SGML (Standard General Markup Langugage), était utilisé par le Département militaire américain pour la documentation technique dans les années 1980 : le physicien Tim Berners-Lee, employé du CERN (Centre européen pour la recherche nucléaire), dans The La base du langage développé était le langage SGML et les techniques de travail avec l'hypertexte, c'est pourquoi le nom du langage qu'il a créé - HTML - est connecté. Le nouveau langage utilisait les constructions de base de SGML pour décrire des documents et des liens hypertextes. Quelques dates : Sommaire

Le terme « hypertexte » a été inventé pour la première fois par Ted Nelson en 1969. Hypertexte – document électronique, contenant des liens vers d'autres documents. Contenu

Structure d'un document Web. ..., L'intégralité du contenu du fichier de la page Internet est contenue dans un conteneur... indiquant au navigateur que ce texte est un document HTML et peut contenir des balises que le navigateur doit identifier, reconnaître et interpréter. Une page Internet typique (HEAD)(BODY) Une page Internet typique se compose de deux parties : un en-tête (HEAD) et un corps (BODY). Contenu

Structure d'un document Web. début du conteneur de document HTML début du conteneur d'en-tête conteneur de début de ligne - titre de la page ... ligne de titre de la page conteneur de fin de ligne - titre de la page conteneur de fin de titre début du conteneur de corps de page ... corps (tout le contenu) de la fin de la page du conteneur du corps de la page fin du conteneur du document HTML Cette structure de base dans sa forme la plus simple peut être clairement illustrée comme suit : Contenu

Structure d'un document Web. La chaîne de titre que vous spécifiez sera affichée dans le titre de la fenêtre du navigateur lorsque cette page y sera consultée, ainsi que (après la publication de la page sur Internet) dans les listes fournies par les serveurs de recherche. Contenu

Balises de formatage du texte. affiche le texte en caractères gras. affiche le texte en italique affiche le texte en police soulignée. et affichez le texte traversé par une ligne horizontale. affiche le texte en police plus grande taille qu'une partie de texte sans étiquette affiche le texte inclus dans une taille de police plus petite que le reste du texte : déplace le texte en dessous du niveau de la ligne et l'affiche dans une taille de police plus petite. Recommandé pour l'impression d'index mathématiques : déplace le texte au-dessus du niveau de la ligne et l'affiche dans une taille de police plus petite. Cette balise peut être utilisée pour spécifier les puissances des nombres : Contenu

Balise Une balise vous permet de modifier la police utilisée par le navigateur pour afficher une page Web. Une balise peut avoir les paramètres suivants : FACE – spécifie le nom de la police dans laquelle le texte sera affiché. TAILLE – définit la taille de la police unités conventionnelles de 1 (le plus petit) à 7 (le plus grand). Il est généralement admis qu'une taille de police normale correspond à une valeur de 3. COULEUR – définit la couleur de la police, qui peut être spécifiée à l'aide de noms standard ou d'un ensemble de chiffres hexadécimaux. Contenu

Couleur du fond et du texte Nous savons déjà comment changer la couleur du texte, mais pour ce faire, nous devions l'encadrer balises de police, et ce n'est pas toujours pratique. Parfois, il est préférable de définir la couleur du texte pour l’ensemble du document. Vous pouvez également définir image de fond. Voici les attributs requis : BACKGROUND – définit l'image pour « remplir » l'arrière-plan. La valeur est spécifiée sous la forme d'une URL complète ou du nom d'un fichier avec une image au format GIF ou JPG (nous y reviendrons plus tard). BGCOLOR – définit la couleur d'arrière-plan du document. TEXTE – définit la couleur du texte dans le document. Tous sont enregistrés pour l’élément BODY. Les valeurs de couleur sont spécifiées soit par une valeur hexadécimale RVB, soit par l'une des 16 couleurs de base. Contenu

Couleur d'arrière-plan et de texte Exemple : Ce texte sera rouge car nous avons modifié la couleur du texte dans la balise BODY et désormais tout le texte de la page sera rouge par défaut. Ce paragraphe aura du texte vert car nous l'avons enveloppé dans des balises de police et avons donné lui la couleur appropriée Maintenant, le texte sera à nouveau rouge Contenu

Listes Chaque élément de liste commence par une balise. Le langage HTML fournit un ensemble spécial de balises pour présenter des informations sous la forme de listes des types suivants : À puces (); Numéroté(/); liste de définitions (/). Terme. Sa définition... Sommaire

Page Web avec des objets graphiques. Les images font partie intégrante de tout site Web sur Internet. Ils sont utilisés partout, alors voyons de quoi il s'agit. Il existe trois types de fichiers image qui peuvent être insérés dans vos pages : GIF (Graphics Interchange Format) JPG/JPEG (Joint Photographic Experts Group) PNG (Portable Network Graphics)

Page Web avec des objets graphiques. Quelques mots sur les formats : GIF - n'utilise que 256 couleurs et, par conséquent, convient mieux aux dessins avec un petit nombre de nuances. Ce format prend en charge la transparence des images. JPEG est un format d'image qui utilise jusqu'à un million de couleurs. Généralement utilisé pour les photographies et les graphiques de haute qualité (avec un grand nombre de nuances). PNG est un format relativement nouveau. Il surpasse le JPEG et le GIF à bien des égards : des millions de couleurs et une compression efficace. Prend également en charge la transparence. Le format dans lequel prendre les images dépend de vous, mais essayez d'obtenir une qualité maximale lorsque taille minimale. Contenu

Page Web avec des objets graphiques. Pour placer des images dans des documents HTML, utilisez une balise dont le paramètre SRC spécifie l'emplacement du fichier image. Par exemple : - l'image située dans le fichier image.gif sera placée dans le document HTML ; - une image sera placée dans le document HTML, située dans le fichier Tile.bmp, qui se trouve dans le dossier Images, situé dans le même dossier que le document HTML. Contenu

Page Web avec des objets graphiques. Lorsque vous incluez un graphique dans un document, vous pouvez spécifier son emplacement par rapport au texte ou à d'autres éléments de la page. La méthode d'alignement de l'image est spécifiée par la valeur du paramètre ALIGN de ​​la balise. Voici quelques valeurs possibles pour ce paramètre : GAUCHE Ajuste l'image à la marge gauche de la fenêtre. Le texte s'enroule autour de l'image sur le côté droit. DROITE L'image est pressée contre la marge droite de la fenêtre. Le texte s'enroule autour de l'image sur le côté gauche. Contenu

Traduction : Vlad Merjevitch

Je suis récemment tombé sur une citation de développeurs de Mozilla sur les tensions entourant le développement de normes :

Les implémentations et les spécifications doivent s'enchaîner dans une danse gracieuse. Vous ne voulez pas que la mise en œuvre ait lieu avant que la spécification ne soit terminée, car les gens deviendront dépendants des détails de la mise en œuvre et cela freinera la spécification. Cependant, vous ne voulez pas non plus que la spécification soit terminée avant la mise en œuvre, les auteurs commenceront alors à expérimenter la mise en œuvre lorsque vous aurez besoin de commentaires. Il y a ici une tension inévitable, mais nous devons simplement hésiter dans nos choix jusqu’à la fin.

Gardez cette citation à l’esprit et laissez-moi vous expliquer l’essor du HTML5.

Types MIME

Ce livre concerne HTML5, pas les versions précédentes de HTML ni les versions de XHTML. Mais pour comprendre l'histoire du HTML5 et ses motivations, vous devez d'abord en comprendre quelques-uns. points techniques. En particulier, les types MIME.

Chaque fois que votre navigateur demande une page, le serveur Web envoie des « en-têtes » avant d'envoyer le code réel de la page. Ces en-têtes sont généralement invisibles, bien qu'il existe des outils de développement Web qui les rendent visibles si vous êtes intéressé. Les en-têtes sont importants car ils indiquent à votre navigateur comment interpréter le balisage de la page. L'en-tête le plus important s'appelle Content-Type et ressemble à ceci :

Type de contenu : texte/html

"text/html" est appelé le "type de contenu" ou "type MIME" de la page. Cet en-tête définit uniquement ce qu'est réellement la ressource et comment l'afficher. Les images ont leurs propres types MIME (image/jpeg pour JPEG, image/png pour PNG, etc.). Les fichiers JavaScript ont leur propre type MIME. CSS a son propre type MIME. Tous ont leur propre type MIME. Internet fonctionne sur des types MIME.

Bien sûr, en réalité, tout est beaucoup plus compliqué. La première génération de serveurs web (je parle des serveurs web depuis 1993) n'envoyait pas l'en-tête Content-Type car il n'existait pas (il n'a été inventé qu'en 1994). Pour des raisons de compatibilité, en ramenant les dates à 1993, certaines navigateurs populaires ignorer les en-têtes Content-Type dans certaines circonstances (c'est ce qu'on appelle le « reniflage de contenu »). Mais, en règle générale, tout ce que vous avez consulté sur le Web - pages HTML, images, scripts, vidéos, PDF, etc. - vous a été présenté avec un type MIME spécifique dans l'en-tête Content-Type.

Mettez votre chapeau de côté pour l'instant. Nous y reviendrons plus tard.

Une longue digression sur la façon dont les normes sont élaborées

Pourquoi utilisons-nous l'élément ? Ce n’est pas une question que l’on entend tous les jours. De toute évidence, quelqu'un l'a créé. Ces choses n’apparaissent pas de nulle part. Chaque élément, chaque attribut, chaque fonctionnalité HTML que vous avez utilisée - quelqu'un les a créés, a décidé de leur fonctionnement et a tout écrit. Ces gens ne sont pas des dieux et ils ne sont pas parfaits. Ce sont des gens ordinaires. Personnes intelligentes, bien sûr. Mais juste des gens.

L’un des avantages des standards open source est que vous pouvez remonter le temps et répondre à différentes questions. Les discussions ont lieu via une liste de diffusion, qui est généralement archivée et accessible au public. J'ai donc décidé de faire une petite "archéologie postale" pour tenter de répondre à la question "Pourquoi utilise-t-on l'élément ?. Je dois revenir à l'époque où il y avait une organisation appelée le World Wide Web Consortium (W3C). Je reviens aux débuts du Web, à l'époque où l'on pouvait compter le nombre de serveurs Web sur deux mains et peut-être sur une paire d'orteils.

Il y a un certain nombre de fautes de frappe dans les citations suivantes. J'ai décidé de les laisser intacts pour des raisons d'exactitude historique.

J'aimerais suggérer une nouvelle balise HTML supplémentaire :

Argument obligatoire SRC="url"

Il s'agit du nom du fichier bitmap ou graphique du navigateur qui tente de l'extraire sur le Web et de l'interpréter comme une image, qui doit être incluse dans le texte lors de la création de la balise.

(Il n'y a pas de balise de fermeture ici, c'est juste une seule balise.)

Les navigateurs doivent être flexibles dans les formats graphiques qu'ils prennent en charge. Xbm et Xpm sont par exemple bien pris en charge. Si le navigateur ne peut pas interpréter ce format, il peut faire ce qu'il veut (X Mosaic affichera par défaut un bitmap comme espace réservé).

Cela nécessitera des fonctionnalités pour X Mosaic, cela fonctionne pour nous et nous l'avons au moins utilisé en interne. Je suis bien sûr ouvert aux suggestions sur la façon dont cela devrait être géré en HTML, si vous avez une meilleure idée que celle suggérée, faites-le moi savoir. Je comprends que j'ai vaguement écrit sur les formats d'image, mais je ne vois pas d'autre alternative que de simplement dire "laissez le navigateur faire ce qu'il peut" et attendez. solution parfaite(MIME, un jour, peut-être).

J'ai quelque chose de similaire dans Midas 2.0 (utilisé ici au SLAC et dont la publication est prévue cette semaine), sauf que les noms sont tous différents et qu'il y a un argument supplémentaire NAME="name". Elle a presque exactement les mêmes fonctionnalités que la balise IMG que vous proposez, par exemple.

L'idée derrière le paramètre name permettrait au navigateur d'installer des images « intégrées ». Si le nom correspond à l'image "intégrée", il est utilisé au lieu d'aller chercher l'image. Le nom peut également servir d'indice aux navigateurs en "mode ligne" pour mettre un caractère à la place de l'image.

Je ne me souciais pas beaucoup des paramètres ou des noms de balises, mais il serait logique d'utiliser les mêmes choses. Je ne me soucie pas beaucoup des abréviations, alors pourquoi pas IMAGE= et SOURCE=. Je préfère toujours ICON car il est plus simple qu'IMAGE et devrait être petit, mais peut-être que ICON est un mot surchargé ?

Midas est un autre des premiers navigateurs, un contemporain de X Mosaic. Il est multiplateforme et fonctionne sous Unix et VMS. SLAC fait référence au Stanford Linear Accelerator Center, aujourd'hui le SLAC National Accelerator Laboratory, qui exploitait le premier serveur Web américain (en fait le premier serveur Web en dehors de l'Europe). Lorsque Tony a écrit cet article, le SLAC était le plus ancien du Web, ayant hébergé cinq pages sur son serveur Web pendant 441 jours.

Tony continue :

Pendant que nous parlons de nouvelles balises, j'ai une autre idée, une balise quelque peu similaire que j'aimerais prendre en charge dans Midas 2.0. En gros comme ça :

L'idée est que le deuxième document est inséré dans le premier document à l'emplacement où apparaît cette balise. En principe, ledit document peut être n'importe quoi, mais l'objectif principal est de permettre l'intégration d'images (dans ce cas de taille arbitraire) dans des documents. Encore une fois, l’idée est qu’avec l’avènement de HTTP2, les formats des documents inclus seront discutés séparément.

Quelques heures après que Tony ait envoyé le message, Tim Berners-Lee a répondu.

Je pensais que les illustrations seraient présentées comme ceci :

Illustration

où les valeurs du rapport désignent

EMBED Insérer ici si disponible
PRÉSENT Indiquer quand le document original est présenté

Notez que vous pouvez avoir différentes combinaisons de ces éléments, et si le navigateur ne les prend pas en charge, il ne les interrompt pas.

[Je] peux voir que cela est utilisé comme méthode de sélection d'une icône via des liens imbriqués. Hmmm. Mais je n'aimerais pas une étiquette spéciale.

Cette proposition n'a pas été mise en œuvre, mais attribut rel toujours là.

Ce serait bien s'il y avait un moyen de spécifier le type de contenu, par ex.

Mais je suis tout à fait disposé à accepter l'exigence de spécifier le type de contenu par extension de fichier.

Cette proposition n'a pas été implémentée, mais Netscape a ajouté plus tard la prise en charge de l'intégration d'objets multimédias avec l'élément .

Bien que les images soient en haut de ma liste de souhaits, au milieu des types dans les navigateurs WWW, je ne pense pas que nous devrions ajouter des crochets spécifiques aux médias un par un. Qu’est-il arrivé à l’enthousiasme suscité par l’utilisation du mécanisme MIME ?

Cela ne remplace pas l’utilisation prochaine de MIME comme mécanisme de document standard ; il fournit l'implémentation nécessaire et simple des fonctionnalités requises indépendamment de MIME.

Oublions MIME pour l'instant s'il s'agit d'un problème éphémère. Mon objection concernait la discussion sur "comment allons-nous prendre en charge les images en ligne" plutôt que sur "comment allons-nous prendre en charge les images en ligne sur tous les supports".

DANS sinon quelqu'un dans une semaine suggérera "insérer nouvelle balise " pour le son.

Il ne devrait pas y avoir beaucoup de dépenses lors du passage d'un produit générique.

Avec le recul, les inquiétudes de Jay semblent justifiées. Cela a pris un peu plus d'une semaine, mais de nouveaux éléments ont finalement été ajoutés au HTML5

En réponse au message original de Jay, Dave Ragett a déclaré :

Exactement! Je souhaite examiner la gamme complète d'images/lignes de type artistique possibles ainsi qu'une discussion sur le format. Tim a souligné la prise en charge des zones cliquables à l'intérieur des images, ce qui est également important.

En fait, nous devrions peut-être réfléchir à un langage graphique procédural à usage général avec lequel nous pourrions insérer des hyperliens arbitraires attachés à des icônes, des images, du texte, etc. Quelqu'un d'autre a-t-il vu les capacités d'Intermedia à ce sujet ?

Découvrez d'autres systèmes qui ont ces concepts (très précieux), Andrew et Slate. Andrew est construit avec des _inserts_, chacun d'eux a plusieurs types intéressants, tels que du texte, des bitmaps, des graphiques, des animations, des messages, des feuilles de calcul, etc. Le concept d'imbrication récursive arbitraire est présent, de sorte qu'une insertion de n'importe quel type peut être imbriquée dans tout autre type prenant en charge l'imbrication. Par exemple, un encart peut être intégré n'importe où dans le texte d'un widget de texte, ou dans n'importe quelle zone rectangulaire d'un widget de dessin, ou dans n'importe quelle cellule d'une feuille de calcul.

Voici mon avis. La meilleure façon de restituer des images sur le Web est d'utiliser MIME. Je suis sûr que PostScript prend déjà en charge le sous-typage MIME et qu'il fait un très bon travail en combinant texte et graphiques.

Mais ce n'est pas cliquable tu dis ? Oui, tu as raison. Je soupçonne que la réponse à cette question se trouve déjà dans Display PostScript. Même si cela n'est pas ajouté au PostScript standard, cela est trivial. Définissez une commande de lien qui spécifie une URL et utilise le chemin actuel comme zone délimitée pour le bouton. Étant donné que PostScript gère bien les chemins, la création d'un bouton personnalisé est triviale.

Display PostScript était une technologie de rendu d'écran développée conjointement par Adobe et NeXT.

Cette proposition n'a pas été mise en œuvre, mais l'idée selon laquelle la meilleure façon de corriger le HTML est de le remplacer par quelque chose de complètement différent revient encore de temps en temps.

HTTP2 permet à un document de contenir n'importe quel type avec lequel l'utilisateur a déclaré qu'il pouvait fonctionner, pas seulement les types MIME enregistrés. Vous pouvez donc expérimenter. Oui, je pense qu'il existe un argument pour PostScript avec hypertexte. Je ne sais pas si Display PostScript est suffisant. Je sais qu'Adobe essaie de créer son propre "PDF" centré sur PostScript qui comportera des liens et sera lisible par sa visionneuse propriétaire.

Je pense qu'un langage de superposition commun pour les liens (basé sur Hytime ?) permettrait aux normes hypertextes et graphiques/vidéo d'évoluer séparément, ce qui aiderait les deux.

Laissez la balise IMG inclure INCLUDE et laissez-la faire référence à un type de document arbitraire. Ou EMBED si INCLUDE ressemble à cpp include afin que les gens puissent fournir source SGML pour l'analyse ligne par ligne - pas comme prévu.

Revenons aux images en ligne - je suis sur le point de publier Mosaic 0.10, qui prend en charge Images GIF et XBM comme mentionné précédemment...

Nous ne sommes pas prêts à prendre en charge INCLUDE/EMBED à ce stade... Nous allons donc probablement utiliser (pas ICON, puisque toutes les images en ligne ne peuvent pas raisonnablement être appelées icônes). Actuellement, les images en ligne ne contiendront pas explicitement de type de contenu ; à l'avenir, nous prévoyons de prendre en charge cela (avec une adaptation générale de MIME). En fait, la procédure de lecture d'images que nous utilisons dans actuellement, détermine le format à la volée, donc l'extension du fichier n'est pas si importante.

Ligne continue

Je suis extrêmement passionné par tous les aspects de cette conversation de près de 17 ans, qui a conduit à la création d'un élément HTML qui a été utilisé sur pratiquement toutes les pages Web jamais publiées. Prenons en compte :

• HTTP existe toujours. HTTP a évolué avec succès de 0.9 à 1.0 et plus tard à 1.1. Et cela continue à se développer.
• Le HTML existe toujours. Il s'agit d'un format de données rudimentaire - il ne prend même pas en charge les images linéaires ! - développé avec succès en 2.0, 3.2, 4.0. HTML est une ligne continue. Une ligne tordue, noueuse et emmêlée, bien sûr. Il y avait de nombreuses « branches mortes » dans l’arbre évolutif, des endroits où les gens pensant de manière standard prenaient de l’avance sur eux-mêmes (et surpassaient les auteurs et les interprètes). Mais néanmoins. Nous sommes ici en 2010 et les pages Web de 1990 sont toujours affichées dans les navigateurs modernes. Je viens d'en charger un dans le navigateur de mon téléphone portable sur le dernier Android et on ne m'a même pas demandé de "Veuillez patienter pendant que l'ancien format est importé...".
• HTML a toujours été une conversation entre les développeurs de navigateurs, les auteurs, les passionnés de normes et d'autres personnes qui se présentent simplement et souhaitent parler des crochets angulaires. Les versions HTML les plus réussies ont été des « spécifications rétro », rattrapant le monde tout en essayant de le pousser dans la bonne direction. Quiconque vous dit que le HTML doit être « propre » (en ignorant probablement les développeurs du navigateur ou en ignorant les auteurs, ou les deux) est tout simplement mal informé. Le HTML n'a jamais été propre et toutes les tentatives pour le nettoyer ont échoué de façon spectaculaire et n'ont d'égal que les tentatives pour le remplacer.
• Aucun des navigateurs depuis 1993 n'existe dans aucun pays. forme reconnaissable. Netscape Navigator a été abandonné en 1998 et réécrit de toutes pièces pour créer la suite Mozilla, dont Firefox est ensuite issu. Internet Explorer a commencé comme un humble « par où commencer » dans « Microsoft Plus ! pour Windows 95" où il était livré avec des thèmes de bureau et un jeu de flipper.
• Certains systèmes d'exploitation de 1993 existent toujours, mais aucun d'entre eux n'est pertinent pour le Web moderne. La plupart des personnes « averties » accèdent à Internet sur un PC exécutant Windows 2000 ou version ultérieure, un Mac exécutant Mac OS X, un PC exécutant un savoureux Linux ou des appareils portables comme un iPhone. En 1993, Windows était en version 3.1 (en concurrence avec OS/2), les Mac tournaient sous System 7, Linux était distribué via Usenet.
• Certaines personnes sont toujours impliquées et participent encore à ce que nous appelons désormais simplement les « standards du Web ». Cela fait presque 20 ans maintenant. Et certains ont été impliqués dans les précurseurs du HTML, remontant aux années 1980 et avant.
• En parlant de prédécesseurs... Avec la popularité ultime du HTML et du Web, il est facile d'oublier ceux qui ont façonné la conception des formats et des systèmes modernes. André ? Intermédia ? HyTime? Et HyTime n'était pas un antédiluvien projet de recherche, c'était une norme ISO. Il a été approuvé pour un usage militaire. C'était le Big Business. Et vous pouvez le lire vous-même... .

Mais rien de tout cela ne répond à la question initiale : pourquoi utilisons-nous l'élément ? Pourquoi pas un élément ? Ou élément ? Pourquoi pas des hyperliens avec un attribut include ou une combinaison de valeurs rel ? Pourquoi l'élément ? C'est très simple car Marc Andreessen l'a implémenté et le code implémenté a gagné.

Cela ne veut pas dire que tout codes implémentés a gagné, à la fin, Andrew et Intermedia et HyTime ont également été mis en œuvre. Le code est nécessaire, mais pas suffisant pour réussir. Je ne veux certainement pas dire que l'implémentation du code avant la publication de la norme est La meilleure décision. Marque d'élément ne définit pas les formats graphiques de base ; ne précise pas comment le texte doit s'y dérouler ; ne prend pas en charge le texte alternatif ou le contenu de secours pour les anciens navigateurs. Et 17 ans plus tard, nous sommes toujours aux prises avec le reniflage de contenu et cela reste une source de failles de sécurité folles. Et vous pouvez retracer tout cela 17 ans plus tard, à travers la Grande Guerre des Navigateurs, jusqu'au 25 février 1993, lorsque Marc Andreessen a fait remarquer avec désinvolture : « MIME, un jour, peut-être », puis a implémenté son code quoi qu'il arrive.

Chronologie du développement HTML de 1997 à 2004

En décembre 1997, le World Wide Web Consortium (W3C) a publié HTML 4.0 et a rapidement fermé le groupe de travail HTML. Moins de deux mois plus tard, un groupe de travail distinct du W3C a publié XML 1.0. Trois mois plus tard, les dirigeants du W3C ont organisé un atelier intitulé « Façonner l'avenir du HTML » pour répondre à la question : « Le W3C a abandonné le HTML ? Voici leur réponse :

Au cours de la discussion, il a été décidé qu'une expansion ultérieure de HTML 4.0 serait difficile, comme si nous convertissions 4.0 en applications XML. Le chemin proposé vous libérera des restrictions pour commencer une nouvelle vie avec la prochaine génération de HTML basée sur un ensemble de balises XML.

Le W3C a relancé le groupe de travail HTML pour créer cet « ensemble de balises XML ». Leur première étape en décembre 1998 a été de rédiger une spécification provisoire qui retravaillait simplement le HTML en XML sans ajouter de nouveaux éléments ou attributs. Cette spécification est devenue plus tard connue sous le nom de « XHTML 1.0 ». Il a défini un nouveau type MIME pour les documents XHTML - application/xhtml+xml. Cependant, pour faciliter la migration des pages HTML4 existantes, il incluait également l'Annexe C, qui « résume les directives de conception pour les auteurs qui souhaitent que leurs documents XHTML soient rendus sur les agents utilisateurs HTML existants ». L'annexe C vous indique qu'elle permet à l'auteur de pages dites "XHTML" de toujours les servir avec le type MIME text/html .

L'objectif suivant était les formulaires Web. En août 1999, le même groupe de travail HTML a publié la première version de XHTML Extended Forms. Elle a défini les attentes dans le premier paragraphe :

Après un examen attentif, le groupe de travail HTML a déterminé que les objectifs de la prochaine génération de formulaires ne sont pas les mêmes que le maintien de la compatibilité ascendante avec les navigateurs conçus pour les versions antérieures de HTML. Notre objectif est de garantir la pureté du nouveau modèle de formulaires (XHTML Extended Forms) basé sur un ensemble d'exigences clairement définies. Ces exigences sont décrites dans ce document et sont basées sur l'expérience acquise avec un large éventail d'applications de formulaires.

Quelques mois plus tard, « XHTML Extended Forms » a été renommé « XForms » et intégré dans son propre groupe de travail. Ce groupe a travaillé en parallèle avec le groupe de travail HTML et a finalement publié la première version de XForms 1.0 en octobre 2003.

Parallèlement, avec la transition vers le XML intégral, le groupe de travail HTML s'est fixé pour objectif de créer la « prochaine génération de HTML ». En mai 2001, il a publié la première révision de XHTML 1.1, qui n'ajoutait que quelques fonctionnalités mineures à XHTML 1.0, mais comblait également la faille de « l'Annexe C ». Depuis la version 1.1, tous les documents XHTML doivent être servis avec le type MIME application/xhtml+xml.

Tout ce que vous savez sur XHTML est faux

Pourquoi les types MIME sont-ils si importants ? Pourquoi est-ce que je reviens toujours vers eux ? Trois mots : gestion draconienne des erreurs. Les navigateurs ont toujours été indulgents avec HTML. Si vous avez créé une page HTML mais avez oublié la balise, le navigateur affichera toujours la page (certaines balises provoquent implicitement la complétion et le début ). Vous devez supposer une imbrication hiérarchique des balises - elles sont fermées dans l'ordre inverse - mais si vous créez du code comme , les navigateurs le géreront (d’une manière ou d’une autre) et continueront sans afficher de message d’erreur.

Comme on pouvait s’y attendre, le fait que la « ligne brisée » Balisage HTML fonctionne dans les navigateurs, permettant aux auteurs de créer des pages HTML cassées. Beaucoup de pages cassées. Selon certaines estimations, plus de 99 % des pages HTML présentes sur le Web contiennent aujourd'hui au moins une erreur. Mais comme ces bugs n’obligent pas les navigateurs à afficher des messages d’erreur visibles, personne ne les corrige jamais.

Le W3C a vu cela comme un problème fondamental du Web et a entrepris de le résoudre. XML, publié en 1997, a rompu avec la tradition du pardon aux clients et a décrété que tous les programmes qui consomment du XML doivent traiter les erreurs dites de « syntaxe » comme fatales. Ce concept d'échec à la première erreur est devenu connu sous le nom de « gestion draconienne des erreurs », à l'instar du dirigeant grec Draco, qui a institué la peine de mort pour la moindre violation de ses lois. Lorsque le W3C a reformulé HTML en vocabulaire XML, il a exigé que tous les documents transmis avec le nouveau type MIME application/xhtml+xml soient soumis à un traitement draconien des erreurs. S'il y a au moins une erreur de syntaxe dans la page XHTML - comme une balise oubliée ou des balises de début et de fin mal imbriquées - les navigateurs n'auront d'autre choix que d'arrêter le traitement et d'afficher un message d'erreur à l'utilisateur final.

Cette idée n’est pas populaire partout. Avec un taux d'erreur estimé à 99 % sur les pages existantes, la probabilité généralisée que des erreurs soient affichées à l'utilisateur final et le manque de nouvelles fonctionnalités dans XHTML 1.0 et 1.1, les auteurs ignorent largement application/xhtml+xml pour justifier le coût. Mais cela ne veut pas dire qu’ils ont ignoré le XHTML dans son ensemble. Oh, certainement pas. L'Annexe C de la spécification XHTML 1.0 a donné une faille aux auteurs du monde entier : "Créez quelque chose qui ressemble à la syntaxe XHTML, mais laissez-le passer avec le type MIME text/html." Et c'est exactement ce qu'ont fait des milliers de développeurs Web : ils ont "mis à niveau" vers la syntaxe XHTML, mais ont continué à effectuer le rendu avec le type MIME texte/html.

Aujourd'hui encore, des millions de pages Web revendiquent le XHTML. Ils commencent par un doctype XHTML sur la première ligne, utilisent des noms de balises minuscules, des guillemets autour des attributs et ajoutent une barre oblique après les éléments vides comme
Et

---

. Mais seule une petite fraction de ces pages est servie avec le type MIME application/xhtml+xml, qui inclut une gestion draconienne des erreurs XML. Toute page transmise avec le type MIME text/html - quel que soit le type de document, la syntaxe ou le style de codage - sera analysée par un analyseur HTML "indulgent", ignorant silencieusement les erreurs de balisage et ne signalant jamais les utilisateurs finaux(ou n'importe qui d'autre) même si la page est techniquement cassée.

XHTML 1.0 incluait cette faille, mais XHTML 1.1 l'a comblée, et le XHTML 2.0 inachevé a continué la tradition d'exiger une gestion draconienne des erreurs. C'est pourquoi il existe des milliards de pages qui prétendent être XHTML 1.0 et seulement une poignée qui prétendent être XHTML 1.1 (ou XHTML 2.0). Alors, utilisez-vous réellement XHTML ? Vérifiez votre type MIME (en fait, si vous ne savez pas quel type MIME vous utilisez, je peux presque garantir que vous utilisez également text/html ). Tant que vous ne transmettez pas vos pages avec le type MIME application/xhtml+xml , votre soi-disant "XHTML" n'a que le nom XML.

Vision compétitive

En juin 2004, le W3C a organisé un atelier sur les applications Web et les documents composites. Cet atelier a réuni des représentants de trois navigateurs, une société de développement Web et d'autres membres du W3C. Des groupes de parties prenantes, dont la Fondation Mozilla et Opera Software, ont exposé leurs visions concurrentes pour l'avenir du Web : l'évolution de la norme HTML 4 existante inclut de nouvelles fonctionnalités pour les développeurs d'applications Web modernes.

Les sept principes suivants reflètent ce que nous considérons comme les exigences les plus importantes pour ce travail.

Les technologies d'application Web rétrocompatibles et claires doivent être basées sur des technologies familières aux auteurs et inclure HTML, CSS, DOM et JavaScript. Les fonctionnalités de base d'une application Web doivent aujourd'hui être réalisées à l'aide de comportements, de scripts et de feuilles de style dans IE6, afin que les auteurs disposent d'un chemin de migration clair. Toute solution qui ne peut pas être utilisée par l'agent utilisateur actuel sans les plugins nécessaires ne peut probablement pas réussir. Gestion des erreurs de bien-être La gestion des erreurs dans les applications Web doit être définie à un niveau de granularité où les agents utilisateurs ne doivent pas inventer leurs propres mécanismes de gestion des erreurs ou faire de l'ingénierie inverse sur d'autres agents utilisateurs. Les utilisateurs ne doivent pas être sujets à des erreurs propriétaires. Les spécifications doivent spécifier le comportement de récupération exact pour chaque scénario d'erreur possible. La gestion des erreurs doit principalement être définie en termes de récupération gracieuse des erreurs (comme en CSS), plutôt que comme un échec évident et catastrophique (comme en XML). Utilisation pratique Chaque fonction entrant dans la spécification d'une application Web doit être justifiée utilisation pratique. L’inverse n’est pas toujours vrai : chaque cas d’utilisation ne garantit pas nécessairement une nouvelle fonctionnalité. Il est préférable d'utiliser des arguments basés sur des sites réels où les auteurs ont préalablement utilisé Mauvaise Décision pour contourner la restriction. Les scripts subsistent mais doivent être évités lorsqu'un balisage pratique peut être utilisé. Les scripts doivent être neutres sur les appareils et s'afficher aussi longtemps que possible sur des appareils spécifiques (par exemple s'ils ne sont pas inclus dans XBL). Le profil doit être évité appareil spécifique Les auteurs doivent pouvoir s'appuyer sur les mêmes fonctionnalités fournies dans les versions de bureau et versions mobiles le même agent utilisateur. Un processus ouvert Le Web était bénéfique car il se développait dans un environnement ouvert. Les applications Web seront le cœur du Web et leur développeur devra être ouvert. Les listes de diffusion, les archives et les projets de spécifications doivent être visibles en permanence par le public.

Dans un sondage informel, les participants à l'atelier ont été interrogés : « Le W3C devrait-il développer des extensions déclaratives de HTML et CSS et nécessairement étendre le DOM pour répondre aux exigences des applications Web de niveau intermédiaire, par opposition aux API complexes d'un système d'exploitation complet ? (suggéré par Ian Hickson, Opera Software)." Le vote a été de 11 pour et 8 contre. Dans son résumé de l'atelier, le W3C a écrit : « Pour le moment, le W3C n'a pas l'intention de fournir de ressources sur le sujet de l'enquête informelle tierce : les extensions HTML et CSS pour les applications Web, au-delà des technologies développées dans le cadre de la charte de l'actuel Groupe de travail du W3C."

Face à cette décision, ceux qui proposaient de développer du HTML et des formulaires HTML n'avaient que deux options : abandonner ou continuer leur travail en dehors du W3C. Ils ont choisi cette dernière solution et ont enregistré le domaine whatwg.org, et le groupe de travail WHAT est né en juin 2004.

QUEL groupe de travail ?

De toute façon, qu'est-ce que c'est que le groupe de travail QUOI ? Je les laisse s'expliquer :

Le groupe de travail WHAT est une collaboration libre, informelle et ouverte entre les fournisseurs de navigateurs et les parties intéressées. Le groupe a pour objectif d'élaborer des spécifications pour Basé sur HTML et les technologies associées pour faciliter le déploiement d'applications Web interopérables afin de fournir à l'organisation des résultats fondés sur des normes. Cette disposition constituera ensuite la base du travail formel d'extension HTML dans le cours sur les normes.

La création de ce forum fait suite à plusieurs mois de correspondance privée concernant les spécifications de chaque technologie. L'accent était mis sur l'extension des formulaires HTML4 pour prendre en charge les fonctionnalités demandées par les auteurs, sans rompre la compatibilité ascendante avec le contenu existant. Ce groupe a été créé pour assurer le développement futur de ces spécifications, et sera entièrement ouvert via une liste de diffusion d'archives publiques et accessible.

La phrase clé ici est « sans rompre la rétrocompatibilité ». XHTML (à l'exclusion de la faille de l'Annexe C) n'est pas rétrocompatible avec HTML. Il nécessite un tout nouveau type MIME, qui inclut une gestion draconienne des erreurs pour tout contenu transmis avec ce type MIME. Les XForms ne sont pas compatibles avec les formulaires HTML car ils ne peuvent être utilisés que dans des documents soumis avec le nouveau type XHTML MIME, ce qui signifie que XForms inclut également une gestion draconienne des erreurs. Tous les chemins mènent au MIME.

Au lieu de gaspiller plus d'une décennie d'investissement HTML et de rendre 99 % des pages Web existantes inutilisables, le groupe de travail WHAT a décidé d'adopter une approche différente : documenter les algorithmes de gestion des erreurs « indulgents » que les navigateurs utilisent réellement. Les navigateurs pardonnent toujours les erreurs HTML, mais personne n’a jamais pris la peine d’écrire exactement comment ils l’ont fait. NCSA Mosaic possède ses propres algorithmes pour traiter les pages cassées, et Netscape a essayé de les adapter. Internet Explorer tente alors de concurrencer Netscape. Opera et Firefox tentent ensuite de concurrencer Internet Explorer. Safari tente alors de concurrencer Firefox. Et ainsi de suite, jusqu'à nos jours. En cours de route, les développeurs ont consacré des milliers et des milliers d’heures à essayer de rendre leur produit compatible avec la concurrence.

Si cela semble être une quantité de travail insensée, c'est parce que c'est le cas. Ou plutôt, ça l'était. Cela a pris cinq ans, mais le groupe de travail WHAT a réussi à documenter comment analyser le HTML d'une manière compatible avec le contenu Web existant. Il n'y a nulle part dans l'algorithme final une étape indiquant que HTML doit arrêter le traitement et afficher un message d'erreur à l'utilisateur final.

Pendant que l'ingénierie inverse se déroulait, le groupe de travail WHAT travaillait tranquillement sur d'autres choses. L'une d'entre elles était une spécification qui dupliquait initialement Web Forms 2.0 et ajoutait de nouveaux types de champs aux formulaires HTML (vous en apprendrez davantage sur les Web Forms dans ). Un autre projet de spécification s'appelle "Web Applications 1.0", qui inclut de nombreuses nouvelles fonctionnalités telles qu'un canevas pour le dessin direct et une prise en charge audio et vidéo native sans plugins.

Retour au W3C

Pendant deux ans et demi, le W3C et le groupe de travail WHAT se sont largement ignorés. Alors que le groupe de travail WHAT se concentrait sur les formulaires Web et les nouvelles fonctionnalités HTML, le groupe de travail HTML du W3C s'occupait de la version 2.0 de XHTML. Mais en octobre 2006, il est devenu clair que le groupe de travail WHAT avait pris un sérieux élan, alors que XHTML 2 traînait encore à l'état de projet et n'avait été implémenté dans aucun navigateur sérieux. En octobre 2006, Tim Berners-Lee, fondateur du W3C, a annoncé que le W3C travaillerait avec le groupe de travail WHAT pour développer le HTML.

Certaines choses deviennent claires après quelques années. Il est nécessaire de développer le HTML progressivement. Essayer d'obtenir le monde en passant au XML, en incluant des guillemets autour des valeurs d'attribut et des barres obliques dans les balises vides et les espaces de noms, ne fonctionne pas tous en même temps. L'immense public formé autour du HTML n'a pas bougé, en grande partie parce que les navigateurs ne se sont pas plaints. Certaines grandes communautés ont franchi le pas et profitent des avantages syntaxiques systèmes corrects, Mais pas tout. Il est important de prendre en charge HTML progressivement, de continuer à évoluer vers un monde syntaxiquement correct et de déployer de plus grands efforts dans ce monde.

Il est prévu d'organiser un tout nouveau groupe HTML. Contrairement au groupe précédent, il apportera des améliorations incrémentielles au HTML ainsi qu'au XHTML en parallèle. Elle aura une direction et un personnel différents. Il fonctionnera ensemble sur HTML et XHTML. Nous bénéficions d'un fort soutien pour ce groupe de la part de nombreuses personnes dont nous avons parlé, y compris les développeurs de navigateurs.

Il y aura également du travail avec les formulaires. Il s'agit d'un domaine délicat car les formulaires HTML et XForms existants sont un langage de formulaire. Les formulaires HTML sont largement déployés et il existe de nombreuses implémentations et utilisateurs de XForms. Pendant ce temps, les WebForms font l'objet d'une extension intelligente dans les formulaires HTML. Il est prévu de transformer les WebForms en une extension des formulaires HTML.

L'une des premières choses que le nouveau groupe de travail HTML du W3C a fait a été de décider de renommer « Applications Web 1.0 » en « HTML5 ». Et donc nous plongeons dans HTML5.

P.S.

En octobre 2009, le W3C a fermé le groupe de travail XHTML 2 et a publié une déclaration expliquant la décision :

Lorsque le W3C a annoncé la création des groupes de travail HTML et XHTML 2 en mars 2007, nous avons indiqué que nous continuerions à surveiller le marché du XHTML 2. Le W3C reconnaît un signal clair et important de la communauté concernant l'avenir du HTML.

Même si nous reconnaissons l'importance du groupe de travail XHTML 2 au fil des années, après discussion avec les membres, la direction du W3C a décidé que la charte du groupe de travail, qui expire fin 2009, ne sera pas renouvelée.

Ceux qui l’ont mis en œuvre en ont bénéficié.

• Traduction

HTML est le langage qui unit le World Wide Web. Avec juste un ensemble de balises simples, l’humanité a réussi à créer un système incomparable de pages et de sites Web interconnectés : d’Amazon, eBay et Wikipedia, aux blogs personnels et aux sites dédiés aux chats qui ressemblent à Hitler.

HTML5 est la dernière version de ce langage. Mais même si cela apportera des changements importants et de nouvelles opportunités, on ne peut pas dire que cela se produit pour la première fois et que la langue n’a jamais évolué auparavant. Il s'est développé et constamment amélioré, et ce depuis sa création.

Comme le World Wide Web en général, HTML – HyperText Mark-up Language – est une idée originale de Sir Tim Berners-Lee. En 1991, il a écrit un article intitulé « HTML Tags », dans lequel il décrivait un peu moins de deux douzaines de balises qu'il proposait pour baliser les pages Web.

L’idée d’utiliser pour cela des mots de code entre crochets triangulaires n’appartenait cependant pas à Sir Tim. Un tel système existait déjà à cette époque et était utilisé dans SGML (Standard Generalized Markup Language), et au lieu d'inventer quelque chose à partir de zéro, Sir Tim a jugé plus rationnel de prendre comme base les solutions existantes. Une approche similaire a été utilisée tout au long du processus de développement de HTML5.

De l'IEFT au W3C : le chemin vers HTML 4

Il n'y a jamais eu de version de HTML 1. La première spécification officielle était HTML 2.0, publiée par l'IETF (Internet Engineering Task Force). De nombreuses fonctionnalités du langage décrites dans cette spécification étaient basées sur des développements tiers déjà utilisés. Par exemple, balisez pour insérer des images dans les pages a été implémenté dans le principal navigateur de l'époque (nous parlons de 1994) le navigateur Mosaic, puis a simplement migré vers le standard HTML 2.0.

Le relais de l'IEFT a ensuite été repris par le W3C (World Wide Web Consortium), qui a géré toutes les versions ultérieures du HTML. Dans la seconde moitié des années 90, un travail actif a été mené pour réviser et modifier les spécifications, qui ont finalement (plus précisément, en 1999) donné naissance à HTML 4.01.

Après cela, le premier tournant clé est survenu dans l’histoire du HTML.

XHTML 1 : HTML au format XML

La nouvelle version du langage de balisage après HTML 4.01 s'appelle XHTML 1.0. Le « X » dans le nom signifiait eXtreme, et les développeurs Web devaient croiser les bras devant eux à chaque fois qu'ils prononçaient ce mot.

Non bien sûr que non. En fait, le « x » signifiait eXtensible (« extensible »), et croiser les bras était facultatif.

La spécification elle-même pour XHTML 1.0 n'était pas différente de HTML 4.01. Aucune nouvelle balise ou paramètre n'a été ajouté - la seule différence réside dans les règles de syntaxe. Alors qu'en HTML les développeurs disposaient d'une totale liberté quant au style d'écriture du code, en XHTML ils étaient tenus de respecter les règles du langage XML - beaucoup plus rigide et intolérant aux libertés - sur lequel reposaient la plupart des technologies développées par le Consortium. .

Les règles strictes se sont toutefois avérées utiles. Ils ont encouragé les codeurs à adhérer à un style unique, par exemple : écrire toutes les balises et tous les paramètres exclusivement en minuscules, alors qu'en HTML, vous pouvez le faire à votre guise.

La sortie de XHTML 1.0 a coïncidé avec la prise en charge accrue par les navigateurs modernes des feuilles de style - CSS - et la syntaxe stricte de XHTML a pris pied dans la communauté des développeurs avec la réputation d'être le meilleur moyen d'écrire du code de balisage.

Puis il y a eu XHTML 1.1.

Si la version 1.0 n'était que du HTML créé sous XML, alors XHTML 1.1 est déjà du vrai XML pur. Dans le sens où il n'était plus possible de lui appliquer le type mime texte/html et devait désigner le document comme étant au format XML. Cependant, dans ce cas, le navigateur le plus populaire de l'époque - Internet Explorer - n'aurait pas été en mesure de l'afficher, donc l'utilisation de ce langage dans la pratique n'était clairement pas une option.

Il semblait que le W3C, dans son évolution, commençait à perdre contact avec la réalité dans laquelle vivait le World Wide Web.

XHTML 2 : non, il ne rentre plus dans aucune porte

Si le personnage de Dustin Hoffman dans The Graduate était un web designer, le W3C n'aurait qu'un seul mot à lui dire : XML.

Le consortium était convaincu que HTML était devenu obsolète après la version 4 et a commencé à travailler sur XHTML 2, dont l'objectif était de conduire le Web vers un brillant avenir XML. Et même si le nom reste le même, une nouvelle version n'avait absolument rien à voir avec XHTML 1. De plus, il n'était pas destiné à être rétrocompatible avec ses prédécesseurs et les anciennes versions de HTML (et donc avec tous les contenus web existants). Au lieu de cela, il aurait dû introduire un nouveau langage clair, débarrassé de tout vestige des spécifications passées.

En d’autres termes, c’était absurde.

Divisé : W(HATWG) TF ?

Un soulèvement se préparait au sein du Consortium. Il était évident qu'il allait diriger le développement de normes - bien que nouvelles, propres et belles - mais totalement insensibles aux besoins de la communauté moderne des concepteurs et développeurs Web. Opera, Apple et Mozilla n'étaient clairement pas satisfaits de cela, car ils s'attendaient à quelque chose de complètement différent : davantage d'accent sur les formats qui élargissent les possibilités de création d'applications Web.

Le début des changements a eu lieu en 2004 lors d'une des réunions. Ian Hickson, qui était à l'époque employé d'Opera Software, a proposé de développer le HTML à un niveau permettant d'utiliser le langage pour des applications Web. L'offre a été rejetée.

Les rebelles désillusionnés ont été contraints de se séparer du Consortium et de former leur propre groupe : le Web Hypertext Application Technology Working Group, ou WHATWG en abrégé.

Des applications Web 1.0 au HTML5

La façon dont WHATWG fonctionnait était quelque peu différente de celle du W3C. Au W3C, les problèmes sont soulevés, discutés et la décision finale est prise par vote populaire. Dans WHATWG, des problèmes sont également soulevés et discutés, mais les décisions finales concernant ce qui est inclus dans la spécification et ce qui ne l'est pas appartiennent au rédacteur en chef, Ian Hickson.

À première vue, il peut sembler que le système du W3C est plus démocratique et honnête, mais la pratique montre que les conflits sans fin et les querelles internes ralentissent terriblement le processus de développement. Dans WHATWG, où tout le monde peut contribuer, mais où le patron a le dernier mot, les choses avancent beaucoup plus vite. Le rédacteur en chef n'a cependant pas absolu pouvoir - un groupe restreint de hauts fonctionnaires peut contester sa décision dans le cas peu probable où cela l'exigerait.

Initialement, WHATWG se concentrait sur deux spécifications – Web Forms 2.0 et Web Apps 1.0 – qui étaient toutes deux destinées à être des extensions du HTML. Mais au fil du temps, ils ont été combinés en un seul, simplement appelé HTML5.

Réunion

Pendant que le WHATWG travaillait sur HTML5, le W3C continuait à s'occuper de son XHTML 2. Cela ne veut pas dire que l'idée allait être merdique. Elle s'y enfonça lentement et lentement.

En octobre 2006, Sir Tim Berners-Lee admettait sur son blog que l'idée de faire passer le Web du HTML au XML était stupide. Quelques mois plus tard, le W3C publiait nouvelle installation au groupe de travail HTML : il a été sagement décidé que les futures versions de HTML devraient s'appuyer sur le travail du WHATWG, plutôt que de partir de zéro.

Tous ces revirements et changements de cap ont conduit à une situation quelque peu confuse. Pendant un certain temps, le W3C travaillait simultanément sur deux langages de balisage totalement incompatibles - XTHML 2 et HTML 5 (attention, avec un espace) - tandis que le WHATWG, une organisation distincte, travaillait sur la spécification HTML5 (sans espace) cela allait devenir la base d'une autre spécification du W3C. Le raifort poussera ici, quoi de neuf ? Il aurait été plus facile de comprendre la séquence des événements dans Memento et les œuvres de David Lynch.

XHTML est mort, vive la syntaxe XHTML

La situation a commencé à devenir plus claire en 2009, lorsque le W3C a annoncé qu'il n'y aurait plus de mises à jour de XHTML 2. Essentiellement, ils ont simplement admis officiellement que le format était mort depuis sa naissance.

Cependant, d'une manière étrange, au lieu de passer inaperçue, la mort de XHTML 2 a donné lieu à une sorte de bouillonnement malveillant. Les opposants à XML ont transformé cette nouvelle en un appel à l’abandon de XHTML 1, même si, comme nous le savons, cela n’avait rien de commun avec XHTML 2. À leur tour, les partisans de XHTML 1, adeptes d’une syntaxe stricte, craignaient que HTML5 ne légitime une fois de plus une mise en page bâclée.

Ce dernier, cependant, ne devrait pas sembler être un problème sérieux - comme nous le verrons plus tard, chacun a le droit de choisir lui-même le degré de rigueur de la syntaxe HTML5.

Développement HTML5

L’état actuel du HTML5 n’est plus aussi trouble qu’avant, mais il n’est toujours pas très transparent non plus.

Deux organisations travaillent actuellement sur ce format. Le WHATWG développe la spécification sur la base du principe « exécuter d’abord, tester plus tard ». Le groupe de travail HTML du W3C reprend à son tour cette spécification et la soumet à un processus « tester d'abord, puis exécuter ». Comme vous pouvez le constater, une telle coopération peut difficilement être qualifiée de solide et efficace. Mais au moins, la question de « mettre ou non un espace » dans le nom de la norme semble avoir été résolue (il n'est pas nécessaire de le mettre, si c'est le cas - HTML5).

La plus grande préoccupation des concepteurs de sites Web, qui ont déjà essayé certaines des fonctionnalités du nouveau langage, est la question : "Quand sera-t-il prêt ?" Dans une interview, Ian Hickson a mentionné 2022 comme date à laquelle HTML5 recevra le statut de « recommandation proposée ». Cela a provoqué une vague d’indignation parmi les concepteurs, car ils n’avaient aucune idée de ce que signifiait « proposition de recommandation », mais ils savaient avec certitude qu’ils n’avaient clairement pas assez de doigts pour compter combien d’années encore ils devaient attendre jusqu’en 2022.

Si vous y regardez, l’indignation est infondée. Dans ce cas, « recommandation proposée » signifie qu’à ce stade, les navigateurs devraient prendre entièrement en charge toutes les fonctionnalités linguistiques. Dans ce cas, viser 2022 est encore trop audacieux ; Nous savons tous que de nombreux navigateurs ont eu du mal à rattraper même les normes existantes. Prenez Internet Explorer, qui a mis plus de dix ans avant même de commencer à prendre en charge la balise. .

Date à laquelle vraiment il faut être conscient que nous sommes en 2012, date à laquelle HTML5 recevra le statut de « recommandation candidate », ce qui signifie que la spécification a été finalisée et, en tant que telle, la norme est prête.

Mais, bien sûr, cela ne signifie pas que tout cela sera immédiatement disponible - vous devrez surveiller la manière dont les navigateurs ajoutent progressivement la prise en charge de certaines fonctionnalités et commencer à les utiliser au fur et à mesure qu'elles apparaissent. En fait, c'était exactement la même chose avec CSS 2.1 : nous avons commencé à tirer parti des capacités de cette norme au fur et à mesure que les navigateurs l'incluaient de manière fragmentaire. Si nous avions préféré attendre qu’ils le mettent en œuvre dans son intégralité, nous attendrions encore.

En d’autres termes, il n’y aura pas un moment où vous pourrez dire « Bang, l’heure du HTML5 est venue ! » Mais vous pouvez commencer à travailler avec eux dès maintenant. Heureusement, cette langue n'est pas née d'une révolution, mais d'un processus d'évolution et est basée sur ce qui a été créé avant elle. Ainsi, nous pouvons dire que si vous en utilisez Versions précédentes HTML, vous utilisez déjà HTML5.

Tim Berners-Lee
Créateur du langage HTML

Cet article est à propos de HTML Dan brève revue la langue, sa structure, ses caractéristiques, son histoire. Cet article est à propos de Langage HTML est destiné à être lu pour le développement général et au stade initial de l'apprentissage du HTML, vous pouvez l'ignorer et y revenir plus tard, après la lecture.

HTML (Langage Signalétique Hyper Text)- Langage Signalétique Hyper Text. Les sites Web sont créés à l'aide Langage HTML.

Le créateur du langage HTML est un scientifique britannique exceptionnel - Tim Berners-Lee.

Versions HTML

Avant 1995, il n’existait pas de standard officiel pour le langage HTML, mais il existait plusieurs versions non standardisées du langage HTML. Le 22 septembre 1995 a créé le premier norme officielle Langage HTML, il reçut immédiatement le numéro 2.0 (HTML 2.0).

Le 14 janvier 1997, la version HTML 3.2 est apparue,
18 décembre 1997 HTML 4.0,
24 décembre 1999 HTML 4.01

Dans les années 2000, il y avait aussi langue Balisage XHTML (identique au HTML, mais avec une syntaxe plus stricte). XHTML était destiné à préparer les webmasters à des règles de balisage strictes Langage XML. Grâce à un balisage strict, divers programmes et services comprenant XML peuvent traiter efficacement les données sur des sites écrits en XHTML ; ce langage a également la capacité d'implémenter SVG, MathML, CML et d'autres dérivés du langage XML.

XHTML existait en trois versions : stricte, transitionnelle et frameset ; dans la version transitionnelle, vous pouviez utiliser des balises héritées telles que center ou font. Actuellement, le développement Langage XHTML fermé.

La version moderne du langage HTML est HTML5, c'est la version que nous étudierons dans ce tutoriel. HTML5 est plus pratique que les langages précédents et a absorbé tous leurs avantages, il inclut également grande importance sémantique.

Langage CSS et HTML

A partir de la version 4 du langage HTML, changez apparence Balises HTML Il est recommandé d'utiliser uniquement le langage CSS. Il est donc conseillé d’étudier en parallèle les langages HTML et CSS. Dans ce tutoriel HTML pour débutants, nous examinerons également les premiers aspects du langage CSS, mais pour continuer à apprendre, vous pouvez le lire vous-même.

Histoire du HTML

Le langage HTML a été créé en 1991 par le scientifique britannique Tim Berners-Lee. À l’époque, Tim travaillait au CERN (Organisation européenne pour la recherche nucléaire) et les sites Internet n’existaient pas encore. Les scientifiques travaillant dans ce centre avaient besoin d'un moyen fiable et efficace pour échanger des informations.

Le choix s'est porté sur Langage SGML, mais c'était trop compliqué et ensuite Tim, basé sur SGML, en a créé une variante simplifiée - HTML, grâce auquel n'importe quel scientifique pouvait créer un document simple contenant des informations, en l'encadrant avec diverses balises : paragraphes, titres, liens, et le publier sur Internet, et en même temps d'autres scientifiques pouvaient lire ces informations.

Initialement, dans les documents HTML (sur les pages d'un site Web), il était possible de placer uniquement informations textuelles, la possibilité d'ajouter des fichiers multimédias : images, vidéo et audio sont apparues un peu plus tard.

Pour le moment, support et développement Langage HTML est engagé W3C (World Wide Web Consortium)- World Wide Web Consortium. Le W3C se compose de divers groupes de travail qui mettent en œuvre et développent des normes et technologies Internet.

Tableau de répartition du navigateur

Les fichiers HTML ont généralement une extension .html ou .htm. Ces fichiers peuvent être consultés à l'aide des navigateurs Internet.

Tableau des noms de navigateurs et de leur numéro de distribution dans le monde, en janvier 2016, par ordre décroissant :

Navigateur	Diffusion
Google Chrome	54,22 %
Internet Explorer	14,67 %
Mozilla Firefox	14,61 %
Safari	9,43 %
Opéra	1,96 %
Autres	5,11 %