Sections contenant des références : [Documentation connexe|Table des matières de la RFC 1866|Accès direct à chacune des 76 pages de la RFC 1866|Accès direct à chacune des balises HTML décrite par la RFC 1866]
-
Accès direct au guide de lecture -
Il existe d'ailleurs des livres sur HTML qui sont articulés entièrement autour des différents chapitres de cette RFC. Ce document se propose de fouiller en détail les possibilités d'une telle démarche, en utilisant au mieux les possibilités de l'hypertexte. Il a été rédigé dans le cadre d'un travail de recherche sur l'ergonomie des sites Web (projet webBO (http://webbo.enst-bretagne.fr/)), quand l'auteur s'est aperçu que les connaissances de base manquaient cruellement aux développeurs et mainteneurs de zones Web, alors que dans le même temps les documents de base décrivant le Web et ses projets connexes permettaient l'accès à ces connaissances, dès qu'on était en mesure de les déchiffrer. L'auteur se propose donc de vous donner le goût d'aller chercher vous-même la connaissance à la source...
La deuxième numérotation est alphanumérique (i.e. section B.2), et indexe les différentes sections de ce Guide de Lecture.
Voici la table des matières alphanumérique de ce guide de lecture :
Le deuxième type de liens hypertextes pointe vers des documents extérieurs à celui-ci (comme les références elles-même, ou tout autre document permettant d'appuyer une démonstration ou de donner des renseignements complémentaires, voire des pistes d'exploration).
Le lecteur de ce document est invité dans un premier temps à suivre la trame ordinaire de lecture, c'est-à-dire en allant du début vers la fin. Il peut emprunter les liens internes et utiliser la fonction Backward de son navigateur pour reprendre sa lecture là où il l'avait laissée. Les liens externes qu'il est nécessaire d'emprunter (annexes à ce document par exemple) sont explicitement indiqués, les autres pouvant être empruntés dès que le lecteur estimera avoir pris la mesure de ce document...
example : exemple
Voir [Example-book], I.e.1, p23
Ensuite, une petite connaissance du Web, d'Internet, d'HTML vous permettra d'avoir une impresion de déjà-vu, mais ce n'est pas complètement nécessaire.
"Insisting on HTML 4.0 compliance now will preserve your free choice of suppliers of Web software, tools and applications well into the future. With HTML 4.0, any Web application can be vendor independent. There really is no excuse for tying yourselves or your partners to proprietary solutions."
-- Tim Berners-Lee, W3C Director and inventor of the World Wide Web
[A | ADDRESS | B | BASE | BLOCKQUOTE | BODY | BR | CITE | CODE | DD | DIR | DL | DT | EM | FORM | HEAD | H1..H6 | HR | HTML | I | IMG | INPUT | ISINDEX | KBD | LI | LINK | MENU | META | NEXTID | OL | OPTION | P | PLAINTEXT | PRE | SAMP | SELECT | STRONG | TEXTAREA | TITLE | TT | UL | VAR ]
| Balise (section 5) | Description sommaire | Section 9 |
|---|---|---|
| TITLE | Titre du document | TITLE |
| ISINDEX | Recherche basique au sein du document | ISINDEX |
| BASE | URL de base du document | BASE |
| META | Meta-informations | META |
| LINK | Documents connexes | LINK |
| NEXTID | inclus pour raisons historiques | NEXTID |
| Balise (section 5 ou 8) | Description sommaire | Section 9 |
|---|---|---|
| En-têtes | ||
| H1...H6 | Niveaux d'en-têtes | H1..H6 |
| Listes | ||
| UL | Listes non-ordonnées | UL |
| OL | Listes ordonnées | OL |
| DIR | Liste non-ordonnée d'articles cours | DIR |
| MENU | Liste non-ordonnée d'articles tenant sur une ligne | MENU |
| LI | Item de liste | LI |
| DL | Liste de définitions | DL |
| DT | Terme à définir | DT |
| DD | Définition du terme | DD |
| Conteneurs de texte | ||
| P | Paragraphes | P |
| PRE | Paragraphes préformattés | PRE |
| BLOCKQUOTE | Larges citations | BLOCKQUOTE |
| ADDRESS | Adresse | ADDRESS |
| Divers | ||
| FORM | Formulaire | FORM |
| HR | Ligne horizontale | HR |
| Balise (section 5 ou 8) | Description sommaire | Section 9 |
|---|---|---|
| Balises logiques | ||
| EM | Texte mis en valeur | EM |
| STRONG | Texte fortement mis en valeur | STRONG |
| CODE | Segment de code
| CODE |
| SAMP | Exemples mis en valeur | SAMP |
| KBD | Informations entrées au clavier | KBD |
| VAR | Variables | VAR |
| CITE | Courte citation | CITE |
| Balises Physiques | ||
| I | Italiques | I |
| B | Graisse | B |
| TT | Télétype | TT |
| Balises spéciales | ||
| A | Hyperlien | A |
| IMG | Images | IMG |
| BR | Passage à la ligne | BR |
| Balises de formulaires | ||
| INPUT | Champ d'entrée | INPUT |
| SELECT | Champ de sélection | SELECT |
| OPTION | Choix (au sein d'un champ de sélection) | OPTION |
| TEXTAREA | Aire de texte | TEXTAREA |
Network Working Group T. Berners-Lee
Request for Comments: 1866 MIT/W3C
Category: Standards Track D. Connolly
November 1995
Hypertext Markup Language - 2.0
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Toutes les RFC, tous les working drafts et autres documents de
travail de ce genre comportent une clause de ce type, permettant d'établir
clairement le contexte d'exploitation et de redistribution de ce document.
HTML 2.0 a été suivi depuis novembre 1995 par d'autres documents de ce
type, dont voici une liste, assortie de commentaires :
Abstract The Hypertext Markup Language (HTML) is a simple markup language used to create hypertext documents that are platform independent. HTML documents are SGML documents with generic semantics that are appropriate for representing information from a wide range of domains. HTML markup can represent hypertext news, mail, documentation, and hypermedia; menus of options; database query results; simple structured documents with in-lined graphics; and hypertext views of existing bodies of information.
markup : balisage
SGML document : document SGML
Dans leur RFC, les auteurs agrémentent leur DTD de commentaires pour aider le développeur d'un navigateur qui présenterait des documents selon cette DTD ; nous aurons l'occasion d'en reparler.
continued from abstract...
HTML has been in use by the World Wide Web (WWW) global information
initiative since 1990. This specification roughly corresponds to the
capabilities of HTML in common use prior to June 1994. HTML is an
application of ISO Standard 8879:1986 Information Processing Text and
Office Systems; Standard Generalized Markup Language (SGML).
The "text/html" Internet Media Type (RFC 1590) and MIME Content Type
(RFC 1521) is defined by this specification.
Media Type : ???
La RFC a donc été produite pour figer l'état de l'art HTML tel qu'observé avant juin 1994. Noter que le document est rédigé en octobre 1995, date à laquelle de nombreuses extensions à ce qui n'était pas encore du HTML 2.0 avaient été développées pour certains navigateurs (au sujet des extensions, voir un autre document rédigé par l'auteur : "HTML et ses extensions" http://www-eleves.enst-bretagne.fr/~maubant/publis/jrnTech170996/articlePourHTML.html ).continued from RFC 1866...
Table of Contents
1. Introduction ........................................... 2
1.1 Scope .................................................. 3
1.2 Conformance ............................................ 3
2. Terms .................................................. 6
3. HTML as an Application of SGML .........................10
3.1 SGML Documents .........................................10
3.2 HTML Lexical Syntax ................................... 12
3.3 HTML Public Text Identifiers .......................... 17
3.4 Example HTML Document ................................. 17
4. HTML as an Internet Media Type ........................ 18
Berners-Lee & Connolly Standards Track [Page 1]
Pourquoi cette mention de page 1 ? Tout simplement parce que ce document
est composé de telle manière à être facilement imprimable, page par page
(document possédant un nombre de lignes standard).
Le lecteur qui aurait besoin d'aller directement aux pages
ainsi mentionnées peut utiliser la liste des liens hypertextes
suivante :
[1][2][3][4][5][6][7][8][9][10]
[11][12][13][14][15][16][17][18][19][20]
[21][22][23][24][25][26][27][28][29][30]
[31][32][33][34][35][36][37][38][39][40]
[41][42][43][44][45][46][47][48][49][50]
[51][52][53][54][55][56][57][58][59][60]
[61][62][63][64][65][66][67][68][69][70]
[71][72][73][74][75][76]
Au début de sa RFC, les auteurs vont replacer HTML dans un contexte plus large. Ce sera très instructif.
continued from TOC...
RFC 1866 Hypertext Markup Language - 2.0 November 1995
4.1 text/html media type .................................. 18
4.2 HTML Document Representation .......................... 19
5. Document Structure .................................... 20
5.1 Document Element: HTML ................................ 21
5.2 Head: HEAD ............................................ 21
5.3 Body: BODY ............................................ 24
5.4 Headings: H1 ... H6 ................................... 24
5.5 Block Structuring Elements ............................ 25
5.6 List Elements ......................................... 28
5.7 Phrase Markup ......................................... 30
5.8 Line Break: BR ........................................ 34
5.9 Horizontal Rule: HR ................................... 34
5.10 Image: IMG ............................................ 34
6. Characters, Words, and Paragraphs ..................... 35
6.1 The HTML Document Character Set ....................... 36
7. Hyperlinks ............................................ 36
7.1 Accessing Resources ................................... 37
7.2 Activation of Hyperlinks .............................. 38
7.3 Simultaneous Presentation of Image Resources .......... 38
7.4 Fragment Identifiers .................................. 38
7.5 Queries and Indexes ................................... 39
7.6 Image Maps ............................................ 39
8. Forms ................................................. 40
8.1 Form Elements ......................................... 40
8.2 Form Submission ....................................... 45
Jusqu'ici, les auteurs n'ont fait qu'expliquer ce qu'il y avait derrière
HTML 2.0. C'est à présent que les choses sérieuses vont commencer, la
DTD
dans toute sa beauté.
DTD (Document Type Definition) : définition d'un modèle de document
continued from TOC...
9. HTML Public Text ...................................... 49
9.1 HTML DTD .............................................. 49
9.2 Strict HTML DTD ....................................... 61
9.3 Level 1 HTML DTD ...................................... 62
9.4 Strict Level 1 HTML DTD ............................... 63
9.5 SGML Declaration for HTML ............................. 64
9.6 Sample SGML Open Entity Catalog for HTML .............. 65
9.7 Character Entity Sets ................................. 66
10. Security Considerations ............................... 69
11. References ............................................ 69
12. Acknowledgments ....................................... 71
12.1 Authors' Addresses .................................... 71
13. The HTML Coded Character Set .......................... 72
14. Proposed Entities ..................................... 75
1. Introduction
The HyperText Markup Language (HTML) is a simple data format used to
create hypertext documents that are portable from one platform to
another. HTML documents are SGML documents with generic semantics
that are appropriate for representing information from a wide range
of domains.
Berners-Lee & Connolly Standards Track [Page 2]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
As HTML is an application of SGML, this specification assumes a
working knowledge of [SGML].
HTML document : document HTML
À chaque apparition d'une référence pour la première fois, j'inclue le texte intégral de cette référence dans le cours du document. Par la suite, le lecteur trouvera des liens directs vers le chapitre 11 qui contient toutes les références. [SGML]
ISO 8879. Information Processing -- Text and Office
Systems - Standard Generalized Markup Language (SGML),
1986. <URL:http://www.iso.ch/cate/d16387.html>
Reprennons à présent la présentation de la RFC, avec une sorte
d'abstract (résumé) délocalisé...
continued from RFC 1866...
1.1. Scope HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. Previously, informal documentation on HTML has been available from a number of sources on the Internet. This specification brings together, clarifies, and formalizes a set of features that roughly corresponds to the capabilities of HTML in common use prior to June 1994. A number of new features to HTML are being proposed and experimented in the Internet community. This document thus defines a HTML 2.0 (to distinguish it from the previous informal specifications). Future (generally upwardly compatible) versions of HTML with new features will be released with higher version numbers. HTML is an application of ISO Standard 8879:1986, "Information Processing Text and Office Systems; Standard Generalized Markup Language" (SGML). The HTML Document Type Definition (DTD) is a formal definition of the HTML syntax in terms of SGML. This specification also defines HTML as an Internet Media Type[IMEDIA] and MIME Content Type[MIME] called `text/html'. As such, it defines the semantics of the HTML syntax and how that syntax should be interpreted by user agents.Il est important de comprendre que les choses ne se font pas au hasard, sur Internet. Comme vous le savez peut-être, tout utilisateur qui sait s'y prendre peut faire évoluer Internet. Une de ses possibilités est de proposer des RFC (request for comments). Il va de soi que certaines RFC reposent fortement sur des RFC antérieures, et c'est le cas de la RFC qui nous occupe. Elle repose en effet sur MIME, ou comment décrire un format de données circulant sur Internet, et IMEDIA, ou comment officialiser un nouveau format selon MIME.
[MIME]
Borenstein, N., and N. Freed. "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet Message
Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
<URL:ftp://ds.internic.net/rfc/rfc1521.txt>
[IMEDIA]
Postel, J., "Media Type Registration Procedure",
RFC 1590, USC/Information Sciences Institute, March 1994.
<URL:ftp://ds.internic.net/rfc/rfc1590.txt>
Les festivités commencent à présent...
continued from RFC 1866...
1.2. Conformance This specification governs the syntax of HTML documents and aspects of the behavior of HTML user agents.Autrement dit, cette RFC non seulement explique ce qu'est HTML, mais également donne des conseils sur le comportement attendu des navigateurs (les fameux user agents, ou UA) face à des documents HTML tels que spécifiés précédemment. C'est ce dernier point, le comportement attendu, qui fait le plus souvent défaut -ce qui tendrait à dire que les personnes qui développent des navigateurs n'ont pas bien compris le sens de cette DTD.
Mais ce ne sera pas votre cas, n'est-ce-pas ?
continued from RFC 1866...
1.2.1. Documents
A document is a conforming HTML document if:
* It is a conforming SGML document, and it conforms to the
HTML DTD (see 9.1, "HTML DTD").
NOTE - There are a number of syntactic idioms that
are not supported or are supported inconsistently in
some historical user agent implementations. These
idioms are identified in notes like this throughout
this specification.
* It conforms to the application conventions in this
specification. For example, the value of the HREF attribute
Berners-Lee & Connolly Standards Track [Page 3]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
of the <A> element must conform to the URI syntax.
Trois points fondamentaux définissent un document pouvant
se qualifier d'HTML. Nous voyons tout d'abord les deux premiers.
* Its document character set includes [ISO-8859-1] and
agrees with [ISO-10646]; that is, each code position listed
in 13, "The HTML Coded Character Set" is included, and each
code position in the document character set is mapped to the
same character as [ISO-10646] designates for that code
position.
NOTE - The document character set is somewhat
independent of the character encoding scheme used to
represent a document. For example, the `ISO-2022-JP'
character encoding scheme can be used for HTML
documents, since its repertoire is a subset of the
[ISO-10646] repertoire. The critical distinction is
that numeric character references agree with
[ISO-10646] regardless of how the document is
encoded.
[ISO-10646]
ISO/IEC 10646-1:1993 Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane
<URL:http://www.iso.ch/cate/d18741.html>
[ISO-8859-1]
ISO 8859. International Standard -- Information
Processing -- 8-bit Single-Byte Coded Graphic Character
Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.
<URL:http://www.iso.ch/cate/d16338.html>
Le lecteur désireux d'en savoir plus sur le codage des caractères est
invité à se reporter à l'excellent article
de
Jacques André et Michel Goossens intitulé "Codage des caractères : de
l'ASCII à UNICODE et ISO/IEC-10646". Ce que nous exposons à présent est tiré
en grande partie de cet article.
(ftp://ftp.univ-rennes1.fr/pub/GUTenberg/publicationsPS/20-jamg.ps.gz)
Ce que les auteurs de la RFC 1866 clarifient ici, c'est le jeu de caractères utilisable pour écrire un document HTML (ce qui n' est pas la même chose que le jeu de caractère affiché par le navigateur ; ici on parle seulement des caractères que vous pouvez voir en regardant le source du document HTML). Ce jeu-là est ISO 8859-1, appelé autrement isolatin1. C'est le jeu de caractères utilisé par les langues d'europe occidentale et d'amérique latine, à savoir : allemand, anglais, danois, espagnol, féroïen, finnois, français, islandais, italien, néerlandais, norvégien, portugais et suédois.
Ce jeu contient tous les caractères ASCII (ISO 646) plus 128 autres caractères (soit 256 caractères en tout, mais seulement 191 sont imprimables). C'est dans ces 128 caractères que l'on retrouve les caractères avec diacritiques (accents, cédilles, etc... sauf l'"e dans l'o"). Ces 128 caractères suplémentaires impliquent l'utilisation du 8ième bit de l'octet nécessaire pour coder un caractère. C'est pour cette raison que des entités comme é pour l'"é" ont été introduites, de manière à permettre à ceux qui le désirent d'écrire de l'HTML seulement avec 7 bits, c'est-à-dire avec le jeu de caractères ASCII seulement. Mais rien ne vous oblige à utiliser ces entités qui en effraient plus d'un de prime abord.
ISO 10646 permet de coder les caractères sur plusieurs octets, ce qui honore toutes les langues du monde. Ce que la NOTE exprime, c'est que, par exemple, un japonais peut écrire comme code HTML ceci : ghuwydsa safmd ! Cela semble ne pas vouloir dire grand chose. Mais en réalité, s'il configure son navigateur pour ISO-2022-JP, il verra ses caractères japonais classiques, bien que ce soit "ghuwydsa safmd" qui est transporté sur le réseau. En revanche, toute entité dans son code comme ó correspondra au jeu ISO-10646, ce qui est ici, vu le numéro (inférieur à 256) ISO-8859-1, c'est-à-dire ó.
Si vous trouvez cela très compliqué, prenez le temps de bien lire l'article d'André et Goossens.
continued from RFC 1866...
1.2.2. Feature Test Entities
The HTML DTD defines a standard HTML document type and several
variations, by way of feature test entities. Feature test entities
are declarations in the HTML DTD that control the inclusion or
exclusion of portions of the DTD.
HTML.Recommended
Certain features of the language are necessary for
compatibility with widespread usage, but they may
compromise the structural integrity of a document. This
feature test entity selects a more prescriptive document
type definition that eliminates those features. It is
set to `IGNORE' by default.
For example, in order to preserve the structure of a
document, an editing user agent may translate HTML
documents to the recommended subset, or it may require
that the documents be in the recommended subset for
import.
HTML.Deprecated
Certain features of the language are necessary for
compatibility with earlier versions of the
specification, but they tend to be used and implemented
inconsistently, and their use is deprecated. This
feature test entity enables a document type definition
that allows these features. It is set to `INCLUDE' by
default.
Berners-Lee & Connolly Standards Track [Page 4]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Documents generated by translation software or editing
software should not contain deprecated idioms.
Il s'agit là probablement d'une partie qui aura échappé à beaucoup de
gens. La DTD exposée est souple. Elle présente des éléments qui
proviennent d'implémentations antérieures d'HTML. C'est ce qu'on
appelle les sections deprecated. C'est ici une des possibilités de
SGML lui-même (c'est l'histoire de "INCLUDE", en particulier).
Et c'est principalement prévu pour tous les outils automatiques (filtres,
parsers, convertisseurs en tout genre) pour qu'ils ne perdent pas leurs
petits en route. Pour les êtres humains, cela signifie : Cessez dès
maintenant d'utiliser les éléments HTML ainsi étiquettés, merci. Il va
de soi que cette recommendation est valable également pour les outils
automatiques qui fabriqueraient de nouveaux documents, selon cette RFC.
continued from RFC 1866...
1.2.3. User Agents
An HTML user agent conforms to this specification if:
* It parses the characters of an HTML document into data
characters and markup according to [SGML].
NOTE - In the interest of robustness and
extensibility, there are a number of widely deployed
conventions for handling non-conforming documents.
See 4.2.1, "Undeclared Markup Error Handling" for
details.
* It supports the `ISO-8859-1' character encoding scheme and
processes each character in the ISO Latin Alphabet No. 1 as
specified in 6.1, "The HTML Document Character Set".
NOTE - To support non-western writing systems, HTML
user agents are encouraged to support
`ISO-10646-UCS-2' or similar character encoding
schemes and as much of the character repertoire of
[ISO-10646] as is practical.
* It behaves identically for documents whose parsed token
sequences are identical.
parsed token sequence : ???
BLA BLA BLA (analyse lexicale plus bas)continued from RFC 1866...
For example, comments and the whitespace in tags disappear
during tokenization, and hence they do not influence the
behavior of conforming user agents.
* It allows the user to traverse (or at least attempt to
traverse, resources permitting) all hyperlinks from <A>
elements in an HTML document.
Nous avons vu plus haut quelles étaient les conditions pour qu'un document
puisse s'affirmer conforme à la DTD, et nous avons vu également que
cette RFC désire aussi donner un avis sur le comportement d'un UA.
C'est donc au tour de ces derniers de passer chez le tailleur.
Un UA, ce peut être un navigateur (le logiciel de navigation sur le web que vous utilisez quotidiennement), mais ce peut être également n'importe quel outil qui prend en entrée du HTML et produit quelque chose en sortie, comme par exemple, un filtre HTML vers Word (pourquoi pas ?), vers du braille (c'est déjà plus sérieux), ou un outil pour imprimer directement (et proprement, sans veuve ni orphelin) des documents hypertextes à la HTML. Il va de soi que de tels UA doivent être capables de décoder le HTML de cette RFC, et en particulier les jeux de caractères choisis.
Ensuite, et sans rentrer dans les détails de la technique d'analyse lexicale d'un programme (car c'est de cela dont il s'agit quand les auteurs parlent de tokenization), il est nécessaire que des documents équivalents quant à leur analyse lexicale -et pas nécessairement leur source originelle- subissent le même traitement. L'exemple donné est le suivant : deux versions d'un même document, différant seulement par un nombre d'espaces, ou de commentaires, doivent être équivalents, une fois analysés. Vous allez peut-être penser que cette recommendation est inutile ? Eh bien sachez que certains navigateurs ont abrité des analyseurs lexicaux bancals qui n'y obéissaient pas. Et c'est d'ailleurs encore le cas à l'heure de rédaction de ce document (été 1996), avec ces quelques navigateurs qui pour une raison ou une autre se permettent d'interpréter ce qui est en commentaire (netscape 2 pour le javascript, internet explorer 3 pour les feuilles de style).
continued from User Agents...
An HTML user agent is a level 2 user agent if, additionally:
* It allows the user to express all form field values
specified in an HTML document and to (attempt to) submit the
values as requests to information services.
Les formulaires ont une place spéciale, car tous les UA (par exemple ceux
qui traduisent en braille, ou qui impriment) ne peuvent permettre une
interactivité avec l'utilisateur final. D'où cette distinction entre UA de
niveau 1, et UA de niveau 2, ces derniers étant capables de gérer les
formulaires (affichage et renvoi des données entrées dans le formulaire
vers le serveur qui a délivré le document HTML, fonctionnalité qui,
vous en conviendrez, n'a pas de rapport direct avec la définition d'un
HTML et mérite donc cette distinction). Les formulaires sont amplement
décrits dans la RFC
1867 .
continued from RFC 1866...
Berners-Lee & Connolly Standards Track [Page 5]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
2. Terms
absolute URI
a URI in absolute form; for example, as per [URL]
absolute URI (Universal Resource Identifiers) : ???
anchor
one of two ends of a hyperlink; typically, a phrase
marked as an <A> element.
anchor : ancre, lien
Un hyperlien a deux bouts. Car trop souvent on le voit comme un lien vers quelque chose, et pas entre deux choses. Or, et nous le verrons plus loin, il est possible d'utiliser un hyperlien par les deux bouts. Patience :-)continued from Terms...
base URI
an absolute URI used in combination with a relative URI
to determine another absolute URI.
base URI (Universal Resource Identifiers) : ???
La distinction -fondamentale, et très utile- entre URI absolue et URI relative sera discutée amplement en section 5.2.2.continued from Terms...
character
An atom of information, for example a letter or a digit.
Graphic characters have associated glyphs, whereas
control characters have associated processing semantics.
character encoding
scheme
A function whose domain is the set of sequences of
octets, and whose range is the set of sequences of
characters from a character repertoire; that is, a
sequence of octets and a character encoding scheme
determines a sequence of characters.
character repertoire
A finite set of characters; e.g. the range of a coded
character set.
character encoding scheme : fonction d'encodage des
caractères
character repertoire : ensemble fini de caractères
continued from Terms...
code position
An integer. A coded character set and a code position
from its domain determine a character.
coded character set
A function whose domain is a subset of the integers and
whose range is a character repertoire. That is, for some
set of integers (usually of the form {0, 1, 2, ..., N}
), a coded character set and an integer in that set
determine a character. Conversely, a character and a
coded character set determine the character's code
position (or, in rare cases, a few code positions).
code position : ???
coded character set : ???
conforming HTML user
agent
A user agent that conforms to this specification in its
processing of the Internet Media Type `text/html'.
conforming HTML user agent : interface utilisateur traitant -correctement- HTML
Berners-Lee & Connolly Standards Track [Page 6]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
data character
Characters other than markup, which make up the content
of elements.
document character set
a coded character set whose range includes all
characters used in a document. Every SGML document has
exactly one document character set. Numeric character
references are resolved via the document character set.
data character : ???
document character set :
???
DTD
document type definition. Rules that apply SGML to the
markup of documents of a particular type, including a
set of element and entity declarations. [SGML]
element
A component of the hierarchical structure defined by a
document type definition; it is identified in a document
instance by descriptive markup, usually a start-tag and
end-tag. [SGML]
element : élément
end-tag
Descriptive markup that identifies the end of an
element. [SGML]
start-tag : balise de fin / fin de balise
Pour fixer les idées,<b> est un start-tag, et </b> un end-tag. Ces deux balises permettent d'indiquer qu'un mot est en gras. C'est le fonctionnement de base d'HTML. Par exemple, ce dernier mot a été produit ainsi :
| Code HTML | Résultat |
|---|---|
| <tt>HTML</tt> | HTML |
continued from Terms...
entity
data with an associated notation or interpretation; for
example, a sequence of octets associated with an
Internet Media Type. [SGML]
entity : entité
element, entity, tout ceci est du vocabulaire SGML. & est une entity associée au code ascii 38. Nous aurons l'occasion de revenir sur ces concepts lors de l'examen de la DTD.continued from Terms...
fragment identifier
the portion of an HREF attribute value following the `#'
character which modifies the presentation of the
destination of a hyperlink.
fragment identifier : ???
form data set
a sequence of name/value pairs; the names are given by
an HTML document and the values are given by a user.
form data set : ensemble des couples nom/valeur dans un formulaire
HTML document
An SGML document conforming to this document type
definition.
hyperlink
a relationship between two anchors, called the head and
the tail. The link goes from the tail to the head. The
head and tail are also known as destination and source,
respectively.
hyperlink : hyperlien
Berners-Lee & Connolly Standards Track [Page 7]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
markup
Syntactically delimited characters added to the data of
a document to represent its structure. There are four
different kinds of markup: descriptive markup (tags),
references, markup declarations, and processing
instructions. [SGML]
Voici des exemples de ces types de balisage :
continued from Terms...
may
A document or user interface is conforming whether this
statement applies or not.
media type
an Internet Media Type, as per [IMEDIA].
message entity
a head and body. The head is a collection of name/value
fields, and the body is a sequence of octets. The head
defines the content type and content transfer encoding
of the body. [MIME]
minimally conforming
HTML user agent
A user agent that conforms to this specification except
for form processing. It may only process level 1 HTML
documents.
must
Documents or user agents in conflict with this statement
are not conforming.
numeric character
reference
markup that refers to a character by its code position
in the document character set.
Eh oui, vous pouvez écrire ceci dans votre code HTML :
> et ce sera interprété comme un >.
continued from Terms...
SGML document
A sequence of characters organized physically as a set
of entities and logically into a hierarchy of elements.
An SGML document consists of data characters and markup;
the markup describes the structure of the information
and an instance of that structure. [SGML]
shall
If a document or user agent conflicts with this
statement, it does not conform to this specification.
Berners-Lee & Connolly Standards Track [Page 8]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
should
If a document or user agent conflicts with this
statement, undesirable results may occur in practice
even though it conforms to this specification.
start-tag
Descriptive markup that identifies the start of an
element and specifies its generic identifier and
attributes. [SGML]
syntax-reference
character set
A coded character set whose range includes all
characters used for markup; e.g. name characters and
delimiter characters.
tag
Markup that delimits an element. A tag includes a name
which refers to an element declaration in the DTD, and
may include attributes. [SGML]
text entity
A finite sequence of characters. A text entity typically
takes the form of a sequence of octets with some
associated character encoding scheme, transmitted over
the network or stored in a file. [SGML]
typical
Typical processing is described for many elements. This
is not a mandatory part of the specification but is
given as guidance for designers and to help explain the
uses for which the elements were intended.
URI
A Uniform Resource Identifier is a formatted string that
serves as an identifier for a resource, typically on the
Internet. URIs are used in HTML to identify the anchors
of hyperlinks. URIs in common practice include Uniform
Resource Locators (URLs)[URL] and Relative URLs
[RELURL].
user agent
A component of a distributed system that presents an
interface and processes requests on behalf of a user;
for example, a www browser or a mail user agent.
Berners-Lee & Connolly Standards Track [Page 9]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
WWW
The World-Wide Web is a hypertext-based, distributed
information system created by researchers at CERN in
Switzerland. <URL:http://www.w3.org/>
Et je reprends à présent les différentes subtilités de ce glossaire :
may
A document or user interface is conforming whether this
statement applies or not.
must
Documents or user agents in conflict with this statement
are not conforming.
shall
If a document or user agent conflicts with this
statement, it does not conform to this specification.
should
If a document or user agent conflicts with this
statement, undesirable results may occur in practice
even though it conforms to this specification.
typical
Typical processing is described for many elements. This
is not a mandatory part of the specification but is
given as guidance for designers and to help explain the
uses for which the elements were intended.
Section à compléter avec des exemples pris plus loin
3. HTML as an Application of SGML HTML is an application of ISO 8879:1986 -- Standard Generalized Markup Language (SGML). SGML is a system for defining structured document types and markup languages to represent instances of those document types[SGML]. The public text -- DTD and SGML declaration -- of the HTML document type definition are provided in 9, "HTML Public Text". The term "HTML" refers to both the document type defined here and the markup language for representing instances of this document type. 3.1. SGML Documents An HTML document is an SGML document; that is, a sequence of characters organized physically into a set of entities, and logically as a hierarchy of elements.Nous avons ici, à mon avis, le noeud du problème de l'apparition des dialectes HTML. Les dialectes, ce sont ces dérivés d'HTML comportant des extensions qui ne peuvent être exploitées que sous certains navigateurs (du moins à leur naissance) et qui, le plus souvent, ne font même pas partie d'une DTD. En réalité le premier dialecte est né avec la balise <img> introduite par Mosaic (disons par Marc Andreessen, qui commit Netscape par la suite), mais la non-distinction précise entre logique et physique est fortement responsable de l'éclatement d'HTML en dialectes. [Pour en savoir plus, voir HTML et ses extensions , par l'auteur (http://www-eleves.enst-bretagne.fr/~maubant/publis/jrnTech170996/articlePourHTML.html)].
Regardez le source de ce document, pour le paragraphe précédent. Vous verrez par exemple que le mot "extensions" est entouré de la balise <em>, pour emphasize. Le résultat, sur votre navigateur graphique préféré, est probablement de l'italique. J'aurai donc tout aussi bien pu mettre dans mon source <i>extensions</i> ?
Non, car pour une interface à synthèse de parole, <em> indiquera clairement qu'il faut insister sur le mot, en adoptant peut-être un ton différent. Il en est de même pour <strong>. Ce sont là des caractères logiques, alors que <b> et <i> sont des caractères physiques, que je préfère réserver à des noms de marque, de logiciel, d'entreprise (comme pour <i>Mosaic</i>) ou des lettrines (pour le gras ; voir début de ce paragraphe).
HTML est conçu pour structurer un document, donc les caractères logiques doivent être les plus importants. Très peu de caractères physiques auraient du être spécifiés, et un renvoi explicite vers des mécanismes comme les feuilles de style aurait du être placé dans la RFC 1866 pour contrer l'ajout de nouveaux caractères physiques dans les DTD HTML (comme le <font size="+1"> de Netscape).
continued from SGML Documents...
In the SGML specification, the first production of the SGML syntax grammar separates an SGML document into three parts: an SGML declaration, a prologue, and an instance. For the purposes of this specification, the prologue is a DTD. This DTD describes another grammar: the start symbol is given in the doctype declaration, the terminals are data characters and tags, and the productions are determined by the element declarations. The instance must conform to the DTD, that is, it must be in the language defined by this grammar.
start symbol : première balise rencontrée dans un document HTML
Il s'agit tout simplement de la balise <html> dont le positionnement en début du document HTML n'est pas obligatoire.continued from SGML Documents...
The SGML declaration determines the lexicon of the grammar. It specifies the document character set, which determines a character repertoire that contains all characters that occur in all text entities in the document, and the code positions associated with those characters. The SGML declaration also specifies the syntax-reference character set of the document, and a few other parameters that bind the abstract syntax of SGML to a concrete syntax. This concrete syntax determines how the sequence of characters of the document is mapped to a sequence of terminals in the grammar of the prologue.La déclaration SGML pour HTML sera vue en détails en section 9.5.
continued from SGML Documents
Berners-Lee & Connolly Standards Track [Page 10]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
For example, consider the following document:
<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>Parsing Example</title>
<p>Some text. <em>*wow*</em></p>
An HTML user agent should use the SGML declaration that is given in
9.5, "SGML Declaration for HTML". According to its document character
set, `*' refers to an asterisk character, `*'.
The instance above is regarded as the following sequence of
terminals:
1. start-tag: TITLE
2. data characters: "Parsing Example"
3. end-tag: TITLE
4. start-tag: P
5. data characters "Some text."
6. start-tag: EM
7. data characters: "*wow*"
8. end-tag: EM
9. end-tag: P
Berners-Lee & Connolly Standards Track [Page 11]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
The start symbol of the DTD grammar is HTML, and the productions are
given in the public text identified by `-//IETF//DTD HTML 2.0//EN'
(9.1, "HTML DTD"). The terminals above parse as:
HTML
|
\-HEAD
| |
| \-TITLE
| |
| \-<TITLE>
| |
| \-"Parsing Example"
| |
| \-</TITLE>
|
\-BODY
|
\-P
|
\-<P>
|
\-"Some text. "
|
\-EM
| |
| \-<EM>
| |
| \-"*wow*"
| |
| \-</EM>
|
\-</P>
Some of the elements are delimited explicitly by tags, while the
boundaries of others are inferred. The <HTML> element contains a
<HEAD> element and a <BODY> element. The <HEAD> contains <TITLE>,
which is explicitly delimited by start- and end-tags.
L'exemple qui vient d'être donné décrit le travail de base d'un UA se
conformant à HTML (2.0 en l'occurence). En fonction du document
HTML qui lui est présenté, et de la DTD associée, il
reconstruit l'arbre des éléments HTML (dans lequel on retrouve les
filliations entre éléments) et peut donc détecter au passage si le code
HTML est correct. Il n'a plus ensuite qu'à -par exemple- afficher le
document (ou l'imprimer, ou le transformer...).
Certains navigateurs-éditeurs vous présentent cet arbre HTML en même temps que le document. C'est le cas du navigateur de démonstration Amaya développé actuellement au sein du W3Consortium.
continued from RFC 1866...
3.2. HTML Lexical Syntax SGML specifies an abstract syntax and a reference concrete syntax. Aside from certain quantities and capacities (e.g. the limit on the length of a name),En effet, et nous le verrons plus loin, une limite de 72 caractères est fixée pour les NAME à la SGML (il s'agit d'une limite arbitraire, qui provient des longueurs maximum conseillées des lignes dans un article Usenet). Un NAME est un concept de SGML. Par exemple amp de l'entité & est un NAME. La déclaration SGML pour HTML décrite en section 9.5 spécifie ainsi le nombre de caractères maximum d'un NAME.
continued from HTML Lexical Syntax...
all HTML documents use the reference concrete syntax. In particular, all markup characters are in the repertoire of [ISO-646]. Data characters are drawn from the document character set (see 6, "Characters, Words, and Paragraphs"). Berners-Lee & Connolly Standards Track [Page 12] RFC 1866 Hypertext Markup Language - 2.0 November 1995 A complete discussion of SGML parsing, e.g. the mapping of a sequence of characters to a sequence of tags and data, is left to the SGML standard[SGML]. This section is only a summary.Dans cette section, les auteurs viennent de porter à l'attention du lecteur qu'SGML définit une syntaxe abstraite (abstract syntax) et une syntaxe concrète de référence (reference concrete syntax).
abstract syntax : syntaxe abstraite
reference
concrete syntax : syntaxe concrète de référence
Cela vous semble obscur ? Cela peut l'être. Les courageux iront voir de plus près SGML ; et pour tout le monde, il suffit de retenir que ces différentes notions assurent que les documents HTML profitent pleinement de tous les mécanismes permis par la machinerie SGML (en particulier la validation du code, qui peut vous intéresser...).
Voir [SGML-Handbook], 7.2, p198
À présent, les auteurs expliquent clairement les différentes classes de caractères en HTML et ce qu'on attend d'une UA conforme.continued from RFC 1866...
3.2.1. Data Characters
Any sequence of characters that do not constitute markup (see 9.6
"Delimiter Recognition" of [SGML]) are mapped directly to strings of
data characters. Some markup also maps to data character strings.
Numeric character references map to single-character strings, via the
document character set. Each reference to one of the general entities
defined in the HTML DTD maps to a single-character string.
For example,
abc<def => "abc","<","def"
abc<def => "abc","<","def"
Ce qui doit se comprendre ainsi : le code HTML
"abc<def" reçu par une UA doit être compris comme étant la chaîne "abc"
suivie du signe inférieur "<" suivi de la chaîne "def".
continued from Data Characters...
The terminating semicolon on entity or numeric character references
is only necessary when the character following the reference would
otherwise be recognized as part of the name (see 9.4.5 "Reference
End" in [SGML]).
abc < def => "abc ","<"," def"
abc < def => "abc ","<"," def"
An ampersand is only recognized as markup when it is followed by a
letter or a `#' and a digit:
abc & lt def => "abc & lt def"
abc &# 60 def => "abc &# 60 def"
C'est pourquoi, et vous pouvez le vérifier dans le source, les
& isolés dans les sections de la RFC que je cite -comme par exemple
Berners-Lee & Connolly, sont restés tels quels, tandis que j'ai
transformé tous les autres en & pour rester conforme à la
DTD.
continued from Data Characters...
A useful technique for translating plain text to HTML is to replace
each '<', '&', and '>' by an entity reference or numeric character
reference as follows:
ENTITY NUMERIC
CHARACTER REFERENCE CHAR REF CHARACTER DESCRIPTION
--------- ---------- ----------- ---------------------
& & & Ampersand
< < < Less than
> > > Greater than
NOTE - There are SGML mechanisms, CDATA and RCDATA
declared content, that allow most `<', `>', and `&'
characters to be entered without the use of entity
references. Because these mechanisms tend to be used and
implemented inconsistently, and because they conflict
CDATA, PCDATA, et RCDATA sont trois classes de
caractères rencontrées couramment dans une DTD comme vous le
constaterez plus tard. En voici à présent les déifinitions, qu'il est
important de bien comprendre :
Voir [SGML-Handbook], B.13.1.1, p58
continued from Data Characters...
Berners-Lee & Connolly Standards Track [Page 13]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
with techniques for reducing HTML to 7 bit ASCII for
transport, they are deprecated in this version of HTML.
See 5.5.2.1, "Example and Listing: XMP, LISTING".
Cela signifie que nous ne devons plus utiliser ces deux balises
<XMP> et <LISTING>.
continued from RFC 1866...
3.2.2. Tags
Tags delimit elements such as headings, paragraphs, lists, character
highlighting, and links. Most HTML elements are identified in a
document as a start-tag, which gives the element name and attributes,
followed by the content, followed by the end tag. Start-tags are
delimited by `<' and `>'; end tags are delimited by `</' and `>'. An
example is:
<H1>This is a Heading</H1>
Some elements only have a start-tag without an end-tag. For example,
to create a line break, use the `<BR>' tag. Additionally, the end
tags of some other elements, such as Paragraph (`</P>'), List Item
(`</LI>'), Definition Term (`</DT>'), and Definition Description
(`</DD>') elements, may be omitted.
The content of an element is a sequence of data character strings and
nested elements. Some elements, such as anchors, cannot be nested.
Anchors and character highlighting may be put inside other
constructs. See the HTML DTD, 9.1, "HTML DTD" for full details.
Nous aurons l'occasion de voir tous les éléments dans le détail par la
suite...
continued from Tags...
NOTE - The SGML declaration for HTML specifies SHORTTAG YES, which
means that there are other valid syntaxes for tags, such as NET
tags, `<EM/.../'; empty start tags, `<>'; and empty end-tags,
`</>'. Until support for these idioms is widely deployed, their
use is strongly discouraged.
Un petit mot sur cette note : ce que veulent dire les auteurs, c'est
que <em>emphasize</em> est équivalent à
<em/emphasize/. Le tableau suivant reprend ces exemples en
HTML pour que vous puissiez voir si le navigateur que vous utilisez est
conforme à la DTD (en réalité à la déclaration SGML de
celle-ci) :
| <em>emphasize</em> | emphasize |
| <em/emphasize/ | |
| Si vous ne voyez rien dans la cellule au-dessus de celle-ci, c'est que votre navigateur ne sait pas gérer les SHORTTAG YES |
Il est fort dommage que les auteurs n'aient pas insisté sur cet aspect des choses. Ce n'est certainement pas en décourageant fortement l'emploi de cette facilité tant que les UA ne supporteront pas cette fonctionnalité que les UA vont faire un effort. Alors autant mettre SHORTTAG NO dès le début, non ?
continued from RFC 1866...
3.2.3. Names A name consists of a letter followed by letters, digits, periods, or hyphens.C'est-à-dire l'ensemble "abcedfghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789.-".
continued from Names...
The length of a name is limited to 72 characters by the `NAMELEN' parameter in the SGML declaration for HTML, 9.5, "SGML Declaration for HTML". Element and attribute names are not case sensitive, but entity names are. For example, `<BLOCKQUOTE>', `<BlockQuote>', and `<blockquote>' are equivalent, whereas `&' is different from `&'. In a start-tag, the element name must immediately follow the tag open delimiter `<'. Berners-Lee & Connolly Standards Track [Page 14] RFC 1866 Hypertext Markup Language - 2.0 November 1995Vous voulez savoir comment se comporte votre UA vis-à-vis de ces règles ? Il n'y a qu'à demander...
| Code HTML | Résultat |
|---|---|
| <em>emphasize</em> | emphasize |
| <eM>emphasize</EM> | emphasize |
| & | & |
| < b>start-tag avec un espace en trop</b> | < b>start-tag avec un espace en trop |
continued from RFC 1866...
3.2.4. Attributes In a start-tag, white space and attributes are allowed between the element name and the closing delimiter.Par exemple :
| Code HTML | Résultat |
|---|---|
| <em >emphasize</em> | emphasize |
| <a name="foobar">foobar</a> | foobar |
continued from Attributes...
An attribute specification typically consists of an attribute name, an equal sign, and a value, though some attribute specifications may be just a name token.C'est ainsi que <DL COMPACT> est équivalent à la syntaxe plus rigoureuse <DL COMPACT="COMPACT">. Mais je ne sais pas pourquoi je vous dis ça maintenant, les auteurs vont en parler dans deux minutes...
White
space is allowed around the equal sign.
The value of the attribute may be either:
* A string literal, delimited by single quotes or double
quotes and not containing any occurrences of the delimiting
character.
NOTE - Some historical implementations consider any
occurrence of the `>' character to signal the end of
a tag. For compatibility with such implementations,
when `>' appears in an attribute value, it should be
represented with a numeric character reference. For
example, `<IMG SRC="eq1.jpg" alt="a>b">' should be
written `<IMG SRC="eq1.jpg" alt="a>b">' or `<IMG
SRC="eq1.jpg" alt="a>b">'.
Même remarque que pour une note précédente, on ne comprend pas pourquoi
les auteurs sont si bons avec des implémentations antérieures de vieilles UA qui
n'était pas conforme aux spécifs SGML (HTML n'ayant rien à
voir dans tout ça). Mais à sa décharge il faut peut-être dire que ce document a
été émis en 1995 et tenait compte d'un état général du Web en juin 1994.
Et votre UA, que dit-elle de tout cela, hmmm ? (vous allez devoir désactiver le chargement des images pour savoir ce qui se passe, si votre UA est graphique)
| Code HTML | Résultat |
|---|---|
| <img src="http://bogus/on/purpose.gif" alt="a>b"> |
continued from Attributes...
* A name token (a sequence of letters, digits, periods, or
hyphens). Name tokens are not case sensitive.
NOTE - Some historical implementations allow any
character except space or `>' in a name token.
In this example, <img> is the element name, src is the attribute
name, and `http://host/dir/file.gif' is the attribute value:
<img src='http://host/dir/file.gif'>
A useful technique for computing an attribute value literal for a
given string is to replace each quote and white space character by an
entity reference or numeric character reference as follows:
ENTITY NUMERIC
CHARACTER REFERENCE CHAR REF CHARACTER DESCRIPTION
--------- ---------- ----------- ---------------------
HT 	 Tab
LF Line Feed
CR Carriage Return
SP   Space
" " " Quotation mark
& & & Ampersand
ampersand : et commercial, esperluette
[André et Goossens] disent à ce propos :Il s'agit de la très vieille ligature "et" qui a fait l'objet d'études célèbres [...].continued from Attributes...Son nom français est "esperluette" ; mais il y a beaucoup de variantes : "perluète" pour IsoLatin, "perluette" ou "eperluette" ; il est aussi appelé et commercial [...] ce qui confirme son origine comptable. [...] Son nom anglais [...] est en fait un mélange de latin et d'anglais : and per se and (et à lui tout seul "et")
Berners-Lee & Connolly Standards Track [Page 15] RFC 1866 Hypertext Markup Language - 2.0 November 1995 For example: <IMG SRC="image.jpg" alt="First "real" example"> The `NAMELEN' parameter in the SGML declaration (9.5, "SGML Declaration for HTML") limits the length of an attribute value to 1024 characters.Ce qui semble amplement suffisant :-) Il faut noter cependant que la RFC traitant des URL (http://abcdrfc.free.fr/rfc-vo/RFC1738.TXT) ne donne aucune limite à la longueur des URL. Il y a donc là une contradiction entre les standards. On préférera suivre la recommendation la plus récente, à savoir la limite de 1024 caractères.
continued from Attributes...
Attributes such as ISMAP and COMPACT may be written using a minimized syntax (see 7.9.1.2 "Omitted Attribute Name" in [SGML]). The markup: <UL COMPACT="compact"> can be written using a minimized syntax: <UL COMPACT> NOTE - Some historical implementations only understand the minimized syntax.Il ne faut pas hésiter à utiliser la syntaxe minimum ; elle est prévue pour cela.
3.2.5. Comments
To include comments in an HTML document, use a comment declaration. A
comment declaration consists of `<!' followed by zero or more
comments followed by `>'. Each comment starts with `--' and includes
all text up to and including the next occurrence of `--'. In a
comment declaration, white space is allowed after each comment, but
not before the first comment. The entire comment declaration is
ignored.
NOTE - Some historical HTML implementations incorrectly consider
any `>' character to be the termination of a comment.
For example:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HEAD>
<TITLE>HTML Comment Example</TITLE>
<!-- Id: html-sgml.sgm,v 1.5 1995/05/26 21:29:50 connolly Exp -->
<!-- another -- -- comment -->
<!>
</HEAD>
<BODY>
<p> <!- not a comment, just regular old data characters ->
Berners-Lee & Connolly Standards Track [Page 16]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Voici ce que donne le bout de
code ci-dessus dans votre UA. J'ai ajouté un petit texte explicatif.
Petit aparté... Il y a eu une certaine agitation à propos du problème ci-dessous, en septembre 1996, sur la liste de diffusion www-html@w3.org. Voilà le problème :
En réalité un commentaire n'est pas défini "as anything but the '--' sequence, enclosed in '--'"... Galactus a fait une légère erreur.
RFC 1866 defines an HTML comment tag as "<!" followed by 0 or more comments followed by ">". A comment is defined as "anything but the '--' sequence, enclosed in '--'". Now, is the following tag a valid comment?
<!-- hello--->
Should a parser accept the first '-' of the three as part of the contents, or should it barf on the "->" stuff outside the first comment?
Galactus
Voici la réponse :
The parser locates the start of the comment declaration (MDO), then parses pairs of comment delimiters (COM = "--") containing valid content (white space or valid SGML characters). Your example
<!-- hello--->
parses to:"<!" MDO "--" COM " hello" SGML character* | s (space) "--" COM "->" #### invalid: only s and comment allowed in comment declarationIn your example, the first instance of the second COM occurs right after "hello", leaving the "->" dangling.
The nsgmls error message means that only s (whitespace) and comments ("-- text --" is an example of a comment) are allowed in a comment declaration. You can check page 390-391 of Goldfarb's "The SGML Handbook" to confirm.
The parser is scanning forward for the next instance of COM, not for the next instance of "-->", which has no singular significance in a comment declaration; it is simply the concatenation of a COM and MDC (">"); that's why parsers that look for "-->" are making an error. It is perfectly SGML-legal to write a comment declaration such as:<!-- hello -- >Murray Altheim, Program Manager
Spyglass, Inc., Cambridge, Massachusetts
continued from RFC 1866...
3.3. HTML Public Text Identifiers
To identify information as an HTML document conforming to this
specification, each document must start with one of the following
document type declarations.
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
This document type declaration refers to the HTML DTD in 9.1, "HTML
DTD".
NOTE - If the body of a `text/html' message entity does not begin
with a document type declaration, an HTML user agent should infer
the above document type declaration.
Un petit aparté sur le dialogue entre
serveur de documents HTML et UA est nécessaire. Pour cela, vous pouvez
consulter à la suite les uns des autres les documents suivants :
continued from HTML Public Text Identifiers...
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN"> This document type declaration also refers to the HTML DTD which appears in 9.1, "HTML DTD". <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN"> This document type declaration refers to the level 1 HTML DTD in 9.3, "Level 1 HTML DTD". Form elements must not occur in level 1 documents. <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN"> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN"> These two document type declarations refer to the HTML DTD in 9.2, "Strict HTML DTD" and 9.4, "Strict Level 1 HTML DTD". They refer to the more structurally rigid definition of HTML.Il est extrêmement important qu'une ligne <!DOCTYPE... débute tous vos documents HTML. En effet, grâce à cette instruction, vous signalez à l'UA qui traite votre document quelle est la DTD associée. Une UA multi-DTD saura donc quel dialecte de HTML vous avez choisi, et pourra donc traiter au mieux votre document. Un validateur de code HTML aura besoin aussi de ce renseignement.
Plusieurs déclarations sont définies au sein de la DTD d'HTML2.0. Elles seront décrite en temps et heure. Pour l'instant ce que vous devez retenir, c'est que ces déclarations vous permettent d'indiquer que vous utilisez une version plus ou moins stricte dHTML2.0 (par exemple vous indiquez ainsi si vous utilisez ou non les formulaires).
continued from HTML Public Text Identifiers...
HTML user agents may support other document types. In particular, they may support other formal public identifiers, or other document types altogether. They may support an internal declaration subset with supplemental entity, element, and other markup declarations.Extrêmement rares sont les formations sur HTML qui soulignent ce point. Et pourtant il est vital. En effet, rien ne vous empêche d'utiliser une DTD différente de celle décrite dans cette RFC, à partir du moment où vous l'indiquez en haut de votre document. En effet, une UA un peu générique saura peut-être s'adapter à plusieurs DTD, dont la vôtre, alors facilitez-lui le travail.
Pour vous convaincre de l'importance de cet aspect, je vous invite à soumettre à la validation un de vos documents HTML qui ne comporte pas de telle ligne en début de document. Ne vous cachez pas, je sais que vous en avez au moins un ! Quand vous reviendrez ici dans 5 minutes, vous serez convaincu de l'importance de cette ligne. (pour les lecteurs papier, l'URL indiquée est http://ugweb.cs.ualberta.ca/~gerald/validate/)
Notez que dans le dernier paragraphe cité de la RFC, les auteurs ont l'esprit large sur ce qu'une UA peut faire en plus d'être conforme à la DTD décrite ici. Mais cette internal declaration devrait normalement faire l'objet d'une DTD publiée, histoire que les autres UA ne soient pas en reste pendant des années. Au lieu de ça, nous avons du inventer le mot netscaperie, si vous voyez ce que je veux dire...
Pendant que j'y suis, si vous avez eu le malin plaisir de faire valider le document que vous lisez , vous vous serez aperçu que les seules erreurs présentes sont celles introduites exprès pour vous montrer comment votre UA les traitait.
continued from HTML RFC 1866...
3.4. Example HTML Document
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HTML>
<!-- Here's a good place to put a comment. -->
<HEAD>
<TITLE>Structural Example</TITLE>
</HEAD><BODY>
<H1>First Header</H1>
<P>This is a paragraph in the example HTML file. Keep in mind
Berners-Lee & Connolly Standards Track [Page 17]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
that the title does not appear in the document text, but that
the header (defined by H1) does.</P>
<OL>
<LI>First item in an ordered list.
<LI>Second item in an ordered list.
<UL COMPACT>
<LI> Note that lists can be nested;
<LI> Whitespace may be used to assist in reading the
HTML source.
</UL>
<LI>Third item in an ordered list.
</OL>
<P>This is an additional paragraph. Technically, end tags are
not required for paragraphs, although they are allowed. You can
include character highlighting in a paragraph. <EM>This sentence
of the paragraph is emphasized.</EM> Note that the </P>
end tag has been omitted.
<P>
<IMG SRC ="triangle.xbm" alt="Warning: ">
Be sure to read these <b>bold instructions</b>.
</BODY></HTML>
Les auteurs ne viendraient-ils pas de nous faire un petit cours sur
HTML, mine de rien ? Voici le résultat,
et voici un
moyen de le valider,
si vous lisez ce document en ligne.
4. HTML as an Internet Media Type An HTML user agent allows users to interact with resources which have HTML representations. At a minimum, it must allow users to examine and navigate the content of HTML level 1 documents. HTML user agents should be able to preserve all formatting distinctions represented in an HTML document, and be able to simultaneously present resources referred to by IMG elements (they may ignore some formatting distinctions or IMG resources at the request of the user). Level 2 HTML user agents should support form entry and submission.Autrement dit, une UA de niveau 1 doit comprendre le HTML 2.0 et afficher quelque chose d'intelligent quand on lui soumet un document écrit selon cette DTD, et également afficher si besoin est des images (selon que l'UA est orientée texte ou non, par essence, ou par choix de l'utilisateur). Noter que les auteurs sont obligés à ce niveau d'expliciter ce qu'est exactement <IMG> pour une UA, car cet élément, au delà de sa -normalement- stricte pureté structurelle SGML, doit revêtir une réalité différente de tout le reste de la DTD. Vous me suivez ?
continued from HTML RFC 1866...
4.1. text/html media type
This specification defines the Internet Media Type [IMEDIA] (formerly
referred to as the Content Type [MIME]) called `text/html'. The
following is to be registered with [IANA].
Media Type name
text
Media subtype name
html
Ce qui donne le fameux text/html.
Required parameters
none
Berners-Lee & Connolly Standards Track [Page 18]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Optional parameters
level, charset
Encoding considerations
any encoding is allowed
Security considerations
see 10, "Security Considerations"
The optional parameters are defined as follows:
Level
The level parameter specifies the feature set used in
the document. The level is an integer number, implying
that any features of same or lower level may be present
in the document. Level 1 is all features defined in this
specification except those that require the <FORM>
element. Level 2 includes form processing. Level 2 is
the default.
Charset
The charset parameter (as defined in section 7.1.1 of
RFC 1521[MIME]) may be given to specify the character
encoding scheme used to represent the HTML document as a
sequence of octets. The default value is outside the
scope of this specification; but for example, the
default is `US-ASCII' in the context of MIME mail, and
`ISO-8859-1' in the context of HTTP [HTTP].
Nous avons déjà fourni des pointeurs plus
tôt pour comprendre les interactions entre MIME et HTML, qui
nécessitent de saisir l'aspect client-serveur du Web. Voici à présent les deux
références qui n'ont pas encore été signalées : [HTTP]
Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen,
"Hypertext Transfer Protocol - HTTP/1.0", Work in
Progress, MIT, UC Irvine, CERN, March 1995.
[IANA]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciecnes Institute, October
1994. <URL:ftp://ds.internic.net/rfc/rfc1700.txt>
continued from RFC 1866... 4.2. HTML Document Representation A message entity with a content type of `text/html' represents an HTML document, consisting of a single text entity. The `charset' parameter (whether implicit or explicit) identifies a character encoding scheme. The text entity consists of the characters determined by this character encoding scheme and the octets of the body of the message entity.Si vous avez accès à telnet, vérifiez par vous-même ce qui se passe quand on demande à un serveur un document HTML. Choisissez par exemple le serveur de l'ENST Bretagne (en gras, c'est ce que vous tapez ; au niveau de <CR>, vous tapez en fait un retour chariot (ce qui fera donc deux retours-chariot après HTTP/1.0)) :
telnet www.enst-bretagne.fr 80 Trying 192.108.115.36 ... Connected to melimelo.enst-bretagne.fr. Escape character is '^]'. GET /index.html HTTP/1.0 <CR> HTTP/1.0 200 OK Date: ... Server: ... Content-type: text/html Content-length: ... Last-modified: ... <HTML> ...(nous avons indiqué par "..." les informations que l'on reçoit du serveur et qui ne nous intéressent pas ici). Ce que l'on observe, c'est que toute requête de document HTML spécifie la méthode de requête (GET), l'URL et la version du protocole HTTP utilisée. En retour, un message d'erreur parvient (ici 200 car tout s'est bien passé, mais cela aurait pu être 404 : le document n'existe pas), puis la date, le type de serveur, le type de données, ici text/html, ce qui vient d'être expliqué dans la RFC (mais cela aurait pu être par exemple application/ms-word pour un document Word : essayez avec des documents dont vous avez connaissance, en indiquant dans la manip' ci-dessus leur URL directe), la longueur du document, sa date de dernière modification, puis le document lui-même, ici du code HTML.
En tant que développeur de document HTML, vous n'avez jamais à indiquer text/html dans vos documents. Le serveur qui relaye vos documents l'indique en regardant l'extension de votre fichier (.html, .htm...). Ceci est spécifié dans les fichiers de configuration du serveur. Vous pouvez le vérifier en renommant un de vos fichiers HTML avec une extension non utilisée (.hltm par exemple). Vous allez ainsi voir quel est le type par défaut que votre serveur transmet (probablement text/plain).
continued from text/html media type...
4.2.1. Undeclared Markup Error Handling To facilitate experimentation and interoperability between implementations of various versions of HTML, the installed base of HTML user agents supports a superset of the HTML 2.0 language by reducing it to HTML 2.0: markup in the form of a start-tag or end- tag, whose generic identifier is not declared is mapped to nothing during tokenization.Ce qui signifie qu'une balise HTML inconnue ne va pas engendrer d'erreurs, ce que je prouve :
| Code HTML | Résultat |
|---|---|
| <aymeric>Coucou !</aymeric> |
(ce serait bien le diable qu'une telle balise HTML existe un jour :-) )
continued from Undeclared Markup Error Handling...
Undeclared attributes are treated similarly. The
entire attribute specification of an unknown attribute (i.e., the
unknown attribute and its value, if any) should be ignored. On the
Berners-Lee & Connolly Standards Track [Page 19]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
other hand, references to undeclared entities should be treated as
data characters.
For example:
<div class=chapter><h1>foo</h1><p>...</div>
=> <H1>,"foo",</H1>,<P>,"..."
Accessoirement, <DIV> est probablement une balise
existante, à l'heure actuelle.. (voir les DTD supérieures à celle-ci,
proposées en documentation
connexe au début de ce document, et en particulier HTML3.2).
continued from Undeclared Markup Error Handling...
xxx <P ID=z23> yyy
=> "xxx ",<P>," yyy
Let α & β be finite sets.
=> "Let α & β be finite sets."
Support for notifying the user of such errors is encouraged.
Information providers are warned that this convention is not binding:
unspecified behavior may result, as such markup does not conform to
this specification.
Ce que les auteurs expriment, c'est que des personnes désireuses
d'utiliser des entités comme α (pour les maths par exemple)
le font à leur risques et périls.
Je chipote, je chipote, mais il manque un " après "yyy", vous avez remarqué ?
continued from RFC 1866...
4.2.2. Conventional Representation of Newlines SGML specifies that a text entity is a sequence of records, each beginning with a record start character and ending with a record end character (code positions 10 and 13 respectively) (section 7.6.1, "Record Boundaries" in [SGML]). [MIME] specifies that a body of type `text/*' is a sequence of lines, each terminated by CRLF, that is, octets 13, 10. In practice, HTML documents are frequently represented and transmitted using an end of line convention that depends on the conventions of the source of the document; frequently, that representation consists of CR only, LF only, or a CR LF sequence. Hence the decoding of the octets will often result in a text entity with some missing record start and record end characters. Since there is no ambiguity, HTML user agents are encouraged to infer the missing record start and end characters. An HTML user agent should treat end of line in any of its variations as a word space in all contexts except preformatted text. Within preformatted text, an HTML user agent should treat any of the three common representations of end-of-line as starting a new line.
5. Document Structure An HTML document is a tree of elements, including a head and body, headings, paragraphs, lists, etc. Form elements are discussed in 8, "Forms". Berners-Lee & Connolly Standards Track [Page 20] RFC 1866 Hypertext Markup Language - 2.0 November 1995Les formulaires, qui sont un aspect spécial d'HTML, puisqu'ils permettent une interaction entre le document lu et le lecteur, ce qui n'est pas un des buts de SGML (qui ne fait qu'expliciter la structure d'un document), seront discutés plus loin. De même pour les hyperliens, du reste.
5.1. Document Element: HTML The HTML document element consists of a head and a body, much like a memo or a mail message. The head contains the title and optional elements. The body is a text flow consisting of paragraphs, lists, and other elements.
5.2. Head: HEAD
The head of an HTML document is an unordered collection of
information about the document. For example:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<HEAD>
<TITLE>Introduction to HTML</TITLE>
</HEAD>
...
Chose importante à comprendre : <HEAD> étant une série
d'informations sur un document, il existe des logiciels (ou des fonctions de
logiciel) qui utilisent ces informations sans examiner le corps
(<BODY>) du document.
continued from RFC 1866...
5.2.1. Title: TITLE
Every HTML document must contain a <TITLE> element.
The title should identify the contents of the document in a global
context. A short title, such as "Introduction" may be meaningless out
of context. A title such as "Introduction to HTML Elements" is more
appropriate.
NOTE - The length of a title is not limited; however, long titles
may be truncated in some applications. To minimize this
possibility, titles should be fewer than 64 characters.
A user agent may display the title of a document in a history list or
as a label for the window displaying the document. This differs from
headings (5.4, "Headings: H1 ... H6"), which are typically displayed
within the body text flow.
Une grande attention doit être portée au choix du titre d'un document. Ne
pas en proposer est illégal suivant la DTD, mais la plupart des
navigateurs ne s'en formalisent pas (ils remplacent le titre manquant par le nom
du fichier, ou la mention "untitled"). Un titre bien choisi facilite la
gestion de marque-pages. Il permet aussi de se faire une idée du contenu du
document.continued from RFC 1866...
5.2.2. Base Address: BASE The optional <BASE> element provides a base address for interpreting relative URLs when the document is read out of context (see 7, "Hyperlinks"). The value of the HREF attribute must be an absolute URI.L'idée est de mettre une ligne du genre :
<BASE HREF="http://foo.bar/fu/bach/">pour permettre par la suite d'avoir des URL relatives, du type :
<IMAGE SRC="images/logo.gif">qui ne perdent pas leur signification hors contexte, comme nous l'expliquons à présent. Le choix de cet exemple (une image) n'est en effet pas innocent. Sans le <BASE HREF...>, le navigateur saura toujours interprêter l'URL de l'image, mais si vous veniez à sauvegarder le document contenant ce code, l'URL relative n'aurait plus de signification (sauf si vous avez également ramené la hiérarchie de fichiers correspondante). Avec le <BASE HREF...>, la transformation de l'URL relative en URL complète est faite correctement, et les images sont cherchées au bon endroit (le site original), ainsi que tout autre type d'URL relative, bien sûr.
continued from RFC 1866...
5.2.3. Keyword Index: ISINDEX The <ISINDEX> element indicates that the user agent should allow the user to search an index by giving keywords. See 7.5, "Queries and Indexes" for details. Berners-Lee & Connolly Standards Track [Page 21] RFC 1866 Hypertext Markup Language - 2.0 November 1995Cette balise a été présente très tôt (c'était une des spécificités d'HTML de rendre ses propres documents indexables en texte intégral). La création des formulaires a rendu cette balise de moins en moins courante.
continued from RFC 1866...
5.2.4. Link: LINK The <LINK> element represents a hyperlink (see 7, "Hyperlinks"). Any number of LINK elements may occur in the <HEAD> element of an HTML document. It has the same attributes as the <A> element (see 5.7.3, "Anchor: A"). The <LINK> element is typically used to indicate authorship, related indexes and glossaries, older or more recent versions, document hierarchy, associated resources such as style sheets, etc.Cette balise est sous-utilisée -et c'est excessivement dommage. La généralisation des feuilles de style va sans doute la rendre plus populaire, et faire en sorte que les UA majeures supportent correctement et efficacement les fonctionnalités qu'elle propose. Grâce à cette balise, en effet, chaque document peut être relié à d'autres documents, pour des raisons diverses : ce peuvent être des informations sur l'auteur du document, une ou plusieurs feuilles de style, le document précédent ou suivant (dans un manuel en ligne, par exemple), un index, un glossaire, une bibliographie, une table des matières, des versions précédentes du document... La section 9 qui décrit en détail cette balise (au sein de la DTD) déclinera toutes ses possibilités.
continued from RFC 1866...
5.2.5. Associated Meta-information: META
The <META> element is an extensible container for use in identifying
specialized document meta-information. Meta-information has two main
functions:
* to provide a means to discover that the data set exists
and how it might be obtained or accessed; and
* to document the content, quality, and features of a data
set, indicating its fitness for use.
Each <META> element specifies a name/value pair. If multiple META
elements are provided with the same name, their combined contents--
concatenated as a comma-separated list--is the value associated with
that name.
NOTE - The <META> element should not be used where a
specific element, such as <TITLE>, would be more
appropriate. Rather than a <META> element with a URI as
the value of the CONTENT attribute, use a <LINK>
element.
HTTP servers may read the content of the document <HEAD> to generate
header fields corresponding to any elements defining a value for the
attribute HTTP-EQUIV.
NOTE - The method by which the server extracts document
meta-information is unspecified and not mandatory. The
<META> element only provides an extensible mechanism for
identifying and embedding document meta-information --
how it may be used is up to the individual server
implementation and the HTML user agent.
Berners-Lee & Connolly Standards Track [Page 22]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Attributes of the META element:
HTTP-EQUIV
binds the element to an HTTP header field. An HTTP
server may use this information to process the document.
In particular, it may include a header field in the
responses to requests for this document: the header name
is taken from the HTTP-EQUIV attribute value, and the
header value is taken from the value of the CONTENT
attribute. HTTP header names are not case sensitive.
NAME
specifies the name of the name/value pair. If not
present, HTTP-EQUIV gives the name.
CONTENT
specifies the value of the name/value pair.
Examples
If the document contains:
<META HTTP-EQUIV="Expires"
CONTENT="Tue, 04 Dec 1993 21:29:02 GMT">
<meta http-equiv="Keywords" CONTENT="Fred">
<META HTTP-EQUIV="Reply-to"
content="fielding@ics.uci.edu (Roy Fielding)">
<Meta Http-equiv="Keywords" CONTENT="Barney">
then the server may include the following header fields:
Expires: Tue, 04 Dec 1993 21:29:02 GMT
Keywords: Fred, Barney
Reply-to: fielding@ics.uci.edu (Roy Fielding)
as part of the HTTP response to a `GET' or `HEAD' request for
that document.
An HTTP server must not use the <META> element to form an HTTP
response header unless the HTTP-EQUIV attribute is present.
An HTTP server may disregard any <META> elements that specify
information controlled by the HTTP server, for example `Server',
`Date', and `Last-modified'.
La balise META est également peu utilisée mais les éditeurs
HTML commencent à l'exploiter sérieusement). Elle sert principalement à
véhiculer des informations... meta sur le document en cours (complétant ainsi un
peu le rôle de LINK). Voici quelques exemples commentés pour se faire
une idée de la bestiole :
Voir http://www.htmlhelp.com/reference/wilbur/head/meta.html
pour d'autres exemples.
continued from RFC 1866...
Berners-Lee & Connolly Standards Track [Page 23] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.2.6. Next Id: NEXTID The <NEXTID> element is included for historical reasons only. HTML documents should not contain <NEXTID> elements. The <NEXTID> element gives a hint for the name to use for a new <A> element when editing an HTML document. It should be distinct from all NAME attribute values on <A> elements. For example: <NEXTID N=Z27>Les documents contenant cette balise sont très recherchés par les collectionneurs :-)
5.3. Body: BODY
The <BODY> element contains the text flow of the document, including
headings, paragraphs, lists, etc.
For example:
<BODY>
<h1>Important Stuff</h1>
<p>Explanation about important stuff...
</BODY>
Il s'agit du corps du document, de son contenu informatif. Le numérotage
des sections qui suivent est étrange, car il s'agit de la description de balises
qui ne peuvent se trouver que dans ce corps...
continued from RFC 1866...
5.4. Headings: H1 ... H6 The six heading elements, <H1> through <H6>, denote section headings. Although the order and occurrence of headings is not constrained by the HTML DTD, documents should not skip levels (for example, from H1 to H3), as converting such documents to other representations is often problematic.Noter l'emploi de should. La plupart des validateurs syntaxiques de code HTML vous avertiront si vous avez sauté un heading.
continued from RFC 1866...
Example of use:
<H1>This is a heading</H1>
Here is some text
<H2>Second level heading</H2>
Here is some more text.
Typical renderings are:
H1
Bold, very-large font, centered. One or two blank lines
above and below.
H2
Bold, large font, flush-left. One or two blank lines
above and below.
Berners-Lee & Connolly Standards Track [Page 24]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
H3
Italic, large font, slightly indented from the left
margin. One or two blank lines above and below.
H4
Bold, normal font, indented more than H3. One blank line
above and below.
H5
Italic, normal font, indented as H4. One blank line
above.
H6
Bold, indented same as normal text, more than H5. One
blank line above.
Ces rendus typiques n'ont pas été suivis par tous les développeurs de
navigateurs, ce qui est leur droit le plus strict. En revanche, il est dommage
que certains navigateurs ne fassent pas de différence entre <H1>
et <H2>, ou <H3> et <H4>, ou
<H5> et <H6>. Regardez par vous-même ce que votre
navigateur fait :
Utilisez ces en-têtes uniquement pour structurer votre document en sections, sous-sections, sous-sous-sections.
continued from RFC 1866...
5.5. Block Structuring Elements
Block structuring elements include paragraphs, lists, and block
quotes. They must not contain heading elements, but they may contain
phrase markup, and in some cases, they may be nested.
5.5.1. Paragraph: P
The <P> element indicates a paragraph. The exact indentation, leading
space, etc. of a paragraph is not specified and may be a function of
other tags, style sheets, etc.
Typically, paragraphs are surrounded by a vertical space of one line
or half a line. The first line in a paragraph is indented in some
cases.
Example of use:
<H1>This Heading Precedes the Paragraph</H1>
<P>This is the text of the first paragraph.
<P>This is the text of the second paragraph. Although you do not
need to start paragraphs on new lines, maintaining this
convention facilitates document maintenance.</P>
<P>This is the text of a third paragraph.</P>
Noter la remarque des auteurs sur le style à adopter en rédigeant un
document HTML, pour faciliter sa lecture, et donc sa maintenance
future.
continued from RFC 1866...
5.5.2. Preformatted Text: PRE
The <PRE> element represents a character cell block of text and is
suitable for text that has been formatted for a monospaced font.
The <PRE> tag may be used with the optional WIDTH attribute. The
WIDTH attribute specifies the maximum number of characters for a line
Berners-Lee & Connolly Standards Track [Page 25]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
and allows the HTML user agent to select a suitable font and
indentation.
Within preformatted text:
* Line breaks within the text are rendered as a move to the
beginning of the next line.
NOTE - References to the "beginning of a new line"
do not imply that the renderer is forbidden from
using a constant left indent for rendering
preformatted text. The left indent may be
constrained by the width required.
* Anchor elements and phrase markup may be used.
NOTE - Constraints on the processing of <PRE>
content may limit or prevent the ability of the HTML
user agent to faithfully render phrase markup.
* Elements that define paragraph formatting (headings,
address, etc.) must not be used.
NOTE - Some historical documents contain <P> tags in
<PRE> elements. User agents are encouraged to treat
this as a line break. A <P> tag followed by a
newline character should produce only one line
break, not a line break plus a blank line.
* The horizontal tab character (code position 9 in the HTML
document character set) must be interpreted as the smallest
positive nonzero number of spaces which will leave the
number of characters so far on the line as a multiple of 8.
Documents should not contain tab characters, as they are not
supported consistently.
Example of use:
<PRE>
Line 1.
Line 2 is to the right of line 1. <a href="abc">abc</a>
Line 3 aligns with line 2. <a href="def">def</a>
</PRE>
Berners-Lee & Connolly Standards Track [Page 26]
RFC 1866 Hypertext Markup Language - 2.0 November
1995
Cette balise a été fortement utilisée au début pour émuler des tableaux,
puisque le navigateur est censé utiliser des polices dites sans-sérif (tous les
caractères ont la même largeur, ce qui permet des alignements verticaux). Elle
ne devrait plus à présent être détournée ainsi. En effet la RFC 1942
décrit les tableaux en HTML. HTML3.2 intègre complètement les
tableaux dans sa DTD.
Noter que les éléments HTML que l'on peut rencontrer au sein d'une zone PRE sont réduits. Tous les éléments de bloc (qui définissent du formatage de paragraphe) ne signifient rien dans une telle zone.
continued from RFC 1866...
5.5.2.1. Example and Listing: XMP, LISTING
The <XMP> and <LISTING> elements are similar to the <PRE> element,
but they have a different syntax. Their content is declared as CDATA,
which means that no markup except the end-tag open delimiter-in-
context is recognized (see 9.6 "Delimiter Recognition" of [SGML]).
NOTE - In a previous draft of the HTML specification, the syntax
of <XMP> and <LISTING> elements allowed closing tags to be treated
as data characters, as long as the tag name was not <XMP> or
<LISTING>, respectively.
Since CDATA declared content has a number of unfortunate interactions
with processing techniques and tends to be used and implemented
inconsistently, HTML documents should not contain <XMP> nor <LISTING>
elements -- the <PRE> tag is more expressive and more consistently
supported.
The <LISTING> element should be rendered so that at least 132
characters fit on a line. The <XMP> element should be rendered so
that at least 80 characters fit on a line but is otherwise identical
to the <LISTING> element.
NOTE - In a previous draft, HTML included a <PLAINTEXT> element
that is similar to the <LISTING> element, except that there is no
closing tag: all characters after the <PLAINTEXT> start-tag are
data.
XMP et LISTING ont les mêmes buts que PRE, mais
la liste des éléments HTML que l'on peut trouver dans une telle zone
est nulle. Seuls </XMP> et </LISTING> sont
interpétés. Les auteurs signalent que ces balises ne devraient plus être
utilisés.
continued from RFC 1866...
5.5.3. Address: ADDRESS
The <ADDRESS> element contains such information as address, signature
and authorship, often at the beginning or end of the body of a
document.
Typically, the <ADDRESS> element is rendered in an italic typeface
and may be indented.
Example of use:
<ADDRESS>
Newsletter editor<BR>
J.R. Brown<BR>
JimquickPost News, Jimquick, CT 01234<BR>
Tel (123) 456 7890
</ADDRESS>
Berners-Lee & Connolly Standards Track [Page 27]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Voici comment votre UA rend l'exemple donné par Tim & Dan :
continued from RFC 1866...
5.5.4. Block Quote: BLOCKQUOTE
The <BLOCKQUOTE> element contains text quoted from another source.
A typical rendering might be a slight extra left and right indent,
and/or italic font. The <BLOCKQUOTE> typically provides space above
and below the quote.
Single-font rendition may reflect the quotation style of Internet
mail by putting a vertical line of graphic characters, such as the
greater than symbol (>), in the left margin.
Example of use:
I think the play ends
<BLOCKQUOTE>
<P>Soft you now, the fair Ophelia. Nymph, in thy orisons, be all
my sins remembered.
</BLOCKQUOTE>
but I am not sure.
Voici comment votre UA rend l'exemple donné par Tim & Dan :
but I am not sure.Soft you now, the fair Ophelia. Nymph, in thy orisons, be all my sins remembered.
continued from RFC 1866...
5.6. List Elements
HTML includes a number of list elements. They may be used in
combination; for example, a <OL> may be nested in an <LI> element of
a <UL>.
The COMPACT attribute suggests that a compact rendering be used.
5.6.1. Unordered List: UL, LI
The <UL> represents a list of items -- typically rendered as a
bulleted list.
The content of a <UL> element is a sequence of <LI> elements. For
example:
<UL>
<LI>First list item
<LI>Second list item
<p>second paragraph of second item
<LI>Third list item
</UL>
Voici comment votre UA rend l'exemple donné par Tim & Dan :
second paragraph of second item
continued from RFC 1866...
5.6.2. Ordered List: OL
The <OL> element represents an ordered list of items, sorted by
sequence or order of importance. It is typically rendered as a
Berners-Lee & Connolly Standards Track [Page 28]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
numbered list.
The content of a <OL> element is a sequence of <LI> elements. For
example:
<OL>
<LI>Click the Web button to open URI window.
<LI>Enter the URI number in the text field of the Open URI
window. The Web document you specified is displayed.
<ol>
<li>substep 1
<li>substep 2
</ol>
<LI>Click highlighted text to move from one link to another.
</OL>
Voici comment votre UA rend l'exemple donné par Tim & Dan :
continued from RFC 1866...
5.6.3. Directory List: DIR
The <DIR> element is similar to the <UL> element. It represents a
list of short items, typically up to 20 characters each. Items in a
directory list may be arranged in columns, typically 24 characters
wide.
The content of a <DIR> element is a sequence of <LI> elements.
Nested block elements are not allowed in the content of <DIR>
elements. For example:
<DIR>
<LI>A-H<LI>I-M
<LI>M-R<LI>S-Z
</DIR>
Voici comment votre UA rend l'exemple donné par Tim & Dan :
continued from RFC 1866...
5.6.4. Menu List: MENU
The <MENU> element is a list of items with typically one line per
item. The menu list style is typically more compact than the style of
an unordered list.
The content of a <MENU> element is a sequence of <LI> elements.
Nested block elements are not allowed in the content of <MENU>
elements. For example:
<MENU>
<LI>First item in the list.
<LI>Second item in the list.
<LI>Third item in the list.
</MENU>
Voici comment votre UA rend l'exemple donné par Tim & Dan :
continued from RFC 1866...
Berners-Lee & Connolly Standards Track [Page 29]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
5.6.5. Definition List: DL, DT, DD
A definition list is a list of terms and corresponding definitions.
Definition lists are typically formatted with the term flush-left and
the definition, formatted paragraph style, indented after the term.
The content of a <DL> element is a sequence of <DT> elements and/or
<DD> elements, usually in pairs. Multiple <DT> may be paired with a
single <DD> element. Documents should not contain multiple
consecutive <DD> elements.
Example of use:
<DL>
<DT>Term<DD>This is the definition of the first term.
<DT>Term<DD>This is the definition of the second term.
</DL>
Voici comment votre UA rend l'exemple donné par Tim & Dan :
continued from RFC 1866...
If the DT term does not fit in the DT column (typically one third of
the display area), it may be extended across the page with the DD
section moved to the next line, or it may be wrapped onto successive
lines of the left hand column.
The optional COMPACT attribute suggests that a compact rendering be
used, because the list items are small and/or the entire list is
large.
Unless the COMPACT attribute is present, an HTML user agent may leave
white space between successive DT, DD pairs. The COMPACT attribute
may also reduce the width of the left-hand (DT) column.
<DL COMPACT>
<DT>Term<DD>This is the first definition in compact format.
<DT>Term<DD>This is the second definition in compact format.
</DL>
Voici comment votre UA rend l'exemple donné par Tim & Dan :
continued from RFC 1866...
5.7. Phrase Markup Phrases may be marked up according to idiomatic usage, typographic appearance, or for use as hyperlink anchors. User agents must render highlighted phrases distinctly from plain text. Additionally, <EM> content must be rendered as distinct from <STRONG> content, and <B> content must rendered as distinct from <I> content. Phrase elements may be nested within the content of other phrase elements; however, HTML user agents may render nested phrase elements Berners-Lee & Connolly Standards Track [Page 30] RFC 1866 Hypertext Markup Language - 2.0 November 1995 indistinctly from non-nested elements: plain <B>bold <I>italic</I></B> may be rendered the same as plain <B>bold </B><I>italic</I>Vérifions ce dernier point sur un exemple :
continued from RFC 1866...
5.7.1. Idiomatic Elements
Phrases may be marked up to indicate certain idioms.
NOTE - User agents may support the <DFN> element, not included in
this specification, as it has been deployed to some extent. It is
used to indicate the defining instance of a term, and it is
typically rendered in italic or bold italic.
Cette balise, qui n'est pas dans HTML2.0, bien qu'assez ancienne,
est actuellement dans HTML3.2. Est-ce que votre navigateur en fait
quelque chose d'intéressant (normalement non, puisque la DTD associée à
ce document est HTML2.0) ?
continued from RFC 1866...
5.7.1.1. Citation: CITE
The <CITE> element is used to indicate the title of a book or
other citation. It is typically rendered as italics. For example:
He just couldn't get enough of <cite>The Grapes of
Wrath</cite>.
Ce qui donne :
continued from RFC 1866...
5.7.1.2. Code: CODE
The <CODE> element indicates an example of code, typically
rendered in a mono-spaced font. The <CODE> element is intended for
short words or phrases of code; the <PRE> block structuring
element (5.5.2, "Preformatted Text: PRE") is more appropriate
for multiple-line listings. For example:
The expression <code>x += 1</code>
is short for <code>x = x + 1</code>.
Ce qui donne :
x += 1 is short for x = x +
1. continued from RFC 1866...
5.7.1.3. Emphasis: EM
The <EM> element indicates an emphasized phrase, typically
rendered as italics. For example:
A singular subject <em>always</em> takes a singular verb.
Nous avons déjà vu cette balise plus haut :
continued from RFC 1866...
5.7.1.4. Keyboard: KBD
The <KBD> element indicates text typed by a user, typically
rendered in a mono-spaced font. This is commonly used in
instruction manuals. For example:
Enter <kbd>FIND IT</kbd> to search the database.
Ce qui donne :
continued from RFC 1866...
Berners-Lee & Connolly Standards Track [Page 31]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
5.7.1.5. Sample: SAMP
The <SAMP> element indicates a sequence of literal characters,
typically rendered in a mono-spaced font. For example:
The only word containing the letters <samp>mt</samp> is dreamt.
Ce qui donne :
continued from RFC 1866...
5.7.1.6. Strong Emphasis: STRONG
The <STRONG> element indicates strong emphasis, typically rendered
in bold. For example:
<strong>STOP</strong>, or I'll say "<strong>STOP</strong>" again!
Nous avons déjà vu cette balise plus haut :
continued from RFC 1866...
5.7.1.7. Variable: VAR
The <VAR> element indicates a placeholder variable, typically
rendered as italic. For example:
Type <SAMP>html-check <VAR>file</VAR> | more</SAMP>
to check <VAR>file</VAR> for markup errors.
Ce qui donne :
continued from RFC 1866...
5.7.2. Typographic Elements
Typographic elements are used to specify the format of marked
text.
Typical renderings for idiomatic elements may vary between user
agents. If a specific rendering is necessary -- for example, when
referring to a specific text attribute as in "The italic parts are
mandatory" -- a typographic element can be used to ensure that the
intended typography is used where possible.
NOTE - User agents may support some typographic elements not
included in this specification, as they have been deployed to some
extent. The <STRIKE> element indicates horizontal line through the
characters, and the <U> element indicates an underline.
5.7.2.1. Bold: B
The <B> element indicates bold text. Where bold typography is
unavailable, an alternative representation may be used.
Nous avons déjà rencontré cette balise plus haut :
continued from RFC 1866...
5.7.2.2. Italic: I The <I> element indicates italic text. Where italic typography is unavailable, an alternative representation may be used.Nous avons déjà rencontré cette balise plus haut :
continued from RFC 1866...
Berners-Lee & Connolly Standards Track [Page 32] RFC 1866 Hypertext Markup Language - 2.0 November 1995 5.7.2.3. Teletype: TT The <TT> element indicates teletype (monospaced )text. Where a teletype font is unavailable, an alternative representation may be used.
continued from RFC 1866...
5.7.3. Anchor: A
The <A> element indicates a hyperlink anchor (see 7, "Hyperlinks").
At least one of the NAME and HREF attributes should be present.
Attributes of the <A> element:
HREF
gives the URI of the head anchor of a hyperlink.
NAME
gives the name of the anchor, and makes it available as
a head of a hyperlink.
TITLE
suggests a title for the destination resource --
advisory only. The TITLE attribute may be used:
* for display prior to accessing the destination
resource, for example, as a margin note or on a
small box while the mouse is over the anchor, or
while the document is being loaded;
* for resources that do not include a title, such as
graphics, plain text and Gopher menus, for use as a
window title.
REL
The REL attribute gives the relationship(s) described by
the hyperlink. The value is a whitespace separated list
of relationship names. The semantics of link
relationships are not specified in this document.
REV
same as the REL attribute, but the semantics of the
relationship are in the reverse direction. A link from A
to B with REL="X" expresses the same relationship as a
link from B to A with REV="X". An anchor may have both
REL and REV attributes.
URN
specifies a preferred, more persistent identifier for
the head anchor of the hyperlink. The syntax and
Berners-Lee & Connolly Standards Track [Page 33]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
semantics of the URN attribute are not yet specified.
METHODS
specifies methods to be used in accessing the
destination, as a whitespace-separated list of names.
The set of applicable names is a function of the scheme
of the URI in the HREF attribute. For similar reasons as
for the TITLE attribute, it may be useful to include the
information in advance in the link. For example, the
HTML user agent may chose a different rendering as a
function of the methods allowed; for example, something
that is searchable may get a different icon.
Tout ça pour ça, serait-on tenté de dire. C'est en effet
cette balise, A, qui donne toute sa puissance au Web.
Pour commencer, les deux attributs principaux sont HREF et NAME. Le premier indique l'URL de ce qui est à l'autre bout de l'ancre. Le deuxième indique le nom de l'ancre, rendant ainsi possible de se reférer à cette ancre directement (et pas seulement au début du document lui-même). Par exemple, voici une ancre très peu utile. Elle a été définie ainsi : <a href="#ancre" name="ancre">une ancre</a>. Dans votre navigateur, si vous actionnez ce lien, vous ne devez pas bouger, puisque ce lien se réfère à lui-même. En revanche, ce bout de texte est accessible à présent de l'extérieur de ce document, avec l'URL : <rfc1866.html> (passionnant, n'est-ce pas ?).
Les autres attributs ne sont quasiment jamais utilisés, car presque tous les navigateurs Web n'en font rien (donc aucun n'est un navigateur conforme à HTML, finalement). TITLE permettrait de suggérer un titre pour le document à l'autre bout, plus pertinent que celui choisi par l'auteur, quand il s'agit d'un document HTML, ou tout simplement un titre pour un document qui n'en a pas (image, texte basique etc...).
Avec REL (et REV, mais de manière inverse), vous puvez spécifier la relation qui existe entre le document courant et le document à l'autre bout. Par exemple, vous pouvez indiquer que le document à l'autre bout est un section du chapitre que le document courant représente. Malheureusement la sémantique associée n'était pas spécifiée à l'époque de la RFC 1866. Elle devrait l'être actuellement de manière officielle avec notamment les choix possibles suivants : Contents, Index, Glosaary, Copyright, Next, Previous, Help, Bookmark...
Les mêmes remarques à propos d'URN sont de mise.
Enfin, en ce qui concerne METHODS, comme aucun UA ne semble s'en servir, il n'existe même plus dans HTML3.2 (URN non plus, du reste).
continued from RFC 1866...
5.8. Line Break: BR
The <BR> element specifies a line break between words (see 6,
"Characters, Words, and Paragraphs"). For example:
<P> Pease porridge hot<BR>
Pease porridge cold<BR>
Pease porridge in the pot<BR>
Nine days old.
Voici ce que donne l'exemple :
Pease porridge hot
Pease porridge cold
Pease porridge in the
pot
Nine days old.
continued from RFC 1866...
5.9. Horizontal Rule: HR
The <HR> element is a divider between sections of text; typically a
full width horizontal rule or equivalent graphic. For example:
<HR>
<ADDRESS>February 8, 1995, CERN</ADDRESS>
</BODY>
Voici ce que donne l'exemple (execpté le </BODY>) :
continued from RFC 1866...
5.10. Image: IMG
The <IMG> element refers to an image or icon via a hyperlink (see
7.3, "Simultaneous Presentation of Image Resources").
HTML user agents may process the value of the ALT attribute as an
alternative to processing the image resource indicated by the SRC
attribute.
NOTE - Some HTML user agents can process graphics linked via
anchors, but not <IMG> graphics. If a graphic is essential, it
should be referenced from an <A> element rather than an <IMG>
element. If the graphic is not essential, then the <IMG> element
is appropriate.
Attributes of the <IMG> element:
Berners-Lee & Connolly Standards Track [Page 34]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
ALIGN
alignment of the image with respect to the text
baseline.
* `TOP' specifies that the top of the image aligns
with the tallest item on the line containing the
image.
* `MIDDLE' specifies that the center of the image
aligns with the baseline of the line containing the
image.
* `BOTTOM' specifies that the bottom of the image
aligns with the baseline of the line containing the
image.
ALT
text to use in place of the referenced image resource,
for example due to processing constraints or user
preference.
ISMAP
indicates an image map (see 7.6, "Image Maps").
SRC
specifies the URI of the image resource.
NOTE - In practice, the media types of image
resources are limited to a few raster graphic
formats: typically `image/gif', `image/jpeg'. In
particular, `text/html' resources are not
intended to be used as image resources.
Examples of use:
<IMG SRC="triangle.xbm" ALT="Warning:"> Be sure
to read these instructions.
<a href="http://machine/htbin/imagemap/sample">
<IMG SRC="sample.xbm" ISMAP>
</a>
Que dire de IMG ? C'est sans doute la balise la plus célèbre
(après A :-) ). Ne jamais oublier de renseigner l'attribut
ALT, qui permet de donner un minimum d'informations pour les UA
orientées texte.
6. Characters, Words, and Paragraphs An HTML user agent should present the body of an HTML document as a collection of typeset paragraphs and preformatted text. Except for preformatted elements (<PRE>, <XMP>, <LISTING>, <TEXTAREA>), each block structuring element is regarded as a paragraph by taking the Berners-Lee & Connolly Standards Track [Page 35] RFC 1866 Hypertext Markup Language - 2.0 November 1995 data characters in its content and the content of its descendant elements, concatenating them, and splitting the result into words, separated by space, tab, or record end characters (and perhaps hyphen characters). The sequence of words is typeset as a paragraph by breaking it into lines.Noter que les auteurs imaginent très bien que les navigateurs puissent couper les mots en bout de ligne, ce qui permettrait de faire de la justification complète. Malheureusement, il faudrait pour cela connaître les règles de coupure des mots, et en particulier la langue utilisée. Le sens de direction du texte intervient également. Ces problèmes -intéressants- sont encore à l'ordre du jour de certains groupes de travail à l'heure actuelle.
À présent, les auteurs indiquent quel est l'ensemble de caractères légal en HTML2.0. Il s'agit d'isolatin1 (ISO 8859-1) et nous en avons parlé plus haut en section 1.2.1.
continued from RFC 1866...
6.1. The HTML Document Character Set
The document character set specified in 9.5, "SGML Declaration for
HTML" must be supported by HTML user agents. It includes the graphic
characters of Latin Alphabet No. 1, or simply Latin-1. Latin-1
comprises 191 graphic characters, including the alphabets of most
Western European languages.
NOTE - Use of the non-breaking space and soft hyphen indicator
characters is discouraged because support for them is not widely
deployed.
NOTE - To support non-western writing systems, a larger character
repertoire will be specified in a future version of HTML. The
document character set will be [ISO-10646], or some subset that
agrees with [ISO-10646]; in particular, all numeric character
references must use code positions assigned by [ISO-10646].
In SGML applications, the use of control characters is limited in
order to maximize the chance of successful interchange over
heterogeneous networks and operating systems. In the HTML document
character set only three control characters are allowed: Horizontal
Tab, Carriage Return, and Line Feed (code positions 9, 13, and 10).
The HTML DTD references the Added Latin 1 entity set, to allow
mnemonic representation of selected Latin 1 characters using only the
widely supported ASCII character repertoire. For example:
Kurt Gödel was a famous logician and mathematician.
See 9.7.2, "ISO Latin 1 Character Entity Set" for a table of the
"Added Latin 1" entities, and 13, "The HTML Coded Character Set" for
a table of the code positions of [ISO 8859-1] and the control
characters in the HTML document character set.
continued from RFC 1866...
7. Hyperlinks
In addition to general purpose elements such as paragraphs and lists,
HTML documents can express hyperlinks. An HTML user agent allows the
user to navigate these hyperlinks.
Berners-Lee & Connolly Standards Track [Page 36]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
A hyperlink is a relationship between two anchors, called the head
and the tail of the hyperlink[DEXTER]. Anchors are identified by an
anchor address: an absolute Uniform Resource Identifier (URI),
optionally followed by a '#' and a sequence of characters called a
fragment identifier. For example:
http://www.w3.org/hypertext/WWW/TheProject.html
http://www.w3.org/hypertext/WWW/TheProject.html#z31
In an anchor address, the URI refers to a resource; it may be used in
a variety of information retrieval protocols to obtain an entity that
represents the resource, such as an HTML document. The fragment
identifier, if present, refers to some view on, or portion of the
resource.
Each of the following markup constructs indicates the tail anchor of
a hyperlink or set of hyperlinks:
* <A> elements with HREF present.
* <LINK> elements.
* <IMG> elements.
* <INPUT> elements with the SRC attribute present.
* <ISINDEX> elements.
* <FORM> elements with `METHOD=GET'.
These markup constructs refer to head anchors by a URI, either
absolute or relative, or a fragment identifier, or both.
In the case of a relative URI, the absolute URI in the address of the
head anchor is the result of combining the relative URI with a base
absolute URI as in [RELURL]. The base document is taken from the
document's <BASE> element, if present; else, it is determined as in
[RELURL].
7.1. Accessing Resources
Once the address of the head anchor is determined, the user agent may
obtain a representation of the resource.
For example, if the base URI is `http://host/x/y.html' and the
document contains:
<img src="../icons/abc.gif">
Berners-Lee & Connolly Standards Track [Page 37]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
then the user agent uses the URI `http://host/icons/abc.gif' to
access the resource, as in [URL]..
7.2. Activation of Hyperlinks
An HTML user agent allows the user to navigate the content of the
document and request activation of hyperlinks denoted by <A>
elements. HTML user agents should also allow activation of <LINK>
element hyperlinks.
To activate a link, the user agent obtains a representation of the
resource identified in the address of the head anchor. If the
representation is another HTML document, navigation may begin again
with this new document.
7.3. Simultaneous Presentation of Image Resources
An HTML user agent may activate hyperlinks indicated by <IMG> and
<INPUT> elements concurrently with processing the document; that is,
image hyperlinks may be processed without explicit request by the
user. Image resources should be embedded in the presentation at the
point of the tail anchor, that is the <IMG> or <INPUT> element.
<LINK> hyperlinks may also be processed without explicit user
request; for example, style sheet resources may be processed before
or during the processing of the document.
7.4. Fragment Identifiers
Any characters following a `#' character in a hypertext address
constitute a fragment identifier. In particular, an address of the
form `#fragment' refers to an anchor in the same document.
The meaning of fragment identifiers depends on the media type of the
representation of the anchor's resource. For `text/html'
representations, it refers to the <A> element with a NAME attribute
whose value is the same as the fragment identifier. The matching is
case sensitive. The document should have exactly one such element.
The user agent should indicate the anchor element, for example by
scrolling to and/or highlighting the phrase.
For example, if the base URI is `http://host/x/y.html' and the user
activated the link denoted by the following markup:
<p> See: <a href="app1.html#bananas">appendix 1</a>
for more detail on bananas.
Berners-Lee & Connolly Standards Track [Page 38]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Then the user agent accesses the resource identified by
`http://host/x/app1.html'. Assuming the resource is represented using
the `text/html' media type, the user agent must locate the <A>
element whose NAME attribute is `bananas' and begin navigation there.
7.5. Queries and Indexes
The <ISINDEX> element represents a set of hyperlinks. The user can
choose from the set by providing keywords to the user agent. The
user agent computes the head URI by appending `?' and the keywords to
the base URI. The keywords are escaped according to [URL] and joined
by `+'. For example, if a document contains:
<BASE HREF="http://host/index">
<ISINDEX>
and the user provides the keywords `apple' and `berry', then the
user agent must access the resource
`http://host/index?apple+berry'.
<FORM> elements with `METHOD=GET' also represent sets of
hyperlinks. See 8.2.2, "Query Forms: METHOD=GET" for details.
7.6. Image Maps
If the ISMAP attribute is present on an <IMG> element, the <IMG>
element must be contained in an <A> element with an HREF present.
This construct represents a set of hyperlinks. The user can choose
from the set by choosing a pixel of the image. The user agent
computes the head URI by appending `?' and the x and y coordinates of
the pixel to the URI given in the <A> element. For example, if a
document contains:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<head><title>ImageMap Example</title>
<BASE HREF="http://host/index"></head>
<body>
<p> Choose any of these icons:<br>
<a href="/cgi-bin/imagemap"><img ismap src="icons.gif"></a>
and the user chooses the upper-leftmost pixel, the chosen
hyperlink is the one with the URI
`http://host/cgi-bin/imagemap?0,0'.
Le lecteur désireux de maîtriser ISMAP (cartes réactives) est
invité à se reporter à http://webbo.enst-bretagne.fr/ActiveWebFr2/eg-uk-tut.book_17.fr.html#HEADING40
(noter qu'un mécanisme s'effectuant côté client, et non pas serveur comme ici,
appelé USEMAP est actuellement standardisé).
La version courante du guide de lecture de la RFC 1866 n'entre pas dans les détails des formulaires. Les explications données par les auteurs sont suffisament claires. Pour un atelier sur les formulaires, vous pouvez consulter le document http://webbo.enst-bretagne.fr/ActiveWebFr/eg-uk-tut.book_18.fr.html#HEADING46. Vous pouvez également sauter directement à la section 9, qui présente la DTD de HTML2.0.
continued from RFC 1866...
Berners-Lee & Connolly Standards Track [Page 39]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
8. Forms
A form is a template for a form data set and an associated
method and action URI. A form data set is a sequence of
name/value pair fields. The names are specified on the NAME
attributes of form input elements, and the values are given
initial values by various forms of markup and edited by the
user. The resulting form data set is used to access an
information service as a function of the action and method.
Forms elements can be mixed in with document structuring
elements. For example, a <PRE> element may contain a <FORM>
element, or a <FORM> element may contain lists which contain
<INPUT> elements. This gives considerable flexibility in
designing the layout of forms.
Form processing is a level 2 feature.
8.1. Form Elements
8.1.1. Form: FORM
The <FORM> element contains a sequence of input elements, along
with document structuring elements. The attributes are:
ACTION
specifies the action URI for the form. The action URI of
a form defaults to the base URI of the document (see 7,
"Hyperlinks").
METHOD
selects a method of accessing the action URI. The set of
applicable methods is a function of the scheme of the
action URI of the form. See 8.2.2, "Query Forms:
METHOD=GET" and 8.2.3, "Forms with Side-Effects:
METHOD=POST".
ENCTYPE
specifies the media type used to encode the name/value
pairs for transport, in case the protocol does not
itself impose a format. See 8.2.1, "The form-urlencoded
Media Type".
8.1.2. Input Field: INPUT
The <INPUT> element represents a field for user input. The TYPE
attribute discriminates between several variations of fields.
Berners-Lee & Connolly Standards Track [Page 40]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
The <INPUT> element has a number of attributes. The set of applicable
attributes depends on the value of the TYPE attribute.
8.1.2.1. Text Field: INPUT TYPE=TEXT
The default value of the TYPE attribute is `TEXT', indicating a
single line text entry field. (Use the <TEXTAREA> element for multi-
line text fields.)
Required attributes are:
NAME
name for the form field corresponding to this element.
The optional attributes are:
MAXLENGTH
constrains the number of characters that can be entered
into a text input field. If the value of MAXLENGTH is
greater the the value of the SIZE attribute, the field
should scroll appropriately. The default number of
characters is unlimited.
SIZE
specifies the amount of display space allocated to this
input field according to its type. The default depends
on the user agent.
VALUE
The initial value of the field.
For example:
<p>Street Address: <input name=street><br>
Postal City code: <input name=city size=16 maxlength=16><br>
Zip Code: <input name=zip size=10 maxlength=10 value="99999-9999"><br>
8.1.2.2. Password Field: INPUT TYPE=PASSWORD
An <INPUT> element with `TYPE=PASSWORD' is a text field as above,
except that the value is obscured as it is entered. (see also: 10,
"Security Considerations").
For example:
<p>Name: <input name=login> Password: <input type=password name=passwd>
Berners-Lee & Connolly Standards Track [Page 41]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
8.1.2.3. Check Box: INPUT TYPE=CHECKBOX
An <INPUT> element with `TYPE=CHECKBOX' represents a boolean choice.
A set of such elements with the same name represents an n-of-many
choice field. Required attributes are:
NAME
symbolic name for the form field corresponding to this
element or group of elements.
VALUE
The portion of the value of the field contributed by
this element.
Optional attributes are:
CHECKED
indicates that the initial state is on.
For example:
<p>What flavors do you like?
<input type=checkbox name=flavor value=vanilla>Vanilla<br>
<input type=checkbox name=flavor value=strawberry>Strawberry<br>
<input type=checkbox name=flavor value=chocolate checked>Chocolate<br>
8.1.2.4. Radio Button: INPUT TYPE=RADIO
An <INPUT> element with `TYPE=RADIO' represents a boolean choice. A
set of such elements with the same name represents a 1-of-many choice
field. The NAME and VALUE attributes are required as for check boxes.
Optional attributes are:
CHECKED
indicates that the initial state is on.
At all times, exactly one of the radio buttons in a set is checked.
If none of the <INPUT> elements of a set of radio buttons specifies
`CHECKED', then the user agent must check the first radio button of
the set initially.
For example:
<p>Which is your favorite?
<input type=radio name=flavor value=vanilla>Vanilla<br>
<input type=radio name=flavor value=strawberry>Strawberry<br>
<input type=radio name=flavor value=chocolate>Chocolate<br>
Berners-Lee & Connolly Standards Track [Page 42]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
8.1.2.5. Image Pixel: INPUT TYPE=IMAGE
An <INPUT> element with `TYPE=IMAGE' specifies an image resource to
display, and allows input of two form fields: the x and y coordinate
of a pixel chosen from the image. The names of the fields are the
name of the field with `.x' and `.y' appended. `TYPE=IMAGE' implies
`TYPE=SUBMIT' processing; that is, when a pixel is chosen, the form
as a whole is submitted.
The NAME attribute is required as for other input fields. The SRC
attribute is required and the ALIGN is optional as for the <IMG>
element (see 5.10, "Image: IMG").
For example:
<p>Choose a point on the map:
<input type=image name=point src="map.gif">
8.1.2.6. Hidden Field: INPUT TYPE=HIDDEN
An <INPUT> element with `TYPE=HIDDEN' represents a hidden field.The
user does not interact with this field; instead, the VALUE attribute
specifies the value of the field. The NAME and VALUE attributes are
required.
For example:
<input type=hidden name=context value="l2k3j4l2k3j4l2k3j4lk23">
8.1.2.7. Submit Button: INPUT TYPE=SUBMIT
An <INPUT> element with `TYPE=SUBMIT' represents an input option,
typically a button, that instructs the user agent to submit the form.
Optional attributes are:
NAME
indicates that this element contributes a form field
whose value is given by the VALUE attribute. If the NAME
attribute is not present, this element does not
contribute a form field.
VALUE
indicates a label for the input (button).
You may submit this request internally:
<input type=submit name=recipient value=internal><br>
or to the external world:
<input type=submit name=recipient value=world>
Berners-Lee & Connolly Standards Track [Page 43]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
8.1.2.8. Reset Button: INPUT TYPE=RESET
An <INPUT> element with `TYPE=RESET' represents an input option,
typically a button, that instructs the user agent to reset the form's
fields to their initial states. The VALUE attribute, if present,
indicates a label for the input (button).
When you are finished, you may submit this request:
<input type=submit><br>
You may clear the form and start over at any time: <input type=reset>
8.1.3. Selection: SELECT
The <SELECT> element constrains the form field to an enumerated list
of values. The values are given in <OPTION> elements. Attributes
are:
MULTIPLE
indicates that more than one option may be included in
the value.
NAME
specifies the name of the form field.
SIZE
specifies the number of visible items. Select fields of
size one are typically pop-down menus, whereas select
fields with size greater than one are typically lists.
For example:
<SELECT NAME="flavor">
<OPTION>Vanilla
<OPTION>Strawberry
<OPTION value="RumRasin">Rum and Raisin
<OPTION selected>Peach and Orange
</SELECT>
The initial state has the first option selected, unless a SELECTED
attribute is present on any of the <OPTION> elements.
8.1.3.1. Option: OPTION
The Option element can only occur within a Select element. It
represents one choice, and has the following attributes:
SELECTED
Indicates that this option is initially selected.
Berners-Lee & Connolly Standards Track [Page 44]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
VALUE
indicates the value to be returned if this option is
chosen. The field value defaults to the content of the
<OPTION> element.
The content of the <OPTION> element is presented to the user to
represent the option. It is used as a returned value if the VALUE
attribute is not present.
8.1.4. Text Area: TEXTAREA
The <TEXTAREA> element represents a multi-line text field.
Attributes are:
COLS
the number of visible columns to display for the text
area, in characters.
NAME
Specifies the name of the form field.
ROWS
The number of visible rows to display for the text area,
in characters.
For example:
<TEXTAREA NAME="address" ROWS=6 COLS=64>
HaL Computer Systems
1315 Dell Avenue
Campbell, California 95008
</TEXTAREA>
The content of the <TEXTAREA> element is the field's initial value.
Typically, the ROWS and COLS attributes determine the visible
dimension of the field in characters. The field is typically rendered
in a fixed-width font. HTML user agents should allow text to extend
beyond these limits by scrolling as needed.
8.2. Form Submission
An HTML user agent begins processing a form by presenting the
document with the fields in their initial state. The user is allowed
to modify the fields, constrained by the field type etc. When the
user indicates that the form should be submitted (using a submit
button or image input), the form data set is processed according to
its method, action URI and enctype.
Berners-Lee & Connolly Standards Track [Page 45]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
When there is only one single-line text input field in a form, the
user agent should accept Enter in that field as a request to submit
the form.
8.2.1. The form-urlencoded Media Type
The default encoding for all forms is `application/x-www-form-
urlencoded'. A form data set is represented in this media type as
follows:
1. The form field names and values are escaped: space
characters are replaced by `+', and then reserved characters
are escaped as per [URL]; that is, non-alphanumeric
characters are replaced by `%HH', a percent sign and two
hexadecimal digits representing the ASCII code of the
character. Line breaks, as in multi-line text field values,
are represented as CR LF pairs, i.e. `%0D%0A'.
2. The fields are listed in the order they appear in the
document with the name separated from the value by `=' and
the pairs separated from each other by `&'. Fields with null
values may be omitted. In particular, unselected radio
buttons and checkboxes should not appear in the encoded
data, but hidden fields with VALUE attributes present
should.
NOTE - The URI from a query form submission can be
used in a normal anchor style hyperlink.
Unfortunately, the use of the `&' character to
separate form fields interacts with its use in SGML
attribute values as an entity reference delimiter.
For example, the URI `http://host/?x=1&y=2' must be
written `<a href="http://host/?x=1&y=2"' or `<a
href="http://host/?x=1&y=2">'.
HTTP server implementors, and in particular, CGI
implementors are encouraged to support the use of
`;' in place of `&' to save users the trouble of
escaping `&' characters this way.
8.2.2. Query Forms: METHOD=GET
If the processing of a form is idempotent (i.e. it has no lasting
observable effect on the state of the world), then the form method
should be `GET'. Many database searches have no visible side-effects
and make ideal applications of query forms.
Berners-Lee & Connolly Standards Track [Page 46]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
To process a form whose action URL is an HTTP URL and whose method is
`GET', the user agent starts with the action URI and appends a `?'
and the form data set, in `application/x-www-form-urlencoded' format
as above. The user agent then traverses the link to this URI just as
if it were an anchor (see 7.2, "Activation of Hyperlinks").
NOTE - The URL encoding may result in very long URIs, which cause
some historical HTTP server implementations to exhibit defective
behavior. As a result, some HTML forms are written using
`METHOD=POST' even though the form submission has no side-effects.
8.2.3. Forms with Side-Effects: METHOD=POST
If the service associated with the processing of a form has side
effects (for example, modification of a database or subscription to a
service), the method should be `POST'.
To process a form whose action URL is an HTTP URL and whose method is
`POST', the user agent conducts an HTTP POST transaction using the
action URI, and a message body of type `application/x-www-form-
urlencoded' format as above. The user agent should display the
response from the HTTP POST interaction just as it would display the
response from an HTTP GET above.
8.2.4. Example Form Submission: Questionnaire Form
Consider the following document:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<title>Sample of HTML Form Submission</title>
<H1>Sample Questionnaire</H1>
<P>Please fill out this questionnaire:
<FORM METHOD="POST" ACTION="http://www.w3.org/sample">
<P>Your name: <INPUT NAME="name" size="48">
<P>Male <INPUT NAME="gender" TYPE=RADIO VALUE="male">
<P>Female <INPUT NAME="gender" TYPE=RADIO VALUE="female">
<P>Number in family: <INPUT NAME="family" TYPE=text>
<P>Cities in which you maintain a residence:
<UL>
<LI>Kent <INPUT NAME="city" TYPE=checkbox VALUE="kent">
<LI>Miami <INPUT NAME="city" TYPE=checkbox VALUE="miami">
<LI>Other <TEXTAREA NAME="other" cols=48 rows=4></textarea>
</UL>
Nickname: <INPUT NAME="nickname" SIZE="42">
<P>Thank you for responding to this questionnaire.
<P><INPUT TYPE=SUBMIT> <INPUT TYPE=RESET>
</FORM>
Berners-Lee & Connolly Standards Track [Page 47]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
The initial state of the form data set is:
name
""
gender
"male"
family
""
other
""
nickname
""
Note that the radio input has an initial value, while the
checkbox has none.
The user might edit the fields and request that the form be
submitted. At that point, suppose the values are:
name
"John Doe"
gender
"male"
family
"5"
city
"kent"
city
"miami"
other
"abc\ndefk"
nickname
"J&D"
The user agent then conducts an HTTP POST transaction using the URI
`http://www.w3.org/sample'. The message body would be (ignore the
line break):
Berners-Lee & Connolly Standards Track [Page 48]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
name=John+Doe&gender=male&family=5&city=kent&city=miami&
other=abc%0D%0Adef&nickname=J%26D
continued from RFC 1866...
9. HTML Public Text 9.1. HTML DTD This is the Document Type Definition for the HyperText Markup Language, level 2.La DTD elle-même commence à la prochaine ligne. Elle débute du reste par un commentaire (<!-- indique un début de commentaire en SGML).
<!-- html.dtd
Document Type Definition for the HyperText Markup Language
(HTML DTD)
$Id: html.dtd,v 1.30 1995/09/21 23:30:19 connolly Exp $
Author: Daniel W. Connolly <connolly@w3.org>
See Also: html.decl, html-1.dtd
http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
"-//IETF//DTD HTML 2.0//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
...
</html>
--
>
La première entité décrite par la DTD est la version de la
DTD présentée. En commentaire (entre les deux "--" qui
sont bien des commentaires puisque nous sommes dans une zone <!
... >), on trouve le code HTML que l'on est censé
trouver en début et fin d'un document HTML.
<! est une "markup declaration open" et > une "markup declaration close". Vous vous apercevrez que toutes les déclarations SGML sont cernées par ces deux signaux.
Voir [SGML-Handbook], B.3.2, p23
Le % ("parameter entity reference open" delimiter) séparé de HTML.Version par une espace indique que l'entité HTML.Version est ici déclarée, et que l'on pourra s'y référer dans la suite du document par %HTML.Version (qui est donc une "parameter entity reference").Voir [SGML-Handbook], B.4.2.3, p29
Voici à présent un message de la liste www-html@w3.org du 30 septembre 1996, expliquant comment il est possible de placer sur le Web des documents selon une DTD non encore répandue...continued from -//IETF//DTD HTML//EN...
> Interesting side-note: suppose I write my documents to adhere to
> such a non-official DTD. How can I pass them to a validator if
> that validator does not have that DTD available? Can I use the
> DOCTYPE declaration to point to the DTD (assuming I put it on the Web)?Yes. The public identifier (and/or system identifier) is used to signify the document type declaration external subset.
> I've seen many documents with
> <!DOCTYPE HTML PUBLIC "-//IETF/DTD HTML 3.0//" "html.dtd">
> which is obvious incorrect,No it is not. The declaration is perfectly valid.
> but does the last bit imply you can
> provide an URL to your own DTD to be used?Yes.
With SGML, an external entity can be identified with a public identifier, a system identifier, or both. With a public identifier, the processing system has to map the public identifier to a system identifier (ie. the actual storage object). The system id can be a file, a URL, a SQL query, etc. The definition of the mapping is normally done by an entity catalog that tells the system what are the system identifiers for public identifiers.
If just a system id is specified, then the processing system uses it to find the entity. Since this leads to portability problems, some systems allow the mapping of a system id to another system id. BTW, public identifiers should be used when a document is to transmitted to, or processed by, other systems.
When both are defined, it is implementation defined on which takes precedence. SP allows you to specify which identifier takes precedence.
Hence, if you publish a document on the web that does not adhere to a standard DTD, you can use something like one of the following doctype declarations:
<!DOCTYPE HTML SYSTEM "http://myorg.org/html.dtd">
<!DOCTYPE HTML PUBLIC "-//MyOrg/DTD HTML 3.0 Variant//EN">
<!DOCTYPE HTML PUBLIC "-//MyOrg/DTD HTML 3.0 Variant//EN" "http://myorg.org/html.dtd">Note: Formal system identifiers should used for system identifiers so the processing system can adequately determine how to resolve the system identifier. Example:
<!DOCTYPE HTML SYSTEM "<url>http://myorg.org/html.dtd">
The "<url>" tag is added to signify to the parser that the system identifier is to be treated as a URL.
The problem in the long run is you would like to avoid specifying system identifiers in your document since when the external entities it references move, you must update your document. Since you can specify entity mappings outside of the document source, ideally, you will only be required to update the mapping. With respect to the WWW, when you serve your document to a client, you also serve your entity catalog so the client will now how to resolve any external entities.
Groups have already been working on this issue (for general SGML document delivery on the WWW), so hopefully something will become available to the masses in the near future.
Earl Hood <ehood@isogen.com>
<!--============ Feature Test Entities ========================-->
<!ENTITY % HTML.Recommended "IGNORE"
-- Certain features of the language are necessary for
compatibility with widespread usage, but they may
compromise the structural integrity of a document.
This feature test entity enables a more prescriptive
document type definition that eliminates
those features.
-->
<![ %HTML.Recommended [
<!ENTITY % HTML.Deprecated "IGNORE">
Berners-Lee & Connolly Standards Track [Page 49]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
]]>
Juste après la "markup declaration open" on trouve le caractère
[ qui est une "declaration subset open" delimiter, suivi
de IGNORE (sous la forme de %HTML.Recommended)
suivi d'une seconde "declaration subset open" delimiter, suivi du contenu
<!ENTITY % HTML.Deprecated "IGNORE">, suivi de deux
] qui sont les "marked section close" delimiter, puis
d'une "markup declaration close".
Voir [SGML-Handbook], B.8.1, p48
continued from -//IETF//DTD HTML//EN...<!ENTITY % HTML.Deprecated "INCLUDE"
-- Certain features of the language are necessary for
compatibility with earlier versions of the specification,
but they tend to be used and implemented inconsistently,
and their use is deprecated. This feature test entity
enables a document type definition that eliminates
these features.
-->
<!ENTITY % HTML.Highlighting "INCLUDE"
-- Use this feature test entity to validate that a
document uses no highlighting tags, which may be
ignored on minimal implementations.
-->
<!ENTITY % HTML.Forms "INCLUDE"
-- Use this feature test entity to validate that a document
contains no forms, which may not be supported in minimal
implementations
-->
<!--============== Imported Names ==============================-->
<!ENTITY % Content-Type "CDATA"
-- meaning an internet media type
(aka MIME content type, as per RFC1521)
-->
<!ENTITY % HTTP-Method "GET | POST"
-- as per HTTP specification, in progress
-->
<!--========= DTD "Macros" =====================-->
<!ENTITY % heading "H1|H2|H3|H4|H5|H6">
<!ENTITY % list " UL | OL | DIR | MENU " >
Les deux "macros" qui viennent d'être déclarées seront utiles par la suite
pour désigner d'un coup les éléments qui les constituent.
continued from -//IETF//DTD HTML//EN...
<!--======= Character mnemonic entities =================--> <!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML"> %ISOlat1; <!ENTITY amp CDATA "&" -- ampersand --> Berners-Lee & Connolly Standards Track [Page 50] RFC 1866 Hypertext Markup Language - 2.0 November 1995 <!ENTITY gt CDATA ">" -- greater than --> <!ENTITY lt CDATA "<" -- less than --> <!ENTITY quot CDATA """ -- double quote -->Nous venons de déclarer des entités supplémentaires en deux lots. Le premier, ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML est un jeu d'entités contenu dans un fichier séparé (le fameux ISO 8879), le deuxième est un ensemble de quatre entités déclarées ici même.
Dans le premier lot, le mot-clé PUBLIC indique que le lot d'entité est parfaitement connu indépendemment de la DTD en cours de spécification. Il réfère donc un document précis et unique.
Voir [SGML-Handbook], B.6.2.4, p42
Les quatre entités du deuxième lot définissent les caractères &, >, < et " qui ont un statut particulier dans le codage HTML, comme vous devez le savoir ; & est le caractère de début des entités comme é, < et > sont les caractères permettant de délimiter les noms de balises (comme <em>) et " intervient dans la déclaration des attributs d'une balise (comme <img src="image.gif">). C'est pourquoi la DTD définit ces quatres entités, pour pouvoir quand-même dessiner les caractères sur votre UA, sans que celle-ci les prenne pour autre chose.continued from -//IETF//DTD HTML//EN...
<!--========= SGML Document Access (SDA) Parameter Entities =====-->
<!-- HTML 2.0 contains SGML Document Access (SDA) fixed attributes
in support of easy transformation to the International Committee
for Accessible Document Design (ICADD) DTD
"-//EC-USA-CDA/ICADD//DTD ICADD22//EN".
ICADD applications are designed to support usable access to
structured information by print-impaired individuals through
Braille, large print and voice synthesis. For more information on
SDA & ICADD:
- ISO 12083:1993, Annex A.8, Facilities for Braille,
large print and computer voice
- ICADD ListServ
<ICADD%ASUACAD.BITNET@ARIZVM1.ccit.arizona.edu>
- Usenet news group bit.listserv.easi
- Recording for the Blind, +1 800 221 4792
-->
<!ENTITY % SDAFORM "SDAFORM CDATA #FIXED"
-- one to one mapping -->
<!ENTITY % SDARULE "SDARULE CDATA #FIXED"
-- context-sensitive mapping -->
<!ENTITY % SDAPREF "SDAPREF CDATA #FIXED"
-- generated text prefix -->
<!ENTITY % SDASUFF "SDASUFF CDATA #FIXED"
-- generated text suffix -->
<!ENTITY % SDASUSP "SDASUSP NAME #FIXED"
-- suspend transform process -->
<!--========== Text Markup =====================-->
<![ %HTML.Highlighting [
Il s'agit là du début de la définition des éléments et entités regroupés
sous le patronyme HTML.Highlighting.
continued from -//IETF//DTD HTML//EN...
<!ENTITY % font " TT | B | I "> <!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE "> <!ENTITY % text "#PCDATA | A | IMG | BR | %phrase | %font">On vient de définir trois entités, les deux premières étant des macros comme on l'a vu plus tôt, la dernière étant également une macro, mais qui reprend les deux macros précédentes et ajoute un type de données appelé PCDATA.
La gestion des caractères est un point important -et délicat- de SGML. On les classe selon les types suivants :
Voir [SGML-Handbook], B.7, p43
Voir [SGML-Handbook],
B.13.1, p58
Pour en revenir à la définition de text, on voit qu'il peut contenir des données PCDATA ou les balises A, IMG, BR ainsi que les balises réunies dans les entités phrase et font (utiliser les liens hypertextes proposés en ligne si vous ne vous souvenez pas ce que recouvrent ces deux entités).
continued from -//IETF//DTD HTML//EN...
<!ELEMENT (%font;|%phrase) - - (%text)*>La définition de cet élément résoud le problème suivant : "que peut-on trouver au sein des balises définies par font et phrase". La réponse est : "autant de données du type text que l'on veut", ce qui permet une récursivité sur font et phrase qui sont eux-mêmes des données permises au sein de text. Par cette construction, du code HTML comme <tt><b>gras et télétype</b></tt> est autorisé.
Les tirets "- -" signalent que les balises d'entrée et de sortie de font et phrase sont obligatoires. Nous reviendrons sur ce concept plus loin. Le * de "(%text)*" signifie "autant de... que l'on veut" (? aurait signifié zéro ou une fois, et + au moins une fois). Les deux parenthèses autour de "%font;|%phrase" signifient que les expressions qui sont incluses à l'intérieur forment un groupe pour le reste de l'opération ici définie.
Voir [SGML-Handbook], B.4.2.8, p32
Voir
[SGML-Handbook], C.1.2, p71
<!ATTLIST ( TT | CODE | SAMP | KBD | VAR )
%SDAFORM; "Lit"
Berners-Lee & Connolly Standards Track [Page 51]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
>
<!ATTLIST ( B | STRONG )
%SDAFORM; "B"
>
<!ATTLIST ( I | EM | CITE )
%SDAFORM; "It"
>
Que le lecteur patiente un peu pour avoir l'explication concernant les
ATTLIST...
continued from -//IETF//DTD HTML//EN...
<!-- <TT> Typewriter text --> <!-- <B> Bold text --> <!-- <I> Italic text --> <!-- <EM> Emphasized phrase --> <!-- <STRONG> Strong emphasis --> <!-- <CODE> Source code phrase --> <!-- <SAMP> Sample text or characters --> <!-- <KBD> Keyboard phrase, e.g. user input --> <!-- <VAR> Variable phrase or substitutable --> <!-- <CITE> Name or title of cited work -->On voit que les auteurs de la DTD spécifient dans leur commentaires ce que devrait signifier pour un humain les différentes balises qui viennent d'être définies.
continued from -//IETF//DTD HTML//EN...
<!ENTITY % pre.content "#PCDATA | A | HR | BR | %font | %phrase"> ]]>Il s'agit là de la fin de la définition des éléments et entités regroupés sous le patronyme HTML.Highlighting.
Une dernière entité a été déclarée, pre.content, qui servira plus loin, et que vous devez savoir interprêter à présent.
continued from -//IETF//DTD HTML//EN...
<!ENTITY % text "#PCDATA | A | IMG | BR">Nouvelle définition de text dans le cas où la section précédente HTML.Highlighting ne serait pas incluse (par le jeu des INCLUDE, IGNORE). Si cette dernière est incluse, c'est la définition de text qui y est formulée qui prend le pas sur celle, plus pauvre, qui vient d'être proposeée.
continued from -//IETF//DTD HTML//EN...
<!ELEMENT BR - O EMPTY>
<!ATTLIST BR
%SDAPREF; "&#RE;"
>
<!-- <BR> Line break -->
L'élément BR peut voir sa balise de sortie ommise
(présence de O, là où on avait le deuxième tiret de "-
-" plus haut). Cela signifie que </BR> n'est pas
obligatoire, ce qui est rassurant puisque cette balise ne doit pas
(EMPTY) contenir quoi que ce soit : i.e. <BR>bla
bla</BR> est inconcevable.
Voir [SGML-Handbook], B.4.2.6, p31
<!--========= Link Markup ======================-->
<!ENTITY % linkType "NAMES">
<!ENTITY % linkExtraAttributes
"REL %linkType #IMPLIED
REV %linkType #IMPLIED
URN CDATA #IMPLIED
TITLE CDATA #IMPLIED
METHODS NAMES #IMPLIED
">
Il s'agit là du début de la définition des éléments et entités regroupés
sous le patronyme HTML.Recommended.
continued from -//IETF//DTD HTML//EN...
<![ %HTML.Recommended [
<!ENTITY % A.content "(%text)*"
Berners-Lee & Connolly Standards Track [Page 52]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
-- <H1><a name="xxx">Heading</a></H1>
is preferred to
<a name="xxx"><H1>Heading</H1></a>
-->
]]>
Il s'agit là de la fin de la définition des éléments et entités regroupés
sous le patronyme HTML.Recommended.
Seul a.content a été défini, d'une manière telle (voir les commentaires des auteurs de la DTD) que la balise A ne peut accepter en son sein que des données définies par text. Hors de ces recommendations, on voit que la dite balise peut aussi contenir des en-têtes H1..H6 (voir juste en dessous la reprise de la DTD). Il s'agit juste d'indications de style (de codage HTML) qui sont founies par les auteurs.
continued from -//IETF//DTD HTML//EN...
<!ENTITY % A.content "(%heading|%text)*"> <!ELEMENT A - - %A.content -(A)>Une balise A doit avoir ses balises d'entrée et de sortie présentes, et ne peut englober que du A.content tel que défini à l'instant.
-(A) signifie qu'aucune balise A n'est autorisée à vivre au sein d'une autre balise A. Les constructions du type <a href="bla">un <a name="blu">petit</a> exemple</a></a> ne peuvent donc exister.
Voir [SGML-Handbook], B.11.2, p55
<!ATTLIST A
HREF CDATA #IMPLIED
NAME CDATA #IMPLIED
%linkExtraAttributes;
%SDAPREF; "<Anchor: #AttList>"
>
<!-- <A> Anchor; source/destination of link -->
<!-- <A NAME="..."> Name of this anchor -->
<!-- <A HREF="..."> Address of link destination -->
<!-- <A URN="..."> Permanent address of destination -->
<!-- <A REL=...> Relationship to destination -->
<!-- <A REV=...> Relationship of destination to this -->
<!-- <A TITLE="..."> Title of destination (advisory) -->
<!-- <A METHODS="..."> Operations on destination (advisory) -->
Il est temps d'expliquer ce que recouvrent les fameux
ATTLIST, déjà rencontrés plus tôt. Comme vous l'aurez peut-être
deviné, il s'agit des attributs qu'il est possible d'accoler à un
élément. Par exemple, pour l'élément A, vous allez recontrer la code
HTML suivant : <a href="bla"
name="blo">blu</a> (les auteurs de la RFC 1866 donnent du reste
plusieurs exemples commentés).
Les différents attributs proposés (HREF, NAME plus la liste des "linkExtraAttributes" définie plus haut) peuvent cohabiter comme dans l'exemple du paragraphe précédent (l'espace étant le séparateur). #IMPLIED signifie que l'attribut est optionnel, et qu'en cas d'absence le système SGML saura ajouter les éventuelles informations nécessaires. Et rappelez-vous, CDATA signifie que la valeur de l'attribut ne sera pas analysée lexicalement
Voir [SGML-Handbook], B.5, pp33-38
<!--========== Images ==========================-->
<!ELEMENT IMG - O EMPTY>
<!ATTLIST IMG
SRC CDATA #REQUIRED
ALT CDATA #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
ISMAP (ISMAP) #IMPLIED
%SDAPREF; "<Fig><?SDATrans Img: #AttList>#AttVal(Alt)</Fig>"
>
<!-- <IMG> Image; icon, glyph or illustration -->
<!-- <IMG SRC="..."> Address of image object -->
<!-- <IMG ALT="..."> Textual alternative -->
<!-- <IMG ALIGN=...> Position relative to text -->
<!-- <IMG ISMAP> Each pixel can be a link -->
Ici #REQUIRED signifie que l'attribut en question est
obligatoire. (top|middle|bottom) signifie que
l'attribut ALT ne peut prendre qu'une des trois valeurs top,
middle ou bottom. De même ISMAP ne peut
prendre comme valeur que ISMAP. C'est la valeur par défaut et la
construction classique est <img src="bla" ismap>.
À part ces deux points, vous savez interprêter le reste de la définition de IMG, que nous pouvons donc laisser à titre d'exercice. Par exemple, interrogez-vous sur la signification de - O EMPTY...
continued from -//IETF//DTD HTML//EN...
<!--========== Paragraphs=======================-->
<!ELEMENT P - O (%text)*>
<!ATTLIST P
%SDAFORM; "Para"
>
Interrogation écrite, prenez une feuille : que peut-on trouver entre
les balises <p> et </p>, et cette dernière
(</p>) est-elle obligatoire ?
continued from -//IETF//DTD HTML//EN...
Berners-Lee & Connolly Standards Track [Page 53]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!-- <P> Paragraph -->
<!--========== Headings, Titles, Sections ===============-->
<!ELEMENT HR - O EMPTY>
<!ATTLIST HR
%SDAPREF; "&#RE;&#RE;"
>
<!-- <HR> Horizontal rule -->
<!ELEMENT ( %heading ) - - (%text;)*>
<!ATTLIST H1
%SDAFORM; "H1"
>
<!ATTLIST H2
%SDAFORM; "H2"
>
<!ATTLIST H3
%SDAFORM; "H3"
>
<!ATTLIST H4
%SDAFORM; "H4"
>
<!ATTLIST H5
%SDAFORM; "H5"
>
<!ATTLIST H6
%SDAFORM; "H6"
>
<!-- <H1> Heading, level 1 -->
<!-- <H2> Heading, level 2 -->
<!-- <H3> Heading, level 3 -->
<!-- <H4> Heading, level 4 -->
<!-- <H5> Heading, level 5 -->
<!-- <H6> Heading, level 6 -->
<!--========== Text Flows ======================-->
<![ %HTML.Forms [
<!ENTITY % block.forms "BLOCKQUOTE | FORM | ISINDEX">
]]>
<!ENTITY % block.forms "BLOCKQUOTE">
Berners-Lee & Connolly Standards Track [Page 54]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<![ %HTML.Deprecated [
<!ENTITY % preformatted "PRE | XMP | LISTING">
]]>
Une section HTML.Deprecated pour signifier qu'une ancienne
définition de preformatted doit être vouée à l'abandon. En effet
XMP et LISTING sont considérés dans cette RFC comme devant ne
plus être utilisées. La nouvelle définition de preformatted sera
réduite à PRE.
continued from -//IETF//DTD HTML//EN...
<!ENTITY % preformatted "PRE">
<!ENTITY % block "P | %list | DL
| %preformatted
| %block.forms">
<!ENTITY % flow "(%text|%block)*">
<!ENTITY % pre.content "#PCDATA | A | HR | BR">
<!ELEMENT PRE - - (%pre.content)*>
<!ATTLIST PRE
WIDTH NUMBER #implied
%SDAFORM; "Lit"
>
NUMBER signifie ici que les valeurs de l'attribut
WIDTH sont des entiers (positifs, car on ne peut pas mettre de signe
"-" devant).
continued from -//IETF//DTD HTML//EN...
<!-- <PRE> Preformatted text -->
<!-- <PRE WIDTH=...> Maximum characters per line -->
<![ %HTML.Deprecated [
<!ENTITY % literal "CDATA"
-- historical, non-conforming parsing mode where
the only markup signal is the end tag
in full
-->
<!ELEMENT (XMP|LISTING) - - %literal>
<!ATTLIST XMP
%SDAFORM; "Lit"
%SDAPREF; "Example:&#RE;"
>
<!ATTLIST LISTING
%SDAFORM; "Lit"
%SDAPREF; "Listing:&#RE;"
>
<!-- <XMP> Example section -->
<!-- <LISTING> Computer listing -->
<!ELEMENT PLAINTEXT - O %literal>
<!-- <PLAINTEXT> Plain text passage -->
<!ATTLIST PLAINTEXT
%SDAFORM; "Lit"
Berners-Lee & Connolly Standards Track [Page 55]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
>
]]>
<!--========== Lists ==================-->
<!ELEMENT DL - - (DT | DD)+>
<!ATTLIST DL
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "Definition List:"
>
<!ELEMENT DT - O (%text)*>
<!ATTLIST DT
%SDAFORM; "Term"
>
<!ELEMENT DD - O %flow>
<!ATTLIST DD
%SDAFORM; "LItem"
>
<!-- <DL> Definition list, or glossary -->
<!-- <DL COMPACT> Compact style list -->
<!-- <DT> Term in definition list -->
<!-- <DD> Definition of term -->
Voici le début des définitions de listes structurées. On rappelle que le
signe "+" signifie "au moins une fois". La lecture de ces
définitions ne devrait plus poser de difficultés.
continued from -//IETF//DTD HTML//EN...
<!ELEMENT (OL|UL) - - (LI)+>
<!ATTLIST OL
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!ATTLIST UL
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
>
<!-- <UL> Unordered list -->
<!-- <UL COMPACT> Compact list style -->
<!-- <OL> Ordered, or numbered list -->
<!-- <OL COMPACT> Compact list style -->
<!ELEMENT (DIR|MENU) - - (LI)+ -(%block)>
<!ATTLIST DIR
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Directory</LHead>"
>
Berners-Lee & Connolly Standards Track [Page 56]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ATTLIST MENU
COMPACT (COMPACT) #IMPLIED
%SDAFORM; "List"
%SDAPREF; "<LHead>Menu</LHead>"
>
<!-- <DIR> Directory list -->
<!-- <DIR COMPACT> Compact list style -->
<!-- <MENU> Menu list -->
<!-- <MENU COMPACT> Compact list style -->
<!ELEMENT LI - O %flow>
<!ATTLIST LI
%SDAFORM; "LItem"
>
<!-- <LI> List item -->
<!--========== Document Body ===================-->
<![ %HTML.Recommended [
<!ENTITY % body.content "(%heading|%block|HR|ADDRESS|IMG)*"
-- <h1>Heading</h1>
<p>Text ...
is preferred to
<h1>Heading</h1>
Text ...
-->
]]>
<!ENTITY % body.content "(%heading | %text | %block |
HR | ADDRESS)*">
Vous aurez observé que la différence entre la version
HTML.Recommended et la version de base est que dans le premier cas
%text n'apparaît pas. Comme block contient text, via
p (vérifiez), nous sommes sauvés, cela permet quand-même de mettre du
texte de base (le fameux #PCDATA de text, vérifiez) dans le
corps (BODY) d'un document HTML. Mais, comme l'expliquent les
auteurs, la recommendation tient à ce que du text ne soit pas un
élément que l'on trouve immédiatement après H1 par exemple.
Prenez le temps de réfléchir à cette subtilité qui va vous permettre de revoir les éléments déjà définis et de bien saisir les mécanismes de structuration grâce à une DTD d'un format de document.
Au fait, que pensez-vous de la différence entre les deux définitions en ce qui concerne IMG ?
continued from -//IETF//DTD HTML//EN...
<!ELEMENT BODY O O %body.content>Les balises d'entrée et de sortie de BODY sont optionnelles, car la DTD est suffisament cohérente pour qu'aucune ambiguïté n'existe entre les informations de type HEAD et celles de type BODY.
continued from -//IETF//DTD HTML//EN...
<!-- <BODY> Document body -->
<!ELEMENT BLOCKQUOTE - - %body.content>
<!ATTLIST BLOCKQUOTE
%SDAFORM; "BQ"
>
<!-- <BLOCKQUOTE> Quoted passage -->
<!ELEMENT ADDRESS</a> - - (%text|P)*>
<!ATTLIST ADDRESS
%SDAFORM; "Lit"
%SDAPREF; "Address:&#RE;"
Berners-Lee & Connolly Standards Track [Page 57]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
>
<!-- <ADDRESS> Address, signature, or byline -->
On ne peut pas mettre grand chose au sein d'une
ADDRESS : du texte de base, ancres et images, et des
P, rien de plus (pas de formulaires, pas de texte préformatté, pas de
listes...).
continued from -//IETF//DTD HTML//EN...
<!--======= Forms ====================-->
<![ %HTML.Forms [
<!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)>
<!ATTLIST FORM
ACTION CDATA #IMPLIED
METHOD (%HTTP-Method) GET
ENCTYPE %Content-Type; "application/x-www-form-urlencoded"
%SDAPREF; "<Para>Form:</Para>"
%SDASUFF; "<Para>Form End.</Para>"
>
<!-- <FORM> Fill-out or data-entry form -->
<!-- <FORM ACTION="..."> Address for completed form -->
<!-- <FORM METHOD=...> Method of submitting form -->
<!-- <FORM ENCTYPE="..."> Representation of form data -->
Comme l'exprime -(FORM), un formulaire ne peut pas
contenir immédiatement un formulaire. En revanche, il peut contenir (même en
plein milieu des data characters) des éléments de type INPUT,
SELECT et TEXTAREA -et bien sûr tout ce qui est du
body.content.
Est-ce que, par l'intermédiaire des éléments qu'il peut contenir, un formualire pourrait quand-même contenir un formulaire ? S'il le pouvait, ce serait par l'intermédiaire de body.content, car INPUT, SELECT et TEXTAREA ne peuvent contenir de FORM (vérifier plus bas). En examinant body.content, on s'aperçoit que c'est en réalité block qui poserait problème, ce dernier permettant l'inclusion de commentaire seulement si on est dans le cas HTML.Forms. Donc formellement -sans jeu de mots- un formulaire peut contenir un formulaire ?
Examinons à présent les attributs de FORM. On y trouve deux attributs dont les valeurs possibles ont été définies très tôt (au tout début de la DTD), et qui ont chacun une valeur par défaut (respectivement GET et "application/x-www-form-urlencoded"). En l'absence de l'attribut METHOD, la méthode utilisée sera donc GET (quoi que cela puisse vouloir signifier).
continued from -//IETF//DTD HTML//EN...
<!ENTITY % InputType "(TEXT | PASSWORD | CHECKBOX |
RADIO | SUBMIT | RESET |
IMAGE | HIDDEN )">
<!ELEMENT INPUT - O EMPTY>
<!ATTLIST INPUT
TYPE %InputType TEXT
NAME CDATA #IMPLIED
VALUE CDATA #IMPLIED
SRC CDATA #IMPLIED
CHECKED (CHECKED) #IMPLIED
SIZE CDATA #IMPLIED
MAXLENGTH NUMBER #IMPLIED
ALIGN (top|middle|bottom) #IMPLIED
%SDAPREF; "Input: "
>
<!-- <INPUT> Form input datum -->
<!-- <INPUT TYPE=...> Type of input interaction -->
<!-- <INPUT NAME=...> Name of form datum -->
<!-- <INPUT VALUE="..."> Default/initial/selected value -->
<!-- <INPUT SRC="..."> Address of image -->
<!-- <INPUT CHECKED> Initial state is "on" -->
<!-- <INPUT SIZE=...> Field size hint -->
<!-- <INPUT MAXLENGTH=...> Data length maximum -->
<!-- <INPUT ALIGN=...> Image alignment -->
Berners-Lee & Connolly Standards Track [Page 58]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ELEMENT SELECT - - (OPTION+) -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST SELECT
NAME CDATA #REQUIRED
SIZE NUMBER #IMPLIED
MULTIPLE (MULTIPLE) #IMPLIED
%SDAFORM; "List"
%SDAPREF;
"<LHead>Select #AttVal(Multiple)</LHead>"
>
<!-- <SELECT> Selection of option(s) -->
<!-- <SELECT NAME=...> Name of form datum -->
<!-- <SELECT SIZE=...> Options displayed at a time -->
<!-- <SELECT MULTIPLE> Multiple selections allowed -->
<!ELEMENT OPTION - O (#PCDATA)*>
<!ATTLIST OPTION
SELECTED (SELECTED) #IMPLIED
VALUE CDATA #IMPLIED
%SDAFORM; "LItem"
%SDAPREF;
"Option: #AttVal(Value) #AttVal(Selected)"
>
<!-- <OPTION> A selection option -->
<!-- <OPTION SELECTED> Initial state -->
<!-- <OPTION VALUE="..."> Form datum value for this option-->
<!ELEMENT TEXTAREA - - (#PCDATA)* -(INPUT|SELECT|TEXTAREA)>
<!ATTLIST TEXTAREA
NAME CDATA #REQUIRED
ROWS NUMBER #REQUIRED
COLS NUMBER #REQUIRED
%SDAFORM; "Para"
%SDAPREF; "Input Text -- #AttVal(Name): "
>
<!-- <TEXTAREA> An area for text input -->
<!-- <TEXTAREA NAME=...> Name of form datum -->
<!-- <TEXTAREA ROWS=...> Height of area -->
<!-- <TEXTAREA COLS=...> Width of area -->
Que ce soit pour SELECT ou TEXTAREA dont les deux
balises d'entrée et de sorties sont obligatoires, vous noterez comment les
autres éléments possibles d'un formulaire sont exclus d'apparition en leur sein.
Vous noterez également que l'on peut mettre ce que l'on veut dans un
TEXTAREA -en d'autres termes, la valeur d'un TEXTAREA va entre
ses deux balises, alors que pour les autres éléments d'un formulaire il y a
toujours un attribut VALUE ad'hoc.
continued from -//IETF//DTD HTML//EN...
]]>
<!--======= Document Head ======================-->
<![ %HTML.Recommended [
Berners-Lee & Connolly Standards Track [Page 59]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ENTITY % head.extra "">
]]>
<!ENTITY % head.extra "& NEXTID?">
<!ENTITY % head.content "TITLE & ISINDEX? & BASE? %head.extra">
<!ELEMENT HEAD O O (%head.content) +(META|LINK)>
<!-- <HEAD> Document head -->
<!ELEMENT TITLE - - (#PCDATA)* -(META|LINK)>
<!ATTLIST TITLE
%SDAFORM; "Ti" >
<!-- <TITLE> Title of document -->
<!ELEMENT LINK - O EMPTY>
<!ATTLIST LINK
HREF CDATA #REQUIRED
%linkExtraAttributes;
%SDAPREF; "Linked to : #AttVal (TITLE) (URN) (HREF)>" >
<!-- <LINK> Link from this document -->
<!-- <LINK HREF="..."> Address of link destination -->
<!-- <LINK URN="..."> Lasting name of destination -->
<!-- <LINK REL=...> Relationship to destination -->
<!-- <LINK REV=...> Relationship of destination to this -->
<!-- <LINK TITLE="..."> Title of destination (advisory) -->
<!-- <LINK METHODS="..."> Operations allowed (advisory) -->
<!ELEMENT ISINDEX - O EMPTY>
<!ATTLIST ISINDEX
%SDAPREF;
"<Para>[Document is indexed/searchable.]</Para>">
<!-- <ISINDEX> Document is a searchable index -->
<!ELEMENT BASE - O EMPTY>
<!ATTLIST BASE
HREF CDATA #REQUIRED >
<!-- <BASE> Base context document -->
<!-- <BASE HREF="..."> Address for this document -->
<!ELEMENT NEXTID - O EMPTY>
<!ATTLIST NEXTID
N CDATA #REQUIRED >
Berners-Lee & Connolly Standards Track [Page 60]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!-- <NEXTID> Next ID to use for link name -->
<!-- <NEXTID N=...> Next ID to use for link name -->
<!ELEMENT META - O EMPTY>
<!ATTLIST META
HTTP-EQUIV NAME #IMPLIED
NAME NAME #IMPLIED
CONTENT CDATA #REQUIRED >
<!-- <META> Generic Meta-information -->
<!-- <META HTTP-EQUIV=...> HTTP response header name -->
<!-- <META NAME=...> Meta-information name -->
<!-- <META CONTENT="..."> Associated information -->
<!--======= Document Structure =================-->
<![ %HTML.Deprecated [
<!ENTITY % html.content "HEAD, BODY, PLAINTEXT?">
]]>
<!ENTITY % html.content "HEAD, BODY">
<!ELEMENT HTML O O (%html.content)>
<!ENTITY % version.attr "VERSION CDATA #FIXED '%HTML.Version;'">
<!ATTLIST HTML
%version.attr;
%SDAFORM; "Book"
>
<!-- <HTML> HTML Document -->
Et voilà ! Vous devez maintenant savoir lire
une DTD à peu près correctement. N'hésitez pas à vous exercer sur les
DTD des versions HTML plus récentes. Leur URL sera indiqué ici
un jour.
continued from RFC 1866...
9.2. Strict HTML DTD
This document type declaration refers to the HTML DTD with the
`HTML.Recommended' entity defined as `INCLUDE' rather than IGNORE;
that is, it refers to the more structurally rigid definition of HTML.
<!-- html-s.dtd
Document Type Definition for the HyperText Markup Language
with strict validation (HTML Strict DTD).
$Id: html-s.dtd,v 1.3 1995/06/02 18:55:46 connolly Exp $
Author: Daniel W. Connolly <connolly@w3.org>
See Also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
Berners-Lee & Connolly Standards Track [Page 61]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ENTITY % HTML.Version
"-//IETF//DTD HTML 2.0 Strict//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML Strict//EN">
<html>
...
</html>
--
>
<!-- Feature Test Entities -->
<!ENTITY % HTML.Recommended "INCLUDE">
<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
%html;
9.3. Level 1 HTML DTD
This document type declaration refers to the HTML DTD with the
`HTML.Forms' entity defined as `IGNORE' rather than `INCLUDE'.
Documents which contain <FORM> elements do not conform to this DTD,
and must use the level 2 DTD.
<!-- html-1.dtd
Document Type Definition for the HyperText Markup Language
with Level 1 Extensions (HTML Level 1 DTD).
$Id: html-1.dtd,v 1.2 1995/03/29 18:53:10 connolly Exp $
Author: Daniel W. Connolly <connolly@w3.org>
See Also: http://info.cern.ch/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
"-//IETF//DTD HTML 2.0 Level 1//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML Level 1//EN">
<html>
...
</html>
Berners-Lee & Connolly Standards Track [Page 62]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
--
>
<!-- Feature Test Entities -->
<!ENTITY % HTML.Forms "IGNORE">
<!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN">
%html;
9.4. Strict Level 1 HTML DTD
This document type declaration refers to the level 1 HTML DTD with
the `HTML.Recommended' entity defined as `INCLUDE' rather than
IGNORE; that is, it refers to the more structurally rigid definition
of HTML.
<!-- html-1s.dtd
Document Type Definition for the HyperText Markup Language
Struct Level 1
$Id: html-1s.dtd,v 1.3 1995/06/02 18:55:43 connolly Exp $
Author: Daniel W. Connolly <connolly@w3.org>
See Also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
<!ENTITY % HTML.Version
"-//IETF//DTD HTML 2.0 Strict Level 1//EN"
-- Typical usage:
<!DOCTYPE HTML PUBLIC
"-//IETF//DTD HTML Strict Level 1//EN">
<html>
...
</html>
--
>
<!-- Feature Test Entities -->
<!ENTITY % HTML.Recommended "INCLUDE">
<!ENTITY % html-1 PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN">
%html-1;
Berners-Lee & Connolly Standards Track [Page 63]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Voici à présent la déclaration SGML de HTML. Il s'agit
des définitions des syntaxes concrètes et abstraites.
La description de cette section est laissée en plan pour l'instant.
continued from RFC 1866...
9.5. SGML Declaration for HTML
This is the SGML Declaration for HyperText Markup Language.
<!SGML "ISO 8879:1986"
--
SGML Declaration for HyperText Markup Language (HTML).
--
CHARSET
BASESET "ISO 646:1983//CHARSET
International Reference Version
(IRV)//ESC 2/5 4/0"
DESCSET 0 9 UNUSED
9 2 9
11 2 UNUSED
13 1 13
14 18 UNUSED
32 95 32
127 1 UNUSED
BASESET "ISO Registration Number 100//CHARSET
ECMA-94 Right Part of
Latin Alphabet Nr. 1//ESC 2/13 4/1"
DESCSET 128 32 UNUSED
160 96 32
CAPACITY SGMLREF
TOTALCAP 150000
GRPCAP 150000
ENTCAP 150000
SCOPE DOCUMENT
SYNTAX
SHUNCHAR CONTROLS 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 127
BASESET "ISO 646:1983//CHARSET
International Reference Version
(IRV)//ESC 2/5 4/0"
DESCSET 0 128 0
FUNCTION
RE 13
RS 10
SPACE 32
TAB SEPCHAR 9
NAMING LCNMSTRT ""
UCNMSTRT ""
Berners-Lee & Connolly Standards Track [Page 64]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
LCNMCHAR ".-"
UCNMCHAR ".-"
NAMECASE GENERAL YES
ENTITY NO
DELIM GENERAL SGMLREF
SHORTREF SGMLREF
NAMES SGMLREF
QUANTITY SGMLREF
ATTSPLEN 2100
LITLEN 1024
NAMELEN 72 -- somewhat arbitrary; taken from
internet line length conventions --
PILEN 1024
TAGLVL 100
TAGLEN 2100
GRPGTCNT 150
GRPCNT 64
FEATURES
MINIMIZE
DATATAG NO
OMITTAG YES
RANK NO
SHORTTAG YES
LINK
SIMPLE NO
IMPLICIT NO
EXPLICIT NO
OTHER
CONCUR NO
SUBDOC NO
FORMAL YES
APPINFO "SDA" -- conforming SGML Document Access application
--
>
<!--
$Id: html.decl,v 1.17 1995/06/08 14:59:32 connolly Exp $
Author: Daniel W. Connolly <connolly@w3.org>
See also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.html
-->
9.6. Sample SGML Open Entity Catalog for HTML
The SGML standard describes an "entity manager" as the portion or
component of an SGML system that maps SGML entities into the actual
storage model (e.g., the file system). The standard itself does not
Berners-Lee & Connolly Standards Track [Page 65]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
define a particular mapping methodology or notation.
To assist the interoperability among various SGML tools and systems,
the SGML Open consortium has passed a technical resolution that
defines a format for an application-independent entity catalog that
maps external identifiers and/or entity names to file names.
Each entry in the catalog associates a storage object identifier
(such as a file name) with information about the external entity that
appears in the SGML document. In addition to entries that associate
public identifiers, a catalog entry can associate an entity name with
a storage object identifier. For example, the following are possible
catalog entries:
-- catalog: SGML Open style entity catalog for HTML --
-- $Id: catalog,v 1.3 1995/09/21 23:30:23 connolly Exp $ --
-- Ways to refer to Level 2: most general to most specific --
PUBLIC "-//IETF//DTD HTML//EN" html.dtd
PUBLIC "-//IETF//DTD HTML 2.0//EN" html.dtd
PUBLIC "-//IETF//DTD HTML Level 2//EN" html.dtd
PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN" html.dtd
-- Ways to refer to Level 1: most general to most specific --
PUBLIC "-//IETF//DTD HTML Level 1//EN" html-1.dtd
PUBLIC "-//IETF//DTD HTML 2.0 Level 1//EN" html-1.dtd
-- Ways to refer to
Strict Level 2: most general to most specific --
PUBLIC "-//IETF//DTD HTML Strict//EN" html-s.dtd
PUBLIC "-//IETF//DTD HTML 2.0 Strict//EN" html-s.dtd
PUBLIC "-//IETF//DTD HTML Strict Level 2//EN" html-s.dtd
PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 2//EN" html-s.dtd
-- Ways to refer to
Strict Level 1: most general to most specific --
PUBLIC "-//IETF//DTD HTML Strict Level 1//EN" html-1s.dtd
PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 1//EN" html-1s.dtd
-- ISO latin 1 entity set for HTML --
PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" ISOlat1\
sgml
9.7. Character Entity Sets
The HTML DTD defines the following entities. They represent
particular graphic characters which have special meanings in places
in the markup, or may not be part of the character set available to
Berners-Lee & Connolly Standards Track [Page 66]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
the writer.
9.7.1. Numeric and Special Graphic Entity Set
The following table lists each of the characters included from the
Numeric and Special Graphic entity set, along with its name, syntax
for use, and description. This list is derived from `ISO Standard
8879:1986//ENTITIES Numeric and Special Graphic//EN'. However, HTML
does not include for the entire entity set -- only the entities
listed below are included.
GLYPH NAME SYNTAX DESCRIPTION
< lt < Less than sign
> gt > Greater than signn
& amp & Ampersand
" quot " Double quote sign
9.7.2. ISO Latin 1 Character Entity Set
The following public text lists each of the characters specified in
the Added Latin 1 entity set, along with its name, syntax for use,
and description. This list is derived from ISO Standard
8879:1986//ENTITIES Added Latin 1//EN. HTML includes the entire
entity set.
<!-- (C) International Organization for Standardization 1986
Permission to copy in any form is granted for use with
conforming SGML systems and applications as defined in
ISO 8879, provided this notice is included in all copies.
-->
<!-- Character entity set. Typical invocation:
<!ENTITY % ISOlat1 PUBLIC
"ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML">
%ISOlat1;
-->
<!-- Modified for use in HTML
$Id: ISOlat1.sgml,v 1.2 1994/11/30 23:45:12 connolly Exp $ -->
<!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) -->
<!ENTITY Aacute CDATA "Á" -- capital A, acute accent -->
<!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent -->
<!ENTITY Agrave CDATA "À" -- capital A, grave accent -->
<!ENTITY Aring CDATA "Å" -- capital A, ring -->
<!ENTITY Atilde CDATA "Ã" -- capital A, tilde -->
<!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut mark -->
<!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla -->
<!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic -->
<!ENTITY Eacute CDATA "É" -- capital E, acute accent -->
<!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent -->
Berners-Lee & Connolly Standards Track [Page 67]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ENTITY Egrave CDATA "È" -- capital E, grave accent -->
<!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut mark -->
<!ENTITY Iacute CDATA "Í" -- capital I, acute accent -->
<!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent -->
<!ENTITY Igrave CDATA "Ì" -- capital I, grave accent -->
<!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut mark -->
<!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde -->
<!ENTITY Oacute CDATA "Ó" -- capital O, acute accent -->
<!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent -->
<!ENTITY Ograve CDATA "Ò" -- capital O, grave accent -->
<!ENTITY Oslash CDATA "Ø" -- capital O, slash -->
<!ENTITY Otilde CDATA "Õ" -- capital O, tilde -->
<!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut mark -->
<!ENTITY THORN CDATA "Þ" -- capital THORN, Icelandic -->
<!ENTITY Uacute CDATA "Ú" -- capital U, acute accent -->
<!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent -->
<!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent -->
<!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut mark -->
<!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent -->
<!ENTITY aacute CDATA "á" -- small a, acute accent -->
<!ENTITY acirc CDATA "â" -- small a, circumflex accent -->
<!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) -->
<!ENTITY agrave CDATA "à" -- small a, grave accent -->
<!ENTITY aring CDATA "å" -- small a, ring -->
<!ENTITY atilde CDATA "ã" -- small a, tilde -->
<!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut mark -->
<!ENTITY ccedil CDATA "ç" -- small c, cedilla -->
<!ENTITY eacute CDATA "é" -- small e, acute accent -->
<!ENTITY ecirc CDATA "ê" -- small e, circumflex accent -->
<!ENTITY egrave CDATA "è" -- small e, grave accent -->
<!ENTITY eth CDATA "ð" -- small eth, Icelandic -->
<!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut mark -->
<!ENTITY iacute CDATA "í" -- small i, acute accent -->
<!ENTITY icirc CDATA "î" -- small i, circumflex accent -->
<!ENTITY igrave CDATA "ì" -- small i, grave accent -->
<!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut mark -->
<!ENTITY ntilde CDATA "ñ" -- small n, tilde -->
<!ENTITY oacute CDATA "ó" -- small o, acute accent -->
<!ENTITY ocirc CDATA "ô" -- small o, circumflex accent -->
<!ENTITY ograve CDATA "ò" -- small o, grave accent -->
<!ENTITY oslash CDATA "ø" -- small o, slash -->
<!ENTITY otilde CDATA "õ" -- small o, tilde -->
<!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut mark -->
<!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature)->
<!ENTITY thorn CDATA "þ" -- small thorn, Icelandic -->
<!ENTITY uacute CDATA "ú" -- small u, acute accent -->
<!ENTITY ucirc CDATA "û" -- small u, circumflex accent -->
<!ENTITY ugrave CDATA "ù" -- small u, grave accent -->
Berners-Lee & Connolly Standards Track [Page 68]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut mark -->
<!ENTITY yacute CDATA "ý" -- small y, acute accent -->
<!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark -->
10. Security Considerations Anchors, embedded images, and all other elements which contain URIs as parameters may cause the URI to be dereferenced in response to user input. In this case, the security considerations of [URL] apply. The widely deployed methods for submitting forms requests -- HTTP and SMTP -- provide little assurance of confidentiality. Information providers who request sensitive information via forms -- especially by way of the `PASSWORD' type input field (see 8.1.2, "Input Field: INPUT") -- should be aware and make their users aware of the lack of confidentiality.
11. References
[URI]
Berners-Lee, T., "Universal Resource Identifiers in WWW:
A Unifying Syntax for the Expression of Names and
Addresses of Objects on the Network as used in the
World- Wide Web", RFC 1630, CERN, June 1994.
<URL:ftp://ds.internic.net/rfc/rfc1630.txt>
[URL]
Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
University of Minnesota, December 1994.
<URL:ftp://ds.internic.net/rfc/rfc1738.txt>
[HTTP]
Berners-Lee, T., Fielding, R., and H. Frystyk Nielsen,
"Hypertext Transfer Protocol - HTTP/1.0", Work in
Progress, MIT, UC Irvine, CERN, March 1995.
[MIME]
Borenstein, N., and N. Freed. "MIME (Multipurpose
Internet Mail Extensions) Part One: Mechanisms for
Specifying and Describing the Format of Internet Message
Bodies", RFC 1521, Bellcore, Innosoft, September 1993.
<URL:ftp://ds.internic.net/rfc/rfc1521.txt>
[RELURL]
Fielding, R., "Relative Uniform Resource Locators", RFC
1808, June 1995
<URL:ftp://ds.internic.net/rfc/rfc1808.txt>
Berners-Lee & Connolly Standards Track [Page 69]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
[GOLD90]
Goldfarb, C., "The SGML Handbook", Y. Rubinsky, Ed.,
Oxford University Press, 1990.
[DEXTER]
Frank Halasz and Mayer Schwartz, "The Dexter Hypertext
Reference Model", Communications of the ACM, pp.
30-39, vol. 37 no. 2, Feb 1994.
[IMEDIA]
Postel, J., "Media Type Registration Procedure",
RFC 1590, USC/Information Sciences Institute, March 1994.
<URL:ftp://ds.internic.net/rfc/rfc1590.txt>
[IANA]
Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
RFC 1700, USC/Information Sciecnes Institute, October
1994. <URL:ftp://ds.internic.net/rfc/rfc1700.txt>
[SQ91]
SoftQuad. "The SGML Primer", 3rd ed., SoftQuad Inc.,
1991. <URL:http://www.sq.com/>
[ISO-646]
ISO/IEC 646:1991 Information technology -- ISO 7-bit
coded character set for information interchange
<URL:http://www.iso.ch/cate/d4777.html>
[ISO-10646]
ISO/IEC 10646-1:1993 Information technology -- Universal
Multiple-Octet Coded Character Set (UCS) -- Part 1:
Architecture and Basic Multilingual Plane
<URL:http://www.iso.ch/cate/d18741.html>
[ISO-8859-1]
ISO 8859. International Standard -- Information
Processing -- 8-bit Single-Byte Coded Graphic Character
Sets -- Part 1: Latin Alphabet No. 1, ISO 8859-1:1987.
<URL:http://www.iso.ch/cate/d16338.html>
[SGML]
ISO 8879. Information Processing -- Text and Office
Systems - Standard Generalized Markup Language (SGML),
1986. <URL:http://www.iso.ch/cate/d16387.html>
Berners-Lee & Connolly Standards Track [Page 70]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
12. Acknowledgments
The HTML document type was designed by Tim Berners-Lee at CERN as
part of the 1990 World Wide Web project. In 1992, Dan Connolly wrote
the HTML Document Type Definition (DTD) and a brief HTML
specification.
Since 1993, a wide variety of Internet participants have contributed
to the evolution of HTML, which has included the addition of in-line
images introduced by the NCSA Mosaic software for WWW. Dave Raggett
played an important role in deriving the forms material from the
HTML+ specification.
Dan Connolly and Karen Olson Muldrow rewrote the HTML Specification
in 1994. The document was then edited by the HTML working group as a
whole, with updates being made by Eric Schieler, Mike Knezovich, and
Eric W. Sink at Spyglass, Inc. Finally, Roy Fielding restructured
the entire draft into its current form.
Special thanks to the many active participants in the HTML working
group, too numerous to list individually, without whom there would be
no standards process and no standard. That this document approaches
its objective of carefully converging a description of current
practice and formalization of HTML's relationship to SGML is a
tribute to their effort.
12.1. Authors' Addresses
Tim Berners-Lee
Director, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Phone: +1 (617) 253 9670
Fax: +1 (617) 258 8682
EMail: timbl@w3.org
Daniel W. Connolly
Research Technical Staff, W3 Consortium
MIT Laboratory for Computer Science
545 Technology Square
Cambridge, MA 02139, U.S.A.
Phone: +1 (617) 258 8682
EMail: connolly@w3.org
URI: http://www.w3.org/hypertext/WWW/People/Connolly/
Berners-Lee & Connolly Standards Track [Page 71]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
13. The HTML Coded Character Set This list details the code positions and characters of the HTML document character set, specified in 9.5, "SGML Declaration for HTML". This coded character set is based on [ISO-8859-1].La RFC 1866 écrite en ASCII, ne propose pas un rendu des caractères dont elle donne les positions. Il n'y a dans la suite de la RFC 1866 que les deux colonnes REFERENCE et DESCRIPTION. Nous avons choisi d'ajouter une colonne DISPLAYED ON YOUR UA AS pour que vous puissiez voir comment votre UA affiche ces caractères. Chaque caractère en question est entre "[]".
continued from RFC 1866...
REFERENCE DESCRIPTION DISPLAYED ON YOUR UA AS
-------------- ----------- ------------------[ ]---
� -  Unused
	 Horizontal tab [ ]
Line feed [
]
 -  Unused
Carriage Return [
]
 -  Unused
  Space [ ]
! Exclamation mark [!]
" Quotation mark ["]
# Number sign [#]
$ Dollar sign [$]
% Percent sign [%]
& Ampersand [&]
' Apostrophe [']
( Left parenthesis [(]
) Right parenthesis [)]
* Asterisk [*]
+ Plus sign [+]
, Comma [,]
- Hyphen [-]
. Period (fullstop) [.]
/ Solidus (slash) [/]
0 - 9 Digits 0-9 [0 - 9]
: Colon [:]
; Semi-colon [;]
< Less than [<]
= Equals sign [=]
> Greater than [>]
? Question mark [?]
@ Commercial at [@]
A - Z Letters A-Z [A - Z]
[ Left square bracket [[]
\ Reverse solidus (backslash) [\]
] Right square bracket []]
^ Caret [^]
_ Horizontal bar (underscore) [_]
` Acute accent [`]
a - z Letters a-z [a - z]
{ Left curly brace [{]
| Vertical bar [|]
Berners-Lee & Connolly Standards Track [Page 72]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
} Right curly brace [}]
~ Tilde [~]
 - Ÿ Unused
  Non-breaking Space [ ]
¡ Inverted exclamation [¡]
¢ Cent sign [¢]
£ Pound sterling [£]
¤ General currency sign [¤]
¥ Yen sign [¥]
¦ Broken vertical bar [¦]
§ Section sign [§]
¨ Umlaut (dieresis) [¨]
© Copyright [©]
ª Feminine ordinal [ª]
« Left angle quote, guillemotleft [«]
¬ Not sign [¬]
­ Soft hyphen []
® Registered trademark [®]
¯ Macron accent [¯]
° Degree sign [°]
± Plus or minus [±]
² Superscript two [²]
³ Superscript three [³]
´ Acute accent [´]
µ Micro sign [µ]
¶ Paragraph sign [¶]
· Middle dot [·]
¸ Cedilla [¸]
¹ Superscript one [¹]
º Masculine ordinal [º]
» Right angle quote, guillemotright [»]
¼ Fraction one-fourth [¼]
½ Fraction one-half [½]
¾ Fraction three-fourths [¾]
¿ Inverted question mark [¿]
À Capital A, grave accent [À]
Á Capital A, acute accent [Á]
 Capital A, circumflex accent [Â]
à Capital A, tilde [Ã]
Ä Capital A, dieresis or umlaut mark [Ä]
Å Capital A, ring [Å]
Æ Capital AE dipthong (ligature) [Æ]
Ç Capital C, cedilla [Ç]
È Capital E, grave accent [È]
É Capital E, acute accent [É]
Ê Capital E, circumflex accent [Ê]
Ë Capital E, dieresis or umlaut mark [Ë]
Ì Capital I, grave accent [Ì]
Berners-Lee & Connolly Standards Track [Page 73]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
Í Capital I, acute accent [Í]
Î Capital I, circumflex accent [Î]
Ï Capital I, dieresis or umlaut mark [Ï]
Ð Capital Eth, Icelandic [Ð]
Ñ Capital N, tilde [Ñ]
Ò Capital O, grave accent [Ò]
Ó Capital O, acute accent [Ó]
Ô Capital O, circumflex accent [Ô]
Õ Capital O, tilde [Õ]
Ö Capital O, dieresis or umlaut mark [Ö]
× Multiply sign [×]
Ø Capital O, slash [Ø]
Ù Capital U, grave accent [Ù]
Ú Capital U, acute accent [Ú]
Û Capital U, circumflex accent [Û]
Ü Capital U, dieresis or umlaut mark [Ü]
Ý Capital Y, acute accent [Ý]
Þ Capital THORN, Icelandic [Þ]
ß Small sharp s, German (sz ligature) [ß]
à Small a, grave accent [à]
á Small a, acute accent [á]
â Small a, circumflex accent [â]
ã Small a, tilde [ã]
ä Small a, dieresis or umlaut mark [ä]
å Small a, ring [å]
æ Small ae dipthong (ligature) [æ]
ç Small c, cedilla [ç]
è Small e, grave accent [è]
é Small e, acute accent [é]
ê Small e, circumflex accent [ê]
ë Small e, dieresis or umlaut mark [ë]
ì Small i, grave accent [ì]
í Small i, acute accent [í]
î Small i, circumflex accent [î]
ï Small i, dieresis or umlaut mark [ï]
ð Small eth, Icelandic [ð]
ñ Small n, tilde [ñ]
ò Small o, grave accent [ò]
ó Small o, acute accent [ó]
ô Small o, circumflex accent [ô]
õ Small o, tilde [õ]
ö Small o, dieresis or umlaut mark [ö]
÷ Division sign [÷]
ø Small o, slash [ø]
ù Small u, grave accent [ù]
ú Small u, acute accent [ú]
û Small u, circumflex accent [û]
ü Small u, dieresis or umlaut mark [ü]
Berners-Lee & Connolly Standards Track [Page 74]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
ý Small y, acute accent [ý]
þ Small thorn, Icelandic [þ]
ÿ Small y, dieresis or umlaut mark [ÿ]
Voici à présent les entités proposées pour émuler, de manière plus
lisible, les caractères ci-dessus qui ont un indice supérieur à 128. Le travail
sur UNICODE définit un nombre impressionnant d'entités, ce qui constitue la
véritable référence. Il existe quelques contradictions entre ce qui suit et
UNICODE, en ce qui concerne les différents guillemets.
continued from RFC 1866...
14. Proposed Entities
The HTML DTD references the "Added Latin 1" entity set, which only
supplies named entities for a subset of the non-ASCII characters in
[ISO-8859-1], namely the accented characters. The following entities
should be supported so that all ISO 8859-1 characters may only be
referenced symbolically. The names for these entities are taken from
the appendixes of [SGML].
<!ENTITY nbsp CDATA " " -- no-break space -->
<!ENTITY iexcl CDATA "¡" -- inverted exclamation mark -->
<!ENTITY cent CDATA "¢" -- cent sign -->
<!ENTITY pound CDATA "£" -- pound sterling sign -->
<!ENTITY curren CDATA "¤" -- general currency sign -->
<!ENTITY yen CDATA "¥" -- yen sign -->
<!ENTITY brvbar CDATA "¦" -- broken (vertical) bar -->
<!ENTITY sect CDATA "§" -- section sign -->
<!ENTITY uml CDATA "¨" -- umlaut (dieresis) -->
<!ENTITY copy CDATA "©" -- copyright sign -->
<!ENTITY ordf CDATA "ª" -- ordinal indicator, feminine -->
<!ENTITY laquo CDATA "«" -- angle quotation mark, left -->
<!ENTITY not CDATA "¬" -- not sign -->
<!ENTITY shy CDATA "­" -- soft hyphen -->
<!ENTITY reg CDATA "®" -- registered sign -->
<!ENTITY macr CDATA "¯" -- macron -->
<!ENTITY deg CDATA "°" -- degree sign -->
<!ENTITY plusmn CDATA "±" -- plus-or-minus sign -->
<!ENTITY sup2 CDATA "²" -- superscript two -->
<!ENTITY sup3 CDATA "³" -- superscript three -->
<!ENTITY acute CDATA "´" -- acute accent -->
<!ENTITY micro CDATA "µ" -- micro sign -->
<!ENTITY para CDATA "¶" -- pilcrow (paragraph sign) -->
<!ENTITY middot CDATA "·" -- middle dot -->
<!ENTITY cedil CDATA "¸" -- cedilla -->
<!ENTITY sup1 CDATA "¹" -- superscript one -->
<!ENTITY ordm CDATA "º" -- ordinal indicator, masculine -->
<!ENTITY raquo CDATA "»" -- angle quotation mark, right -->
<!ENTITY frac14 CDATA "¼" -- fraction one-quarter -->
<!ENTITY frac12 CDATA "½" -- fraction one-half -->
<!ENTITY frac34 CDATA "¾" -- fraction three-quarters -->
<!ENTITY iquest CDATA "¿" -- inverted question mark -->
<!ENTITY Agrave CDATA "À" -- capital A, grave accent -->
<!ENTITY Aacute CDATA "Á" -- capital A, acute accent -->
<!ENTITY Acirc CDATA "Â" -- capital A, circumflex accent -->
Berners-Lee & Connolly Standards Track [Page 75]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ENTITY Atilde CDATA "Ã" -- capital A, tilde -->
<!ENTITY Auml CDATA "Ä" -- capital A, dieresis or umlaut mark -->
<!ENTITY Aring CDATA "Å" -- capital A, ring -->
<!ENTITY AElig CDATA "Æ" -- capital AE diphthong (ligature) -->
<!ENTITY Ccedil CDATA "Ç" -- capital C, cedilla -->
<!ENTITY Egrave CDATA "È" -- capital E, grave accent -->
<!ENTITY Eacute CDATA "É" -- capital E, acute accent -->
<!ENTITY Ecirc CDATA "Ê" -- capital E, circumflex accent -->
<!ENTITY Euml CDATA "Ë" -- capital E, dieresis or umlaut mark -->
<!ENTITY Igrave CDATA "Ì" -- capital I, grave accent -->
<!ENTITY Iacute CDATA "Í" -- capital I, acute accent -->
<!ENTITY Icirc CDATA "Î" -- capital I, circumflex accent -->
<!ENTITY Iuml CDATA "Ï" -- capital I, dieresis or umlaut mark -->
<!ENTITY ETH CDATA "Ð" -- capital Eth, Icelandic -->
<!ENTITY Ntilde CDATA "Ñ" -- capital N, tilde -->
<!ENTITY Ograve CDATA "Ò" -- capital O, grave accent -->
<!ENTITY Oacute CDATA "Ó" -- capital O, acute accent -->
<!ENTITY Ocirc CDATA "Ô" -- capital O, circumflex accent -->
<!ENTITY Otilde CDATA "Õ" -- capital O, tilde -->
<!ENTITY Ouml CDATA "Ö" -- capital O, dieresis or umlaut mark -->
<!ENTITY times CDATA "×" -- multiply sign -->
<!ENTITY Oslash CDATA "Ø" -- capital O, slash -->
<!ENTITY Ugrave CDATA "Ù" -- capital U, grave accent -->
<!ENTITY Uacute CDATA "Ú" -- capital U, acute accent -->
<!ENTITY Ucirc CDATA "Û" -- capital U, circumflex accent -->
<!ENTITY Uuml CDATA "Ü" -- capital U, dieresis or umlaut mark -->
<!ENTITY Yacute CDATA "Ý" -- capital Y, acute accent -->
<!ENTITY THORN CDATA "Þ" -- capital THORN, Icelandic -->
<!ENTITY szlig CDATA "ß" -- small sharp s, German (sz ligature) -->
<!ENTITY agrave CDATA "à" -- small a, grave accent -->
<!ENTITY aacute CDATA "á" -- small a, acute accent -->
<!ENTITY acirc CDATA "â" -- small a, circumflex accent -->
<!ENTITY atilde CDATA "ã" -- small a, tilde -->
<!ENTITY auml CDATA "ä" -- small a, dieresis or umlaut mark -->
<!ENTITY aring CDATA "å" -- small a, ring -->
<!ENTITY aelig CDATA "æ" -- small ae diphthong (ligature) -->
<!ENTITY ccedil CDATA "ç" -- small c, cedilla -->
<!ENTITY egrave CDATA "è" -- small e, grave accent -->
<!ENTITY eacute CDATA "é" -- small e, acute accent -->
<!ENTITY ecirc CDATA "ê" -- small e, circumflex accent -->
<!ENTITY euml CDATA "ë" -- small e, dieresis or umlaut mark -->
<!ENTITY igrave CDATA "ì" -- small i, grave accent -->
<!ENTITY iacute CDATA "í" -- small i, acute accent -->
<!ENTITY icirc CDATA "î" -- small i, circumflex accent -->
<!ENTITY iuml CDATA "ï" -- small i, dieresis or umlaut mark -->
<!ENTITY eth CDATA "ð" -- small eth, Icelandic -->
<!ENTITY ntilde CDATA "ñ" -- small n, tilde -->
<!ENTITY ograve CDATA "ò" -- small o, grave accent -->
Berners-Lee & Connolly Standards Track [Page 76]
RFC 1866 Hypertext Markup Language - 2.0 November 1995
<!ENTITY oacute CDATA "ó" -- small o, acute accent -->
<!ENTITY ocirc CDATA "ô" -- small o, circumflex accent -->
<!ENTITY otilde CDATA "õ" -- small o, tilde -->
<!ENTITY ouml CDATA "ö" -- small o, dieresis or umlaut mark -->
<!ENTITY divide CDATA "÷" -- divide sign -->
<!ENTITY oslash CDATA "ø" -- small o, slash -->
<!ENTITY ugrave CDATA "ù" -- small u, grave accent -->
<!ENTITY uacute CDATA "ú" -- small u, acute accent -->
<!ENTITY ucirc CDATA "û" -- small u, circumflex accent -->
<!ENTITY uuml CDATA "ü" -- small u, dieresis or umlaut mark -->
<!ENTITY yacute CDATA "ý" -- small y, acute accent -->
<!ENTITY thorn CDATA "þ" -- small thorn, Icelandic -->
<!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark -->
Vous avez vraiment lu jusqu'ici ? Félicitations !
Que faire maintenant ? Vous pouvez bien sûr envoyer vos commentaires à l'auteur du guide. Vous pouvez surtout exercer votre nouveau savoir sur d'autres DTD. Allez lire également la documentation connexe dont la liste est donnée en début de ce document (section E). Fréquentez également les différents groupes de discussion et listes de diffusion concernant HTML. Enfin, vous pourrez suivre de près, et en connoisseur, les différentes étapes de normalisation en cours au sein du W3Consortium .
Bonnes lectures...