These are comments from Ian Jacobs on the 31 Jan 2003 draft of XHTML 2.0. I have prepared these comments as part of work in the User Agent Accessibility Guidelines Working Group, for our 27 Feb 2003 teleconference, and in anticipation of discussions with the HTML WG next week in Boston.
Below are general comment and comments inline in the text. Comments inline are highlighted in color and are preceded by "IJ:".
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.
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 fourth 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 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 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.
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.
This section is informative.
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.
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.
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.
In designing XHTML, a number of design aims were kept in mind to help direct the design. These included:
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.
IJ: XML terms should be quoted from the XML spec, with a reference to the section where defined.
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 E using its Formal 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.
A conforming user agent must meet all user agent conformance requirements defined in [XHTMLMOD].
IJ: There are varied types of requirements for user agents that should be identified more clearly:
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, address, blockquote, cite, code, dfn, div, em, h, hr, h1,
h2, h3, h4, h5, h6, kbd, l, p, pre, quote, samp, section, span, strong,
sub, sup, var
a
dl, dt, dd, label, nl, ol, ul, li
area, map
link
meta
object, param
noscript, script
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, as per section 2.2 of [XML]. IJ: s/as per/per/g |
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 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. |
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.IJ: This is inconsistent with the definition later in the spec, which does not speak about "window name"; instead it is explicitly not window-specific. In any case, please use "viewport" rather than "window" |
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. IJ: WAI should discuss whether there are other values that would be useful for accessibility, such as: description, summary, and equivalent.
Linktype 'required' Linktype 'required'Linktype 'prefetch' Linktype 'prefetch'Linktype 'redirect' Linktype 'redirect' to handle the one missing piece of functionality that http-equiv used to supply. |
MediaDesc | A comma-separated list of media descriptors as described by [CSS2]. The default is
|
Number | One or more digits |
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] (called IRI in some other
specifications). IJ: If values can be IRIs, I find
it troubling that the name is "URI". There are TAG discussions on the
use of IRIs that we've not yet wrapped up, and there are some
suggested ways to introduce IRIs into a specification. |
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 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.
Attribute representing the linguistic root of a word
A 'root of word' attribute for commonIJ: In this section, the default value is "unspecified"; in section 6.3 (dir attribute), the default value is user-agent dependent. I have the feeling that those statements mean the same thing, and should be harmonized.
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: normal; direction: ltr}
*[dir="rtl"] { unicode-bidi: normal; direction: rtl}
*[dir="lro"] { unicode-bidi: bidi-override; direction: ltr}
*[dir="rlo"] { unicode-bidi: bidi-override; direction: rtl}
Example:
improve bidi example
<p dir="ltr"> I received the following email: <l dir="lro">english werbeh english</l> <l dir="lro">werbeh english werbeh</l> </p>
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.
IJ: This is an example of default rendering behavior that suggests that:
For instance, in this case, change the first sentence of the preceding paragraph to:
A graphical user agent MUST be capable of rendering an element with 'edit="deleted"' using the CSS semantics 'display:none'. A user agent MAY allow the user agent to choose between that rendering and others (e.g., the deleted text is rendered with CSS 'strike-through' semantics).
Example:
<p>I will do it next <span class="deleted">week</span><span class="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]. IJ: As mentioned above, this is not in agreement with definition of HrefTarget.
Example:
<a href="home.html" target="main">Home</a>
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.
IJ: I'm not sure what this means. Does this mean that the author is telling the user agent "Don't accept content unless it is sent as one of the following media types?" If that is the case, then it sounds like the author has the final say over the user's environment, which I think should not be the case. Or, is this attribute advisory for the user agent? But why wouldn't the user agent use content negotiation to find out the authoritative list of available media types?
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.
IJ: Please express as "the user agent MUST use "*/*" as 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>
Example:
<link href="top.html" rel="contents"/>
Pressing an access key assigned to an element gives focus to the element.
IJ: I think this is the first instance of the term "focus" in this document. Please use the UAAG 1.0 definition of focus, and include UAAG 1.0 focus requirements in XHTML 2.0. I think the UAWG and the HTML WG should discuss the UAAG 1.0 navigation model.
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).
IJ: After the second sentence above, I suggest instead citing UAAG 1.0, checkpoint 7.4
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.
IJ: Please define the semantics of this attribute in terms of the UAAG 1.0 focus. In UAAG 1.0, "navigation" is defined in terms of moving the focus around.
Elements that may receive focus should be navigated by user agents according to the following rules:
IJ: Why is this SHOULD and not MUST?
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.
IJ: I suggest instead the following general model for focus navigation (expressed using UAAG 1.0 terminology).
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).
IJ: I suggest instead: The user agent MUST allow the user to configure which keyboard keys are used to navigate via the content focus.
User agents may also define key sequences to navigate the navigation order in reverse.
IJ: See UAAG 1.0, checkpoint 9.7
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.
IJ: The above para is another example of user agent processing behavior required for conformance.
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.
IJ: There are times when it is useful for a description to be a separate resource, and other times when it is useful that it be part of a document. From the perspective of the user agent, what's important is to know that "A" is a description of "B", whether A is in the same document as B or some other. It's the "is a description of" relationship that authors need to be able to represent.
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.
IJ: Please see my earlier comments about the "type" attribute.
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.
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.
IJ: See WCAG 1.0, checkpoint 9.1.
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.
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 do not require 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.
Add events listener element to head
The listener element from XML Events must be added to the content model for the head element.This collection assembles the Core, I18N, Events, Edit, Embedding, Bi-directional, 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 |
---|---|---|
html | Common, profile (URI), xmlns (URI = "http://www.w3.org/2002/06/xhtml2") | head, body |
head | Common | title |
title | Common | PCDATA |
body | Common | (Heading | Block | List)* |
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
footer PR #744
There was a suggestion for a footer element to contain data that should be presented at the bottom of content. The working group has not yet addressed this suggestion.IJ: This is about visual presentation in page media; sounds like CSS.
security tag
There was a suggestion that we define a security tag, within which elements that have security ramifications would be rendered harmless. The working group has not yet addressed this suggestion.After the document type declaration, the remainder of an XHTML document is contained by the html element.
Attributes
IJ: I don't understand why XHTML 2.0 only considers first URI to be significant.
Example:
<html class="slideshow">
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.
IJ: See UAAG 1.0, checkpoint 2.3.
Attributes
Example:
<head> <title>My Life</title> </head>
Every XHTML document must have a title element in the head section.
Attributes
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.
IJ: Yes, see UAAG 1.0, checkpoint 2.3.
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). Example:
<title>A study of population dynamics</title>
duplication of title
There has been a request for facilities to reduce the need for duplicating title and headingsThe body of a document contains the document's content.
IJ: This statement is not consistent with UAAG 1.0, which defines "content" to be what is represented in the DOM. So, for example, the title of a document is considered part of content, even though it appears in the <head> element. The XHTML spec should address user agent rendering requirements in terms of CSS style properties, even if CSS implementation is not required. Set strong expectations about default rendering to promote interoperability.
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)* |
address | Common | (PCDATA | Inline)* |
blockquote | Common | (PCDATA | Inline | Heading | Block | List)* |
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)* |
hr | Common | EMPTY |
kbd | Common | (PCDATA | Inline)* |
l | Common | (PCDATA | Inline)* |
p | Common | (PCDATA | Inline | List | blockquote | pre | table)* |
pre | Common | (PCDATA | Inline)* |
quote | Common | (PCDATA | Inline)* |
samp | Common | (PCDATA | Inline)* |
section | Common | (PCDATA | Flow)* |
span | Common | (PCDATA | Inline)* |
strong | Common | (PCDATA | Inline)* |
sub | Common | (PCDATA | Inline)* |
sup | Common | (PCDATA | Inline)* |
var | Common | (PCDATA | Inline)* |
split text module
Text module should be split into inline and block submodulesIJ: If I understand, this would be a distinction based on visual rendering, which I think should be avoided.
l element content model
Content model of the l element should not allow nested linesThe 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 since a style sheet might give any
element within the Block content a display
property of
inline
.
Implementation: DTD
nr element
There was a suggestion to introduce annr
element to help
annotate content as being a number. This suggestion has not yet been
addressed by the working group.The abbr element indicates that a text fragment is an abbreviation (e.g., W3C, XML, Inc., Ltd., Mass., etc.); this includes acronyms.
Attributes
The content of the abbr element 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. IJ: Per UAAG 1.0, checkpoint 2.3, the user agent MUST make available this information to users.
Note that abbreviations 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 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.
IJ: The previous sentence can be deleted with no loss of value.
content model of address element
The content model of the address element should be improved to improve its semantic processability.IJ: I agree. I think that there are a number of HTML elements that don't really serve their intended purpose well, and could be greatly improved if backwards compatibility is not a constraint.
Attributes
Example:
<address href="mailto:webmaster@example.net">Webmaster</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 cite element contains a citation or a reference to other sources.
IJ: Why not create real citation and bibliographic elements?
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 xml: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.
IJ: Why not create real elements for building a glossary, e.g., an element to define a term somewhere in a document, and another element to refer to that definition?
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, offers a generic mechanism for adding extra 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.
IJ: It seems like XHTML 2.0 is a good opportunity to get rid of either <em> or <strong>. The difference between them semantically has always been unclear to me.
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.
Deprecate h1-6?
There was a suggestion that h1 - h6 be deprecated. The working group has not yet addressed this suggestion.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.
IJ: The previous sentence should be deleted. Instead, there are a number of options:
See also UAAG 1.0 checkpoints 4.1 and 4.2 for configuration requirements related to text size.
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 indicates the importance of the heading. The heading for the section is the one that is a child of the section element.
IJ: In the example below, the first <h> is used without an englobing <section> element. This contradicts the earlier statement that <h> "is used in combination with the section element."
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 hr element places a horizontal line in the document.
Remove or rename hr
It has been suggested thathr
be removed or renamed to, for
instance, <separator/>
. The working group has not yet
addressed this suggestion.
IJ: <hr> might have some non-presentation semantics if you squint the right way. But I think it's mostly presentation and could be removed from the spec in favor of style sheets.
Attributes
The kbd element indicates text to be entered by the user.
IJ: How about instead: "The <kdb> element identifies keyboard keystrokes." Here's why:
Attributes
Example:
To exit, type <kbd>QUIT</kbd>.
The l element contains a
sub-paragraph that represents a sinle line of text. 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.
IJ: Several comments:
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"> <l>program p(input, output);</l> <l>begin</l> <l> writeln("Hello world");</l> <l>end.</l> </p>
the following CSS stylesheet would number each line:
.program { counter-reset: linenumber } l: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
Example:
<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 visual 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 any elements may preserve or collapse whitespace on rendering, under control of a stylesheet. Also note that there is no normative requirement that the <pre> element be rendered in a monospace font (although this is the default rendering), nor that text wrapping be disabled.
IJ: Please rephrase the previous paragraph in terms of normative rendering requirements. Where is the rule that a user agent must preserve white space defined for the XHTML family? I note that "although this is the default rendering" specifies another normative rendering requirement.
Non-visual user agents are not required to respect extra white space in the content of a pre element.
Attributes
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 an inline text fragment of quoted text.
IJ: Delete this element. Here's why: In HTML 4, this element
was introduced for two reasons (as I recall): to insert quotes and for inline
rendering. The statement "Visual user agents must not by default add
delimiting quotation marks" obviates the first part, and the spec as a whole
is eliminating some rendering semantics. I don't see any reason to keep
<quote> around. If someone wishes to build an "inline quote", use
blockquote { display: inline}
. Alternatively, get rid of
<blockquote> and keep <quote>, which does not suggest any
rendering semantics.
Attributes
Visual user agents must not by default add delimiting quotation marks (as
was the case for the q
element in earlier versions of XHTML). It
is the responsibility of the document author to add any required quotation
marks, either directly in the text, or via a stylesheet.
The following example illustrates nested quotations with the quote element.
<p>John said, <quote>"I saw Lucy at lunch, she told me <quote>'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.example.org/2002/01.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.
IJ: Delete the previous sentence. Define a default rendering for <section> that is "display: blocklevel". Don't talk about "inline" or "blocklevel" outside of a default 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 higher importance for its contents.
Attributes
On <strong>Monday</strong> please put the rubbish out, but <em>not</em> before nightfall!
strong
Leave in, deprecate or remove? No consensus.The sub element indicates that its contents should regarded as a subscript.
IJ: Why "should be regarded as"? Why not "is"?
Attributes
For visual user agents this element would normally be rendered as a
subscript of the text baseline, but on user agents where this is not possible
(for instance teletype-like devices) other renderings may be used. For
instance, a<sub>i, j</sub>
that would be rendered as
ai, j
on a device that can render it so, might be
rendered as a[i, j]
on a simpler device.
IJ: This is a rendering requirement. Specify default rendering through stylesheet with the vertical-align property.
Example:
H<sub>2</sub>O
The sup element indicates that its contents should be regarded as a super-script.
IJ: Why "should be regarded as"? Why not "is"?
Attributes
For visual user agents this element would normally be rendered as a
super-script of the text baseline, but on user agents where this is not
possible (for instance teletype-like devices) other renderings may be used.
For instance, 2<sup>n</sup>
that would be rendered
as 2n
on a device that can render it so, might be
rendered as 2↑(n)
on a simpler device.
IJ: This is a rendering requirement. Specify default rendering through stylesheet with the vertical-align property.
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 xml:lang="fr">M<sup>lle</sup> Dupont</span>
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 an element that traditionally has been used in HTML to define hypertext links to other resources. Although all elements may now play the role of a hyperlink (using the href attribute) or hyperlink anchor (using the id attribute), this element remains for explicit markup of links, though is otherwise identical in semantics to the span element.
This module supports the following element:
Element | Attributes | Minimal Content Model |
---|---|---|
a | Common | (PCDATA | Inline)* |
This module adds the a element to the Inline content set of the Text Module.
Implementation: DTD
IJ: If everything can take the src attribute and style sheets control all presentation, why is <a> necessary?
Attributes
An 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.
IJ: The previous sentence defines user agent behavior for retrieving a representation of the identified resource. I don't think this is mandatory behavior, so the above sentence should be rewritten to be one possible behavior.
User agents generally render links in such a way as to make them obvious to users (underlining, reverse video, etc.).
IJ: Also, the spec should say that the user agent SHOULD render the link content.
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. ~~~~~~~~~~~~
IJ: I think that "A possible visual" through "W3C Web site" can be deleted since by now people are familiar with underlined links.
Suppose we define an anchor named "anchor-one" in the file "one.html".
...text before the anchor... <a id="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 are required to find anchors created by empty a elements.
IJ: This is a normative processing requirement. It should not be expressed as a Note. [Generally, Notes are informative.] I don't know what it means to "find anchors"; what semantics are intended here?
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)* |
label | Common | (PCDATA | Inline)* |
nl | Common | label , 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 and/or the stylesheet in effect. Authors must not use 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.
IJ: Hmm, this seems more like an XForms element than an XHTML element. Most of the interesting part of the <nl> definition involves rendering; could that be done through style sheets?
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 label element that defines the label 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.
IJ:The previous sentence suggests quite strongly that this element is only about visual presentation.
This example illustrates the basic structure of a nested navigation list:
<nl> <label>Contents </label> <li href="#introduction">Introduction</li> <li> <nl> <label>Terms</label> <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.
IJ: If presentation semantics are to be moved out of XHTML, there is only need for one list element. I expect that a proposal to delete the <ol> element will be met with much resistance. That's fine, but the spec needs to be clearer about the interaction of number (or bullets for that matter) and style sheets. I think that it should state explicitly:
Basically, the statement "unordered list items are not numbered" is underspecified.
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
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 label element is used to define a label for an nl navigation list. The contents of the label element are displayed as the title of a list (or sublist). See nl for more information.
This section is normative.
The Client-side Image Map Module provides elements for client side image maps. It requires that the Image Map Attribute Collection and the Embedding Attribute Collection (or the Object Module) be included. The Client-side Image Map Module supports the following elements:
Elements | Attributes | Minimal Content Model |
---|---|---|
area | Common, Map, alt* (Text), nohref ("nohref") | EMPTY |
map | I18N, Events, Edit, Embedding, Bi-directional, class (ClassName), id* (ID), title (Text) | ((Heading | Block) | area)+ |
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.
IJ: Is the AREA element really required? We moved away from <area> towards rich content. Now is the time to get rid of <area>.
Attributes
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:
IJ: Include a reference to the relevant portions of WCAG 1.0 techniques here and delete this text from XHTML 2.0.
IJ: Why is this attribute necessary? Is it used in practice?
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 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.
The presence of the usemapattribute 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:
IJ: This content model was introduced for backwards compatibility in HTML 4.0 and can be simplified in XHTML 2.0.
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.).
IJ: I think that the previous paragraph should be replaced with a <switch> element construct.
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 src="navbar1.png" type="image/png" usemap="#map1"> <map id="map1"> <nl> <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> </map> </p> </body> </html>
IJ: These examples can be simplified if <area> is eliminated.
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 xmlns="http://www.w3.org/2002/06/xhtml2"> <head> <title>The cool site!</title> </head> <body> <p src="navbar1.gif" type="image/gif" usemap="#map1"> ...the rest of the page here... <map id="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> </p> </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.<p> </object></p> <map id="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></p>
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 id="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></p> </map> </object> </object></p>
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 id="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></p> </map>
Similarly, the nohref attribute for the area element declares that geometric region has no associated link.
IJ: I find it confusing that the name of this module is "XHTML Linking" and it doesn't include <a>. For that matter, since every element can be a link, why is there this special module?
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, media (MediaDesc), | 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
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).
Possible rel values
Allowable and new values for the rel attribute are being discussed.XML linking support
The HTML Working Group is aware that there are issues surrounding various linking models that would permit generic XML user agents to support generic linking semantics and presentation. The Working Group is coordinating closely with other groups both inside and outside of the W3C to resolve these issues.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.
IJ: Does anybody use "rev?" Could it be deleted?
Consider two documents A and B.
Document A: <link href="docB" rel="index"/>
Has exactly the same meaning as:
Document B: <link href="docA" rev="index"/>
namely that document B is the index for document A.
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.
IJ: I have several comments on the preceding sentence:
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 xml:lang attribute to indicate to a search engine where to find Dutch, Portuguese, and Arabic versions of a document. Note that this also indicates 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" rel="alternate" xml:lang="nl" href="http://example.com/manual/dutch.html"/> <link title="The manual in Portuguese" rel="alternate" xml:lang="pt" href="http://example.com/manual/portuguese.html"/> <link title="The manual in Arabic" rel="alternate" xml:lang="ar" href="http://example.com/manual/arabic.html"/> <link lang="fr" title="La documentation en Français" rel="alternate" xml:lang="fr" href="http://example.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://example.com/manual/postscript.ps"/> </head>
IJ: Why does the author specify the "type"? Why not just rely on protocol headers?
In the following example, we tell search engines where to find the front page of a collection of documents.
<head> <title>Reference manual -- Chapter 5</title> <link rel="Start" title="The first chapter of the manual" type="text/html" href="http://example.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 | Common, name (NMTOKEN) | PCDATA |
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:
IJ: That's not exactly true. The semantics of the common collection is not 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.
meta properties
We should specify a minimal set of useful meta propertiesEach meta element specifies a property/value pair. The name attribute identifies the property and the content of the element specifies the property's value.
For example, the following declaration sets a value for the
Author
property:
<meta name="Author">Steven Pemberton</meta>
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 edit and related attributes, 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">http://www.rfc-editor.org/rfc/rfc3236.txt</meta>
might also be written:
<link rel="DC.identifier" type="text/plain" href="http://www.rfc-editor.org/rfc/rfc3236.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" xml:lang="en-us">vacation, Greece, sunshine</meta> <!-- For speakers of British English --> <meta name="keywords" xml:lang="en">holiday, Greece, sunshine</meta> <!-- For speakers of French --> <meta name="keywords" xml:lang="fr">vacances, Grèce, soleil</meta>
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.
IJ: I think this section should be deleted. Are we are still encouraging people to use PICS?
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"> (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)) </meta> <title>... document title ...</title> </head>
meta and RDF
How to represent and include RDF in XHTML2 documents is under discussion.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.
<html ... profile="http://www.acme.com/profiles/core"> <head> <title>How to complete Memorandum cover sheets</title> <meta name="author">John Doe</meta> <meta name="copyright">© 1997 Acme Corp.</meta> <meta name="keywords">corporate,guidelines,cataloging</meta> <meta name="date">1994-11-06T08:49:37+00:00</meta> </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), content-length (Number), data (URI), declare ("declare"), standby (Text) | ( caption?,(PCDATA | Flow | param)*) |
param | id (ID), name* (CDATA), 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
IJ: I wish the semantics of the object could be simplified and the applet semantics handled through other means than these attributes. I don't have a counter proposal, but it makes the <object> element so complicated.
Attributes
IJ: What is the relation of this attribute to protocol headers?
IJ: How does the user agent decide? Is that processing specified? Also, is the the same "type" attribute as defined by the common collection?
The following terms will be used throughout this section.
Most user agents have built-in mechanisms for processing common data types such as text, and various image types (gif, jpg and png for example) in some instances the user agent may pass the processing to an external application. Generally, a user agent will attempt to process the object declaration, otherwise it may invoke an external application, which are normally referred to as "plug-ins".
IJ: This is important: this is not the UAAG 1.0 model of what a user agent is. In UAAG 1.0, a "user agent" is a set of components that implement some functionalities. This includes plug-ins, which are user-approved extensions to the user agent. Rather than talk about an "external application," how about talking about an appropriate handler, where a handler may be something that runs in process or in a separate process; that's an implementation detail.
In the most general case, an author should specify three types of information:
The object element allows authors to specify all three types of information, but authors may not have to specify all three at once. For example, some object element instances may not require data (e.g., a self-contained applet that performs a small animation). Others may not require mime type information, i.e., the user agent itself may already know how to process that type of data (e.g., GIF images). Still others may not require run-time initialization.
Authors specify an object's mime type 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 element in the head does 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.
A user agent must interpret an object element according to the following precedence rules:
IJ: This is user agent behavior that is part of user agent conformance.
Authors should not include content in object elements that appear in the head element.
IJ: The previous sentence can be deleted; it was expressed earlier in this section.
When a user agent is able to successfully process an object element it MUST not attempt to process inner elements. For example, if the following code is encountered:
IJ: This is more normative user agent behavior.
<object ... pointing to objectdataA> <object ... pointing to objectdataB> <p>alternate text</p> </object> </object>
When the user agent encounters objectdataA and is able to process that object element, then all nested elements (except for applicable param elements) MUST be ignored.
IJ: This is the perhaps the first appearance of MUST in uppercase. See the Manual of Style for information about marking up instances of MUST/SHOULD/MAY.
If a user agent cannot process an object element or a set of nested objects, and the author did not provide alternate text, the user agent SHOULD NOT supply any additional information. It is the responsibility of the author to supply additional or alternate information. It may be the intent of the author to not provide additional information if the object cannot be processed.
The user agent SHOULD attempt to process the outer object to its fullest extent before dropping to a nested object. For example, if the author provided information that could be used to download an external application to be used to process the object, then the user agent SHOULD attempt to download and install the application. If the user selects to not install the application, the user agent SHOULD continue to process the nested object or objects, if they exist.
The following example, shows a minimally coded object element. The data attribute specifies the location of the object data and the type attribute specifies the mime type associated with the object data:
<object data="http://www.example.com/foo.mp3" type="audio/mpeg"><em>alternate text</em></object>
Note that the MP3 file will be processed as soon as the object handler interprets this object element declaration. It is possible to delay processing of an object through the use of additional values defined within the param element (described later). It may also be delayed by the use of the declare attribute.
The following example shows an object element coded to process an image. The data attribute specifies the location of the object data, in this case the image to be processed, and the type attribute specifies the mime type associated with the object data:
<object data="http://www.example.com/foo.jpg" type="image/jpeg"><em>alternate text</em></object>
The following example shows how an applet element can be converted to an object element. The codebase attribute is replaced with the xml:base attribute.
IJ: Since there is no more "applet element" in XHTML 2.0, that term needs to be further qualified.
The code attribute is replaced with the data attribute. The width and the height of the applet are defined using CSS. The param elements are not modified since the values within the param elements are passed directly to the external application. If a particular version reference is required, that would be appended to the content of the type attribute. For example, type="application/x-java-applet;version=1.4.1"
If the archive attribute is used, the object handler should process the search order by interpreting the archive attribute value first and then the xml:base attribute value.
<object codebase="http://www.example.com/applets/classes" code="Clock.class" width="150" height="150"> <param name="bgcolor" value="ffffff"/> <param name="border" value="5"/> <param name="ccolor" value="dddddd"/> <param name="cfont" value="TimesRoman|BOLD|18"/> <param name="delay" value="100"/> <param name="hhcolor" value="0000ff/"> <param name="link" value="http://www.example.com/"/> <param name="mhcolor" value="00ff00"/> <param name="ncolor" value="000000"/> <param name="nradius" value="80"/> <param name="shcolor" value="ff0000"/> </object>
<style type="text/css"> #obj1 {width:150; height:150;} </style> ... <object id="obj1" xml:base="http://www.example.com/applets/classes" type="application/x-java-applet" data="Clock.class"> <param name="delay" value="100"/> <param name="link" value="http://www.example.com/"/> <param name="border" value="5"/> <param name="nradius" value="80"/> <param name="cfont" value="TimesRoman|BOLD|18"/> <param name="bgcolor" value="ddddff"/> <param name="shcolor" value="ff0000"/> <param name="mhcolor" value="00ff00"/> <param name="hhcolor" value="0000ff"/> <param name="ccolor" value="dddddd"/> <param name="ncolor" value="000000"/> <em>alternate text</em> </object>
Authors should always include alternate text as the content of the object element declaratio when an embedded object is not defined. If an author includes alternate text and an embedded object, the object handler may process both the text and the embedded object. The alternate text will provide the user a hint in cases where the object handler cannot process the object data. The author should also consider supplying a link to the location where the external application may be downloaded in case the user does not have the external application installed.
The following example demonstrates how alternate text may be used within an object element.
<object data="http://www.example.com/foo.mp3" type="audio/mpeg"> A really cool audio file. If you want to download and install a plug-in to listen to this file, please go to <a href="http://www.example.com">here</a> </object>
IJ: The previous example is not a good example of hypertext. The link content should not be "here."
One significant consequence of the object element's design is that it offers a mechanism for specifying alternate object processing; each embedded object element declaration may specify alternate content types. If the object handler cannot process the outermost object, it must then process the embedded contents, which may be another object element, etc. In this case, the innermost object element declaration should contain alternative text, the outer object element declarations should not contain alternative text since an embedded object element declaration is present.
A user agent must attempt to process the outermost object element. If the object cannot be processed, then the next level object declaration should be processed. If that object cannot be processed, then the user agent must continue to process each embedded object declaration until the inner most object declaration is reached. Once the inner most object declaration is analyzed and if the user agent cannot process it, then the alternative text of the inner most object declaration should be processed.
IJ: I think the previous two paragraphs can be simplified since the evaluation semantics is defined earlier in the section.
In the following example, we embed several object element declarations to illustrate how alternate processing works. In the following order: (1) an Earth applet, (2) an MPEG animation of the Earth, (3) a GIF image of the Earth, (4) alternate text.
<!-- First, try the applet --> <object data="http://www.example.com/TheEarth.class" type="application/x-java-applet"> <!-- Else, try the MPEG video --> <object data="TheEarth.mpeg" type="video/mpeg" xml:base="http://www.example.com/"> <!-- Else, try the GIF image --> <object data="TheEarth.gif" type="image/gif" xml:base="http://www.example.com/"> <!-- Else process the alternate text --> The <strong>Earth</strong> as seen from space. </object> </object> </object>
The outermost object element declaration specifies an applet that requires no initial values, the data attribute points to the applet class file, and the type attribute defines the mime type. An xml:base attribute could have been used to point to the base location to access the class file. In this example, however, the data attribute value contains an absolute URL so the xml:base attribute was not required. An archive attribute could have been used if the author needed to include any associated jar files. The second object element declaration specifies an MPEG animation, and the xml:base attribute defines the location of the object data defined in the data attribute. We also set the type attribute so that a user agent can determine if it has the capability to process the object data or to invoke an external application to process the MPEG. The third object element declaration specifies a GIF file and furnishes alternate text in case all other mechanisms fail.
Another way to approach the usage of the object element attributes is this way:
attribute | function |
---|---|
archive | For example, when defining an applet you could reference a space-separated list of jar files. |
content-length | This is similar to meta data, in that this can be used by the object handler as a hint to the physical size of the object data that is to be processed. |
data | This URI points to the object data to be processed. This can be an absolute URI (http://www.example.com/datafiles/myinstance.mpg), or a relative URI (myinstance.mpg). If you use a relative URI, then you will need to use the xml:base attribute to define the base location of the object data. This attribute should only refer to the data to be processed. |
declare | This is used to delay the processing of the object data until such time that it is referred to by another element that requires the object data to be processed. In other words, the object data should be downloaded but should not be processed. For example, if an a element is coded to refer to the object element and the a element is activated, then the object data would be processed. |
standby | The author can provide a text string that should be displayed while the object data is being downloaded and processed. |
type | Defining the mime type of the object data will assist the object handler in determining whether the object data can be processed by the user agent or if an external application needs to be launched to process the object data. |
xml:base | Use this attribute to define the base location of the object data. For example: http://www.example.com/datafiles/. This attribute should not be used for any other purpose. |
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 handler:
<object id="clock1" type="application/x-java-applet"> A clock. </object>
Attributes
Possible values:
param elements specify a set of values that may be required to process the object data by an object handler 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 user agent or the external application that will process the object data. This document does not specify how object handlers should retrieve name/value pairs nor how they should interpret parameter names that appear twice.
The user agent or the external application can utilize the param element name/value pairs to pass unique datapoints to trigger specific functions or actions.
IJ: What does "can utilize" mean here? Who chooses?
For example, the user agent may wish to trigger an external application download if the user does not have an appropriate application installed on their system.
We return to the clock example to illustrate the use of the param element. For example, 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 elements.
<object data="http://www.example.com/myclock.class" type="application/x-java-applet"> <param name="height" value="40" valuetype="data" /> <param name="width" value="40" valuetype="data" /> This user agent cannot process a java applet. </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.
<object data="http://www.example.com/gifappli" type="image/gif" standby="Loading Elvis..."> <param name="Init_values" value="./images/elvis.gif" valuetype="ref" /> Elvis lives! </object>
Note that we have also set the standby attribute so that the object handler may display a message while the object data is downloading.
When an object element is processed, the user agent must search the content for only those param elements that are direct children and "feed" them to the object handler.
Thus, in the following example, if "obj1" is processed, then the name/value content of "param1" applies to "obj1" (and not "obj2"). If "obj1" is not processed and "obj2" is, "param1" is ignored, and the name/value content of "param2" applies to "obj2". If neither object element is processed, neither param name/value content applies.
<object data="obj1" type="application/x-something"> <param name="param1" value="value1" /> <object data="obj2" type="application/x-something"> <param name="param2" value="value2" /> This user agent cannot process this application. </object> </object>
The location of an object's data is given by a URI. The URI may be either an absolute URI or a relative URI. If the URI is relative, it may be based from the referring document location or from the xml:base attribute location.
IJ: Please be more precise in the semantics of resolving the relative URI reference; this is unclear: "it may be based from the referring document location or from the xml:base attribute location". Who chooses?
In the following example, we insert a video clip into an XHTML document.
<object data="mymovie.mpg" type="video/mpeg"> A film showing how to open the printer to replace the cartridge. </object>
By setting the type attribute, a user agent can determine whether to retrieve the external application based on its ability to do so.
IJ: I think this is problematic since the authoritative media type is provided through protocols.
The location of the object data is relative to the referencing document, in this example the object data would need to exist within the same directory.
The following example specifies a base location via the xml:base attribute. The data attribute defines the data to process.
<object xml:base="http://www.example.com/" data="mymovie.mpg" type="video/mpeg"> This user agent cannot process this movie. </object>
The following example is for illustrative purposes only. When a document is designed to contain more than one instance of the same object data, it is possible to separate the declaration of the object from the references to the object data. Doing so has several advantages:
To declare an object element so that it is not executed when read by the object handler, set the boolean declare attribute in the object element. At the same time, authors must identify the object declaration by setting the id attribute in the object element to a unique value. Later processing of the object data will refer to this identifier.
A declared object element must appear in a document before the first time the object data is referenced. For example, the delaring object element must appear before a link referencing the object data.
When an object element is defined with the declare attribute, the object handler is instantiated every time an element refers to that object data later in the document. The references will require the object data to be processed (e.g., a link that refers to it is activated, an object element that refers to it is activated, etc.).
In the following example, we declare an object element and cause the object handler to be instantiated by referring to it from a link. Thus, the object data can be activated by clicking on some highlighted text, for example.
<object declare="declare" id="earth.declaration" data="TheEarth.mpg" type="video/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></p>
In the previous example, when the document is initially loaded the object data should not be processed. If this was to be processed within a visual user agent, the object data would not be displayed. When the user selects the anchor data, the object data would then be initialized and displayed. This would also be the case for an audio file, where the file would be instantiated but would not be processed. Selecting the anchor data would then trigger the audio file to be processed.
User agents that do not support the declare attribute must process the contents of the object element.
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), declare ("declare"), src (URI), type* (ContentType), xml:space="preserve" | PCDATA | script | noscript |
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 will be rendered if and only if the containing script is not processed.
IJ: The preceding sentence is user agent rendering behavior that is relevant for conformance.
noscript elements that are not contained in a script element will only be rendered in the following cases:
User agents that do not support client-side scripts must render this element's contents.
IJ: The user MUST be able to configure the user agent to turn off execution of scripts; see UAAG 1.0 checkpoint 3.4.
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" src="http://example.org/script"> <noscript> <p>Access the <a href="http://example.org/data">data.</a></p> </noscript> </script>
Attributes
IJ: This refers to the <object> element; is that correct?
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.
IJ: The above paragraph is an example of user agent behavior required for conformance.
Scripts are evaluated by script engines that must be known to a user agent.
A user agent must interpret a script element according to the following precedence rules:
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". The JavaScript code contained in the inner script will be evaluated if and only if the user agent isn't evaluating the outer script. We also include one script in the body, which contains its own script written in "text/x-perl".
<html xmlns="http://www.w3.org/2002/06/xhtml2"> <head> <title>A document with script</title> <script type="text/x-vbscript" src="http://example.org/progs/vbcalc"> <script type="text/javascript"> ...some inline JavaScript... </script> </script> </head> <body> <script type="text/x-perl"/> </body> </html>
Note that because of the XML processing model, where a document is first
parsed before being processed, the form of dynamic generation used in earlier
versions of HTML, using document.write
cannot be used in XHTML2.
To dynamically generate content in XHTML you have to add elements to the DOM
tree using DOM calls [DOM] rather than
using document.write
top generate text that then gets parsed.
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 | Common, media (MediaDesc) | 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
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.
IJ: This might be the first instance of the term "error" in the specification. What does it mean when there is an error? Instead, define the required user agent behavior. Perhaps this should be expressed as "display:none"? Can the user override this? I would add that this does not take into account a "source view", which is a perfectly valid rendering of this content. Instead, just talk about this in terms of default rendering. Let the user override this if the user chooses (even if not useful).
The syntax of style data depends on the style sheet language.
Rules for style rule precedences and inheritance depend on the style sheet language.
Example:
<head> <style type="text/css"> h1 {border-width: thin; border-style: solid; text-align: center} </style> </head>
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.
IJ: What does the previous sentence mean? The part about media descriptors is underspecified, in my opinion.
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.
IJ: See UAAG 1.0, checkpoint 4.14 for requirements related to selecting from among author-specified style sheets, specifying a user style sheet, and turning of author and user style sheets. Please make these MUST requirements.
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.
IJ: This is an example of user agent behavior required for conformance.
This section is normative.
The Tables Module provides elements for marking up tabular information in a document.
The 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.
Visual user agents allow sighted people to quickly grasp the structure of the table from the headings as well as the caption. A consequence of this is that captions will often be inadequate as a summary of the purpose and structure of the table from the perspective of people relying on non-visual user agents.
IJ: See UAAG 1.0, checkpoint 10.1 for requirements related to tables.
Authors should therefore take care to provide additional information summarizing the purpose and structure of the table using the summary attribute of the table element. This is especially important for tables without captions. The example below illustrates the use of the summary attribute.
User agents must provide access to the content of the summary attribute. As an example, access could be provided through a menu option, a mouse-over function, or through a dialog.
IJ: See UAAG 1.0, checkpoint 2.3 for requirements related to rendering conditional content such as "summary".
The following example demonstrates the difference between a table caption and a table summary.
<table summary="The table defines the class roster. The columns contain the following data: students name, permanent address, permanent phone, local address, local phone, declared major, assigned academic advisor, student standing"> <caption>Student Class Roster</caption> ...the rest of the table... </table>
Visual user agents must 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. For example, the author may wish to divide the columns into logical groups such as the student's permanent address, phone number and emergency contact information. And group the student's local address, phone and email address into another logical group.
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. For example, the author may wish to apply a specific style to the student's permanent data and apply a different style to the student's local data.
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 element is that authors may logically group multiple columns. By grouping columns, the author can apply rules across the entire group. The author can also apply column width balancing across the group of columns. For example, if the author has a table with five columns and the author divides the table into two column groups, one with three columns and the other with two columns. The author could define the first column group to consume 300 pixels and the second column group to consume 100 pixels. Each column within the first column group would be 100 pixels wide and the remaining two columns would be 50 pixels wide. If the author added embedded col elements, she could force one or more columns to be a specific width and the remaining columns within the group would be evenly divided within the remaining allotted width.
For example, the following table defines a column group and embedded columns with differing widths.
<style type="text/css"> #colgrp1 {width: 300} #col1 {width: 100} #col2 {width: 50} </style> ... <table> <colgroup id="colgrp1"> <col id="col1" span="3"> <col id="col2" span="2"> </colgroup> ...the rest of the table... </table>
In this example, the defined width for the colgroup constrains all of the columns to fit within that value regardless of the of the defined values within the col eleemnts. In this example, the width of the columns within the column group must be constrained to fit the defined width of the column group.
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).
There are two ways to determine the number of columns in a table (in order of precedence):
It is an error if a table contains colgroup or col elements and the two calculations do not result in the same number of columns.
Once the user agent has calculated the number of columns in the table, it may group them into a colgroup.
Attributes
The table element contains all other elements that specify the caption, column groups, columns, rows, and content for a table.
The following informative list describes what operations visual user agents may carry out when rendering a table:
IJ: The list is described as informative, but bullet 3 includes a "must" requirement.
The XHTML table model has been designed so that, with author assistance, user agents may render tables incrementally (i.e., as table rows arrive) rather than having to wait for all the data before beginning to render.
In order for a user agent to format a table in one pass, authors must tell the user agent:
IJ: Is this really an authoring "must" requirement, or should it be expressed as "If the author does this, this allows the user agent to..."?
More precisely, a user agent may render a table in a single pass when the column widths are specified using a combination of colgroup and col elements. If any of the columns are specified in relative or percentage terms, authors must also specify the width of the table itself.
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.
IJ: The previous sentence should be rewritten in terms of required user agent behavior.
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.
This section provides more detailed discussion on cell header data and how non-visual agents may utilize that information.
IJ: I would like to talk to WAI PF about whether these attributes are used (or useful) in practice.
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 authors a means to customize rendering (e.g., through style sheets).
In the absence of header information from either the scope or headers attribute, user agents may construct header information according to the following algorithm. The goal of the algorithm is to find an ordered list of headers. (In the following description of the algorithm the table directionality is assumed to be left-to-right.)
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
IJ: The user agent SHOULD allow the user to configure the user agent to render the value of this attribute instead of the cell contents; see UAAG 1.0 checkpoint 2.3.
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.
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 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.