Cette spécification a été traduite par Karl Dubost, Normandie Web (karl+misc@la-grange.net) dans une démarche volontaire. Toute amélioration est la bienvenue.
François Yergeau (yergeau@alis.com) pour la correction des détails.

La version française de cette traduction est :
http://www.la-grange.net/w3c/xhtml1/

Traducteur : Karl Dubost - <karl+misc@la-grange.net>
François Yergeau <yergeau@alis.com> pour la correction des détails.
La version française peut contenir des erreurs. La version anglaise de cette spécification est l'unique version normative. Version originale : http://www.w3.org/TR/xhtml1

sommaire

W3C

XHTMLMD 1.0 : Le langage de balisage hypertexte extensible

Une reformulation de HTML 4 en XML 1.0

Recommandation W3C 26 Janvier 2000

Cette version :
http://www.w3.org/TR/2000/REC-xhtml1-20000126
(version Postscript, version PDF, archive ZIP, ou archive TAR gzippé)
Dernière version :
http://www.w3.org/TR/xhtml1
Version précédente :
http://www.w3.org/TR/1999/PR-xhtml1-19991210
Auteurs :
Voir remerciements.

Copyright ©2000 W3C® (MIT, INRIA, Keio), tous droits réservés. Les règles du W3C sur la responsabilité, les marques déposées, les droits d'auteurs and les licences de logiciels sont appliquées.

Résumé

Cette spécification définit XHTML 1.0, comme une reformulation de HTML 4 en une application XML 1.0, et trois DTDs correspondant àcelles définies par HTML 4. Les sémantiques des éléments et leurs attributs sont définis dans la Recommendation W3C pour le HTML 4. Ces sémantiques définissent les fondations de l'extensibilité future de XHTML. La compatibilité avec les agents utilisateurs HTML actuels est possible en suivant un ensemble raisonnable de règles.

Statut de ce document

Cette section décrit le statut de ce document à la date de sa publication. D'autres documents pourront remplacer ce document. Le dernier status de cette série de document est maintenu au W3C.

Ce document a été validé par les membres du W3C ainsi que par d'autres organismes et a été approuvé par le Directeur comme une recommandation. C'est un document stable et il peut-être utilisé comme document de référence et peut être cité comme un référence normative pour d'autres documents. Le rôle du W3C dans l'établissement de cette recommandation est d'attirer l'attention sur la spécification et de promouvoir sa large diffusion. Ceci améliore la fonctionnalité et l'interopérabilité du Web.

Ce document a été produit comme une partie de l'Activité HTML du W3C. Les buts du Groupe de travail HTML (réservé aux membres) sont discutés au sein des statuts du Groupe de Travail HTML (réservé aux membres).

Une liste des recommandations actuelles et d'autres documents techniques peut être trouvée à http://www.w3.org/TR.

La discussion publique à propos des spécificités du HTML a lieu sur la liste de discussion www-html@w3.org (archive).

Faites part des erreurs de ce document à www-html-editor@w3.org.

La liste des erreurs connues de cette spécification est disponible à http://www.w3.org/2000/01/REC-xhtml1-20000126-errata.

Sommaire

1. Qu'est-ce que XHTML ?

XHTML est une famille de types de documents futurs et actuels et de modules qui reproduit, détermine des sous-ensembles, et étends HTML 4 [HTML]. La famille XHTML des types de documents est basée sur XML, et est conçue finalement pour fonctionner en accord avec les agents utilisateurs supportant XML. Les détails de cette famille et de son évolution sont discutés plus en détail dans la section Prospectives futures.

XHTML 1.0 (cette spécification) est le premier type de document dans la famille XHTML. C'est une reformulation des trois types de documents HTML 4 en tant qu'applications de XML 1.0 [XML]. Il a été conçu dans le but d'être utilisé come un langage pour le contenu qui est, à la fois, conforme à XML et, si des règles simples sont suivies, fonctionne également avec les agents utilisateurs compatible HTML4. Les développeurs qui font migrer leur contenu vers XHTML 1.0 réaliseront les bénéfices suivants :

La famille XHTML est la prochaine étape de l'évolution d'internet. En migrant aujourd'hui vers XHTML, les développeurs de contenu peuvent entrer dans le monde XML avec tous ses bénéfices attendus, tout en restant confiant sur la compatibilité ascendante et future de leur contenu.

1.1 Qu'est-ce que HTML 4 ?

HTML 4 [HTML] est une application SGML (Standard Generalized Markup Language) conforme au standard international ISO 8879, et qui est largement admise comme le standard du langage de publication du World Wide Web.

SGML est un langage pour décrire les langages de structuration (balisage), particulièrement ceux utilisées dans l'échange de documents électroniques, la gestion documentaire, et la publication de document. HTML est un exemple de langage défini en SGML.

SGML a été créé au milieu des années 80 et est resté stable. Cette stabilité est inhérente au fait que le langage est riche de fonctionnalité et souple. Cette souplesse a, tout de même, un prix, et ce prix est un niveau de complexité qui a empêché son développement dans une grande diversité d'environnements, dont le World Wide Web.

HTML, comme il a été conçu à l'origine, a été défini pour être un langage d'échange de documents scientifiques et techniques, et utilisable par des non spécialistes de la grammaire syntaxique. HTML a résolu le problème de la complexité SGML en spécifiant un petit ensemble de balises sémantiques et structurelles, facilement utilisable pour l'écriture de documents relativement simples. De même pour simplifier la structure du document, HTML a ajouté la possibilité de l'hypertexte. Les capacités Multimedia seront ajoutées plus tard.

En un cours espace de temps, HTML est devenu très populaire et a rapidement dépassé sa fonction première. Depuis le commencement de HTML, il y a eu rapidement création de nouveaux éléments au sein de HTML (en tant que standard) et pour adapter HTML aux marchés verticaux, hautement spécialisés. Cette plethore de nouveaux éléments a finalement créé des disparités de compatibilité entre les différentes plateformes.

Comme l'hétérogénité, à la fois des logiciels et des plateformes, s'est rapidement répandue, il est devenu évident que la facilité d'utilisation du HTML 4 'classique' sur ces plateformes est quelque peu limité.

1.2 Qu'est-ce que XML ?

XMLMD est l'abbréviation de Extensible Markup Language, et est un acronyme de Extensible Markup Language [XML].

XML a été conçu comme un moyen de regagner la puissance et la souplesse de SGML sans pour autant subir sa complexité. Bien qu'étant une forme restreinte de SGML, XML préserve pratiquement toute la puissance et la richesse de SGML, et respecte toutes les options habituellement utilisées de SGML.

Bien que conservant ces options avantageuses, XML élimine la plupart des options complexes de SGML qui rendent la conception et l'écriture de logiciels utiles, à la fois difficile et couteux.

1.3 Pourquoi XHTML ?

Les bénéfices de la migration vers XHTML 1.0 sont décris plus hauts. Quelques uns des bénéfices en général sont :

2. Définitions

2.1 Terminologie

Les termes suivants sont utilisés dans la spécification. Ces termes étendent les définitions contenus dans la [RFC2119] en s'appuyant sur des définitions similaires à celles de l'ISO/IEC 9945-1:1990 [POSIX.1]:

Défini possible (Implementation-defined)
Une valeur ou un comportement est défini possible [et documenté] lorsque les exigences pounr une construction correcte du document sont laissées à la mise-en-oeuvre propre de celui-ci.
Peut (May)
Par rapport aux mises en oeuvre, le mot "peut" (may) doit être interprêté comme une caractéristique optionnelle qui n'est pas exigée dans cette spécification mais qui peut être fournie. Par rapport à la Conformité du document, le mot "peut" (may) signifie que la caractéristique optionnelle ne doit pas être utilisée. Le terme "optionnel" (optional) a la même définition que "peut" (may).
Doit (Must)
Dans cette spécification, le mot "doit" (must) signifie une exigence obligatoire de la mise en oeuvre ou dans des Documents XHTML Strictement Conformes, dépendant du contexte. Le terme "shall" a la même définition que "doit" (must).
Réservé (Reserved)
Une valeur ou un comportement est non spécifié, mais il n'est pas permis de l'utiliser dans un document conforme ou bien d'être mise en oeuvre au sein des agents utilisateurs conformes.
Devrait (Should)
Par rapport aux mises en oeuvre, le mot "devrait" (should) est défini comme une possibilité de la recommandation, mais non pas comme une exigence. Par rapport aux documents, le mot "devrait" (should) est défini comme une pratique recommandée de programmation pour les documents et une exigence pour les Documents XHTML Strictement Conformes.
Maintenu (Supported)
Certains aménagements de cette spécification sont optionnels. Si un aménagement est maintenu, il se conforme tel que spécifié par cette spécification.
Non spécifié (Unspecified)
Quand une valeur ou un comportement sont non spécifiés, la spécification ne définit pas d'exigences particulières de portabilité pour l'aménagement de sa mise en oeuvre même lorsque ce document utilise l'aménagement en question. Un document qui requière un comportement spécifique n'est pas un DOcument XHTML Strictement Conforme, plutôt que tolérer quelque comportement utilisant cet aménagement.

2.2 Termes généraux

Attribut
Un attribut est un paramètre pour un élément déclaré dans la DTD. Un type d'attribut et un intervalle de valeurs, dont possiblement une valeur par défaut, sont définis dans la DTD.
DTD
Une DTD, ou définition de type de document, est un assemblage de déclarations XML qui, en tant qu'assemblage, définit la structure légale, les éléments, et les attributs qui sont disponibles pour un document se conformant à la DTD.
Document
Un document est un flux de données qui, après avoir été combiné avec tout autre flux qu'il référence, est structuré de manière à ce que l'information contenu à l'intérieur des éléments soit organisée tel que défini par la DTD associée. Voir Conformité du document pour plus d'informations.
Elément
un élément est une unité structurante du document déclarée dans la DTD. Le modèle de contenu de l'élément est définit dans la DTD, et la sémantique supplémentaire peut être défini dans la description factuel de l'élément.
Aménagements
Les fonctionnalités comprennent les éléments, les attributs, et les sémantiques associées à ces éléments et ces attributs. Une mise en oeuvre rendant possible cette fonctionnalité est définie pour fournir les aménagements nécessaires.
Mise en oeuvre
Une mise en oeuvre est un système qui fournit un assemblage d'aménagements et de services qui rendent possible cette spécification. Voir Conformité de l'agent utilisateur pour plus d'informations.
Parser
Parser est l'acte par lequel un document est examiné, et par lequel l'information contenue à l'intérieur de ce document est filtré dans le contexte des éléments structurant l'information.
Interprétation
L'interprétation est l'acte par lequel l'information dans un document est présentée. Cette présentation est faite dans la forme la plus appropriée dépendant de l'environnement (soit sonore, visuelle, imprimé).
Agent utilisateur
Un agent utilisateur est une mise en oeuvre qui extrait et traite les documents XHTML. Voir Conformité de l'agent utilisateur pour plus d'informations.
Validation
La validation est traitement par lequel des documents sont vérifiés en fonction de la DTD associée, assurant que la structure, l'utilisation des éléments, et l'utilisation des attributs sont en accord avec les définitions de la DTD.
Bien rédigé
Un document est bien rédigé lorsqu'il est structuré en accord avec les règles définies dans la Section 2.1 de la recommandation XML 1.0 [XML]. Simplement, cette définition dit que les éléments, délimités par leurs balises de début et de fin, sont correctement emboîtés les uns par rapport aux autres.

3. Définition normative de XHTML 1.0

3.1 Conformité du document

Cette version de XHTML fournit une définition des documents XHTML strictement conformes, ce qui la restreint aux balises et attributs de l'espace nominatif XHTML. Voir Section 3.1.2 pour avoir de l'information sur l'utilisation de XHTML avec d'autres espaces nominatifs, par exemple, pour inclure des données méta exprimées en RDF à l'intérieur des documents XHTML.

3.1.1 Documents strictement conformes

Un Document XHTML strictement conforme est un document qui requiert que tous les aménagements soit décrites comme obligatoires dans cette spécification. Un tel document doit recouvrir tous les critères suivants :

  1. Il doit être validé par l'une des trois DTDs fournies dans l'Appendice A.

  2. L'élément racine du document doit être .

  3. L'élément racine du document doit nommer l'espace nominatif XHTML en utilisant l'attribut xmlns [XMLNAMES]. L'espace nominatif pour XHTML est défini par http://www.w3.org/1999/xhtml.

  4. Une déclaration DOCTYPE doit être présente dans le document avant l'élément racine. L'identificateur publique inclue dans la déclaration DOCTYPE doit faire référence à l'une des trois DTDs fournies dans l'Appendice Aen utilisant l'Identificateur Publique Formel. Le système identificateur peut être changé pour agréer aux conventions des systèmes locaux.

    <!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "DTD/xhtml1-strict.dtd">

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
     "DTD/xhtml1-transitional.dtd">

<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN"
     "DTD/xhtml1-frameset.dtd">

Voici un exemple de document XHTML minimal

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
    "DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>Virtual Library</title>
  </head>
  <body>
    <p>Moved to <a href="http://vlib.org/">vlib.org</a>.</p>
  </body>
</html>

Notez que dans cet exemple, la déclaration XML est inclue. Une déclaration XML comme celle-ci n'est pas requise dans tous les documents XML. Les auteurs de documents XHTML sont fortement encouragés d'utiliser des déclarations XML dans tous leurs documents. Ce type de déclaration est requis lorsque l'encodage du document est différent de ceux par défaut tels que UTF-8 ou UTF-16.

3.1.2 Utiliser XHTML avec d'autres espaces nominatifs

L'espace nominatif XHTML peut être utilisé conjointement avec d'autres espaces nominatifs comme par [XMLNAMES], bien que ce type de documents ne soient pas des documents XHTML 1.0 strictement conformes au sens défini plus tôt. Les travaux futurs du W3C donneront des moyens pour spécifier la conformité des documents impliquant plusieurs espaces nominatifs.

L'exemple suivant montre la manière permettrait d'utiliser conjointement XHTML 1.0 et la recommandation MathML :

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <title>A Math Example</title>
  </head>
  <body>
    <p>The following is MathML markup:</p>
    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <apply> <log/>
        <logbase>
          <cn> 3 </cn>
        </logbase>
        <ci> x </ci>
      </apply>
    </math>
  </body>
</html>

L'exemple suivant montre la manière qui permettrait d'utiliser le balisage XHTML 1.0 en l'incorporant dans un autre espace nominatif XML :

<?xml version="1.0" encoding="UTF-8"?>
<!-- initially, the default namespace is "books" -->
<book xmlns='urn:loc.gov:books'
    xmlns:isbn='urn:ISBN:0-395-36341-6' xml:lang="en" lang="en">
  <title>Cheaper by the Dozen</title>
  <isbn:number>1568491379</isbn:number>
  <notes>
    <!-- make HTML the default namespace for a hypertext commentary -->
    <p xmlns='http://www.w3.org/1999/xhtml'>
        This is also available <a href="http://www.w3.org/">online</a>.
    </p>
  </notes>
</book>

3.2 Conformité de l'agent utilisateur

Un agent utilisateur conforme doit respecter tous les critères suivants :

  1. Tout d'abord pour être en accord avec la recommandation XML 1.0 [XML], l'agent utilisateur doit examiné et évalué un document XHTML pour vérifier sa bonne rédaction (grammaire). Si l'agent utilisateur requiert d'être un agent utilisateur de validation, il doit également valider les documents selon les DTDs fournies en accord avec [XML].
  2. Lorsque l'agent utilisateur requiert des aménagements maintenus définis à l'intérieur de cette spécification ou requis par cette spécification au travers d'une référence normative, Il doit le faire de façon à rester en accord avec la définition des aménagements.
  3. Lorsqu'un agent utilisateur traite un document XHTML comme du XML générique, ll ne devrait uniquement reconnaître que les attributs de type ID (soit l'attribut id de la plupart des éléments XML) comme les identificateurs partiels.
  4. Si un agent utilisateur rencontre un élément qu'il ne reconnaît pas, il doit interpréter le contenu de l'élément.
  5. Si un agent utilisateur rencontre un attribut qu'il ne reconnaît pas, il doit ignorer la spécification complète de l'attribut (soit l'attribut et sa valeur).
  6. Si un agent utilisateur rencontre une valeur qu'il ne peut pas reconnaître, il doit utiliser la valeur par défaut de l'attribut.
  7. S'il rencontre une référence d'entité (autres que celles des entités prédéfinies) pour lequel l'agent utilisateur n'a pas traité de déclaration (ce qui peut arriver si la déclaration est un sous-ensemble externe non lu par l'agent utilisateur), la référence d'entité doit être interprétée en tant que caractères (démarrant avec un esperluette et se terminant par un point-virgule) tels qu'ils décrivent la référence d'entité.
  8. Lorsque le contenu est interprété, Les agents utilisateurs qui rencontrent des caractères ou des références d'entité caractère qui sont reconnus mais non interprétables devrait afficher le document de façon à mettre en évidence que l'interprétation normale n'a pas eu lieu.
  9. Les caractères suivants sont définis en [XML] comme des caractères d'espacement :

    Le processeur XML normalise les codes de fin de ligne des différents systèmes en un unique caractère de fin de ligne, qu'il passe ensuite à l'application. L'agent utilisateur XHTML doit, de plus, traiter les caractères suivants comme des espacements :

    Dans les éléments où l'attribut 'xml:space' est défini comme 'preserve', l'agent utilisateur doit laisser tous les caractères d'espacement intacts (à l'exception des caractères d'espacement de début ou de fin, qui doivent être éliminés). Autrement, les espacements sont traités avec les règles suivantes :

    Les valeurs d'attribut d'espacement est traité en suivant [XML].

4. Différences avec le HTML 4

Etant donné que XHTML est une application XML, quelques habitudes qui étaient parfaitement légales dans le HTML 4 basé sur SGML [HTML] doivent être changées.

4.1 Les documents doivent être correctement rédigés

La rédaction correcte est un nouveau concept introduit par [XML]. Essentiellement, cela signifie que tous les éléments doivent toujours avoir des balises de fin ou être écrit dans une forme particulière (comme expliqué plus bas), et que tous les éléments doivent être emboîtés.

Bien que le chevauchement soit illégal en SGML, il est largement toléré par les navigateurs actuels.

CORRECT : éléments emboités.

<p>here is an emphasized <em>paragraph</em>.</p>

INCORRECT : éléments se chevauchant

<p>here is an emphasized <em>paragraph.</p></em>

4.2 Les noms d'élément et d'attribut doivent être en casse minuscule

les documents XHTML documents doivent utiliser la casse minuscule pour tous les noms d'élément HTML et les noms d'attribut. Cette différence est nécessaire car XML est sensible à la casse c.a-d.

4.3 Pour les éléments non-vides, les balises de fin sont obligatoires

Dans le HTML 4 basé sur SGML, il est possible d'omettre la balise de fin de certains éléments ; en considérant que l'élément suivant créé une balise de fin implicite. Cette omission n'est plus autorisée dans le XHTML basé sur XML. Tous les éléments autres que ceux déclarés dans la DTD comme EMPTY doivent posséder une balise de fin.

CORRECT : éléments terminés

<p>here is a paragraph.</p> <p>here is another paragraph.</p>

INCORRECT : éléments non terminés

<p>here is a paragraph.<p>here is another paragraph.

4.4 Les valeurs d'attributs doivent être toujours mise entre guillemets

Toutes les valeurs d'attributs doivent être mise entre guillemets, mais celles qui semblent être numériques.

CORRECT : valeurs d'attributes entre guillemets

<td rowspan="3">

INCORRECT : valeurs d'attributs sans les guillemets

<td rowspan=3>

4.5 Minimisation de l'attribut

XML ne supporte pas la minimisation de l'attribut. la paire Valeur-Attribut doit être écrite au complet. Les noms d'attributs tels que compact et checked ne peuvent pas pris comme éléments sans spécifier leurs valeurs.

CORRECT : attributs non minimisés

<dl compact="compact">

INCORRECT : attributs minimisés

<dl compact>

4.6 Eléments vides

les éléments vides doivent toujours avoir une balise de fin ou la balise de début doit se terminer avec />. Par exemple,
ou

. Voir les règles de compatibilités HTMLpour obtenir de l'information sur les moyens d'assurer une compatibilité antérieure avec les agent utilisateurs HTML 4.

CORRECT : balises vides terminées

<br/><hr/>

INCORRECT : balises vides non terminées

<br><hr>

4.7 Traitement des espacements dans les valeurs d'attribut

Dans les valeurs d'attributs, les agent utilisateurs oteront les espacements de début et de fin des valeurs d'attributs et dresseront une séquence d'un ou plusieurs caractères d'espacements (tels que les retours de lignes) à un unique espacement inter mots (un caractère d'espacement ASCII pour les écritures occidentales). Voir Section 3.3.3 of [XML].

4.8 Les éléments Script et Style

En XHTML, les éléments script et style elements sont déclarés comme ayant un contenu de type #PCDATA. Ainsi, < et & seront traités comme le début d'un balisage, et les entités comme < et & seront reconnus comme des références d'entités par le processeur XML, soit < et & respectivement. Emballer le contenu des éléments script ou style à l'intérieur d'une section marquée CDATA évitera la transformation de ces entités.

<script>
 <![CDATA[
 ... unescaped script content ...
 ]]>
 </script>

les sections CDATA sont reconnus par le processeur XMLet apparaissent commes des noeuds dans le Modèle Object de Document (Document Object Model), voir Section 1.3 de la Recommandation DOM Niveau 1 [DOM].

Une alternative est d'utiliser des scripts et des styles externes.

4.9 Exclusions SGML

SGML donne au rédacteur d'une DTD la possibilité d'exclure la présence de certains éléments à l'intérieur d'un élément. Une telle interdiction (appelée "exclusions") n'est pas possible en XML.

Par exemple, la DTD HTML 4 Stricte interdit l'emboîtement d'un élément 'a' dans un autre élément 'a' à quelques profondeurs que ce soit. Il n'est pas possible de définir ce type d'interdiction en XML. Bien que cette interdiction ne puisse être défini dans la DTD, certains éléments ne devraient pas être emboîtés. Un sommaire de ce type d'éléments et des éléments qui ne devraient pas être emboîtés en leur sein est fournie dans l'Appendice B.

4.10 Les éléments avec les attributs 'id' et 'name'

HTML 4 a défini l'attribut name pour les éléments a, applet, form, frame, iframe, img, and map. HTML 4 a également introduit l'attribut id. Ces deux attributs ont été conçus pour être utilisés comme des identificateurs partiels.

En XML, Les identificateurs partiels sont de type ID, et il ne peut y avoir qu'un unique attribut ID par élément. En XHTML 1.0 l'attribut id est aussi défini de type ID. Pour s'assurer que les documents XHTML 1.0 sont des documents XML correctement structurés, les documents XHTML 1.0 DOIVENT utiliser l'attribut id quand l'identificateur partiel est défini, même sur les éléments qui historiquement ont également un attribut name. Voir les règles de compatibilité HTML pour obtenir de l'information pour assurer une compatibilité antérieures lorsque les ancres pointent sur des documents XHTML en tant que type de média text/html.

Notez qu'en XHTML 1.0, l'attribut name de ces éléments est formellement abandonné, et il sera éliminé dans les versions suivantes de XHTML.

5. Problèmes de compatibilité

Bien qu'il ne soit pas obligatoire que les documents XHTML 1.0 soient compatibles avec les agent utilisateurs actuels, cette option est facilement réalisable. Les régles pour créer des documents compatibles peuvent être trouvées dans l'Appendice C.

5.1 Type de Media Internet

Comme la publication de cette recommandation, le nommage MIME général recommandé pour les applications n'a pas encore été résolus.

Cependant, les documents XHTML qui suivent les régles définies dans l'Appendice C, "HTML Compatibility Guidelines" peuvent être nommés avec le Type Media Internet "text/html", lorsqu'ils sont compatibles avec la plupart des navigateurs HTML. Ce document ne fait aucune recommandation à propos du choix du nommage MIME pour les autres documents XHTML.

6. Directions futures

XHTML 1.0 fournit les bases d'une famille de types de documents qui étendront et définiront des sous-ensembles XHTML, de façon à maintenir une large variété de nouveaux matériels et d'applications, en définissant des modules et en spécifiant le mécanisme pour combiner ces modules. Ce mécanisme permettra l'extension et la construction de sous-ensembles de XHTML 1.0 de façon unique à travers la définition de nouveaux modules.

6.1 Modularisation de HTML

Comme l'utilisation de XHTML se fait des agents utilisateurs traditionnels vers d'autres plateformes, il est clair que tous les éléments XHTML ne seront pas nécessaires sur toutes les plateformes. Par exemple, un ordinateur de poche ou un téléphone cellulaire peuvent seulement maintenir un sous-ensemble d'éléments de XHTML.

Le processus de modularisation éclate XHTML en une séries d'ensembles d'éléments plus petits. Ces éléments peuvent être recombinés afin de remplir les besoins de différentes communautés.

Ces modules seront définis ultérieurement dans un document W3C.

6.2 Sous-ensembles et extensibilité

La modularisation apporte certains avantages :

6.3 Profils de document

Un profil de document spécifie la syntaxe et les sémantiques d'un ensemble de documents. La conformité à un profil de document donne une base pour garantir l'interopérabilité. Le profil de document spécifie les aménagements obligatoires pour traiter les documents de ce type, c.à-d. quels formats d'images peuvent être utilisés, niveaux de scripting, maintenance des feuilles de style, ainsi de suite.

Les créateurs de produits cela permet à des groupes différents de définir leur propre profil standard.

Pour les auteurs, cela permet d'éviter d'écrire différentes versions d'une même document pour différents clients.

Pour des groupes particuliers comme les chimistes, les docteurs en médecine, ou les mathématiciens cela permet de construire un profil particulier en utilisant les éléments HTML standard, plus un groupe d'éléments spécifiques aux besoins de la spécialité.

Appendice A. DTDs

Cet appendice est normatif.

Ces DTDs et ces ensembles d'entité forme une partie normative de cette spécification. L'ensemble complet des fichiers DTD ainsi que la déclaration XML et le SGML Open Catalog sont inclus dans le fichier zip pour cette spécification.

A.1 Définitions de Type du Document

Ces DTDs s'approchent des DTDs HTML 4. Il est préferrable lorsque les DTDs sont modularisées, d'employer une méthode de construction de la DTD qui se rapproche de HTML 4.

A.2 Ensembles d'entité

Les ensembles d'entité XHTML sont les mêmes que pour HTML 4, mais ont été modifiés pour des déclarations d'entités XML 1.0 valides. Notez que l'entité pour le symbole de la monnaie européenne Euro (€ ou € ou €) est défini comme faisant parti des caractères spéciaux.

Appendice B. Interdictions d'élément

Cette appendice est normatif.

Les éléments suivants ont des interdits sur les éléments qu'ils peuvent contenir (voir Section 4.9). Cette interdiction s'applique à toutes profondeurs d'emboîtements, c.à-d. pour tous les éléments fils.

a
ne peut pas contenir d'autres éléments a.
pre
ne peut pas contenir les éléments img, object, big, small, sub, ou sup.
button
ne peut pas contenir les élémentsinput, select, textarea, label, button, form, fieldset, iframe ou isindex.
label
ne peut pas contenir d'autres éléments label.
form
ne peut pas contenir d'autres élémentsform.

Appendice C. Règles de Compatibilité HTML

Cet appendice est informatif.

Cet appendice résume les règles pour les auteurs qui souhaitent que leur document XHTML s'affiche sur les agents utilisateurs existants.

C.1 Instructions de traitement

Vérifiez que les instructions de traitement s'éxécutent sur les agent utilisateurs. Cependant, notez également que si la déclaration XML n'est pas incluse dans un document, le document peut utiliser uniquement le jeu de caractère par défaut UTF-8 ou UTF-16.

C.2 Eléments vides

Inclure un espacement avant le / et >de fin des éléments vides, par exemple <br />, <hr /> et <img src="karen.jpg" alt="Karen" />. Utilisez également une syntaxe minale pour les éléments vides, par exemple <br />, comme syntaxe alternative de <br></br> qui est autorisé par XML, car cela donne des résultats inattendus dans certains agents utilisateurs.

C.3 Minimisation d'élément et contenu d'élément vide

Soit une occurrence vide d'un élément dont le modèle de contenu n'est pas EMPTY (par exemple, un titre ou un paragraphe vide), n'utilisez pas la forme minimisée (utilisez <p> </p> et non pas <p />).

C.4 Les feuilles de styles imbriquées et les scripts

Utilisez des feuilles de style externe si votre feuille de style utilise < ou & ou ]]> ou --. Utilisez des scripts externes si vos scripts utilisent < ou & ou ]]> ou --. Notez que les parseurs XML ont le droit d'éliminer le contenu des commentaires. Par conséquent, la pratique historique de "cacher" ses scripts et ses feuilles de style au sein d'un commentaire pour rendre les documents compatibles avec les anciens navigateurs n'est pas conseillée car elle ne fonctionnera comme attendue dans les mises en oeuvre basées sur XML.

C.5 Retours de ligne à l'intérieur des valeurs d'attributs

Evitez les retours de ligne et les caractères d'espacement muliples au sein des valeurs d'attributs. Ils seront traités illogiquement par les agents utilisateurs.

C.6 Isindex

Ne mettez pas plus d'un élément isindex dans le head d'un document. L'élément isindex est abandonné en faveur de l'élément input.

C.7 Les attributs lang et xml:lang

Utilisez les deux attributs lang et xml:lang lorsque vous spécifiez le langage d'un élément. La valeur de l'attribut xml:lang est prioritaire.

C.8 Identificateurs partiels

En XML, les URIs [RFC2396] qui termine avec des identificateurs partiels de la forme "#foo" ne se réfère pas aux éléments avec un attribut name="foo" ; mais au contraire, ils se réfèrent aux éléments avec un attribut défini de type ID, c-à.d., l'attribut id de HTML 4. Beaucoup de clients HTML existants ne maintiennent pas l'utilisation des attributs de type ID de cette manière, donc des valeurs identiques doivent être fournies pour les deux attributs pour assurer une compatibilité ascendante et descendante maximum (c.à-d., ...).

Egalement, depuis que l'ensemble des valeurs légales définies pour les attributs de type ID est bien plus restreint que pour ceux de type CDATA, le type de l'attribut name a été changé en NMTOKEN. Cet attribut est contraint de manière à ce qu'il ne puisse avoir que les mêmes valeurs que celles de type ID, ou comme la production Name en XML 1.0 Section 2.5, production 5. Malheureusement, cette contrainte ne peut pas être exprimée dans les DTDs XHTML 1.0. A cause de ces changements, la plus grande attention doit être prise lors de la conversion de vos documents HTML existants. Les valeurs de ces attributs doivent être uniques à l'intérieur d'un document, valides et toutes références à ces identificateurs partiels (qu'ils soient internes ou externes) doit être mise à jour même si les valeurs doivent être changées durant la conversion

Finalement, notez que le XHTML 1.0 a abandonné l'attribut name des éléments a, applet, form, frame, iframe, img, and map, et qu'il sera éliminé dans les versions suivantes.

C.9 Encodage de caractère

Pour spécifier l'encodage de caractère dans le document, utilisez la spécification de l'attribut d'encodage dans la déclaration xml (par exemple <?xml version="1.0" encoding="EUC-JP"?>) et une déclaration meta http-equiv (par exemple <meta http-equiv="Content-type" content='text/html; charset="EUC-JP"' />). La valeur de l'attribut d'encodage de instruction de traitement xml est prioritaire.

C.10 Attributs booléens

Quelques agent utilisateurs HTML sont incapables d'interprêter les attributs booléens quand ils apparaissent dans leur forme complète (non-minimisée), tels que requis par XML 1.0. Notez que ce problème n'affecte pas les agents utilisateurs compatibles avec HTML 4. Cela concerne les attributs suivants : compact, nowrap, ismap, declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer.

C.11 Modèle Objet du Document et XHTML

La recommandation de Modèle Objet du Document niveau 1 [DOM] définit les interfaces du modèle objet du document pour XML et HTML 4. Le modèle objet du document du HTML 4 spécifie que les noms des élements et des attributs HTML sont retournés en casse majuscule. Le modèle objet du document XML spécifie que les noms des élements et des attributs sont retournés dans la casse spécifiée. En XHTML 1.0, les noms des éléments et des attributs sont spécifiés dans la casse minuscule. Cette différence apparente peut être fixée de 2 manières :

  1. Les applications qui accèdent à des documents XHTML distribués avec le type de media Internet text/html via le DOM peuvent utiliser le DOM HTML, et peuvent s'appuyer sur des noms d'éléments et d'attributs retournés en majuscule par ces interfaces.
  2. Les applications qui accèdent à des documents XHTML distribués avec le type de media Internet text/html ou application/xml peuvent également utiliser le DOM XML. Les noms des élements et des attributs seront retournés dans la casse minuscule. Quelques éléments XHTML peuvent apparaitre ou ne pas apparaître, également, dans l'arbre d'objet parce-qu'ils sont optionnels dans le modèle de contenu (par exemple l'élément tbody à l'intérieur d'un tableau table). Cela arrive parce-qu'en HTML 4 quelques éléments avaient la permission d'être minimisés tels que leur balise de début et de fin pouvaient être toutes les deux omises (une fonctionnalité SGML). Ce n'est pas possible en XML. Plutôt que de demander aux auteurs de document d'insérer des éléments hors contexte, XHTML a rendu les éléments optionnels. Les applications ont besoin de s'adapter en respectant cela.

C.12 Utilisation de l'esperluette dans les valeurs d'attributs

Quand une valeur d'attribut contient une esperluette, il doit être exprimé comme une référence d'entité du caractère (par exemple "&"). Par exemple, quand l'attribut href de l'élément a pointe vers un script CGI qui accepte des paramètres, il doit être exprimé comme ceci http://my.site.dom/cgi-bin/myscript.pl?class=guest&amp;name=user plutôt que http://my.site.dom/cgi-bin/myscript.pl?class=guest&name=user.

C.13 Feuilles de Style Imbriquées (CSS) et XHTML

La recommandation des feuilles de style imbriquée niveau 2 [CSS2] définit les propriétés qui sont appliquées à l'arbre d'analyse grammaticale du document HTML ou XML. Les différences dans l'analyse produiront différents résultats sonores ou visuels, dépendant des sélecteurs utilisés. Les indicateurs suivants réduiront cet effet pour des documents qui sont distribués sans modification des deux types de média :

  1. les feuilles de style CSS pour le XHTML devrait utiliser des noms d'éléments et d'attributs de casse minuscule.
  2. Dans les tableaux, l'élément tbody sera déduit par le parseur d'un agent utilisateur HTML, mais pas par le parseur de l'agent utilisateur XML. Par conséquent, vous devriez toujours ajouter explicitement un élément tbody si il se réfère à un sélecteur CSS.
  3. Au sein de l'espace nominatif XHTML, les agent utilisateurs reconnaîtront l'attribut "id" comme un attribut de type ID. Par conséquent, les feuilles de style devraient être capable de continuer à utiliser la syntaxe raccourcie "#" du sélecteur même si l'agent utilisateur ne lit pas la DTD.
  4. Au sein de l'espace nominatif XHTML, les agent utilisateurs reconnaîtront l'attribut "class". Par conséquent, les feuilles de style devraient être capable de continuer à utiliser la syntaxe raccourcie "." du sélecteur.
  5. Les CSS définissent différentes règles de conformité pour les documents HTML et XML ; faites attention que les règles HTML s'appliquent aux documents XHTML distribués en tant que HTML et que les règles XML s'appliquent aux documents XHTML distribués en tant que XML.

Appendice D. Remerciements

Cet appendice est informatif.

Cette spécification a été écrite avec la participation des membres du groupe de travail HTML du W3C :

Steven Pemberton, CWI (HTML Working Group Chair)
Murray Altheim, Sun Microsystems
Daniel Austin, AskJeeves (CNET: The Computer Network through July 1999)
Frank Boumphrey, HTML Writers Guild
John Burger, Mitre
Andrew W. Donoho, IBM
Sam Dooley, IBM
Klaus Hofrichter, GMD
Philipp Hoschka, W3C
Masayasu Ishikawa, W3C
Warner ten Kate, Philips Electronics
Peter King, Phone.com
Paula Klante, JetForm
Shin'ichi Matsui, Panasonic (W3C visiting engineer through September 1999)
Shane McCarron, Applied Testing and Technology (The Open Group through August 1999)
Ann Navarro, HTML Writers Guild
Zach Nies, Quark
Dave Raggett, W3C/HP (W3C lead for HTML)
Patrick Schmitz, Microsoft
Sebastian Schnitzenbaumer, Stack Overflow
Peter Stark, Phone.com
Chris Wilson, Microsoft
Ted Wugofski, Gateway 2000
Dan Zigmond, WebTV Networks

Appendice E. Références

Cet appendice est informatif.

[CSS2]
´ Cascading Style Sheets, level 2 (CSS2) Specification ª, B. Bos, H. W. Lie, C. Lilley, I. Jacobs, 12 May 1998.
Dernière version disponible à : http://www.w3.org/TR/REC-CSS2
[DOM]
´ Document Object Model (DOM) Level 1 Specification ª, Lauren Wood et al., 1 October 1998.
Dernière version disponible à : http://www.w3.org/TR/REC-DOM-Level-1
[HTML]
´ HTML 4.01 Specification ª, D. Raggett, A. Le Hors, I. Jacobs, 24 December 1999.
Dernière version disponible à : http://www.w3.org/TR/html401
Version française (non complète) disponible à : http://www.la-grange.net/w3c/html401/
[POSIX.1]
´ ISO/IEC 9945-1:1990 Information Technology - Portable Operating System Interface (POSIX) - Part 1: System Application Program Interface (API) [C Language] ª, Institute of Electrical and Electronics Engineers, Inc, 1990.
[RFC2046]
´ RFC2046: Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types ª, N. Freed and N. Borenstein, November 1996.
Disponible à http://www.ietf.org/rfc/rfc2046.txt. Note that this RFC obsoletes RFC1521, RFC1522, and RFC1590.
[RFC2119]
´ RFC2119: Key words for use in RFCs to Indicate Requirement Levels ª, S. Bradner, March 1997.
Disponible à : http://www.ietf.org/rfc/rfc2119.txt
[RFC2376]
´ RFC2376: XML Media Types ª, E. Whitehead, M. Murata, July 1998.
Disponible à : http://www.ietf.org/rfc/rfc2376.txt
[RFC2396]
´ RFC2396: Uniform Resource Identifiers (URI): Generic Syntax ª, T. Berners-Lee, R. Fielding, L. Masinter, August 1998.
Ce document met à jour la RFC1738 et RFC1808.
Disponible à : http://www.ietf.org/rfc/rfc2396.txt
[XML]
´ Extensible Markup Language (XML) 1.0 Specification ª, T. Bray, J. Paoli, C. M. Sperberg-McQueen, 10 February 1998.
Dernière version disponible à : http://www.w3.org/TR/REC-xml
Version française disponible à : http://babel.alis.com/web_ml/xml/REC-xml.fr.html
[XMLNAMES]
´ Namespaces in XML ª, T. Bray, D. Hollander, A. Layman, 14 January 1999.
XML namespaces provide a simple method for qualifying names used in XML documents by associating them with namespaces identified by URI.
Dernière version disponible à : http://www.w3.org/TR/REC-xml-names

Level Triple-A conformance icon, W3C-WAI Web Content Accessibility Guidelines 1.0