XHTML™ 2.0

W3C Working Draft 6 May 2003

This version:

http://www.w3.org/TR/2003/WD-xhtml2-20030506

Latest version:

http://www.w3.org/TR/xhtml2

Previous version:

http://www.w3.org/TR/2003/WD-xhtml2-20030131

Diff-marked version:

xhtml2-diff.html

Editors:

Jonny Axelsson, Opera Software

Beth Epperson , Netscape/ AOL

Masayasu Ishikawa ,W3C

Shane McCarron , Applied Testing and Technology

Ann Navarro, WebGeek, Inc.

Steven Pemberton , CWI ( HTML Working Group Chair)

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 ©2003 W3C ^® ( MIT , ERCIM , Keio ), All Rights Reserved. W3C liability , trademark , document use and software licensing rules apply.

Abstract

XHTML 2 is a general purpose markup language designed for representing documents for a wide range of purposes across the World Wide Web. To this end it does not attempt to be all things to all people, supplying every possible markup idiom, but to supply a generally useful set of elements.

Status of This Document

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 fifth public Working Draft of this specification. It should in no way be considered stable, and should not be normatively referenced for any purposes whatsoever. This version includes an early implementation of XHTML 2.0 in RELAX NG [ RELAXNG ], but does not include the implementations in DTD or XML Schema form. Those will be included in subsequent versions, once the content of this language stabilizes. This version also does not address the issues revolving around the use of [ XLINK ] by XHTML 2. Those issues are being worked independent of the evolution of this specification. Those issues should, of course, be resolved as quickly as possible, and the resolution will be reflected in a future draft. Finally, the working group has started to resolve many of the issues that have been submitted by the public. If your particular issue has not yet been addressed, please be patient - there are many issues, and some are more complex than others.

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 no 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.

Quick Table of Contents

List of Issues

Full Table of Contents

1. Introduction

This section is informative .

1.1. What is XHTML 2?

XHTML 2 is a general purpose markup language designed for representing documents for a wide range of purposes across the World Wide Web. To this end it does not attempt to be all things to all people, supplying every possible markup idiom, but to supply a generally useful set of elements, with the possibility of extension using the span and div elements in combination with stylesheets.

1.1.1. Backwards compatibility

Because earlier versions of HTML were special-purpose languages, it was necessary to ensure a level of backwards compatibility with new versions so that new documents would still be usable in older browsers. However, thanks to XML and stylesheets, such strict element-wise backwards compatibility is no longer necessary, since an XML-based browser, of which at the time of writing means more than 95% of browsers in use, can process new markup languages without having to be updated. Much of XHTML2 works already in existing browsers. Much, but not all: just as when forms and tables were added to HTML, and people had to wait for new version of browsers before being able to use the new facilities, some parts of XHTML2, such as XForms and XML Events, still require user agents that understand that functionality.

1.1.2. XHTML2 and Presentation

The original version of HTML was designed to represent the structure of a document, not its presentation. Even though presentation-oriented elements were later added to the language by browser manufacturers, HTML is at heart a document structuring language. XHTML2 takes HTML back to these roots, by removing all presentation elements, and subordinating all presentation to stylesheets. This gives greater flexibility, and more powerful presentation possibilities, since CSS can do more than the presentational elements of HTML ever did.

1.1.3. Design Aims

In designing XHTML, a number of design aims were kept in mind to help direct the design. These included:

• As generic XML as possible: if a facility exists in XML, try to use that rather than duplicating it.
• Less presentation, more structure: already mentioned above.
• More usability: try to make the language easy to write, and make the resulting documents easy to use.
• More accessibility: some call it 'designing for our future selves'; the design should be as inclusive as possible.
• Better internationalization: it is a World Wide Web.
• More device independence: new devices coming online, such as telephones, PDAs, tablets, televisions and so on mean that it is imperative to have a design that allows you to author once and render in different ways on different devices, rather than authoring new versions of the document for each type of device.
• Less scripting: achieving functionality through scripting is difficult for the author and restricts the type of user agent you can use to view the document. We have tried to identify current typical usage, and include those usages in markup.

1.2. What are the XHTML 2 Modules?

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 [ HTML4 ], 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.

2. Terms and Definitions

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.

abstract module

a unit of document type specification corresponding to a distinct type of content, corresponding to a markup construct reflecting this distinct type.

content model

the declared markup structure allowed within instances of an element type. XML 1.0 differentiates two types: elements containing only element content (no character data) and mixed content (elements that may contain character data optionally interspersed with child elements). The latter are characterized by a content specification beginning with the "#PCDATA" string (denoting character data).

deprecated

a feature marked as deprecated is in the process of being removed from this recommendation. Portable applications should not use features marked as deprecated.

document model

the effective structure and constraints of a given document type. The document model constitutes the abstract representation of the physical or semantic structures of a class of documents.

document type

a class of documents sharing a common abstract structure. The ISO 8879 [ SGML ] definition is as follows: "a class of documents having similar characteristics; for example, journal, article, technical manual, or memo. (4.102)"

document type definition (DTD)

a formal, machine-readable expression of the XML structure and syntax rules to which a document instance of a specific document type must conform; the schema type used in XML 1.0 to validate conformance of a document instance to its declared document type. The same markup model may be expressed by a variety of DTDs.

driver

a generally short file used to declare and instantiate the modules of a DTD. A good rule of thumb is that a DTD driver contains no markup declarations that comprise any part of the document model itself.

element

an instance of an element type.

element type

the definition of an element, that is, a container for a distinct semantic class of document content.

entity

an entity is a logical or physical storage unit containing document content. Entities may be composed of parseable XML markup or character data, or unparsed (i.e., non-XML, possibly non-textual) content. Entity content may be either defined entirely within the document entity ("internal entities") or external to the document entity ("external entities"). In parsed entities, the replacement text may include references to other entities.

entity reference

a mnemonic string used as a reference to the content of a declared entity (eg., "&amp;" for "&", "&lt;" for "<", "&copy;" for "©".)

generic identifier

the name identifying the element type of an element. Also, element type name.

hybrid document

A hybrid document is a document that uses more than one XML namespace. Hybrid documents may be defined as documents that contain elements or attributes from hybrid document types.

instantiate

to replace an entity reference with an instance of its declared content.

markup declaration

a syntactical construct within a DTD declaring an entity or defining a markup structure. Within XML DTDs, there are four specific types: entity declaration defines the binding between a mnemonic symbol and its replacement content; element declaration constrains which element types may occur as descendants within an element (see also content model); attribute definition list declaration defines the set of attributes for a given element type, and may also establish type constraints and default values; notation declaration defines the binding between a notation name and an external identifier referencing the format of an unparsed entity.

markup model

the markup vocabulary (i.e., the gamut of element and attribute names, notations, etc.) and grammar (i.e., the prescribed use of that vocabulary) as defined by a document type definition (i.e., a schema) The markup model is the concrete representation in markup syntax of the document model, and may be defined with varying levels of strict conformity. The same document model may be expressed by a variety of markup models.

module

an abstract unit within a document model expressed as a DTD fragment, used to consolidate markup declarations to increase the flexibility, modifiability, reuse and understanding of specific logical or semantic structures.

modularization

an implementation of a modularization model; the process of composing or de-composing a DTD by dividing its markup declarations into units or groups to support specific goals. Modules may or may not exist as separate file entities (i.e., the physical and logical structures of a DTD may mirror each other, but there is no such requirement).

modularization model

the abstract design of the document type definition (DTD) in support of the modularization goals, such as reuse, extensibility, expressiveness, ease of documentation, code size, consistency and intuitiveness of use. It is important to note that a modularization model is only orthogonally related to the document model it describes, so that two very different modularization models may describe the same document type.

parameter entity

an entity whose scope of use is within the document prolog (i.e., the external subset/DTD or internal subset). Parameter entities are disallowed within the document instance.

parent document type

A parent document type of a hybrid document is the document type of the root element.

tag

descriptive markup delimiting the start and end (including its generic identifier and any attributes) of an element.

3. Conformance Definition

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 ].

3.1. Document Conformance

3.1.1. Strictly Conforming 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:

1. The document must conform to the constraints expressed in Appendix B - XHTML 2.0 RELAX NG Definition ,Appendix D - XHTML 2.0 Schema or Appendix F - XHTML 2.0 Document Type Definition .

2. The root element of the document must be html .

3. The root element of the document must contain an xmlns declaration for the XHTML 2.0 namespace [ XMLNAMES ]. The namespace for XHTML 2.0 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">
   

4. 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 F using its Public Identifier. The system identifier may be modified appropriately.

   <!DOCTYPE
    html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
    "TBD">
   

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"
    "TBD">
<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.

3.2. User Agent Conformance

A conforming user agent must meet all user agent conformance requirements defined in [ XHTMLMOD ].

4. The XHTML 2.0 Document Type

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.

Structure Module *

body, head, html, title

Block Text Module *

address, blockcode, blockquote, div, h, h1, h2, h3, h4, h5, h6, hr, p, pre, section

Inline Text Module *

abbr, cite, code, dfn, em, kbd, l, quote, samp, span, strong, sub, sup, var

Hypertext Module *

a

List Module *

dl, dt, dd, label, nl, ol, ul, li

Link Module

link

Metainformation Module

meta

Object Module

object, param, standby

Scripting Module

noscript, script

Style Attribute Module

style attribute

Stylesheet Module

style element

Tables Module

caption, col, colgroup, summary, table, tbody, td, tfoot, th, thead, tr

XHTML 2.0 also uses the following externally defined modules:

Ruby Annotation Module [ RUBY ]

ruby, rbc, rtc, rb, rt, rp

XML Events Module [ XMLEVENTS ]

listener

XForms Module [ XFORMS ]

action, alert, bind, case, choices, copy, delete, dispatch, extension, filename, group, help, hint, input, insert, instance, item, itemset, label, load, mediatype, message, model, output, range, rebuild, recalculate, refresh, repeat, reset, revalidate, secret, select, select1, send, setfocus, setindex, setvalue, submission, submit, switch, textarea, toggle, trigger, upload, value

There are no additional definitions required by this document type. An implementation of this document type as a RELAX NG grammar is defined in Appendix B ,as an XML Schema in Appendix D , and as a DTD in Appendix F .

5. Module Definition Conventions

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.

5.1. Module Structure

Each module in this document is structured in the following way:

• An abstract definition of the module's elements, attributes, and content models, as appropriate.
• A sub-section for each element in the module; These sub-sections contain the following components:
  • A brief description of the element,
  • A definition of each attribute or attribute collection usable with the element, and
  • A detailed description of the behavior of the element, if appropriate.

  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.

5.2. Abstract Module Definitions

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.

5.3. Syntactic Conventions

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.

element name

When an element is included in a content model, its explicit name will be listed.

content set

Some modules define lists of explicit element names called content sets . When a content set is included in a content model, its name will be listed.

expr ?

Zero or one instances of expr are permitted.

expr +

One or more instances of expr are required.

expr *

Zero or more instances of expr are permitted.

a , b

Expression a is required, followed by expression b .

a | b

Either expression a or expression b is required.

a - b

Expression a is permitted, omitting elements in expression b.

parentheses

When an expression is contained within parentheses, evaluation of any subexpressions within the parentheses take place before evaluation of expressions outside of the parentheses (starting at the deepest level of nesting first).

extending pre-defined elements

In some instances, a module adds attributes to an element. In these instances, the element name is followed by an ampersand ( & ).

defining required attributes

When an element requires the definition of an attribute, that attribute name is followed by an asterisk ( * ).

defining the type of attribute values

When a module defines the type of an attribute value, it does so by listing the type in parentheses after the attribute name.

defining the legal values of attributes

When a module defines the legal values for an attribute, it does so by listing the explicit legal values (enclosed in quotation marks), separated by vertical bars ( | ), 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.

5.4. Content Types

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.

5.5. Attribute Types

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:

In addition to these pre-defined data types, XHTML Modularization defines the following data types and their semantics (as appropriate):

6. XHTML Attribute Collections

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.

6.1. Core Attribute Collection

class = NMTOKENS

This attribute assigns one or more class names to an element; the element may be said to belong to these classes. A class name may be shared by several element instances.

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 class="note">
These programs are only available if you have purchased
the advanced professional suite.
</p>

Style sheet rules can then be used to render the paragraph appropriately, for instance by putting a border around it, giving it a different background colour, or where necessary by not displaying it at all.

id = ID

The id attribute assigns an identifier to an element. The id of an element must be unique within a document.

The id attribute has several roles in XHTML:

• As a style sheet selector.
• As a target anchor for hypertext links.
• As a means to reference a particular element from a script .
• As the name of a declared object element.
• For general purpose processing by user agents (e.g. for identifying fields when extracting data from XHTML pages into a database, translating XHTML documents into other formats, etc.).

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>

title = Text

This attribute offers advisory information about the element for which it is set.

Values of the title attribute may be used 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.

Example of the use of title :

<a href="/Jakob/" title="Author biography">Jakob Nielsen</a>'s
Alertbox for January 11, 1998

The title attribute has an additional role when used with the link element to designate an external style sheet. See the section on links and style sheets for details.

6.2. I18N Attribute Collection

xml:lang = LanguageCode

This attribute specifies the base language of an element's attribute values and text content. It is defined normatively in [ XML ] section 2.12 . The default value of this attribute is unspecified.

An element inherits language code information according to the following order of precedence (highest to lowest):

• The xml:lang attribute set for the element itself.
• The closest parent element that has the xml:lang attribute set (i.e., the xml:lang attribute is inherited).
• The HTTP "Content-Language" header (which may be configured in a server).

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"
   "TBD">
<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>

6.3. Bi-directional Text Collection

dir = "ltr|rtl|lro|rlo"

This attribute specifies the base direction of the element's text content. This direction overrides the inherent directionality of characters as defined in [ UAX9 ], and defines directional properties of text as defined by CSS2 [ CSS2 ]. The default value of this attribute is user-agent dependent. Possible values are:

• ltr : Left-to-right text. The effect of this attribute is defined by the CSS2 rule:

  *[dir="ltr"] { unicode-bidi: embed; direction: ltr}
  
  

• rtl : Right-to-left text. The effect of this attribute is defined by the CSS2 rule:

  *[dir="rtl"] { unicode-bidi: embed; direction: rtl}
  
  

• lro : Left-to-right override. The effect of this attribute is defined by the CSS2 rule:

  *[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
  

• rlo : Right-to-left override. The effect of this attribute is defined by the CSS2 rule:

  *[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}
  

Example:

improve bidi example

This example is sort of contrived. Can't we come up with a real-world example that is actually interesting?

<p dir="ltr">
I received the following email:
<l dir="lro">english werbeh english</l>
<l dir="lro">werbeh english werbeh</l>
</p>

6.3.1. Inheritance of text direction information

The Unicode bidirectional algorithm requires a base text direction for text blocks. To specify the base direction of a block-level element, set the element's dir attribute. The default value of the dir attribute is "ltr" (left-to-right text).

When the dir attribute is set for a block-level element, it remains in effect for the duration of the element and any nested block-level elements. Setting the dir attribute on a nested element overrides the inherited value.

To set the base text direction for an entire document, set the dir attribute on the html element.

Example:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 2.0//EN"
   "http://www.w3.org/TR/xhtml2/DTD/xhtml2.dtd">
<html dir="rtl">
<head>
<title>...a right-to-left title...</title>
</head>
...right-to-left text...<p dir="ltr">...left-to-right text...</p>
<p>...right-to-left text again...</p>
</html>

Inline elements, on the other hand, do not inherit the dir attribute. This means that an inline element without a dir attribute does not open an additional level of embedding with respect to the bidirectional algorithm. (Here, an element is considered to be block-level or inline based on its default presentation.)

6.3.2. The effect of style sheets on bidirectionality

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.

6.4. Edit Collection

This collection allows elements to carry information indicating how, when and why content has changed.

edit = "inserted|deleted|changed|moved"

This attribute allows elements to carry information indicating how content has changed. Possible values:

• inserted : the content has been inserted
• deleted : the content has been deleted
• changed : the content has changed considerably, therefore making it not worth being marked up with values of inserted and deleted
• moved : the content has been moved from some other part of the document.

The default presentation for an element with edit="deleted" is display: none (in other words, it is not displayed) although an alternate style might display it as crossed through. The other three values cause no special presentation by default, though an alternate style might use background colors or other text decoration to indicate the changed text.

Example:

<p>I will do it
next <span edit="deleted">week</span><span edit="inserted">month</span>.</p>

datetime = Datetime

The value of this attribute specifies the date and time when a change was made.

Example:

datetime="2003-01-13T13:15:30Z"

6.5. Hypertext Attribute Collection

This collection allows an element to be the start point of a hypertext link to a remote resource.

href = URI

This attribute specifies a URI that is actuated when the element is activated.

Examples:

<abbr href="http://www.w3.org/" title="World Wide Web">WWW</abbr>
<li href="contents.xhtml">contents</li>
<a href="http://www.cwi.nl/~steven/amsterdam.html">Amsterdam</a>
<quote href="hamlet.xhtml#p2435">To be or not to be</quote>
<var href="#index_ninc">ninc</var>

cite = URI

The value of this attribute is a URI that designates a source document or message. This attribute is intended to give further information about the element's contents (e.g., the source from which a quotation was borrowed, or the reason text was inserted or deleted). User Agents should provide a means for the user to access the further information.

Example:

cite="comments.html"

target = HrefTarget

This attribute identifies an environment that will act as the destination for a resource identified by a hyperlink when it is activated.

This specification does not define how this attribute gets used, since that is defined by the environment that the hyperlink is actuated in. See for instance XFrames [ XFRAMES ].

Example:

<a href="home.html" target="main">Home</a>

rel = LinkTypes

This attribute describes the relationship from the current document to the URI referred to by the element. The value of this attribute is a space-separated list of link types.

Example:

<link href="top.html" rel="contents"/>

rev = LinkTypes

This attribute is used to describe a reverse link from the anchor specified by the href attribute to the current document. The value of this attribute is a space-separated list of link types.

accesskey = Character

This attribute assigns an access key to an element. An access key is a single character from the document character set. Note. Authors should consider the input method of the expected reader when specifying an accesskey.

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 the access key "C" to a link. Typing this access key takes the user to another document, in this case, a table of contents.

<p accesskey="C" 
   rel="contents"
   href="http://example.com/specification/contents.html">
  Table of Contents
</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).

Accesskey

Actuation of elements with accesskey

navindex = Number

This attribute specifies the position of the current element in the navigation order for the current document. This value must be a number between 0 and 32767. User agents must ignore leading zeros.

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:

1. Those elements that support the navindex attribute and assign a positive value to it are navigated first. Navigation proceeds from the element with the lowest navindex value to the element with the highest value. Values need not be sequential nor need they begin with any particular value. Elements that have identical navindex values should be navigated in the order they appear in the character stream.
2. Those elements that do not support the navindex attribute or support it and assign it a value of "0" are navigated next. These elements are navigated in the order they appear in the character stream.

When a document is loaded using a URL that includes a fragment reference (such as book.html#chapter5 ) navigation begins at the point the fragment begins. If the user has moved away from that point (for instance using page up or page down), the navigation starting point is undefined.

The following example would allow the links to be navigated in column order (without the use of navindex they would be navigated in document, i.e. row, order):

<table>
<tr><td href="a" navindex="1">NW</td>
    <td href="c" navindex="3">NE</td></tr>
<tr><td href="b" navindex="2">SW</td>
    <td href="d" navindex="4">SE</td></tr>
</table>

Navigation keys. The actual key sequence that causes navigation or element activation depends on the configuration of the user agent (e.g., the "tab" key might be used for navigation and the "enter" key or "space" key 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).

xml:base = URI

This attribute specifies the base URI from which to resolve relative URIs. It is normatively defined in [ XMLBASE ]. Any relative URI used on an element that uses this attribute, or on an element contained within an element that uses this attribute, must be resolved relative to the base URI defined by this attribute.

An element inherits URI base information according to the following order of precedence (highest to lowest):

• The xml:base attribute set for the element itself.
• The closest parent element that has the xml:base attribute set (i.e., the xml:base attribute is inherited).
• The HTTP "Content-Location" header (which may be configured in a server).
• The location of the document itself.

Example:

See:
<ul xml:base="http://www.w3.org">
<li href="/">The W3C home page</li>
<li href="/TR">The W3C Technical Reports page</li>
<li href="/Markup">The HTML home page</li>
<li href="/Markup/Forms">The XForms home page</li>
</ul>

6.6. Embedding Attribute Collection

This collection causes the contents of a remote resource to be embedded in the document in place of the element's content. If accessing the remote resource fails, for whatever reason (network unavailable, no resource available at the URI given, inability of the user agent to process the type of resource) the content of the element must be processed instead.

Note that this behavior makes documents far more robust, and gives much better opportunities for accessible documents than the longdesc attribute present in earlier versions of XHTML, since it allows the description of the resource to be included in the document itself, rather than in a separate document.

Examples:

<p src="holiday.png" type="image/png">
    <span src="holiday.gif" type="image/gif">
        An image of us on holiday.
    </span>
</p>
<table src="temperature-graph.png" type="image/png">
<caption>Average monthly temperature over the last 20 years</caption>
<tr><th>Jan</th><th>Feb</th><th>Mar</th><th>Apr</th><th>May</th><th>Jun</th>
    <th>Jul</th><th>Aug</th><th>Sep</th><th>Oct</th><th>Nov</th><th>Dec</th>
</tr>
<tr><td> 4</td><td> 2</td><td> 7</td><td> 9</td><td>13</td><td>16</td>
    <td>17</td><td>17</td><td>14</td><td>11</td><td> 7</td><td> 4</td>
</tr>
</table>

src = URI

This attribute specifies the location of an external source for the contents of the element.

type = ContentType

This attribute specifies the allowable content types of the relevant src URI. At its most general, it is a comma-separated list of media ranges with optional accept parameters, as defined in section 14.1 of [ RFC2616 ] as the field value of the accept request header.

In its simplest case, this is just a media type, such as "image/png" or "application/xml", but it may also contain asterisks, such as "image/*" or "*/*", or lists of acceptable media types, such as "image/png, image/gif, image/jpeg".

The user agent must combine this list it with its own list of acceptable media types by taking the intersection, and then use the resulting list as the field value of the accept request header when requesting the resource using HTTP.

For instance, if the attribute specifies the value "image/png, image/gif, image/jpeg", but the user agent does not accept images of type "image/gif" then the resultant accept header would contain "image/png, image/jpeg".

A user agent should imitate similar behavior when using other methods than HTTP. For instance, when accessing files in a local filestore, <p src="logo" type="image/png, image/jpeg"> might cause the user agent first to look for a file logo.png , and then for logo.jpg .

If this attribute is not present, "*/*" is used for its value.

For the current list of registered content types, please consult [ MIMETYPES ].

Examples:

<script src="pop" type="application/x-javascript, text/x-newspeak"/>
<style src="midnight" type="text/css, text/x-mystyle"/>
<p src="w3c-logo" type="image/png, image/jpeg;q=0.2">W3C logo</p>
<span src="logo.png">Our logo</span>
<span src="theme.mp3" type="audio/x-mpeg">Our theme jingle</span>

6.7. Image Map Attribute Collection

This collection adds attributes that specify that an embedded image may be used as an image map, so that clicking on different parts of the image causes different hyperlinks to be activated.

usemap = URI

This attribute associates an image map with an element. The value of usemap must match the value of the id attribute of an element that contains one or more elements with shape and coords attributes.

ismap = "ismap"

This attribute indicates that the associated image is to be treated as a "server-side image map". When selected, the coordinates within the element that the user selected are sent to the server where the document resides. Screen coordinates are expressed as screen pixel values relative to the image, and start at (0,0) at the top left corner.

In the following example, the active region defines a server-side image map. A click anywhere on the image will cause the click's coordinates to be sent to the server.

<p href="http://www.example.com/cgi-bin/map"
      src="map.png" ismap="ismap">
   Our location.
</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 element, by appending `?' followed by the x and y coordinates, separated by a comma. The link is then actuated 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/map?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.

shape = "default|rect|circle|poly"

This attribute specifies the shape of a region. Possible values:

• default: Specifies the entire region.
• rect: Define a rectangular region.
• circle: Define a circular region.
• poly: Define a polygonal region.

coords = Coordinates

This attribute specifies the position and shape of the area. The number and order of values depends on the shape being defined. Possible combinations:

• rect: left-x, top-y, right-x, bottom-y.
• circle: center-x, center-y, radius. Note. When the radius value is a percentage value, user agents should calculate the final radius value based on the associated object's width and height. The radius should be the smaller value of the two.
• poly: x1, y1, x2, y2, ..., xN, yN. The first x and y coordinate pair and the last should be the same to close the polygon. When these coordinate values are not the same, user agents should infer an additional coordinate pair to close the polygon.

Coordinates are relative to the top, left corner of the object. All values are of type Length . All values are separated by commas. The coordinates of the top, left corner of an area are 0, 0 .

Note that in the following example, if the image is unavailable for any reason, the fallback properties of the src attribute mean that the <nl> will be displayed instead of the image, thus making the page still useful:

 
<html xmlns="http://www.w3.org/2002/06/xhtml2">
   <head>
      <title>The cool site!</title>
   </head> 
   <body>
     <p src="navbar1.png" type="image/png" usemap="#map1"> 
         <nl id="map1">
           <label>Navigate the site:</label>
           <li href="guide.html" shape="rect" coords="0,0,118,28">
           Access Guide</li> 
           <li href="shortcut.html" shape="rect" coords="118,0,184,28">
           Go</li> 
           <li href="search.html" shape="circle" coords="184,200,60">
           Search</li>
           <li href="top10.html" shape="poly" coords="276,0,276,28,100,200,50,50,276,0">
           Top Ten</li>
         </nl>
      </p>
   </body>
</html> 

Note that an li in an nl is not required to have an href attribute. In that case, the relevant region of the image is inactive:

<p src="image.png" type="image/png" usemap="#map1">
   <nl id="map1">
   <li shape="circle" coords="100,200,50">I'm inactive.</li>
   <li href="outer-ring-link.html" shape="circle" coords="100,200,250">I'm active.</li>
   </nl>
</p>

6.8. Events

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:

defaultAction = cancel|perform

This attribute defines whether or not the default action associated with the event should be processed. The default value is perform

event = CDATA

This attribute defines the event type that is being listened for. The set of legal names for XHTML 2 is to be defined.

List of XHTML 2 Events Needed

We need to define the list of XHTML 2 events and map them into the XHTML DOM. activate, load, focusIn, focusOut, ...

handler = IDREF

This attribute specifies the ID of a handler element that defines the action that should be performed if the event reaches the observer.

observer = IDREF

This attribute specifies an ID for an observer element for which the listener is to be registered.

phase = capture|default

This attribute specifies the phase of event propagation in which to process the event. If not specified, the default value of this attribute is default .

propagate = stop|continue

This attribute specifies whether an event should stop propagating after this observer processes it, or continue for possible further processing. The default value of this attribute is continue .

target = IDREF

This attribute specifies the id of the target element of the event (i.e., the node that caused the event). If not specified, the default value of this attribute is the element on which the event attribute is specified.

Note that these attributes are not in the XHTML namespace but in the XML Events namespace. The XHTML namespace is the default namespace for XHTML documents, so XHTML elements and attributes may be expressed without namespace prefixes (although they are permitted on elements). XML Events attributes MUST use a prefix, since they are not in the default namespace of the document.

6.9. Style Attribute Collection

style = CDATA

This attribute specifies style information for the current element.

The syntax of the value of the style attribute is determined by the default style sheet language. For example, for [ CSS2 ] inline style, use the declaration block syntax described in the Style Sheet Module (without curly brace delimiters).

This CSS example sets color and font size information for the text in a specific paragraph.

<p style="font-size: 12pt; color: fuchsia">Aren't style sheets wonderful?</p>

In CSS, property declarations have the form "name : value" and are separated by a semi-colon.

To specify style information for more than one element, authors should use the style element. For optimal flexibility, authors should define styles in external style sheets.

Style Attributes and Generic XML

There is currently no way to declare what attribute within a given namespace contains "styling" information in a way that a Generic XML processor can discern. In an ideal world, someone would define such a mechanism (e.g., through the xml-stylesheet PI).

Note that the Style collection is only defined when the Style Attribute Module is selected. Otherwise, the Style collection is empty.

6.10. Common Attribute Collection

This collection assembles the Core , I18N , Events , Edit , Embedding , Map ,Style , Bi-directional , and Hypertext attribute collections defined above.

7. XHTML Structure Module

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:

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: RELAX NG

7.1. The html element

After the document type declaration, the remainder of an XHTML document is contained by the html element.

Example:

<html class="slideshow">

7.2. The head element

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. The default presentation of the head is not to display it; however that can be overridden with a stylesheet for special purpose use. User agents may however make information in the head available to users through other mechanisms.

Example:

<head>
    <title>My Life</title>
</head>

7.3. The title element

Every XHTML document must have a title element in the head section.

The title element is used to identify the document. Since documents are often consulted 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. The mechanism for doing so depends on the user agent (e.g., as a caption, spoken).

Example:

<title>A study of population dynamics</title>

7.4. The body element

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.

8. XHTML Block Text Module

This section is normative .

This module defines all of the basic text container elements, attributes, and their content models that are "block level". Note that while the concept of "block level" can be construed as a presentation aspect, in this case it is intended to only have a semantic meaning.