Contents
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 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.
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 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.
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" "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>
*[dir="ltr"] { unicode-bidi: embed; direction: ltr}
*[dir="rtl"] { unicode-bidi: embed; direction: rtl}
*[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
*[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>
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.)
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 collection allows elements to carry information indicating how, when and why content has changed.
inserted
and deleted
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>
Example:
datetime="2003-01-13T13:15:30Z"
This collection allows an element to be the start point of a hypertext link to a remote resource.
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>
Example:
cite="comments.html"
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>
Example:
<link href="top.html" rel="contents"/>
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 accesskeyThe 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:
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).
An element inherits URI base information according to the following order of precedence (highest to lowest):
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>
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>
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>
Type attribute is inconsistent with the Embedding Attribute Collection
The Embedding Attribute Collection defines src and type. We need to ensure that the use of type is consistent, or find a way to rename the attributes.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.
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.
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>
Allow any element to be an image map?
Should we allow any element (such as <p>) that contains a number of hyperlinks to be an image map?Define ismap better
Can we define ismap better?Require UA to give feedback on regions
Should a UA be required to give feedback on the regions when hovering?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. activate, load, focusIn, focusOut, ...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.
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.
This collection assembles the Core, I18N, Events, Edit, Embedding, Map, Style, Bi-directional, and Hypertext attribute collections defined above.