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
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 :
ils ne répondent pas au problème plus général de la manière d'inclure
les nouveaux comme les futurs types de média ;
l'élément APPLET ne fonctionne
qu'avec des applets basés sur le langage Java. Cet élément est déconseillé
en faveur de l'élément OBJECT ;
ils entraînent des problèmes d'accessibilité.
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 :
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 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.
Cet attribut spécifie un lien vers une description longue de l'image. Cette description devrait compléter la
description brève fournie par l'attribut alt.
Quand il s'agit d'une image cliquable, cet attribut devrait fournir des informations à propos du
contenu de l'image cliquable. C'est particulièrement important en ce qui concerne les images cliquables côté serveur.
Comme l'élément IMG peut apparaître
en contenu d'un élément A, le mécanisme
dans l'interface utilisateur de l'agent utilisateur pour accéder à la ressource désignée par l'attribut
longdesc doit être différent de celui pour accéder à la ressource désignée
par l'attribut href de ce dernier.
Cet attribut nomme l'élément de sorte qu'il puisse être appelé par des feuilles de style ou des scripts.
Remarque : Cet attribut a été retenu pour des raisons de rétro-compatibilité. Les applications
devraient utiliser l'attribut id pour identifier les éléments.
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".
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 --
archiveCDATA #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 --
nameCDATA #IMPLIED -- soumettre comme partie d'un formulaire --
tabindexNUMBER #IMPLIED -- position dans l'ordre de tabulation --
>
Cet attribut peut être utilisé pour spécifier la localisation de l'implémentation d'un objet
via un URI. On peut l'utiliser en même temps que, ou en alternative à,
l'attribut data, selon le type de l'objet impliqué.
Cet attribut spécifie le chemin de base utilisé pour résoudre les URI
relatifs spécifiés par les attributs classid,
data et
archive. Quand il est absent,
sa valeur par défaut correspond à l'URI de base
du document courant.
Cet attribut spécifie le type de contenu des données attendues lors du chargement de l'objet spécifié
par l'attribut classid. Cet attribut est optionnel,
mais recommandé quand l'attribut classid
est spécifié parce qu'il permet à l'agent utilisateur d'éviter le chargement des informations dont les
types ne sont pas reconnus. Quand il est absent, sa valeur par défaut est celle de l'attribut type.
Cet attribut peut être utilisé pour spécifier la localisation des données de l'objet, par exemple
les données d'image pour les objects définissant des images, ou plus généralement, la forme
sérialisée d'un objet qui peut être utilisée pour recréer cet objet. Quand il est donné
comme URI relatif, celui-ci devrait être interprété
relativement à l'attribut codebase.
Cet attribut spécifie le type de contenu des données spécifiées par l'attribut
data. Cet attribut est optionnel, mais recommandé
quand l'attribut data est spécifié
parce qu'il permet à l'agent utilisateur d'éviter le chargement des informations dont les types de contenu ne sont pas
reconnus. Si la valeur de cet attribut diffère de l'en-tête HTTP
« Content-Type » retourné par le serveur quand l'objet est ramené, alors c'est l'en-tête
HTTP « Content-Type » qui a préséance.
Cet attribut peut être utilisé pour spécifier la liste des URI,
séparés par des espaces, des archives contenant les ressources concernant l'objet, liste qui peut inclure
les ressources spécifiées par les attributs classid
et data. Le préchargement des archives
aboutira généralement à des temps de chargement réduits pour les objets. Les archives spécifiées
comme URI relatifs devraient être interprétées
relativement à l'attribut codebase.
Quand il est présent, cet attribut booléen fait de la définition de l'élément
OBJECT courant seulement une déclaration.
L'objet doit être instancié par la suite au travers d'une définition
OBJECT qui se réfère à cette
déclaration.
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'implémentation de l'objet inclus. Par exemple, si l'objet inclus est un applet d'horloge, l'auteur doit indiquer
la localisation du code exécutable de l'applet ;
Les données à restituer. Par exemple, si l'objet inclus est un programme pour restituer des données de
polices, l'auteur doit indiquer la localisation de ces données ;
Les valeurs supplémentaires requises par l'objet à l'exécution. Par exemple, certains applets peuvent
demander des valeurs initiales en paramètres.
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).
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 :
L'agent utilisateur doit en premier essayer de restituer l'objet. Il ne devrait pas restituer le contenu de l'élément,
mais il doit l'examiner au cas où l'élément contiendrait d'éventuels enfants directs qui soient des
éléments PARAM (voir la section sur
l'initialisation de l'objet) ou bien des éléments
MAP (voir la section sur les
images cliquables côté client) ;
Si l'agent utilisateur est incapable de restituer l'objet, pour une raison ou pour une autre (non configuré pour, absence
des ressources, architecture erronée, etc.), il doit essayer de restituer son contenu.
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 :
PARAM - O EMPTY -- valeur de propriété nommée -->
idID #IMPLIED -- identifiant unique dans le document --
nameCDATA #REQUIRED -- nom de propriété --
valueCDATA #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" --
>
Cet attribut définit le nom d'un paramètre d'exécution censé être connu des objets insérés.
La sensibilité à la casse de la propriété dépend de l'implémentation spécifique de l'objet.
Cet attribut spécifie la valeur d'un paramètre d'exécution spécifié par l'attribut
name. Les valeurs de propriété
n'ont aucune signification pour HTML : leur signification est
déterminée par l'objet en question.
Cet attribut spécifie le type de l'attribut value. Les valeurs possibles sont :
data : c'est la valeur par défaut de l'attribut. Elle signifie que la valeur spécifiée par
value sera évaluée puis passée à l'implémentation de l'objet sous
forme d'une chaîne ;
ref : la valeur spécifiée par l'attribut value est un URI
qui désigne une ressource dans laquelle les valeurs d'exécution sont stockées. Ceci permet aux outils de gestion
d'identifier les URI qui sont donnés en paramètres.
L'URI doit être passé à l'objet tel quel,
i.e., non résolu ;
object : la valeur spécifiée par l'attribut value est un identifiant
qui se réfère à la déclaration d'un élément OBJECT
dans le même document. L'identifiant doit être la valeur de l'attribut
id mis pour l'élément
OBJECT déclaré.
Cet attribut spécifie le type de contenu de la ressource désignée par l'attribut
valueseulement dans le cas où l'attribut
valuetype a la valeur "ref".
Cet attribut indique donc à l'agent utilisateur le type des valeurs qui seront trouvées à
l'URI que désigne l'attribut value.
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.
L'agent utilisateur ne reconnaît pas les applications Python.
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.
valuetype="ref">
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).
Les exemples précédents n'ont illustré, jusqu'à présent, que des définitions d'objet isolées.
Quand un document doit contenir plusieurs instances du même objet, il est possible de séparer la déclaration
de l'objet de ses instanciations. Cela présente plusieurs avantages :
les données peuvent être ramenées du réseau par l'agent utilisateur une seule fois (lors de la
déclaration) et réutilisées pour chaque instanciation ;
il est possible d'instancier un objet à partir d'un autre endroit que celui de la déclaration de l'objet, par exemple,
à partir d'un lien ;
il est possible de spécifier des objets comme étant des données d'exécution pour d'autres objets.
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.
La Terre vue de l'espace.
...plus loin dans le document...
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...
Il vous manque le fantastique visionneur de poème...
Les agents utilisateurs qui ne reconnaissent pas l'attribut declare
doivent restituer le contenu de la déclaration de l'élément OBJECT.
Cet attribut spécifie l'URI de base pour l'applet.
Si cet attribut n'est pas spécifié, alors il prend par défaut le même URI de base
que celui du document courant. Les valeurs de cet attribut ne peuvent se référer qu'aux sous-répertoires
du répertoire contenant le document courant. Remarque : Bien que la restriction
sur les sous-répertoires constitue un écart par rapport aux pratiques courantes et à la spécification
HTML 3.2, le groupe de travail HTML
a choisi de conserver celle-ci dans cette version de la spécification pour des raisons de sécurité.
Cet attribut spécifie soit le nom du fichier de classe, qui contient la sous-classe d'applet compilée de l'applet,
soit le chemin pour obtenir la classe, y compris le fichier de classe lui-même. Il est évalué par rapport
à l'attribut codebase de l'applet. L'un des attributs code
et object doit être présent.
Cet attribut spécifie une liste des URI, séparés par des virgules,
des archives contenant les classes et les autres ressources qui seront « préchargées ».
Les classes sont chargées en utilisant l'instance d'une classe AppletClassLoader avec la valeur de l'attribut
codebase donné.
Les URI relatifs s'interprètent par rapport à l'attribut
codebase de l'applet. Le préchargement des ressources peut améliorer significativement les performances des applets.
Cet attribut nomme une ressource contenant une représentation sérialisée de l'état d'un applet.
Il est évalué relativement à l'attribut codebase de l'applet. Les données
sérialisées contiennent le nom de classe de l'applet mais pas l'implémentation. Le nom de classe est utilisé
pour chercher l'implémentation dans un fichier de classe ou dans une archive.
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.
Cet attribut spécifie la largeur initiale de la zone d'affichage de l'applet (en excluant les fenêtres ou dialogues
éventuellement créés par l'applet).
Cet attribut spécifie la hauteur initiale de la zone d'affichage de l'applet (en excluant les fenêtres ou dialogues
éventuellement créés par l'applet).
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 :
Un applet Java qui dessine des bulles animées.
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 :
Parfois, plutôt qu'une relation vers un document, l'auteur peut vouloir incorporer celui-ci directement
dans un document HTML principal. Pour cela, l'auteur peut utiliser soit l'élément
IFRAME, soit l'élément
OBJECT, mais ces éléments sont
différents par certains côtés. Ces deux éléments n'ont pas seulement des modèles de contenu
différents, mais l'élément IFRAME
peut être un cadre cible (voir la section sur la spécification des informations du cadre cible
pour les détails) et peut être « sélectionné » par l'agent utilisateur comme
la partie à imprimer, la source HTML à voir, etc. Les agents
utilisateurs peuvent restituer les cadres sélectionnés de manière à les distinguer
des cadres qui ne le sont pas (par exemple, en dessinant une bordure autour du cadre sélectionné).
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...
Avertissement : le fichier "loge_moi.html" n'a pu être incorporé.
...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.
Les images cliquables permettent aux auteurs de spécifier des régions dans une image, ou un objet, et d'assigner une
action particulière à chacune de ces régions (par exemple, ramener un document, lancer un programme, etc.).
Quand l'utilisateur active la région, l'action est exécutée.
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 :
Côté client.
Quand l'utilisateur active une région d'une image cliquable côté client avec une souris, l'agent utilisateur en
interprète les coordonnées du pixel. L'agent utilisateur sélectionne le lien spécifié pour la
région activée et le suit ;
Côté serveur.
Quand l'utilisateur active une région d'une image cliquable côté serveur, les coordonnées du pixel du
clic sont envoyées à l'agent côté serveur, qui est spécifié par l'attribut
href de l'élément
A. L'agent côté serveur interprète ces
coordonnées et effectue une certaine action.
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.
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 --
tabindexNUMBER #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 --
>
Cet attribut spécifie la position et la forme sur l'écran. Le nombre et l'ordre des valeurs dépend de la
forme qui est définie. Les combinaisons possibles sont :
rect : gauche-x, haut-y, droite-x, bas-y ;
circle : centre-x, centre-y, rayon. Remarque : Quand la valeur du rayon est un pourcentage,
l'agent utilisateur devrait calculer le rayon final par rapport à la hauteur et à la largeur de l'objet associé.
Le rayon devrait être la plus petite valeur des deux ;
poly : x1, y1, x2, y2, ..., xN, yN. Le premier couple de coordonnées « x » et « y » et le dernier devraient être
les mêmes pour clore le polygone. Quand ces valeurs de coordonnées ne sont pas les mêmes, l'agent utilisateur
devrait inférer un couple de coordonnées supplémentaire pour clore le polygone.
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.
Cet attribut associe une image cliquable à un élément. Cette image cliquable est définie par
l'élément MAP. La valeur de l'attribut
usemap doit correspondre avec celle de l'attribut name
de l'élément MAP associé.
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 :
Un ou plusieurs éléments AREA.
Ces éléments n'ont aucun contenu mais spécifient les régions géométriques de l'image
cliquable et les liens qui sont associés à chaque région. Remarquez que les agents utilisateurs ne restituent
pas en général les élément AREA.
C'est pourquoi les auteurs doivent fournir un texte de remplacement pour chaque élément
AREA avec l'attribut
alt (voir ci-dessous pour des renseignements sur la manière de spécifier un texte de remplacement) ;
Un contenu de type bloc. Ce contenu devrait comprendre les éléments
A qui spécifient les régions géométriques
de l'image cliquable et le lien associé à chaque région. Remarquez que l'agent utilisateur devraient restituer
le contenu de type bloc d'un élément MAP.
Les auteurs devraient utiliser cette méthode pour créer des documents plus accessibles.
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.
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.
Exemples d'images cliquables côté client
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
OBJECTet 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 barre de navigation.
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 :
texte décrivant l'image...
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.
Surclassement de la hauteur d'une image ou d'un objet.
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éconseillé. Cet attribut spécifie la quantité
d'espace à insérer à gauche et à droite des éléments
IMG,
APPLET
ou OBJECT. La valeur par défaut n'est pas
spécifiée mais il s'agit en général d'une petite longueur non-nulle.
Déconseillé. Cette attribut spécifie la quantité
d'espace à insérer au-dessus et en-dessous des éléments
IMG,
APPLET
ou OBJECT. La valeur par défaut n'est pas
spécifiée mais il s'agit en général d'une petite longueur non-nulle.
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éconseillé. Cet attribut spécifie l'épaisseur
de la bordure d'un élément IMG,
ou OBJECT, en pixels. La valeur par défaut de
cet attribut dépend de l'agent utilisateur.
Déconseillé. Cet attribut spécifie la position
d'un élément IMG,
ou OBJECT,
ou APPLET, par rapport à son contexte.
Les valeurs suivantes de l'attribut align
concernent la position de l'objet par rapport au texte qui l'entoure :
bottom : signifie que le bas de l'objet devrait s'aligner verticalement sur la ligne de base courante. C'est la valeur par défaut ;
middle : signifie que le centre de l'objet devrait s'aligner verticalement sur la ligne de base courante ;
top : signifie que le haut de l'objet devrait s'aligner verticalement sur la ligne de base courante.
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.
Cet attribut spécifie un texte de remplacement pour les agents utilisateurs qui sont incapables d'afficher les images,
les formulaires ou les applets. La langue du texte de remplacement est spécifiée par l'attribut
lang.
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 :
Ne pas spécifier un texte de remplacement non pertinent lors de l'inclusion d'images destinées à la
mise en forme d'une page par exemple, la définition alt="Puce rouge" serait inadéquate pour une
image qui ajoute une puce rouge pour décorer un titre ou un paragraphe. Auquel cas, le texte de remplacement devrait
être la chaîne vide (""). De manière générale, on conseille aux auteurs d'éviter l'emploi d'images pour la mise
en forme des pages ; les feuilles de style sont prévues à cet effet ;
Ne pas spécifier un texte de remplacement dépourvu de signification (par exemple, "texte fictif"). Cela va non seulement
frustrer l'utilisateur, mais aussi ralentir les agents utilisateurs qui doivent convertir le texte en parole ou en sortie Braille.
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.