La version française de cette traduction est :
http://www.la-grange.net/w3c/html4.01/
Traducteur : J.J.Solari dans le cadre de l'effort de la liste de discussion [email protected]
La version française peut contenir des erreurs. La version anglaise de cette note est l'unique version
normative. Version originale : http://www.w3.org/TR/1999/REC-html401-19991224
Sommaire
Les fonctionnalités multimédias de HTML permettent aux auteurs d'inclure dans leurs pages des images, des applets (des programmes qui sont automatiquement chargés puis lancés sur la machine de l'utilisateur), des séquences vidéo et d'autres documents HTML.
Par exemple, pour inclure une image PNG dans un document, l'auteur peut écrire :
Voici un gros plan sur le Grand Canyon :
Les versions antérieures de HTML permettaient aux auteurs d'inclure des images (via l'élément IMG) et des applets (via l'élément APPLET). Ces éléments ont plusieurs limitations :
Pour répondre à ces questions, HTML 4 introduit l'élément OBJECT, qui offre une solution générale aux inclusions d'objets génériques. L'élément OBJECT permet aux auteurs HTML de spécifier tout ce que l'objet requiert pour sa présentation par un agent utilisateur : le code source, les valeurs initiales et les données d'exécution [ndt. run-time data]. Dans cette spécification, on emploie le terme « objet » pour désigner les choses que les personnes mettent dans les documents HTML ; les termes usuels courants pour ces choses sont : les applets, les modules d'extension [ndt. plug-ins], les gestionnaires de média [ndt. media handlers], etc.
Le nouvel élément OBJECT prend donc en charge quelques unes des tâches effectuées par les éléments existants. Considérons le comparatif des fonctionnalités suivant :
| Type d'inclusion | Élément spécifique | Élément générique |
|---|---|---|
| Image | IMG | OBJECT |
| Applet | APPLET (déconseillé) | OBJECT |
| Un autre document HTML | IFRAME | OBJECT |
Le comparatif indique que chaque type d'inclusion possède une solution spécifique et une solution générique. L'élément générique OBJECT servira de solution pour l'implémentation des types de média futurs.
Pour inclure des images, les auteurs peuvent utiliser l'élément OBJECT ou bien l'élément IMG.
Pour inclure des applets, les auteurs devraient utiliser l'élément OBJECT puisque l'élément APPLET est déconseillé.
Pour inclure un document HTML dans un autre, les auteurs peuvent utiliser soit le nouvel élément IFRAME, soit l'élément OBJECT. Dans les deux cas, le document incorporé reste indépendant du document principal. Les agents utilisateurs visuels peuvent présenter le document incorporé dans une fenêtre distincte à l'intérieur du document principal. Veuillez consulter les remarques sur les documents incorporés pour une comparaison entre les éléments OBJECT et IFRAME pour l'inclusion d'un document.
Les images et les autres objets inclus peuvent avoir des hyperliens qui leur sont associés, à la fois au travers des mécanismes de liaison standards mais aussi via des images cliquables [ndt. image maps]. Une image cliquable spécifie les régions géométriques actives d'un objet inclus et assigne un lien à chacune d'elles. Quand ils sont activés, ces liens peuvent entraîner la recherche d'un document, lancer un programme sur le serveur, etc.
Dans les sections suivantes, nous abordons les divers mécanismes dont disposent les auteurs pour les inclusions multimédias et pour la création d'images cliquables pour ces inclusions.
IMG - O EMPTY -- image incorporée --> %attrs; -- %coreattrs, %i18n, %events -- src %URI; #REQUIRED -- URI de l'image à incorporer -- alt %Text; #REQUIRED -- description brève -- longdesc %URI; #IMPLIED -- lien vers une description longue (en complément de l'attribut alt) -- name CDATA #IMPLIED -- nom de l'image destiné aux scripts -- height %Length; #IMPLIED -- surclasse la hauteur -- width %Length; #IMPLIED -- surclasse la largeur -- usemap %URI; #IMPLIED -- utiliser une image cliquable côté client -- ismap (ismap) #IMPLIED -- utiliser une image cliquable côté serveur -- >
Balise ouvrante : obligatoire, balise fermante : interdite
Définition des attributs
Attributs définis ailleurs
L'élément IMG incorpore une image dans le document courant, à l'emplacement de la définition de l'élément. L'élément IMG n'a pas de contenu ; il est généralement remplacé dans la ligne par l'image que désigne l'attribut src, les images alignées à gauche ou à droite qui « flottent » hors de la ligne faisant exception.
Dans un exemple précédent, nous définissions un lien vers une photo familiale. Ici, nous insérons la photo directement dans le document courant :
Je viens de revenir de vacances ! Voici une photo de la famille sur le lac :
On pourrait également obtenir cette inclusion avec l'élément OBJECT, comme suit :
Je viens de revenir de vacances ! Voici une photo de la famille sur le lac :
L'attribut alt spécifie le texte de remplacement qui sera restitué si l'image ne peut s'afficher (voir ci-dessous pour des précisions sur la manière de spécifier un texte de remplacement). Les agents utilisateurs doivent restituer le texte de remplacement quand ceux-ci ne gèrent pas les images, ne reconnaissent pas un certain type d'image ou ne sont pas configurés par afficher les images.
L'exemple suivant montre comment employer l'attribut longdesc pour relier l'image à une description approfondie :
L'attribut alt fournit une description brève de l'image. Celle-ci devrait être suffisante pour permettre à l'utilisateur de décider s'il va suivre le lien donné par l'attribut longdesc vers la description plus détaillée, ici "plandusite.html".
Veuillez consulter la section sur la présentation visuelle des objets, images et applets pour des précisions sur la taille, l'alignement et les bordures de l'image.
OBJECT - - (PARAM | %flow;)* -- objet incorporé générique --> %attrs; -- %coreattrs, %i18n, %events -- declare (declare) #IMPLIED -- déclare mais n'instancie pas de drapeau -- classid %URI; #IMPLIED -- identifie l'implémentation -- codebase %URI; #IMPLIED -- URI de base pour classid, data, archive -- data %URI; #IMPLIED -- référence aux données de l'objet -- type %ContentType; #IMPLIED -- type de contenu des données -- codetype %ContentType; #IMPLIED -- type de contenu pour code code -- archive CDATA #IMPLIED -- liste d'URI séparés par des espaces -- standby %Text; #IMPLIED -- message à afficher pendant le chargement -- height %Length; #IMPLIED -- surclasse la hauteur -- width %Length; #IMPLIED -- surclasse la largeur -- usemap %URI; #IMPLIED -- utiliser une image cliquable côté client -- name CDATA #IMPLIED -- soumettre comme partie d'un formulaire -- tabindex NUMBER #IMPLIED -- position dans l'ordre de tabulation -- >
Balise ouvrante : obligatoire, balise fermante : obligatoire
Définition des attributs
Attributs définis ailleurs
La plupart des agents utilisateurs possèdent des mécanismes intégrés pour la restitution des types de données communs, tels que le texte, les images GIF, les couleurs, les polices et une poignée d'éléments graphiques. Pour restituer les types de données qu'ils ne reconnaissent pas nativement, les agents utilisateurs lancent en général des applications externes. L'élément OBJECT permet aux auteurs de mieux contrôler si les données devraient être restituées de manière externe ou par un certain programme, spécifié par l'auteur, qui restitue ces données au sein de l'agent utilisateur.
Dans le cas le plus général, l'auteur peut avoir besoin de spécifier trois types d'informations :
L'élément OBJECT permet aux auteurs de spécifier tous ces trois types de données, mais il n'est pas nécessaire de toutes les spécifier en une seule fois. Par exemple, certains objets peuvent ne pas requérir de donnés (par exemple, un applet autonome qui effectue une petite animation). D'autres peuvent exiger une initialisation à l'exécution. D'autres encore ne pas avoir besoin d'informations supplémentaires sur l'implémentation, i.e., l'agent utilisateur peut déjà savoir de lui-même comment restituer ce type de données (par exemple, des images GIF).
Les auteurs spécifient l'implémentation d'un objet et la localisation des données à restituer via l'élément OBJECT. Par contre, pour spécifier des valeurs d'exécution, les auteurs utilisent l'élément PARAM, qui est abordé dans la section sur l'initialisation de l'objet.
L'élément OBJECT peut aussi apparaître en contenu de l'ément HEAD. Étant donné que les agents utilisateurs ne restituent généralement pas les éléments placés dans la section HEAD, les auteurs devraient s'assurer qu'aucun élément OBJECT dans la section HEAD ne spécifie un contenu qui peut être restitué. Veuillez consultez la section sur le partage des données entre les cadres pour un exemple d'inclusion de l'élément OBJECT dans l'élément HEAD.
Veuillez consulter la section sur les contrôles des formulaires pour des précisions sur les éléments OBJECT dans les formulaires.
Ce document ne spécifie pas le comportement des éléments OBJECT qui utilisent à la fois l'attribut classid, pour identifier une implémentation, et l'attribut data, pour spécifier les données pour cette implémentation. Afin d'assurer la portabilité, les auteurs devraient employer l'élément PARAM pour indiquer aux implémentations où aller chercher les donnés supplémentaires.
L'agent utilisateur doit interpréter l'élément OBJECT selon les règles de préséance suivantes :
Les auteurs ne devraient pas inclure de contenu dans les éléments OBJECT qui apparaissent dans l'élément HEAD.
Dans l'exemple suivant, nous insérons un applet d'horloge analogique dans un document via l'élément OBJECT. L'applet, écrit dans le langage Python, ne requiert aucune données supplémentaires ni valeurs d'exécution. L'attribut classid spécifie la localisation de l'applet :
Remarquez que l'horloge sera restituée dès l'interprétation de la déclaration de l'élément OBJECT par l'agent utilisateur. Il est possible de différer la restitution d'un objet en effectuant une déclaration préalable de cet objet (décrit ci-dessous).
Les auteurs devraient remplir cette déclaration en y incluant un texte de remplacement comme contenu de l'élément OBJECT, pour le cas où l'agent utilisateur ne pourrait pas restituer l'horloge.
Une conséquence significative de la conception de l'élément OBJECT, c'est qu'elle offre un mécanisme pour spécifier des restitutions alternatives de l'objet chacune des déclarations des éléments OBJECT imbriqués peut spécifier un type de contenu alternatif. Si l'agent utilisateur ne peut pas restituer l'élément OBJECT le plus externe, il essaye d'en restituer le contenu, qui peut être un autre élément OBJECT, etc.
Dans l'exemple suivant, nous imbriquons plusieurs déclarations d'éléments OBJECT pour illustrer le fonctionnement des restitutions alternatives. L'agent utilisateur essaye d'abord de restituer le premier élément OBJECT qu'il peut, dans l'ordre suivant : (1) un applet représentant un globe terrestre interactif, écrit dans le langage Python, (2) une animation MPEG du globe, (3) une image GIF du globe et (4) un texte de remplacement.
La déclaration la plus externe spécifie un applet qui ne requiert ni donnée ni valeurs initiales. La deuxième déclaration spécifie une animation MPEG et, puisqu'elle ne définit pas la localisation d'une l'implémentation pour traiter l'animation MPEG, compte sur l'agent utilisateur pour prendre en charge celle-ci. Nous avons également spécifié l'attribut type, de sorte que l'agent utilisateur, qui sait ne pas pouvoir restituer un MPEG, n'essaiera même pas de charger le fichier "LaTerre.mpeg" à partir du réseau. La troisième déclaration spécifie la localisation d'un fichier GIF et fournit un texte de remplacement au cas où tous les autres mécanismes auraient échoué.
Les données internes comparées aux données externes. Les données à restituer peuvent être fournies de deux façons : en interne ou à partir d'une ressource externe. Tandis que la première méthode donnera en général une restitution plus rapide, elle ne conviendra pas quand il s'agira de restituer une grande quantité de données.
Voici un exemple qui illustre la manière dont les données internes peuvent être injectées dans l'élément OBJECT :
Veuillez consulter la section sur la présentation visuelle des objets, images et applets pour des précisions sur la taille, l'alignement et les bordures d'un objet.
PARAM - O EMPTY -- valeur de propriété nommée --> id ID #IMPLIED -- identifiant unique dans le document -- name CDATA #REQUIRED -- nom de propriété -- value CDATA #IMPLIED -- valeur de propriété -- valuetype (DATA|REF|OBJECT) DATA -- comment interpréter la valeur -- type %ContentType; #IMPLIED -- type de contenu pour la valeur quand valuetype="ref" -- >
Balise ouvrante : obligatoire, balise fermante : interdite
Définition des attributs
Attributs définis ailleurs
Les éléments PARAM spécifient l'ensemble des valeurs qui peuvent être requises à l'exécution par un objet. Il peut y avoir un nombre quelconque d'éléments PARAM dans le contenu d'un élément OBJECT, ou APPLET, dans n'importe quel ordre, mais ceux-ci doivent se placer au début du contenu de l'élément englobant OBJECT, ou APPLET.
La syntaxe des noms et de leurs valeurs est censée comprise par l'implémentation de l'objet. Ce document ne spécifie pas les façons selon lesquelles les agents utilisateurs devraient ramener les couples nom/valeur ni devraient interpréter les noms apparaissant en double.
Nous revenons à l'exemple avec l'horloge pour illustrer l'utilisation de l'élément PARAM : supposons que l'applet admette deux paramètres d'exécution qui définissent sa hauteur et sa largeur initiales. On peut fixer une dimension initiale de 40x40 pixels à l'aide de deux éléments PARAM.
Dans l'exemple suivant, les données d'exécution pour le paramètre « Valeurs_initiales » de l'objet sont spécifiées comme étant une ressource externe (un fichier GIF). La valeur de l'attribut valuetype est donc fixée à "ref" et la valeur de l'attribut value est l'URI qui désigne la ressource.
Remarquez que nous avons également spécifié l'attribut standby pour que l'agent utilisateur puisse afficher un message pendant le chargement du mécanisme de restitution.
Quand un élément OBJECT est restitué, l'agent utilisateur doit rechercher les seuls contenus des éléments PARAM qui sont des enfants directs et les « injecter » dans l'objet OBJECT.
Ainsi, dans l'exemple suivant, si l'objet identifié par "obj1" est restitué, alors le paramètre "param1" s'applique à "obj1" (et non à "obj2"). Si l'objet "obj1" n'est pas restitué et par contre l'objet "obj2" l'est, alors le paramètre "param1" est ignoré et "param2" s'applique à "obj2". Si ni l'un ni l'autre élément OBJECT n'est restitué, alors ni l'un ni l'autre élément PARAM ne s'applique.
La localisation de l'implémentation d'un objet est donnée par un URI. Comme nous l'avons vu dans l'introduction aux URI, le premier segment d'un URI absolu spécifie le système de nommage [ndt. naming scheme] utilisé pour transférer les données désignées par l'URI. Pour les documents HTML, ce système est fréquemment « http ». Certains applets pourraient employer d'autres systèmes de nommage. Par exemple, lors de la spécification d'un applet Java, les auteurs peuvent utiliser des URI qui commencent par « java » et pour les applets ActiveX par « clsid ».
Dans l'exemple suivant, on insère un applet Java dans un document HTML.
Par la spécification de l'attribut codetype, l'agent utilisateur peut décider s'il ramène l'application Java en s'appuyant sur sa capacité à le faire.
Certains systèmes de restitution demandent des informations supplémentaires pour identifier leur implémentation et on doit leur dire où trouver ces informations. Les auteurs peuvent donner une indication de chemin à l'implémentation de l'objet via l'attribut codebase.
L'exemple suivant spécifie (avec l'attribut classid) un objet ActiveX via un URI qui commence par le système de nommage « clsid ». L'attribut data localise les données à restituer (une autre horloge).
Pour déclarer un objet de sorte qu'il ne soit pas exécuté au moment où l'agent utilisateur le lit, il faut placer l'attribut booléen declare dans l'élément OBJECT. Dans le même temps, l'auteur doit identifier cette déclaration, en assignant à l'attribut id dans l'élément OBJECT une valeur unique. Les instanciations ultérieures de l'objet se référeront à cet identifiant.
Un élément OBJECT déclaré doit apparaître dans le document avant la première instance de cet élément OBJECT.
Un objet, défini avec l'attribut declare, est instancié toutes les fois où un élément qui se rapporte à cet objet requiert une restitution de celui-ci (par exemple, un lien qui se réfère à l'objet est activé, un autre objet qui s'y réfère est activé, etc.).
Dans l'exemple suivant, on déclare un élément OBJECT et on induit son instanciation en l'appelant à partir d'un lien. L'objet peut donc être activé, par exemple, en cliquant sur un certain texte mis en surbrillance.
...plus loin dans le document...
Une animation de la Terre bien faite !
L'exemple suivant illustre la manière de spécifier des valeurs d'exécution qui sont d'autres objets. Ici, nous envoyons un texte (plus précisément, un poème) à un mécanisme hypothétique qui permet de visionner les poèmes. L'objet reconnaît un paramètre d'exécution nommé « police » (disons, pour restituer le texte du poème dans une certaine police). La valeur de ce paramètre est elle-même un objet qui insère l'objet police (mais qui ne le restitue pas). La relation entre l'objet police et le visionneur de poème est obtenue (1) en donnant la valeur "tribune" à l'attribut id de l'objet police et (2) en l'appelant à partir de l'élément PARAM de l'objet visionneur de poème (avec les attributs valuetype et value).
...ici visionnage du poème dans la police KublaKhan.txt...
Les agents utilisateurs qui ne reconnaissent pas l'attribut declare doivent restituer le contenu de la déclaration de l'élément OBJECT.
Voir le DTD transitoire pour la définition formelle.
Définition des attributs
Quand l'applet est « désérialisé », la méthode start() est invoquée mais non la méthode init(). Les attributs valide au moment de la sérialisation de l'objet original ne sont pas réenregistrés. Tous les attributs passés à cet instance APPLET seront disponibles pour l'applet. Les auteurs devraient utiliser cette faculté avec une extrême prudence. Un applet devrait être arrêté avant d'être sérialisé.
L'un des attributs code et object doit être présent. Quand les deux attributs code et object sont donnés, il y aura une erreur s'ils fournissent deux noms de classe différents.
Attributs définis ailleurs
Cet élément, qui est géré par tous les navigateurs compatibles avec Java, permet aux développeurs d'incorporer un applet Java dans un document HTML. Il est déconseillé en faveur de l'élément OBJECT.
Le contenu de l'élément APPLET fais office de support d'informations de remplacement pour les agents utilisateurs qui ne reconnaissent pas cet élément ou qui ne sont pas configurés à cet instant pour gérer les applets. Sinon, les agents utilisateurs doivent ignorer le contenu.
EXEMPLE DÉCONSEILLÉ :
Dans l'exemple suivant, l'élément APPLET
inclut un applet Java au document. Comme aucun attribut codebase
n'est donné, l'applet est censé se trouver dans le même répertoire que le document courant.
Cet exemple peut se récrire avec un élément OBJECT, comme suit :
Les valeurs initiales peuvent être fournies à l'applet via l'élément PARAM.
EXEMPLE DÉCONSEILLÉ :
L'exemple d'applet Java suivant :
celui-ci peut se récrire avec l'élément OBJECT, commes suit :
Le document incorporé est complètement indépendant du document dont lequel il se loge. Par exemple, les URI relatifs dans le document incorporé se résolvent par rapport à l'URI de base du document incorporé, non celui du document principal. Le document incorporé est simplement restitué à l'intérieur d'un autre document (par exemple, dans une sous-fenêtre) ; il reste indépendant par ailleurs.
Par exemple, la ligne suivante incorpore le contenu de « loge_moi.html » à l'emplacement où la définition de l'élément OBJECT survient.
...texte qui précède... ...texte qui suit...
Rappelez-vous que le contenu de l'élément OBJECT ne doit seulement être restitué que si le fichier spécifié par l'attribut data n'a pu être chargé.
Le comportement d'un agent utilisateur pour le cas où un fichier s'auto-inclut n'est pas défini.
Une image cliquable est créée en associant à un objet une spécification de zones géométriques sensibles sur celui-ci.
Il existe deux types d'images cliquables :
Les images cliquables côté client sont préférées à celles côté serveur pour au moins deux raisons : elles sont accessibles aux personnes navigant avec des agents utilisateurs non-graphiques et elles renvoient une réponse immédiate pour ce qui est de savoir si le pointeur se trouve sur une région active ou non.
MAP - - ((%block;) | AREA)+ -- image cliquable côté client --> %attrs; -- %coreattrs, %i18n, %events -- name CDATA #REQUIRED -- pour appel par l'attribut usemap -- >
Balise ouvrante : obligatoire, balise fermante : obligatoire
AREA - O EMPTY -- aire d'image cliquable côté client --> %attrs; -- %coreattrs, %i18n, %events -- shape %Shape; rect -- contrôle l'interprétation des coordonnées -- coords %Coords; #IMPLIED -- liste de longueurs séparées par des virgules -- href %URI; #IMPLIED -- URI de la ressource reliée -- nohref (nohref) #IMPLIED -- cette région est neutre -- alt %Text; #REQUIRED -- description brève -- tabindex NUMBER #IMPLIED -- position dans l'ordre de tabulation -- accesskey %Character; #IMPLIED -- touche de caractère pour l'accessibilité -- onfocus %Script; #IMPLIED -- l'élément a l'attention -- onblur %Script; #IMPLIED -- l'élément perd l'attention -- >
Balise ouvrante : obligatoire, balise fermante : interdite
Définition des attributs pour MAP
Définiton des attributs pour AREA
Les coordonnées sont relatives au coin supérieur gauche de l'objet. Toutes les valeurs sont du type longueur. Toutes les valeurs sont séparées par des virgules.
Attribut pour associer une image cliquable à un élément
Attributs définis ailleurs
L'élément MAP spécifie une image cliquable côté client (ou un autre mécanisme de navigation) qui peut être associée à d'autres éléments (IMG, OBJECT ou INPUT). L'image cliquable est associée à un élément via l'attribut usemap de celui-ci. L'élément MAP peut s'employer sans image associée pour des mécanismes de navigation généraux.
La présence de l'attribut usemap sur un élément OBJECT implique que l'objet qui est inclus est une image. En outre, quand l'élément OBJECT a une image cliquable côté client associée, l'agent utilisateur peut produire une interaction utilisateur avec cet élément OBJECT, uniquement en fonction de l'image cliquable côté client. Ceci permet aux agents utilisateurs (tels un navigateur vocal ou un robot) d'interagir avec l'élément OBJECT sans devoir le traiter ; l'agent utilisateur peut même choisir de ne pas ramener (ou traiter) l'objet. Quand un élément OBJECT a une image cliquable associée, l'auteur ne devrait pas compter sur le fait que l'objet sera ramené ou traité par tous les agents utilisateurs.
Le modèle de contenu de l'élément MAP permet à l'auteur les combinaisons suivantes :
Quand un élément MAP contient un contenu mixte (à la fois des éléments AREA et un contenu de type bloc), les agents utilisateurs doivent ignorer les éléments AREA.
Les auteurs devraient spécifier la géométrie d'une image cliquable entièrement avec des éléments AREA, ou entièrement avec des éléments A, ou entièrement avec les deux si le contenu est mixte. Les auteurs peuvent souhaiter mêler le contenu, de sorte que les agents utilisateurs anciens prendront en charge les cartographies spécifiées par les éléments AREA et les agents utilisateurs récents tireront profit des contenus en bloc plus étoffés.
Si deux régions définies ou plus se chevauchent, l'élément définissant une région qui apparaît en premier dans le document a priorité (i.e., répond aux sollicitations de l'utilisateur).
Les agents utilisateurs et les auteurs devraient offrir des alternatives textuelles aux images cliquables quand les graphiques ne sont pas disponibles ou les utilisateurs ne peuvent y accéder. Par exemple, les agents utilisateurs peuvent utiliser le texte de l'attribut alt pour créer des liens textuels à la place des images cliquables graphiques. De tels liens peuvent être activés de diverses façons (clavier, commande vocale, etc.).
Remarque : L'élément MAP n'est pas rétro-compatible avec les agents utilisateurs HTML 2.0.
Dans l'exemple suivant, nous créons une image cliquable côté client pour l'élément OBJECT. Nous ne voulons pas restituer le contenu d'image cliquable quand l'élément OBJECT est restitué, c'est pourquoi nous « dissimulons » l'élément MAP dans le contenu de l'élément OBJECT. En conséquence, le contenu de l'élément MAP ne sera restitué qui si l'élément OBJECT ne peut pas l'être.
Le site sympa !
On peut vouloir que l'image cliquable soit restituée même si l'agent utilisateur est incapable de restituer l'élément OBJECT. Par exemple, on peut vouloir associer une image cliquable à un élément OBJECT et inclure une barre de navigation textuelle en bas de la page. Pour cela, nous définissons l'élément MAP en dehors de l'élément OBJECT :
Le site sympa !
...le reste de la page ici...
Dans l'exemple suivant, nous créons une image cliquable similaire, cette fois en employant l'élément AREA. Remarquez l'utilisation du texte de l'attribut alt :
Voici une variante utilisant l'élément IMG au lieu de OBJECT (avec la même déclaration MAP) :
L'exemple suivant illustre la manière dont on peut partager des images cliquables.
Les éléments OBJECT imbriqués sont utiles pour offrir des solutions de repli au cas où l'agent utilisateur ne reconnaîtrait pas certains formats. Par exemple :
Si l'agent utilisateur ne reconnaît pas le format PNG, celui-ci essaye de restituer l'image GIF. Si celui-ci ne reconnaît pas le format GIF (par exemple, parce qu'il s'agit d'un navigateur vocal), il se rabat par défaut sur la description textuelle fournie en contenu de l'élément OBJECT interne. Quand les éléments OBJECT sont imbriqués de cette manière, les auteurs peuvent partager des images cliquables entre eux :
L'exemple suivant montre comment on peut spécifier des ancres pour créer des zones inactives dans une image cliquable. La première ancre spécifie une petite région circulaire sans lien associé. La deuxième ancre spécifie une région circulaire plus grande de même centre que le précédent. Les deux combinés forment un anneau dont le centre est inactif et le bord actif. L'ordre des définitions des ancres est important, car le petit cercle doit surclasser le grand cercle.
De la même manière, l'attribut nohref de l'élément AREA déclare que la région géométrique n'a pas de lien associé.
Les images cliquables côté serveur peuvent se révéler intéressantes pour les cas où l'image cliquable serait trop compliquée à réaliser côté client.
On ne peut définir une image cliquable côté serveur que pour les éléments IMG et INPUT. Pour ce qui est de l'élément IMG, celui-ci doit se trouver dans un élément A et l'attribut booléen ismap ([CI]) doit être présent. Pour ce qui est de l'élément INPUT, celui-ci doit être du type "image".
Quand l'utilisateur active le lien, en cliquant sur l'image, les cordonnées de ce clic à l'écran sont directement transmises au serveur qui héberge le document. Les coordonnées à l'écran sont exprimées par des valeurs en pixels d'écran relativement à l'image. Pour des informations normatives sur la définition d'un pixel et sur la manière de le mesurer, veuillez consulter la spécification [CSS1].
Dans l'exemple suivant, la région active définit un lien côté serveur. Ainsi, tout clic sur l'image entraînera la transmission des coordonnés du point cliqué au serveur.
Le point cliqué est transmis au serveur comme suit. L'agent utilisateur dérive un nouvel URI à partir de l'URI spécifié par l'attribut href de l'élément A, en lui rajoutant à la fin le caractère « ? » suivi des coordonnées « x » et « y », séparées par une virgule. Le lien est alors suivi en utilisant le nouvel URI. Par exemple, dans l'exemple donné, si l'utilisateur clique au point « x=10, y=27 », alors l'URI dérivé sera "http://www.acme.com/cgi-bin/competition?10,27".
Les agents utilisateurs, qui n'offrent aucun moyen pour sélectionner des coordonnées spécifiques (par exemple, un agent utilisateur non-graphique qui s'appuie sur une saisie au clavier, un agent utilisateur vocal, etc.), devraient envoyer les coordonnées "0,0" au serveur lors de l'activation du lien.
Définition des attributs
Quand ils sont spécifiés, les attributs width et height indiquent à l'agent utilisateur de surclasser les dimensions naturelles de l'image, ou de l'objet, par leurs valeurs.
Quand l'objet est une image, elle est mise à l'échelle. L'agent utilisateur devrait faire de son mieux pour changer l'échelle d'un objet ou d'une image pour correspondre à la largeur et la hauteur spécifiées par l'auteur. Remarquez que les longueurs exprimées en pourcentages sont fonction de l'espace horizontal et vertical disponible à cet instant, non des dimensions naturelles de l'image, de l'objet ou de l'applet.
Les attributs height et width donnent à l'agent utilisateur une indication sur les dimensions d'une image ou d'un objet, de sorte qu'il puisse réserver leur place et continuer à restituer le document en attendant les données d'image.
Définition des attributs
Une image ou un objet peuvent être entourés par une bordure (par exemple, quand l'utilisateur spécifie une bordure ou quand l'image est le contenu d'un élément A).
Définition des attributs
Définition des attributs
Les valeurs suivantes de l'attribut align concernent la position de l'objet par rapport au texte qui l'entoure :
Les deux autres valeurs left et right entraînent l'image à flotter vers la marge gauche, ou droite, courante. Ils sont abordés dans la section sur les objets flottants.
Les interprétations divergentes de l'attribut align. Les agents utilisateurs divergent dans leur interprétation de l'attribut align. Certains ne prennent en compte que ce qui s'est passé sur la ligne de texte avant l'élément, d'autres prennent en compte le texte sur les deux côtés de l'élément.
Définition des attributs
Plusieurs éléments non-textuels (IMG, AREA, APPLET et INPUT) laissent l'auteur spécifier un texte de remplacement qui sert de contenu quand l'élément ne peut pas être restitué normalement. La spécification d'un texte de remplacement représente une aide pour les utilisateurs ne disposant pas de terminaux d'affichage graphiques, pour les utilisateurs dont les navigateurs ne reconnaissent pas les formulaires, pour les utilisateurs avec des déficiences visuelles, pour ceux qui utilisent des synthétiseurs de parole, ceux qui ont désactivé l'affichage des images de leurs agents utilisateurs graphiques, etc.
On doit spécifier l'attribut alt sur les éléments IMG et AREA. Il est optionnel pour les éléments INPUT et APPLET.
Alors qu'un texte de remplacement peut être très utile, on doit l'employer à bon escient. Les auteurs devraient observer les principes directeurs suivants :
Les développeurs devraient consulter la section sur l'accessibilité pour des renseignements sur la façon de prendre en charge les cas où le texte de remplacement est omis.
