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.
HTML has been in use by the World-Wide Web (WWW) global information initiative since 1990. This specification corresponds to the capabilities of HTML in common use prior to June 1994 and referred to as "HTML 2.0".
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.
This specification governs the syntax of HTML documents and the behaviour of HTML user agents.
A document is a conforming HTML document only if:
The HTML DTD defines a standard HTML document type and several variations, based on feature test entities:
An HTML user agent conforms to this specification if:
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 section 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.
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.
The first production of the SGML 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.
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.
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 section 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:
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' (section HTML DTD). Hence the terminals above parse as:
HTML | \-HEAD | | | \-TITLE | | | \-<TITLE> | | | \-"Parsing Example" | | | \-</TITLE> | \-BODY | \-P | \-<P> | \-"Some text. " | \-EM | | | \-<EM> | | | \-"*wow*" | | | \-</EM> | \-</P>
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), all HTML documents use the reference concrete syntax. In particular, all markup characters are in the repertoire of ISO 646 IRV. Data characters are drawn from the document character set (see section Characters, Words, and Paragraphs).
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.
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 also map to single-character strings, via the document character set. Each reference to one of the general entities defined in the HTML DTD also maps to a single-character string.
For example,
abc<def => "abc","<","def" abc<def => "abc","<","def"
Note that the terminating semicolon is only necessary when the character following the reference would otherwise be recognized as markup:
abc < def => "abc ","<"," def" abc < def => "abc ","<"," def"
And note that 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"
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
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, you 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, section HTML DTD for full details. (6)
A name consists of a letter followed by up to 71 letters, digits, periods, or hyphens. Element 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 `<'.
In a start-tag, white space and attributes are allowed between the element name and the closing delimiter. An attribute typically consists of an attribute name, an equal sign, and a value, though some attributes may be just a value. White space is allowed around the equal sign.
The value of the attribute may be either:
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 space character by an entity reference or numeric character reference as follows:
ENTITY NUMERIC CHARACTER REFERENCE CHAR REF CHARACTER DESCRIPTION TAB 	 Tab LF Line Feed CR Carriage Return   Space " " " Quotation mark & & & Ampersand
For example:
<IMG SRC="image.jpg" alt="First "real" example">
Note that the SGML declaration in section 13.3 limits the length of an attribute value to 1024 characters.
Attributes such as ISMAP and COMPACT may be written using a minimized syntax. The markup:
<UL COMPACT="compact">
can be written using a minimized syntax:
<UL COMPACT>
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. (10)
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 ->
To identify information as an HTML document conforming to this specification, each document should 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 section HTML DTD. (11)
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0 Level 2//EN">
This document type declaration also refers to the HTML DTD which appears in section 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 section Strict 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 section Strict HTML DTD and section Strict Level 1 HTML DTD. They refer to the more structurally rigid definition of HTML.
HTML user agents not required to support other document types, but they may. 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, or they may not.
<!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 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>
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). Conforming HTML user agents should support form entry and submission.
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].
The optional parameters are defined as follows:
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.
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. 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 other hand, references to undeclared entities and undefined numeric character references (i.e. references to code positions that are not in the domain of the document character set) should be treated as data characters.
For example:
<div class=chapter><h1>foo</h1><p>...</div> => <H1>,"foo",</H1>,<P>,"..." xxx <P ID=z23> yyy => "xxx ",<P>," yyy Let α, β and 𒭧 be finite sets. => "Let α, β and &76647; 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 is not conforming to this specification.
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 10, 13.
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.
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 the URI specification 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 section Input Field: INPUT) -- should be aware and make their users aware of the lack of confidentiality.
An HTML document is a hierarchy of elements.
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 other optional elements. The body is a text flow consisting of paragraphs, lists, and other elements.
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> ...
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. (12)
A user agent may display the title of a document in a history list or as a label for the window displaying the document. Contrast with headings (section Headings: H1 ... H6), which are typically displayed with the body text flow.
The optional BASE element specifies the URI of the document, overriding any context otherwise known to the user agent. The required HREF attribute specifies the URI for navigating the document (see section Hyperlinks). The value of the HREF attribute must be an absolute URI.
The ISINDEX element indicates that the user agent should allow the user to search an index by giving keywords. See section Queries and Indexes for details.
The LINK element represents a hyperlink (see section Hyperlinks). It has the same attributes as the A element (see section Anchor: A).
The LINK element is typically used to indicate authorship, related indexes and glossaries, older or more recent versions, stylesheets, document hierarchy etc.
The META element is an extensible container for use in identifying, indexing, and cataloging specialized document metainformation. Metainformation has two main functions:
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. (13)
HTTP servers should read the content of the document HEAD to generate header fields corresponding to any elements defining a value for the attribute HTTP-EQUIV. (14)
Attributes of the META element:
Examples
If the document contains:
<META HTTP-EQUIV="Expires" CONTENT="Tue, 04 Dec 1993 21:29:02 GMT"> <meta http-equiv="Keywords" CONTENT="Fred, Barney"> <META HTTP-EQUIV="Reply-to" content="fielding@ics.uci.edu (Roy Fielding)">
then the server should 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.
When the HTTP-EQUIV attribute is not present, the server should not generate an HTTP response header for the metainformation; e.g.,
Do not name an HTTP-EQUIV equal to a response header that should normally only be generated by the HTTP server. Example names that are inappropriate include `Server', `Date', and `Last-modified' -- the exact list of inappropriate names is dependent on the particular server implementation.
They NEXTID element gives a hint for the name to use for an A element when editing an HTML document. It should be distinct from all NAME attribute values on A elements. For example:
<NEXTID N=Z27>
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>
The six heading elements, H1 through H6, denote section headings. Although the order and occurence 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.
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:
Each of the following elements defines a block structure; that is, they indicate a paragraph break before and after.
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>
The PRE element represents a character cell block of text and so is suitable for text that has been formatted on screen.
The PRE tag may be used with the optional WIDTH attribute. The WIDTH attribute specifies the maximum number of characters for a line and allows the HTML user agent to select a suitable font and indentation.
Within preformatted text:
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>
The XMP and LISTING elements are deprectated in favor of the PRE element (see section Preformatted Text: PRE), as their declaration makes use of `CDATA' declared content, which tends to be implemented and used inconsistently. (18)
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. (19)
The ADDRESS element specifies 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, Jumquick, CT 01234<BR> Tel (123) 456 7890 </ADDRESS>
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 poem ends <BLOCKQUOTE> <P>Soft you now, the fair Ophelia. Nymph, in thy orisons, be all my sins remembered. </BLOCKQUOTE> but I am not sure.
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 UL represents a list of items with no inherent ordering -- typically 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>
The UL element represents an ordered list of items, sorted by sequence or order of importance.
The content of a OL element is a sequence of LI elements. For example:
<OL> <LI>Click the Web button to open the Open the 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>
The COMPACT attribute suggests that a compact rendering be used.
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 OL 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>
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>
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.
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>
If the DT term does not fit in the DT column (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>
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 indistinctly from non-nested elements:
plain <B>bold <I>italic</I></B> may the rendered the same as plain <B>bold </B><I>italic</I>
Phrases may be marked up to indicate certain idioms. (20)
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>.
The CODE element indicates an example of code, typically rendered in a monospaced font. Contrast with the PRE block structuring element in section Preformatted Text: PRE. For example:
The expression <code>x += 1</code> is short for <code>x = x + 1</code>.
The EM element indicates an emphasized phrase, typically rendered as italics. For example:
A singular subject <em>always</em> takes a singular verb.
The Keyboard element indicates text typed by a user, typically rendered in a monospaced font. This is commonly used in instruction manuals. For example:
Enter <kbd>FIND IT</kbd> to search the database.
The SAMP element indicates a sequence of literal characters, typically rendered in a monospaced font. For example:
The only word containing the letters <samp>mt</samp> is dreamt.
The STRONG element indicates strong emphasis, typically rendered in bold. For example:
<strong>STOP</strong>, or I'll say "<strong>STOP</strong>" again!.
The VAR element indicates a placeholder, typically rendered as italic. For example:
Take a guess: Roses are <var>blank</var>.
Typographic elements are used to specify the format of marked text.
Typical renderings for idomatic elements 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.
The B element indicates bold text. Where bold typography is unavailable, an alternative representation may be used.
The I element indicates italic text. Where italic typography is unavailable, an alternative representation may be used.
The TT element indicates typewriter text. Where a typewriter font is unavailable, an alternative representation may be used.
The A element indicates a hyperlink anchor (see section Hyperlinks). At least one of the NAME and HREF attributes should be present. Attributes of the A element:
The BR element specifies a line break between words (see section Characters, Words, and Paragraphs). For example:
<P> Pease porridge hot<BR> Pease porridge cold<BR> Pease porridge in the pot<BR> Nine days old.
The HR element is a divider between sections of text; typcially a full width horizontal rule or equivalent graphic. For example:
<HR> <ADDRESS>February 8, 1995, CERN</ADDRESS> </BODY>
The IMG element refers to an image or icon via a hyperlink (see section 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. (22)
Attributes of the IMG element:
Examples of use:
<IMG SRC="triangle.xbm" ALT="Warning:"> Be sure to read these instructions.
<IMG SRC="triangle.xbm">Be sure to read these instructions.
<a href="http://machine/htbin/imagemap/sample"> <IMG SRC="sample.xbm" ISMAP> </a>
An HTML user agent should present the body of an HTML document as a collection of typeset paragraphs and preformatted text. Except for the PRE element, each block structuring element is regarded as a paragraph by taking the 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.
The minimum character repertoire supported by all conforming HTML user agents is Latin Alphabet No. 1, or simply Latin-1. Latin-1 includes characters from most Western European languages, as well as a number of control characters. Latin-1 also includes a non-breaking space, a soft hyphen indicator, 93 graphical characters, 8 unassigned characters, and 25 control characters. (24) (25)
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 HTML, only three control characters are allowed: Horizontal Tab, Carriage Return, and Line Feed (code positions 9, 13, and 10 in ISO 8859-1).
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 section ISO Latin 1 Character Entity Set for a table of the "Added Latin 1" entities, and section The ANSI/ISO 8859-1 Coded Character Set for a table of the code positions of ANSI/ISO 8859-1.
In addition to general purpose elements such as paragraphs and lists, HTML documents can express hyperlinks. A hyperlink is a relationship between two anchors, called the head and the tail of the hyperlink[DEXTER]. An anchor is a resource such as an HTML document, or some fragment of, i.e. view on or portion of a resource.
Anchors are addressed by Uniform Resource Identifiers (URI). URIs either refer directly to an anchor in absolute form for example as in [URL], or they refer to an anchor relative to a base URI which is absolute, as in [RELURL].
Each of the following markup constructs indicates the tail anchor of a hyperlink or set of hyperlinks:
To access the head anchor of a hyperlink, the user agent determines its URI from the URI given in the tail anchor, using the base URI of the document containing the head anchor if necessary. Any fragment identifier is discarded, and the result is used to access a resource, for example as in [URL].
For example, if a document identified as `http://host/x/y.html' contains:
<img src="../icons/abc.gif">
then the user agent must use the URI `http://host/icons/abc.gif' to access the resource linked from the IMG element.
An HTML user agent allows the user to navigate the content of the document and request activation of A element hyperlinks. A request to activate a link is essentially a request to process the resource indicated by the head anchor of the link, for example to display the indicated HTML document. HTML user agents should also allow activation of LINK element hyperlinks.
The base URI for navigating the head anchor may be different from the URI used to access it. For example, it may be replaced by by a BASE tag in the destination document or by an HTTP redirection transaction.
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 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.
Any characters following a `#' character in a URI constitute a fragment identifier. As a degenerate case, a URI of the form `#fragment' refers to an anchor in the same document.
The meaning of fragment identifiers depends on the media type of the resource containing the head anchor. For `text/html' resources, 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 a user agent was processing a document identified as `http://host/x/y.html' and the user indicated the following anchor:
<p> See: <a href="app1.html#bananas">appendix 1</a> for more detail on bananas.
then the user agent URI must access the resource `http://host/x/app1.html'. Assuming the resource is represented using the `text/html' media type, the user agent must locate the anchor named `bananas' and begin navigation there.
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 section Query Forms: METHOD=GET for details.
The ISMAP attribute in combination with the A and IMG elements, 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, then chosen hyperlink is the one with the URI `http://host/cgi-bin/imagemap?0,0'.
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.
The FORM element contains a sequence of input elements, along with document structuring elements. The attributes are:
The INPUT element represents a field for user input. Attributes are:
The SELECT element constrains the form field to an enumerated list of values. The values are given in OPTION elements. Attributes are:
For example:
<SELECT NAME="flavor"> <OPTION>Vanilla <OPTION>Strawberry <OPTION>Rum and Raisin <OPTION>Peach and Orange </SELECT>
The initial state has the first option selected, unless a SELECTED attribute is present on any of the OPTION elements.
The Option element can only occur within a Select element. It represents one choice, and has the following attributes:
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.
The TEXTAREA element represents a multi-line text field. Attrubutes are:
For example:
<TEXTAREA NAME="address" ROWS=64 COLS=6> 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.
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.
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.
The default encoding for all forms is `application/x-www-form-urlencoded'. A form data set is represented in this media type as follows:
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.
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 section Activation of Hyperlinks). (27)
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.
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>
The inital state of the form data set is:
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:
The user agent then conducts an HTTP POST transaction using the URI `http://www.w3.org/sample'. The message body would be (ignore the linebreak):
name=John+Doe&gender=male&family=5&city=kent%2Cmiami& other=abc%0D%0Adef&nickname=J%26D
This is the Document Type Definition for the HyperText Markup Language, level 2.
<!-- html.dtd Document Type Definition for the HyperText Markup Language (HTML DTD) $Id: html.dtd,v 1.26 1995/06/02 08:00:02 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> -- > <!--============ 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"> ]]> <!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 an 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 --> <!ENTITY % URI "CDATA" -- The term URI means a CDATA attribute whose value is a Uniform Resource Identifier, as defined by "Universal Resource Identifiers" by Tim Berners-Lee aka RFC 1630 Note that CDATA attributes are limited by the LITLEN capacity (1024 in the current version of html.decl), so that URIs in HTML have a bounded length. --> <!--========= DTD "Macros" =====================--> <!ENTITY % heading "H1|H2|H3|H4|H5|H6"> <!ENTITY % list " UL | OL | DIR | MENU " > <!--======= Character mnemonic entities =================--> <!ENTITY % ISOlat1 PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML"> %ISOlat1; <!ENTITY amp CDATA "&" -- ampersand --> <!ENTITY gt CDATA ">" -- greater than --> <!ENTITY lt CDATA "<" -- less than --> <!ENTITY quot CDATA """ -- double quote --> <!--========= 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 [ <!ENTITY % font " TT | B | I "> <!ENTITY % phrase "EM | STRONG | CODE | SAMP | KBD | VAR | CITE "> <!ENTITY % text "#PCDATA | A | IMG | BR | %phrase | %font"> <!ELEMENT (%font;|%phrase) - - (%text)*> <!ATTLIST ( TT | CODE | SAMP | KBD | VAR ) %SDAFORM; "Lit" > <!ATTLIST ( B | STRONG ) %SDAFORM; "B" > <!ATTLIST ( I | EM | CITE ) %SDAFORM; "It" > <!-- <TT> Typewriter text --> <!-- <B> Bold text --> <!-- <I> Italic text --> <!-- <EM> Emphasized phrase --> <!-- <STRONG> Strong emphais --> <!-- <CODE> Source code phrase --> <!-- <SAMP> Sample text or characters --> <!-- <KBD> Keyboard phrase, e.g. user input --> <!-- <VAR> Variable phrase or substituable --> <!-- <CITE> Name or title of cited work --> <!ENTITY % pre.content "#PCDATA | A | HR | BR | %font | %phrase"> ]]> <!ENTITY % text "#PCDATA | A | IMG | BR"> <!ELEMENT BR - O EMPTY> <!ATTLIST BR %SDAPREF; "&#RE;" > <!-- <BR> Line break --> <!--========= Link Markup ======================--> <![ %HTML.Recommended [ <!ENTITY % linkName "ID"> ]]> <!ENTITY % linkName "CDATA"> <!ENTITY % linkType "NAME" -- a list of these will be specified at a later date --> <!ENTITY % linkExtraAttributes "REL %linkType #IMPLIED REV %linkType #IMPLIED URN CDATA #IMPLIED TITLE CDATA #IMPLIED METHODS NAMES #IMPLIED "> <![ %HTML.Recommended [ <!ENTITY % A.content "(%text)*" -- <H1><a name="xxx">Heading</a></H1> is preferred to <a name="xxx"><H1>Heading</H1></a> --> ]]> <!ENTITY % A.content "(%heading|%text)*"> <!ELEMENT A - - %A.content -(A)> <!ATTLIST A HREF %URI #IMPLIED NAME %linkName #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) --> <!--========== Images ==========================--> <!ELEMENT IMG - O EMPTY> <!ATTLIST IMG SRC %URI; #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 --> <!--========== Paragraphs=======================--> <!ELEMENT P - O (%text)*> <!ATTLIST P %SDAFORM; "Para" > <!-- <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"> <![ %HTML.Deprecated [ <!ENTITY % preformatted "PRE | XMP | LISTING"> ]]> <!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" > <!-- <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" > ]]> <!--========== 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 --> <!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>" > <!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)*"> <!ELEMENT BODY O O %body.content> <!-- <BODY> Document body --> <!ELEMENT BLOCKQUOTE - - %body.content> <!ATTLIST BLOCKQUOTE %SDAFORM; "BQ" > <!-- <BLOCKQUOTE> Quoted passage --> <!ELEMENT ADDRESS - - (%text|P)*> <!ATTLIST ADDRESS %SDAFORM; "Lit" %SDAPREF; "Address:&#RE;" > <!-- <ADDRESS> Address, signature, or byline --> <!--======= Forms ====================--> <![ %HTML.Forms [ <!ELEMENT FORM - - %body.content -(FORM) +(INPUT|SELECT|TEXTAREA)> <!ATTLIST FORM ACTION %URI #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 --> <!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 %URI #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 --> <!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 --> ]]> <!--======= Document Head ======================--> <![ %HTML.Recommended [ <!ENTITY % head.extra "META* & LINK*"> ]]> <!ENTITY % head.extra "NEXTID? & META* & LINK*"> <!ENTITY % head.content "TITLE & ISINDEX? & BASE? & (%head.extra)"> <!ELEMENT HEAD O O (%head.content)> <!-- <HEAD> Document head --> <!ELEMENT TITLE - - (#PCDATA)*> <!ATTLIST TITLE %SDAFORM; "Ti" > <!-- <TITLE> Title of document --> <!ELEMENT LINK - O EMPTY> <!ATTLIST LINK HREF %URI #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 %URI; #REQUIRED > <!-- <BASE> Base context document --> <!-- <BASE HREF="..."> Address for this document --> <!ELEMENT NEXTID - O EMPTY> <!ATTLIST NEXTID N %linkName #REQUIRED > <!-- <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 Metainformation --> <!-- <META HTTP-EQUIV=...> HTTP response header name --> <!-- <META NAME=...> Metainformation 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 -->
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 --> <!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;
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> -- > <!-- Feature Test Entities --> <!ENTITY % HTML.Forms "IGNORE"> <!ENTITY % html PUBLIC "-//IETF//DTD HTML 2.0//EN"> %html;
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;
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 "" 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 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.16 1995/06/02 08:00:01 connolly Exp $ Author: Daniel W. Connolly <connolly@w3.org> See also: http://www.w3.org/hypertext/WWW/MarkUp/MarkUp.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 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 indentifier. For example, the following are possible catalog entries:
-- catalog: SGML Open style entity catalog for HTML -- -- $Id: catalog,v 1.2 1994/11/30 23:45:18 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 Level 0: most general to most specific -- PUBLIC "-//IETF//DTD HTML Level 0//EN" html-0.dtd PUBLIC "-//IETF//DTD HTML 2.0 Level 0//EN" html-0.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 -- Ways to refer to Strict Level 0: most general to most specific -- PUBLIC "-//IETF//DTD HTML Strict Level 0//EN" html-0s.dtd PUBLIC "-//IETF//DTD HTML 2.0 Strict Level 0//EN" html-0s.dtd -- ISO latin 1 entity set for HTML -- PUBLIC "ISO 8879-1986//ENTITIES Added Latin 1//EN//HTML" ISOlat1.sgml
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 the writer.
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 sign & amp & Ampersand " quot " Double quote sign
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 --> <!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 --> <!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 -->
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.
Director, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. Tel: +1 (617) 253 9670 Fax: +1 (617) 258 8682 Email: timbl@w3.org
Research Technical Staff, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A. Fax: +1 (617) 258 8682 Email: connolly@w3.org URI: http://www.w3.org/hypertext/WWW/People/Connolly/
This list, sorted numerically, is derived from ANSI/ISO 8859-1 8-bit single-byte coded graphic character set:
REFERENCE DESCRIPTION � -  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 : Colon ; Semi-colon < Less than = Equals sign > Greater than ? Question mark @ Commercial at A - Z Letters A-Z [ Left square bracket \ Reverse solidus (backslash) ] Right square bracket ^ Caret _ Horizontal bar (underscore) ` Acute accent a - z Letters a-z { Left curly brace | Vertical bar } Right curly brace ~ Tilde  -   Unused ¡ 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 Í 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 ý Small y, acute accent þ Small thorn, Icelandic ÿ Small y, dieresis or umlaut mark
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 the remaining characters may only be referenced symbolically.
<!ENTITY yuml CDATA "ÿ" -- small y, dieresis or umlaut mark --> <!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 umlaut 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 trademark --> <!ENTITY macron 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 (centred decimal point) --> <!ENTITY cedilla CDATA "¸" -- cedilla accent --> <!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 times CDATA "×" -- multiply sign --> <!ENTITY divide CDATA "÷" -- divide sign -->