This document is also available in these non-normative formats: Single XHTML file, PostScript version, PDF version, ZIP archive, and Gzip'd TAR archive.
Copyright ©2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This Working Draft specifies the XHTML 2.0 Markup Language and a variety of XHTML-conforming modules that support that language.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This document is the first public working draft of this specification. It should in no way be considered stable, and should not be referenced for any purposes whatsoever. This version does not include the implementations of XHTML 2.0 in either DTD or XML Schema form. Those will be included in subsequent versions, once the contents of this language stabilizes.
This document has been produced by the W3C HTML Working Group (members only) as part of the W3C HTML Activity. The goals of the HTML Working Group are discussed in the HTML Working Group charter.
Public discussion of XHTML takes place on www-html@w3.org (archive). To subscribe send an email to www-html-request@w3.org with the word subscribe in the subject line.
Please report errors in this document to www-html-editor@w3.org (archive).
At the time of publication, the Working Group believed there were zero patent disclosures relevant to this specification. A current list of patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
This section is informative.
XHTML 2 is a markup language intended for rich, portable web-based applications. While the ancestry of XHTML 2 comes from HTML 4, XHTML 1.0, and XHTML 1.1, it is not intended to be backward compatible with its earlier versions. Application developers familiar with earlier its ancestors will be comfortable working with XHTML 2. Appendix A describes the ways in which XHTML 2 differs from previous versions and what application developers need to know to convert existing applications to XHTML 2.
XHTML 2 is a member of the XHTML Family of markup languages. It is an XHTML Host Language as defined in XHTML Modularization. As such, it is made up of a set of XHTML Modules that together describe the elements and attributes of the language, and their content model. XHTML 2 updates many of the modules defined in XHTML Modularization 1.0 [XHTMLMOD], and includes the updated versions of all those modules and their semantics. XHTML 2 also uses modules from Ruby [RUBY], XML Events [XMLEVENTS], and XForms [XFORMS].
The modules defined in this specification are largely extensions of the modules defined in XHTML Modularization 1.0. This specification also defines the semantics of the modules it includes. So, that means that unlike earlier versions of XHTML that relied upon the semantics defined in HTML 4, all of the semantics for XHTML 2 are defined either in this specification or in the specifications that it normatively references.
Even though the XHTML 2 modules are defined in this specification, they are available for use in other XHTML family markup languages. Over time, it is possible that the modules defined in this specification will migrate into the XHTML Modularization specification.
This section is informative.
While some terms are defined in place, the following definitions are used throughout this document. Familiarity with the W3C XML 1.0 Recommendation [XML] is highly recommended.
This section is normative.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
DTD Bias
This section has a distinct DTD bias. We need to make it clear that either the DTD or the Schema can be used to validate XHTML 2.0 documents.
A strictly conforming XHTML 2.0 document is a document that requires only the facilities described as mandatory in this specification. Such a document must meet all the following criteria:
The document must conform to the constraints expressed in Appendix B - XHTML 2.0 Schema or Appendix D - XHTML 2.0 Document Type Definition.
The root element of the document must be html
.
The root element of the document must contain an xmlns
declaration for the XHTML 2.0 namespace [XMLNAMES]. The namespace for
XHTML is defined to be http://www.w3.org/2002/06/xhtml2
. An example root element might look like:
<html xmlns="http://www.w3.org/2002/06/xhtml2" xml:lang="en">
There must be a DOCTYPE declaration in the document prior to the root element. If present, the public identifier included in the DOCTYPE declaration must reference the DTD found in Appendix C using its Formal Public Identifier. The system identifier may be modified appropriately.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/TR/xhtml2/DTD/xhtml2.dtd">
Here is an example of an XHTML 2.0 document.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/TR/xhtml2/DTD/xhtml2.dtd"> <html xmlns="http://www.w3.org/2002/06/xhtml2" xml:lang="en" > <head> <title>Virtual Library</title> </head> <body> <p>Moved to <a href="http://vlib.org/">vlib.org</a>.</p> </body> </html>
Note that in this example, the XML declaration is included. An XML declaration like the one above is not required in all XML documents. XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.
A conforming user agent must meet all user agent conformance requirements defined in [XHTMLMOD].
This section is normative.
The XHTML 2.0 document type is a fully functional document type with rich semantics. It is a collection of XHTML-conforming modules (most of which are defined in this specification). The Modules and their elements are listed here for information purposes, but the definitions in their base documents should be considered authoritative. In the on-line version of this document, the module names in the list below link into the definitions of the modules within the relevant version of the authoritative specification.
Need XHTML 2.0 Definition Table
We need a table that defines the modules that are in XHTML 2.0 and links them into this document. Currently, that will be a bunch of modules that are in this document, and modules from XML Events, Ruby, and XForms. The table below is largely correct, but is still just a place holder.
body, head, html, title
abbr, acronym, address, blockquote, br, cite, code, dfn, div, em, h, h1, h2, h3, h4, h5, h6, kbd, line, p, pre, quote, samp, section, span, strong, var
a
dl, dt, dd, name, nl, ol, ul, li
bdo
area, map
del, ins
link
meta
object, param
hr, sub, sup
noscript, script
ismap
on img
style
elementtarget
attributecaption, col, colgroup, table, tbody, td, tfoot, th, thead, tr
XHTML 2.0 also uses the following externally defined modules:
ruby, rbc, rtc, rb, rt, rp
listener
There are no additional definitions required by this document type. An implementation of this document type as an XML Schema is defined in Appendix B, and as a DTD in Appendix D.
This section is normative.
This document defines a variety of XHTML modules and the semantics of those modules. This section describes the conventions used in those module definitions.
Each module in this document is structured in the following way:
Note that attributes are fully defined only the first time they are used in each module. After that, only a brief description of the attribute is provided, along with a link back to the primary definition.
An abstract module is a definition of an XHTML module using prose text and some informal markup conventions. While such a definition is not generally useful in the machine processing of document types, it is critical in helping people understand what is contained in a module. This section defines the way in which XHTML abstract modules are defined. An XHTML-conforming module is not required to provide an abstract module definition. However, anyone developing an XHTML module is encouraged to provide an abstraction to ease in the use of that module.
The abstract modules are not defined in a formal grammar. However, the definitions do adhere to the following syntactic conventions. These conventions are similar to those of XML DTDs, and should be familiar to XML DTD authors. Each discrete syntactic element can be combined with others to make more complex expressions that conform to the algebra defined here.
expr ?
expr +
expr *
a , b
a
is required, followed by expression b
.a | b
a - b
&
).*
).|
), inside of
parentheses following the attribute name. If the attribute has a default value, that value is followed by an asterisk (*
). If the attribute has a fixed value, the attribute name is
followed by an equals sign (=
) and the fixed value enclosed in quotation marks.Abstract module definitions define minimal, atomic content models for each module. These minimal content models reference the elements in the module itself. They may also reference elements in other modules upon which the abstract module depends. Finally, the content model in many cases requires that text be permitted as content to one or more elements. In these cases, the symbol used for text is PCDATA. This is a term, defined in the XML 1.0 Recommendation, that refers to processed character data. A content type can also be defined as EMPTY, meaning the element has no content in its minimal content model.
In some instances, it is necessary to define the types of attribute values or the explicit set of permitted values for attributes. The following attribute types (defined in the XML 1.0 Recommendation) are used in the definitions of the abstract modules:
Attribute Type | Definition |
---|---|
CDATA | Character data |
ID | A document-unique identifier |
IDREF | A reference to a document-unique identifier |
IDREFS | A space-separated list of references to document-unique identifiers |
NAME | A name with the same character constraints as ID above |
NMTOKEN | A name composed of only name tokens as defined in XML 1.0 [XML]. |
NMTOKENS | One or more white space separated NMTOKEN values |
PCDATA | Processed character data |
In addition to these pre-defined data types, XHTML Modularization defines the following data types and their semantics (as appropriate):
Data type | Description |
---|---|
Character | A single character from [ISO10646]. |
Charset | A character encoding, as per [RFC2045]. |
Charsets | A space-separated list of character encodings, as per [RFC2045]. |
ClassName | Used by the class attribute, ClassNames are tokens that identify an element as being a member of the set named by the value of the class attribute. ClassName attribute tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods ("."). |
ContentType | A media type, as per [RFC2045]. |
ContentTypes | A comma-separated list of media types, as per [RFC2045]. |
Coordinates | Comma separated list of Lengths used in defining areas. |
Datetime | Date and time information. |
FPI | A character string representing an SGML Formal Public Identifier. |
HrefTarget | Window name used as destination for results of certain actions. |
LanguageCode | A language code, as per [RFC3066]. |
Length | The value may be either in pixels or a percentage of the available horizontal or vertical space. Thus, the value "50%" means half of the available space. |
LinkTypes |
Authors may use the following recognized link types, listed here with their conventional interpretations. A LinkTypes value refers to a space-separated list of link types. White space characters are not permitted within link types. These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate". User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.
|
MediaDesc |
A comma-separated list of media descriptors as described by [CSS]. The default is |
MultiLength | The value may be a Length or a relative length. A relative length has the form "i*", where "i" is an integer. When allotting space among elements competing for that space, user agents allot pixel and percentage lengths first, then divide up remaining available space among relative lengths. Each relative length receives a portion of the available space that is proportional to the integer preceding the "*". The value "*" is equivalent to "1*". Thus, if 60 pixels of space are available after the user agent allots pixel and percentage space, and the competing relative lengths are 1*, 2*, and 3*, the 1* will be allotted 10 pixels, the 2* will be allotted 20 pixels, and the 3* will be allotted 30 pixels. |
MultiLengths | A comma separated list of items of type MultiLength. |
Number | One or more digits |
Pixels | The value is an integer that represents the number of pixels of the canvas (screen, paper). Thus, the value "50" means fifty pixels. For normative information about the definition of a pixel, please consult [CSS2] |
Shape | The shape of a region. |
Text | Arbitrary textual data, likely meant to be human-readable. |
URI | A Uniform Resource Identifier Reference, as defined by the type anyURI in [XMLSCHEMA]. |
URIs | A space-separated list of URIs as defined above. |
URI List | A comma-separated list of URIs as defined above. |
This section is normative.
Many of the abstract modules in this document define the required attributes for their elements. The table below defines some collections of attributes that are referenced throughout the modules. These expressions should in no way be considered normative or mandatory. They are an editorial convenience for this document. When used in the remainder of this section, it is the expansion of the term that is normative, not the term itself.
The following basic attribute sets are used on many elements. In each case where they are used, their use is identified via their collection name.
The class attribute can be used for different purposes in XHTML, for instance as a style sheet selector (when an author wishes to assign style information to a set of elements), and for general purpose processing by user agents.
For instance in the following example, the p element is used in conjunction with the class attribute to identify a particular type of paragraph.
<p><span class="note"> These programs are only available if you have purchased the advanced professional suite. </p>
Style sheets rules can then be used to render the paragraph appropriately, for instance by putting a border round it, giving it a different background colour, or where necessary by not displaying it at all.
The id attribute has several roles in XHTML:
As an example, the following headings are distinguished by their id values:
<h id="introduction">Introduction</h> <p>...</p> <h id="events">The Events Module</h> <p>...</p>
Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers should display the title as a "tool tip" (a short message that appears when the pointing device pauses over an object). Audio user agents may speak the title information in a similar context.
The title attribute has an additional role when used with the link element to designate an external style sheet. Please consult the section on links and style sheets for details.
Example:
<a href="/Jakob/" title="Author biography">Jakob Nielsen</a>'s Alertbox for January 11, 1998
An element inherits language code information according to the following order of precedence (highest to lowest):
In this example, the primary language of the document is French ("fr"). One paragraph is declared to be in US English ("en-us"), after which the primary language returns to French. The following paragraph includes an embedded Japanese ("ja") phrase, after which the primary language returns to French.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/xhtml2/DTD/xhtml2.dtd"> <html xmlns="http://www.w3.org/2002/06/xhtml2" xml:lang="fr"> <head> <title>Un document multilingue</title> </head> <body> <p>...Interpreted as French...</p> <p xml:lang="en-us">...Interpreted as US English...</p> <p>...Interpreted as French again...</p> <p>...French text interrupted by<em xml:lang="ja">some Japanese</em>French begins here again...</p> </body> </html>
This specification does not define how this attribute gets used, since that is defined by the environment that the hyperlink is evaluated in.
XFrames not published yet
We need a reference to XFrames here, but XFrames is not yet public.Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the a element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.
In this example, we assign an access key to a link defined by the a element. Typing this access key takes the user to another document, in this case, a table of contents.
<p><a accesskey="C" rel="contents" href="http://someplace.com/specification/contents.html"> Table of Contents</a> </p>
The invocation of access keys depends on the underlying system. For instance, on machines running MS Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.
The rendering of access keys depends on the user agent. We recommend that authors include the access key in label text or wherever the access key is to apply. User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).
The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
Tabbing keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).
The global attributes from [XMLEVENTS] are included in the Events attribute collection. The normative definition of those attributes and their semantics is included in that specification. They are described briefly below:
List of XHTML 2 Events Needed
We need to define the list of XHTML 2 events and map them into the XHTML DOM.Note that these attributes are not in the XHTML namespace. Instead, they are in the XML Events namespace. The XHTML namespace is the default namespace for XHTML documents, so
XHTML elements and attributes do not require namespace prefixes (although they are permitted). XML Events attributes MUST use a prefix, since they are not in the default namespace of the document.
When XML Events are included in an XHTML document, the default prefix for those attribute is ev
.
This collection assembles the Core, I18N, Events and Hypertext attribute collections defined above.
This section is normative.
The Structure Module defines the major structural elements for XHTML. These elements effectively act as the basis for the content model of many XHTML family document types. The elements and attributes included in this module are:
Elements | Attributes | Minimal Content Model |
---|---|---|
body | Common | (Heading | Block | List)* |
head | Common | title |
html | I18N, profile (URI), xmlns (URI = "http://www.w3.org/2002/06/xhtml2") | head, body |
title | I18N | PCDATA |
This module is the basic structural definition for XHTML content. The html
element acts as the root element for all XHTML Family Document Types.
Note that the value of the xmlns attribute is defined to be "http://www.w3.org/2002/06/xhtml2". Also note that because the xmlns attribute is treated specially by XML namespace-aware parsers [XMLNAMES], it is legal to have it present as an attribute of each element. However, any time the xmlns attribute is used in the context of an XHTML module, whether with a prefix or not, the value of the attribute shall be the XHTML namespace defined here.
Implementation: DTD
After the document type declaration, the remainder of an XHTML document is contained by the html element.
Attributes
The head element contains information about the current document, such as its title, keywords that may be useful to search engines, and other data that is not considered document content. User agents do not generally render elements that appear in the head as content. They may, however, make information in the head available to users through other mechanisms.
Attributes
Every XHTML document must have a title element in the head section.
Attributes
Authors should use the title element to identify the contents of a document. Since users often consult documents out of context, authors should provide context-rich titles. Thus, instead of a title such as "Introduction", which doesn't provide much contextual background, authors should supply a title such as "Introduction to Medieval Bee-Keeping" instead.
For reasons of accessibility, user agents must always make the content of the title element available to users (including title elements that occur in frames). The mechanism for doing so depends on the user agent (e.g., as a caption, spoken).
Titles may contain entity references (for accented characters, special characters, etc.), but may not contain other markup (including comments). Here is a sample document title:
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN" "http://www.w3.org/TR/xhtml2/DTD/xhtml2.dtd"> <html xmlns="http://www.w3.org/2002/06/xhtml2"> <head> <title>A study of population dynamics</title> ... other head elements... </head> <body> ... document body... </body> </html>
The body of a document contains the document's content. The content may be presented by a user agent in a variety of ways. For example, for visual browsers, you can think of the body as a canvas where the content appears: text, images, colors, graphics, etc. For audio user agents, the same content may be spoken.
Attributes
This section is normative.
This module defines all of the basic text container elements, attributes, and their content model:
Element | Attributes | Minimal Content Model |
---|---|---|
abbr | Common | (PCDATA | Inline)* |
acronym | Common | (PCDATA | Inline)* |
address | Common | (PCDATA | Inline)* |
blockquote | Common, cite (URI) | (PCDATA | Heading | Block | List)* |
br | Core | EMPTY |
cite | Common | (PCDATA | Inline)* |
code | Common | (PCDATA | Inline)* |
dfn | Common | (PCDATA | Inline)* |
div | Common | (PCDATA | Flow)* |
em | Common | (PCDATA | Inline)* |
h | Common | (PCDATA | Inline)* |
h1 | Common | (PCDATA | Inline)* |
h2 | Common | (PCDATA | Inline)* |
h3 | Common | (PCDATA | Inline)* |
h4 | Common | (PCDATA | Inline)* |
h5 | Common | (PCDATA | Inline)* |
h6 | Common | (PCDATA | Inline)* |
kbd | Common | (PCDATA | Inline)* |
line | Common | (PCDATA | Inline)* |
p | Common | (PCDATA | Inline | List | blockquote | pre | table)* |
pre | Common | (PCDATA | Inline)* |
quote | Common, cite (URI) | (PCDATA | Inline)* |
samp | Common | (PCDATA | Inline)* |
section | Common | (PCDATA | Flow)* |
span | Common | (PCDATA | Inline)* |
strong | Common | (PCDATA | Inline)* |
var | Common | (PCDATA | Inline)* |
The minimal content model for this module defines some content sets:
Note that the use of the words Block and Inline here are meant to be suggestive of the role the content sets play. They are not normative with regards to presentation (in other
words, a style sheet might give an element within the Block content a display
property of inline
).
Implementation: DTD
The abbr element indicates that a text fragment is an abbreviation (e.g., W3C, XML, Inc., Ltd., Mass., etc.).
Attributes
The content of the abbr and acronym elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.
Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while "IRS" and "BBC" are typically pronounced letter by letter, "NATO" and "UNESCO" are pronounced phonetically. Still other abbreviated forms (e.g., "URI" and "SQL") are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form.
Examples:
<abbr title="Limited">Ltd.</abbr> <abbr title="Abbreviation">abbr.</abbr>
The acronym element indicates that a text fragment is an acronym (e.g., BBC, WWW, URL, etc.). Its usage is the same as the abbr element above.
While some dictionaries define an acronym to be just a word formed from the initial letters of other words, others require the acronym to be pronouncable as a word. This specification does not require the acronym element to adhere to either definition, but is only provided for author convenience.
Attributes
Examples:
<acronym title="World Wide Web">WWW</acronym> <acronym xml:lang="fr" title="Société Nationale des Chemins de Fer"> SNCF </acronym>
The address element may be used by authors to supply contact information for a document or a major part of a document such as a form. This element often appears at the beginning or end of a document.
Attributes
For example:
<address> <a href="mailto:webmaster@example.net">Webmaster</a> </address>
This element designates a block of quoted text.
Attributes
This example formats an excerpt from "The Two Towers", by J.R.R. Tolkien, as a blockquote.
<blockquote cite="http://www.example.com/tolkien/twotowers.html"> <p>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.</p> </blockquote>
The br element indicates that the current output line should be ended at this point, and a new line begun. This element is deprecated in favor of the line element.
Attributes
Example:
<p class="poem" xml:lang="fr"> Un petit d'un petit<br/> S'etonne aux Halles.<br/> Un petit d'un petit,<br/> Ah! Degres te fallent. </p>
The cite element contains a citation or a reference to other sources.
Attributes
In the following example, the cite element is used to delineate the speaker:
As <cite cite="http://www.whitehouse.gov/history/presidents/ht33.html">Harry S. Truman</cite> said, <quote lang="en-us">The buck stops here.</quote> More information can be found in <cite cite="http://www.w3.org/TR/REC-xml">[XML]</cite>.
The code element contains a fragment of computer code.
Attributes
Example:
The <code>code</code> element contains a fragment of computer code.
The dfn element contains the defining instance of the enclosed term.
Attributes
Example:
An <dfn id="def-acronym">acronym</dfn> is a word formed from the initial letters or groups of letters of words in a set phrase or series of words.
The div element, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. This element defines no presentational idioms on the content. Thus, authors may use this element in conjunction with style sheets, the xml:lang attribute, etc., to tailor XHTML to their own needs and tastes.
Attributes
For example, suppose you wish to make a presentation in XHTML, where each slide is enclosed in a separate element. You could use a div
element, with a class of slide
:
<body> <h>The meaning of life</h> <p>By Huntington B. Snark</p> <div class="slide"> <h>What do I mean by "life"</h> <p>....</p> </div> <div class="slide"> <h>What do I mean by "mean"?</h> ... </div> ... </body>
The em element indicates emphasis for its contents.
Attributes
Example:
Do <em>not</em> phone before 9 a.m.
A heading element briefly describes the topic of the section it introduces. Heading information may be used by user agents, for example, to construct a table of contents for a document automatically.
Attributes
There are two styles of headings in XHTML: the numbered versions h1, h2 etc., and the structured version h, which is used in combination with the section element.
There are six levels of numbered headings in XHTML with h1 as the most important and h6 as the least. The visual presentation of headers can render more important headings in larger fonts than less important ones.
Structured headings use the single h element, in combination with the section element to indicate the structure of the document, and the nesting of the sections indicate the importance of the heading.
For example:
<body> <h>This is a top level heading</h> <p>....</p> <section> <p>....</p> <h>This is a second-level heading</h> <p>....</p> <h>This is another second-level heading</h> <p>....</p> </section> <section> <p>....</p> <h>This is another second-level heading</h> <p>....</p> <section> <h>This is a third-level heading</h> <p>....</p> </section> </section>
These visual representation of these levels can be distinguished in a style sheet:
h {font-family: sans-serif; font-weight: bold; font-size: 200%} section h {font-size: 150%} /* A second-level heading */ section section h {font-size: 120%} /* A third-level heading */
etc.
Numbered sections and references
XHTML does not itself cause section numbers to be generated from headings. Style sheet
languages such as CSS however allow authors to control the generation of section numbers.
The practice of skipping heading levels is considered to be bad practice. The series h1 h2 h1 is acceptable, while h1 h3 h1 is not, since the heading level h2 has been skipped.
The kbd element indicates text to be entered by the user.
Attributes
Example:
To exit, type <kbd>QUIT</kbd>.
The line element represents a sub-paragraph. It is intended as a structured replacement for the br element. It contains a piece of text that when visually represented should start on a new line, and have a line break at the end. Whether the line should wrap or not visually depends on styling properties of the element.
Attributes
By retaining structure in text that has to be broken over lines, you retain essential information about its makeup. This gives you greater freedom with styling the content. For instance, line numbers can be generated automatically from the stylesheet if needed.
For instance, for a document with the following structure:
<p class="program"> <line>program p(input, output);</line> <line>begin</line> <line> writeln("Hello world");</line> <line>end.</line> </p>
the following CSS stylesheet would number each line:
.program { counter-reset: linenumber } line:before { position: relative; left: -1em; counter-increment: linenumber; content: counter(linenumber); }
The p element represents a paragraph.
In comparison with earlier versions of HTML, where a paragraph could only contain inline text, XHTML2's paragraphs represent the conceptual idea of a paragraph, and so may contain lists, blockquotes, pre's and tables as well as inline text. They may not, however, contain directly nested p elements.
Attributes
Authors are discouraged from using empty p elements. User agents should ignore empty p.
<p>Payment options include: <ul> <li>cash</li> <li>credit card</li> <li>luncheon vouchers.</li> </ul> </p>
The pre element indicates that whitespace in the enclosed text has semantic relevance, and will normally be included in renderings of the content
Note that all elements in the XHTML family preserve their whitespace in the document, which is only removed on rendering, via a stylesheet, according to the rules of CSS [CSS]. This means that in principle all elements may preserve or collapse whitespace on rendering, under control of a stylesheet. Also note that there is no requirement that the <pre> element be rendered in a monospace font (although this is the default rendering), nor that text wrapping be disabled.
Attributes
Non-visual user agents are not required to respect extra white space in the content of a pre element.
The following example shows a preformatted verse from Shelly's poem To a Skylark:
<pre> 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. </pre>
Here is how this might be rendered:
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.
This element designates a inline text fragment of quoted text.
Attributes
Visual user agents are not required to add delimiting quotation marks (as was the case for the q
element in earlier versions of HTML). It is the responsibility of the document author
to add any required quotation marks.
The following example illustrates nested quotations with the quote element.
<p>John said, <quote lang="en-us">"I saw Lucy at lunch, she told me <quote lang="en-us">'Mary wants you to get some ice cream on your way home.'</quote> I think I will get some at Jen and Berry's, on Gloucester Road."</quote></p>
Here is an example using the cite attribute:
Steven replied: <quote cite="http://lists.w3.org/Public/www-html/June2002/001.html">We quite agree</quote>
The samp element designates sample output from programs, scripts, etc.
Attributes
Example:
On starting, you will see the prompt <samp>$ </samp>.
Attributes
The section element, in conjunction with the h element, offers a mechanism for structuring documents into sections. This element defines content to be block-level but imposes no other presentational idioms on the content, which may otherwise be controlled from a style sheet.
By representing the structure of documents explicitely using the section and h elements gives the author greater control over presentation possibilities than the traditional implicit structuring using numbered levels of headings. For instance, it is then possible to indicate the nesting of sections by causing a border to be displayed to the left of sections.
Here is an example
<body> <h>Events</h> <section> <h>Introduction</h> <p>....</p> <h>Specifying events</h> <p>...</p> <section> <h>Attaching events to the handler</h> <p>...</p> </section> <section> <h>Attaching events to the listener</h> <p>...</p> </section> <section> <h>Specifying the binding elsewhere</h> <p>...</p> </section> </section>
The span element, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. This element imposes no presentational idioms on the content. Thus, authors may use this element in conjunction with style sheets, the xml:lang attribute, etc., to tailor XHTML to their own needs and tastes.
Attributes
For example, suppose you wish to mark all words in a document that need to be collected into an index. You could use a span element, with a
class of xref
:
<p>This operation is called the <span class="xref">transpose</span> or <span class="xref">inverse</span>.</p>
The strong element indicates strong emphasis for its contents.
Attributes
On <strong>Monday</strong> please put the rubbish out, but <em>not</em> before nightfall!
The var element indicates an instance of a variable or program argument.
Attributes
Example:
The parameter <var>ncols</var> represents the number of colors to use.
This section is normative.
The Hypertext Module provides the element that is used to define hypertext links to other resources, as well as a number of attributes.
This module supports the following element:
Element | Attributes | Minimal Content Model |
---|---|---|
a | Common, charset (Charset), hreflang (LanguageCode), rel (LinkTypes), rev (LinkTypes), type (ContentType) | (PCDATA | Inline)* |
This module adds the a element to the Inline content set of the Text Module, and activates the Hypertext Attribute Collection.
Implementation: DTD
Attributes
Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address.
For the current list of registered content types, please consult [MIMETYPES].
The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
Tabbing keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).
Each a element defines an anchor.
Authors may also create an a element that specifies no anchors, i.e., that doesn't specify href, or id. Values for these attributes may be set at a later time through scripts as defined in the Scripting module.
In the example that follows, the a element defines a link. The source anchor is the text "W3C Web site" and the destination anchor is "http://www.w3.org/":
For more information about W3C, please consult the <a href="http://www.w3.org/">W3C Web site</a>.
This link designates the home page of the World Wide Web Consortium. When a user activates this link in a user agent, the user agent will retrieve the resource, in this case, an XHTML document.
User agents generally render links in such a way as to make them obvious to users (underlining, reverse video, etc.). The exact rendering depends on the user agent. Rendering may vary according to whether the user has already visited the link or not. A possible visual rendering of the previous link might be:
For more information about W3C, please consult the W3C Web site. ~~~~~~~~~~~~
To tell user agents explicitly what the character encoding of the destination page is, set the charset attribute:
For more information about W3C, please consult the <a href="http://www.w3.org/" charset="ISO-8859-1">W3C Web site</a>
Suppose we define an anchor named "anchor-one" in the file "one.html".
...text before the anchor... <a name="anchor-one">This is the location of anchor one.</a> ...text after the anchor...
This creates an anchor around the text "This is the location of anchor one.". Usually, the contents of a are not rendered in any special way when a defines an anchor only.
Having defined the anchor, we may link to it from the same or another document. URIs that designate anchors contain a "#" character followed by the anchor name (the fragment identifier). Here are some examples of such URIs:
Thus, a link defined in the file "two.html" in the same directory as "one.html" would refer to the anchor as follows:
...text before the link... For more information, please consult <a href="./one.html#anchor-one"> anchor one</a>. ...text after the link...
The a element in the following example specifies a link (with href) and creates a named anchor (with id) simultaneously:
I just returned from vacation! Here's a <a id="anchor-two" href="http://www.somecompany.com/People/Ian/vacation/family.png"> photo of my family at the lake.</a>.
This example contains a link to a different type of Web resource (a PNG image). Activating the link should cause the image resource to be retrieved from the Web (and possibly displayed if the system has been configured to do so).
Note. User agents area required to find anchors created by empty a elements.
This section is normative.
As its name suggests, the List Module provides list-oriented elements. Specifically, the List Module supports the following elements and attributes:
Elements | Attributes | Minimal Content Model |
---|---|---|
dl | Common | ( dt | dd)+ |
dt | Common | (PCDATA | Inline)* |
dd | Common | (PCDATA | Flow)* |
nl | Common | name , li+ |
ol | Common | li+ |
ul | Common | li+ |
li | Common | (PCDATA | Flow)* |
This module also defines the content set List with the minimal content model (dl | nl | ol | ul)+ and adds this set to the Flow content set of the Text Module.
Implementation: DTD
XHTML offers authors several mechanisms for specifying lists of information. All lists must contain one or more list elements. Lists may contain:
The previous list, for example, is an unordered list, created with the ul element:
<ul> <li>Unordered information. </li> <li>Ordered information. </li> <li>Navigation information. </li> <li>Definitions. </li> </ul>
An ordered list, created using the ol element, should contain information where order should be emphasized, as in a recipe:
Definition lists, created using the dl element, generally consist of a series of term/definition pairs (although definition lists may have other applications). Thus, when advertising a product, one might use a definition list:
defined in XHTML as:
<dl> <dt><strong>Lower cost</strong></dt> <dd>The new version of this product costs significantly less than the previous one!</dd> <dt><strong>Easier to use</strong></dt> <dd>We've changed the product so that it's much easier to use!</dd> <dt><strong>Safe for kids</strong></dt> <dd>You can leave your kids alone in a room with this product and they won't get hurt (not a guarantee).</dd> </dl>
Lists may also be nested and different list types may be used together, as in the following example, which is a definition list that contains an unordered list (the ingredients) and an ordered list (the procedure):
The exact presentation of the three list types depends on the user agent. We discourage authors from using lists purely as a means of indenting text. This is a stylistic issue and is properly handled by style sheets.
Attributes
Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the dt element and is restricted to inline content. The description is given with a dd element that contains block-level content.
Here is an example:
<dl> <dt>Dweeb</dt> <dd>young excitable person who may mature into a <em>Nerd</em> or <em>Geek</em></dd> <dt>Hacker</dt> <dd>a clever programmer</dd> <dt>Nerd</dt> <dd>technically bright but socially inept person</dd> </dl>
Here is an example with multiple terms and descriptions:
<dl> <dt>Center</dt> <dt>Centre</dt> <dd> A point equidistant from all points on the surface of a sphere.</dd> <dd> In some field sports, the player who holds the middle position on the field, court, or forward line.</dd> </dl>
Another application of dl, for example, is for marking up dialogues, with each dt naming a speaker, and each dd containing his or her words.
Attributes
Navigation lists are intended to be used to define collections of selectable items for presentation in a "navigation" menu. A navigation list is required to start with a name element that defines the name for the list.
On visual user agents, the default presentation behavior is as follows:
It is possible to change this default behavior through the use of style sheets. The behavior of navigation lists in non-visual user agents is unspecified.
This example illustrates the basic structure of a nested navigation list:
<nl> <name>Contents </name> <li href="#introduction">Introduction</li> <li> <nl> <name>Terms</name> <li href="#may">May</li> <li href="#must">Must</li> <li href="#should">Should</li> </nl> </li> <li href="#conformance">Conformance</li> <li href="#references">References</li> ... </nl>
Attributes
Ordered and unordered lists are rendered in an identical manner except that visual user agents number ordered list items. User agents may present those numbers in a variety of ways. Unordered list items are not numbered.
Both types of lists are made up of sequences of list items defined by the li element.
This example illustrates the basic structure of a list.
<ul> <li> ... first list item...</li> <li> ... second list item...</li> ... </ul>
Attributes
Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the a element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.
In this example, we assign an access key to a link defined by the a element. Typing this access key takes the user to another document, in this case, a table of contents.
<p><a accesskey="C" rel="contents" href="http://someplace.com/specification/contents.html"> Table of Contents</a> </p>
The invocation of access keys depends on the underlying system. For instance, on machines running MS Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.
The rendering of access keys depends on the user agent. We recommend that authors include the access key in label text or wherever the access key is to apply. User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).
The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
Tabbing keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).
The li element defines a list item within an ordered, unordered, or navigation list. When the href attribute is defined, the contents of the list item become a selectable link, just as an a element with an href attribute would be.
Attributes
The name element is used to define a name for an nl navigation list. The contents of the name element are displayed as the title of a list (or sublist). See nl for more information.
This section is normative.
The Bi-directional Text module defines an element that can be used to declare the bi-directional rules for the element's content.
Elements | Attributes | Minimal Content Model |
---|---|---|
bdo | Core, dir* ("ltr" | "rtl") | (PCDATA | Inline)* |
When this module is used, the bdo element is added to the Inline content set of the Text Module. Selecting this module also adds the
attribute dir* ("ltr" | "rtl")
to the I18N attribute collection.
Implementation: DTD
The bidirectional algorithm and the dir attribute generally suffice to manage embedded direction changes. However, some situations may arise when the bidirectional algorithm results in incorrect presentation. The bdo element allows authors to turn off the bidirectional algorithm for selected fragments of text.
Attributes
Consider a document containing the same text as before:
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
but assume that this text has already been put in visual order. One reason for this may be that the MIME standard ([RFC2045], [RFC1556]) favors visual order, i.e., that right-to-left character sequences are inserted right-to-left in the byte stream. In an email, the above might be formatted, including line breaks, as:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
This conflicts with the [UNICODE] bidirectional algorithm, because that algorithm would invert 2WERBEH, 4WERBEH, and 6WERBEH a second time, displaying the Hebrew words left-to-right instead of right-to-left.
The solution in this case is to override the bidirectional algorithm by putting the Email excerpt in a pre element (to conserve line breaks) and each line in a bdo element, whose dir attribute is set to ltr:
<pre> <bdo dir="ltr">english1 2WERBEH english3</bdo> <bdo dir="ltr">4WERBEH english5 6WERBEH</bdo> </pre>
This tells the bidirectional algorithm "Leave me left-to-right!" and would produce the desired presentation:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
The bdo element should be used in scenarios where absolute control over sequence order is required (e.g., multi-language part numbers). The dir attribute is mandatory for this element.
Authors may also use special Unicode characters to override the bidirectional algorithm -- LEFT-TO-RIGHT OVERRIDE (202D) or RIGHT-TO-LEFT OVERRIDE (hexadecimal 202E). The POP DIRECTIONAL FORMATTING (hexadecimal 202C) character ends either bidirectional override.
Note. Recall that conflicts can arise if the dir attribute is used on inline elements (including bdo concurrently with the corresponding [UNICODE] formatting characters.
Bidirectionality and character encoding According to [RFC1555] and [RFC1556], there are special conventions for the use of "charset" parameter values to indicate bidirectional treatment in MIME mail, in particular to distinguish between visual, implicit, and explicit directionality. The parameter value "ISO-8859-8" (for Hebrew) denotes visual encoding, "ISO-8859-8-i" denotes implicit bidirectionality, and "ISO-8859-8-e" denotes explicit directionality.
Because XHTML uses the Unicode bidirectionality algorithm, conforming documents encoded using ISO 8859-8 must be labeled as "ISO-8859-8-i". Explicit directional control is also possible with HXTML, but cannot be expressed with ISO 8859-8, so "ISO-8859-8-e" should not be used.
The value "ISO-8859-8" implies that the document is formatted visually, misusing some markup (such as table with right alignment and no line wrapping) to ensure reasonable display on older user agents that do not handle bidirectionality. Such documents do not conform to the present specification. If necessary, they can be made to conform to the current specification (and at the same time will be displayed correctly on older user agents) by adding bdo markup where necessary. Contrary to what is said in [RFC1555] and [RFC1556], ISO-8859-6 (Arabic) is not visual ordering.
Since ambiguities sometimes arise as to the directionality of certain characters (e.g., punctuation), the [UNICODE] specification includes characters to enable their proper resolution. Also, Unicode includes some characters to control joining behavior where this is necessary (e.g., some situations with Arabic letters). XHTML includes character references for these characters.
The following DTD excerpt presents some of the directional entities:
<!ENTITY zwnj CDATA "‌"--=zero width non-joiner--> <!ENTITY zwj CDATA "‍"--=zero width joiner--> <!ENTITY lrm CDATA "‎"--=left-to-right mark--> <!ENTITY rlm CDATA "‏"--=right-to-left mark-->
The zwnj entity is used to block joining behavior in contexts where joining will occur but shouldn't. The zwj entity does the opposite; it forces joining when it wouldn't occur but should. For example, the Arabic letter "HEH" is used to abbreviate "Hijri", the name of the Islamic calendar system. Since the isolated form of "HEH" looks like the digit five as employed in Arabic script (based on Indic digits), in order to prevent confusing "HEH" as a final digit five in a year, the initial form of "HEH" is used. However, there is no following context (i.e., a joining letter) to which the "HEH" can join. The zwj character provides that context.
Similarly, in Persian texts, there are cases where a letter that normally would join a subsequent letter in a cursive connection should not. The character zwnj is used to block joining in such cases.
The other characters, lrm and rlm, are used to force directionality of directionally neutral characters. For example, if a double quotation mark comes between an Arabic (right-to-left) and a Latin (left-to-right) letter, the direction of the quotation mark is not clear (is it quoting the Arabic text or the Latin text?). The lrm and rlm characters have a directional property but no width and no word/line break property. Please consult [UNICODE] for more details.
Mirrored character glyphs. In general, the bidirectional algorithm does not mirror character glyphs but leaves them unaffected. An exception are characters such as parentheses (see [UNICODE], table 4-7). In cases where mirroring is desired, for example for Egyptian Hieroglyphs, Greek Bustrophedon, or special design effects, this should be controlled with styles.
In general, using style sheets to change an element's visual rendering from block-level to inline or vice-versa is straightforward. However, because the bidirectional algorithm relies on the inline/block-level distinction, special care must be taken during the transformation.
When an inline element that does not have a dir attribute is transformed to the style of a block-level element by a style sheet, it inherits the dir attribute from its closest parent block element to define the base direction of the block.
When a block element that does not have a dir attribute is transformed to the style of an inline element by a style sheet, the resulting presentation should be equivalent, in terms of bidirectional formatting, to the formatting obtained by explicitly adding a dir attribute (assigned the inherited value) to the transformed element.
This section is normative.
The Client-side Image Map Module provides elements for client side image maps. It requires that the Image Module (or another module that supports the img
element) be included. The
Client-side Image Map Module supports the following elements:
Elements | Attributes | Minimal Content Model |
---|---|---|
a& | coords (CDATA), shape ("rect" | "circle" | "poly" | "default") | n/a |
input& | usemap (IDREF) | Note: Only when the Forms module is included |
map | I18N, Events, class (NMTOKEN), id* (ID), title (CDATA) | ((Heading | Block) | area)+ |
object& | usemap (IDREF) | Note: Only when the object module is included |
When this module is used, the map element is added to the Inline content set of the Text Module.
Implementation: DTD
The area element defines a geometric region associated with an image map, and optionally associates that region with events or external references.
Attributes
Coordinates are relative to the top, left corner of the object. All values are of type Length. All values are separated by commas.
The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
Tabbing keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).
Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the a element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.
In this example, we assign an access key to a link defined by the a element. Typing this access key takes the user to another document, in this case, a table of contents.
<p><a accesskey="C" rel="contents" href="http://someplace.com/specification/contents.html"> Table of Contents</a> </p>
The invocation of access keys depends on the underlying system. For instance, on machines running MS Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.
The rendering of access keys depends on the user agent. We recommend that authors include the access key in label text or wherever the access key is to apply. User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).
Several non-textual elements let authors specify alternate text to serve as content when the element cannot be rendered normally. Specifying alternate text assists users without graphic display terminals, users whose browsers don't support forms, visually impaired users, those who use speech synthesizers, those who have configured their graphical user agents not to display images, etc.
While alternate text may be very helpful, it must be handled with care. Authors should observe the following guidelines:
The map element specifies a client-side image map (or other navigation mechanism) that may be associated with another object. An image map is associated with an element via the element's usemap attribute. The map element may be used without an associated image for general navigation mechanisms.
Attributes
The presence of the usemap attribute for an object implies that the object being included is an image. Furthermore , when the object element has an associated client-side image map, user agents may implement user interaction with the object solely in terms of the client-side image map. This allows user agents (such as an audio browser or robot) to interact with the object without having to process it; the user agent may even elect not to retrieve (or process) the object. When an object has an associated image map, authors should not expect that the object will be retrieved or processed by every user agent.
The map element content model allows authors to combine the following:
When a map element contains mixed content (both area elements and block-level content), user agents must ignore the area elements.
Authors should specify an image maps's geometry completely with area elements, or completely with a elements, or completely with both if content is mixed. Authors may wish to mix content so that older user agents will handle map geometries specified by area elements and new user agents will take advantage of richer block content.
If two or more defined regions overlap, the region-defining element that appears earliest in the document takes precedence (i.e., responds to user input).
User agents and authors should offer textual alternates to graphical image maps for cases when graphics are not available or the user cannot access them. For example, user agents may use alt text to create textual links in place of a graphical image map. Such links may be activated in a variety of ways (keyboard, voice activation, etc.).
In the following example, we create a client-side image map for the object element. We do not want to render the image map's contents when the object is rendered, so we "hide" the map element within the object element's content. Consequently, the map element's contents will only be rendered if the object cannot be rendered.
<html xmlns="http://www.w3.org/2002/06/xhtml2"> <head> <title>The cool site!</title> </head> <body> <p> <object data="navbar1.gif" type="image/gif" usemap="#map1"> <map name="map1"> <p> Navigate the site: <a href="guide.html" shape="rect" coords="0,0,118,28"> Access Guide</a> | <a href="shortcut.html" shape="rect" coords="118,0,184,28"> Go</a> | <a href="search.html" shape="circle" coords="184,200,60"> Search</a> | <a href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0"> Top Ten</a> </map> </object> </body> </html>
We may want to render the image map's contents even when a user agent can render the object. For instance, we may want to associate an image map with an object element and include a text navigation bar at the bottom of the page. To do so, we define the map element outside the object:
<html> <head> <title>The cool site!</title> </head> <body> <P><object data="navbar1.gif" type="image/gif" usemap="#map1"> </object> ...the rest of the page here... <map name="map1"> <P>Navigate the site: <A href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> | <A href="shortcut.html" shape="rect" coords="118,0,184,28">Go</A> | <A href="search.html" shape="circle" coords="184,200,60">Search</A> | <A href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">Top Ten</A> </map> </body> </html>
In the following example, we create a similar image map, this time using the area element. Note the use of alt text:
<p><object data="navbar1.gif" type="image/gif" usemap="#map1"> <p>This is a navigation bar. </object> <map name="map1"> <area href="guide.html" alt="Access Guide" shape="rect" coords="0,0,118,28"> <area href="search.html" alt="Search" shape="rect" coords="184,0,276,28"> <area href="shortcut.html" alt="Go" shape="circle" coords="184,200,60"> <area href="top10.html" alt="Top Ten" shape="poly" coords="276,0,276,28,100,200,50,50,276,0"> </map>
The following example illustrates how image maps may be shared.
Nested object elements are useful for providing fallbacks in case a user agent doesn't support certain formats. For example:
<p> <object data="navbar.png" type="image/png"> <object data="navbar.gif" type="image/gif"> text describing the image... </object> </object>
If the user agent doesn't support the PNG format, it tries to render the GIF image. If it doesn't support GIF (e.g., it's a speech-based user agent), it defaults to the text description provided as the content of the inner object element. When object elements are nested this way, authors may share image maps among them:
<P> <object data="navbar.png" type="image/png" usemap="#map1"> <object data="navbar.gif" type="image/gif" usemap="#map1"> <map name="map1"> <p>Navigate the site: <a href="guide.html" shape="rect" coords="0,0,118,28">Access Guide</a> | <a href="shortcut.html" shape="rect" coords="118,0,184,28">Go</a> | <a href="search.html" shape="circle" coords="184,200,60">Search</a> | <a href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">Top Ten</a> </map> </object> </object>
The following example illustrates how anchors may be specified to create inactive zones within an image map. The first anchor specifies a small circular region with no associated link. The second anchor specifies a larger circular region with the same center coordinates. Combined, the two form a ring whose center is inactive and whose rim is active. The order of the anchor definitions is important, since the smaller circle must override the larger circle.
<map name="map1"> <p> <A shape="circle" coords="100,200,50">I'm inactive.</A> <A href="outer-ring-link.html" shape="circle" coords="100,200,250">I'm active.</A> </map>
Similarly, the nohref attribute for the area element declares that geometric region has no associated link.
This section is normative.
This module defines elements and attributes for use in editing-related markup:
Element | Attributes | Minimal Content Model |
---|---|---|
del | Common, cite (URI), datetime (Datetime) | (PCDATA | Flow)* |
ins | Common, cite (URI), datetime (Datetime) | (PCDATA | Flow)* |
When this module is used, the del
and ins
elements are added to the Inline content set of the Text Module.
Implementation: DTD
The del element is used to indicate that a section of a document has been deleted with respect to a different version of the document (e.g., in draft legislation where lawmakers need to view the changes).
Attributes
This element is unusual for XHTML in that they may serve as either block-level or inline elements (but not both). It may contain one or more words within a paragraph or contain one or more block-level elements such as paragraphs, lists and tables.
This example could be from a bill to change the legislation for how many deputies a County Sheriff can employ from 3 to 5.
<p> A Sheriff can employ <del>3</del><ins>5</ins> deputies. </p>
The del element must not contain block-level content when it is behaving as an inline element.
ILLEGAL EXAMPLE:
The following is not legal HTML.
<p> <ins><div>...block-level content...</div></ins> </p>
User agents should render deleted text in ways that make the change obvious. For instance, inserted text may appear in a special font, deleted text may not be shown at all or be shown as struck-through or with special markings, etc.
Both of the following examples correspond to November 5, 2001, 8:15:30 am, US Eastern Standard Time.
2001-11-05T13:15:30Z 2001-11-05T08:15:30-05:00
Used with ins, this gives:
<ins datetime="2001-11-05T08:15:30-05:00" cite="http://www.example.org/mydoc/comments.html"> Furthermore, the latest figures from the marketing department suggest that such practice is on the rise. </ins>
The document "http://www.example.org/mydoc/comments.html" would contain comments about why information was inserted into the document.
Authors may also make comments about deleted text by means of the title attribute for the del element. User agents may present this information to the user (e.g., as a popup note). For example:
<del datetime="2001-11-05T08:15:30-05:00" title="Changed as a result of Steve G's comments in meeting."> Furthermore, the latest figures from the marketing department suggest that such practice is on the rise. </del>
The ins element is used to indicate that a section of a document has been inserted with respect to a different version of the document (e.g., in draft legislation where lawmakers need to view the changes).
Attributes
This element is unusual for XHTML in that they may serve as either block-level or inline elements (but not both). It may contain one or more words within a paragraph or contain one or more block-level elements such as paragraphs, lists and tables.
The ins element must not contain block-level content when it is behaving as an inline element.
ILLEGAL EXAMPLE:
The following is not legal HTML.
<p> <ins><div>...block-level content...</div></ins> </p>
User agents should render inserted text in ways that make the change obvious. For instance, inserted text may appear in a special font.
Both of the following examples correspond to November 5, 2001, 8:15:30 am, US Eastern Standard Time.
2001-11-05T13:15:30Z 2001-11-05T08:15:30-05:00
Used with ins, this gives:
<ins datetime="2001-11-05T08:15:30-05:00" cite="http://www.foo.org/mydoc/comments.html"> Furthermore, the latest figures from the marketing department suggest that such practice is on the rise. </ins>
The document "http://www.foo.org/mydoc/comments.html" would contain comments about why information was inserted into the document.
Authors may also make comments about inserted text by means of the title attribute for the ins element. User agents may present this information to the user (e.g., as a popup note). For example:
<ins datetime="2001-11-05T08:15:30-05:00" title="Changed as a result of Steve B's comments in meeting."> Furthermore, the latest figures from the marketing department suggest that such practice is on the rise. </ins>
This section is normative.
The Link Module defines an element that can be used to define links to external resources. These resources are often used to augment the user agent's ability to process the associated XHTML document. The element and attributes included in this module are:
Elements | Attributes | Minimal Content Model |
---|---|---|
link | Common, charset (Charset), hreflang (LanguageCode), media (MediaDesc), rel (LinkTypes), rev (LinkTypes), type (ContentType) | EMPTY |
When this module is used, it adds the link element to the content model of the head element as defined in the Structure Module.
Implementation: DTD
Attributes
Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address.
For the current list of registered content types, please consult [MIMETYPES].
This element defines a link. Unlike a, it may only appear in the head section of a document, although it may appear any number of times. Although link has no content, it conveys relationship information that may be rendered by user agents in a variety of ways (e.g., a tool-bar with a drop-down menu of links).
This example illustrates how several link definitions may appear in the head section of a document. The current document is "Chapter2.html". The rel attribute specifies the relationship of the linked document with the current document. The values "Index", "Next", and "Prev" are explained in the section on link types.
<head> <title>Chapter 2</title> <link rel="Index" href="../index.html"/> <link rel="Next" href="Chapter3.html"/> <link rel="Prev" href="Chapter1.html"/> </head>
While the rel attribute specifies a relationship from this document to another resource, the rev attribute specifies the reverse relationship.
Consider two documents A and B.
Document A: <link href="docB" rel="foo"/>
Has exactly the same meaning as:
Document B: <link href="docA" rev="foo"/>
Both the rel and rev attributes may be specified simultaneously.
When the link element links an external style sheet to a document, the type attribute specifies the style sheet language and the media attribute specifies the intended rendering medium or media. User agents may save time by retrieving from the network only those style sheets that apply to the current device.
Media descriptors are further discussed under Attribute Types.
Authors may use the link element to provide a variety of information to search engines, including:
The examples below illustrate how language information, media types, and link types may be combined to improve document handling by search engines.
The following example shows how to use the hreflang attribute to indicate to a search engine where to find Dutch, Portuguese, and Arabic versions of a document. Note the use of the charset attribute for the Arabic manual. Note also the use of the xml:lang attribute to indicate that the value of the title attribute for the link element designating the French manual is in French.
<head> <title>The manual in English</title> <link title="The manual in Dutch" type="text/html" rel="alternate" hreflang="nl" href="http://someplace.com/manual/dutch.html"/> <link title="The manual in Portuguese" type="text/html" rel="alternate" hreflang="pt" href="http://someplace.com/manual/portuguese.html"/> <link title="The manual in Arabic" type="text/html" rel="alternate" charset="ISO-8859-6" hreflang="ar" href="http://someplace.com/manual/arabic.html"/> <link lang="fr" title="La documentation en Français" type="text/html" rel="alternate" hreflang="fr" href="http://someplace.com/manual/french.html"/> </head>
In the following example, we tell search engines where to find the printed version of a manual.
<head> <title>Reference manual</title> <link media="print" title="The manual in postscript" type="application/postscript" rel="alternate" href="http://someplace.com/manual/postscript.ps"/> </head>
In the following example, we tell search engines where to find the front page of a collection of documents.
<head> <title>Reference manual -- Page 5</title> <link rel="Start" title="The first page of the manual" type="text/html" href="http://someplace.com/manual/start.html"/> </head>
This section is normative.
The Metainformation Module defines an element that describes information within the declarative portion of a document (in XHTML within the head element). This module includes the following element:
Elements | Attributes | Minimal Content Model |
---|---|---|
meta | I18N, content* (CDATA), http-equiv (NMTOKEN), name (NMTOKEN) | EMPTY |
When this module is selected, the meta element is added to the content model of the head element as defined in the Structure Module.
Implementation: DTD
For the following attributes, the permitted values and their interpretation are profile dependent:
Attributes
The meta element can be used to identify properties of a document (e.g., author, expiration date, a list of key words, etc.) and assign values to those properties. This specification does not define a normative set of properties.
Each meta element specifies a property/value pair. The name attribute identifies the property and the content attribute specifies the property's value.
For example, the following declaration sets a value for the Author property:
<meta name="Author" content="Dave Raggett"/>
The xml:lang attribute can be used with meta to specify the language for the value of the content attribute. This enables speech synthesizers to apply language dependent pronunciation rules.
In this example, the author's name is declared to be French:
<meta name="Author" lang="fr" content="Arnaud Le Hors"/>
Note. The meta element is a generic mechanism for specifying meta data. However, some XHTML elements and attributes already handle certain pieces of meta data and may be used by authors instead of meta to specify those pieces: the title element, the address element, the ins and del elements, the title attribute, and the cite attribute.
Note. When a property specified by a meta element takes a value that is a URI, some authors prefer to specify the meta data via the link element. Thus, the following meta data declaration:
<meta name="DC.identifier" content="http://www.ietf.org/rfc/rfc1866.txt"/>
might also be written:
<link rel="DC.identifier" type="text/plain" href="http://www.ietf.org/rfc/rfc1866.txt"/>
A common use for meta is to specify keywords that a search engine may use to improve the quality of search results. When several meta elements provide language-dependent information about a document, search engines may filter on the xml:lang attribute to display search results using the language preferences of the user. For example,
<-- For speakers of US English --> <meta name="keywords" lang="en-us" content="vacation, Greece, sunshine"/> <-- For speakers of British English --> <meta name="keywords" lang="en" content="holiday, Greece, sunshine"/> <-- For speakers of French --> <meta name="keywords" lang="fr" content="vacances, Grèce, soleil"/>
The effectiveness of search engines can also be increased by using the link element to specify links to translations of the document in other languages, links to versions of the document in other media (e.g., PDF), and, when the document is part of a collection, links to an appropriate starting point for browsing the collection.
The Platform for Internet Content Selection (PICS, specified in [PICS]) is an infrastructure for associating labels (meta data) with Internet content. Originally designed to help parents and teachers control what children can access on the Internet, it also facilitates other uses for labels, including code signing, privacy, and intellectual property rights management.
This example illustrates how one can use a meta declaration to include a PICS 1.1 label:
<head> <meta http-equiv="PICS-Label" content=' (PICS-1.1 "http://www.gcf.org/v2.5" labels on "1994.11.05T08:15-0500" until "1995.12.31T23:59-0000" for "http://w3.org/PICS/Overview.html" ratings (suds 0.5 density 0 color/hue 1)) '/> <title>... document title ...</title> </head>
The profile attribute of the html element specifies the location of a meta data profile. The value of the profile attribute is a URI. User agents may use this URI in two ways:
This example refers to a hypothetical profile that defines useful properties for document indexing. The properties defined by this profile -- including "author", "copyright", "keywords", and "date" -- have their values set by subsequent meta declarations.
<head profile="http://www.acme.com/profiles/core"> <title>How to complete Memorandum cover sheets</title> <meta name="author" content="John Doe"/> <meta name="copyright" content="© 1997 Acme Corp."/> <meta name="keywords" content="corporate,guidelines,cataloging"/> <meta name="date" content="1994-11-06T08:49:37+00:00"/> </head>
This section is normative.
The Object Module provides elements for general-purpose object inclusion; this includes images and other media, as well as executable content. Specifically, the Object Module supports:
Elements | Attributes | Minimal Content Model |
---|---|---|
object | Common, archive (URIs), classid (URI), codebase (URI), content-length (MultiLength) codetype (ContentType), data (URI), disabled ("disabled"), declare ("declare"), standby (Text), navindex (Number), type (ContentType) | (PCDATA | Flow | param)* |
param | id (ID), name* (CDATA), type (ContentType), value (CDATA), valuetype ("data"* | "ref" | "object") | EMPTY |
When this module is used, it adds the object
element to the Inline content set of the Text Module.
Implementation: DTD
Attributes
The navigation order defines the order in which elements will receive focus when navigated by the user via the keyboard. The navigation order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
Tabbing keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key is used for navigation and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the navigation order in reverse. When the end (or beginning) of the navigation order is reached, user agents may circle back to the beginning (or end).
Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address.
For the current list of registered content types, please consult [MIMETYPES].
Most user agents have built-in mechanisms for processing common data types such as text, GIF images, colors, fonts, and a handful of graphic elements. To process data types they don't support natively, user agents generally run external applications. The object element allows authors to control whether data should be processed externally or by some program, specified by the author, that processes the data within the user agent.
In the most general case, an author may need to specify three types of information:
The object element allows authors to specify all three types of data, but authors may not have to specify all three at once. For example, some objects may not require data (e.g., a self-contained applet that performs a small animation). Others may not require run-time initialization. Still others may not require additional implementation information, i.e., the user agent itself may already know how to process that type of data (e.g., GIF images).
Authors specify an object's implementation and the location of the data to be processed via the object element. To specify run-time values, however, authors use the param element, which is discussed in the section on object initialization.
The object element may also appear in the content of the head element. Since user agents generally do not process elements in the head, authors should ensure that any object elements in the head do not specify content that may be processed. Please consult the section on sharing frame data for an example of including the object element in the head element.
Please consult the section on form controls for information about object elements in forms.
This document does not specify the behavior of object elements that use both the classid attribute to identify an implementation and the data attribute to specify data for that implementation. In order to ensure portability, authors should use the param element to tell implementations where to retrieve additional data.
A user agent must interpret an object element according to the following precedence rules:
Authors should not include content in object elements that appear in the head element.
In the following example, we insert an analog clock applet in a document via the object element. The applet, written in the Python language, requires no additional data or run-time values. The classid attribute specifies the location of the applet:
<object classid="http://www.miamachina.it/analogclock.py"> </object>
Note that the clock will be processed as soon as the user agent interprets this object declaration. It is possible to delay processing of an object by first declaring the object (described below).
Authors should complete this declaration by including alternate text as the contents of object in case the user agent cannot process the clock.
<p><object classid="http://www.miamachina.it/analogclock.py"> An animated clock. </object>
One significant consequence of the object element's design is that it offers a mechanism for specifying alternate object processing; each embedded object declaration may specify alternate content types. If a user agent cannot process the outermost object, it tries to process the contents, which may be another object element, etc.
In the following example, we embed several object declarations to illustrate how alternate processing work. A user agent will attempt to process the first object element it can, in the following order: (1) an Earth applet written in the Python language, (2) an MPEG animation of the Earth, (3) a GIF image of the Earth, (4) alternate text.
<p> <!-- First, try the Python applet --> <object title="The Earth as seen from space" classid="http://www.observer.mars/TheEarth.py"> <!-- Else, try the MPEG video --> <object data="TheEarth.mpeg" type="application/mpeg"> <!-- Else, try the GIF image --> <object data="TheEarth.gif" type="image/gif"> <!-- Else render the text --> The <strong>Earth</strong> as seen from space. </object> </object> </object>
The outermost declaration specifies an applet that requires no data or initial values. The second declaration specifies an MPEG animation and, since it does not define the location of an implementation to handle MPEG, relies on the user agent to handle the animation. We also set the type attribute so that a user agent that knows it cannot process an MPEG will not bother to retrieve "TheEarth.mpeg" from the network. The third declaration specifies the location of a GIF file and furnishes alternate text in case all other mechanisms fail.
Inline vs. external data. Data to be processed may be supplied in two ways: inline and from an external resource. While the former method will generally lead to faster processing, it is not convenient when processing large quantities of data.
Here's an example that illustrates how inline data may be fed to an object:
<p> <object id="clock1" classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502" data="data:application/x-oleobject;base64, ...base64 data..."> A clock. </object>
Attributes
Possible values:
param elements specify a set of values that may be required by an object at run-time. Any number of param elements may appear in the content of an object element, in any order, but must be placed at the start of the content of the enclosing object element.
The syntax of names and values is assumed to be understood by the object's implementation. This document does not specify how user agents should retrieve name/value pairs nor how they should interpret parameter names that appear twice.
We return to the clock example to illustrate the use of param: suppose that the applet is able to handle two run-time parameters that define its initial height and width. We can set the initial dimensions to 40x40 pixels with two param.
<p><object classid="http://www.miamachina.it/analogclock.py"> <param name="height" value="40" valuetype="data" /> <param name="width" value="40" valuetype="data" /> This user agent cannot render Python applications. </object>
In the following example, run-time data for the object's "Init_values" parameter is specified as an external resource (a GIF file). The value of the valuetype attribute is thus set to "ref" and the value is a URI designating the resource.
<p><object classid="http://www.gifstuff.com/gifappli" standby="Loading Elvis..."> <param name="Init_values" value="./images/elvis.gif" valuetype="ref" /> </object> </p>
Note that we have also set the standby attribute so that the user agent may display a message while the rendering mechanism loads.
When an object element is rendered, user agents must search the content for only those param elements that are direct children and "feed" them to the object.
Thus, in the following example, if "obj1" is rendered, "param1" applies to "obj1" (and not "obj2"). If "obj1" is not rendered and "obj2" is, "param1" is ignored, and "param2" applies to "obj2". If neither object is rendered, neither param applies.
<p> <object id="obj1"> <param name="param1"> <object id="obj2"> <param name="param2"> </object> </object>
The location of an object's implementation is given by a URI. The first segment of an absolute URI specifies the naming scheme used to transfer the data designated by the URI. For XHTML documents, this scheme is frequently "http". Some applets might employ other naming schemes. For instance, when specifying a Java applet, authors may use URIs that begin with "java" and for ActiveX applets, authors may use "clsid".
In the following example, we insert a Java applet into an XHTML document.
<p><object classid="java:program.start"> </object>
By setting the codetype attribute, a user agent can decide whether to retrieve the Java application based on its ability to do so.
<object codetype="application/java-archive" classid="java:program.start"> </object>
Some rendering schemes require additional information to identify their implementation and must be told where to find that information. Authors may give path information to the object's implementation via the codebase attribute.
<object codetype="application/java-archive" classid="java:program.start"> codebase="http://foooo.bar.com/java/myimplementation/" </object>
The following example specifies (with the classid attribute) an ActiveX object via a URI that begins with the naming scheme "clsid". The data attribute locates the data to render (another clock).
<p><object classid="clsid:663C8FEF-1EF9-11CF-A3DB-080036F12502" data="http://www.acme.com/ole/clock.stm"> This application is not supported. </object>
The preceding examples have only illustrated isolated object definitions. When a document is to contain more than one instance of the same object, it is possible to separate the declaration of the object from its instantiations. Doing so has several advantages:
To declare an object so that it is not executed when read by the user agent, set the boolean declare attribute in the object element. At the same time, authors must identify the declaration by setting the id attribute in the object element to a unique value. Later instantiations of the object will refer to this identifier.
A declared object must appear in a document before the first instance of that object.
An object defined with the declare attribute is instantiated every time an element that refers to that object requires it to be rendered (e.g., a link that refers to it is activated, an object that refers to it is activated, etc.).
In the following example, we declare an object and cause it to be instantiated by referring to it from a link. Thus, the object can be activated by clicking on some highlighted text, for example.
<p><object declare id="earth.declaration" data="TheEarth.mpeg" type="application/mpeg"> The <strong>Earth</strong> as seen from space. </object> ...later in the document... <p>A neat <A href="#earth.declaration"> animation of The Earth!</A>
The following example illustrates how to specify run-time values that are other objects. In this example, we send text (a poem, in fact) to a hypothetical mechanism for viewing poems. The object recognizes a run-time parameter named "font" (say, for rendering the poem text in a certain font). The value for this parameter is itself an object that inserts (but does not render) the font object. The relationship between the font object and the poem viewer object is achieved by (1) assigning the id "tribune" to the font object declaration and (2) referring to it from the param element of the poem viewer object (with valuetype and value).
<p><object declare id="tribune" type="application/x-webfont" data="tribune.gif"> </object> ...view the poem in KublaKhan.txt here... <p><object classid="http://foo.bar.com/poem_viewer" data="KublaKhan.txt"> <param name="font" valuetype="object" value="#tribune"> <p>You're missing a really cool poem viewer ... </object>
User agents that don't support the declare attribute must render the contents of the object declaration.
This section is normative.
This module defines elements, attributes, and a minimal content model for simple presentation-related markup:
Element | Attributes | Minimal Content Model |
---|---|---|
hr | Common | EMPTY |
sub | Common | (PCDATA | Inline)* |
sup | Common | (PCDATA | Inline)* |
When this module is used, the hr element is added to the Block content set of the Text Module. In addition, the sub and sup elements are added to the Inline content set of the Text Module.
Implementation: DTD
The hr element places a horizontal line in the document.
Attributes
The sub element indicates that its contents should be presented as a subscript of the text baseline.
Attributes
Many scripts (e.g., French) require superscripts or subscripts for proper rendering. The sub and sup elements should be used to markup text in these cases.
H<sub>2</sub>O E = mc<sup>2</sup> <span lang="fr">M<sup>lle</sup> Dupont</span>
The sup element indicates that its contents should be presented as a super-script of the text baseline.
Attributes
Many scripts (e.g., French) require superscripts or subscripts for proper rendering. The sub and sup elements should be used to markup text in these cases.
H<sub>2</sub>O E = mc<sup>2</sup> <span lang="fr">M<sup>lle</sup> Dupont</span>
This section is normative.
The Scripting Module defines elements that are used to contain information pertaining to executable scripts or the lack of support for executable scripts. Elements and attributes included in this module are:
Elements | Attributes | Minimal Content Model |
---|---|---|
noscript | Common | (Heading | List | Block)+ |
script | charset (Charset), defer ("defer"), src (URI), type* (ContentType), xml:space="preserve" | PCDATA |
When this module is used, the script and noscript elements are added to the Block and Inline content sets of the Text Module. In addition, the script element is added to the content model of the head element defined in the Structure Module.
Implementation: DTD
Attributes
The noscript element allows authors to provide alternate content when a script is not executed. The content of a noscript element should only be rendered by a script-aware user agent in the following cases:
User agents that do not support client-side scripts must render this element's contents.
In the following example, a user agent that executes the script will include some dynamically created data in the document. If the user agent doesn't support scripts, the user may still retrieve the data through a link.
<script type="text/tcl"> ...some Tcl script to insert data... </script> <noscript> <p>Access the <a href="http://someplace.com/data">data.</a></p> </noscript>
Attributes
Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address.
For the current list of registered content types, please consult [MIMETYPES].
Attribute defer not found
The attribute defer was not able to be loaded by the document generator. This implies that either 1) the attribute is not yet defined, or 2) the name is incorrect.The script element places a script within a document. This element may appear any number of times in the head or body of an XHTML document.
The script may be defined within the contents of the script element or in an external file. If the src attribute is not set, user agents must interpret the contents of the element as the script. If the src has a URI value, user agents must ignore the element's contents and retrieve the script via the URI. Note that the charset attribute refers to the character encoding of the script designated by the src attribute; it does not concern the content of the script element.
Scripts are evaluated by script engines that must be known to a user agent.
The syntax of script data depends on the scripting language.
As XHTML does not rely on a specific scripting language, document authors must explicitly tell user agents the language of each script. This may be done either through a default declaration or a local declaration.
The type attribute must be specified for each script element instance in a document.
In this example, we include one script in the header, whose script is located in an external file and is in the scripting language "text/vbscript". We also include one script in the body, which contains its own script written in "text/javascript".
<html xmlns="http://www.w3.org/2002/06/xhtml2"> <head> <title>A document with script</title> <script type="text/vbscript" src="http://someplace.com/progs/vbcalc"/> </head> <body> <script type="text/javascript"> ...some JavaScript... </script> </body> </html>
Each scripting language has its own conventions for referring to XHTML objects from within a script. This specification does not define a standard mechanism for referring to XHTML objects.
Scripts that are executed when a document is loaded may be able to modify the document's contents dynamically. The ability to do so depends on the scripting language itself (e.g., the "document.write" statement in the XHTML object model supported by some vendors).
The dynamic modification of a document may be modeled as follows:
XHTML documents are constrained to conform to the XHTML DTD both before and after processing any script elements.
The following example illustrates how scripts may modify a document dynamically. The following script:
... <title>Test Document</title> ... <script type="text/javascript"> document.write("<p><b>Hello World!<\/b><\/p>") </script> ...
Has the same effect as this markup:
... <title>Test Document</title> ... <p><b>Hello World!</b></p> ...
This section is normative.
The Server-side Image Map Module provides support for image-selection and transmission of selection coordinates. It requires that the Object Module (or another module that supports the object element) be included. The Server-side Image Map Module supports the following attributes:
Elements | Attributes | Minimal Content Model | Notes |
---|---|---|---|
img& | ismap ("ismap") | n/a | |
input& | ismap ("ismap") | n/a | When the Forms Module is selected. |
Implementation: DTD
In the following example, the active region defines a server-side link. Thus, a click anywhere on the image will cause the click's coordinates to be sent to the server.
<p><a href="http://www.example.com/cgi-bin/competition"> <object src="game.gif" ismap="ismap" alt="target" /></a></p>
The location clicked is passed to the server as follows. The user agent derives a new URI from the URI specified by the href attribute of the a element, by appending `?' followed by the x and y coordinates, separated by a comma. The link is then followed using the new URI. For instance, in the given example, if the user clicks at the location x=10, y=27 then the derived URI is "http://www.example.com/cgi-bin/competition?10,27".
User agents that do not offer the user a means to select specific coordinates (e.g., non-graphical user agents that rely on keyboard input, speech-based user agents, etc.) should send the coordinates "0,0" to the server when the link is activated.
This section is normative.
The Style Sheet Module defines an element to be used when declaring internal style sheets. The element and attributes defined by this module are:
Elements | Attributes | Minimal Content Model |
---|---|---|
style | I18N, id (ID), media (MediaDesc), title (Text), type* (ContentType), xml:space="preserve" | PCDATA |
When this module is used, it adds the style element to the content model of the head element of the Structure Module.
Implementation: DTD
Attributes
Authors who use this attribute take responsibility to manage the risk that it may become inconsistent with the content available at the link target address.
For the current list of registered content types, please consult [MIMETYPES].
The style element allows an author to put style sheet rules in the head of the document. XHTML permits any number of style elements in the head section of a document.
User agents that don't support style sheets, or don't support the specific style sheet language used by a style element, must hide the contents of the style element. It is an error to render the content as part of the document's text.
The syntax of style data depends on the style sheet language.
Rules for style rule precedences and inheritance depend on the style sheet language.
The following CSS style declaration puts a border around every h1 element in the document and centers it on the page.
<head> <style type="text/css"> h1 {border-width: thin; border-style: solid; text-align: center} </style> </head>
To specify that this style information should only apply to h1 elements of a specific class, we modify it as follows:
<head> <style type="text/css"> h1.myclass {border-width: thin; border-style: solid; text-align: center} </style> </head> <body> <h1 class="myclass"> This h1 is affected by our style </h1> <h1> This one is not affected by our style </h1> </body>
Finally, to limit the scope of the style information to a single instance of h1, set the id attribute:
<head> <style type="text/css"> #myid {border-width: thin; border-style: solid; text-align: center} </style> </head> <body> <h1 class="myclass"> This h1 is not affected </h1> <h1 id="myid"> This h1 is affected by style </h1> <h1> This h1 is not affected </h1> </body>
Although style information may be set for almost every XHTML element, two elements, div and span, are particularly useful in that they do not impose any presentation semantics (besides block-level vs. inline). When combined with style sheets, these elements allow users to extend XHTML indefinitely, particularly when used with the class and id attributes.
In the following example, we use the span element to set the font style of the first few words of a paragraph to small caps.
<head> <style type="text/css"> span.sc-ex { font-variant: small-caps } </style> </head> <body> <p><span class="sc-ex">The first</span> few words of this paragraph are in small-caps.</p> </body>
In the following example, we use div and the class attribute to set the text justification for a series of paragraphs that make up the abstract section of a scientific article. This style information could be reused for other abstract sections by setting the class attribute elsewhere in the document.
<head> <style type="text/css"> div.Abstract { text-align: justify } </style> </head> <body> <div class="Abstract"> <p>The Chieftain product range is our market winner for the coming year. This report sets out how to position Chieftain against competing products.</p> <p>Chieftain replaces the Commander range, which will remain on the price list until further notice.</p> </div> </body>
Authors may separate style sheets from XHTML documents. This offers several benefits:
XHTML allows authors to associate any number of external style sheets with a document. The style sheet language defines how multiple external style sheets interact (for example, the CSS "cascade" rules).
>Authors may specify a number of mutually exclusive style sheets called alternate style sheets. Users may select their favorite among these depending on their preferences. For instance, an author may specify one style sheet designed for small screens and another for users with weak vision (e.g., large fonts). User agents should allow users to select from alternate style sheets.
The author may specify that one of the alternates is a preferred style sheet. User agents should apply the author's preferred style sheet unless the user has selected a different alternate.
Authors may group several alternate style sheets (including the author's preferred style sheets) under a single style name. When a user selects a named style, the user agent must apply all style sheets with that name. User agents must not apply alternate style sheets with a different style name. The section on specifying external style sheets explains how to name a group of style sheets.
User agents must respect media descriptors when applying any style sheet.
User agents should also allow users to disable the author's style sheets entirely, in which case the user agent must not apply any persistent or alternate style sheets.
Authors specify external style sheets with the following attributes of the link element:
User agents should provide a means for users to view and pick from the list of alternate styles. The value of the title attribute is recommended as the name of each choice.
In this example, we first specify a persistent style sheet located in the file mystyle.css:
<link href="mystyle.css" rel="stylesheet" type="text/css"/>
Setting the title attribute makes this the author's preferred style sheet:
<link href="mystyle.css" title="compact" rel="stylesheet" type="text/css"/>
Adding the keyword "alternate" to the rel attribute makes it an alternate style sheet:
<link href="mystyle.css" title="Medium" rel="alternate stylesheet" type="text/css"/>
For more information on external style sheets, please consult the section on links and external style sheets.
If two or more link elements specify a preferred style sheet, the first one takes precedence.
This section is normative.
As its name suggests, the Tables Module provides table-related elements that are updated to enable access by non-visual user agents. Specifically, the Tables Module supports the following elements, attributes, and content model:
Elements | Attributes | Minimal Content Model |
---|---|---|
table | Common, summary (Text) | caption?, ( col* | colgroup* ), (( thead?, tfoot?, tbody+ ) | ( tr+ )) |
caption | Common | (PCDATA | Inline)* |
col | Common, span (Number) | EMPTY |
colgroup | Common, span (Number) | col* |
thead | Common | tr+ |
tfoot | Common | tr+ |
tbody | Common | tr+ |
tr | Common | ( td | th)+ |
td | Common, abbr (Text), axis (CDATA), colspan (Number), headers (IDREFS), rowspan (Number), scope ("row", "col", "rowgroup", "colgroup") | (PCDATA | Flow)* |
th | Common, abbr (Text), axis (CDATA), colspan (Number), headers (IDREFS), rowspan (Number), scope ("row", "col", "rowgroup", "colgroup") | (PCDATA | Flow)* |
When this module is used, it adds the table element to the Block content set of the Text Module.
Implementation: DTD
Attributes
When present, the caption element's text should describe the nature of the table. The caption element is only permitted immediately after the table start tag. A table element may only contain one caption element.
Caption Clipping
The following text was included in HTML 4 - should we make this a "MUST" in XHTML 2 for visual user agents?
Visual user agents should avoid clipping any part of the table including the caption, unless a means is provided to access all parts, e.g., by horizontal or vertical scrolling. We recommend that the caption text be wrapped to the same width as the table.
Attributes
Values mean the following:
User agents must ignore this attribute if the colgroup element contains one or more col elements.
The colgroup element allows authors to create structural divisions within a table. Authors may highlight this structure through style sheets.
A table may either contain a single implicit column group (no colgroup element delimits the columns) or any number of explicit column groups (each delimited by an instance of the colgroup element).
The col element allows authors to share attributes among several columns without implying any structural grouping. The "span" of the col element is the number of columns that will share the element's attributes.
The colgroup element creates an explicit column group. The number of columns in the column group may be specified in two, mutually exclusive ways:
The advantage of using the colgroup attribute is that authors may group information about multiple columns.
When it is necessary to single out a column (e.g., for style information, to specify width information, etc.) within a group, authors must identify that column with a col element.
The col element allows authors to group together attribute specifications for table columns. The col does not group columns together structurally -- that is the role of the colgroup element. col elements are empty and serve only as a support for attributes. They may appear inside or outside an explicit column group (i.e., colgroup element).
Attributes
The table element contains all other elements that specify caption, rows, content, and formatting for a table.
The directionality of a table is either the inherited directionality (the default is left-to-right) or that specified by the dir attribute for the table element.
For a left-to-right table, column zero is on the left side and row zero is at the top. For a right-to-left table, column zero is on the right side and row zero is at the top.
When a user agent allots extra cells to a row, extra row cells are added to the right of the table for left-to-right tables and to the left side for right-to-left tables.
Note that table is the only element on which dir reverses the visual order of the columns; a single table row ( tr) or a group of columns ( colgroup) cannot be independently reversed.
When set for the table element, the dir attribute also affects the direction of text within table cells (since the dir attribute is inherited by block-level elements).
To specify a right-to-left table, set the dir attribute as follows:
<table dir="rtl"> ...the rest of the table... </table>
The direction of text in individual cells can be changed by setting the dir attribute in an element that defines the cell. Please consult the section on bidirectional text for more information on text direction issues.
This section provides more detailed discussion on cell header data and how non-visual agents may utilize that information.
Non-visual user agents such as speech synthesizers and Braille-based devices may use the following td and th element attributes to render table cells more intuitively:
In the following example, we assign header information to cells by setting the headers attribute. Each cell in the same column refers to the same header cell (via the id attribute).
<table summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar."> <caption>Cups of coffee consumed by each senator</caption> <tbody> <tr> <th id="t1">Name</th> <th id="t2">Cups</th> <th id="t3" abbr="Type">Type of Coffee</th> <th id="t4">Sugar?</th> </tr> <tr> <td headers="t1">T. Sexton</td> <td headers="t2">10</td> <td headers="t3">Espresso</td> <td headers="t4">No</td> </tr> <tr> <td headers="t1">J. Dinnen</td> <td headers="t2">5</td> <td headers="t3">Decaf</td> <td headers="t4">Yes</td> </tr> </tbody> </table>
A speech synthesizer might render this table as follows:
Caption: Cups of coffee consumed by each senator Summary: This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar. Name: T. Sexton, Cups: 10, Type: Espresso, Sugar: No Name: J. Dinnen, Cups: 5, Type: Decaf, Sugar: Yes
Note how the header "Type of Coffee" is abbreviated to "Type" using the abbr attribute.
Here is the same example substituting the scope attribute for the headers attribute. Note the value "col" for the scope attribute, meaning "all cells in the current column":
<table summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar."> <caption>Cups of coffee consumed by each senator</caption> <tbody> <tr> <th scope="col">Name</th> <th scope="col">Cups</th> <th scope="col" abbr="Type">Type of Coffee</th> <th scope="col">Sugar?</th> </tr> <tr> <td>T. Sexton</td> <td>10</td> <td>Espresso</td> <td>No</td> </tr> <tr> <td>J. Dinnen</td> <td>5</td> <td>Decaf</td> <td>Yes</td> </tbody> </table>
Here's a somewhat more complex example illustrating other values for the scope attribute:
<table summary="History courses offered in the community of Bath arranged by course name, tutor, summary, code, and fee"> <tbody> <tr> <th colspan="5" scope="colgroup">Community Courses -- Bath Autumn 1997</th> </tr> <tr> <th scope="col" abbr="Name">Course Name</th> <th scope="col" abbr="Tutor">Course Tutor</th> <th scope="col">Summary</th> <th scope="col">Code</th> <th scope="col">Fee</th> </tr> <tr> <td scope="row">After the Civil War</td> <td>Dr. John Wroughton</td> <td> The course will examine the turbulent years in England after 1646. <em>6 weekly meetings starting Monday 13th October.</em> </td> <td>H27</td> <td>£32</td> </tr> <tr> <td scope="row">An Introduction to Anglo-Saxon England</td> <td>Mark Cottle</td> <td> One day course introducing the early medieval period reconstruction the Anglo-Saxons and their society. <em>Saturday 18th October.</em> </td> <td>H28</td> <td>£18</td> </tr> <tr> <td scope="row">The Glory that was Greece</td> <td>Valerie Lorenz</td> <td> Birthplace of democracy, philosophy, heartland of theater, home of argument. The Romans may have done it but the Greeks did it first. <em>Saturday day school 25th October 1997</em> </td> <td>H30</td> <td>£18</td> </tr> </tbody> </table>
A graphical user agent might render this as:
Note the use of the scope attribute with the "row" value. Although the first cell in each row contains data, not header information, the scope attribute makes the data cell behave like a row header cell. This allows speech synthesizers to provide the relevant course name upon request or to state it immediately before each cell's content.
Users browsing a table with a speech-based user agent may wish to hear an explanation of a cell's contents in addition to the contents themselves. One way the user might provide an explanation is by speaking associated header information before speaking the data cell's contents (see the section on associating header information with data cells).
Users may also want information about more than one cell, in which case header information provided at the cell level (by headers, scope, and abbr) may not provide adequate context. Consider the following table, which classifies expenses for meals, hotels, and transport in two locations (San Jose and Seattle) over several days:
Users might want to extract information from the table in the form of queries:
Each query involves a computation by the user agent that may involve zero or more cells. In order to determine, for example, the costs of meals on 25 August, the user agent must know which table cells refer to "Meals" (all of them) and which refer to "Dates" (specifically, 25 August), and find the intersection of the two sets.
To accommodate this type of query, the table model allows authors to place cell headers and data into categories. For example, for the travel expense table, an author could group the header cells "San Jose" and "Seattle" into the category "Location", the headers "Meals", "Hotels", and "Transport" in the category "Expenses", and the four days into the category "Date". The previous three questions would then have the following meanings:
Authors categorize a header or data cell by setting the axis attribute for the cell. For instance, in the travel expense table, the cell containing the information "San Jose" could be placed in the "Location" category as follows:
<th id="a6" axis="location">San Jose</th>
Any cell containing information related to "San Jose" should refer to this header cell via either the headers or the scope attribute. Thus, meal expenses for 25-Aug-1997 should be marked up to refer to id attribute (whose value here is "a6") of the "San Jose" header cell:
<td headers="a6">37.74</td>
Each headers attribute provides a list of id references. Authors may thus categorize a given cell in any number of ways (or, along any number of "headers", hence the name).
Below we mark up the travel expense table with category information:
<table summary="This table summarizes travel expenses incurred during August trips to San Jose and Seattle"> <caption>Travel Expense Report</caption> <tbody> <tr> <th></th> <th id="a2" axis="expenses">Meals</th> <th id="a3" axis="expenses">Hotels</th> <th id="a4" axis="expenses">Transport</th> <td>subtotals</td> </tr> <tr> <th id="a6" axis="location">San Jose</th> <th></th> <th></th> <th></th> <td></td> </tr> <tr> <td id="a7" axis="date">25-Aug-97</td> <td headers="a6 a7 a2">37.74</td> <td headers="a6 a7 a3">112.00</td> <td headers="a6 a7 a4">45.00</td> <td></td> </tr> <tr> <td id="a8" axis="date">26-Aug-97</td> <td headers="a6 a8 a2">27.28</td> <td headers="a6 a8 a3">112.00</td> <td headers="a6 a8 a4">45.00</td> <td></td> </tr> <tr> <td>subtotals</td> <td>65.02</td> <td>224.00</td> <td>90.00</td> <td>379.02</td> </tr> <tr> <th id="a10" axis="location">Seattle</th> <th></th> <th></th> <th></th> <td></td> </tr> <tr> <td id="a11" axis="date">27-Aug-97</td> <td headers="a10 a11 a2">96.25</td> <td headers="a10 a11 a3">109.00</td> <td headers="a10 a11 a4">36.00</td> <td></td> </tr> <tr> <td id="a12" axis="date">28-Aug-97</td> <td headers="a10 a12 a2">35.00</td> <td headers="a10 a12 a3">109.00</td> <td headers="a10 a12 a4">36.00</td> <td></td> </tr> <tr> <td>subtotals</td> <td>131.25</td> <td>218.00</td> <td>72.00</td> <td>421.25</td> </tr> <tr> <th>Totals</th> <td>196.27</td> <td>442.00</td> <td>162.00</td> <td>800.27</td> </tr> </tbody> </table>
Note that marking up the table this way also allows user agents to avoid confusing the user with unwanted information. For instance, if a speech synthesizer were to speak all of the figures in the "Meals" column of this table in response to the query "What were all my meal expenses?", a user would not be able to distinguish a day's expenses from subtotals or totals. By carefully categorizing cell data, authors allow user agents to make important semantic distinctions when rendering.
Of course, there is no limit to how authors may categorize information in a table. In the travel expense table, for example, we could add the additional categories "subtotals" and "totals".
This specification does not require user agents to handle information provided by the axis attribute, nor does it make any recommendations about how user agents may present axis information to users or how users may query the user agent about this information.
However, user agents, particularly speech synthesizers, may want to factor out information common to several cells that are the result of a query. For instance, if the user asks "What did I spend for meals in San Jose?", the user agent would first determine the cells in question (25-Aug-1997: 37.74, 26-Aug-1997:27.28), then render this information. A user agent speaking this information might read it:
Location: San Jose. Date: 25-Aug-1997. Expenses, Meals: 37.74 Location: San Jose. Date: 26-Aug-1997. Expenses, Meals: 27.28
or, more compactly:
San Jose, 25-Aug-1997, Meals: 37.74 San Jose, 26-Aug-1997, Meals: 27.28
An even more economical rendering would factor the common information and reorder it:
San Jose, Meals, 25-Aug-1997: 37.74 26-Aug-1997: 27.28
User agents that support this type of rendering should allow user agents a means to customize rendering (e.g., through style sheets).
This sample illustrates grouped rows and columns.
<table summary="Calendar for 2002."> <caption><b>Calendar for 2002</b></caption> <colgroup span="7"> <colgroup span="7"> <colgroup span="7"> <thead> <tr> <th colspan="7">January</th> <th colspan="7">February</th> <th colspan="7">March</th> </tr> </thead> <tbody> <tr> <td>S</td> <td>M</td> <td>T</td> <td>W</td> <td>T</td> <td>F</td> <td>S</td> <td>S</td> <td>M</td> <td>T</td> <td>W</td> <td>T</td> <td>F</td> <td>S</td> <td>S</td> <td>M</td> <td>T</td> <td>W</td> <td>T</td> <td>F</td> <td>S</td> </tr> </tbody> <tbody> <tr> <td></td> <td></td> <td>1</td> <td>2</td> <td>3</td> <td>4</td> <td>5</td> <td></td> <td></td> <td></td> <td></td> <td></td> <td>1</td> <td>2</td> <td></td> <td></td> <td></td> <td></td> <td></td> <td>1</td> <td>2</td> </tr> <tr> <td>6</td> <td>7</td> <td>8</td> <td>9</td> <td>10</td> <td>11</td> <td>12</td> <td>3</td> <td>4</td> <td>5</td> <td>6</td> <td>7</td> <td>8</td> <td>9</td> <td>3</td> <td>4</td> <td>5</td> <td>6</td> <td>7</td> <td>8</td> <td>9</td> </tr> <tr> <td>13</td> <td>14</td> <td>15</td> <td>16</td> <td>17</td> <td>18</td> <td>19</td> <td>10</td> <td>11</td> <td>12</td> <td>13</td> <td>14</td> <td>15</td> <td>16</td> <td>10</td> <td>11</td> <td>12</td> <td>13</td> <td>14</td> <td>15</td> <td>16</td> </tr> <tr> <td>20</td> <td>21</td> <td>22</td> <td>23</td> <td>24</td> <td>25</td> <td>26</td> <td>17</td> <td>18</td> <td>19</td> <td>20</td> <td>21</td> <td>22</td> <td>23</td> <td>17</td> <td>18</td> <td>19</td> <td>20</td> <td>21</td> <td>22</td> <td>23</td> </tr> <tr> <td>27</td> <td>28</td> <td>29</td> <td>30</td> <td>31</td> <td></td> <td></td> <td>24</td> <td>25</td> <td>26</td> <td>27</td> <td>28</td> <td></td> <td></td> <td>24</td> <td>25</td> <td>26</td> <td>27</td> <td>28</td> <td>29</td> <td>30</td> </tr> <tr> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> <td>31</td> <td></td> <td></td> <td></td> <td></td> <td></td> <td></td> </tr> </tbody> </table>
would be rendered something like this:
Calendar for 2002 =================================================================== January | February | March S M T W T F S | S M T W T F S | S M T W T F S ------------------------------------------------------------------- 1 2 3 4 5 | 1 2 | 1 2 6 7 8 9 10 11 12 | 3 4 5 6 7 8 9 | 3 4 5 6 7 8 9 13 14 15 16 17 18 19 | 10 11 12 13 14 15 16| 10 11 12 13 14 15 16 20 21 22 23 24 25 26 | 17 18 19 20 21 22 23| 17 18 19 20 21 22 23 27 28 29 30 31 | 24 25 26 27 28 | 24 25 26 27 28 29 30 | | 31 ====================================================================
A graphical user agent might render this as:
This example illustrates how colgroup can be used to group columns and set the default column alignment. Similarly, tbody is used to group rows.
Attributes
The tbody element contains rows of table data. In tables that also contain thead or tfoot elements, all of these sections must contain the same number of columns.
Attributes
Table cells may contain two types of information: header information and data. This distinction enables user agents to render header and data cells distinctly, even in the absence of style sheets. For example, visual user agents may present header cell text with a bold font. Speech synthesizers may render header information with a distinct voice inflection.
The th element defines a cell that contains header information. User agents have two pieces of header information available: the contents of the th element and the value of the abbr attribute. User agents must render either the contents of the cell or the value of the abbr attribute. For visual media, the latter may be appropriate when there is insufficient space to render the full contents of the cell. For non-visual media abbr may be used as an abbreviation for table headers when these are rendered along with the contents of the cells to which they apply.
The headers and scope attributes also allow authors to help non-visual user agents process header information. Please consult the section on labeling cells for non-visual user agents for information and examples.
The td element defines a cell that contains data.
Cells may be empty (i.e., contain no data).
For example, the following table contains four columns of data, each headed by a column description.
<table summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar."> <caption>Cups of coffee consumed by each senator</caption> <tbody> <tr> <th>Name</th> <th>Cups</th> <th>Type of Coffee</th> <th>Sugar?</th> </tr> <tr> <td>T. Sexton</td> <td>10</td> <td>Espresso</td> <td>No</td> </tr> <tr> <td>J. Dinnen</td> <td>5</td> <td>Decaf</td> <td>Yes</td> </tbody> </table>
A user agent rendering to a tty device might display this as follows:
Name Cups Type of Coffee Sugar? T. Sexton 10 Espresso No J. Dinnen 5 Decaf Yes
Cells may span several rows or columns. The number of rows or columns spanned by a cell is set by the rowspan and colspan attributes for the th and td elements.
In this table definition, we specify that the cell in row four, column two should span a total of three columns, including the current column.
<table> <caption>Cups of coffee consumed by each senator</caption> <tbody> <tr> <th>Name</td> <th>Cups</td> <th>Type of Coffee</td> <th>Sugar?</td> </tr> <tr> <td>T. Sexton</td> <td>10</td> <td>Espresso</td> <td>No</td> </tr> <tr> <td>J. Dinnen</td> <td>5</td> <td>Decaf</td> <td>Yes</td> </tr> <tr> <td>A. Soria</td> <td colspan="3"><em>Not available</em></td> </tr> </tbody> </table>
This table might be rendered on a tty device by a visual user agent as follows:
Cups of coffee consumed by each senator -------------------------------------- | Name |Cups|Type of Coffee|Sugar?| -------------------------------------- |T. Sexton|10 |Espresso |No | -------------------------------------- |J. Dinnen|5 |Decaf |Yes | -------------------------------------- |A. Soria |Not available | --------------------------------------
The next example illustrates (with the help of table borders) how cell definitions that span more than one row or column affect the definition of later cells. Consider the following table definition:
<table> <tbody> <tr> <td>1</td> <td rowspan="2">2</td> <td>3</td> </tr> <tr> <td>4 <td>6</td> </tr> <tr> <td>7</td> <td>8</td> <td>9</td> </td></td> </tr> </tbody> </table>
As cell "2" spans the first and second rows, the definition of the second row will take it into account. Thus, the second td in row two actually defines the row's third cell. Visually, the table might be rendered to a tty device as:
------------- | 1 | 2 | 3 | ----| |---- | 4 | | 6 | ----|---|---- | 7 | 8 | 9 | -------------
while a graphical user agent might render this as:
Note that if the td defining cell "6" had been omitted, an extra empty cell would have been added by the user agent to complete the row.
Similarly, in the following table definition:
<table> <tbody> <tr> <td>1</td> <td>2</td> <td>3</td> </tr> <tr> <td colspan="2">4</td> <td>6</td> </tr> <tr> <td>7</td> <td>8</td> <td>9</td> </tr> </tbody> </table>
cell "4" spans two columns, so the second td in the row actually defines the third cell ("6"):
------------- | 1 | 2 | 3 | --------|---- | 4 | 6 | --------|---- | 7 | 8 | 9 | -------------
A graphical user agent might render this as:
Defining overlapping cells is an error. User agents may vary in how they handle this error (e.g., rendering may vary).
The following illegal example illustrates how one might create overlapping cells. In this table, cell "5" spans two rows and cell "7" spans two columns, so there is overlap in the cell between "7" and "9":
<table"> <tbody> <tr> <td>1</td> <td>2</td> <td>3</td> </tr> <tr> <td>4</td> <td rowspan="2">5</td> <td>6</td> </tr> <tr> <td colspan="2">7</td> <td>9</td> </tr> </tbody> </table>
Attributes
Table rows may be grouped into a table head, table foot, and one or more table body sections, using the thead, tfoot and tbody elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
The table head and table foot should contain information about the table's columns. The table body should contain rows of table data.
When present, each thead, tfoot, and tbody contains a row group. Each row group must contain at least one row, defined by the tr element.
If the thead, tfoot, and tbody elements are used, and a rowspan attriubte is used within a group, the rowspan must remain within the group boundaries of which it is defined.
This example illustrates the order and structure of the table head, foot, and bodies.
<table> <thead> <tr> ...header information...</tr> </thead> <tfoot> <tr> ...footer information...</tr> </tfoot> <tbody> <tr> ...first row of block one data...</tr> <tr> ...second row of block one data...</tr> </tbody> <tbody> <tr> ...first row of block two data...</tr> <tr> ...second row of block two data...</tr> <tr> ...third row of block two data...</tr> </tbody> </table>
tfoot must appear before tbody within a table definition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data.
Attributes
The tr elements acts as a container for a row of table cells. The end tag may be omitted.
This sample table contains three rows, each begun by the tr element:
<table summary="This table charts the number of cups of coffee consumed by each senator, the type of coffee (decaf or regular), and whether taken with sugar."> <caption>Cups of coffee consumed by each senator</caption> <tbody> <tr> ...A header row...</tr> <tr> ...First row of data...</tr> <tr> ...Second row of data...</tr> ...the rest of the table...</tr> </tbody> </table>
This section is normative.
The content of a frame can specify destination targets for a selection. This module adds the target
attribute to the area and link defining elements. This is defined as a separate
module so it can be included in documents that will be included in frames and documents that use the target
feature to open a new window.
Elements | Attributes | Notes |
---|---|---|
a& | target (CDATA) | |
link& | target (CDATA) | When the Link Module is selected. |
form& | target (CDATA) | When the Forms module is selected. |
Implementation: DTD
This specification does not define how this attribute gets used, since that is defined by the environment that the hyperlink is evaluated in.
XFrames not published yet
We need a reference to XFrames here, but XFrames is not yet public.This appendix is informative.
This Appendix describes the differences between XHTML 2.0 and XHTML 1.1.
Change summary needed
This section needs a table that illustrates elements removed and added, and changes made to elements that were kept.
This appendix is normative.
This appendix will contain the implementation of the XHTML 2.0 Schema driver file and content model file.
XHTML 2.0 Schema Needed
The XHTML 2.0 Schema driver and content model files need to be built.
This appendix is normative.
This appendix will contain implementations of the modules defined in this specification via XML Schema [XMLSCHEMA] when XML Schema becomes a W3C Recommendation.
This appendix is normative.
This appendix will contain the implementation of the XHTML 2.0 DTD driver file and content model file.
XHTML 2.0 DTD Needed
The XHTML 2.0 DTD driver and content model files need to be built. There is an open issue about how to integrate the XForms instance data into such a DTD.
This appendix is normative.
This appendix will contain implementations of the modules defined in this specification. These module implementations can be used in other XHTML Family Document Types.
In order to take advantage of the XHTML DTD Modules, DTD authors need to define the content model for their DTD. XHTML provides a variety of tools to ease this effort. They are defined in a set of support modules, instantiated by a main Framework module:
Module DTD/xhtml-framework-2.mod not found!
Note that the module above references a content model module. This module is defined on a per-document type basis in addition to the document type driver file. The Modular framework also relies upon the following component modules:
DTD Module XHTML Base Architecture needed
The DTD Module DTD Module XHTML Base Architecture needed referenced as DTD/xhtml-arch-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Notations needed
The DTD Module DTD Module XHTML Notations needed referenced as DTD/xhtml-notations-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Datatypes needed
The DTD Module DTD Module XHTML Datatypes needed referenced as DTD/xhtml-datatypes-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Common Attribute Definitions needed
The DTD Module DTD Module XHTML Common Attribute Definitions needed referenced as DTD/xhtml-attribs-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Qualified Names needed
The DTD Module DTD Module XHTML Qualified Names needed referenced as DTD/xhtml-qname-2.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module XHTML Character Entities needed
The DTD Module DTD Module XHTML Character Entities needed referenced as DTD/xhtml-charent-1.mod needs to be defined. It will be defined before publication of a last call draft.
This section contains the formal definition of each of the XHTML Abstract Modules as a DTD module.
DTD Module Structure needed
The DTD Module DTD Module Structure needed referenced as DTD/xhtml-struct-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Text needed
The DTD Module DTD Module Text needed referenced as DTD/xhtml-text-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Hypertext needed
The DTD Module DTD Module Hypertext needed referenced as DTD/xhtml-hypertext-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Lists needed
The DTD Module DTD Module Lists needed referenced as DTD/xhtml-list-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Bi-directional Text needed
The DTD Module DTD Module Bi-directional Text needed referenced as DTD/xhtml-bdo-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Client-side Image Map needed
The DTD Module DTD Module Client-side Image Map needed referenced as DTD/xhtml-csismap-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Edit needed
The DTD Module DTD Module Edit needed referenced as DTD/xhtml-edit-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Link needed
The DTD Module DTD Module Link needed referenced as DTD/xhtml-link-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Metainformation needed
The DTD Module DTD Module Metainformation needed referenced as DTD/xhtml-meta-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Object needed
The DTD Module DTD Module Object needed referenced as DTD/xhtml-object-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Presentation needed
The DTD Module DTD Module Presentation needed referenced as DTD/xhtml-pres-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Scripting needed
The DTD Module DTD Module Scripting needed referenced as DTD/xhtml-script-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Server-side Image Map needed
The DTD Module DTD Module Server-side Image Map needed referenced as DTD/xhtml-ssismap-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Style Sheet needed
The DTD Module DTD Module Style Sheet needed referenced as DTD/xhtml-style-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Tables needed
The DTD Module DTD Module Tables needed referenced as DTD/xhtml-table-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Target needed
The DTD Module DTD Module Target needed referenced as DTD/xhtml-target-1.mod needs to be defined. It will be defined before publication of a last call draft.
The modules in this section are elements of the XHTML DTD implementation that, while hidden from casual users, are important to understand when creating derivative markup languages using the Modularization architecture.
DTD Module Block Phrasal needed
The DTD Module DTD Module Block Phrasal needed referenced as DTD/xhtml-blkphras-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Block Presentational needed
The DTD Module DTD Module Block Presentational needed referenced as DTD/xhtml-blkpres-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Block Structural needed
The DTD Module DTD Module Block Structural needed referenced as DTD/xhtml-blkstruct-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Inline Phrasal needed
The DTD Module DTD Module Inline Phrasal needed referenced as DTD/xhtml-inlphras-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Inline Presentational needed
The DTD Module DTD Module Inline Presentational needed referenced as DTD/xhtml-inlpres-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Inline Structural needed
The DTD Module DTD Module Inline Structural needed referenced as DTD/xhtml-inlstruct-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Param needed
The DTD Module DTD Module Param needed referenced as DTD/xhtml-param-1.mod needs to be defined. It will be defined before publication of a last call draft.
DTD Module Legacy Redeclarations needed
The DTD Module DTD Module Legacy Redeclarations needed referenced as DTD/xhtml-legacy-redecl-1.mod needs to be defined. It will be defined before publication of a last call draft.
This appendix is normative.
This appendix is informative.
This specification was prepared by the W3C HTML Working Group. The members at the time of publication were:
This section will be updated at publication time.