Author: Dave Raggett <[email protected]>
This document has been reviewed by W3C members and other interested parties and has been endorsed by the Director as a W3C Recommendation.
This specification is a Superseded Recommendation. A newer specification exists that is recommended for new adoption in place of this specification. New implementations should follow the latest version of the HTML specification.
A list of current W3C Recommendations and other technical documents can be found at https://www.w3.org/TR/.
The HyperText Markup Language (HTML) is a simple markup language 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 applications. This specification defines HTML version 3.2. HTML 3.2 aims to capture recommended practice as of early '96 and as such to be used as a replacement for HTML 2.0 (RFC 1866).
HTML 3.2 is W3C's specification for HTML, developed in early `96 together with vendors including IBM, Microsoft, Netscape Communications Corporation, Novell, SoftQuad, Spyglass, and Sun Microsystems. HTML 3.2 adds widely deployed features such as tables, applets and text flow around images, while providing full backwards compatibility with the existing standard HTML 2.0.
W3C is continuing to work with vendors on extensions for accessibility features, multimedia objects, scripting, style sheets, layout, forms, math and internationalization. W3C plans on incorporating this work in further versions of HTML.
HTML 3.2 is an SGML application conforming to International Standard ISO 8879 -- Standard Generalized Markup Language. As an SGML application, the syntax of conforming HTML 3.2 documents is defined by the combination of the SGML declaration and the document type definition (DTD). This specification defines the intended interpretation of HTML 3.2 elements, and places further constraints on the permitted syntax which are otherwise inexpressible in the DTD.
The SGML rules for record boundaries are tricky. In particular, a record end immediately following a start tag should be discarded. For example:
Text
is equivalent to:
Text
Similarly, a record end immediately preceding an end tag should be discarded. For example:
Text
is equivalent to:
Text
Except within literal text (e.g. the PRE element), HTML treats contiguous sequences of white space characters as being equivalent to a single space character (ASCII decimal 32). These rules allow authors considerable flexibility when editing the marked-up text directly. Note that future revisions to HTML may allow for the interpretation of the horizontal tab character (ASCII decimal 9) with respect to a tab rule defined by an associated style sheet.
SGML entities in PCDATA content or in CDATA attributes are expanded by the parser, e.g. é is expanded to the ISO Latin-1 character decimal 233 (a lower case letter e with an acute accent). This could also have been written as a named character entity, e.g. é. The & character can be included in its own right using the named character entity &.
HTML allows CDATA attributes to be unquoted provided the attribute value contains only letters (a to z and A to Z), digits (0 to 9), hyphens (ASCII decimal 45) or, periods (ASCII decimal 46). Attribute values can be quoted using double or single quote marks (ASCII decimal 34 and 39 respectively). Single quote marks can be included within the attribute value when the value is delimited by double quote marks, and vice versa.
Note that some user agents require attribute minimisation for the following attributes: COMPACT, ISMAP, CHECKED, NOWRAP, NOSHADE and NOHREF. These user agents don't accept syntax such as COMPACT=COMPACT or ISMAP=ISMAP although this is legitimate according to the HTML 3.2 DTD.
The SGML declaration and the DTD for use with HTML 3.2 are given in appendices. Further guidelines for parsing HTML are given in WD-html-lex.
HTML 3.2 Documents start with a declaration followed by an HTML element containing a HEAD and then a BODY element:
A study of population dynamics ... other head elements ... document body
In practice, the HTML, HEAD and BODY start and end tags can be omitted from the markup as these can be inferred in all cases by parsers conforming to the HTML 3.2 DTD.
Every conforming HTML 3.2 document must start with the declaration that is needed to distinguish HTML 3.2 documents from other versions of HTML. The HTML specification is not concerned with storage entities. As a result, it is not required that the document type declaration reside in the same storage entity (i.e. file). A Web site may choose to dynamically prepend HTML files with the document type declaration if it is known that all such HTML files conform to the HTML 3.2 specification.
Every HTML 3.2 document must also include the descriptive title element. A minimal HTML 3.2 document thus looks like:
A study of population dynamics
Note: the word "Final" replaces "Draft" now that the HTML 3.2 specification has been ratified by the W3C member organizations.
This contains the document head, but you can always omit both the start and end tags for HEAD. The contents of the document head is an unordered collection of the following elements:
The %head.misc entity is used to allow the associated elements to occur multiple times at arbitrary positions within the HEAD. The following elements can be part of the document head:
TITLE, SCRIPT and STYLE are containers and require both start and end tags. The other elements are not containers so that end tags are forbidden. Note that conforming browsers won't render the contents of SCRIPT and STYLE elements.
Every HTML 3.2 document must have exactly one TITLE element in the document's HEAD. It provides an advisory title which can be displayed in a user agent's window caption etc. The content model is PCDATA. As a result, character entities can be used for accented characters and to escape special characters such as & and <. Markup is not permitted in the content of a TITLE element.
Example TITLE element:
A study of population dynamics
These are place holders for the introduction of style sheets and client-side scripts in future versions of HTML. User agents should hide the contents of these elements.
These elements are defined with CDATA as the content type. As a result they may contain only SGML characters. All markup characters or delimiters are ignored and passed as data to the application, except for ETAGO ("
The ISINDEX element indicates that the user agent should provide a single line text input field for entering a query string. There are no restrictions on the number of characters that can be entered. The PROMPT attribute can be used to specify a prompt string for the input field, e.g.
The semantics for ISINDEX are currently well defined only when the base URL for the enclosing document is an HTTP URL. Typically, when the user presses the enter (return) key, the query string is sent to the server identified by the base URL for this document. For example, if the query string entered is "ten green apples" and the base URL is:
http://www.acme.com/
then the query generated is:
http://www.acme.com/?ten+green+apples"
Note that space characters are mapped to "+" characters and that normal URL character escaping mechanisms apply. For further details see the HTTP specification.
Note in practice, the query string is resticted to Latin-1 as there is no current mechanism for the URL to specify a character set for the query.
The BASE element gives the base URL for dereferencing relative URLs, using the rules given by the URL specification, e.g.
...
The image is deferenced to
http://www.acme.com/icons/logo.gif
In the absence of a BASE element the document URL should be used. Note that this is not necessarily the same as the URL used to request the document, as the base URL may be overridden by an HTTP header accompanying the document.
The META element can be used to include name/value pairs describing properties of the document, such as author, expiry date, a list of key words etc. The NAME attribute specifies the property name while the CONTENT attribute specifies the property value, e.g.
The HTTP-EQUIV attribute can be used in place of the NAME attribute and has a special significance when documents are retrieved via the Hypertext Transfer Protocol (HTTP). HTTP servers may use the property name specified by the HTTP-EQUIV attribute to create an RFC 822 style header in the HTTP response. This can't be used to set certain HTTP headers though, see the HTTP specification for details.
will result in the HTTP header:
Expires: Tue, 20 Aug 1996 14:25:27 GMT
This can be used by caches to determine when to fetch a fresh copy of the associated document.
LINK provides a media independent method for defining relationships with other documents and resources. LINK has been part of HTML since the very early days, although few browsers as yet take advantage of it (most still ignore LINK elements).
LINK elements can be used in principle:
Here are some proposed relationship values:
Example LINK elements:
This contains the document body. Both start and end tags for BODY may be omitted. The body can contain a wide range of elements:
The key attributes are: BACKGROUND, BGCOLOR, TEXT, LINK, VLINK and ALINK. These can be used to set a repeating background image, plus background and foreground colors for normal text and hypertext links.
Example:
Colors are given in the sRGB color space as hexadecimal numbers (e.g. COLOR="#C0FFC0"), or as one of 16 widely understood color names. These colors were originally picked as being the standard 16 colors supported with the Windows VGA palette.
 | Black = "#000000" |  | Green = "#008000" |
 | Silver = "#C0C0C0" |  | Lime = "#00FF00" |
 | Gray = "#808080" |  | Olive = "#808000" |
 | White = "#FFFFFF" |  | Yellow = "#FFFF00" |
 | Maroon = "#800000" |  | Navy = "#000080" |
 | Red = "#FF0000" |  | Blue = "#0000FF" |
 | Purple = "#800080" |  | Teal = "#008080" |
 | Fuchsia = "#FF00FF" |  | Aqua = "#00FFFF" |
Most elements that can appear in the document body fall into one of two groups: block level elements which cause paragraph breaks, and text level elements which don't. Common block level elements include H1 to H6 (headers), P (paragraphs) LI (list items), and HR (horizontal rules). Common text level elements include EM, I, B and FONT (character emphasis), A (hypertext links), IMG and APPLET (embedded objects) and BR (line breaks). Note that block elements generally act as containers for text level and other block level elements (excluding headings and address elements), while text level elements can only contain other text level elements. The exact model depends on the element.
H1, H2, H3, H4, H5 and H6 are used for document headings. You always need the start and end tags. H1 elements are more important than H2 elements and so on, so that H6 elements define the least important level of headings. More important headings are generally rendered in a larger font than less important ones. Use the optional ALIGN attribute to set the text alignment within a heading, e.g.
... centered heading ...
The default is left alignment, but this can be overridden by an enclosing DIV or CENTER element.
The ADDRESS element requires start and end tags, and specifies information such as authorship and contact details for the current document. User agents should render the content with paragraph-breaks before and after. Note that the content is restricted to paragraphs, plain text and text-like elements as defined by the %text entity.
Example:
Newsletter editor
J.R. Brown
8723 Buena Vista, Smallville, CT 01234
Tel: +1 (123) 456 7890
The P element is used to markup paragraphs. It is a container and requires a start tag. The end tag is optional as it can always be inferred by the parser. User agents should place paragraph breaks before and after P elements. The rendering is user agent dependent, but text is generally wrapped to fit the space available.
Example:
This is the first paragraph.
This is the second paragraph.
Paragraphs are usually rendered flush left with a ragged right margin. The ALIGN attribute can be used to explicitly specify the horizontal alignment:
For example:
This is a centered paragraph.
and this is a flush right paragraph.
The default is left alignment, but this can be overridden by an enclosing DIV or CENTER element.
List items can contain block and text level items, including nested lists, although headings and address elements are excluded. This limitation is defined via the %flow entity.
Unordered lists take the form:
The UL element is used for unordered lists. Both start and end tags are always needed. The LI element is used for individual list items. The end tag for LI elements can always be omitted. Note that LI elements can contain nested lists. The COMPACT attribute can be used as a hint to the user agent to render lists in a more compact style.
The TYPE attribute can be used to set the bullet style on UL and LI elements. The permitted values are "disc", "square" or "circle". The default generally depends on the level of nesting for lists.
This list was chosen to cater for the original bullet shapes used by Mosaic in 1993.
Ordered (i.e. numbered) lists take the form:
- ... first list item
- ... second list item ...
The OL START attribute can be used to initialize the sequence number (by default it is initialized to 1). You can set it later on with the VALUE attribute on LI elements. Both of these attributes expect integer values. You can't indicate that numbering should be continued from a previous list, or to skip missing values without giving an explicit number.
The COMPACT attribute can be used as a hint to the user agent to render lists in a more compact style. The OL TYPE attribute allows you to set the numbering style for list items:
| Type | Numbering style | |
|---|---|---|
| 1 | Arabic numbers | 1, 2, 3, ... |
| a | lower alpha | a, b, c, ... |
| A | upper alpha | A, B, C, ... |
| i | lower roman | i, ii, iii, ... |
| I | upper roman | I, II, III, ... |
Definition lists take the form:
DT elements can only act as containers for text level elements, while DD elements can hold block level elements as well, excluding headings and address elements.
For example:
which could be rendered as:
The COMPACT attribute can be used with the DL element as a hint to the user agent to render lists in a more compact style.
These elements have been part of HTML from the early days. They are intended for unordered lists similar to UL elements. User agents are recommended to render DIR elements as multicolumn directory lists, and MENU elements as single column menu lists. In practice, Mosaic and most other user agents have ignored this advice and instead render DIR and MENU in an identical way to UL elements.
The PRE element can be used to include preformatted text. User agents render this in a fixed pitch font, preserving spacing associated with white space characters such as space and newline characters. Automatic word-wrap should be disabled within PRE elements.
Note that the SGML standard requires that the parser remove a newline immediately following the start tag or immediately preceding the end tag.
PRE has the same content model as paragraphs, excluding images and elements that produce changes in font size, e.g. IMG, BIG, SMALL, SUB, SUP and FONT.
A few user agents support the WIDTH attribute. It provides a hint to the user agent of the required width in characters. The user agent can use this to select an appropriate font size or to indent the content appropriately.
Here is an example of a PRE element; a verse from Shelley (To a Skylark):
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
Higher still and higher
From the earth thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
The horizontal tab character (encoded in Unicode, US ASCII and ISO 8859-1 as decimal 9) should be interpreted as the smallest non-zero number of spaces which will leave the number of characters so far on the line as a multiple of 8. Its use is strongly discouraged since it is common practice when editing to set the tab-spacing to other values, leading to misaligned documents.
]]>
These are obsolete tags for preformatted text that predate the introduction of PRE. User agents may support these for backwards compatibility. Authors should avoid using them in new documents!
DIV elements can be used to structure HTML documents as a hierarchy of divisions. The ALIGN attribute can be used to set the default horizontal alignment for elements within the content of the DIV element. Its value is restricted to LEFT, CENTER or RIGHT, and is defined in the same way as for the paragraph element .
Note that because DIV is a block-like element it will terminate an open P element. Other than this, user agents are not expected to render paragraph breaks before and after DIV elements. CENTER is directly equivalent to DIV with ALIGN=CENTER. Both DIV and CENTER require start and end tags.
CENTER was introduced by Netscape before they added support for the HTML 3.0 DIV element. It is retained in HTML 3.2 on account of its widespread deployment.
This is used to enclose block quotations from other works. Both the start and end tags are required. It is often rendered indented, e.g.
They went in single file, running like hounds on a strong scent, and an eager light was in their eyes. Nearly due west the broad swath of the marching Orcs tramped its ugly slot; the sweet grass of Rohan had been bruised and blackened as they passed.
from "The Two Towers" by J.R.R. Tolkien.
This is used to define an HTML form, and you can have more than one form in the same document. Both the start and end tags are required. For very simple forms, you can also use the ISINDEX element. Forms can contain a wide range of HTML markup including several kinds of form fields such as single and multi-line text fields, radio button groups, checkboxes, and menus.
Further details on handling forms are given in RFC 1867.
Horizontal rules may be used to indicate a change in topic. In a speech based user agent, the rule could be rendered as a pause.
HR elements are not containers so the end tag is forbidden. The attributes are: ALIGN, NOSHADE, SIZE and WIDTH.
HTML 3.2 includes a widely deployed subset of the specification given in RFC 1942 and can be used to markup tabular material or for layout purposes. Note that the latter role typically causes problems when rending to speech or to text only user agents.
Tables take the general form:
| first cell | second cell |
The attributes on TABLE are all optional. By default, the table is rendered without a surrounding border. The table is generally sized automatically to fit the contents, but you can also set the table width using the WIDTH attribute. BORDER, CELLSPACING and CELLPADDING provide further control over the table's appearence. Captions are rendered at the top or bottom of the table depending on the ALIGN attribute.
Each table row is contained in a TR element, although the end tag can always be omitted. Table cells are defined by TD elements for data and TH elements for headers. Like TR, these are containers and can be given without trailing end tags. TH and TD support several attributes: ALIGN and VALIGN for aligning cell content, ROWSPAN and COLSPAN for cells which span more than one row or column. A cell can contain a wide variety of other block and text level elements including form fields and other tables.
The TABLE element always requires both start and end tags. It supports the following attributes:
).
This is equivalent to using the entity for
non-breaking spaces within the content of the cell.
| and center alignment for |
although you can override this with an ALIGN attribute on
the TR element.
| Tables are commonly rendered in bas-relief, raised up with the outer border as a bevel, and individual cells inset into this raised surface. Borders around individual cells are only drawn if the cell has explicit content. White space doesn't count for this purpose with the exception of . The algorithms used to automatically size tables should take into account the minimum and maximum width requirements for each cell. This is used to determine the minimum and maximum width requirements for each column and hence for the table itself. Cells spanning more than one column contribute to the widths of each of the columns spanned. One approach is to evenly apportion the cell's minimum and maximum width between these columns, another is to weight the apportioning according to the contributions from cells that don't span multiple columns. For some user agents it may be necessary or desirable to break text lines within words. In such cases a visual indication that this has occurred is advised. The minimum and maximum width of nested tables contribute to the minimum and maximum width of the cell in which they occur. Once the width requirements are known for the top level table, the column widths for that table can be assigned. This allows the widths of nested tables to be assigned and hence in turn the column widths of such tables. If practical, all columns should be assigned at least their minimum widths. It is suggested that any surplus space is then shared out proportional to the difference between the minimum and maximum width requirements of each column. Note that pixel values for width and height refer to screen pixels, and should be multiplied by an appropriate factor when rendering to very high resolution devices such as laser printers. For instance if a user agent has a display with 75 pixels per inch and is rendering to a laser printer with 600 dots per inch, then the pixel values given in HTML attributes should be multiplied by a factor of 8. Text level elementsThese don't cause paragraph breaks. Text level elements that define character styles can generally be nested. They can contain other text level elements but not block level elements.
Font style elementsThese all require start and end tags, e.g. This has some bold text. Text level elements must be properly nested - the following is in error: This has some bold and italic text.User agents should do their best to respect nested emphasis, e.g. This has some bold and italic text. Where the available fonts are restricted or for speech output, alternative means should be used for rendering differences in emphasis.
Note: future revisions to HTML may be phase out STRIKE in favor of the more concise "S" tag from HTML 3.0. Phrase ElementsThese all require start and end tags, e.g. This has some emphasized text.
Form fieldsINPUT, SELECT and TEXTAREA are only allowed within FORM elements. INPUT can be used for a variety of form fields including single line text fields, password fields, checkboxes, radio buttons, submit and reset buttons, hidden fields, file upload, and image buttons. SELECT elements are used for single or multiple choice menus. TEXTAREA elements are used to define multi-line text fields. The content of the element is used to initialize the field. INPUT text fields, radio buttons, check boxes, ...INPUT elements are not containers and so the end tag is forbidden.
SELECT menusSELECT is used to define select one from many or many from many menus. SELECT elements require start and end tags and contain one or more OPTION elements that define menu items. One from many menus are generally rendered as drop-down menus while many from many menus are generally shown as list boxes. Example: SELECT attributes:
OPTION attributes:
TEXTAREA multi-line text fieldsTEXTAREA elements require start and end tags. The content of the element is restricted to text and character entities. It is used to initialize the text that is shown when the document is first loaded. Example:
|