Appendice B : Remarques sur les performances, l'implémentation et la conception

Les remarques suivantes sont informatives, non normatives. Malgré l'apparition de mots tels que « doivent » et « devrait », toutes les obligations dans cette section sont traitées ailleurs dans la spécification.

B.1 Remarques sur les documents invalides

Cette spécification ne définit pas la manière dont les agents utilisateurs conformes prennent en charge les situations d'erreur générales ni le comportement des agents utilisateurs en face d'éléments, d'attributs, de valeurs d'attribut ou d'entités qui ne sont pas spécifiés dans ce document.

Néanmoins, afin de faciliter la mise en œuvre et l'interopérabilité entre les implémentations de diverses versions de HTML, nous recommandons le comportement suivant :

• Si l'agent utilisateur rencontre un élément qu'il ne reconnaît pas, il devrait essayer de restituer le contenu de l'élément ;
• si l'agent utilisateur rencontre un attribut qu'il ne reconnaît pas, il devrait ignorer en entier la spécification de l'attribut (i.e., l'attribut et sa valeur) ;
• si l'agent utilisateur rencontre une valeur d'attribut qu'il ne reconnaît pas, il devrait utiliser la valeur par défaut de l'attribut ;
• s'il rencontre une entité non déclarée, l'entité devrait alors être traitée comme une donnée textuelle.

Nous recommandons également que les agents utilisateurs offrent les moyens de signaler ces erreurs aux utilisateurs.

Étant donné que les agents utilisateurs peuvent varier dont leurs façons de gérer les conditions d'erreur, les auteurs et les utilisateurs ne devraient pas compter sur un comportement spécifique de reprise sur incident [ndt. error recovery].

La spécification HTML 2.0 ([RFC1866]) observe que nombre d'agents utilisateurs HTML 2.0 considèrent un document qui ne commence pas par une déclaration de type de document comme se rapportant à la spécification HTML 2.0. Comme l'expérience le montre, c'est une supposition pour le moins faible, et la spécification courante ne recommande pas ce comportement.

Pour des raisons d'interopérabilité, les auteurs ne doivent pas « augmenter » HTML par le biais des mécanismes SGML disponibles (par exemple, en augmentant le DTD, en ajoutant un nouveau jeu de définitions d'entités, etc.).

B.2 Les caractères spéciaux dans les valeurs d'attribut URI

B.2.1 Les caractères non-ASCII dans les valeur d'attribut URI

Bien que les URI ne contiennent pas de valeur non-ASCII (voir [URI], section 2.1), les auteurs les spécifient parfois avec une valeur d'attribut attendant un URI (i.e., définies par %URI; dans le DTD). Par exemple, la valeur de l'attribut href suivante est illégale :

<A href="http://foo.org/Håkon">...</A>

Nous recommandons que les agents utilisateurs adoptent les conventions suivantes pour gérer les caractères non-ASCII dans de tels cas :

1. Représenter chaque caractère dans le jeu UTF-8 (voir [RFC2279]) en un ou plusieurs octets ;
2. échapper ces octets par le biais du mécanisme d'échappement d'URI (i.e., en convertissant chaque octet dans la forme « %HH », où « HH » représente la notation hexadécimale de la valeur d'octet).

Cette procédure aboutit à un URI syntaxiquement légal (comme défini dans les documents [RFC1738], section 2.2 ou [RFC2141], section 2) qui est indépendant de l'encodage de caractères dans lequel le document HTML porteur de l'URI peut avoir été codé.

B.2.2 Les esperluettes dans les valeurs d'attribut URI

L'URI qui est construit lors de la soumission d'un formulaire peut être utilisé comme un lien du genre ancre (par exemple, l'attribut href de l'élément A). Malheureusement, l'utilisation du caractère esperluette « & » pour séparer les champs du formulaire se confond avec son utilisation pour délimiter les références des entités de caractères dans les valeurs d'attribut SGML. Par exemple, pour utiliser l'URI "http://host/?x=1&y=2" comme URI reliant, celui-ci doit être écrit <A href="http://host/?x=1&#38;y=2"> ou <A href="http://host/?x=1&amp;y=2">.

Nous recommandons que les développeurs de serveurs HTTP et, en particulier, les développeurs de programmes CGI gèrent l'utilisation du caractère point-virgule « ; » à la place du caractère esperluette « & » pour épargner aux auteurs le souci d'échapper les caractères « & » de cette façon.

B.3 Remarques pour les implémentation SGML

B.3.1 Les sauts de ligne

SGML (voir [ISO8879], section 7.6.1) spécifie que le saut de ligne qui suit immédiatement une balise ouvrante doit être ignoré, tout comme le saut de ligne immédiatement avant une balise fermante. Ceci s'applique à tous les éléments HTML sans exception.

Les deux exemples HTML suivants doivent être restitués de manière identique :

<P>Thomas regarde la télé.</P>

<P>
Thomas regarde la télé.
</P>

De même pour les deux exemples suivants :

<A>Mon site favori</A>

<A>
Mon site favori
</A>

B.3.2 La spécification de données non-HTML

Les données de script et de style peuvent apparaître en contenu d'un élément ou en valeurs d'attribut. Les sections suivantes décrivent les limites entre le balisage HTML et les données étrangères.

Comme contenu d'élément 

Quand des données de script ou de style se trouvent en contenu d'un élément (SCRIPT et STYLE), les données commencent immédiatement après la balise ouvrante de l'élément et s'achèvent au premier d&eaute;limiteur ETAGO (« </ ») suivi par un caractère de début de nom ([a-zA-Z]) ; remarquez qu'il ne s'agira pas forcément de la balise fermante de l'élément. C'est pourquoi les auteurs devraient échapper les occurences de « </ » qui font partie du contenu. Les mécanismes d'échappement sont propres à chaque langage de script ou de feuille de style.

    <SCRIPT type="text/javascript">
      document.write ("<EM>Code qui ne fonctionne pas</EM>")
    </SCRIPT>

    <SCRIPT type="text/javascript">
      document.write ("<EM>Code qui fonctionne<\/EM>")
    </SCRIPT>

    <SCRIPT type="text/tcl">
      document write "<EM>Ce code fonctionne<\/EM>"
    </SCRIPT>

    "<EM>Ce code fonctionne<" & Chr(47) & "EM>"

Comme valeurs d'attributs 

Quand les données d'un script ou d'un style sont la valeur d'un attribut (qu'il s'agisse de l'attribut style ou des attributs d'événement intrinsèque), les auteurs devraient échapper les occurrences des guillemets délimiteurs simples ou doubles, dans la valeur, en fonction des conventions du langage de script ou de feuille de style. Les auteurs devraient également échapper les occurences des caractères esperluettes « & » si ceux-ci n'ont pas pour vocation de commencer une référence de caractère.

• Le caractère « " » devrait s'écrire « &quot; » ou bien « &#34; » ;
• le caractère « & » devrait s'écrire « &amp; » ou bien « &#38; ».

 <INPUT name="num" value="0"
 onchange="if (compare(this.value, &quot;aide&quot;)) {assistance()}">

B.3.3 Les fonctionnalités SGML dont la gestion est limitée

Les systèmes SGML conformes à la norme [ISO8879] sont censés reconnaître un certains nombres de fonctionnalités qui sont rarement gérées par les agents utilisateurs HTML. Nous recommandons aux auteurs d'éviter de faire appel à toutes ces fonctionnalités.

B.3.4 Les attributs booléens

Les auteurs devraient garder à l'esprit que nombre d'agents utilisateurs ne reconnaissent que la forme minimisée des attributs booléens et non la forme complète.

<OPTION selected>

<OPTION selected="selected">

B.3.5 Les sections marquées

Les sections marquées jouent un rôle similaire à la structure « #ifdef » reconnue par les pré-processeurs C.

<![INCLUDE[
 <!-- Ceci sera inclus -->
]]>

<![IGNORE[
 <!-- Ceci sera ignoré -->
]]>

SGML définit également l'utilisation de sections marquées pour un contenu de type CDATA, pour lequel le caractère « < » n'est pas considéré comme le début d'une balise, par exemple :

<![CDATA[
 <Un> exemple de balisage <sgml> qui n'est pas
 <fastidieux> à écrire avec < et autres.
]]>

Le signe révélateur qu'un agent utilisateur ne reconnaît pas une section marquée est l'apparition de la séquence « ]]> », qui est visible quand l'agent utilisateur prend par erreur le premier caractère « > » pour la fin de la balise commençant par la séquence « <![ ».

B.3.6 Les instructions de traitement

Les instructions de traitement sont le mécanisme par lequel capturer les idiomes propres de la plate-forme. Une instruction de traitement commence par la séquence « <? » et se termine par « > ».

<?instruction >

<?>
<?style tt = font courier>
<?saut de page>
<?experience> ... <?/experience>

Les auteurs devraient garder à l'esprit que nombre d'agents utilisateurs restituent les instructions de traitement comme faisant partie du texte du document.

B.3.7 Le balisage raccourci

Certaines structures SHORTTAG SGML épargnent de la saisie mais n'ajoutent pas de capacité expressive à l'application SGML. Même si ces structures n'introduisent techniquement aucune ambiguïté, elles réduisent la robustesse des documents, particulièrement quand il s'agit d'un langage amélioré pour inclure de nouveaux éléments. Ainsi, alors que les structures SHORTTAG de SGML relatives aux attributs sont largement utilisées et implémentées, celles relatives aux éléments ne le sont pas. Les documents qui les utilisent sont bien des documents SGML conformes mais ils ne vont vraisemblablement pas fonctionner avec nombre d'outils HTML existants.

Les structures SHORTTAG en question sont les suivantes :

B.4 Remarques pour aider les moteurs de recherche à indexer votre site Web

Cette section fait quelques suggestions simples qui vont rendre vos documents plus accessibles aux moteurs de recherche.

Définir la langue du document

Dans le contexte global du Web, il est important de savoir dans quelle langue la page est écrite. Ceci est expliqué dans la section traitant des indications de langue.

Spécifier les variantes de langue du document

Si vous avez préparé des traductions du document en d'autres langues, vous devriez utiliser l'élément LINK pour les référencer. Cela permet au moteur d'indexation d'offrir à l'utilisateur un résultat de recherche dans sa langue préférée, indépendamment de la manière dont la requête a été écrite. Par exemple, les liens suivants proposent des alternatives en français et en allemand au moteur de recherche :

<LINK rel="alternate"
         type="text/html"
         href="mondoc-fr.html" hreflang="fr"
         lang="fr" title="La vie souterraine">
<LINK rel="alternate"
         type="text/html"
         href="mondoc-de.html" hreflang="de"
         lang="de" title="Das Leben im Untergrund">

Fournir des mots-clés et des descriptions

Certains moteurs d'indexation cherchent les éléments META qui définissent une liste de mots-clés/phrases, séparés par des virgules, ou qui donnent une brève description. Les moteurs de recherche peuvent présenter ces mots-clés comme résultat de la recherche. La valeur de l'attribut name cherchée par le moteur de recherche n'est pas définie par cette spécification. Considérez ces exemples :

<META name="keywords" content="vacances,Grèce,soleil">
<META name="description" content="Vacances de rêve en Europe">

Indiquer le commencement d'une série

Les séries de documents ou de présentations issus de programmes de traitement de texte sont couramment traduites en séries de documents HTML. Il est peut être utile dans les résultats des recherches de signaler le début d'une série en supplément à la page atteinte par la recherche. Vous pouvez assister les moteurs de recherche en utilisant l'élément LINK avec une déclaration rel="start" en même temps que l'attribut title, comme dans :

 <LINK rel="start"
         type="text/html"
         href="page1.html"
         title="Théorie de la relativité générale">

Fournir aux robots des instructions d'indexation

Les personnes sont parfois surprises de constater que leurs sites ont été indexés par un robot d'indexation alors que le robot n'aurait pas du avoir la permission de visiter une partie sensible du site. Nombre de robots Web offrent des facilités aux gestionnaires de site Web et aux fournisseurs d'information pour limiter l'action du robot. On obtient ceci au moyen de deux mécanismes, le fichier « robots.txt » et l'élément META dans les documents HTML, qui sont décrits ci-dessous.

B.4.1 Les robots d'exploration

Le fichier robots.txt 

Quand un robot visite un site Web, disons « http://www.trucmuche.com/ », il vérifie d'abord l'adresse « http://www.trucmuche.com/robots.txt ». S'il peut trouver ce document, il analysera alors son contenu pour voir s'il est autorisé à ramener le document. On peut personnaliser le fichier « robots.txt » afin qu'il s'applique seulement à des robots particuliers et qu'il interdise l'accès à des répertoires ou des fichiers spécifiques.

Voici un exemple de fichier « robots.txt » qui empêche la visite du site entier à tous les robots.

        User-agent: *    # s'applique à tous les robots
        Disallow: /      # inactive l'indexation de toutes les pages

Le robot cherchera simplement un URI avec "/robots.txt" sur votre site, lequel site est défini comme un serveur HTTP fonctionnant sur un hôte et un numéro de port particuliers. Voici quelques exemples d'emplacements pour le fichier robots.txt :

Il ne peut y avoir qu'un seul « /robots.txt » sur un site. Spécifiquement, vous ne devriez pas placer de fichiers « robots.txt » dans les répertoires des utilisateurs, parce qu'un robot n'y regardera jamais. Si vous souhaitez que vos utilisateurs puissent créer leur propre fichier « robots.txt », il vous faudra tous les fusionner en un seul « /robots.txt ». Si vous ne souhaitez pas faire comme cela, vos utilisateurs pourraient employer la balise META pour les robots à la place.

Quelques trucs : les URI sont sensibles à la casse et la chaîne « /robots.txt » doit être entièrement en minuscules. Les lignes blanches ne sont pas admises au sein d'un seul enregistrement dans le fichier « robots.txt ».

Il ne doit y avoir qu'un seul champs « User-agent » exactement par enregistrement. Le robot devrait avoir une interprétation libre de ce champs. On recommande une correspondance sur la sous-chaîne du nom, insensible à la casse, sans l'indication de la version.

Si la valeur est « * », l'enregistrement décrit la politique des accès par défaut pour tout robot qui ne trouve pas de correspondance avec l'un des autres enregistrements. Il est interdit d'avoir plusieurs enregistrements de ce type dans le fichier « /robots.txt ».

Le champs « Disallow » spécifie un URI partiel qui ne doit pas être visité. Cela peut être un chemin complet ou un chemin partiel : aucun URI commençant par cette valeur ne sera ramené. Par exemple :

    Disallow: /aide inactive à la fois /aide.html et /aide/index.html, alors que
    Disallow: /aide/ inactiverait /aide/index.html mais pas /aide.html.

Une valeur vide pour «Disallow  » indique que tous les URI peuvent être ramenés. Il doit y avoir au moins un champs «Disallow  » dans le fichier « robots.txt ».

Les robots et l'élément META 

L'élément META permet aux auteurs HTML de dire aux robots en visite si le document peut être indexé ou utilisé pour récolter plus de liens. Aucune action de l'administrateur du serveur n'est nécessaire.

<META name="ROBOTS" content="NOINDEX, NOFOLLOW">

B.5 Remarques sur les tables

B.5.1 Les justifications de conception

Le modèle de la table HTML a pris forme à partir de l'étude des modèles de table SGML existants, du traitement des tables dans les suites de traitement de texte courantes et du large éventail des techniques de disposition tabulaire des magazines, des livres et des autres documents ayant un rapport avec le papier. Le modèle a été déterminé pour autoriser l'expression facile des tables simples en gardant une complexité supplémentaire si besoin était. Il permet une création réaliste du balisage des tables HTML à l'aide des éditeurs de texte courants et une courbe d'apprentissage réduite. Cette caractéristique a été un élément déterminant du succès de HTML jusqu'à ce jour.

De plus en plus, les personnes créent des tables par conversion à partir d'autres formats de document ou par création directe avec des éditeurs WYSIWYG. Il importe que le modèle de la table HTML corresponde parfaitement à ces outils d'édition. Celui-ci affecte la manière dont les cellules qui couvrent plusieurs rangées ou colonnes sont représentées et la manière dont l'alignement et les autres propriétés de présentation sont associés aux groupes de cellules.

Le reformatage dynamique 

Un aspect capital du modèle de la table HTML c'est que l'auteur ne contrôle pas la manière dont l'utilisateur va dimensionner la table, les polices que celui-ci utilisera, etc. C'est pourquoi il est risqué de compter sur des largeurs de colonne spécifiées en unités de pixels absolues. Au contraire, les tables doivent pouvoir changer de dimensions dynamiquement pour correspondre aux dimensions et aux polices de la fenêtre courante. Les auteurs peuvent fournir des indications sur les largeurs relatives des colonnes, mais les agents utilisateurs devraient s'assurer que les colonnes soient suffisamment grandes pour restituer en largeur le plus grand élément du contenu de la cellule. Si les spécifications de l'auteur devaient être surclassées, les largeurs relatives des colonnes individuelles ne devraient pas changer radicalement.

L'affichage progressif 

Pour les grandes tables ou les connexions au réseau lentes, l'affichage progressif de la table est un élément important de la satisfaction de l'utilisateur. Les agents utilisateurs devraient pouvoir commencer l'affichage de la table avant que toutes les données ne soient reçues. La largeur par défaut de la fenêtre pour la plupart des agents utilisateurs représente à peu près 80 caractères et les graphiques de nombreuses pages HTML sont conçus pour cette dimension. En spécifiant le nombre de colonnes et en incluant un matériel pour le contrôle de la largeur de la table et celles de différentes colonnes, l'auteur peut donner à l'agent utilisateur des indications qui permettent l'affichage progressif du contenu de la table.

Pour l'affichage progressif, le navigateur a besoin du nombre de colonnes et des largeurs de celles-ci. La largeur de la table par défaut vaut la taille de la fenêtre courante (width="100%"). Celle-ci peut être altérée par la spécification de l'attribut width de l'élément TABLE. Par défaut, toutes les colonnes ont la même largeur, mais vous pouvez spécifier les largeurs des colonnes au moyen d'un ou plusieurs éléments COL avant que les données proprement dites de la table n'arrivent.

Le problème qui subsiste c'est le nombre des colonnes. Certaines personnes ont suggéré d'attendre la réception de la première rangée de la table, mais cela pourrait prendre pas mal de temps si les cellules ont beaucoup de contenu. Globalement, il semble plus logique, pour un affichage progressif, d'obtenir des auteurs qu'ils spécifient explicitement le nombre des colonnes dans l'élément TABLE.

Les auteurs ont toujours besoin d'un moyen de signifier aux agents utilisateurs si ceux-ci doivent employer un affichage progressif ou bien redimensionner la table automatiquement pour loger le contenu des cellules. Dans le mode auto-ajusté en deux passes [ndt. two pass auto-sizing mode], le nombre des colonnes est déterminé par la première passe. Dans le mode progressif, le nombre de colonnes doit être déclaré avant (avec des éléments COL ou COLGROUP).

La structure et la présentation 

HTML distingue le balisage structurel, tels que les paragraphes et les citations, des idiomes de restitution, telles que les marges, les polices, les couleurs, etc. Dans quelle mesure cette distinction affecte-t-elle les tables ? Du point de vue du puriste, l'alignement du texte au sein des cellules de la table et les bordures entre les cellules sont des questions de restitution, non de structure. En pratique, cependant, il est utile de regrouper ces indications avec les informations structurelles, car ces caractéristiques sont facilement portables d'une application à l'autre. Le modèle de la table HTML reporte la plupart des indications de restitution sur les feuilles de style associées. Le modèle présenté dans cette spécification est conçu pour tirer partie de ces feuilles de style mais il ne les requiert pas.

Les logiciels de PAO courants offrent un contrôle approfondi de la restitution des tables et il serait irréaliste de vouloir le reproduire en HTML, sans transformer HTML en un format de texte enrichi encombrant comme RTF ou MIF. Cette spécification offre cependant aux auteurs la possibilité de choisir parmi un ensemble de classes couramment employées de style de bordure. L'attribut frame contrôle l'apparence du bord du cadre autour de la table, alors que l'attribut rules détermine le choix des règles à l'intérieur de la table. Un contrôle plus fin sera géré via des annotations de restitution. L'attribut style peut s'utiliser pour spécifier les indications de restitution des éléments individuels. On peut donner des indications de restitution supplémentaires avec l'élément STYLE dans l'en-tête du document ou via des feuilles de style reliées.

Au cours du développement de cette spécification, un certain nombre de voies ont été explorées pour définir les motifs des règles des tables. Une difficulté concerne les genres de déclarations qui peuvent être faites. L'inclusion d'une gestion de la soustraction des bords comme de leur addition conduit à des algorithmes relativement complexes. Par exemple, le travail permettant à l'ensemble complet des éléments de table d'inclure les attributs frame et rules a produit un algorithme faisant intervenir 24 étapes pour déterminer si un bord particulier d'une cellule devrait avoir une règle ou non. Cette complexité supplémentaire n'offre même pas un contrôle de la restitution suffisant pour répondre à l'éventail complet des besoins des tables. La spécification courante se cantonne délibérément à un modèle intuitif simple qui suffit pour la plupart des cas. Des travaux expérimentaux supplémentaires sont encore nécessaires avant qu'une approche plus sophistiquée ne soit normalisée.

Les groupes de rangées et de colonnes 

Cette spécification représente un sur-ensemble du modèle plus simple présenté dans les travaux précédents sur HTML+. Les tables sont considérées comme étant formées à partir d'une légende optionnelle en même temps que d'une succession de rangées, qui à leur tour sont constituées d'une succession de cellules de table. Le modèle fait en plus une distinction entre cellules de rubriques et cellules de données, et autorise les cellules à couvrir plusieurs rangées et colonnes.

Suivant en cela le modèle de la table CALS (voir [CALS]), cette spécification autorise le regroupement des rangées de la table en sections d'en-tête, de corps et de pied. Celui-ci simplifie la représentation des indications de restitution et il peut s'utiliser pour répéter les rangées d'en-tête et de pied lors de la rupture des tables hors des limites de la page ou pour donner un en-tête fixe au-dessus d'un panneau de corps défilant. Dans le balisage, la section de pied se place avant les sections de corps. C'est une optimisation partagée avec le modèle CALS pour traiter les très longues tables. Elle permet la restitution du pied sans devoir attendre le traitement entier de la table.

L'accessibilité 

Pour les déficients visuels, HTML apporte l'espoir de corriger les dommages causés par l'adoption d'interfaces utilisateurs graphiques basées sur des fenêtres. Le modèle de la table HTML comprend des attributs pour l'étiquetage de chaque cellule, pour gérer une conversion du texte vers la parole de qualité supérieure. On peut également employer les mêmes attributs pour gérer l'import et l'export des données de la table entre une base de données ou une feuille de calcul.

B.5.2 Les algorithmes de disposition recommandés

Si les éléments COL ou COLGROUP sont présents, alors ils spécifient le nombre des colonnes et la table peut être restituée à l'aide d'une disposition fixe. Sinon, c'est l'algorithme de disposition automatique, décrit ci-dessous, qui devrait être utilisé.

Si l'attribut width n'est pas spécifié, les agents utilisateurs visuels devraient supposer une valeur par défaut de 100% pour la mise en forme.

On recommande que les agents utilisateurs accroissent la largeur de la table au-delà de la valeur spécifiée par l'attribut width dans les cas où, sinon, le contenu de la cellule déborderait. Les agents utilisateurs qui passent outre la largeur spécifiée devrait le faire à dessein. Les agents utilisateurs peuvent choisir de répartir les mots sur plusieurs lignes pour éviter d'avoir un défilement horizontal excessif ou quand ce défilement est irréaliste ou non souhaitable.

Pour les besoins de la disposition, les agents utilisateurs devraient considérer que les légendes des tables (spécifiées par l'élément CAPTION) se comportent comme des cellules. Toute légende est une cellule qui couvre toutes les colonnes de la table, si elle se trouve en haut ou en bas de la table, ou toutes les rangées de la table, si elle se trouve à gauche ou à droite de la table.

L'algorithme de disposition fixe 

Pour cet algorithme, le nombre de colonnes est censé être connu. Les largeurs de colonne par défaut devraient avoir la même taille. Les auteurs peuvent surclasser ceci en spécifiant des largeurs de colonne relatives ou absolues, en utilisant les éléments COLGROUP ou COL. La largeur par défaut de la table correspond à l'espace entre les marges gauche et droite courantes, mais celle-ci peut être surclassée par l'attribut width sur l'élément TABLE, ou bien déterminée à partir des largeurs de colonne absolues. Pour traiter les mélanges de largeurs de colonne absolues et relatives, la première étape consiste à allouer un espace, provenant de la largeur de la table, aux colonnes qui ont des largeurs absolues. Ensuite, l'espace restant est réparti entre les colonnes qui ont des largeurs relatives.

La seule syntaxe de la table ne suffit pas à garantir la cohérence des valeurs des attributs. Par exemple, le nombre des éléments COL et COLGROUP peut être incompatible avec avec le nombre de colonnes impliqué par les cellules de la table. Un problème supplémentaire survient quand les colonnes sont trop étroites pour éviter le débordement du contenu des cellules. La largeur de la table, telle qu'elle est spécifiée par l'élément TABLE ou par les éléments COL, peut entraîner le débordement du contenu des cellules. On recommande que les agents utilisateurs essayent de se sortir de ces situations avec élégance, par exemple en effectuant la césure des mots et en recourant à la coupure des mots si les points de césure sont inconnus.

Au cas où un élément indivisible entraînerait le débordement de la cellule, l'agent utilisateur peut envisager le ré-ajustement des largeurs de colonne et le rafraîchissement de la table. Dans le pire des cas, le rognage peut être envisagé si les ajustements des largeurs de colonne et/ou le défilement du contenu de la cellule n'étaient pas faisables. Dans tous les cas, si le contenu de la cellule est séparé ou rogné, cela devrait être signalé à l'utilisateur de manière adéquate.

L'algorithme de disposition automatique 

Si le nombre de colonnes n'est pas spécifié par les éléments COL et COLGROUP, alors l'agent utilisateur devrait employer l'algorithme de disposition automatique suivant. Il utilise deux passes dans les données de la table et s'ajuste linéairement à la taille de la table.

Au cours de la première passe, la coupure de ligne est inactivée et l'agent utilisateur garde en mémoire la largeur minimum et maximum de chaque cellule. La largeur maximum est déterminée par la ligne la plus longue. Comme la coupure de ligne est inactive, les paragraphes sont considérés comme des longues lignes, à moins d'une rupture du fait d'un élément BR. La largeur minimum est déterminée par l'élément de texte le plus large (mot, image, etc.) en prenant en compte les indentations de tête et les puces des listes, etc. En d'autres termes, il est nécessaire de déterminer la largeur minimum dont aurait besoin une cellule placée dans sa propre fenêtre, avant que la cellule ne commence à déborder. Le fait d'autoriser l'agent utilisateur à séparer les mots diminuera le besoin de faire appel à un défilement horizontal ou, dans le pire des cas, à un rognage du contenu de la cellule.

Ce processus concerne également les éventuelles tables imbriquées qui apparaîtraient dans le contenu des cellules. Les largeurs minimum et maximum des cellules dans les tables imbriquées sont utilisées pour déterminer les largeurs minimum et maximum de ces tables et, de ce fait, de la cellule parente de la table elle-même. L'algorithme est linéaire avec un contenu de cellule composé et il est, généralement parlant, indépendant de la profondeur d'imbrication.

Pour venir à bout du caractère d'alignement du contenu des cellules, l'agent utilisateur garde en continu trois sommes min/max pour chaque colonne : à gauche du caractère d'alignement, à droite du caractère d'alignement et non aligné. La largeur minimum d'une colonne est alors : max(min_gauche + min_droite, min_non-aligné).

Les largeurs minimum et maximum des cellules sont alors utilisées pour déterminer les largeurs minimum et maximum correspondantes des colonnes. Celles-ci sont à leur tour utilisées pour trouver les largeurs minimum et maximum de la table. Remarquez que les cellules peuvent contenir des tables imbriquées, mais cela ne complique pas le code de manière significative. L'étape suivante consiste à assigner les largeurs aux colonnes en fonction de l'espace disponible (i.e., l'espace entre les marges gauche et droite courantes).

Pour les cellules qui couvrent plusieurs colonnes, une approche simple consisterait à proportionner équitablement les largeurs min/max entre chacune des colonnes constitutives. Une approche légèrement plus complexe serait d'utiliser les largeurs min/max des cellules non couvertes pour évaluer la manière dont les largeurs couvertes sont proportionnées. L'expérimentation suggère qu'un mélange de ces deux approches donne de bons résultats pour un large éventail de tables.

Les bordures et les marges intercellulaires de la table doivent être comprises lors de l'assignation des largeurs aux colonnes. Trois cas se présentent :

1. La largeur minimum de la table est égale ou est supérieure à l'espace disponible. Dans ce cas, assigner les largeurs minimum et permettre à l'utilisateur un défilement horizontal. Pour les conversions en Braille, il sera nécessaire de remplacer les cellules par des références aux notes donnant leur contenu entier. Par convention, ces notes apparaissent avant la table ;
2. La largeur maximum de la table tient dans l'espace disponible. Dans ce cas, donner aux colonnes leur largeur maximum ;
3. La largeur maximum de la table est supérieure à l'espace disponible, mais la largeur minimum de la table y est inférieure. Dans ce cas, établir la différence entre l'espace disponible et la largeur minimum de la table, appelons-la W. Appelons également D la différence entre la largeur maximum et la largeur minimum de la table.

   Pour chaque colonne, appelons d la différence entre la largeur maximum et la largeur minimum de la colonne en question. Maintenant, donnons à la colonne la largeur minimum, plus d fois W sur D. Ceci produit des colonnes avec une grande amplitude entre les largeurs minimum et maximum qui sont plus larges que les colonnes avec une amplitude plus faible.

Cette étape d'assignation est alors répétée pour les tables imbriquées, en utilisant les largeurs minimum et maximum déduites pour toutes ces tables lors de la première passe. Dans ce cas, la largeur de la cellule de table parente joue le rôle de la dimension de fenêtre courante dans la description ci-dessus. Ce processus se répète récursivement pour toutes les tables imbriquées. La table externe est alors restituée en utilisant les largeurs assignées. Les tables imbriquées sont ensuite restituées en tant que partie du contenu de la cellule de la table parente.

Si la largeur de la table est spécifiée avec; l'attribut width, l'agent utilisateur essaye d'ajuster les largeurs des colonnes pour y correspondre. L'attribut width n'est pas pris en compte si cela aboutit à des colonnes faisant moins que leur largeur minimum (i.e., indivisible).

Si des largeurs relatives sont spécifiées au moyen de l'élément COL, l'algorithme est modifié de manière à accroître les largeurs des colonnes par rapport à la largeur minimum pour satisfaire aux contraintes des largeurs relatives. Les éléments COL ne devraient être considérés que comme des indices, de sorte que les colonnes ne soient pas fixées avec une valeur moindre que leur largeur minimum. De la même façon, les colonnes ne devraient pas être si larges que la table s'étire bien au-delà des limites de la fenêtre. Si un élément COL spécifie une largeur relative de zéro, la colonne devrait toujours avoir sa largeur minimum.

Lors de l'utilisation de l'algorithme en deux passes, la position d'alignement par défaut, en l'absence d'un attribut charoff explicite ou hérité, peut se déterminer en choisissant la position qui centreraient les lignes, pour laquelle les largeurs avant et après le caractère d'alignement sont à la valeur maximale pour chacune des lignes dans la colonne avec la déclaration align="char". Pour une dispositon de table progressive, la valeur par défaut suggérée est charoff="50%". Si plusieurs cellules, dans différentes rangées de la même colonne, utilisent un caractère d'alignement, toutes ces cellules en question devraient s'aligner, indépendamment du caractère utilisé pour l'alignement. Les règles de prise en charge des objets trop grands pour une colonne s'appliquent quand l'alignement explicite ou implicite aboutit à une situation dans laquelle les données excèdent la largeur assignée à la colonne.

B.6 Remarques sur les formulaires

B.6.1 L'affichage progressif

L'affichage progressif des documents qui sont en cours de réception à partir du réseau soulève certains problèmes en ce qui concerne les formulaires. Les agents utilisateurs devraient empêcher la soumission d'un formulaire tant que tous les éléments du formulaire n'ont pas été reçus.

L'affichage progressif des documents soulève certaines questions vis-à-vis de la navigation par tabulation. L'heuristique pour donner l'attention à l'élément ayant la plus petite valeur pour l'attribut tabindex dans le document semble raisonnable au premier abord. Cependant, cela implique d'attendre que tout le texte du document soit reçu, puisque jusqu'alors la plus petite valeur de l'attribut tabindex peut encore changer. Si l'utilisateur frappe la touche de tabulation avant ce moment, il est raisonnable que les agents utilisateurs déplacent l'attention sur la plus petite valeur tabindex couramment disponible.

Si le formulaire est associé à un script côté client, cela peut entraîner d'autres problèmes potentiels. Par exemple, le gestionnaire de script d'un champs donné peut se référer à un champs qui n'existe pas encore.

B.6.2 Les évolutions futures

Cette spécification définit un ensemble d'éléments et d'attributs qui sont suffisamment puissants pour satisfaire les besoins généraux pour la production de formulaires. Cependant, il y a toujours de la place pour nombre d'améliorations possibles. Par exemple, les problèmes suivants pourraient être résolus dans le futur :

• L'éventail des types de champs de formulaire est trop limité par rapport aux interfaces utilisateurs modernes. Par exemple, il n'y a aucune mesure pour les entrées de données tabulaires, les cases de défilement [ndt. sliders] ou les dispositions de page multiple ;
• les serveurs ne peuvent pas mettre à jour les champs d'un formulaire soumis et, au lieu de cela, ils doivent renvoyer un document HTML entier, entraînant le papillotement de l'écran 
• les points précédents entraînent également des problèmes pour les navigateurs vocaux, rendant l'interaction avec un formulaire difficile aux déficients visuels.

Une autre extension possible serait l'ajout de l'attribut usemap à l'élément INPUT en utilisation comme image cliquable côté client pour une déclaration "type=image". L'élément AREA correspondant à l'emplacement cliqué contribuerait à passer cette valeur au serveur. Pour éviter d'avoir à modifier les scripts du serveur, il peut être approprié de renforcer l'élément AREA pour qu'il fournisse les valeurs « x » et « y » à utiliser avec l'élément INPUT.

B.7 Remarques sur les scripts

B.7.1 La syntaxe réservée pour les macrocommandes de script futures

Cette spécification réserve une syntaxe pour la gestion future des macrocommandes de script dans les attributs HTML du type CDATA. L'intention est de permettre la spécification des attributs en fonction des propriétés des objets qui apparaissent plus tôt dans la page. La syntaxe est la suivante :

   attribut = "... &{ corps de la macrocommande }; ... "

Les pratiques courantes pour les macrocommandes de script 

Le corps de la macrocommande est constitué d'une ou plusieurs déclarations dans le langage de script par défaut (selon les attributs d'événement intrinsèque). Le point-virgule « ; » qui suit l'accolade fermante « } » est toujours nécessaire car, sinon, ce caractère accolade droite « } » est considéré comme faisant partie du corps de la macrocommande. Il est intéressant de remarquer que les guillemets sont toujours nécessaires pour les attributs contenant des macrocommandes de script.

Le traitement des attributs de type CDATA se déroule de la façon suivante :

1. L'analyseur SGML évalue les éventuelles entités SGML (par exemple, "&gt;") ;
2. Puis les macrocommandes de script sont évaluées par le moteur de script ;
3. Enfin, la chaîne de caractères résultante est passée à l'application pour le traitement suivant.

Le traitement des macrocommandes intervient lors du chargement (ou du déchargement) du document, mais n'est pas réitéré quand le document est redimensionné, rafraîchi, etc.

    <BODY bgcolor='&{randomrgb};'>

    <BODY bgcolor='&{if(Date.getHours > 18)...};'>

 <MAP NAME=foo>
   <AREA shape="rect" coords="&{myrect(imageuri)};" href="&{myuri};" alt="">
 </MAP>

    <IMG src="bar.gif" width='&{document.banniere.width/2};' height='50%' alt="banni&egrave;re">

 <SCRIPT type="text/javascript">
   function fabricant(gadget) {
       ...
   }
   function localisation(fabricant) {
       ...
   }
   function logo(fabricant) {
       ...
   }
 </SCRIPT>
  <A href='&{localisation(fabricant("gadget"))};'>gadget</A>
  <IMG src='&{logo(fabricant("gadget"))};' alt="logo">

   <IMG src="&{logo(fabricant(&quot;gadget&quot;))};" alt="logo">

B.8 Remarques sur les cadres

Étant donné qu'il n'y a aucune garantie pour que le nom d'un cadre cible soit unique, il est approprié de décrire la pratique courante pour trouver un cadre en fonction d'un nom de cible :

1. Si le nom de cible est un mot réservé, tel que décrit dans la partie normative, l'appliquer comme tel ;
2. Sinon, effectuer une première recherche en profondeur de la hiérarchie du cadre dans la fenêtre qui contenait le lien. Utiliser le premier cadre dont le nom correspond exactement ;
3. Si, au cours de l'étape (2), on ne trouve pas un tel cadre, appliquer à nouveau l'étape (2) à chaque fenêtre, de l'avant vers l'arrière. S'arrêter dès la rencontre d'un cadre ayant exactement le même nom ;
4. Si l'étape (3) n'aboutit pas, créer une nouvelle fenêtre et lui assigner ce nom de cible.

B.9 Remarques sur l'accessibilité

L'initiative pour l'accessibilité au Web du W3C ([WAI]) est en train de produire une série de principes directeurs pour améliorer l'accessibilité au Web pour les personnes avec des déficiences physiques. Il y a trois jeux de principes directeurs :

• Les principes directeurs pour l'accessibilité du contenu Web ([WCGL]), pour les auteurs et les gestionnaires de sites. Veuillez consulter les principes directeurs pour l'accessibilité du contenu Web concernant la fourniture d'un texte de remplacement pour les images, les applets, les scripts, etc.
• les principes directeurs pour l'accessibilité des agents utilisateurs ([UAGL]), pour les développeurs des agents utilisateurs (navigateurs, visualiseurs multimédias, technologies d'assistance). Veuillez consulter ces principes directeurs pour la conduite à suivre dans la gestion d'un texte de remplacement 
• les principes directeurs pour l'accessibilité des outils d'édition ([ATGL]), pour les développeurs des outils d'édition.

B.10 Remarques sur la sécurité

Les ancres, les images incorporées et tous les autres éléments qui contiennent un URI en paramètre peuvent provoquer la résolution de l'URI, en réponse à une entrée de l'utilisateur. Auquel cas, les questions de sécurité dans le document [RFC1738], section 6, devraient être considérées. Les méthodes très répandues pour la soumission des requêtes de formulaire, à savoir HTTP et SMTP, offrent peu de garantie de confidentialité. Les fournisseurs d'information, qui demandent des informations sensibles via un formulaire, particulièrement au moyen de l'élément INPUT et de la déclaration type="password", devraient avoir conscience de cette absence de confidentialité et en prévenir leurs utilisateurs.

B.10.1 Les problèmes de sécurité des formulaires

L'agent utilisateur ne devrait pas envoyer un fichier qui n'aura pas été explicitement demandé à l'utilisateur. Les agents utilisateurs HTML sont donc censés confirmer tous les noms de fichier par défaut qui pourrait être suggérés par l'attribut value de l'élément INPUT. Les commandes cachées ne doivent pas spécifier de fichiers.

Cette spécification ne comprend pas de mécanisme pour le cryptage des données : ceci devrait être pris en charge par les autres mécanismes en place, quels qu'ils soient, pour la transmission sécurisée des données.

Une fois que le fichier est chargé sur le serveur, l'agent de traitement devrait le traiter et l'enregistrer de manière adéquate.