Sommaire
Les notes suivantes ne sont données qu'à titre d'information, et ne présentent aucun caractère obligatoire ni normatif.
Cette section expose quelques astuces pour que les robots de recherche puissent plus facilement et plus efficacement indexer les documents d'un site Web.
<LINK rel="alternate" href="mondoc-fr.html"
lang="fr" title="La vie souterrainne">
<LINK rel="alternate" href="mondoc-de.html"
lang="de" title="Das Leben im Untergrund">
<META name="keywords" content="vacances,Grèce,soleil"> <META name="description" content="Vacances européennes idyliques">
<LINK rel="begin"
href="page1.html"
title="Théorie générale de la relativité">
Lorsqu'un Robot visite un site Web, disons http://www.foobar.com/, il recherche tout d'abord une occurence d'un fichier http://www.foobar.com/robots.txt. S'il peut trouver ce document, il analysera son contenu pour déterminer s'il peut indexer le contenu du site. Vous pouvez modifier ce fichier robots.txt de façon qu'il ne s'applique qu'à certains robots, ou rendre invisibles certains documents ou fichiers.
Voici un exemple de fichier robots.txt qui empêche tout robot de venir visiter la moindre partie du site :
User-agent: * # s'applique à tous les robots
Disallow: / # interdit l'indexation à partir de la racine du site
Le robot va simplement rechercher une URL "/robots.txt" sur votre site, ce site étant défini comme un serveur HTTP exécuté sur un hôte défini sur un port particulier. Voici par exemple des exemples de "sites" pour un fichier robots.txt:
| Site URL | URL for robots.txt |
|---|---|
| http://www.w3.org/ | http://www.w3.org/robots.txt |
| http://www.w3.org:80/ | http://www.w3.org:80/robots.txt |
| http://www.w3.org:1234/ | http://www.w3.org:1234/robots.txt |
| http://w3.org/ | http://w3.org/robots.txt |
Il ne peut y avoir qu'un seul "/robots.txt" par site. En particulier, vous ne pourrez pas écrire des fichiers "robots.txt" dans les répertoires de vos utilisateurs, car un robot n'ira jamais les y rechercher à cet endroit. Si vous souhaîtez que vos utilisateurs puissent créer leur propre définition de type "robots.txt", vous devrez les collecter et les rassembler dans un fichier "/robots.txt" à la racine serveur. Si vous voulez éviter cela, vos utilisateus pourront utiliser la balise META propres aux robots à la place.
Quelques astuces : les URL dépendent de la casse, et la chaîne "/robots.txt" doit être en minuscules. Les lignes vides ne sont pas permises dans ce fichier.
Il ne peut y avoir qu'un champ "User-agent". Le robot devra interpréter ce champ de façon la plus libérale possible. Une correspondance sans tenir compte ni de la casse ni du numéro de version est vivement conseillée ici.
Si la valeur vaut "*", l'enregistrement définit les autorisations d'accès pour tout robot qui n'a pas été identifié dans un des précédents enregistrements du fichier. Il ne peut y avoir qu'un enregistrement de ce type dans un fichier "/robots.txt".
Le champ "Disallow" spécifie par une URL partielle les sectionn qui ne doivent pas être visitées. Celles-ci peuvent désigner un répertoire dans son ensemble, ou un chemin d'accès partiel, et toute URL commençant par cette valeur ne sera pas indexée. Par exemple,
Disallow: /help interdit l'indexation de /help.html et de /help/index.html, alors que
Disallow: /help/ interdirait l'indexation de /help/index.html mais autoriserait
celle de /help.html.
Une valeur vide d'un champ "Disallow" indique que toutes les URL peuvent être visitées. On marquera au moins une déclaration "Disallow" dans un fichier robots.txt.
L'élément META permettra aux auteurs de documents HTML d'indiquer à partir de ce dernier si le document peut être indexé, ou utilisé pour accéder à d'autres ressources. Par ce biais, aucune action de l'administrateur du serveur n'est nécessaire.
Dans l'exemple qui suit, un robot se verrait interdire l'indexation de ce document, et ne pourrait en suivre les liens.
<META name="ROBOTS" content="NOINDEX, NOFOLLOW">
La liste des termes admis dans le contenu esgt ALL, INDEX, NOFOLLOW et NOINDEX. Le nom et l'attribut de contenu sont indépendants de la casse.
Note : Dans les débuts de 1997, les robots implémentant ceci étaient peu nombreux, mais ceci devrait changer car le contrôle de l'indexation du Web fait aujourd'hui l'objet d'une attention grandissante.
Le modèle des tableaux HTML a évolué en tenant compte d'études sur les modèles de tableaux en SGML, le traitement des tableaux dans de nombreux outils de traitement de texte, ainsi que l'étude de nombreuses techniques de présentation tabulée dans les magazines, et autre documents papier. Le modèle choisi devait permettre une expression initialement simple d'un tableau de base, avec la possibilité de complexifier sa définition si besoin. Ceci rendrait pratique l'écriture du balisage de ces tableaux à partir d'éditeurs d'aujourd'hui et réduirait le temps d'apprentissage minimal pour pouvoir correctement travailler avec ces éléments. C'est cette volonté générale qui a présidé au succès de HTML jusqu'à aujourd'hui.
De plus en plus souvent, les tableaux sont créés par conversion à partir d'autre formats de document ou par création directe sur des éditeurs WYSIWYG (What You See Is What You Get). Il est important que le modèle de tableaux d'HTML soit cohérent avec celui de ces outils de production documentaire. Ceci affecte plus particulièrement la manière dont les cellules qui s'étalent sur plusieurs colonnes ou lignes sont représentées, et comment l'alignement ou autres propriétés de présentation peuvent être assignés à des groupes de cellules.
Une des considérations majeures à avoir été pris pour le modèle des tableaux HTML a été le fait que l'auteur ne contrôle en rien la façon dont l'agent utilisateur va redimensionner le tableau, quelles seront les polices utilisées, etc. Il eszt donc risqu" de ne se fier qu'à une définition absolue de colonnes spécifées en pixels. Au lieu de cela, les tableaux devront pouvoir être redimensionnés dynamiquement pour s'adapter à toutes les conditions de fenêtres et de taille de polices. Les auteurs devraient pouvoir donner des indications sur la répartition relative des colonnes, et les agents utilisateurs quant à eux, devront s'assurer que la colonne est suffisament large pour pouvoir afficher l'objet le plus large de son contenu. Si les spécifications de l'auteur devaient être ignorées ou contrariées, il serait de bon ton que le rapport relatif des colonnes ne soit pas altéré du tout au tout.
Dansle cas de grands tableaux, ou de connexions réseau à très basse vitesse, un affichage partiel d'un tableau est souhaitable pour éviter la frustration de l'utilisateur. Les agents utilisateur devront être capables de commencer à afficher un tableau avant même que toutes ses données n'aient été reçues. La largeur par défaut de nombreux agents utilisateurs permet en général un affichage de 80 caractères, et la conception de nombreuses pages HTML se base souvent sur ce format de base. En spécifiant le nombre de colonnes, et en y adjoignant des informations concernant la largeur du tableau, et les largeurs relatives des colonnes, les auteurs pourront donner des indications précieuses aux agents utilisateurs qui pourront les utiliser pour commencer à afficher les tableaux plus rapidement.
Pour l'affichage progressif, le navigateur a besoin de savoir le nombre de colonnes et leur largeur. La largeur par défaut du tableau est la largeur de la fenêtre (width="100%"). Ceci peut être contredit par un attribut width-TABLE de l'élément TABLE. Par défaut, toutes les colonnes ont la même largeur, mais vouspourrez spécifier des largeurs de colonnes diférentes avec des éléments COL avant même le début des données du tableau.
Le dernier problème reste le nombre effectif de colonnes. Certains ont pensé attendre l'arrivée de la première ligne du tableau, mais cela peut prendre beaucoup de temps si les cellules ont un contenu de grande taille. D'un autre côté, il devient sensé, lorsque l'on souhaite déclencher l'affichage progressif, de demander aux auteurs d'expliciter effectivement le nombre de colonnes dans l'élément TABLE.
Les auteurs auront toujours besoin de pouvoir explicitement indiquer si l'affichage progressif doit être effectué ou permettre au tableau de se dimensionner automatiquement suivant le contenu des cellules. Dans le mode d'autodimensionnement en deux passes, le nombre de colonnes est déterminé dès la première passe. ans le mode progressif, le nombre de colonnes doit être tout de suite connu. Il semble plus sensé d'utiliser alors l'attribut cols indiquant le nombre de colonnes plutôt qu'un attribut de "layout" (ex., un éventuel layout="fixed" ou layout="auto").
HTML distingue le balisage de structure tel que marquage de paragraphes ou de citations du balisage de présentation tel que marges, polices, couleurs, etc. Comment cette distinction affecte les tableaux ? Du point de vue du puriste, l'alignement du texte à l'intérieur des cellules d'un tableau et les gouuttières entre cellules sont de l'ordre de la présentation, et non de la structure. En pratique cependant, il sera utile de grouper ces paramètres avec des informations de structure, du fait que ces définitions sont transmissibles sans difficulté entre applications. Le modèle de tableaux d'HTML laisse le soin de la définition de la plupart des atributs de présentation aux feuilles de style associées au document. Le modèle présenté dans ce document est conçu pour tirer le meilleur parti de ces feuilles de style, mais n'en n'impose pas l'usage.
Les ensembles actuels de bureautique proposent de nombreux paramètres d'enrichissement de la présentation des tableaux, et il serait illusoire et peu pratique de vouloir les représenter toutes en HTML sans transformer le HTML en un langage de formatage opaque tel que RTF ou MIF. Cette spécification permet cependant aux auteurs de faire une sélection parmi un certain nombre de syles de bordures prédéfinies et courantes. L'atribut frame contrôle l'apparence des bordures autour du tableau tandis que l'attribut rules influe sur le type de gouttières utilisées entre les cellules. Un niveau de contrôle plus fin sera obtenu par un certain nombre d'annotations d'affichage. L'attribut style pourra servir à apporter des informations de présentation supplémentaires pour des éléments individuels. Les paramètres de présentation seront alors définis en détail via des éléments STYLE placés dans l'en-tête du document ou des feuilles de style externes associées.
Durant la mise en place de cette spécification, un certain nombre de solutions ont été envisagées pour définir les règles d'encadrement des tableaux. L'un des problèmes concernait le type d'instructions pouvant être écrites. Inclure un support fin des superpositions d'ajout et de retrait de bordure conduisait à écrire un algorithme relativement complexe. Par exemple, notre travail sur un ensemble d'éléments complet incluant les attributs frame et rules conduisirent à la mise en oeuvre d'un algorithme à 24 étapes pour déterminer si une bordure particulière de cellule devait être visible ou non. Même cette complexité supplémentaire n'arrivait pas à répondre à tous les cas de figure supposés apparaître lors de la définition d'un tableau. La spécification actuelle s'impose délibérément de redescendre sur un modèle plus intuitif, et qui se révélera suffisant pour la plupart des cas de figure. Un travail compplémentaire nous attend avant qu'un définition plus complexe ne puisse être standardisée.
Cette spécification propose un surensemble du modèle le plus simple présenté dans des travaus antérieurs sur HTML+. Les tableaux étaient considérés être formés d'un titre, lequel était suivi d'un certain nombre de lignes, qui à leur tour étaient considérés comme des séries de cellules. Le modèle suivant différenciait les cellules de titre des cellules de données, et permettait aux cellules de s'étaler sur plusieurs lignes ou colonnes.
En suivant le modèle des tableaux CALS (Cf. [CALS]), cette spécification permet aux lignes de tableaux d'être groupées en sections d'en-tête, de piettement et de corps de table. Ceci simplifie la spécification des paramètres de présentation et permet de pouvoir répéter des en-têtes et des piettements de tableaux lorsque l'affichage de celui-ci se fait sur plusieurs pages ou écrans, ou encore de pouvoir laisser une en-tête constante sur un corps de table défilant. Dans le balisage, la section piettement apparaît avant le corps de tableau. Il s'agit d'une optimisation que nous partageons avec CALS pour traiter efficacement les très longs tableaux. Elle permet de commencer à afficher "l'environnement" des données avant que toutes ces dernières ne soient reçues.
Pour les malvoyants, le HTML porte l'espoir de voir réparé le préjudice subi par l'adoption généralisée d'interfaces graphiques fenêtrées et "visuelles". Le modèle de tableaux du HTML include des attributs qui permettent d'étiquetter chaque cellule, ce qui sera utile pour des navigateurs à synthèse vocale. Ces mêmes attributs pourront également servir à la programmation de fonctions d'inmport et d'export automaitsées à partir de bases de données ou de tableurs.
Si l'attribut cols de l'élément TABLE indique un nombre de colonnes, alors le tableau peut être mis en page sur une base bien déterminée, autrement l'algorithme de diùmensionnement automatique ci-dessous pourra être utilisé.
Si l'attribut width n'est pas spécifié, les agents visuels considèreront par défaut une valeur de 100% pour cet attribut.
Nous recommandons que les agents utilisateurs augmentent d'aux-même la largeur du tableau au delà de la valeur spécifiée par width dans le cas où certains contenus de cellules seraient susceptibles de "dépasser". Les agents utilisateurs qui décident d'outrepasser cette valeur devront user de cette faculté avec raison. Il devront aussi penser à couper des lignes de texte dans le cas où les lignes originales demanderaient un défilement horizontal excessif, ou lorsque ce défilement n'est pas pratique voire possible.
On supposera pour cet algorithme que le nombre de colonnes est connu à l'avance. Par défaut, toutes les largeurs de colonnes seront fixées à la même taille. Les auteurs pouront contrarier ce comportement en définissant des largeurs relatives différentes, ou en fixant certaines colonnes à des largeurs absolues, via les éléments COLGROUP ou COL. La largeur de table par défaut est déterminé par l'espace situé entre la marge gauche et la marge droite du canvas courant, mais pourra être contrariée par l'attribut width de l'élément TABLE, ou encore déterminé comme la somme de colonnes de largeurs absolues. Pour gérer le mélange de définitions relatives et absolues de colonens dans un tableau, la première étape consistera à soustraire de l'espace disponible celui occupé par toutes les colonnes de largeur absolue. Une fois cette préréservation effectuée, le reste de l'espace disponible sera réparti entre les colonnes "relatives".
La syntaxe des tableaux seule ne suffit pas à garantir la consistance des valeurs d'attributs. Par exemple, le nombre de colonnes spécifiées par l'attribut cols peut contredire le nombre des colonnes définies par des éléments COL. Cette valeur peut à son tour se révéler incohérente avec la détermination effective du nombre des colonnes par comptage dans les lignes. Un autre problème rencontré est lorsque les largeurs de colonnes déterminées sont trop faibles pour éviter que des contenus n'en débordent. La largeur du tableau telle que définie dans l'élément TABLE ou la somme des éléments COL peut conduire à une telle situation. Il est conseillé que les agents utilisateurs sachent se sortir élégament de telles situations, par exemple, en effectuant une césure des mots.
Au cas où un élément indivisible provoquerait le débordement, l'agent utilisateur devra prévoir le réajustement des largeurs de colonnes et le raffraîchissement de l'écran. Dans le pire des cas, on considèrera le rognage des éléments comme dernier rempart si d'autres ajustements, ou le défilement de cellules ne sont pas possibles. Dans tous les cas, si le contenu est coupé ou rogné, l'agent utilisateur devra trouver un moyen d'en informaer l'utilisateur de façon explicite.
Si l'attribut COLS n'apparaît pas dans la balise de début de définition du tableau, alors l'agent utilisateur pourra utiliser l'algorithme de redimensionnement automatique suivant. Il consiste en deux passes d'analyse des données du tableau et s'adapte linéairement à la taille détectée.
La première passe désactive les reports à la ligne, et l'agent utilisateur enregistre les tailles minimale et maximale de chacune des cellules. La largeur d'une colonne est déterminée comme la largeur "la pire", c'est à dire celle de la cellule dont le contenu demande le plus d'espace. comme le report de ligne est désactivé, les paragraphes sont traités comme des lignes longues, sauf si un retour à la ligne explicite (élément BR) y est inclus. La largeur minimum est donnée par l'élément de cellule le plus large (texte, image, etc.) en comptant les indentations de titres ou les puces, etc. Autrement dit, il est nécessaire de savoir la largeur qu'occuperait le contenu dans une fenêtre autonome avant de commencer à reboucler à la ligne. Permettre aux agents utilisateur de couper les lignes permettra de diminuer le défilement horizontal, ou dans le pire des cas, évitera que des cellules ne soient rognées.
Ce procédé s'appliquera de même à tous les tableaux imbriqués dans une cellule d'un tableau de niveau supérieur. Les largeurs miniamle et maximale des colonnes de la table imbriquée dépendront de ce qui est nécessairepour le tableau en tenant compte des largeurs minimale et maximale permises pour la cellule qui contient ce tableau. L'algorithme dépend linéairement de l'aggrégation du contenu de cellule, et dans le sens général, est indépendant du degré d'imbrication.
Pour remplir les conditions d'alignement des caractères dans les cellules, l'algorithme calcule trois totalisations min/max pour chaque colonne : caractères à gauche de la position d'alignement, caractères à droite de la position d'alignement et caractères non alignés. la largeur minimale de cette colonne sera alors le résultat de : max(min_left + min_right, min_non-aligned).
Les largeurs minimale et maximale de cellules sont alors utilisées pour déterminer les largeurs minimale et maximale des colonnes, lesquelles serviront alors à déterminer les largeurs minimale et maximale du tableau. Notez que les cellules peuvent contenir des tableaux imbriqués, mais cela ne complique pas le code de façon significative. La prochaine étape consiste à assigner aux colonnes une certaine portion de l'espace disponible (c'est-à-dire, l'espace compris entre les marges gauche et droite courantes).
Pour les cellules qui s'étalent sur plusierus colonnes, une approche simple (celle utilisée par Arena) consiste à répartir les valeurs min/max équitablement entre les colonnes. Une approche légèrement plus complexe est d'utiliser les valeurs min/max des cellules monocellulaires pour pondérer la répartition précédente. L'expérimentation suggère qu'un mélange des deux approches donne d'excellents résultats pour la grande majorité des tableaux.
Les bordures de cellules et marges intracellulaires doivent être prises en compte dans le calcul de la répartition de largeur. Il existe trois cas :
Pour chaque colonne, disons que d soit la différence entre son maximum et son minimum. Réglons alors la colonne sur son minimum plus d fois W / D. Ceci permet de répartir le surplus de place disponible par rapport au tableau minimum en privilégiant les colonnes plus larges.
Cette étape de détermination des largeurs doit être répétée pour tous les tableaux imbriqués en leur associant les valeurs minimales et maximales déterminées à la passe sur le niveau supérieur. Dans ce cas, la largeur de la cellule du tableau parent (c'est-à-dire, celle qui englobe) joue le rôle de la fenêtre courante dont la largeur calculée précédemment sera prise comme référence. Ce procédé est répété récursivement sur toute la profondeur d'imbrication de tableaux. Le tableau le plus extérieur est alors représenté en fonction de ce qui est établi. Les tableaux internes sont successivement représentés.
Si la largeur du tableau est spécifiée par un attribut width, l'agent utilisateur tentera de régler la largeur des colonnes pour respecter cette contrainte. L'attribut width ne peut être respecté si les largeurs qui en résulteraient sont inférieures aux largeurs minimales (c'est-à-dire la largeur de l'élément indivisible le plus large).
Si des indications de largeurs relatives sont indiquées par des éléments COL, l'algorithme est modifié de façon à augmenter la largeur des cellules à partir de leur largeur minimale jusqu'à remplir les conditions relatives. Les éléments COL ne devront être considérées que comme des recommandations, indiquant que ces colonnes ne peuvent être moins large que les valeurs préconisées. Si un élément COL element spécifie une largeur relative de zéro, la colonne correspondante devra être réglée à la valeur minimale calculée.
Lorsque l'algorithme de redimensionnement à deux passes est utilisé, la position d'alignement par défaut en l'absence de définition ou d'héritage de tout attribut charoff peut être déterminée en choisissant la position qui centrerait les lignes pour lesquelles le nombre de caractères avant et après le caractère d'alignement est le maximum dans la colonne des cellules pour lesquelles align="char". Lors de la mise en page progressive, la valeur par défaut suggérée est charoff="50%". Si plusieurs cellules dans différentes lignes d'une même colonne exploitent l'alignement sur caractère, alors par défaut, toutes ces cellules devront être alignées entre elles, quel que soit le caractère sur lequel se fait cet alignement. Les règles qui permettent de gérer des objets trop grands pour la colonne s'appliquent lorsque le résultat de l'alignement n'est plus compatible avec les largeurs de ces objets.
Choix des noms d'attributs. Il eut été préférable de choisir des valeurs d'attribut frame cohérentes avec les attributs rules et les valeurs d'alignement choisies. Par exemple : none, top, bottom, topbot, left, right, leftright, all. Malheureusement, le SGML nécessite que les valeurs d'attributs énumérées soient uniques pour chaque élément, et indépendentes du nom de l'attribut. Le problème pour les tokens "none", "left", "right" et "all" est trivial. Les valeurs d'attribut frame ont été choisies pour éviter un conflit avec celles des atributs rules, align et valign-COLGROUP. Ceci permet de fiabiliser la certification, et anticipe le fait que les attributs frame et rules seront certainement ajoutés à d'autres éléments dans des futures versions de cette spécification. Un alternative serait de transformer le type de l'attribut frame en un CDATA. Le consensus adopté par le groupe de travail HTML du W3C s'est basé sur les avantages que procurent l'usage d'outils de vérification et certification SGML, lesquels sont plus simples à mettre en oeuvre lorsque les valeurs sont à choisir dans une énumération.
Certaines personnes ont émis des doutes concernant les performances des feuilles de style. Par exemple, le fait de lier une feuille de style externe pourrait ralentir le retard du premier affichage. Une situation similaire pourrait être le fait d'une très grande quantité de définitions stylistiques dans une en-tête de document.
La présente proposition s'attaque à ces problèmes en permettant aux auteurs d'inclure des instructios de présentation au niveau des éléments HTML eux-mêmes. L'information de présentation sera alors disponible dès le moment où l'agent utilisateur est sensé en avoir besoin.
Dans de nombreux cas, les auteurs verront un avantage évident à mettre en commun des définitions de style pour une série de documents similaires. Dans ce cas, la distribution des informations de style à travers tout le document sera certainement d'une moins bonne performance que l'usage d'une feuille de style externe, car pour la plupart de ces documents, la feuille de style se trouvera déjà exister dans le cache. La mise à disposition de feuilles de style standard de bonne facture dans le domaine public encouragera leur usage.
Il y a de fortes chances que le nombre de types de média référencés aujourd'hui augmente sensiblement dans le futur. Pour permettre a ces nouveaux style d'être introduits "en douceur", les agents utilisateurs devront interpréter l'attribut de type de média de la façon suivante :
media="screen, 3d-glasses, print and resolution > 90dpi"
peut être vue comme :
"screen"
"3d-glasses"
"print and resolution > 90dpi"
"screen"
"3d-glasses"
"print"
Note : Les feuilles de style pourront inclure des variations dépendantes du médium. Par exemple, la construction @media du langage CSS. Dans un tel cas, il serait judicieux d'utiliser la valeur par défaut "all".
L'affichage progressif des documents au fur et à mesure qu'ils sont reçus via le réseau pose un certain nombre de problèmes relativement aux formulaires. Les agents utilisateurs devront éviter que le formulaire puisse être soumis avant qu'il ne soit intégralement parvenu sur la machine cliente.
L'affichage progressif des documents pose également des problèmes en matière de navigation tabulée. La démarche heuristique qui consiste à donner le focus à l'élément de plus faible tabindex dans le document semble raisonnable en première approche. Mais ceci impliquerait d'attendre que tout le texte du document soit reçu, avant quoi l'élément de tabindex le plus faible peut varier. Si l'utilisateur appuie sur la touche de tabulation avant que tout le formulaire soit chargé, l'attitude consistant, pour les agents utilisateurs, à donner le focus à l'élément de plus faible tabindex disponible à ce moment paraît raisonnable.
Si les formulaires sont associés à des scripts clients, de nouveaux problèmes peuvent subvenir. Par exemple, un gestionnaire pour un certain événement peut très bien se référer à un élément qui n'existe pas encore.
Cette spécification définit un ensemble d'éléments et d'attributs suffisamment puissant pour subvenir aux besoins les plus courants en matière de formulaires. Il reste cependant de la place pour de nouvelles évolutions. Par exemple, les problèmes suivants pourraient être résolus dans le futur :
Cette spécification réserve une syntaxe pour le support futur de macros encodées dans des valeurs d'attributs HTML de type CDATA. Notre intention est de pouvoir définir des attributs en fonction de propiétés d'objets qui sont apparus plus tôt dans la page. La syntaxe est :
attribute = "... &{ corps de macro }; ... "
Le corps de macro est constitué d'une ou plusieurs instructions écrites dans le langage de script par défaut (comme pour les attributs d'événements intrinsèques). Le point virgule suivant l'accolade droite est obligatoire, faute de quoi cette accolade droite "}" devrait être considérée comme partie du corps de macro. Il peut être important de remarquer que des valeurs d'attributs contenant des macros scriptées doivent toujours être quotées.
Le traitement des attributs CDATA se fait ainsi :
L'exécution des macros est exécutée lors du chargement du document (ou de son raffraichissement) mais n'instervient pas lorsque la fenêtre contenant le document est redimensionnée, raffraichie (graphiquement), etc.
Voici quelques exemples utilisant JavaScript. Le premier instaure une couleur de fond aléatoire pour le document :
<BODY bgcolor='&{randomrbg()};'>
Peut-être souhaiterez-vous diminuer l'intensité de l'affichage le soir ?
<BACKGROUND src='&{if(Date.getHours > 18)...};'>
L'exemple suivant utilise JavaScript pour définir les coordonénes d'une imagemap cliente :
<MAP NAME=foo>
<AREA shape="rect" coords="&{myrect(imageurl)};" href="&{myurl};">
</MAP>
Cet exemple détermine la taille d'affichage d'une image suivant certaines propriétés du document :
<IMG src="bar.gif" width='&{document.banner.width/2};' height='50%'>
Vous pouvez définir l'URL d'un lien ou d'une image par un script :
<SCRIPT>
function manufacturer(widget) {
...
}
function location(manufacturer) {
...
}
function logo(manufacturer) {
...
}
</SCRIPT>
<A href='&{location(manufacturer("widget"))};'>widget</A>
<IMG src='&{logo(manufacturer("widget"))};'>
Ce dernier exemple montre comment un attribut SGML de type CDATA peut être quoté indifféremment par des guillemets ou par des apostrophes. Si vous quotez la valeur par des apostrophes, alors des guillemets litéraux pourront apparaître dans la chaîne. Une autre approche sera d'utiliser des entités " comme marques de quotation :
<IMG src="&{logo(manufacturer("widget"))};">