Changements entre la version 3.2 et 4.0 d'HTML 

Modifications d'éléments 

Nouveaux éléments 

Les nouveaux éléments apportés par cette version d'HTML sont Q, INS, DEL, ACRONYM, LEGEND, COLGROUP, BUTTON, et FIELDSET.

Eléments obsolètes 

Les éléments suivants sont désormais obsolètes : ISINDEX, APPLET, CENTER, FONT, BASEFONT, STRIKE, S, U, DIR, et MENU.

Eléments périmés 

Les éléments suivants sont désormais périmés : XMP, PLAINTEXT, et LISTING. A la place de ces éléments, il conviendra d'utiliser l'élément PRE.

Modifications dans les tableaux 

Le modèle de tableaux d'HTML 4.0 a grossi depuis les premières définitions de HTML+ et les premières références de l'HTML3.0. Ce précédent modèle a été étendu en réponse de nombreuses demandes de fournisseurs d'information interactive en ligne, de façon à leur permettre un meilleur contrôle sur le positionnement des champs :

• La possibilité d'aligner des cellules sur les caractères prédéfinis "." et ":"
  (ex., aligner une colonne de nombres sur le point décimal).
• Le besoin de plus grande souplesse dans le choix des bords et gouttières de tableaux.
• Le besoin d'un affichage incrémental de grands tableaux au fur et à mesure de l'arrivée des données.
• La possibilité de travailler avec des tableaux à défilement et à en-têtes ou piettement fixes et un meilleur contrôle sur la "pagination" des tableaux pour l'impression.
• Un besoin d'un nouveau paramétrage sur une base de colonne pour un alignement plus aisé

De plus, un des objectifs majeurs a été de maintenir une compatibilité ascendante avec l'implémentation largement distribuée des tableaux Netscape. Un autre objectif était de pouvoir facilement importer des tableaux conformes au modèle SGML CALS. Le dernier document provisoire a préservé la compatibilité de l'attribut align et des attributs similaires des dernières implémentations de navigateurs. Le rôle exact de l'attribut dir a été clarifié et un comportement a été préconisé dans le cas de mélange de colonnes de largeur absolues et relatives.

Un nouvel élément, COLGROUP, a été introduit pour permettre de grouper des ensembles de colonnes de largeurs et d'alignement différents, spécifiés une base de colonne au niveau d'élément COL. La sémantique des éléments COLGROUP a été clarifié par rapport aux documents provisoires précédents, et la forme rules="basic" a été remplacée par rules="groups".

L'attribut style est compris comme un moyen d'étendre les propriétés associées aux bordures et fonds de groupes de cellule. Par exemple, les style de ligne : pointillé, double, fine/épaisse etc ; le remplissage par couleur/motif pour l'intérieur ; les marges de cellules et informations sur les polices. Un complément de spécification traitant des feuilles de style précisera tout cela.

Les attributs frame et rules ont été modifiés afin d'éviter des conflits de noms SGML l'un avec l'autre, et pour éviter des conflits avec les attributs align et valign. Ces modifications ont été de plus motivées par notre désir de contourner des problèmes futurs si une extension de la présente spécification prévoyait d'associer des attributs frame et rules à d'autres constituants de tableaux.

Modification dans les formulaires 

Les formulaires définis par le HTML 3.2 connaissaient les problèmes suivants :

• Aucun mécanisme de raccourci clavier pour une action particulière, aucun raccourci clavier pour pilotage de menus, etc.
• Bien que les contrôles pussent être désactivés dynamiquement, ils ne pouvaient être déclarés comme tels à l'initialisation.
• Dans le même ordre d'idées, les contrôles de formulaires tels que champs de formulaires, ne pouvaient être en "lecture seule".
• Les labels des boutons radio et des cases à cocher n'étaient pas "sensibles", c'est-à-dire qu'un clic sur le label ne modifiait pas l'état du bouton.
• Il n'existait aucun moyen de rassembler des champs de formulaires de sorte que leur navigation soit plus ergonomique pour des agents utilisateurs à commande vocale.
• Il n'y avait aucun moyen de pouvoir vérifier les valeurs au fur et à mesure où elle étaient rentrées. La vérification était faite sur le serveur lors de la soumission du formulaire.
• Rien n'était prévu pour spécifier le type de fichiers lors de la soumission de fichiers pour téléchargement.
• Les formulaires ne pouvaient contenir que les deux boutons "submit" et "reset".
• Il n'y avait aucun moyen de spécifier quel jeu de caractère le serveur devait s'attendre à supporter.

Pour résoudre ces problèmes, cette spécification introduit de nouveaux attributs et éléments.

• L'attribut accesskey permet de définir des touches d'accès rapide à des contrôles de formulaire.
• L'attribut disabled permet aux concepteurs de formulaires d'afficher des champs qui sont inactifs au premier affichage du formulaire.
• Et grâce au nouvel attribut readonly, ces mêmes concepteurs pourront interdire la modification d'un champ.
• L'élément LABEL associe un label à un contrôle de formulaire particulier. L'élément FIELDSET groupe des champs de formulaires et, lequel groupe peut recevoir un nom par la définition de l'élément LEGEND. Ces deux éléments améliorent l'affichage et l'ergonomie. Les navigateurs vocaux pourront plus facilement décrire le formulaire. Les navigateurs visuels peuvent rendre le label sensible ou non.
• Une nouvelle palette d'azttributs, incluant onchange-INPUT, associé au support de langages de script, permettent aux concepteurs d'implémenter des fonctions de vérification de saisie.
• L'élément INPUT dispose d'un nouvel attribut accept qui permet aux auteurs de définir une liste de types de média acceptés pour cette entrée.
• Le nouvel élément BUTTON peut être utilisé pour concevoir des formulaires enrichis avec d'autres boutons que les deux seuls "submit" et "reset".
• L'élément FORM inclue l'attribut accept-charset, par analogie au champ d'en-tête HTTP "Accept-Charset" (Cf. [RFC2068]). Cet attribut (tout d'abord proposé dans la [RFC1867]) peut être utilisé pour définir une liste de jeux de caractères acceptables par les scripts serveurs destinés à traiter le formulaire.