This document has been modified by Henri Sivonen to serve as a DOM performance test case. Specifically, a script that walks the DOM and times itself has been added.
You can take part in this work. Join the working group's discussion list.
© Copyright 2004-2006 Apple Computer, Inc., Mozilla Foundation, and Opera Software ASA.
You are granted a license to use, reproduce and create derivative works of this document.
This specification introduces features to HTML and the DOM that ease the authoring of Web-based applications. Additions include the context menus, a direct-mode graphics canvas, inline popup windows, server-sent events, and more.
This is a work in progress! This document is changing on a daily if not hourly basis in response to comments and as a general part of its development process. Comments are very welcome, please send them to whatwg@whatwg.org. Thank you.
Implementors should be aware that this specification is not stable. Implementors who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this specification before it eventually reaches the call for implementations should join the WHATWG mailing list and take part in the discussions.
This draft may contain namespaces that use the uuid: URI
scheme. These are temporary and will be changed before those parts of the
specification are ready to be implemented in shipping products.
To find the latest version of this working draft, please follow the "Latest version" link above.
Sections marked [TBW] are placeholders for future text. Sections marked [WIP] are very early drafts that need much more work. Other sections are first drafts that are ready for substantial comments.
Sections marked [SCS] are sections intended to be self-contained (Self Contained Section). Such sections are considered logical units that it would make sense to implement independent of most of the rest of the specification, provided that enough of the infrastructure is already implemented.
It is not expected that any new major sections will be added to this specification beyond those already present (though much work still remains in the sections that are present).
This specification is intended to replace (be the new version of) what was previously the HTML4, XHTML 1.x, and DOM2 HTML specifications.
body element
section element
nav element
article element
blockquote element
aside element
h1, h2,
h3, h4, h5,
and h6 elements
header element
footer element
address element
a element
q element
cite element
em element
strong element
small element
m element
dfn element
abbr element
i element
t element [WIP]
meter element
progress element
code element
var element
samp element
kbd element
sup and sub elements
span element
bdo element
br element
datagrid element
command element
menu element
DocumentWindow interface
Window interface
document.write(), innerHTML [TBW]
DocumentStyle interface
contenteditable
attribute
The World Wide Web's markup language has always been HTML. HTML was primarily designed as a language for semantically describing scientific documents, although its general design and adaptations over the years has enabled it to be used to describe a number of other types of documents.
The main area that has not been adequately addressed by HTML is a vague subject referred to as Web Applications. This specification attempts to rectify this, while at the same time updating the HTML specifications to address issues raised in the past few years.
This specification is limited to providing a semantic-level markup language and associated semantic-level scripting APIs for authoring accessible pages on the Web ranging from static documents to dynamic applications.
The scope of this specification does not include addressing presentation concerns.
The scope of this specification does not include documenting every HTML
or DOM feature supported by Web browsers. Browsers support many features
that are considered to be very bad for accessibility or that are otherwise
inappropriate. For example, the blink element is clearly
presentational and authors wishing to cause text to blink should instead
use CSS.
The scope of this specification is not to describe an entire operating system. In particular, office productivity applications, image manipulation, and other applications that users would be expected to use with high-end workstations on a daily basis are out of scope. In terms of applications, this specification is targetted specifically at applications that would be expected to be used by users on an occasional basis, or regularly but from disparate locations. For instance online purchasing systems, searching systems, games (especially multiplayer online games), public telephone books or address books, communications software (e-mail clients, instant messaging clients, discussion software), etc.
For sophisticated cross-platform applications, there already exist several proprietary solutions (such as Mozilla's XUL and Macromedia's Flash). These solutions are evolving faster than any standards process could follow, and the requirements are evolving even faster. These systems are also significantly more complicated to specify, and are orders of magnitude more difficult to achieve interoperability with, than the solutions described in this document. Platform-specific solutions for such sophisticated applications (for example the MacOS X Core APIs) are even further ahead.
This spec is probably big enough to need a guide as to where to look for various things. Hence once the structure is stable we should probably fill out this section.
This section will probably be dropped in due course.
HTML, CSS, DOM, and JavaScript provide enough power that Web developers have managed to base entire businesses on them. What is required are extensions to these technologies to provide much-needed features such as:
DOMActivate is a start, but it lacks equivalent HTML
attributes, and additional events may be needed.Some less important features would be good to have as well:
Several of the features in these two lists have been supported in non-standard ways by some user agents for some time.
This specification represents a new version of HTML4 and XHTML1, along with a new version of the associated DOM2 HTML API. Migration from HTML4 or XHTML1 to the format and APIs described in this specification should in most cases be straightforward, as care has been taken to ensure that backwards-compatibility is retained.
XHTML2 [XHTML2] defines a new HTML vocabulary with better features for hyperlinks, multimedia content, annotating document edits, rich metadata, declarative interactive forms, and describing the semantics of human literary works such as poems and scientific papers.
However, it lacks elements to express the semantics of many of the non-document types of content often seen on the Web. For instance, forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well, and are not covered by XHTML2.
This specification aims to extend HTML so that it is also suitable in these contexts.
XHTML2 and this specification use different namespaces and therefore can both be implemented in the same XML processor.
This specification is designed to complement Web Forms 2.0. [WF2] Where Web Forms concentrates on input controls, data validation, and form submission, this specification concentrates on client-side user interface features needed to create modern applications.
Eventually WF2 will simply be folded into this spec.
This specification is independent of the various proprietary UI languages that various vendors provide.
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in [RFC2119]. For readability, these words do not appear in all uppercase letters in this specification.
This specification describes the conformance criteria for user agents (relevant to implementors) and documents (relevant to authors and authoring tool implementors).
There is no implied relationship between document conformance requirements and implementation conformance requirements. User agents are not free to handle non-conformant documents as they please; the processing model described in this specification applies to implementations regardless of the conformity of the input documents.
User agents fall into several (overlapping) categories with different conformance requirements.
Web browsers that support XHTML must process elements and attributes from the XHTML namespace found in XML documents as described in this specification, so that users can interact with them, unless the semantics of those elements have been overridden by other specifications.
A conforming XHTML processor would, upon finding an
XHTML script element in an XML
document, execute the script contained in that element. However, if the
element is found within an XSLT transformation sheet (assuming the UA
also supports XSLT), then the processor would instead treat the script element as an opaque element that
forms part of the transform.
Web browsers that support HTML must
process documents labelled as text/html as described in
this specification, so that users can interact with them.
User agents that process HTML and XHTML documents purely to render non-interactive versions of them must comply to the same conformance criteria as Web browsers, except that they are exempt from requirements regarding user interaction.
Typical examples of non-interactive presentation user agents are printers (static UAs) and overhead displays (dynamic UAs). It is expected that most static non-interactive presentation user agents will also opt to lack scripting support.
A non-interactive but dynamic presentation UA would still execute scripts, allowing forms to be dynamically submitted, and so forth. However, since the concept of "focus" is irrelevant when the user cannot interact with the document, the UA would not need to support any of the focus-related DOM APIs.
Implementations that do not support scripting (or which have their scripting features disabled) are exempt from supporting the events and DOM interfaces mentioned in this specification. For the parts of this specification that are defined in terms of an events model or in terms of the DOM, such user agents must still act as if events and the DOM were supported.
Scripting can form an integral part of an application. Web browsers that do not support scripting, or that have scripting disabled, might be unable to fully convey the author's intent.
Conformance checkers must verify that a document conforms to the
applicable conformance criteria described in this specification.
Conformance checkers are exempt from detecting errors that require
interpretation of the author's intent (for example, while a document is
non-conforming if the content of a blockquote element is not a quote,
conformance checkers do not have to check that blockquote elements only contain quoted
material).
Conformance checkers must check that the input document conforms when scripting is disabled, and should also check that the input document conforms when scripting is enabled. (This is only a "SHOULD" and not a "MUST" requirement because it has been proven to be impossible. [HALTINGPROBLEM])
The term "validation" specifically refers to a subset of conformance checking that only verifies that a document complies with the requirements given by an SGML or XML DTD. Conformance checkers that only perform validation are non-conforming, as there are many conformance requirements described in this specification that cannot be checked by SGML or XML DTDs.
To put it another way, there are three types of conformance criteria:
A conformance checker must check for the first two. A simple DTD-based validator only checks for the first class of errors and is therefore not a conforming conformance checker according to this specification.
Applications and tools that process HTML and XHTML documents for reasons other than to either render the documents or check them for conformance should act in accordance to the semantics of the documents that they process.
A tool that generates document outlines but increases the nesting level for each paragraph and does not increase the nesting level for each section would not be conforming.
Authoring tools and markup generators must generate conforming documents. Conformance criteria that apply to authors also apply to authoring tools, where appropriate.
This needs expanding (see source).
Some conformance requirements are phrased as requirements on elements, attributes, methods or objects. Such requirements fall into two categories; those describing content model restrictions, and those describing implementation behaviour. The former category of requirements are requirements on documents and authoring tools. The second category are requirements on user agents.
Conformance requirements phrased as algorithms or specific steps may be implemented in any manner, so long as the end result is equivalent. (In particular, the algorithms defined in this specification are intended to be easy to follow, and not intended to be performant.)
User agents may impose implementation-specific limits on otherwise unconstrained inputs, e.g. to prevent denial of service attacks, to guard against running out of memory, or to work around platform-specific limitations.
For compatibility with existing content and prior specifications, this specification describes two authoring formats: one based on XML (referred to as XHTML5), and one using a custom format inspired by SGML (referred to as HTML5). Implementations may support only one of these two formats, although supporting both is encouraged.
XML documents using elements from the XHTML namespace that use the new
features described in this specification and that are served over the wire
(e.g. by HTTP) must be sent using an XML MIME type such as
application/xml or application/xhtml+xml and
must not be served as text/html. [RFC3023]
These XML documents may contain a DOCTYPE if desired, but
this is not required to conform to this specification.
HTML documents that use the new features described in this specification
and that are served over the wire (e.g. by HTTP) must be sent as
text/html and must start with the following DOCTYPE:
<!DOCTYPE html>.
This specification refers to both HTML and XML attributes and DOM attributes, often in the same context. When it is not clear which is being referred to, they are referred to as content attributes for HTML and XML attributes, and DOM attributes for those from the DOM. Similarly, the term "properties" is used for both ECMAScript object properties and CSS properties. When these are ambiguous they are qualified as object properties and CSS properties respectively.
To ease migration from HTML to XHTML, UAs conforming
to this specification will place elements in HTML in the
http://www.w3.org/1999/xhtml namespace, at least for the
purposes of the DOM and CSS. The term "elements in the
HTML namespace", when used in this specification, thus refers to
both HTML and XHTML elements.
Unless otherwise stated, all elements defined or mentioned in this
specification are in the http://www.w3.org/1999/xhtml
namespace, and all attributes defined or mentioned in this specification
have no namespace (they are in the per-element partition).
Generally, when the specification states that a feature applies to HTML or XHTML, it also includes the other. When a feature specifically only applies to one of the two languages, it is called out by explicitly stating that it does not apply to the other format, as in "for HTML, ... (this does not apply to XHTML)".
For readability, the term URI is used to refer to both ASCII URIs and Unicode IRIs, as those terms are defined by [RFC3986] and [RFC3987] respectively. On the rare occasions where IRIs are not allowed but ASCII URIs are, this is called out explicitly.
The term root element, when not qualified to explicitly refer to the document's root element, means the furthest ancestor element node of whatever node is being discussed, or the node itself is there is none. When the node is a part of the document, then that is indeed the document's root element. However, if the node is not currently part of the document tree, the root element will be an orphaned node.
When it is stated that some element or attribute is ignored, or treated as some other value, or handled as if it was something else, this refers only to the processing of the node after it is in the DOM. A user agent must not mutate the DOM in such situations.
When an XML name, such as an attribute or element name, is referred to
in the form prefix:localName, as in xml:id or
svg:rect, it refers to a name with the local name localName and the namespace given by the prefix, as defined
by the following table:
xml
http://www.w3.org/XML/1998/namespace
html
http://www.w3.org/1999/xhtml
svg
http://www.w3.org/2000/svg
For simplicity, terms such as shown, displayed, and visible might sometimes be used when referring to the way a document is rendered to the user. These terms are not meant to imply a visual medium; they must be considered to apply to other media in equivalent ways.
This specification uses the term HTML documents to generally refer to any use of HTML, ranging from short static documents to long essays or reports with rich multimedia, as well as to fully-fledged interactive applications.
Various DOM interfaces are defined in this specification using pseudo-IDL. This looks like OMG IDL but isn't. For instance, method overloading is used, and types from the W3C DOM specifications are used without qualification. Language-specific bindings for these abstract interface definitions must be derived in the way consistent with W3C DOM specifications. Some interface-specific binding information for ECMAScript is included in this specification.
The construction "a Foo object", where Foo is
actually an interface, is sometimes used instead of the more accurate "an
object implementing the interface Foo".
The terms fire and dispatch are used interchangeably in the context of events, as in the DOM Events specifications. [DOM3EVENTS]
If a DOM object is said to be live, then that means that any attributes returning that object must always return the same object (not a new object each time), and the attributes and methods on that object must operate on the actual underlying data, not a snapshot of the data.
As the specification evolves, these conformance requirements will most likely be moved to more appropriate places. For now it's not clear where they should go.
When a UA needs to convert a string to a number, algorithms equivalent to those specified in ECMA262 sections 9.3.1 ("ToNumber Applied to the String Type") and 8.5 ("The Number type") should be used (possibly after suitably altering the algorithms to handle numbers of the range that the UA can support). [ECMA262]
DOM mutation events must not fire for
changes caused by the UA parsing the document. (Conceptually, the parser
is not mutating the DOM, it is constructing it.) This includes the parsing
of any content inserted using document.write() and
document.writeln() calls. Other changes, including fragment
insertions involving innerHTML and similar attributes, must
fire mutation events. [DOM3EVENTS]
The default value of
Content-Style-Type and the default value of the type attribute of the
style element is is
text/css.
The default value of
Content-Script-Type and the default value of the type attribute of the
script element is the ECMAScript MIME
type.
User agents must follow the rules given by XML Base to resolve relative URIs in HTML and XHTML fragments. [XMLBASE]
It is possible for xml:base attributes to be
present even in HTML fragments, as such attributes can be added
dynamically using script.
This section is non-normative.
An introduction to marking up a document.
The Document Object Model (DOM) is a representation — a model — of the document and its content. [DOM3CORE] The DOM is not just an API; operations on the in-memory document are defined, in this specifiation, in terms of the DOM.
DOM3 Core defines mechanisms for checking for interface support, and for obtaining implementations of interfaces, using feature strings. [DOM3CORE]
A DOM application can use the hasFeature(feature, version) method of the
DOMImplementation interface with parameter values "HTML" and "5.0" (respectively) to determine
whether or not this module is supported by the implementation. In addition
to the feature string "HTML", the feature string
"XHTML" (with version string "5.0") can
be used to check if the implementation supports XHTML. User agents should
respond with a true value when the hasFeature method is queried with these
values. Authors are cautioned, however, that UAs returning true might not
be perfectly compliant, and that UAs returning false might well have
support for features in this specification; in general, therefore, use of
this method is discouraged.
The values "HTML" and "XHTML" (both with version "5.0") should also
be supported in the context of the getFeature() and
isSupported() methods, as defined by DOM3 Core.
The interfaces defined in this specification are not always
supersets of the interfaces defined in DOM2 HTML; some features that were
formerly deprecated, poorly supported, rarely used or considered
unnecessary have been removed. Therefore it is not guarenteed that an
implementation that supports "HTML"
"5.0" also supports "HTML"
"2.0".
Some DOM attributes are defined to reflect a particular content attribute. This means that on getting, the DOM attribute returns the current value of the content attribute, and on setting, the DOM attribute changes the value of the content attribute to the given value.
If a reflecting DOM attribute is a DOMString attribute
defined to contain a URI, then on getting, the DOM attribute returns the
value of the content attribute, resolved to an absolute URI, and on
setting, sets the content attribute to the specified literal value. If the
content attribute is absent, the DOM attribute must return the default
value, if the content attribute has one, or else the empty string.
If a reflecting DOM attribute is a DOMString attribute that
is not defined to contain a URI, then the getting and setting is done in a
transparent, case-sensitive manner, except if the content attribute is
defined to only allow a specific set of values. In this latter case, the
attribute's value is first converted to
lowercase before being returned. If the content
attribute is absent, the DOM attribute must return the default value, if
the content attribute has one, or else the empty string.
If a reflecting DOM attribute is a boolean attribute, then the DOM attribute returns true if the attribute is set, and false if it is absent. On setting, the content attribute is removed if the DOM attribute is set to false, and is set to have the same value as its name if the DOM attribute is set to true.
If a reflecting DOM attribute is a numeric type (long) then
the content attribute must be converted to a numeric
type first (truncating any fractional part). If that fails, or if the
attribute is absent, the default value should be returned instead, or 0 if
there is no default value. On setting, the given value is converted to a
string representing the number in base ten and then that string should be
used as the new content attribute value.
In the ECMAScript DOM binding, the ECMAScript
native Function type must implement the
EventListener interface such that invoking the
handleEvent() method of that interface on the object from
another language binding invokes the function itself, with the
event argument as its only argument. In the ECMAScript
binding itself, however, the handleEvent() method of the
interface is not directly accessible on Function objects.
Such functions must be called in the global scope. If the function returns
false, the event's preventDefault() method must then invoked.
Exception: for historical reasons, for the HTML mouseover
event, the preventDefault() method must be called when the
function returns true instead.
In HTML, event handler attributes (such as
onclick) are invoked as if they were functions implementing
EventListener, with the argument called event.
Such attributes are added as non-capture event listeners of the type given
by their name (without the leading on prefix). Only
attributes actually defined by specifications
implemented by the UA (e.g. HTML, Web Forms 2, Web
Apps) are actually
registered, however. If, for example, an author created an
onfoo attribute, it would not be fired for foo
events.
The scope chain for ECMAScript executed in HTML
event handler attributes must link from the activation object for the
handler, to its this parameter (the event target), to the
element's form element if it is a form control, to the
document, to the default view (the Window object).
This definition is compatible with how most browsers implemented DOM Level 0, but does not exactly describe IE's behaviour. See also ECMA262 Edition 3, sections 10.1.6 and 10.2.3, for more details on activation objects. [ECMA262]
Certain operations and methods are defined as firing events on elements.
For example, the click() method on the HTMLCommandElement is defined as
firing a click event on the element. [DOM3EVENTS]
Firing a click event means that a click
event in the http://www.w3.org/2001/xml-events namespace,
which bubbles and is cancelable, and which uses the
MouseEvent interface, must be dispatched at the given
element. The event object must have its screenX,
screenY, clientX, clientY, and button attributes set
to 0, its ctrlKey, shiftKey,
altKey, and metaKey attributes
set according to the current state of the key input device, if any (false
for any keys that are not available), its detail
attribute set to 1, and its relatedTarget attribute
set to null. The getModifierState() method on the
object must return values appropriately describing the state of the key
input device at the time the event is created.
Firing a change event means that a change
event in the http://www.w3.org/2001/xml-events namespace,
which bubbles but is not cancelable, and which uses the Event
interface, must be dispatched at the given element. The event object must
have its detail attribute set to 0.
Firing a contextmenu event means that a
contextmenu event in the
http://www.w3.org/2001/xml-events namespace, which bubbles
and is cancelable, and which uses the Event interface, must
be dispatched at the given element. The event object must have its detail attribute set to 0.
Firing a show event means that a show event in the
http://www.w3.org/2001/xml-events namespace, which does not
bubble but is cancelable, and which uses the Event interface,
must be dispatched at the given element. The event object must have its
detail attribute set to 0.
The default action of these event is to do nothing unless otherwise stated.
If you dispatch a custom "click" event at an element that would normally have default actions, they should get triggered. We need to go through the entire spec and make sure that any default actions are defined in terms of any event of the right type on that element, not those that are dispatched in expected ways.
textContent attributeSome elements are defined in terms of their DOM textContent attribute. This is an
attribute defined on the Node interface in DOM3 Core. [DOM3CORE]
Should textContent be defined differently for dir="" and <bdo>? Should we come up with an alternative to textContent that handles those and other things, like alt=""?
Still need to define HTMLCollection.
interface DOMTokenString {
boolean has(in DOMString token);
void add(in DOMString token);
void remove(in DOMString token);
};
Need to define those members.
Every XML and HTML document in an HTML UA must be represented by a
Document object. [DOM3CORE]
All Document objects (in user agents implementing this
specification) must also implement the HTMLDocument interface, available using
binding-specific methods.
Document objects must also implement the document-level
interface of any other namespaces found in the document that the UA
supports. For example, if an HTML implementation also supports SVG, then
the Document object must implement HTMLDocument and SVGDocument.
interface HTMLDocument : Document { attribute DOMString title; readonly attribute DOMString referrer; readonly attribute DOMString domain; readonly attribute DOMString URL; attribute HTMLElement body; readonly attribute HTMLCollection images; readonly attribute HTMLCollection applets; readonly attribute HTMLCollection links; readonly attribute HTMLCollection forms; readonly attribute HTMLCollection anchors; attribute DOMString cookie; void open(); void close(); void write(in DOMString text); void writeln(in DOMString text); NodeList getElementsByName(in DOMString elementName); NodeList getElementsByClassName(in DOMString className1 [, in DOMString className2, ...] ); };
The Document objects of documents that are
being rendered in a browsing context
will also implement the DocumentWindow and DocumentStyle interfaces.
Need to define those members; the body attribute will be used to define
the body element.
The getElementsByClassName()
method takes one or more strings representing classes and must return all
the elements in that document that are of all those classes. HTML, XHTML,
SVG and MathML elements define which classes they are in by having an
attribute in the per-element partition with the name class containing a space-separated list of
classes to which the element belongs. Other specifications may also allow
elements in their namespaces to be labelled as being in specific classes.
UAs must not assume that all attributes of the name class for elements in any namespace work in this
way, however, and must not assume that such attributes, when used as
global attributes, label other elements as being in specific classes.
There is an open issue on whether we should use multiple arguments or just one argument that needs to be split on spaces.
The space character (U+0020) is not special in the method's arguments. In HTML, XHTML, SVG and MathML it is impossible for an element to belong to a class whose name contains a space character, however, and so typically the method would return no nodes if one of its arguments contained a space.
Similarly, if the method is passed an argument consisting of the empty string, it will typically not return any nodes since in HTML, XHTML, SVG and MathML it is impossible to assign an element to the "" class.
Given the following XHTML fragment:
<div id="example"> <p id="p1" class="aaa bbb"/> <p id="p2" class="aaa ccc"/> <p id="p3" class="bbb ccc"/> </div>
A call to
document.getElementById('example').getElementsByClassName('aaa')
would return a NodeList with the two paragraphs
p1 and p2 in it. A call to
getElementsByClassName('ccc', 'bbb') would only return one
node, however, namely p3.
A call to getElementsByClassName('aaa bbb') would return
no nodes; none of the elements above are in the "aaa bbb" class.
The nodes representing HTML elements in the DOM must implement, and expose to scripts, the interfaces listed for them in the relevant sections of this specification. This includes XHTML elements in XML documents, even when those documents are in another context (e.g. inside an XSLT transform).
The basic interface, from which all the HTML elements' interfaces
inherit, and which is used by elements that have no additional
requirements, is the HTMLElement
interface.
Define HTMLElement here.
In HTML documents, for HTML elements, the DOM APIs must return tag names and attributes names in uppercase, regardless of the case with which they were created. This does not apply to XML documents; in XML documents, the DOM APIs must always return tag names and attribute names in the original case used to create those nodes.
An element is said to have been inserted into a document when either its
parentNode DOM attribute changes and its new value is the
Document in question, or, when the DOM node represented by
its parentNode, if any, has itself just been inserted
into a document.
There are various places in HTML that accept particular data types, such as dates or numbers. This section describes what the conformance criteria for content in those formats is, and how to parse them.
A valid floating point number ...
A valid denominator punctuation character ...
The value associated with each denominator punctuation character is ...
U+0025 PERCENT SIGN
U+066A ARABIC PERCENT SIGN
U+FE6A SMALL PERCENT SIGN
U+FF05 FULLWIDTH PERCENT SIGN
=> 100
U+2030 PER MILLE SIGN
=> 1000
U+2031 PER TEN THOUSAND SIGN
=> 10000
The rules for parsing floating point number values ...
...
The steps for finding one or two numbers in a string are as follows:
The algorithm to find a number is as follows. It is given a string and a starting position, and returns either nothing, a number, or an error condition.
...
Elements, attributes, and attribute values in HTML are defined (by this
specification) to have certain meanings (semantics). For example, the
ol element represents an ordered list, and
the lang attribute
represents the language of the content.
Authors must only use elements, attributes, and attribute values for their appropriate semantic purposes.
For example, the following document is non-conforming, despite being syntactically correct:
<!DOCTYPE html>
<html lang="en-GB">
<head> <title> Demonstration </title> </head>
<body>
<table>
<tr> <td> My favourite animal is the cat. </td> </tr>
<tr>
<td>
—<a href="http://example.org/~ernest/"><cite>Ernest</cite></a>,
in an essay from 1992
</td>
</tr>
</table>
</body>
</html>
...because the data placed in the cells is clearly not tabular data. A corrected version of this document might be:
<!DOCTYPE html> <html lang="en-GB"> <head> <title> Demonstration </title> </head> <body> <blockquote> <p> My favourite animal is the cat. </p> </blockquote> <p> —<a href="http://example.org/~ernest/"><cite>Ernest</cite></a>, in an essay from 1992 </p> </body> </html>
This next document fragment, intended to represent the heading of a corporate site, is similarly non-conforming because the second line is not intended to be a heading of a subsection, but merely a subheading or subtitle (a subordinate heading for the same section).
<body> <h1>ABC Company</h1> <h2>Leading the way in widget design since 1432</h2> ...
The header element should be used
in these kinds of situations:
<body> <header> <h1>ABC Company</h1> <h2>Leading the way in widget design since 1432</h2> </header> ...
Through scripting and using other mechanisms, the values of attributes, text, and indeed the entire structure of the document may change dynamically while a user agent is processing it. The semantics of a document at an instant in time are those represented by the state of the document at that instant in time, and the semantics of a document can therefore change over time. User agents must update their presentation of the document as this occurs.
HTML has a progress element that describes a progress
bar. If its "value" attribute is dynamically updated by a script, the UA
would update the rendering to show the progress changing.
All the elements in this specification have a defined content model, which describes what nodes are allowed inside the elements, and thus what the structure of an HTML document or fragment must look like. Authors must only put elements inside an element if that element allows them to be there according to its content model.
For the purposes of determining if an element matches its content model or not, CDATA nodes in the DOM must be treated as text nodes, and character entity reference nodes must be treated as if they were expanded in place.
The whitespace characters U+0020 SPACE, U+000A LINE FEED, and U+000D CARRIAGE RETURN are always allowed between elements. User agents must always represent these characters between elements in the source markup as text nodes in the DOM. Empty text nodes and text nodes consisting of just sequences of those characters are considered inter-element whitespace and must be ignored when establishing whether an element matches its content model or not.
Authors must only use elements from the HTML namespace in the contexts where they are allowed, as defined for each element. For XML compound documents, these contexts could be inside elements from other namespaces, if those elements are defined as providing the relevant contexts.
The SVG specification defines the SVG foreignObject
element as allowing foreign namespaces to be included, thus allowing
compound documents to be created by inserting subdocument content under
that element. This specification defines the XHTML html element as being allowed where subdocument
fragments are allowed in a compound document. Together, these two
definitions mean that placing an XHTML html element as a child of an SVG
foreignObject element is conforming.
Each element in HTML falls into zero or more categories that group elements with similar characteristics together. This specification uses the following categories:
Some elements have unique requirements and do not fit into any particular category.
Block-level elements are used for structural grouping of page content.
There are several kinds of block-level elements:
blockquote, section, article, header.
p, h1-h6, address.
nav, aside, footer, div.
ul, ol, dl, table, script.
There are also elements that seem to be block-level but aren't, such as
body, li, dt, dd, and td. These elements are allowed
only in specific places, not simply anywhere that block-level elements are
allowed.
Some block-level elements play multiple roles. For instance, the
script elements is allowed inside
head elements and can also be used as
inline-level content. Similarly,
the ul, ol, dl,
table, and blockquote
elements play dual roles as both block-level and inline-level elements.
Inline-level content consists of text and various elements to annotate the text, as well as some embedded content (such as images or sound clips).
Inline-level content comes in various types:
a, i, noscript. Elements used in contexts allowing
only strictly inline-level content must not contain anything other than
strictly inline-level content.
ol, blockquote, table.
Unless an element's content model explicitly states that it must contain significant inline content, simply having no text nodes and no elements satisfies an element whose content model is some kind of inline content.
Some elements are defined to have as a content model significant inline content. This means that at least one descendant of the element must be significant text or embedded content.
Significant text, for the purposes of determining the presence of significant inline content, consists of any character other than those falling in the Unicode categories Zs, Zl, Zp, Cc, and Cf. [UNICODE]
The following three paragraphs are non-conforming because their content model is not satisfied (they all count as empty).
<p></p> <p><em> </em></p> <p> <ol> <li></li> </ol> </p>
Some elements are defined to have content models that allow either
block-level elements or inline-level content, but not both. For
example, the aside and li elements.
To establish whether such an element is being used as a block-level container or as an inline-level container, for example in order to determine if a document conforms to these requirements, user agents must look at the element's child nodes. If any of the child nodes are not allowed in block-level contexts, then the element is being used for inline-level content. If all the child nodes are allowed in a block-level context, then the element is being used for block-level elements.
For instance, in the following (non-conforming) fragment, the li element is being used as an inline-level
element container, because the style
element is not allowed in a block-level context. (It doesn't matter, for
the purposes of determining whether it is an inline-level or block-level
context, that the style element is not
allowed in inline-level contexts either.)
<ol> <li> <p> Hello World </p> <style> /* This example is illegal. */ </style> </li> </ol>
In the following fragment, the aside
element is being used as a block-level container, because even though all
the elements it contains could be considered inline-level elements, there
are no nodes that can only be considered inline-level.
<aside> <ol> <li> ... </li> </ol> <ul> <li> ... </li> </ul> </aside>
On the other hand, in the following similar fragment, the aside element is an inline-level container,
because the text ("Foo") can only be considered inline-level.
<aside> <ol> <li> ... </li> </ol> Foo </aside>
Certain elements in HTML can be activated, for instance a elements, button elements, or
input elements when their type attribute is set
to radio. Activation of those elements can happen in various
(UA-defined) ways, for instance via the mouse or keyboard.
When activation is performed via some method other than clicking the
pointing device, the default action of the event that triggers the
activation must, instead of being activating the element directly, be to
fire a click
event on the same element.
The default action of this click event,
or of the real click event if the element
was activated by clicking a pointing device, must be to dispatch yet
another event, namely DOMActivate.
It is the default action of that event that then performs the
actual action.
For certain form controls, this process is complicated further by changes that must happen around the click event. [WF2]
Most interactive elements have content models that disallowed nesting interactive elements.
Need to define how default actions actually work. For instance, if you click an event inside a link, the event is triggered on that element, but then we'd like a click is sent on the link itself. So how does that happen? Does the link have a bubbling listener that triggers that second click event? what if there are multiple nested links, which one should we send that event to?
User agents must support the following common attributes on all elements in the HTML namespace (including elements that are not defined by this specification).
id
The element's unique identifier. The value must be unique in the document and must contain at least one character.
If the value is not the empty string, user agents must associate the
element with the given value (exactly) for the purposes of ID matching
(e.g. for selectors in CSS or for the getElementById()
method in the DOM).
Identifiers are opaque strings. Particular meanings should not be
derived from the value of the id attribute.
When an element has an ID set through multiple methods (for example,
if it has both id and
xml:id attributes simultaneously [XMLID]), then the element has multiple
identifiers. User agents must use all of an HTML element's identifiers
(including those that are in error according to their relevant
specification) for the purposes of ID matching.
title
Advisory information for the element, such as would be appropriate for a tooltip. On a link, this could be the title or a description of the target resource; on an image, it could be the caption or a description of the image; on a paragraph, it could be a footnote or commentary on the text; on a citation, it could be further information about the source; and so forth. The value is text.
If this attribute is omitted from an element, then it implies that the
title attribute of
the nearest ancestor with a title attribute set is also relevant to this
element. Setting the attribute overrides this, explicitly stating that
the advisory information of any ancestors is not relevant to this
element. Setting the attribute to the empty string indicates that the
element has no advisory information.
Some elements, such as link and
dfn, define additional semantics for
the title
attribute beyond the semantics described above.
lang (HTML only) and xml:lang (XML only)
The primary language for the element's contents and for any of the element's attributes that contain text. The value must be a valid RFC 3066 language code, or the empty string. RFC3066
If this attribute is omitted from an element, then it implies that the language of this element is the same as the language of the parent element. Setting the attribute to the empty string indicates that the primary language is unknown.
The lang attribute only applies to
HTML documents. Authors must not use the lang attribute in XML documents. Authors must
instead use the xml:lang attribute,
defined in XML. [XML]
To determine the language of a node, user agents must look at the
nearest ancestor element (including the element itself if the node is an
element) that has a lang or xml:lang attribute set. That specifies the
language of the node.
If both the xml:lang attribute and
the lang attribute are set, user agents
must use the xml:lang attribute, and
the lang attribute must be ignored for
the purposes of determining the element's language.
If no explicit language is given for the root element, then language information from a higher-level protocol (such as HTTP), if any, must be used as the final fallback language. In the absence of any language information, the default value is unknown (the empty string).
User agents may use the element's language to determine proper processing or rendering (e.g. in the selection of appropriate fonts or pronounciations, or for dictionary selection).
dir
The element's text directionality. The attribute, if specified, must
have either the literal value ltr or the literal value
rtl.
If the attribute has the literal value ltr, the element's
directionality is left-to-right. If the attribute has the literal value
rtl, the element's directionality is right-to-left. If the
attribute is omitted or has another value, then the directionality is
unchanged.
The processing of this attribute depends on the presentation layer. For example, CSS 2.1 defines a mapping from this attribute to the CSS 'direction' and 'unicode-bidi' properties, and defines rendering in terms of those property.
class
The element's classes. The value must be a list of zero or more words (consisting of one or more non-space characters) separated by one or more spaces.
User agents must assign all the given classes to the element, for the
purposes of class matching (e.g. for selectors in CSS or for the getElementsByClassName()
method in the DOM).
Unless defined by one of the URIs given in the profile attribute, classes are opaque
strings. Particular meanings must not be derived from undefined values
in the class attribute.
Authors should bear in mind that using the class attribute does not convey any additional
meaning to the element (unless using classes defined by a profile). There is no semantic difference
between an element with a class attribute and one
without. Authors that use classes that are not defined in a
profile should make sure, therefore,
that their documents make as much sense once all class attributes have been removed as they do
with the attributes present.
contextmenu
The element's context
menu. The value must be the ID of a menu element in the DOM. If the node that would
be obtained by the invoking the getElementById() method
using the attribute's value as the only argument is null or not a
menu element, then the element has no
assigned context menu. Otherwise, the element's assigned context menu is
the element so identified.
Event handler attributes aren't handled yet.
The following DOM interface, common to elements in the HTML namespace, provides scripts with convenient access to the content attributes listed above:
interface HTMLElement : Element { attribute DOMString id; attribute DOMString title; attribute DOMString lang; attribute DOMString dir; attribute DOMString className; NodeList getElementsByClassName(in DOMString className1 [, in DOMString className2, ...] ); };
The id attribute must
reflect the content id attribute.
The title
attribute must reflect the content
title attribute.
The lang attribute
must reflect the content lang attribute.
The dir attribute must
reflect the content dir attribute.
The className attribute must reflect the content class attribute.
should also introduce a DOMTokenString accessor for the class attribute
The getElementsByClassName()
method must return the nodes that the HTMLDocument getElementsByClassName() method
would return, excluding any elements that are not descendants of the
HTMLElement on which the method
was invoked.
html elementhead element followed by a
body element.HTMLElement.
The html element represents the root
of an HTML document.
Document metadata is represented by metadata
elements in the document's head
element.
head elementhtml
element.
title
element, optionally one base element
(HTML only), and zero or more other metadata
elements (in particular, link, meta,
style, and script).
profile
interface HTMLHeadElement : HTMLElement { attribute DOMString profile; };
The head element collects the
document's metadata.
The profile attribute must, if
specified, contain a list of zero or more URIs (or IRIs) representing
definitions of classes, metadata names, and link relations. These URIs are
opaque strings, like namespaces; user agents are not expected to determine
any useful information from the resources that they reference.
Each time a class, metadata, or link relationship name that is not
defined by this specification is found in a document, the UA must check
whether any of the URIs in the profile
attribute are known (to the UA) to define that name. The class, metadata,
or link relationship shall then be interpreted using the semantics given
by the first URI that is known to define the name. If the name is not
defined by this specification and none of the specified URIs defines the
name either, then the class, metadata, or link relationship is meaningless
and the UA must not assign special meaning to that name.
If two profiles define the same name, then the semantic is given by the
first URI specified in the profile
attribute. There is no way to use the names from both profiles in one
document.
User agents must ignore all the URIs given in the profile attribute that follow a URI that the UA
does not recognise. (Otherwise, if a name is defined in two profiles, UAs
would assign meanings to the document differently based on which profiles
they supported.)
If a profile's definition introduces new definitions over time, documents that use multiple profiles can change defined meaning over time. So as to avoid this problem, authors are encouraged to avoid using multiple profiles.
The profile
DOM attribute must reflect the
profile content attribute on getting
and setting.
title elementhead element containing no
other title elements.
HTMLElement.
The title element represents the
document's title or name. Authors should use titles that identify their
documents even when they are used out of context, for example in a user's
history or bookmarks, or in search results. The document's title is often
different from its first header, since the first header does not have to
stand alone when taken out of context.
Here are some examples of appropriate titles, contrasted with the top-level headers that might be used on those same pages.
<title>Introduction to The Mating Rituals of Bees</title>
...
<h1>Introduction</h1>
<p>This companion guide to the highly successful
<cite>Introduction to Medieval Bee-Keeping</cite> book is...
The next page might be a part of the same site. Note how the title describes the subject matter unambiguously, while the first header assumes the reader knowns what the context is and therefore won't wonder if the dances are Salsa or Waltz:
<title>Dances used during bee mating rituals</title>
...
<h1>The Dances</h1>
In HTML (as opposed to XHTML), the title element must not contain content other
than text and entities; user agents parse the element so that entities are
recognised and processed, but all other markup is interpreted as literal
text.
In XHTML, the title element must not
contain any elements.
User agents must concatenate the contents of all the text nodes and
CDATA nodes that are direct children of the title element (ignoring any other nodes such as
comments or elements), in tree order, to get the string to use as the
document's title. User agents should use the document's title when
referring to the document in their user interface.
base elementhead element, before any
elements that use relative URIs, and only if there are no other base elements anywhere in the document. Only in
HTML documents (never in XML documents).
href
interface HTMLBaseElement : HTMLElement { attribute DOMString href; };
The base element allows authors to
specify the document's base URI for the purposes of resolving relative
URIs.
The href
content attribute, if specified, must contain a URI (or IRI).
User agents must use the value of the href attribute on the first base element in the document as the document
entity's base URI for the purposes of section 5.1.1 of RFC 2396
("Establishing a Base URI": "Base URI within Document Content"). [RFC2396] Note that this base URI from RFC 2396 is
referred to by the algorithm given in XML Base, which is a normative part of this specification.
If the base URI given by this attribute is a relative URI, it must be resolved relative to the higher-level base URIs (i.e. the base URI from the encapsulating entity or the URI used to retrieve the entity) to obtain an absolute base URI.
The href content
attribute must be reflected by the DOM href attribute.
Authors must not use the base element
in XML documents. Authors should instead use the xml:base
attribute. [XMLBASE]
link elementhead element.
href
rel
media
hreflang
type
title attribute has special semantics on this
element.
interface HTMLLinkElement : HTMLElement { attribute boolean disabled; attribute DOMString href; attribute DOMString rel; attribute DOMString media; attribute DOMString hreflang; attribute DOMString type; };
The LinkStyle
interface defined in DOM2 Style must also be implemented by this
element. [DOM2STYLE]
The link element allows authors to
indicate explicit relationships between their document and other
resources.
The destination of the link is given by the href attribute, which must be a
URI (or IRI). If the href attribute is absent, then the element does
not define a link.
The type of link indicated (the relationship) is given by the value of
the rel attribute.
The allowed values and their meanings are defined
in a later section. If the rel attribute is absent, or if the value used is
not allowed according to the definitions in this specification, then the
element does not define a link.
Two categories of links can be created using the link element. Links to external resources are links to resources
that are to be used to augment the current document, and hyperlinks are links to other
documents. The link types section defines whether
a particular link type is an external resource or a hyperlink. One element
can create multiple links (of which some might be external resource links
and some might be hyperlinks). User agents should process the links on a
per-link basis, not a per-element basis.
The exact behaviour for links to external resources depends on the exact relationship, as defined for the relevant link type. Some of the attributes control whether or not the external resource is to be applied (as defined below). For external resources that are represented in the DOM (for example, style sheets), the DOM representation must be made available even if the resource is not applied. (However, user agents may opt to only fetch such resources when they are needed, instead of pro-actively downloading all the external resources that are not applied.)
Interactive user agents should provide users with a means to follow the hyperlinks
created using the link element, somewhere within their user
interface. The exact interface is not defined by this specification, but
it should include the following information (obtained from the element's
attributes, again as defined below), in some form or another (possibly
simplified), for each hyperlink created with each link element in the document:
rel attribute)
title attribute).
href attribute).
hreflang
attribute).
media attribute).
User agents may also include other information, such as the type of the
resource (as given by the type attribute).
The media
attribute says which media the resource applies to. The value must be a
valid media query. [MQ]
If the link is a hyperlink then the media attribute is
purely advisory, and describes for which media the document in question
was designed.
However, if the link is an external resource
link, then the media attribute is prescriptive. The user agent
must only apply the external resource to views while
their state match the listed media.
The default, if the media attribute is omitted, is all,
meaning that by default links apply to all media.
The hreflang attribute gives the
language of the linked resource. It is purely advisory. The value must be
a valid RFC 3066 language code. RFC3066 User
agents must not consider this attribute authoritative — upon
fetching the resource, user agents must only use language information
associated with the resource to determine its language, not metadata
included in the link to the resource.
The type
attribute gives the MIME type of the linked resource. It is purely
advisory. The value must be a valid MIME type, optionally with parameters.
[RFC2046]
For external resource links, user agents may use the type given in this attribute to decide whether or not to consider using the resource at all. If the UA does not support the given MIME type for the given link relationship, then the UA may opt not to download and apply the resource.
User agents must not consider the type attribute authoritative — upon fetching
the resource, user agents must only use the Content-Type information
associated with the resource to determine its type, not metadata included
in the link to the resource.
If the attribute is omitted, then the UA must fetch the resource to determine its type and thus determine if it supports (and can apply) that external resource.
If a document contains three style sheet links labelled as follows:
<link rel="stylesheet" href="A" type="text/css"> <link rel="stylesheet" href="B" type="text/plain"> <link rel="stylesheet" href="C">
...then a compliant UA that supported only CSS style sheets would fetch
the A and C files, and skip the B file (since text/plain is
not the MIME type for CSS style sheets). For these two files, it would
then check the actual types returned by the UA. For those that are sent
as text/css, it would apply the styles, but for those
labelled as text/plain, or any other type, it would not.
The title
attribute gives the title of the link. With one exception, it is purely
advisory. The value is text. The exception is for style sheet links, where
the title
attribute defines alternate style sheet
sets.
The title attribute on link elements differs from the global title attribute of most
other elements in that a link without a title does not inherit the title
of the parent element: it merely has no title.
Some versions of HTTP defined a Link: header, to
be processed like a series of link
elements. When processing links, those must be taken into consideration as
well. For the purposes of ordering, links defined by HTTP headers must be
assumed to come before any links in the document, in the order that they
were given in the HTTP entity header. Relative URIs in these headers must
be resolved according to the rules given in HTTP, not relative to base
URIs set by the document (e.g. using a base element or xml:base
attributes). [RFC2616] [RFC2068]
The DOM attributes href, rel, media, hreflang, and type each reflect the respective content attributes of
the same name.
The DOM attribute disabled only applies to
style sheet links. When the link element
defines a style sheet link, then the disabled attribute behaves as defined for the alternate style sheets DOM. For all
other link elements it must always
return false and must do nothing on setting.
meta elementhead element.
name
http-equiv (HTML only, optional)
content
interface HTMLMetaElement : HTMLElement { attribute DOMString content; attribute DOMString name; };
The meta element allows authors to
specify document metadata that cannot be expressed using the title, base,
link, style, and script elements. The metadata is expressed in
terms of name/value pairs: the name attribute on the meta element gives the name, and the content
attribute on the same element gives the value.
To set metadata with meta elements,
authors must first specify a profile that defines metadata names, using
the profile attribute. The value of
the name attribute
must be defined by one of the profiles, and the value of the content attribute
must conform to the syntax given by the profile.
How user agents handle metadata set in this way depends on the definitions of the profiles involved.
If a meta element has no name attribute, it does
not set document metadata. If a meta
element has no content attribute, then the value part of the
metadata name/value pair is the empty string.
The DOM attributes name and content reflect the respective content attributes of
the same name.
The meta element may also be used, in
HTML only (not in XHTML) to provide UAs with character encoding
information for the file. To do this, the meta element must be the first element in the
head element, it must have the http-equiv
attribute set to the literal value Content-Type, and must
have the content attribute set to the literal value
text/html; charset= immediately followed by the character
encoding, which must be a valid character encoding name. [IANACHARSET]
When the meta element is used in this
way, there must be no other attributes set on the element, and the
http-equiv attribute must be listed first in the source.
Other than for giving the document's character encoding in this way, the
http-equiv attribute must not be used.
We should allow those strings to be case-insensitive, and for zero-or-more spaces where we currently require just one.
In XHTML, the XML declaration should be used for inline character encoding information, if necessary.
Authors should avoid including inline character encoding information.
Character encoding information should instead be included at the transport
level (e.g. using the HTTP Content-Type header).
style elementhead element.
type attribute.
type
media
title attribute has special semantics on this
element.
interface HTMLStyleElement : HTMLElement { attribute booleandisabled; attribute DOMStringmedia; attribute DOMStringtype; };
The LinkStyle
interface defined in DOM2 Style must also be implemented by this
element. [DOM2STYLE]
The style element allows authors to
embed style information in their documents.
If the type
attribute is given, it must contain a MIME type, optionally with
parameters, that designates a styling language. [RFC2046] If the attribute is absent, the type
defaults to text/css. [RFC2138]
If the UA supports the given styling language, then the UA must use the given styles as appropriate for that language.
When examining types to determine if they support the language, user agents must not ignore unknown MIME parameters — types with unknown parameters must be assumed to be unsupported.
The media
attribute says which media the styles apply to. The value must be a valid
media query. [MQ] User agents must only apply the
styles to views while their state match the listed
media.
The default, if the media attribute is
omitted, is all, meaning that by default styles apply to all
media.
The title attribute on style elements defines alternate style sheet sets. If the
style element has no title attribute,
then it has no title; the title attribute of ancestors does not apply to
the style element.
The title attribute on style elements, like the title attribute on
link elements, differs from the global
title attribute in
that a style block without a title does
not inherit the title of the parent element: it merely has no title.
All descendant elements must be processed, according to their semantics,
before the style element itself is
evaluated. For styling languages that consist of pure text, user agents
must evaluate style elements by passing
the concatenation of the contents of all the text nodes and CDATA nodes
that are direct children of the style
element (not any other nodes such as comments or elements), in tree order,
to the style system. For XML-based styling languages, user agents must
pass all the children nodes of the style element to the style system.
This specification does not specify a style system, but CSS is expected to be supported by most Web browsers. [CSS21]
The DOM attributes media and type each reflect the respective content attributes of
the same name.
The DOM disabled attribute behaves
as defined for the alternate style sheets
DOM.
Sectioning elements are elements that divide the page into, for lack of a better word, sections. This section describes HTML's sectioning elements and elements that support them.
Some elements are scoped to their nearest ancestor
sectioning element. For example, address elements apply just to their section.
For such elements x, the elements that apply to a
sectioning element e are all the x
elements whose nearest sectioning element is e.
body elementhtml
element.
HTMLElement.
The body element represents the main
content of the document.
The body element potentially has a
heading. See the section on headings and
sections for further details.
Some DOM operations (for example, parts of the drag and drop model) are defined in terms of
"the body element". See
the definition of the document.body
DOM attribute for details.
section elementSectioning block-level element.
HTMLElement.
The section element represents a
generic document or application section. A section, in this context, is a
thematic grouping of content, typically with a header, possibly with a
footer.
Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site's home page could be split into sections for an introduction, news items, contact information.
Each section element potentially
has a heading. See the section on headings and
sections for further details.
nav elementSectioning block-level element.
HTMLElement.
The nav element represents a section of
a page that links to other pages or to parts within the page: a section
with navigation links.
When used as an inline-level content container, the element represents a paragraph.
Each nav element potentially has a
heading. See the section on headings and
sections for further details.
article elementSectioning block-level element.
HTMLElement.
The article element represents a
section of a page that consists of a composition that forms an independent
part of a document, page, or site. This could be a forum post, a magazine
or newspaper article, a Web log entry, a user-submitted comment, or any
other independent item of content.
An article element is
"independent" in that its contents could stand alone, for example in
syndication. However, the element is still associated with its ancestors;
for instance, contact information that applies to a
parent body element still covers the
article as well.
When article elements are nested,
the inner article elements represent
articles that are in principle related to the contents of the outer
article. For instance, a Web log entry on a site that accepts
user-submitted comments could represent the comments as article elements nested within the article element for the Web log entry.
Author information associated with an article element (q.v. the address element) does not apply to nested
article elements.
Each article element potentially
has a heading. See the section on headings and
sections for further details.
blockquote elementSectioning block-level element, and structured inline-level element.
cite
interface HTMLQuoteElement : HTMLElement { attribute DOMString cite; };
The HTMLQuoteElement interface is also
used by the q element.
The blockquote element
represents a section that is quoted from another source.
Content inside a blockquote must
be quoted from another source, whose URI, if it has one, should be cited
in the cite attribute.
If the cite attribute is present, it must be a URI (or
IRI). User agents should allow users to follow such citation links.
Each blockquote element
potentially has a heading. See the section on headings and sections for further details.
The cite DOM
attribute reflects the element's cite
content attribte.
The blockquote element can be
used with the ol and cite elements to mark up dialogue. This example
demonstrates this using an extract from Abbot and Costello's famous
sketch, Who's on first:
<ol>
<li> <cite>Costello</cite>
<blockquote> <p> Look, you gotta first baseman? </p> </blockquote>
<li> <cite>Abbott</cite>
<blockquote> <p> Certainly. </p> </blockquote>
<li> <cite>Costello</cite>
<blockquote> <p> Who's playing first? </p> </blockquote>
<li> <cite>Abbott</cite>
<blockquote> <p> That's right. </p> </blockquote>
<li> <cite>Costello</cite>
<blockquote> <p> When you pay off the first baseman every month, who gets the money? </p> </blockquote>
<li> <cite>Abbott</cite>
<blockquote> <p> Every dollar of it. </p> </blockquote>
</ol>
aside elementSectioning block-level element.
HTMLElement.
The aside element represents a
section of a page that consists of content that is tangentially related to
the content around the aside element,
and which could be considered separate from that content. Such sections
are often represented as sidebars in printed typography.
When used as an inline-level content container, the element represents a paragraph.
Each aside element potentially has a
heading. See the section on headings and
sections for further details.
h1, h2, h3, h4, h5, and h6
elementsHTMLElement.
These elements define headers for their sections.
The semantics and meaning of these elements are defined in the section on headings and sections.
These elements have a rank given by the number in
their name. The h1 element is said to have
the highest rank, the h6 element has the
lowest rank, and two elements with the same name have equal rank.
These elements must not be empty.
header elementheader
ancestors.
h1, h2, h3, h4, h5, or h6 element,
but no sectioning element descendants, no header element descendants, and no footer element descendants.
HTMLElement.
The header element represents the
header of a section. Headers may contain more than just the section's
heading — for example it would be reasonable for the header to
include version history information.
header elements must not contain any
header elements, footer elements, or any sectioning elements
(such as section) as descendants.
header elements must have at least
one h1, h2, h3, h4, h5, or h6 element as a descendant.
For the purposes of document summaries, outlines, and the like, header elements are equivalent to the highest
ranked h1-h6 element
descendant (the first such element if there are multiple elements with
that rank).
Other heading elements indicate subheadings or subtitles.
Here are some examples of valid headers. In each case, the emphasised text represents the text that would be used as the header in an application extracting header data and ignoring subheadings.
<header> <h1>The reality dysfunction</h1> <h2>Space is not the only void</h2> </header>
<header> <p>Welcome to...</p> <h1>Voidwars!</h1> </header>
<header> <h1>Scalable Vector Graphics (SVG) 1.2</h1> <h2>W3C Working Draft 27 October 2004</h2> <dl> <dt>This version:</dt> <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20041027/">http://www.w3.org/TR/2004/WD-SVG12-20041027/</a></dd> <dt>Previous version:</dt> <dd><a href="http://www.w3.org/TR/2004/WD-SVG12-20040510/">http://www.w3.org/TR/2004/WD-SVG12-20040510/</a></dd> <dt>Latest version of SVG 1.2:</dt> <dd><a href="http://www.w3.org/TR/SVG12/">http://www.w3.org/TR/SVG12/</a></dd> <dt>Latest SVG Recommendation:</dt> <dd><a href="http://www.w3.org/TR/SVG/">http://www.w3.org/TR/SVG/</a></dd> <dt>Editor:</dt> <dd>Dean Jackson, W3C, <a href="mailto:dean@w3.org">dean@w3.org</a>></dd> <dt>Authors:</dt> <dd>See <a href="#authors">Author List</a></dd> </dl> <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notic ... </header>
The section on headings and
sections defines how header
elements are assigned to individual sections.
The rank of a header element is the same as for an h1 element (the highest rank).
footer elementh1,
h2, h3,
h4, h5,
h6, header, or footer elements as descendants, and with no
sectioning
elements as descendants; or, inline-level content (but not both).
HTMLElement.
The footer element represents the
footer for the section it applies to. A
footer typically contains information about its section such as who wrote
it, links to related documents, copyright data, and the like.
footer elements must not contain any
footer, header, h1,
h2, h3,
h4, h5, or
h6 elements, or any of the sectioning
elements (such as section), as
descendants.
When used as an inline-level content container, the element represents a paragraph.
Contact information for the section given in a footer should be marked up using the address element.
address elementHTMLElement.
The address element represents a
paragraph of contact information for
the section it applies to.
For example, a page at the W3C Web site related to HTML might include the following contact information:
<ADDRESS> <A href="../People/Raggett/">Dave Raggett</A>, <A href="../People/Arnaud/">Arnaud Le Hors</A>, contact persons for the <A href="Activity">W3C HTML Activity</A> </ADDRESS>
The address element must not be
used to represent arbitrary addresses (e.g. postal addresses), unless
those addresses are contact information for the section. (The p element is the appropriate element for marking up
such addresses.)
The address element must not
contain information other than contact information.
For example, the following is non-conforming use of the address element:
<ADDRESS>Last Modified: 1999/12/24 23:37:50</ADDRESS>
Typically, the address element
would be included with other information in a footer element.
To determine the contact information for a sectioning element (such as
the body element, which would give the
contact information for the page), UAs must collect all the address elements that apply to that sectioning element and its
ancestor sectioning elements. The contact information is the collection of
all the information given by those elements.
Contact information for one sectioning element, e.g. a
aside element, does not apply to its
ancestor elements, e.g. the page's body.
The h1-h6 elements and the header element are headings.
The first heading in a sectioning element gives the header for that section. Subsequent headers of equal or higher rank start new (implied) sections, headers of lower rank start subsections that are part of the previous one.
Sectioning elements other than blockquote are always considered
subsections of their nearest ancestor sectioning element, regardless of
what implied sections other headings may have created. However, blockquote elements are associated
with implied sections. Effectively, blockquote elements act like sections on
the inside, and act opaquely on the outside.
For the following fragment:
<body> <h1>Foo</h1> <h2>Bar</h2> <blockquote> <h3>Bla</h3> </blockquote> <p>Baz</p> <h2>Quux</h2> <section> <h3>Thud</h3> </section> <p>Grunt</p> </body>
...the structure would be:
body
section)
blockquote section)
section section)
Notice how the blockquote nests
inside an implicit section while the section does not (and in fact, ends the
earlier implicit section so that a later paragraph is back at the top
level).
Sections may contain headers of any rank, but authors are strongly encouraged to
either use only h1 elements, or to use
elements of the appropriate rank for the
section's nesting level.
Authors are also encouraged to explictly wrap sections in sectioning elements, instead of relying on the implicit sections generated by having multiple heading in one sectioning element.
For example, the following is correct:
<body> <h4>Apples</h4> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <h6>Sweet</h6> <p>Red apples are sweeter than green ones.</p> <h1>Colour</h1> <p>Apples come in various colours.</p> </section> </body>
However, the same document would be more clearly expressed as:
<body> <h1>Apples</h1> <p>Apples are fruit.</p> <section> <h2>Taste</h2> <p>They taste lovely.</p> <section> <h3>Sweet</h3> <p>Red apples are sweeter than green ones.</p> </section> </section> <section> <h2>Colour</h2> <p>Apples come in various colours.</p> </section> </body>
Both of the documents above are semantically identical and would produce the same outline in compliant user agents.
HTML documents can be viewed as a tree of sections, which defines how each element in the tree is semantically related to the others, in terms of the overall section structure. This tree is related to the document tree, but there is not a one-to-one relationship between elements in the DOM and the document's sections.
The tree of sections should be used when generating document outlines, for example when generating tables of contents.
To derive the tree of sections from the document tree, a hypothetical
tree is used, consisting of a view of the document tree containing only
the h1-h6
and header elements, and the
sectioning elements other than blockquote. Descendants of h1-h6, header, and blockquote elements must be removed from
this view.
The hypothetical tree must be rooted at the root element or at a sectioning element.
In particular, while the sections inside blockquotes do not contribute to the
document's tree of sections, blockquotes can have outlines of their own.
UAs must take this hypothetical tree (which will become the outline) and
mutate it by walking it depth first in tree order and, for each h1-h6 or header element that is not the first element of
its parent sectioning element, inserting a new sectioning element, as
follows:
header
element, or if it is an h1-h6 node of rank
equal to or higher than the first element in the parent sectioning
element (assuming that is also an h1-h6 node), or if
the first element of the parent sectioning element is a sectioning
element:
header element, or h1-h6 of equal or
higher rank, whichever comes first, into
the new sectioning element, then insert the new sectioning element where
the current header was.
The outline is then the resulting hypothetical tree. The ranks of the headers become irrelevant at this point: each sectioning element in the hypothetical tree contains either no or one heading element child. If there is one, then it gives the section's heading, of there isn't, the section has no heading.
Sections are nested as in the hypothetical tree. If a sectioning element is a child of another, that means it is a subsection of that other section.
When creating an interactive table of contents, entries should jump the user to the relevant section element, if it was a real element in the original document, or to the heading, if the section element was one of those created during the above process.
Selecting the first section of the document therefore
always takes the user to the top of the document, regardless of where the
first header in the body is to be found.
The hypothetical tree (before mutations) could be generated by creating
a TreeWalker with the following NodeFilter
(described here as an anonymous ECMAScript function). [DOMTR] [ECMA262]
function (n) {
// This implementation only knows about HTML elements.
// An implementation that supports other languages might be
// different.
// Reject anything that isn't an element.
if (n.nodeType != Node.ELEMENT_NODE)
return NodeFilter.FILTER_REJECT;
// Skip any descendants of headings.
if (n.parentNode && n.parentNode.namespaceURI == 'http://www.w3.org/1999/xhtml') &&
(n.parentNode.localName == 'h1' || n.parentNode.localName == 'h2' ||
n.parentNode.localName == 'h3' || n.parentNode.localName == 'h4' ||
n.parentNode.localName == 'h5' || n.parentNode.localName == 'h6' ||
n.parentNode.localName == 'header')
return NodeFilter.FILTER_REJECT;
// Skip any blockquotes.
if (n.namespaceURI == 'http://www.w3.org/1999/xhtml') &&
(n.localName == 'blockquote'))
return NodeFilter.FILTER_REJECT;
// Accept HTML elements in the list given in the prose above.
if ((n.namespaceURI == 'http://www.w3.org/1999/xhtml') &&
(n.localName == 'body' || /*n.localName == 'blockquote' ||*/
n.localName == 'section' || n.localName == 'nav' ||
n.localName == 'article' || n.localName == 'aside' ||
n.localName == 'h1' || n.localName == 'h2' ||
n.localName == 'h3' || n.localName == 'h4' ||
n.localName == 'h5' || n.localName == 'h6' ||
n.localName == 'header'))
return NodeFilter.FILTER_ACCEPT;
// Skip the rest.
return NodeFilter.FILTER_SKIP;
}
Given a particular node, user agents must use the following algorithm, in the given order, to determine which heading and section the node is most closely associated with. The processing of this algorithm must stop as soon as the associated section and heading are established (even if they are established to be nothing).
header element, then the associated heading is
the most distant such ancestor. The associated section is that header's associated section (i.e. repeat this
algorithm for that header).
h1-h6 element,
then the associated heading is the most distant such ancestor. The
associated section is that heading's section (i.e. repeat this algorithm
for that heading element).
h1-h6 element or a header element, then the associated heading is
the element itself. The UA must then generate the hypothetical section tree described in the previous
section, rooted at the nearest section ancestor (or the root element if there is no such
ancestor). If the parent of the heading in that hypothetical tree is an
element in the real document tree, then that element is the associated
section. Otherwise, there is no associated section element.
h1-h6 element or a header element, then that element is the
associated heading. Otherwise, there is no associated heading element.
footer or
address element, then the associated
section is the nearest ancestor sectioning element, if there is one. The
node's associated heading is the same as that sectioning element's
associated heading (i.e. repeat this algorithm for that sectioning
element). If there is no ancestor sectioning element, the element has no
associated section nor an associated heading.
h1-h6 elements, header elements, the node itself, and
sectioning elements other than blockquote elements. (Descendants of any
of the nodes in this view can be ignored, as can any node later in the
tree than the node in question, as the algorithm below merely walks
backwards up this view.)
h1 or header
element, then return that element as the answer.
h2-h6 element,
and heading candidates are not being searched for, then return that
element as the answer.
h2-h6 element,
and either c is still null, or c is a heading of lower rank than this one, then set c to be this element, and continue going backwards
through the previous siblings.
h1-h6 element or a
header element, then the associated
heading is that element and the associated section is that heading
element's associated section (i.e. repeat this algorithm for that
heading).
Not all nodes have an associated header or section. For example, if a section is implied, as when multiple headers are found in one sectioning element, then a node in that section has an anonymous associated section (its section is not represented by a real element), and the algorithm above does not associate that node with any particular sectioning element.
For the following fragment:
<body> <h1>X</h1> <h2>X</h2> <blockquote> <h3>X</h3> </blockquote> <p id="a">X</p> <h4>Text Node A</h4> <section> <h5>X</h5> </section> <p>Text Node B</p> </body>
The associations are as follows (not all associations are shown):
| Node | Associated heading | Associated section |
|---|---|---|
<body>
| <h1>
| <body>
|
<h1>
| <h1>
| <body>
|
<h2>
| <h2>
| None. |
<blockquote>
| <h2>
| None. |
<h3>
| <h3>
| <blockquote>
|
<p id="a">
| <h2>
| None. |
Text Node A
| <h4>
| None. |
Text Node B
| <h1>
| <body>
|
A paragraph is typically a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping. For instance, an address is also a paragraph, as is a part of a form, a byline, or a stanza in a poem.
Paragraphs can be represented by several elements. The address element always represents a paragraph
of contact information for its section, the aside, nav,
footer, li, and dd elements
represent paragraphs with various specific semantics when they are used as inline-level
content containers, and the p
element represents all the other kinds of paragraphs, for which there are
no dedicated elements.
p elementHTMLElement.
The p element represents a paragraph.
p elements can contain a mixture of
strictly inline-level content, such
as text, images, hyperlinks, etc, and structured inline-level elements, such as
lists, tables, and block quotes. p elements
must not be empty.
The following examples are conforming HTML fragments:
<p>The little kitten gently seated himself on a piece of carpet. Later in his life, this would be referred to as the time the cat sat on the mat.</p>
<fieldset> <legend>Personal information</legend> <p> <label>Name: <input name="n"></label> <label><input name="anon" type="checkbox"> Hide from other users</label> </p> <p><label>Address: <textarea name="a"></textarea></label></p> </fieldset>
<p>There was once an example from Femley,<br> Whose markup was of dubious quality.<br> The validator complained,<br> So the author was pained,<br> To move the error from the markup to the rhyming.</p>
The p element should not be used when a
more specific element is more appropriate.
The following example is technically correct:
<section> <!-- ... --> <p>Last modified: 2001-04-23</p> <p>Author: fred@example.com</p> </section>
However, it would be better marked-up as:
<section> <!-- ... --> <footer>Last modified: 2001-04-23</footer> <address>Author: fred@example.com</address> </section>
Or:
<section> <!-- ... --> <footer> <p>Last modified: 2001-04-23</p> <address>Author: fred@example.com</address> </footer> </section>
hr element [TBW]thematic separator. break. transition. hinge realignment. reconstruction, refinement, remodeling, reversal, revision, revolution. Maybe an 'html respite' or a 'hypertext rest'? .
pre elementBlock-level element, and structured inline-level element.
HTMLElement.
The pre element represents a block of
preformatted text, in which structure is represented by typographic
conventions rather than by elements.
Some examples of cases where the pre
element could be used:
If, ignoring text nodes consisting only of white space, the only child
of a pre is a code element, then the pre element represents a block of computer code.
If, ignoring text nodes consisting only of white space, the only child
of a pre is a samp element, then the pre element represents a block of computer output.
ol elementBlock-level element, and structured inline-level element.
li elements.
start
interface HTMLOListElement : HTMLElement { attribute long start; };
The ol element represents an ordered
list of items (which are represented by li
elements).
The start attribute, if present, must
have a value that consists of an optional U+002D HYPHEN-MINUS followed by
one or more digits (U+0030 to U+0039) expressing a base ten integer giving
the ordinal value of the first list item.
If the start attribute is present,
user agents must convert the value to a numeric
type, truncating any fractional part, in order to determine the
attribute's value. The default value, used if the attribute is missing or
if the value cannot be converted to a number according to the referenced
algorithm, is 1.
The items of the list are the li element
child nodes of the ol element, in tree
order.
The first item in the list has the ordinal value given by the ol element's start attribute (unless it is further overridden
by that li element's value attribute).
Each subsequent item in the list has the ordinal value given by its
value attribute, if it has one, or, if
it doesn't, the ordinal value of the previous item, plus one.
The start DOM
attribute must reflect the value of
the start content attribute.
ul elementBlock-level element, and structured inline-level element.
li elements.
HTMLElement.
The ul element represents an unordered
list of items (which are represented by li
elements).
The items of the list are the li element
child nodes of the ul element.
li elementol elements.
ul elements.
menu elements.
ol
or ul element and the grandchild of an
element that is being used as an inline-level content
container, or, when the element is a child of a menu element: inline-level content.
ol
element: value
ol element: None.
interface HTMLLIElement : HTMLElement { attribute long value; };
The li element represents a list item.
If its parent element is an ol, ul, or menu
element, then the element is an item of the parent element's list, as
defined for those elements. Otherwise, the list item has no defined
list-related relationship to any other li
element.
When the list item is the child of an ol
or ul element, the content model of the
item depends on the way that parent element was used. If it was used as
structured inline content (i.e. if that element's parent was
used as an
inline-level content container), then the li element must only contain inline-level content. Otherwise, the
element may be used either for inline content or block-level elements.
When the list item is the child of a menu element, the li element must contain only inline-level content.
When the list item is not the child of an ol, ul, or menu element, e.g. because it is an orphaned node
not in the document, it may contain either for inline content or block-level elements.
When used as an inline-level content container, the list item represents a single paragraph.
The value attribute, if present,
must have a value that consists of an optional U+002D HYPHEN-MINUS
followed by one or more digits (U+0030 to U+0039) expressing a base ten
integer giving the ordinal value of the first list item.
If the value attribute is present,
user agents must convert the value to a numeric
type, truncating any fractional part, in order to determine the
attribute's value. If the attribute's value cannot be converted to a
number, it is treated as if the attribute was absent. The attribute has no
default value.
The value attribute is processed
relative to the element's parent ol
element, if there is one. If there is not, the attribute has no effect.
The value DOM
attribute must reflect the value of
the value content attribute.
dl elementBlock-level element, and structured inline-level element.
dt elements followed by one or mode dd elements.
HTMLElement.
The dl element introduces an unordered
association list consisting of zero or more name-value groups. Each group
must consist of one or more names (dt
elements) followed by one or more values (dd elements).
Name-value groups may be terms and definitions, metadata topics and values, or any other groups of name-value data.
The following are all conforming HTML fragments.
In the following example, one entry ("Authors") is linked to two values ("John" and "Luke").
<dl> <dt> Authors <dd> John <dd> Luke <dt> Editor <dd> Frank </dl>
In the following example, one definition is linked to two terms.
<dl> <dt lang="en-US"> <dfn>color</dfn> </dt> <dt lang="en-GB"> <dfn>colour</dfn> </dt> <dd> A sensation which (in humans) derives from the ability of the fine structure of the eye to distinguish three differently filtered analyses of a view. </dd> </dl>
The following example illustrates the use of the dl element to mark up metadata of sorts. At the
end of the example, one group has two metadata labels ("Authors" and
"Editors") and two values ("Robert Rothman" and "Daniel Jackson").
<dl> <dt> Last modified time </dt> <dd> 2004-12-23T23:33Z </dd> <dt> Recommended update interval </dt> <dd> 60s </dd> <dt> Authors </dt> <dt> Editors </dt> <dd> Robert Rothman </dd> <dd> Daniel Jackson </dd> </dl>
If a dl element is empty, it contains no
groups.
If a dl element contains non-whitespace
text nodes, or elements other than dt and
dd, then those elements or text nodes do
not form part of any groups in that dl,
and the document is non-conforming.
If a dl element contains only dt elements, then it consists of one group with
names but no values, and the document is non-conforming.
If a dl element contains only dd elements, then it consists of one group with
values but no names, and the document is non-conforming.
The dl element is
inappropriate for marking up dialogue, since dialogue is ordered (each
speaker/line pair comes after the next). For an example of how to mark up
dialogue, see the blockquote
element.
dt elementdd elements inside dl elements.
HTMLElement.
The dt element represents the term, or
name, part of a name-value group in a dl
element.
The dt element itself does
not indicate that its contents are a term being defined, but this can be
indicated using the dfn element.
dd elementdt elements inside dl elements.
dl
element and the grandchild of an element that is being used as an inline-level content
container: inline-level
content.
HTMLElement.
The dd element represents the
definition, or value, part of a name-value group in a dl element.
The content model of a dd element
depends on the way its parent element is being used. If the parent element
is a dl element that is being used as
structured inline content (i.e. if the dl
element's parent element is being used as an inline-level content
container), then the dd element must only
contain inline-level content.
Otherwise, the element may be used either for inline content or block-level elements.
a elementInteractive, strictly inline-level content.
href
rel
media
hreflang
type
ping
interface HTMLAnchorElement : HTMLElement { attribute DOMString href; attribute DOMString rel; attribute DOMString media; attribute DOMString hreflang; attribute DOMString type; attribute DOMString ping; };
The Command
interface must also be implemented by this element.
If the a element has an href attribute, then it represents
a hyperlink.
If the a element has no href attribute, then the
element is a placeholder for where a link might otherwise have been
placed, if it had been relevant.
If a site uses a consistent navigation toolbar on every page, then the
link that would normally link to the page itself could be marked up using
an a element:
<nav> <ul> <li> <a href="/">Home</a> </li> <li> <a href="/news">News</a> </li> <li> <a>Examples</a> </li> <li> <a href="/legal">Legal</a> </li> </ul> </nav>
The href
attribute, if present, must have a value that is a URI (or IRI).
The relationship between the document containing the hyperlink and the
destination resource indicated by the hyperlink is given by the value of
the rel attribute.
The allowed values and their meanings are defined
in a later section. The rel attribute has no default value. If the
attribute is omitted or if none of the values in the attribute are
recognised by the UA, then the document has no particular relationship
with the destination resource other than there being a hyperlink between
the two.
Interactive user agents should allow users to follow hyperlinks created
using the a element. The rel, media, hreflang, and
type attributes may
be used to indicate to the user the likely nature of the target resource.
The media
attribute describes for which media the target document was designed. It
is purely advisory. The value must be a valid media query. [MQ] The default, if the media attribute is omitted or has an invalid
value, is all.
The hreflang attribute, if present,
gives the language of the linked resource. It is purely advisory. The
value must be a valid RFC 3066 language code. RFC3066 User agents must not consider this
attribute authoritative — upon fetching the resource, user agents
must only use language information associated with the resource to
determine its language, not metadata included in the link to the resource.
The type
attribute, if present, gives the MIME type of the linked resource. It is
purely advisory. The value must be a valid MIME type, optionally with
parameters. [RFC2046] User agents must not
consider the type
attribute authoritative — upon fetching the resource, user agents
must only use the Content-Type information associated with the resource to
determine its type, not metadata included in the link to the resource.
The ping
attribute, if present, gives the URIs of the resources that are interested
in being notified if the user follows the hyperlink. The value must be a
space separated list of one or more URIs.
If the element has an href attribute and a ping attribute and the user follows the hyperlink,
the user agent should take the ping attribute's value, strip leading and trailing
spaces (U+0020), split the value on sequences of spaces, treat each
resulting part as a URI (resolving relative URIs according to element's
base URI) and then send a request to each of the resulting URIs. This may
be done in parallel with the primary request, and is independent of the
result of that request.
User agents should allow the user to adjust this behaviour, for example
in conjunction with a setting that disables the sending of HTTP Referrer
headers. Based on the user's preferences, UAs may either ignore the ping attribute altogether,
or selectively ignore URIs in the list (e.g. ignoring any third-party
URIs).
For URIs that are HTTP URIs, the requests must be performed using the POST method (with an empty entity body in the request). User agents must ignore any entity bodies returned in the responses, but must, unless otherwise specified by the user, honour the HTTP headers — in particular, HTTP cookie headers. [RFC2965]
To save bandwidth, implementors might wish to consider
omitting optional headers such as Accept from these requests.
When the ping
attribute is present, user agents should clearly indicate to the user that
following the hyperlink will also cause secondary requests to be sent in
the background, possibly including listing the actual target URIs.
The ping attribute
is redundant with pre-existing technologies like HTTP redirects and
JavaScript in allowing Web pages to track which off-site links are most
popular or allowing advertisers to track click-through rates.
However, the ping
attribute provides these advantages to the user over those alternatives:
Thus, while it is possible to track users without this feature, authors
are encouraged to use the ping attribute so that the user agent can improve
the user experience.
The a element must not be empty.
The DOM attributes href, rel, media, hreflang, type, and ping each reflect the respective content attributes of
the same name.
q elementStrictly inline-level content.
cite
q element uses the HTMLQuoteElement interface.
The q element represents a part of a
paragraph quoted from another source.
Content inside a q element must be quoted
from another source, whose URI, if it has one, should be cited in the cite attribute.
If the cite
attribute is present, it must be a URI (or IRI). User agents should allow
users to follow such citation links.
cite elementStrictly inline-level content.
HTMLElement.The cite element represents a
citation: the source, or reference, for a quote or statement made in the
document.
A citation is not a quote (for which the
q element is appropriate).
This is incorrect usage:
<p><cite>This is wrong!</cite>, said Ian.</p>
This is the correct way to do it:
<p><q>This is correct!</q>, said <cite>Ian</cite>.</p>
This is also wrong, because the title and the name are not references or citations:
<p>My favourite book is <cite>The Reality Dysfunction</cite> by <cite>Peter F. Hamilton</cite>.</p>
em elementStrictly inline-level content.
HTMLElement.
The em element represents stress
emphasis of its contents.
The level of emphasis that a particlar piece of content has is given by
its number of ancestor em elements.
The placement of emphasis changes the meaning of the sentence. The element thus forms an integral part of the content. The precise way in which emphasis is used in this way depends on the language.
These examples show how changing the emphasis changes the meaning. First, a general statement of fact, with no emphasis:
<p>Cats are cute animals.</p>
By emphasising the first word, the statement implies that the kind of animal under discussion is in question (maybe someone is asserting that dogs are cute):
<p><em>Cats</em> are cute animals.</p>
Moving the emphasis to the verb, one highlights that the truth of the entire sentence is in question (maybe someone is saying cats are not cute):
<p>Cats <em>are</em> cute animals.</p>
By moving it to the adjective, the exact nature of the the cats is reasserted (maybe someone suggested cats were mean animals):
<p>Cats are <em>cute</em> animals.</p>
Similarly, if someone asserted that cats were vegetables, someone correcting this might emphasise the last word:
<p>Cats are cute <em>animals</em>.</p>
By emphasising the entire sentence, it becomes clear that the speaker is fighting hard to get the point across. This kind of emphasis also typically affects the punctuation, hence the exclamation mark here.
<p><em>Cats are cute animals!</em></p>
Anger mixed with emphasising the cuteness could lead to markup such as:
<p><em>Cats are <em>cute</em> animals!</em></p>
strong elementStrictly inline-level content.
HTMLElement.
The strong element represents strong
importance for its contents.
The relative level of importance of a piece of content is given by its
number of ancestor strong elements;
each strong element increases the
importance of its contents.
Changing the importance of a piece of text with the strong element does not change the meaning of
the sentence.
Here is an example of a warning notice in a game, with the various parts marked up according to how important they are:
<p><strong>Warning.</strong> This dungeon is dangerous. <strong>Avoid the ducks.</strong> Take any gold you find. <strong><strong>Do not take any of the diamonds</strong>, they are explosive and <strong>will destroy anything within ten meters.</strong></strong> You have been warned.</p>
small elementStrictly inline-level content.
HTMLElement.
The small element represents small
print (part of a document often describing legal restrictions, such as
copyrights or other disadvantages), or other side comments.
The small element does
not "de-emphasise" or lower the importance of text emphasised by the
em element or marked as important with the
strong element.
In this example the footer contains contact information and a copyright.
<footer> <address> For more details, contact <a href="mailto:js@example.com">John Smith</a>. </address> <p><small>© copyright 2038 Example Corp.</small></p> </footer>
In this second example, the small
element is used for a side comment.
<p>Example Corp today announced record profits for the second quarter <small>(Full Disclosure: Foo News is a subsidiary of Example Corp)</small>, leading to speculation about a third quarter merger with Demo Group.</p>
In this last example, the small
element is marked as being important small print.
<p><strong><small>Continued use of this service will result in a kiss.</small></strong></p>
m elementStrictly inline-level content.
HTMLElement.
The m element represents a run of text
marked or highlighted.
Should we just repurpose u or
b for this semantic instead? What would they stand for?
In the following snippet, a paragraph of text refers to a specific part of a code fragment.
<p>The highlighted part below is where the error lies:</p> <pre><code>var i: Integer; begin i := <m>1.1</m>; end.</code></pre>
Another example of the m element is
highlighting parts of a document that are matching some search string. If
someone looked at a document, and the server knew that the user was
searching for the word "kitten", then the server might return the
document with one paragraph modified as follows:
<p>I also have some <m>kitten</m>s who are visiting me these days. They're really cute. I think they like my garden!</p>
dfn elementStrictly inline-level content.
dfn elements.
dfn
elements.
title attribute has special semantics on this
element.
HTMLElement.
The dfn element represents the defining
instance of a term. The paragraph,
definition list group, or section that
contains the dfn element contains the
definition for the term given by the contents of the dfn element.
dfn elements must not be nested.
Defining term: If the dfn element has a title attribute, then the exact
value of that attribute is the term being defined. Otherwise, if it
contains exactly one element child node and no child text nodes, and that
child element is an abbr element with a
title
attribute, then the exact value of that attribute is the term
being defined. Otherwise, it is the exact textContent of the dfn element that gives the term being defined.
If the title
attribute of the dfn element is present,
then it must only contain the term being defined.
There must only be one dfn element per
document for each term defined (i.e. there must not be any duplicate terms).
The title attribute of ancestor elements does not
affect dfn elements.
The dfn element enables automatic
cross-references. Specifically, any span, abbr,
code, var, samp, or
i element that has a non-empty title attribute whose
value exactly equals the term of a dfn
element in the same document, or which has no title attribute but whose textContent exactly equals the term of a dfn element in the document, and that has no
interactive elements or dfn elements either as ancestors or descendants,
and has no other elements as ancestors that are themselves matching these
conditions, should be presented in such a way that the user can jump from
the element to the first dfn element
giving the defining instance of that term.
In the following fragment, the term "GDO" is first defined in the first
paragraph, then used in the second. A compliant UA could provide a link
from the abbr element in the second
paragraph to the dfn element in the
first.
<p>The <dfn><abbr title="Garage Door Opener">GDO</abbr></dfn> is a device that allows off-world teams to open the iris.</p> <!-- ... later in the document: --> <p>Teal'c activated his <abbr title="Garage Door Opener">GDO</abbr> and so Hammond ordered the iris to be opened.</p>
abbr elementStrictly inline-level content.
title attribute has special semantics on this
element.
HTMLElement.
The abbr element represents an
abbreviation or acronym. The title attribute should be used
to provide an expansion of the abbreviation. If present, the attribute
must only contain an expansion of the abbreviation.
The paragraph below contains an abbreviation marked up with the
abbr element.
<p>The <abbr title="Web Hypertext Application Technology Working Group">WHATWG</abbr> is a loose unofficial collaboration of Web browser manufacturers and interested parties who wish to develop new technologies designed to allow authors to write and deploy Applications over the World Wide Web.</p>
The title
attribute may be omitted if there is a dfn element in the document whose defining term is the abbreviation (the
textContent of the abbr element).
In the example below, the word "Zat" is used as an abbreviation in the
second paragraph. The abbreviation is defined in the first, so the
explanatory title attribute has been omitted. Because of
the way dfn elements are defined, the
second abbr element in this example
would be connected (in some UA-specific way) to the first.
<p>The <dfn><abbr>Zat</abbr></dfn>, short for Zat'ni'catel, is a weapon.</p> <p>Jack used a <abbr>Zat</abbr> to make the boxes of evidence disappear.</p>
i elementStrictly inline-level content.
title attribute has special semantics on this
element when used with the dfn element.
HTMLElement.
The i element represents an instance of
the use of a term, such as a taxonomic designation, technical term, an
idiomatic phrase from another language, or similar.
Terms in languages different from the main text should be annotated with
lang attributes (xml:lang in XML).
The examples below show uses of the i
element:
<p>The <i>felis silvestris catus</i> is cute.</p> <p>The <i>block-level elements</i> are defined above.</p> <p>There is a certain <i lang="fr">je ne sais quoi</i> in the air.</p>
The i element is not
appropriate for marking up names (e.g. of people, or of ships).
actually maybe we shouldn't be stealing i's "semantics", it'll be confusing especially if we
still let WYSYWIG authoring tools use it to mean italics...
t element [WIP]Strictly inline-level content.
datetime
HTMLElement.
The t element represents a date and/or a
time.
...
...
meter elementStrictly inline-level content.
value
min
low
high
max
optimum
interface HTMLMeterElement : HTMLElement { attribute long value; attribute long min; attribute long max; attribute long low; attribute long high; attribute long optimum; };
The meter element represents a scalar
measurement within a known range, or a fractional value; for example disk
usage, the relevance of a query result, or the fraction of a voting
population to have selected a particular candidate.
This is also known as a gauge.
The meter element should
not be used to indicate progress (as in a progress bar). For that role,
HTML provides a separate progress
element.
There are six attributes that determine the semantics of the gauge represented by the element.
The min
attribute specifies the lower bound of the range, and the max attribute specifies the
upper bound. The value attribute specifies the
value to have the gauge indicate as the "measured" value.
The other three attributes can be used to segment the gauge's range into
"low", "medium", and "high" parts, and to indicate which part of the gauge
is the "optimum" part. The low attribute specifies the
range that is considered to be the "low" part, and the high attribute specifies the
range that is considered to be the "high" part. The optimum attribute gives the
position that is "optimum"; if that is higher than the "high" value then
this indicates that the higher the value, the better; if it's lower than
the "low" mark then it indicates that lower values are better, and
naturally if it is in between then it indicates that neither high nor low
values are good.
Authoring requirements: The recommended way of giving the value is to include it as contents of the element, either as two numbers (the higher number represents the maximum, the other number the current value), or as a percentage or similar (using one of the characters such as "%"), or as a fraction.
The value,
min, low, high, max, and optimum
attributes are all optional. When present, they must have values that are
valid floating
point numbers.
The following examples all represent a measurement of three quarters (of the maximum of whatever is being measured):
<meter>75%</meter> <meter>750‰</meter> <meter>3/4</meter> <meter>6 blocks used (out of 8 total)</meter> <meter>max: 100; current: 75</meter> <meter><object data="graph75.png">0.75</object></meter> <meter min="0" max="100" value="75"></meter>
User agent requirements: User agents must parse the
min, max, value, low, high, and optimum
attributes using the rules for parsing floating
point number values.
If the value
attribute has been omitted, the user agent must also process the textContent of the element according to
the steps for finding one or two numbers in a
string. These steps will return nothing, one number, one number
with a denominator punctuation character, or two numbers.
User agents must then use all these numbers to obtain values for six points on the gauge, as follows. (The order in which these are evaluated is important, as some of the values refer to earlier ones.)
If the min
attribute is specified and a value could be parsed out of it, then the
minimum value is that value. Otherwise, the minimum value is zero.
If the max
attribute is specified and a value could be parsed out of it, the
maximum value is that value.
Otherwise, if the max attribute is specified but no value could be
parsed out of it, or if it was not specified, but either or both of the
min or value attributes
were specified, then the maximum value is 1.
Otherwise, none of the max, min, and value attributes were specified. If the result
of processing the textContent
of the element was either nothing or just one number with no denominator
punctuation character, then the maximum value is 1; if the result was
one number but it had an associated denominator punctuation character,
then the maximum value is the value associated
with that denominator punctuation character; and finally, if
there were two numbers parsed out of the textContent, then the maximum is the
higher of those two numbers.
If the above machinations result in a maximum value less than the minimum value, then the maximum value is actually the same as the minimum value.
If the value attribute is specified and a value could
be parsed out of it, then that value is the actual value.
If the value attribute is not specified but the max attribute
is specified and the result of processing the textContent of the element was one
number with no associated denominator punctuation character, then that
number is the actual value.
If neither of the value and max attributes are specified, then, if the result
of processing the textContent
of the element was one number (with or without an associated denominator
punctuation character), then that is the actual value, and if the result
of processing the textContent
of the element was two numbers, then the actual value is the lower of
the two numbers found.
Otherwise, if none of the above apply, the actual value is zero.
If the above procedure results in an actual value less than the minimum value, then the actual value is actually the same as the minimum value.
If, on the other hand, the result is an actual value greater than the maximum value, then the actual value is the maximum value.
If the low
attribute is specified and a value could be parsed out of it, then the
low boundary is that value. Otherwise, the low boundary is the same as
the minimum value.
If the above results in a low boundary that is less than the minimum value, the low boundary is the minimum value.
If the high
attribute is specified and a value could be parsed out of it, then the
high boundary is that value. Otherwise, the high boundary is the same as
the maximum value.
If the above results in a high boundary that is higher than the maximum value, the high boundary is the maximum value.
If the optimum attribute is specified and a value
could be parsed out of it, then the optimum point is that value.
Otherwise, the optimum point is the midpoint between the minimum value
and the maximum value.
If the optimum point is then less than the minimum value, then the optimum point is actually the same as the minimum value. Similarly, if the optimum point is greater than the maximum value, then it is actually the maximum value instead.
All of which should result in the following inequalities all being true:
UA requirements for regions of the gauge: If the optimum point is equal to the low boundary or the high boundary, or anywhere in between them, then the region between the low and high boundaries of the gauge must be treated as the optimum region, and the low and high parts, if any, must be treated as suboptimal. Otherwise, if the optimum point is less than the low boundary, then the region between the minimum value and the low boundary must be treated as the optimum region, the region between the low boundary and the high boundary must be treated as a suboptimal region, and the region between the high boundary and the maximum value must be treated as an even less good region. Finally, if the optimum point is higher than the high boundary, then the situation is reversed; the region between the high boundary and the maximum value must be treated as the optimum region, the region between the high boundary and the low boundary must be treated as a suboptimal region, and the remaining region between the low boundary and the minimum value must be treated as an even less good region.
UA requirements for showing the gauge: When
representing a meter element to the
user, the UA should indicate the relative position of the actual value to
the minimum and maximum values, and the relationship between the actual
value and the three regions of the gauge.
The following markup:
<h3>Suggested groups</h3>
<menu type="toolbar">
<a href="?cmd=hsg" onclick="hideSuggestedGroups()">Hide suggested groups</a>
</menu>
<ul>
<li>
<p><a href="/group/comp.infosystems.www.authoring.stylesheets/view">comp.infosystems.www.authoring.stylesheets</a> -
<a href="/group/comp.infosystems.www.authoring.stylesheets/subscribe">join</a></p>
<p>Group description: <strong>Layout/presentation on the WWW.</strong></p>
<p><meter value="0.5">Moderate activity,</meter> Usenet, 618 subscribers</p>
</li>
<li>
<p><a href="/group/netscape.public.mozilla.xpinstall/view">netscape.public.mozilla.xpinstall</a> -
<a href="/group/netscape.public.mozilla.xpinstall/subscribe">join</a></p>
<p>Group description: <strong>Mozilla XPInstall discussion.</strong></p>
<p><meter value="0.25">Low activity,</meter> Usenet, 22 subscribers</p>
</li>
<li>
<p><a href="/group/mozilla.dev.general/view">mozilla.dev.general</a> -
<a href="/group/mozilla.dev.general/subscribe">join</a></p>
<p><meter value="0.25">Low activity,</meter> Usenet, 66 subscribers</p>
</li>
</ul>
Might be rendered as follows:

The min, max, value, low, high, and optimum DOM attributes must
reflect the elements' content attributes of the same name. When the
relevant content attributes are absent, the DOM attributes must return
zero. The value parsed from the textContent never affects the DOM values.
Would be cool to have the value DOM attribute
update the textContent in-line...
progress elementStrictly inline-level content.
value
max
interface HTMLProgressElement : HTMLElement { attribute long value; attribute long max; };
The progress element represents
the completion progress of a task. The progress is either indeterminate,
indicating that progress is being made but that it is not clear how much
more work remains to be done before the task is complete (e.g. because the
task is waiting for a remote host to respond), or the progress is a number
in the range zero to a maximum, giving the fraction of work that has so
far been completed.
There are two attributes that determine the current task completion represented by the element.
The value attribute specifies
how much of the task has been completed, and the max attribute specifies how
much work the task requires in total. The units are arbitrary and not
specified.
Instead of using the attributes, authors are recommended to simply include the current value and the maximum value inline as text inside the element.
Here is a snippet of a Web application that shows the progress of some automated task:
<section>
<h2>Task Progress</h2>
<p><label>Progress: <progress><span id="p">0</span>%</progress></p>
<script>
var progressBar = document.getElementById('p');
function updateProgress(newValue) {
progressBar.textContent = newValue;
}
<</script>
</section>
(The updateProgress() method in this example would be
called by some other code on the page to update the actual progress bar
as the task progressed.)
Author requirements: The max and value attributes,
when present, must have values that are valid floating point numbers.
User agent requirements: User agents must parse the
max and value attributes
according to the rules for parsing floating point number attribute
values.
If the value attribute is omitted, then user agents
must also parse the textContent
of the progress element in question
using the steps for finding one or two numbers in a
string. These steps will return nothing, one number, one number
with a denominator punctuation character, or two numbers.
Using the results of this processing, user agents must determine whether the progress bar is an indeterminate progress bar, or whether it is a determinate progress bar, and in the latter case, what its current and maximum values are, all as follows:
max
attribute is omitted, and the value is omitted, and the results of parsing
the textContent was nothing,
then the progress bar is an indeterminate progress bar. Abort these
steps.
max
attribute is included, then, if a value could be parsed out of it, then
the maximum value is that value.
max attribute is absent but the value attribute
is present, or, if the max attribute is present but no value could be
parsed from it, then the maximum is 1.
textContent contained one number with an
associated denominator punctuation character, then the maximum value is
the value associated with that denominator punctuation
character; otherwise, if the textContent contained two numbers, the
maximum value is the higher of the two values; otherwise, the maximum
value is 1.
value attribute is present on the element and a
value could be parsed out of it, that value is the current value of the
progress bar. Otherwise, if the attribute is present but no value could
be parsed from it, the current value is zero.
value attribute is absent and the max attribute is
present, then, if the textContent was parsed and found to
contain just one number, with no associated denominator punctuation
character, then the current value is that number. Otherwise, if the value attribute
is absent and the max attribute is present then the current value
is zero.
textContent of the element.
UA requirements for showing the progress bar: When
representing a progress element to
the user, the UA should indicate whether it is a determinate or
indeterminate progress bar, and in the former case, should indicate the
relative position of the current value relative to the maximum value.
The max and
value DOM
attributes must reflect the elements' content attributes of the same name.
When the relevant content attributes are absent, the DOM attributes must
return zero. The value parsed from the textContent never affects the DOM values.
Would be cool to have the value DOM
attribute update the textContent
in-line...
code elementStrictly inline-level content.
title attribute has special semantics on this
element when used with the dfn element.
HTMLElement.
The code element represents a fragment
of computer code. This could be an XML element name, a filename, a
computer program, or any other string that a computer would recognise.
See the pre element for
more detais.
The following example shows how a block of code could be marked up
using the pre and code elements.
<pre><code>var i: Integer; begin i := 1; end.</code></pre>
var elementStrictly inline-level content.
title attribute has special semantics on this
element when used with the dfn element.
HTMLElement.
The var element represents a variable.
This could be an actual variable in a mathematical expression or
programming context, or it could just be a term used as a placeholder in
prose.
In the paragraph below, the letter "n" is being used as a variable in prose:
<p>If there are <var>n</var> pipes leading to the ice cream factory then I expect at <em>least</em> <var>n</var> flavours of ice cream to be available for purchase!</p>
samp elementStrictly inline-level content.
title attribute has special semantics on this
element when used with the dfn element.
HTMLElement.
The samp element represents (sample)
output from a program or computing system.
See the pre and kbd elements for more detais.
This example shows the samp element
being used inline:
<p>The computer said <samp>Too much cheese in tray two</samp> but I didn't know what that meant.</p>
This second example shows a block of sample output. Nested samp and kbd
elements allow for the styling of specific elements of the sample output
using a style sheet.
<pre><samp><samp class="prompt">jdoe@mowmow:~$</samp> <kbd>ssh demo.example.com</kbd> Last login: Tue Apr 12 09:10:17 2005 from mowmow.example.com on pts/1 Linux demo 2.6.10-grsec+gg3+e+fhs6b+nfs+gr0501+++p3+c4a+gr2b-reslog-v6.189 #1 SMP Tue Feb 1 11:22:36 PST 2005 i686 unknown <samp class="prompt">jdoe@demo:~$</samp> <samp class="cursor">_</samp></samp></pre>
kbd elementStrictly inline-level content.
HTMLElement.
The kbd element represents user input
(typically keyboard input, although it may also be used to represent other
input, such as voice commands).
When the kbd element is nested inside a
samp element, it represents the input as
it was echoed by the system.
When the kbd element contains
a samp element, it represents input
based on system output, for example invoking a menu item.
When the kbd element is nested inside
another kbd element, it represents an
actual key or other single unit of input as appropriate for the input
mechanism.
Here the kbd element is used to
indicate keys to press:
<p>To make George eat an apple, press <kbd><kbd>Shift</kbd>+<kbd>F3</kbd></kbd></p>
In this second example, the user is told to pick a particular menu
item. The outer kbd element marks up a
block of input, with the inner kbd
elements representing each individual step of the input, and the samp elements inside them indicating that the
steps are input based on something being displayed by the system, in this
case menu labels:
<p>To make George eat an apple, select
<kbd><kbd><samp>File</samp></kbd>|<kbd><samp>Eat Apple...</samp></kbd></kbd>
</p>
sup and sub
elementsStrictly inline-level content.
HTMLElement.
The sup element represents a
superscript and the sub element
represents a subscript.
These elements must only be used to mark up typographical conventions
with specific meanings, not for typographical presentation for
presentation's sake. For example, it would be inappropriate for the
sup and sub elements to be used in the name of the LaTeX
document preparation system. In general, authors should not use these
elements if the absence of those elements would not change the
meaning of the content.
When the sub element is used inside a
var element, it represents the subscript
that identifies the variable in a family of variables.
<p>The coordinate of the <var>i</var>th point is (<var>x<sub><var>i</var></sub></var>, <var>y<sub><var>i</var></sub></var>). For example, the 10th point has coordinate (<var>x<sub>10</sub></var>, <var>y<sub>10</sub></var>).</p>
In certain languages, superscripts are part of the typographical conventions for some abbreviations.
<p>The most beautiful women are <span lang="fr"><abbr>M<sup>lle</sup></abbr> Gwendoline</span> and <span lang="fr"><abbr>M<sup>me</sup></abbr> Denise</span>.</p>
Mathematical expressions often use subscripts and superscripts. Authors
are encouraged to use MathML for marking up mathematics, but authors may
opt to use sub and sup if detailed mathematical markup is not
desired. [MathML]
<var>E</var>=<var>m</var><var>c</var><sup>2</sup>
f(<var>x</var>, <var>n</var>) = log<sub>4</sub><var>x</var><sup><var>n</var></sup>
span elementStrictly inline-level content.
title attribute has special semantics on this
element when used with the dfn element.
HTMLElement.
The span element doesn't mean anything
on its own, but can be useful when used together with other attributes,
e.g. lang or dir, or when used in conjunction with the dfn element.
Now that we have i, do
we need span to work with dfn?
bdo elementStrictly inline-level content.
dir global attribute is
required on this element.
HTMLElement.
The bdo element allows authors to
override the Unicode bidi algorithm by explicitly specifying a direction
override. [BIDI]
Authors must specify the dir attribute
on this element, with the value ltr to specify a
left-to-right override and with the value rtl to specify a
right-to-left override.
If the element has the dir attribute set
to the exact value ltr, then for the purposes of the bidi
algorithm, the user agent must act as if there was a U+202D LEFT-TO-RIGHT
OVERRIDE character at the start of the element, and a U+202C POP
DIRECTIONAL FORMATTING at the end of the element.
If the element has the dir attribute set
to the exact value rtl, then for the purposes of the bidi
algorithm, the user agent must act as if there was a U+202E RIGHT-TO-LEFT
OVERRIDE character at the start of the element, and a U+202C POP
DIRECTIONAL FORMATTING at the end of the element.
The requirements on handling the bdo
element for the bidi algorithm may be implemented indirectly through the
style layer. For example, an HTML+CSS user agent should implement these
requirements by implementing the CSS unicode-bidi property.
[CSS21]
br elementStrictly inline-level content.
HTMLElement.
The br element represents a line break.
br elements must be empty. Any content
inside br elements must not be considered
part of the surrounding text.
br elements must only be used for line
breaks that are actually part of the content, as in poems or addresses.
The following example is correct usage of the br element:
<p>P. Sherman<br> 42 Wallaby Way<br> Sydney</p>
br elements must not be used for
separating thematic groups in a paragraph.
The following examples are non-conforming, as they abuse the br element:
<p><a ...>34 comments.</a><br> <a ...>Add a comment.<a></p>
<p>Name: <input name="name"><br> Address: <input name="address"></p>
Here are alternatives to the above, which are correct:
<p><a ...>34 comments.</a></p> <p><a ...>Add a comment.<a></p>
<p>Name: <input name="name"></p> <p>Address: <input name="address"></p>
The ins and del elements represent edits to the document.
ins elementBlock-level element, and strictly inline-level content.
ins elements, and
del elements: same content model as the
parent element, with the additional restriction that if the parent
element allows a choice in content models (e.g. block or inline) then if
all the children of all the sibling ins
elements were placed directly in the parent element, the document would
still be conforming.
cite
datetime
HTMLModElement
interface.
The ins element represents an addition
to the document.
The ins element must be used only where
block-level elements or strictly inline-level content can be used.
An ins element must only contain
content that would still be conformant if all ins elements were replaced by their contents.
The following would be syntactically legal:
<aside> <ins> <p>...</p> </ins> </aside>
As would this:
<aside> <ins> <em>...</em> </ins> </aside>
However, this last example would be illegal, as em and p cannot
both be used inside an aside element
at the same time:
<aside> <ins> <p>...</p> </ins> <ins> <em>...</em> </ins> </aside>
del elementBlock-level element, and strictly inline-level content.
cite
datetime
HTMLModElement
interface.
The del element represents a removal
from the document.
The del element must only contain
content that would be allowed inside the parent element (regardless of
what the parent element actually contains).
The following would be syntactically legal:
<aside> <del> <p>...</p> </del> <ins> <em>...</em> </ins> </aside>
...even though the p and em elements would never be allowed side by side in
the aside element. This is allowed
because the del element represents
content that was removed, and it is quite possible that an edit could
cause an element to go from being an inline-level container to a
block-level container, or vice-versa.
ins and del elementsThe cite
attribute may be used to specify a URI that explains the change. When that
document is long, for instance the minutes of a meeting, authors are
encouraged to include a fragment identifier pointing to the specific part
of that document that discusses the change.
If the cite
attribute is present, it must be a URI (or IRI) that explains the change.
User agents should allow users to follow such citation links.
The datetime attribute may be
used to specify the time and date of the change.
This next bit should be extracted to the "common microsyntaxes" section
If the datetime attribute is present, it must have a
value consisting of four digits representing the year, a literal hyphen,
two digits representing the month, a literal hyphen, two digits
representing the day, a literal T, two digits for the hour, a colon, two
digits for the minutes, another colon, two digits for the seconds,
optionally a decimal point followed by one or more digits for the fraction
of a second, and finally either a literal Z, or, a plus sign or a minus
sign followed by two digits for the hour offset, a colon, and two digits
for the minute offset.
In other words: YYYY-MM-DDThh:mm:ss.sTZ
Digits must be in the range 0-9 (U+0030 to U+0039), interpreted in base ten. The hyphen must be U+002D, the T must be U+0054, the colon must be U+003A, the Z must be U+005A, the plus must be U+002B, and the minus U+002D (same as the hyphen).
To interpret this value, user agents must first check to see if the value matches the pattern described here. If it does, then the values must be extracted and interpreted as a date and time with a timezone offset, as per ISO 8601. [ISO8601]
If the attribute value does not match the format, or, if the date or time given is not a valid date and time (e.g. because the month is out of range) then the user agent must ignore the attribute (the modification has no associated timestamp).
The ins and del elements must implement the HTMLModElement interface:
interface HTMLModElement : HTMLElement { attribute DOMString cite; attribute DOMString datetime; };
The cite and
datetime
DOM attributes must reflect the elements' content attributes of the same
name.
img elementStrictly inline-level content.
src (required)
alt (required)
height
width
usemap
ismap
interface HTMLImageElement : HTMLElement { attribute DOMString src; attribute DOMString alt; attribute long height; attribute long width; attribute boolean isMap; attribute DOMString useMap; };
The img element represents a piece of
text with an alternate graphical representation. The text is given by the
alt attribute, and the URI to the graphical representation of
that text is given by the src attribute.
This section is (obviously) incomplete.
The alt attribute on
images must not be shown in a tooltip in visual browsers.
This section will contain definitions of the
table element and so forth.
This section will contain definitions of the
form element and so forth.
script elementBlock-level element, strictly inline-level content, and metadata element.
head element.
src attribute, depends on the value of the type attribute.
src attribute, the element must be empty.
src
type
defer (if the src attribute is
present)
async (if the src attribute is
present)
interface HTMLScriptElement : HTMLElement { attribute DOMStringtext; attribute DOMStringsrc; attribute DOMStringtype; attribute booleandefer; attribute booleanasync; };
The script element allows authors to
include dynamic script in their documents.
When the src
attribute is set, the script element
refers to an external file. The value of the attribute must be a URI.
If the src
attribute is not set, then the script is given by the contents of the
element.
The language of the script is given by the type attribute. The value must
be a valid MIME type, optionally with parameters. [RFC2046]
script elements have an associated
piece of metadata, a flag indicating whether or not the script block has
been "already executed". Initially, script elements must have this flag unset
(script blocks, when created, are not "already executed"). When a script element is cloned, the "already
executed" flag, if set, must be propagated to the clone when it is
created.
When script blocks are run: When a script element whose "already executed" flag is
not set is inserted into a document, the user agent must act
as follows:
First, if the element has a src attribute, then a load for the specified
content must be started.
Then, if the document is still being parsed, and the element has a
defer attribute, then the element
must be added to the end of the list of scripts that will execute
when the document has finished parsing.
Otherwise, if the document is still being parsed, and the element has
a async attribute and a src attribute, then
the element must be added to the end of the list of scripts that
will execute asynchronously.
Otherwise, if the document is still being parsed, the element must be executed synchronously.
Otherwise, the document has finished being parsed; if the element has
no src
attribute, the element must be executed synchronously.
Otherwise, the document has finished being parsed and the element has
a src attribute:
the element must be added to the end of the list of scripts that
will execute asynchronously.
How to execute a script block: ...
WIP
The DOM attributes src, type, defer, async, each reflect the respective content attributes of
the same name.
The DOM attribute text must return a
concatenation of the contents of all the text nodes and CDATA nodes that
are direct children of the script
element (ignoring any other nodes such as comments or elements), in tree
order. On setting, it must act the same way as the textContent DOM attribute.
The following lists some MIME types and the languages to which they refer:
text/javascript
text/javascript;e4x=1
noscript element [TBW]The noscript
element needs to be defined too.
all the new things in WA1: menu, calendar, card, canvas, switch, datagrid, datatree, switch, etc
This section may somehow introduce some predefined classes with actual semantic meanings; possibly by defining a profile.
This section might at some future point list a small
set of link relationship types and more exactly define their
semantics than HTML4. This section (or indeed this specification in
general) is unlikely to specify anything related to the profile attribute and how to extend the link
types in HTML. Work in this area is currently being done by GMPG and others.
User agents must support all of the common attributes and event handlers
on the section element, as well as
the active attribute (for use with mutually exclusive sections).
In CSS-aware user agents, the default presentation of this element should be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:
@namespace xh url(http://www.w3.org/1999/xhtml);
xh|section { display: block; margin: 1em 0; }
For h1 elements, CSS-aware visual user
agents should derive the size of the header from the level of section nesting. This effect should be
achieved by including the following rules, or their equivalent, in the
UA's user agent style sheet:
@namespace xh url(http://www.w3.org/1999/xhtml);
xh|section xh|h1 { /* same styles as h2 */ }
xh|section xh|section xh|h1 { /* same styles as h4 */ }
xh|section xh|section xh|section xh|h1 { /* same styles as h4 */ }
xh|section xh|section xh|section xh|section xh|h1 { /* same styles as h5 */ }
xh|section xh|section xh|section xh|section xh|section xh|h1 { /* same styles as h6 */ }
Authors should use h1 elements to denote
headers in sections. Authors may instead use h2 ... h6 elements,
for backwards compatibility with user agents that do not support section elements.
This section should probably die.
A group of related, order-neutral sections may be denoted using the tabbox element. The default presentation in
a visual media (as described below) is to render each section as a
separate tab in a tab box, allowing the user to switch between them.
Sections can also be represented by links to other documents, instead of
them being included literally in the markup.
The tabbox element is a block-level
element that should only contain section, fieldset, and a elements.
Authors should only use a elements that
cause the user agent to change the active page to a page with a similar
structure. Other behaviours are likely to be highly confusing to users.
Each section,
fieldset, and a child can have
a title. If the element is a section
element, then the title is taken from the title attribute of the element, if specified,
or, if absent, from the textContent DOM attribute of the first
element child of the section element,
if that is an h1 ... h6 element. (If it is taken from a header child,
then that child is hidden from the rendering.) If the element is a
fieldset element, then the title is taken from the the
textContent DOM attribute of the
first element child of the fieldset element, if that is an
legend element. If the element is an a element, then the title is taken from the textContent DOM attribute of the element.
(Titles may be the empty string.)
The titles obtained in this way, and the section, fieldset, and a elements from which they were derived, represent
the list of sections in the tabbox.
This list is live, in that dynamic changes to
the DOM immediately affect the representation of the tabbox element.
All the other child nodes of the tabbox shall be ignored for the purposes of
rendering the tabbox. Authors may use
this in order to obtain acceptable renderings even in UAs that do not
support tabbox.
In CSS-aware user agents, the default presentation of the tabbox element should, in part, be achieved by
including the following rules, or their equivalent, in the UA's user agent
style sheet:
@namespace xh url(http://www.w3.org/1999/xhtml);
xh|tabbox { display: block; }
xh|tabbox > xh|section:not([title]) > xh|h1:first-child,
xh|tabbox > xh|section:not([title]) > xh|h2:first-child,
xh|tabbox > xh|section:not([title]) > xh|h3:first-child,
xh|tabbox > xh|section:not([title]) > xh|h4:first-child,
xh|tabbox > xh|section:not([title]) > xh|h5:first-child,
xh|tabbox > xh|section:not([title]) > xh|h6:first-child,
xh|tabbox > xh|fieldset > xh|legend:first-child { display: none; }
These rules do not come even close to fully describing the full
behaviour of a tabbox element, however.
The behaviour of the tabbox should be
to provide quick access to any of the children of the tabbox that have a title (as described above).
UAs may keep track of which section is the selected section, and report
this information to the user.
When the user specifies a section to access, the relevant element must
have a click event dispatched to it, whose default
action is to further dispatch a DOMActivate event to the
element.
For section and
fieldset elements, the default action of
DOMActivate events is to display, or jump to, the relevant
section. For a elements, the default action
is the normal default action for a elements
(activating the link, command, or whatever). In addition to these default
actions, when a child of a tabbox is
accessed, it becomes the selected section.
If the DOMActivate event is canceled (or if the click event is canceled, causing the
DOMActivate event to never be fired in the first place), then
the selected section does not change.
If an a element has a command attribute, it can be disabled. In
such cases, the UA should not allow the user to select that section.
The initially selected section shall be the first element from the
tabbox element's child list that is:
a element whose href
attribute matches the URI of the current document, if there is one,
a element whose
href attribute matches the URI given by the
href attribute of the first link element in the document that has a
rel attribute whose value contains the keyword
up (treating that attribute as a space-separated list), if
there is one,
section or
fieldset element that has a title, if there is one.
If no elements match, then initially no section shall be selected.
In the above algorithm, URI comparisons should be done after
canonicalisation, and should ignore fragment identifiers unless the
a element in question has one.
In non-interactive or non-spatial media (such as in print, on braille systems, or with speech synthesis) the UA may automatically switch the selected section to the next section once the selected section has been rendered.
Which section is selected if the element representing the currently selected section is dynamically removed from the document is up to the UA.
In interactive visual media, the tabbox element should be rendered as a tab box,
with the section titles listed as the tabs, and the selected section (if
it is a section or
fieldset element) displayed in the tab panel area. When the
selected section is an a element, the tab
panel area should be empty.
This specification does not describe how CSS properties apply to
tabbox elements when the UA uses this
rendering, but the children rendered in the tab panel area must be styled
using CSS, as if the tab panel area defined a new containing block and new
block formatting context.
User agents must support all of the common attributes and event handlers
on the tabbox element.
Here is an example of a tabbox used
to allow the user to read three different parts of the document:
<tabbox> <section> <h2>About</h2> <p><img src="logo" alt=""></p> <p>The Application.</p> <p>© copyright 2004 by The First Team.</p> </section> <section> <h2>Credits</h2> <ul> <li>Jack O'Neill</li> <li>Samantha Carter</li> <li>Daniel Jackson</li> <li>Teal'c</li> <li>Jonas Quinn</li> </ul> </section> </tabbox>
Next, an example of a form that has been split into little groups of controls:
<tabbox> <fieldset> <legend>Identity</legend> <p><label>First name: <input name="fn"></label></p> <p><label>Last name: <input name="ln"></label></p> <p><label>Date of Birth: <input name="dob" type="date"></label></p> </fieldset> <fieldset> <legend>Food</legend> <p><label>Favourite appetizer: <input name="fa"></label></p> <p><label>Favourite meal: <input name="fm"></label></p> <p><label>Favourite desert: <input name="fd"></label></p> </fieldset> </tabbox>
Finally, an example of a page using a tabbox to point to sections outside the
document. Note the use of fallback content (elements and text in the
tabbox element that are not
fieldset, section, or
a elements) for backwards compatibility.
<div> <tabbox> <strong>Navigation:</strong> <a href="/"><span>Home</span></a>, <a href="/news/"><span>News</span></a>, <a href="/games/"><span>Games</span></a>, <a href="/help/"><span>Help</span></a>, <a href="/contact/"><span>Contact</span></a>. </tabbox> </div>
This would be semantically equivalent to the following:
<tabbox> <section><h2>Home</h2> ...content... </section> <section><h2>News</h2> ...content... </section> <section><h2>Games</h2> ...content... </section> <section><h2>Help</h2> ...content... </section> <section><h2>Contact</h2> ...content... </section> </tabbox>
The switch element represents a
block of mutually exclusive sections.
For example, in an application for an online mutiplayer game, there could be four mutually exclusive sections: one for the login page, one for the network status page displayed while the user is logging in, one for a "lobby" where players get together to organise a game, and one for the actual game. The different sections are the various states that the application can reach.
The switch element must contain only
block-level elements. User agents
must support all of the common attributes and event handlers on the
switch element.
All child elements of a switch
element shall be hidden except those that have active
attributes (or, for non-XHTML elements, active attributes in
the XHTML namespace).
In CSS-aware user agents, the default presentation of this element should be achieved by including the following rules, or their equivalent, in the UA's user agent style sheet:
@namespace xh url(http://www.w3.org/1999/xhtml);
xh|switch { display: block; }
xh|switch xh|*:not([active]) { display: none; }
xh|switch *:not([xh|active]) { display: none; }
switch and sectioninterface HTMLSwitchElement : HTMLElement { readonly attribute Element activeElement; void setActive(in Element element); }; interface HTMLSectionElement : HTMLElement { readonly attribute boolean active; void setActive(); };
...
When an element is added to a switch
element as a child (whether during parsing, or later), the element is
examined. If the element has an active attribute (or, if it
is a non-XHTML element, if it has an active attribute in the
XHTML namespace), or, if the switch
element's activeElement DOM attribute is null, then the
switch element's setActive
method is called with that element as the argument. This causes the
element to be made the active element for the switch, and causes any other
elements to be deactivated if needed.
A side-effect of this definition is that the first element in a switch element is the default element if none
have been explicitly marked as active.
The calendar element may be used
for indicating hCalendar fragments that should be processed and rendered,
e.g. as inline calendars.
The calendar element is a
block-level element whose content model is any block-level elements. User agents must
support all the common attributes and event handlers on calendar elements.
Web browsers should render the calendar element by replacing the element by a
representation of the calendar data contained within it.
UAs must process the contents of calendar data as described in the hCalendar
specification. [HCALENDAR]
These examples will need updating to track hCalendar as it evolves.
The following fragment:
<calendar>
<div class="vcalendar">
<span class="prodid">-//hCalendar//EN</span>
<span class="version">2.0</span>
<p class="vevent">
<a href="http://www.web2con.com/">
<span class="dtstart">20041005</span>-
<span class="dtend">20041007</span>
<span class="summary">Web 2.0 Conference</span>
</a>
</p>
</div>
</calendar>
...might render as the following:

The card element may be used for
indicating hCard fragments that should be processed and rendered, e.g. as
inline business cards.
The card element is a block-level
element whose content model is any block-level elements. User agents must
support all the common attributes and event handlers on card elements.
Web browsers should render the card
element by replacing the element by a representation of the personal data
contained within it.
UAs must process the contents of card
data as described in the hCard specification. [HCARD]
These examples will need updating to track hCard as it evolves.
The following fragment:
<card> <p class="vcard"> <a class="fn n" href="http://tantek.com/"> <span class="Given-Name">Tantek</span> <span class="Family-Name">Çelik</span> </a> </p> </card>
...might render as the following:

The "more details" widget.
datagrid elementIt has been suggested that instead of this flattened-row API, we should have all the "row" arguments in the API below be arrays of integers, and instead of getParentRow(), we would have getRowCount() get the number of children that a row had. A future version of this specification will make this change, along with adding a way to detect when a row/selection has been deleted, activated, etc.
This element is defined as interactive, which means it can't contain other interactive elements, despite the fact that we expect it to work with other interactive elements e.g. checkboxes and input fields. It should be called something like a Leaf Interactive Element or something, which counts for ancestors looking in and not descendants looking out.
Interactive, block-level element.
multiple
disabled
interface HTMLDataGridElement : HTMLElement { attribute DataGridDataProvider data; attribute SelectedRowRanges selection; attribute boolean multiple; attribute boolean disabled; void updateEverything(); void updateRowsChanged(in long row, in long count); void updateRowsInserted(in long row, in long count); void updateRowsRemoved(in long row, in long count); void updateRowChanged(in long row); void updateColumnChanged(in long column); void updateCellChanged(in long row, in long column); };
The datagrid element represents an
interactive representation of tree, list, or tabular data.
The data being presented can come either from the content, as elements
given as children of the datagrid
element, or from a scripted data provider given by the data DOM attribute.
The multiple attribute, if present, must be
either empty or have the literal value multiple.
Similarly, the disabled attribute, if present, must be
either empty or have the literal value disabled.
(The actual values do not have any effect on how these attributes are
processed, only the presence or absence of the attributes is important.)
The multiple and disabled
DOM attributes reflect the multiple
and disabled content attributes respectively.
datagrid data modelThis section is non-normative.
In the datagrid data model, data
is structured as a set of rows representing a tree, each row being split
into a number of columns. The columns are always present in the data
model, although individual columns may be hidden in the presentation.
Each row can have a parent row. If a row r has a parent row p, then all the rows between it and its parent will also have a parent row, and for each row i between p and r the parent row of i will be either p or another row between p and i.
Rows that have other rows claiming them as their parent row are open. Rows can be closed, hiding all the data that would form child rows, but when a row is closed its child data does not appear in the data model.
The columns can have captions. Those captions are not considered a row in their own right, they are obtained separately.
Selection of data in a datagrid
operates at the row level. If the multiple attribute is present, multiple rows
can be selected at once, otherwise the user can only select one row at a
time.
The datagrid element can be
disabled entirely by setting the disabled attribute.
Columns, rows, and cells can each have specific flags, known as classes,
applied to them by the data provider. These classes affect the functionality of the datagrid element, and are also passed to the style system. They are similar
in concept to the class attribute, except
that they are not specified on elements but are given by scripted data
providers.
The conformance criteria in this section apply to any implementation
of the DataGridDataProvider, including
(and most commonly) the content author's implementation(s).
// To be implemented by Web authors as a JS object
interface DataGridDataProvider {
void initialize(in HTMLDataGridElement datagrid);
long getRowCount();
long getColumnCount();
DOMString getCaptionText(in long column);
void getCaptionClasses(in long column, in DOMTokenString classes);
long getRowParent(in long row);
DOMString getRowImage(in long row);
HTMLMenuElement getRowMenu(in long row);
void getRowClasses(in long row, in DOMTokenString classes);
DOMString getCellData(in long row, in long column);
void getCellClasses(in long row, in long column, in DOMTokenString classes);
void toggleRowOpenState(in long row);
void toggleColumnSortState(in long column);
void setCellCheckedState(in long row, in long column, in int state);
void cycleCell(in long row, in long column);
void editCell(in long row, in long column, in DOMString data);
};
The DataGridDataProvider interface
represents the interface that objects must implement to be used as custom
data views for datagrid elements.
Not all the methods are required. The minimum number of methods that
must be implemented in a useful view is two: the getRowCount() and getCellData() methods.
Once the object is written, it must be hooked up to the datagrid using the data DOM attribute.
The following methods may be usefully implemented:
initialize(datagrid)
datagrid element
(the one given by the datagrid argument) after it has
first populated itself. This would typically be used to set the initial
selection of the datagrid element
when it is first loaded. The data provider could also use this method
call to register a select event handler on the datagrid in order to monitor selection
changes.
getRowCount()
datagrid must be called first. Otherwise,
this method must always return the same number.
getColumnCount()
datagrid's updateEverything() method must be
called.
getCaptionText(column)
datagrid's updateColumnChanged() method must
be called with the appropriate column index.
getCaptionClasses(column, classes)
datagrid's updateColumnChanged() method must
be called with the appropriate column index. Some classes have predefined meanings.
getRowParent(row)
datagrid is a list and not a tree.
If the value that this method would return changes, the datagrid's update methods must be called to
update all the rows in the range that covers the old parent, the new
parent, and the row in question.
getRowImage(row)
datagrid's update methods must be called to
update the row in question.
getRowMenu(row)
HTMLMenuElement object that is to be used
as a context menu for row row, or null if there is no
particular context menu. May be omitted if none of the rows have a
special context menu. As this method is called immediately before showing
the menu in question, no precautions need to be taken if the return value
of this method changes.
getRowClasses(row, classes)
datagrid's update methods must be
called to update the row in question. Some classes have predefined meanings.
getCellData(row, column)
datagrid's update methods must be called to
update the rows that changed. If only one cell changed, the updateCellChanged() method may be
used.
getCellClasses(row, column, classes)
datagrid's update methods must be called to
update the rows or cells in question. Some classes have predefined meanings.
toggleRowOpenState(row)
datagrid when the
user tries to open or close a row. When it is called on a closed row, the
data provider must update its state so that the rows now include the
child rows, and must call the updateRowsInserted() method
appropriately. Similarly, when it is called on an open row, the data
provider must update its state so that the rows that were shown under the
row in question are now removed from the data model, and must then call
the updateRowsRemoved() method
appropriately. There is no need to tell the datagrid that the row itself has changed (as
it should; in particular its classes should change to reflect the new
open/closed state), as the datagrid
automatically assumes that the row will need updating.
toggleColumnSortState(column)
Called by the datagrid when the
user tries to sort the data using a particular column column. The data provider must update its state so that
the rows are in the new order, and update the classes of the columns to
represent the new sort status. There is no need to tell the datagrid that it the data has changed, as
the datagrid automatically assumes
that the entire data model will need updating.
It is the data provider's responsibility to ensure that the user's
selection persists through a sort. Typically this will involve taking a
note of which rows were selected before the sort (using the getRangeStart() and getRangeLength() methods of the selection DOM attribute, for instance),
and then clearing the selection and reselecting all the
rows in their new positions (e.g. using the addRange() method).
setCellCheckedState(row, column, state)
datagrid when the
user changes the state of a checkbox cell on row row,
column column. The checkbox should be toggled to the
state given by state, which is a positive integer (1)
if the checkbox is to be checked, zero (0) if it is to be unchecked, and
a negative number (-1) if it is to be set to the indeterminate state.
There is no need to tell the datagrid that the cell has changed, as the
datagrid automatically assumes that
the given cell will need updating.
cycleCell(row,
column)
datagrid when the
user changes the state of a cyclable cell on row row,
column column. The data provider should change the
state of the cell to the new state, as appropriate. There is no need to
tell the datagrid that the cell has
changed, as the datagrid
automatically assumes that the given cell will need updating.
editCell(row, column, data)
datagrid when the
user edits the cell on row row, column column. The new value of the cell is given by data. The data provider should update the cell
accordingly. There is no need to tell the datagrid that the cell has changed, as the
datagrid automatically assumes that
the given cell will need updating.The following classes (for rows, columns, and cells) may be usefully used in conjunction with this interface:
| Class name | Applies to | Description |
|---|---|---|
checked
| Cells | The cell has a checkbox and it is checked. (The cyclable and progress classes override this, though.)
|
closed
| Rows | The row can be opened and closed, and, unless the open class
is also present, the row is currently closed.
|
cyclable
| Cells | The cell can be cycled through multiple values. (The progress class overrides this, though.)
|
editable
| Cells | The cell can be edited. (The cyclable, progress, checked, unchecked and indeterminate classes override this,
though.)
|
header
| Rows | The row is a heading, not a data row. |
indeterminate
| Cells | The cell has a checkbox, and it can be set to an indeterminate
state. If neither the checked nor unchecked classes are present, then the
checkbox is in that state, too. (The cyclable and progress classes override this, though.)
|
initially-hidden
| Columns | The column will not be shown when the datagrid is initially rendered.
|
open
| Rows | The row can be opened and closed, and is currently open. |
progress
| Cells | The cell is a progress bar. |
reversed
| Columns | If the cell is sorted, the sort direction is descending, instead of ascending. |
selectable-separator
| Rows | The row is a normal, selectable, data row, except that instead of
having data, it only has a separator. (The header
and separator classes override this, though.)
|
separator
| Rows | The row is a separator row, not a data row. (The header
class overrides this, though.)
|
sortable
| Columns | The data can be sorted by this column. |
sorted
| Columns | The data is sorted by this column. Unless the reversed class is also present, the sort
direction is ascending.
|
unchecked
| Cells | The cell has a checkbox and, unless the checked class is present as well, it is
unchecked. (The cyclable and progress classes override this, though.)
|
The user agent must supply a default data provider for the case where
the datagrid's data attribute is
null. It must act as described in this section.
The behaviour of the default data provider depends on the nature of the
first element child of the datagrid.
table
getRowCount(): The number of
rows returned by the default data provider must be the number of
tr elements that are children of tbody
elements that are children of the table, if there are any
such child tbody elements. If there are no such
tbody elements then the number of rows returned must be the
number of tr elements that are children of the
table.
Rows in thead elements do not contribute to
the number of rows returned, although they do affect the columns and
column captions. Rows in tfoot elements are ignored
completely by this algorithm.
getColumnCount(): The number
of columns returned must be the number of td element
children in the first tr element child of the first
tbody element child of the table, if there are
any such tbody elements. If there are no such
tbody elements, then it must be the number of
td element children in the first tr element
child of the table, if any, or otherwise 1. If the number
that would be returned by these rules is 0, then 1 must be returned
instead.
getCaptionText(i): If the table has no
thead element child, or if its first thead
element child has no tr element child, the default data
provider must return the empty string for all captions. Otherwise, the
value of the textContent
attribute of the ith th element child
of the first tr element child of the first
thead element child of the table element must
be returned. If there is no such th element, the empty
string must be returned.
getCaptionClasses(i, classes): If the table
has no thead element child, or if its first
thead element child has no tr element child,
the default data provider must not add any classes for any of the
captions. Otherwise, each class in the class attribute of the ith
th element child of the first tr element child
of the first thead element child of the table
element must be added to the classes. If there is no
such th element, no classes must be added. The user agent
must then:
sorted and reversed classes.
table element has a class attribute that includes the sortable class, add the sortable class.
sorted class.
reversed class as well.
The various row- and cell- related methods operate relative to a particular element, the element of the row or cell specified by their arguments.
For rows: Since the view of the data can be sorted, the positions of the rows in the data model might not be the same as the positions of the real rows in the DOM. When the data is sorted, the row given by the method's argument has to be mapped to the real row. Initially, the mapping is the identity transform, but the mapping can be changed if the user sorts the rows.
Once the method's argument has been translated into an index for the
real row, the row's element is found as follows. If the
table has tbody element children, the element
for the ith real row is the ith
tr element that is a child of a tbody element
that is a child of the table element. If the
table does not have tbody element children,
then the element for the ith real row is the ith tr element that is a child of the
table element.
For cells: Given a row and its element, the row's
ith cell's element is the ith
td element child of the row element.
The colspan and rowspan
attributes are ignored by this algorithm.
getRowParent(i): The default data provider must
always return -1 as the parent row of any row.
The table-based default data provider cannot
represent a tree.
getRowImage(i): If the row's first cell's element
has an img element child, then the URI
of the row's image is the URI of the first img element child of the row's first cell's
element. Otherwise, the URI of the row's image is the empty string.
getRowMenu(i): If the row's first cell's element
has a menu element child, then the
row's menu is the first menu element
child of the row's first cell's element. Otherwise, the row has no menu.
getRowClasses(i, classes): The default data provider
must never add a class to the row's classes.
toggleColumnSortState(i): If the data is already being
sorted on the given column, then the user agent must change the current
sort mapping to be the inverse of the current sort mapping; if the sort
order was ascending before, it is now descending, otherwise it is now
ascending. Otherwise, if the current sort column is another column, or
the data model is currently not sorted, the user agent must create a new
mapping, which maps rows in the data model to rows in the DOM so that
the rows in the data model are sorted by the specified column, in
ascending order. (Which sort comparison operator to use is left up to
the UA to decide.)
getCellData(i, j), getCellClasses(i, j, classes), getCellCheckedState(i,
j, state), cycleCell(i, j), and editCell(i, j, data): See the common definitions
below.
The data provider must call the datagrid's update methods appropriately
whenever the descendants of the datagrid mutate. For example, if a
tr is removed, then the updateRowsRemoved() methods would
probably need to be invoked, and any change to a cell or its descendants
must cause the cell to be updated. If the table element
stops being the first child of the datagrid, then the data provider must call
the updateEverything() method on the
datagrid. Any change to a cell
that is in the column that the data provider is currently using as its
sort column must also cause the sort to be reperformed, with a call to
updateEverything() if the change did
affect the sort order.
select
The default data provider must return 1 for the column count, the empty string for the column's caption, and must not add any classes to the column's classes.
For the rows, assume the existence of a linear node iterator view of
the children of the first select element child of the
datagrid element, that skips all
nodes other than optgroup and option elements,
as well as any descendents of any option elements, and
descendants of optgroup elements with the closed token in their class attribute.
Given this view, each element in the view represents a row in the data model: the ith element in the view is the ith row's element. The row of a particular method call is the row given by its arguments.
getRowCount() must return the number of
elements in this view.
getRowParent(i) must
return the index in the view of the nearest ancestor
optgroup element of the row's element, -1 if there is no
such ancestor.
getRowImage(i) must
return the empty string, getRowMenu(i) must
return null.
getRowClasses(i, classes) must add the classes from the
following list to classes when their condition is
met:
class attribute
contains the closed class: closed
class attribute
doesn't contain the closed class: open
The toggleRowOpenState(i) method must add a closed class to that row's element's class attribute and remove any open class, unless it already has a closed class and has no open
class, in which case it must instead remove the closed class and add an open
class. It must then invoke the appropriate update methods to inform the
datagrid of the newly added or
removed rows.
The getCellData(i, j) method must return the value of the label attribute if the row's element
is an optgroup element, otherwise, if the row's element is
an optionelement, its label attribute if it has one,
otherwise the value of its textContent DOM attribute.
The getCellClasses(i, j, classes) method must
add no classes.
The data provider must call the datagrid's update methods appropriately
whenever the descendants of the datagrid mutate.
The default data provider must return 1 for the column count, the empty string for the column's caption, and must not add any classes to the column's classes.
For the rows, assume the existence of a linear node iterator view of
the children of the datagrid that
skips all nodes other than li, h1-h6, and
hr elements, and skips all elements that
are descendants of elements with the closed token
in their class attribute, and any
descendants of menu elements.
Given this view, each element in the view represents a row in the data model: the ith element in the view is the ith row's element. The row of a particular method call is the row given by its arguments.
getRowCount() must return the number of
elements in this view.
getRowParent(i) must
return the index in the view of the nearest ancestor (in the real DOM)
of the row's element that is also in the view, -1 if there is no such
ancestor.
In the following example, the row numbered 2 returns 1 as its parent, and the other rows return -1:
<datagrid>
<ol>
<li> row 0 </li>
<li> row 1
<ol>
<li> row 2 </li>
</ol>
</li>
<li> row 3 </li>
</ol>
</datagrid>
getRowImage(i) must
return the URI of the image given by the first img element descendant (in the real DOM) of the
row's element, that is not also a descendant of another element that has
a later position in the view.
In the following example, the row numbered 2 returns "http://example.com/a" as its image URI, and the other rows (including row 1) return the empty string:
<datagrid>
<ol>
<li> row 0 </li>
<li> row 1
<ol>
<li> row 2 <img src="http://example.com/a" alt=""> </li>
</ol>
</li>
<li> row 3 </li>
</ol>
</datagrid>
getRowMenu(i) must
return the first menu element
descendant (in the real DOM) of the row's element, that is not also a
descendant of another element that has a later position in the view.
(This is analogous to the image case above.)
getRowClasses(i, classes) must add the classes from the
following list to classes when their condition is
met:
class attribute
contains the closed class: closed
class attribute
doesn't contain the closed class: open
h1-h6 element:
header
hr
element: separatorThe toggleRowOpenState(i) method must add a closed class to that row's element's class attribute and remove any open class, unless it already has a closed class and has no open
class, in which case it must instead remove the closed class and add an open
class. It must then invoke the appropriate update methods to inform the
datagrid of the newly added or
removed rows.
The getCellData(i, j), getCellClasses(i, j, classes), getCellCheckedState(i,
j, state), cycleCell(i, j), and editCell(i, j, data) methods must act as described in the common definitions
below, treating the row's element as being the cell's element.
The data provider must call the datagrid's update methods appropriately
whenever the descendants of the datagrid mutate.
The data provider must return 0 for the number of rows, 1 for the
number of columns, the empty string for the first column's caption, and
must add no classes when asked for that column's classes. If the
datagrid's child list changes such
that the first element child is one of the above, then the data provider
must call the updateEverything() method on the
datagrid.
These definitions are used for the cell-specific methods of the default
data providers (other than in the select case). How they
behave is based on the contents of an element that represents the cell
given by their first two arguments (which are the row and column indices
respectively). Which element that is is defined in the previous section.
If the first element child of a cell's element is a
select element that has a no multiple attribute and has at least
one option element descendent, then the cell acts as a
cyclable cell.
The "current" option element is the selected
option element, or the first option element if
none is selected.
The getCellData() method must return the
textContent of the current
option element (the label attribute is ignored in this
context as the optgroups are not displayed).
The getCellClasses() method must add the
cyclable class and then all the classes of
the current option element.
The cycleCell() method must change the
selection of the select element such that the next
option element after the current option
element is the only one that is selected (in tree order). If the current
option element is the last option element
descendent of the select, then the first
option element descendent must be selected instead.
The setCellCheckedState() and editCell()
methods must do nothing.
If the first element child of a cell's element is a progress element, then the cell acts as a
progress bar cell.
The getCellData() method must return the
value returned by the progress
element's position DOM
attribute.
The getCellClasses() method must add the
progress class.
The setCellCheckedState(), cycleCell(), and editCell()
methods must do nothing.
If the first element child of a cell's element is an
input element that has a type attribute with the value checkbox, then the cell acts as a check box cell.
The getCellData() method must return the
textContent of the cell
element.
The getCellClasses() method must add the
checked class if the input
element is checked, and the unchecked class otherwise.
The setCellCheckedState() method must
set the input element's checkbox state to checked if the method's third
argument is 1, and to unchecked otherwise.
The cycleCell() and editCell()
methods must do nothing.
If the first element child of a cell's element is an
input element that has a type attribute with the value text or that has no type attribute at all, then the cell acts
as an editable cell.
The getCellData() method must return the
value of the input
element.
The getCellClasses() method must add the
editable class.
The editCell() method must set the
input element's value
DOM attribute to the value of the third argument to the method.
The setCellCheckedState() and cycleCell() methods must do nothing.
datagrid elementA datagrid must be disabled until
its end tag has been parsed (in the case of a datagrid element in the original document
markup) or until it has been inserted into the document (in the case of a
dynamically created element). After that point, the element must fire a
single load event at itself, which doesn't
bubble and cannot be canceled.
The datagrid must then populate
itself using the data provided by the data provider assigned to the data DOM attribute.
After the view is populated (using the methods described below), the
datagrid must invoke the initialize() method on the data provider
specified by the data attribute, passing itself (the HTMLDataGridElement object) as the
only argument.
When the data
attribute is null, the datagrid must
use the default data provider described in the previous section.
To obtain data from the data provider, the element must invoke methods on the data provider object in the following ways:
getRowCount() method with no arguments.
The return value is the number of rows. If the return value is negative,
not an integer, or simply not a numeric type, or if the method is not
defined, then zero must be used instead.
getColumnCount() method with no
arguments. The return value is the number of columns. If the return value
is zero or negative, not an integer, or simply not a numeric type, or if
the method is not defined, then 1 must be used instead.
getCaptionText() method with the index
of the column in question. The index i must be in the
range 0 ≤ i < N, where N is the total number of columns. The return value is the
string to use when referring to that column. If the method returns null
or the empty string, the column has no caption. If the method is not
defined, then none of the columns have any captions.
getCaptionClasses() method with the
index of the column in question, and an object implementing the DOMTokenString interface, initialised
to empty. The index i must be in the range 0 ≤
i < N, where N is the total number of columns. The values contained in
the DOMTokenString object when
the method returns represent the classes that apply to the given column.
If the method is not defined, no classes apply to the column.
initially-hidden class applies to the
column. If it does, then the column should not be initially included; if
it does not, then the column should be initially included.
sortable class applies to the column. If it
does, then the user should be able to ask the UA to display the data
sorted by that column; if it does not, then the user agent must not allow
the user to ask for the data to be sorted by that column.
sorted
class applies to the column. If it does, then that column is the sorted
column, otherwise it is not.
sorted class applies to that column. The first
column that has that class, if any, is the sorted column. If none of the
columns have that class, there is no sorted column.
reversed class applies to the column. If it
does, then the sort direction is descending (down; first rows have the
highest values), otherwise it is ascending (up; first rows have the
lowest values).
Invoke the getRowParent() method with the index of
the row in question. The index i must be in the
range 0 ≤ i < N, where
N is the total number of rows. The return value p is the index of the parent row. If the method returns a
number outside the range 0 ≤ p < i, or if the returned value is non-numeric, or if the
method is not defined, then the row has no parent row (it is an
unparented top-level row).
If a row r has a parent row p, but not all the rows between it and its parent also have a parent row, or if there is a row i between p and r the parent of which is neither p nor another row between p and i, then the user agent may present the tree structure in an inconsistent way instead of attempting to render the actual described tree structure.
getRowImage() method with the index of the
row in question. The index i must be in the range 0
≤ i < N, where N is the total number of rows. The return value is a
string representing a URI or IRI to an image. Relative URIs must be
interpreted relative to the datagrid's base URI. If the method returns
the empty string, null, or if the method is not defined, then the row has
no associated image.
getRowMenu() method with the index of the
row in question. The index i must be in the range 0
≤ i < N, where N is the total number of rows. The return value is a
reference to an object implementing the HTMLMenuElement
interface, i.e. a menu element DOM
node. (This element must then be interpreted as described in the section
on context menus to obtain the actual context menu to
use.) If the
method returns something that is not an HTMLMenuElement, or
if the method is not defined, then the row has no associated context
menu. User agents may provide their own default context menu, and may add
items to the author-provided context menu. For example, such a menu could
allow the user to change the presentation of the datagrid element.
getRowClasses() method with the index of
the row in question, and an object implementing the DOMTokenString interface, initialised
to empty. The index i must be in the range 0 ≤
i < N, where N is the total number of rows. The values contained in the
DOMTokenString object when the
method returns represent the classes that apply to the row in question.
If the method is not defined, no classes apply to the row.
header
class applies to the row, then it is not a data row, it is a subheading.
The data from the first cell of the row is the text of the subheading,
the rest of the cells must be ignored. Otherwise, if the separator class applies to the row, then in
the place of the row, a separator should be shown. Otherwise, if the
selectable-separator class
applies to the row, then the row should be a data row, but represented as
a separator. (The difference between a separator and a selectable-separator is that the
former is not an item that can be actually selected, whereas the second
can be selected and thus has a context menu that applies to it, and so
forth.) For both kinds of separator rows, the data of the rows' cells
must all be ignored. If none of those three classes apply then the row is
a simple data row.
open or closed
classes applies to the row. If one (or both) of these are present, then
the row can be opened and closed, otherwise neither are present and the
row cannot be opened or closed. (It might still have rows that consider
this row a parent, however.)
open class applies to the row. If it does, the
row is open. Otherwise, the row is closed. The closed
class is not examined to make this determination (although either it or
the open
class must be present to make the row openable in the first place). If a
closed row has rows that consider it a parent, those rows must still be
included in the rendering.getCellData() method with the first
argument being the index of the cell's row and the second argument being
the index of its column. The two arguments must be zero or positive
integers less than the total number of rows and columns respectively. The
return value is the value of the cell. If the return value is null or the
empty string, or if the method is not defined, then the cell has no data.
(For progress bar cells, the cell's value must be further interpreted, as
described below.)
getCellClasses() method with the first
argument being the index of the cell's row, the second argument being the
index of its column, and the third being an object implementing the
DOMTokenString interface,
initialised to empty. The first two arguments must be zero or positive
integers less than the total number of rows and columns respectively. The
values contained in the DOMTokenString object when the method
returns represent the classes that apply to that cell. If the method is
not defined, no classes apply to the cell.
progress class applies to the cell, it is a
progress bar. Otherwise, if the cyclable class applies to the cell, it is a
cycling cell whose value can be cycled between multiple states.
Otherwise, none of these classes apply, and the cell is a simple text
cell.
checked, unchecked, or indeterminate classes applies to the
cell. If any of these are present, then the cell has a checkbox,
otherwise none are present and the cell does not have a checkbox. If the
cell has no checkbox, check whether the editable class applies to the cell. If it
does, then the cell value is editable, otherwise the cell value is
static.
checked class applies to the cell. If it does,
the cell is checked. Otherwise, check whether the unchecked class applies to the cell. If it
does, the cell is unchecked. Otherwise, the indeterminate class appplies to the cell
and the cell's checkbox is in an indeterminate state. When the indeterminate class appplies to the
cell, the checkbox is a tristate checkbox, and the user can set it to the
indeterminate state. Otherwise, only the checked
and/or unchecked classes apply to the cell, and the
cell can only be toggled betwen those two states.
If the data provider ever raises an exception while the datagrid is invoking one of its methods, the
datagrid must act, for the purposes
of that particular method call, as if the relevant method had not been
defined.
The data model is considered stable: user agents may assume that
subsequent calls to the data provider methods will return the same data,
until one of the update methods is called on the datagrid element. If a user agent is returned
inconsistent data, for example if the number of rows returned by getRowCount() varies in ways that do not
match the calls made to the update methods, the user agent may disable the
datagrid. User agents that do not
disable the datagrid in inconsistent
cases must honour the most recently returned values.
User agents may cache returned values so that the data provider is never
asked for data that could contradict earlier data. User agents must not
cache the return value of the getRowMenu method.
The exact algorithm used to populate the data grid is not defined here, since it will differ based on the presentation used. However, the behaviour of user agents must be consistent with the descriptions above. For example, it would be non-conformant for a user agent to make cells have both a checkbox and be editable, as the descriptions above state that cells that have a checkbox cannot be edited.
datagridWhenever the data attribute is set to a new value, the datagrid must clear the current selection,
remove all the displayed rows, and plan to repopulate itself using the
information from the new data provider at the earliest opportunity.
There are a number of update methods that can be invoked on the datagrid element to cause it to refresh
itself in slightly less drastic ways:
When the updateEverything()
method is called, the user agent must repopulate the entire datagrid. If the number of rows decreased,
the selection must be updated appropriately. If the number of rows
increased, the new rows should be left unselected.
When the updateRowsChanged(row, count) method is
called, the user agent must refresh the rendering of the rows in the range
from row row to row row+count-1.
When the updateRowsInserted(row, count) method is
called, the user agent must assume that count new rows
have been inserted between what used to be row row-1
and row row. The user agent must update its rendering
and the selection accordingly. The new rows should not be selected.
When the updateRowsRemoved(row, count) method is
called, the user agent must assume that count rows
have been removed starting from row row. The user
agent must update its rendering and the selection accordingly.
The updateRowChanged(row) method must be exactly equivalent to
calling updateRowsChanged(row,
1).
When the updateColumnChanged(column) method is called, the user agent must
refresh the rendering of the specified column column,
for all rows.
When the updateCellChanged(row, column) method is
called, the user agent must refresh the rendering of the cell on row row, in column column.
Any effects the update methods have on the datagrid's selection is not considered a
change to the selection, and must therefore not fire the select event.
These update methods should only be called by the data provider, or code
acting on behalf of the data provider. In particular, calling the updateRowsInserted() and updateRowsRemoved() methods without
actually inserting or removing rows from the data provider is likely to
result in inconsistent renderings.
This section only applies to interactive user agents.
If the datagrid element has a disabled
attribute, then the user agent must disable the datagrid, preventing the user from
interacting with it. The datagrid
element should still continue to update itself when the data provider
signals changes to the data, though. Obviously, conformance requirements
stating that datagrid elements must
react to users in particular ways do not apply when one is disabled.
If a row is openable, then the user must be able
to toggle its open/closed state. When the user does so, then the datagrid must invoke the data provider's
toggleRowOpenState() method, with
the row's index as the only argument. The datagrid must then act as if the
datagrid's updateRowChanged() method had been
invoked with that row's index immediately before the provider's method was
invoked.
If a cell is a cell whose value can be cycled
between multiple states, then the user must be able to activate the
cell to cycle its value. When the user activates this "cycling" behaviour
of a cell, then the datagrid must
invoke the data provider's cycleCell() method, with the cell's row index
as the first argument and its column index as the second. The datagrid must then act as if the datagrid's updateCellChanged() method had been
invoked with those same arguments immediately before the provider's method
was invoked.
When a cell has a checkbox, the user must be
able to set the checkbox's state. When the user changes the state of a
checkbox in such a cell, the datagrid must invoke the data provider's
setCellCheckedState() method, with
the cell's row index as the first argument, its column index as the
second, and the checkbox's new state as the third. The state should be
represented by the number 1 if the new state is checked, 0 if the new
state is unchecked, and -1 if the new state is indeterminate (which must
only be possible if the cell has the indeterminate class set). The datagrid must then act as if the datagrid's updateCellChanged() method had been
invoked, specifying the same cell, immediately before the provider's
method was invoked.
If a cell is editable, the user must be able to
edit the data for that cell, and doing so must cause the user agent to
invoke the editCell() method of the data provider with
three arguments: the row number and column number of the cell, and the new
text entered by the user. The user agent must then act as if the updateCellChanged() method had been
invoked, with the same row and column specified.
This section only applies to interactive user agents. For other user
agents, the selection attribute must return null.
interface SelectedRowRanges {
readonly attribute long count;
long getRangeStart(in long index);
long getRangeLength(in long index);
void addRange(in long start, in long count);
void removeRange(in long index);
void setSelected(in long row, in boolean selected);
boolean isSelected(in long row);
void selectAll();
void invert();
void clear();
};
Each datagrid element must keep
track of which rows are currently selected. Initially no rows are
selected, but this can be changed via the methods described in this
section.
The selection of a datagrid is
represented by its selection DOM attribute,
which must be a SelectedRowRanges object.
The SelectedRowRanges
object represents the selection using ranges. Each range has a starting
index and a length. The starting index is relative to the first row (index
0) of the datagrid. The length
states how many of the rows are selected, starting from the starting
index. A range of length one implies that only the row indicated by its
starting index is selected.
The ranges in a selection must not overlap. Ranges may be adjacent (e.g. one range starting at index zero with length two, and a second range starting at index two) but user agents should coalesce adjacent ranges.
The start index of a range must not be negative, and must not be greater than the index of the last row. The length of a range must not be such that the range's start index plus its length yields a value greater than the number of rows.
The count attribute
must return the number of ranges currently present in the selection. The
getRangeStart()
and getRangeLength()
methods must return the starting index and length (respectively) of the
range specified by their argument. If the argument is out of range (less
than zero or greater than the number of ranges minus one), then they must
raise an INDEX_SIZE_ERR exception. [DOM3CORE]
The ranges must be returned in ascending numerical order. That is, the
value returned by the getRangeStart() method for an index x must always be greater than the value it returns for any
index less than x.
The addRange()
method takes two arguments, an index and a length, specifying a range of
rows to select. If the specified range is invalid or would contain rows
outside the datagrid (e.g. the
starting index is negative, or the length would take the selection beyond
the end of the datagrid), then the
method must raise an INDEX_SIZE_ERR exception. Otherwise, the
specified range must be added to the selection. If the range overlaps,
grows, or joins existing selections, the user agent must adjust the ranges
so that no two ranges overlap, and should adjust them so that no two
ranges are adjacent. Thus, calling addRange() may actually reduce the total
number of ranges in the selection.
The removeRange()
method takes two arguments, an index and a length, specifying a range of
rows to unselect. If the specified range is invalid or would contain rows
outside the datagrid (e.g. the
starting index is negative, or the length would take the selection beyond
the end of the datagrid), then the
method must raise an INDEX_SIZE_ERR exception. Otherwise, the
specified rows must be removed from the selection. Calling removeRange() may actually increase the
total number of ranges in the selection, e.g. if a range had to be split
in order to unselect a row in the middle.
The setSelected()
method takes two arguments, row and selected. When invoked, it must set the selection state of
row row to selected if selected is
true, and unselected if it is false, by adjusting the selection's ranges
accordingly. If row is less than zero or greater than
the index of the last row then the method must raise an
INDEX_SIZE_ERR exception.
The isSelected()
method must return the selected state of the row specified by its
argument. If the specified row exists and is in one of the ranges of the
selection, it must return true, otherwise it must return false.
The selectAll()
method must replace all the current ranges in the selection with a single
selection range having index zero and a length equal to the number of rows
in the datagrid. If there are no
rows in the datagrid then this
method must instead only remove all the current ranges. (In a compliant
UA, there would not be any ranges to remove.)
The invert() method
must adjust the selections such that the selection is inverted. That is,
the ranges must be adjusted such that only the rows that were previously
not a part of the selection must be made a part of the new selection.
The clear() method must
remove all the ranges in the selection.
If the datagrid element has a multiple
attribute, then the user must be able to select any number of rows (zero
or more). If the attribute is not present, then the user must only be able
to select a single row at a time, and selecting another one must unselect
all the other rows.
This only applies to the user. Scripts can select multiple
rows even when the multiple attribute is absent.
Whenever the selection of a datagrid changes, whether due to the user
interacting with the element, or as a result of calls to methods of the
selection object, a select
event that bubbles but is not cancelable must be fired on the datagrid element. If multiple changes are
made to the selection via calls to the object's methods during a single
execution of a script,
then the select
events should be coalesced into one (which later
fires once the script execution has completed).
The SelectedRowRanges interface has no
relation to the Selection and
Range interfaces.
This section only applies to interactive user agents.
Each datagrid element must keep
track of which columns are currently being rendered. User agents should
initially show all the columns except those with the initially-hidden class, but may allow
users to hide or show columns. User agents should initially display the
columns in the order given by the data provider, but may allow this order
to be changed by the user.
If columns are not being used, as might be the case if the data grid is being presented in an icon view, or if an overview of data is being read in an aural context, then the text of the first column of each row should be used to represent the row.
If none of the columns have any captions (i.e. if the data provider does
not provide a getCaptionText() method), then user
agents may avoid showing the column headers at all. This may prevent the
user from performing actions on the columns (such as reordering them,
changing the sort column, and so on).
Whatever the order used for rendering, and irrespective of
what columns are being shown or hidden, the "first column" as referred to
in this specification is always the column with index zero, and the "last
column" is always the column with the index one less than the value
returned by the getColumnCount() method of the data
provider.
If a column is sortable, then the user must
be able to invoke it to sort the data. When the user does so, then the
datagrid must invoke the data
provider's toggleColumnSortState() method,
with the column's index as the only argument. The datagrid must then act as if the
datagrid's updateEverything() method had been
invoked.
command elementMetadata element, and strictly inline-level content.
head element.
type
label
icon
hidden
disabled
checked
radiogroup
default
title attribute has special semantics on this
element.
interface HTMLCommandElement : HTMLElement { attribute DOMString type; attribute DOMString label; attribute DOMString icon; attribute boolean hidden; attribute boolean disabled; attribute boolean checked; attribute DOMString radiogroup; attribute boolean default; void click(); };
The Command
interface must also be implemented by this element.
The command element represents a
command that the user can invoke.
The type
attribute indicates the kind of command: either a normal command with an
associated action, or a state or option that can be toggled, or a
selection of one item from a list of items.
The attribute's value must be either "command",
"checkbox", or "radio",
denoting each of these three types of commands respectively. The attribute
may also be omitted if the element is to represent the first of these
types, a simple command.
The label
attribute gives the name of the command, as shown to the user.
The title
attribute gives a hint describing the command, which might be shown to the
user to help him.
The icon
attribute gives a picture that represents the command. If the attribute is
specified, the attribute's value must contain a URI.
The hidden attribute indicates,
if present, that the command is not relevant and is to be hidden. If
present, the attribute must have the exact value hidden.
The disabled attribute
indicates, if present, that the command is not available in the current
state. If present, the attribute must have the exact value disabled.
The distinction between Disabled State and Hidden State is subtle. A command should be Disabled if, in the same context, it could be enabled if only certain aspects of the situation were changed. A command should be marked as Hidden if, in that situation, the command will never be enabled. For example, in the context menu for a water faucet, the command "open" might be Disabled if the faucet is already open, but the command "eat" would be marked Hidden since the faucet could never be eaten.
The checked attribute
indicates, if present, that the command is selected. If present, the
attribute must have the exact value checked.
The radiogroup attribute
gives the name of the group of commands that will be toggled when the
command itself is toggled, for commands whose type attribute has
the value "radio". The scope of the name is the
child list of the parent element.
If the command element is used when
generating a context
menu, then the default attribute
indicates, if present, that the command is the one that would have been
invoked if the user had directly activated the menu's subject instead of
using its context menu.
Need an example that shows an element that, if
double-clicked, invokes an action, but that also has a context menu,
showing the various command
attributes off, and that has a default command.
The type,
label, icon, hidden, disabled,
checked,
radiogroup, and default DOM
attributes must reflect their
respective namesake content attributes.
The click()
method's behaviour depends on the value of the type attribute of
the element, as follows:
type attribute has the value checkbox
If the element has a checked attribute, the UA must remove that
attribute. Otherwise, the UA must add a checked
attribute, with the literal value checked. The UA
must then fire a click
event at the element.
type attribute has the value radio
If the element has a parent, then the UA must walk the list of child
nodes of that parent element, and for each node that is a command element, if that element has a radiogroup attribute whose value exactly
matches the current element's (treating missing radiogroup attributes as if they were the
empty string), and has a checked attribute, must remove that
attribute and fire a click
event at the element.
Then, the element's checked attribute attribute must be set to
the literal value checked and a click event must be fired at
the element.
The UA must fire a click
event at the element.
Firing a synthetic click
event at the element does not cause any of the actions described above to
happen.
Need to define the command="" attribute
command elements are
not rendered unless they form part of a menu.
menu elementBlock-level element, and structured inline-level element.
li elements, or inline-level content (but not both).
type
label
autosubmit
interface HTMLCommandElement : HTMLElement { attribute DOMString type; attribute DOMString label; attribute boolean autosubmit; };
The menu element represents a list of
commands.
The type
attribute indicates the kind of menu. It must have either the value popup (to declare a context menu) or the value toolbar (to define a tool bar). The attribute may also be
omitted, to indicate that the element is merely a list of commands that is
neither declaring a context menu nor defining a tool bar.
If a menu element has a type attribute with the
value popup, then it represents the commands of a
context menu, and the user can only interact with the commands if that
context menu is activated.
If a menu element has a type attribute with the
value toolbar, then it represents a list of active
commands that the user can immediately interact with.
Otherwise, if a menu element has no
type attribute,
or if has a type
attribute with a value other than popup or toolbar, then it either represents an unordered list of
items (each represented by an li element),
each of which represents a command that the user may perform or activate,
or, if the element has no li element
children, a paragraph describing
available commands.
The label
attribute gives the label of the menu. It is used by user agents to
display nested menus in the UI. For example, a context menu containing
another menu would use the nested menu's label attribute for the submenu's menu label.
The autosubmit attribute
indicates whether selections made to form controls in this menu should
result in the control's form being immediately submitted. If the attribute
is present, its value must be autosubmit.
If a change event bubbles through a
menu element, then, in addition to any
other default action that that event might have, the UA must act as if the
following was an additional default action for that event: if (when it
comes time to execute the default action) the menu element has an autosubmit
attribute, and the target of the event is an input element,
and that element has a type attribute
whose value is either radio or checkbox, and the input element in question
has a non-null form DOM attribute,
then the UA must invoke the submit()
method of the form element indicated by that DOM attribute.
The processing model for menus is described in the next section.
This section will end up defining what the UA should
do when the user clicks a link. This will probably involve being honest
about the fact that UAs typically content sniff for RSS/Atom feeds at this
point. It should also reference the registerProtocolHandler and
registerContentHandler methods
and their stuff.
A command is the abstraction behind menu items, buttons, and links. Once a command is defined, other parts of the interface can refer to the same command, allowing many access points to a single feature to share aspects such as the disabled state.
Commands are defined to have the following facets:
Commands are represented by elements in the DOM. Any element that can
define a command also implements the Command interface:
interface Command {
readonly attribute DOMString commandType;
readonly attribute DOMString id;
readonly attribute DOMString label;
readonly attribute DOMString title;
readonly attribute DOMString icon;
readonly attribute boolean hidden;
readonly attribute boolean disabled;
readonly attribute boolean checked;
void click();
readonly attribute HTMLCollection triggers;
readonly attribute Command command;
};
The Command
interface is implemented by any element capable of defining a command. (If
an element can define a command, its definition will list this interface
explicitly.) All the attributes of the Command interface are read-only. Elements
implementing this interface may implement other interfaces that have
attributes with identical names but that are mutable; in bindings that
simply flatten all supported interfaces on the object, the mutable
attributes must shadow the readonly attributes defined in the Command interface.
The commandType
attribute must return a string whose value is either "command", "radio", or "checked", depending on whether the Type of the
command defined by the element is "command", "radio", or "checked"
respectively. If the element does not define a command, it must return
null.
The id
attribute must return the command's ID, or null if the element does not define a
command or defines an anonymous
command. This attribute will be shadowed by the id DOM attribute on the HTMLElement interface.
The label attribute must
return the command's Label, or null if the element does not define a
command or does not specify a Label. This attribute will be shadowed by the
label DOM attribute on option and
command elements.
The title attribute must
return the command's Hint, or null if the element does not define a
command or does not specify a Hint. This attribute will be shadowed by the title DOM attribute on the
HTMLElement interface.
The icon
attribute must return an absolute URI to the command's Icon. If the
element does not specify an icon, or if the element does not define a
command, then the attribute must return null. This attribute will be
shadowed by the icon DOM attribute on command elements.
The hidden attribute must
return true if the command's Hidden State is that the command is hidden, and
false if it is that the command is not hidden. If the element does not
define a command, the attribute must return false. This attribute will be
shadowed by the hidden DOM attribute on command elements.
The disabled attribute must
return true if the command's Disabled State is that the command is
disabled, and false if the command is not disabled. This attribute is not
affected by the command's Hidden State. If the element does not define a
command, the attribute must return false. This attribute will be shadowed
by the disabled attribute on button,
input, option, and command elements.
The checked attribute must
return true if the command's Checked State is that the command is checked,
and false if it is that the command is not checked. If the element does
not define a command, the attribute must return false. This attribute will
be shadowed by the checked attribute on
input and command
elements.
The click() method must
trigger the Action for the command. If the element does not
define a command, this method must do nothing. This method will be
shadowed by the click() method on
button, input, and command elements.
The triggers attribute must
return a list containing the elements that can trigger the command (the
command's Triggers). The list must be live. While the element does not define a command,
the list must be empty.
All the commands that have IDs must be in the list returned by the commands
attribute of the document's DocumentWindow interface. The collection
represented by this attribute is live; as
commands are defined in or removed from the document, the attribute is
updated.
The following elements may define commands: a, button, input, option, command.
a element to define a
commandAn a element with an href attribute defines a command.
The Type of the command is "command".
The ID of the
command is the value of the id attribute of the element, if the attribute is
present and not empty. Otherwise the command is an anonymous command.
The Label
of the command is the string given by the element's textContent DOM attribute.
The Hint of
the command is the value of the title attribute of the a element. If the attribute is not present, the
Hint is the
empty string.
The Icon of
the command is the absolute URI of the first image in the element.
Specifically, in a depth-first search of the children of the element, the
first element that is img element with a src
attribute
is the one that is used as the image.
The URI must be taken
from the element's src attribute.
Relative URIs must be resolved relative to the base URI of the image
element.
If no image is found, then the Icon facet is left blank.
The Hidden State and Disabled State facets of the command are always false. (The command is always enabled.)
The Checked State of the command is always false. (The command is never checked.)
The Action of the command is to fire a click
event at the element.
button element to define a
commandA button element always defines a command.
The Type,
ID, Label, Hint, Icon, Hidden
State, Checked State, and Action facets of
the command are determined as
for a elements (see the previous section).
The Disabled State of the command mirrors the
disabled state of the button. Typically this is given by the element's
disabled attribute, but certain
button types become disabled at other times too (for example, the
move-up button type is disabled when it would have no
effect).
input element to define a
commandAn input element whose type attribute is one of
submit, reset, button,
radio, checkbox, move-up,
move-down, add, and remove defines a command.
The Type
of the command is "radio" if the type
attribute has the value radio, "checkbox" if the
type attribute has the value checkbox, and
"command" otherwise.
The ID of the
command is the value of the id attribute of the element, if the attribute is
present and not empty. Otherwise the command is an anonymous command.
The Label of the command depends on the Type of the command:
If the Type is "command", then it is the string given
by the value attribute, if any, and
a UA-dependent value that the UA uses to
label the button itself if the attribute is absent.
Otherwise, the Type is "radio" or "checkbox". If the element
has a label element associated with it, the textContent of the first such element is
the Label
(in DOM terms, this the string given by
element.labels[0].textContent). Otherwise, the
value of the value attribute, if
present, is the Label. Otherwise, the Label is the
empty string.
The Hint of
the command is the value of the title attribute of the input
element. If the attribute is not present, the Hint is the empty
string.
There is no Icon for the command.
The Hidden State of the command is always false. (The command is never hidden.)
The Disabled State of the command mirrors the
disabled state of the control. Typically this is given by the element's
disabled attribute, but certain
input types become disabled at other times too (for example, the
move-up input type is disabled when it would have no effect).
The Checked
State of the command is true if the command is of Type "radio" or
"checkbox" and the element has a checked attribute, and false otherwise.
The Action of the command is to fire a click
event at the element.
option element to define a
commandAn option element with an ancestor select
element and either no value attribute
or a value attribute that is not the
empty string defines a
command.
The Type
of the command is "radio" if the option's nearest ancestor
select element has no multiple attribute, and "checkbox" if
it does.
The ID of the
command is the value of the id attribute of the element, if the attribute is
present and not empty. Otherwise the command is an anonymous command.
The Label
of the command is the value of the option element's label attribute, if there is one, or the
value of the option element's textContent DOM attribute if it doesn't.
The Hint of
the command is the string given by the element's title attribute, if any,
and the empty string if the attribute is absent.
There is no Icon for the command.
The Hidden State of the command is always false. (The command is never hidden.)
The Disabled State of the command is true
(disabled) if the element has a disabled attribute, and false
otherwise.
The Checked
State of the command is true (checked) if the element's selected DOM attribute is true, and
false otherwise.
The Action of the command depends on its Type. If the
command is of Type "radio" then this must set the selected DOM attribute of the
option element to true, otherwise it must toggle the state of
the selected DOM attribute (set
it to true if it is false and vice versa). Then a change event must be
fired on the option element's nearest ancestor
select element (if there is one), as if the selection had
been changed directly.
command element
to define a commandA command element defines a command.
The Type
of the command is "radio" if the command's type attribute is "radio",
"checkbox" if the attribute's value is "checkbox", and
"command" otherwise.
The ID of the
command is the value of the id attribute of the element, if the attribute is
present and not empty. Otherwise the command is an anonymous command.
The Label
of the command is the value of the element's label attribute, if
there is one, or the empty string if it doesn't.
The Hint of
the command is the string given by the element's title attribute,
if any, and the empty string if the attribute is absent.
The Icon
for the command is the absolute URI resulting from resolving the value of
the element's icon attribute as a URI relative to the element's
base URI. If the element has no icon attribute then the command has no Icon.
The Hidden
State of the command is true (hidden) if the element has a
hidden
attribute, and false otherwise.
The Disabled State of the command is true
(disabled) if the element has either a disabled
attribute or a hidden attribute (or both), and false otherwise.
The Checked
State of the command is true (checked) if the element has a
checked
attribute, and false otherwise.
The Action of the command is to invoke the behaviour
described in the definition of the click() method of the HTMLCommandElement interface.
See WF2 for now
See WF2 for now
...
A menu consists of a list of zero or more of the following components:
The list corresponding to a particular element is built by iterating over its child nodes.
For each child node in document order, the required behaviour depends on what the node is, as follows:
command element with a default
attribute, mark the command as being a default command.
hr element
option element that has a value attribute set to the empty string,
and has a disabled attribute,
and whose textContent consists
of a string of one or more hyphens (U+002D HYPHEN-MINUS)
li element
li
element.
menu element with no label attribute
select element
menu or select element,
then append another separator.
menu element with a label attribute
optgroup element
label attribute as the label of the menu. The submenu
must be constructed by taking the element and creating a new menu for it
using the complete process described in this section.
Once all the nodes have been processed as described above, the user agent must the post-process the menu as follows:
The contextmenu attribute associates an element
with a menu element.
When an element's context menu is requested (e.g. by the user
right-clicking the element, or pressing a context menu key), the UA must
fire a contextmenu
event on the element for which the menu was requested.
Typically, therefore, the firing of the contextmenu event will be the default
action of a mouseup or keyup event. The exact sequence of events is
UA-dependent, as it will vary based on platform conventions.
The default action of the contextmenu event depends on whether the
element has a context menu assigned (using the contextmenu
attribute) or not. If it does not, the default action must be for the user
agent to show its default context menu, if it has one.
If the element does have a context menu assigned, then the user
agent must fire a show
event on the relevant menu
element.
The default action of this event is that the user agent must
show a context menu built from the menu element.
The user agent may also provide access to its default context menu, if any, with the context menu shown. For example, it could merge the menu items from the two menus together, or provide the page's context menu as a submenu of the default menu.
If the user dismisses the menu without making a selection, nothing in particular happens.
If the user selects a menu item that represents a command, then the UA must invoke that command's Action, as defined above.
Context menus must not, while being shown, reflect changes in the DOM;
they are constructed as the default action of the show event and must remain like that until
dismissed.
User agents may provide means for bypassing the context menu processing
model, ensuring that the user can always access the UA's default context
menus. For example, the user agent could handle right-clicks that have the
Shift key depressed in such a way that it does not fire the contextmenu event and instead always
shows the default context menu.
Toolbars are a kind of menu that is always visible.
When a menu element has a type attribute with the
value toolbar, then the user agent must build the menu for
that menu element and render it in the document
in a position appropriate for that menu
element.
The user agent must reflect changes made to the menu's DOM immediately in the UI.
See WF2 for now
Web browsers and other user agents that display HTML documents to the user in the context of a browsing environment may display one or more views of those documents to the user.
Each set of one or more views is considered a browsing context.
In a tabbed Web browser, for instance, each tab in the browser window represents a browsing context.
A browsing context may have
further browsing contexts nested within it; the iframe
element, for instance, instantiates a browsing
context within the context of a parent document. The lifetime
of a nested browsing context is bounded by the lifetime of
the document in which it lives, or by the UA if the browsing context does not have a parent
document.
A browsing context that does not have a parent document or browsing context is the top-level browsing context for any browsing contexts nested within it (and their documents).
Each browsing context must have a
single unique session history,
consisting of one or more documents, each represented by an object
implementing the DocumentWindow
interface.
A document can have more than one entry in the session history of a particular browsing
context. All the entries related to a particular DocumentWindow object are contiguous.
Each view of each document in a browsing
context must be represented by an object implementing the
Window interface. In each set of such
objects there is a default view, represented by
one of the Window objects, which is the
primary output mode of the document (and, for interactive user agents,
nominally the user's primary way of interacting with the document).
When a UI event is fired, the view attribute of
the UIEvent object must point to the Window object representing the view in which the
user triggered the event.
Typically Web browsers only have one view per document, but a Web browser that rendered document to a screen while simultaneously providing a speech synthesis version would be one example where two views were present.
It would be good to have a summary or diagram for the above relationships.
DocumentWindow interfaceThe DocumentWindow interface
extends the DocumentView interface defined in DOM2 Views. [DOM2VIEWS]
Every Document object that is being rendered in a browsing context must implement the DocumentWindow interface.
interface DocumentWindow : DocumentView { // helper objects attribute Location location; /* performs magic on setting */ Selection getSelection(); readonly attribute HTMLCollection commands; // editing attribute boolean designMode; boolean execCommand(in DOMString commandID); boolean execCommand(in DOMString commandID, in boolean doShowUI); boolean execCommand(in DOMString commandID, in boolean doShowUI, in DOMString value); };
The domain of a
DocumentWindow object is the domain given by the
hostname attribute of the Location object returned by the DocumentWindow object's location
attribute, if that hostname attribute is not the
empty string. If it is, the domain of the document
is UA-defined. For now.
The domain of a script
is the domain of the
DocumentWindow object that is returned by the
document attribute of the script's
primary Window object (in UAs that
implement ECMAScript, that is the global
scope object).
The the string representing the script's domain in IDNA format is obtained as follows: take the script's domain and apply the IDNA ToASCII algorithm and then the IDNA ToUnicode algorithm to each component of the domain name (with both the AllowUnassigned and UseSTD3ASCIIRules flags set both times). [RFC3490] If ToASCII fails to convert one of the components of the string, e.g. because it is too long or because it contains invalid characters, then the string representing the script's domain in IDNA format cannot be obtained. (ToUnicode is defined to never fail.)
Window interfaceThe Window interface extends the
AbstractView interface defined in DOM2 Views. [DOM2VIEWS]
interface Window : AbstractView { // self-reference readonly attribute Window window; // timers long setTimeout(in TimeoutHandler handler, in long timeout); long setTimeout(in TimeoutHandler handler, in long timeout, arguments...); long setTimeout(in DOMString code, in long timeout); long setTimeout(in DOMString code, in long timeout, in DOMString language); void clearTimeout(in long handle); long setInterval(in TimeoutHandler handler, in long timeout); long setInterval(in TimeoutHandler handler, in long timeout, arguments...); long setInterval(in DOMString code, in long timeout); long setInterval(in DOMString code, in long timeout, in DOMString language); void clearInterval(in long handle); // convenient event handlers attribute ErrorHandler onerror; // helper objects readonly attribute History history; attribute Location location; /* performs magic on setting */ readonly attribute Storage sessionStorage; readonly attribute StorageList globalStorage; readonly attribute ClientInformation navigator; readonly attribute UndoManager undoManager; Selection getSelection(); }; interface TimeoutHandler { void handleEvent(arguments...); }; interface ErrorHandler { void handleEvent(in DOMString errorMessage, in DOMString fileName, in DOMString lineNumber); };
Objects implementing the Window
interface must also implement the EventTarget interface.
In UAs that expose the DOM to ECMAScript [ECMA262] scripts, the global scope object must
implement the Window interface
described above.
The window
attribute of an object implementing the Window interface must always point to the object
itself. In other words, the following equality must also always hold:
x.window == x
...where x is an object implementing the Window interface.
Thus, in ECMAScript, the ECMAScript global object must have a property
window pointing at
the global object itself.
The document attribute inherited from the
AbstractView interface must return the document associated
with this view.
We need a section to define how events all work, default actions, etc. For example, how does clicking on a span in a link that is in another link actually cause a link to be followed? which one? (where should this section be?)
This entire section will be merged with earlier sections in due course.
When an element is focused, key events are targetted at that element instead of at the document's root element.
tabindex AttributeThis section on the tabindex attribute needs to be checked for
backwards-compatibility.
The tabindex attribute defined in
HTML4 is extended to apply to all HTML elements by defining it as a common
attribute.
The tabindex attribute specifies
the relative order of elements for the purposes of sequential focus
navigation. The name "tab index" comes from the common use of the "tab"
key to navigate through the focusable elements. The term "tabbing" refers
to moving forward through the focusable elements.
The tabindex attribute can take
any integer (an optional U+002D HYPHEN-MINUS representing negativity
followed by one or more digits in the range 0-9, U+0030 to U+0039,
interpreted as base ten).
A positive integer (including zero) specifies the index of the element in the current scope's tab order. Elements with the same index are sorted in document order for the purposes of tabbing.
A negative integer specifies that the element should be removed from the tab order. If the element does normally take focus, it may still be focused using other means (e.g. it could be focussed by a click).
Other values are ignored, as if the attribute was absent. Certain
elements may default absent tabindex
attributes to zero, at the user agent's discretion. (In other words, some
elements are focusable by default, and they are assumed to have tab index
0. Text fields will typically be in the tab order by default, for
instance.)
When an element that does not normally take focus has the tabindex attribute specified with a positive
value, then it is added to the tab order and is made focusable. When
focused, the element matches the CSS :focus pseudo-class and key events are
dispatched on that element when appropriate, just like focusing a link.
Since all HTML elements can thus be focused and unfocusd, the
onfocus and onblur attributes shall also apply
to all HTML elements.
ElementFocus interfaceThe ElementFocus interface
contains methods for moving focus to and from an element. It can be
obtained from objects that implement the Element interface
using binding-specific casting methods.
interface ElementFocus {
attribute long tabIndex;
void focus();
void blur();
};
The tabIndex DOM attribute
reflects the value of the related content attribute. If the attribute is
not present (or has an invalid value) then the DOM attribute should return
the UA's default value for that element, typically either 0 (for elements
in the tab order) or -1 (for elements not in the tab order).
The focus() and blur() methods focus and unfocus the element
respectively, if the element is focusable.
DocumentFocus interfaceThe DocumentFocus interface
contains methods for moving focus around the document. It can be obtained
from objects that implement the Document interface using
binding-specific casting methods.
interface DocumentFocus {
readonly attribute Element currentFocus;
void moveFocusForward();
void moveFocusBackward();
void moveFocusUp();
void moveFocusRight();
void moveFocusDown();
void moveFocusLeft();
};
The currentFocus attribute
returns the element to which key events will be sent when the document
receives key events.
The moveFocusForward
method uses the 'nav-index' property and the tabindex attribute to find the next focusable
element and focuses it.
The moveFocusBackward
method uses the 'nav-index' property and the tabindex attribute to find the previous
focusable element and focuses it.
The moveFocusUp method uses the
'nav-up' property and the tabindex attribute to find an appropriate
focusable element and focuses it.
In a similar manner, the moveFocusRight, moveFocusDown, and moveFocusLeft methods use the
'nav-right', 'nav-down', and
'nav-left' properties (respectively), and the tabindex attribute, to find an appropriate
focusable element and focus it.
The 'nav-index', 'nav-up',
'nav-right', 'nav-down', and
'nav-left' properties are defined in [CSS3UI].
The onerror attribute takes a
reference to an object implementing the ErrorHandler interface. In
ECMAScript, such an interface is implemented by any function that takes
three arguments and returns a boolean value, as well as by the
null value and the undefined value.
The function to which the onerror
attributes points must be invoked whenever a runtime script error occurs
in the context of the window object, before the error is reported to
the user. If the function is null or if the function returns
true then the error should not reported to the user. If the function is
undefined or if the function doesn't returns true, then the
message must be reported as normal.
The three arguments passed to the function are all
DOMStrings; the first gives the message that the UA is
considering reporting, the second gives the URI to the resource in which
the error occured, and the third gives the line number in tha resource on
which the error occured.
The initial value of onerror must be
undefined.
The setTimeout and setInterval methods allow authors to
schedule timer-based events.
The setTimeout(handler, timeout[, arguments...]) method takes a reference to a
TimeoutHandler object and a
length of time in milliseconds. It must return a handle to the timeout
created, and then asynchronously wait timeout
milliseconds and then invoke handleEvent() on the handler object. If any arguments...
were provided, they must be passed to the handler as
arguments to the handleEvent() function.
In the ECMAScript DOM binding, the ECMAScript native
Function type must implement the TimeoutHandler interface such that
invoking the handleEvent() method of that interface on the
object from another language binding invokes the function itself, with the
arguments passed to handleEvent() as the arguments passed to
the function. In the ECMAScript binding itself, however, the
handleEvent() method of the interface is not directly
accessible on Function objects. Such functions must be called
in the global scope.
Alternatively, setTimeout(code, timeout[, language])