[This local archive copy is from the official and canonical URL, http://toocan.philabs.research.philips.com/misc/atsc/bhtml/bhtml_4.html; please refer to the canonical source document if possible.]
This specification is currently in DRAFT form. The language specified is based on work prepared for the Advanced Television Systems Committee (ATSC). The ATSC T3/S17 specialist group is in the process of defining the application programming interfaces for a Digital Television Application Software Environment (DASE) compliant receiver.
xHTML specifies a collection of document type definition (DTD) sets that can be combined to specify an xHTML-based platform. Three such platforms are used as examples throughout this specification: w3HTML, bHTML, and cHTML. The w3HTML platform provides support full World Wide Web (WWW) connectivity. The bHTML platform provides a profile for TV-centric products. The cHTML platform provides a compact profile for appliance-oriented products.
This design allows content developers to author content for a variety of platforms and for consumer electronics manufacturers to develop a range of platforms, some with full World Wide Web operability.
The ATSC technical specialist group T3/S17 is defining the software application environment for broadcast digital television (DTV) receivers. T3/S17 (also known as DASE, DTV application software environment) has identified a reference architecturethat specifies an application execution engine, presentation engine, content decoders, and other system services.
T3/S17 selected the Java virtual machine (VM) as the application execution engine. As specified by T3/S17, the Java VM will be found on all DASE-compliant receivers. Procedural applications written in Java will be able to execute on a DASE compliant receiver and access system services through Java based application programming interfaces (APIs). These system services include a presentation service that allows a Java application to draw directly to the screen.
T3/S17 also solicited proposals for the presentation engine (a declarative language machine). In the ensuing discussions, the specialist group was greatly divided between the two HTML-based proposals and a MHEG proposal. Unfortunately, the two sides of the HTML and MHEG debate were along industry lines, which did not bode well for reconciliation. The primary concerns of the consumer electronic manufacturers was that the HTML based proposals were too costly to implement, were less demonstrably integrated than the MHEG proposal, and forced consumer electronic manufacturer's to build Internet connectivity into all of their products.
This latter point is often misunderstood or under-appreciated by non-consumer electronics manufacturers. Consumer manufacturers desire to build a variety of difference products that provide a variety of functions to consumers at a variety of price points. Only by having a variety of products can the consumer electronics manufacturer's better establish a value for the price (and cost) of a feature. In addition, product differentiation between their own products and between competitor's products is quite desireable.
Aninda DasGupta, the T3/S17 chairman, proposed an alternative he called "Broadcast HTML". This alternative uses Internet technologies favored by many T3/S17 members: it is written in XML, scales back HTML elements and attributes, and integrates synchronization functionality as new elements, attributes, and style properties.
This document specifies a language that may serve as the foundation for BHTML. The language is modular so that consumer electronic manufacturer's may deliver a range of products with varying levels of Internet connectivity.
Element names are written in uppercase letters (e.g.,BODY). Attribute names are written in lowercase letters (e.g., lang). xHTML is written in XML, therefore element names are case-sensitive. On implementation, all elements and attributes will use lowercase.
While this document intends to be a full specification, many readers are solely interested in the differences between this specification and HTML 4.0. The differences are summarized in the following sections:
Still others are more interested in understanding the Broadcast HTML Profile (bHTML). The following sections summarize bHTML:
Comments and criticism may be directed to:
Ted Wugofski Over the Moon Productions, Inc. 669 Airport Freeway #200 Hurst TX 76053 Email:ted.wugofski@otmp.com Voice:+1 817 285-1853
This specification has had contributions and critiques from a number of individuals. A special thanks to Joseph Cozad (Motorola), Aninda DasGupta (Philips), Warner ten Kate (Philips), Chris Marrin (Sony), Petr Peterka (General Instruments), Dave Raggett (Hewlett-Packard and the W3C), Dave Reynolds (Hewlett-Packard), and David Rivas (Sun).
Copyright © 1998 Over the Moon Productions, Inc. (A wholly owned subsidiary of Gateway). All Rights Reserved.
Portions Copyright © 1997 World Wide Web Consortium, (Massachusetts Institute of Technology, Institut National de Recherche en Informatique et en Automatique, Keio University). All Rights Reserved.
THIS DOCUMENT IS PROVIDED "AS IS," AND COPYRIGHT HOLDERS MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-INFRINGEMENT, OR TITLE; THAT THE CONTENTS OF THE DOCUMENT ARE SUITABLE FOR ANY PURPOSE; NOR THAT THE IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. COPYRIGHT HOLDERS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF ANY USE OF THE DOCUMENT OR THE PERFORMANCE OR IMPLEMENTATION OF THE CONTENTS THEREOF.
The name and trademarks of copyright holders may NOT be used in advertising or publicity pertaining to this document or its contents without specific, written prior permission. Title to copyright in this document will at all times remain with copyright holders.
Throughout this document, three profiles of xHTML will be used as examples of how to apply the modular HTML concept:
Each of these profiles differs by the DTD sets it includes and, to a lesser degree, the elements in a DTD set that it supports. The author would prefer that they only differed in terms of the DTD sets they support, but experience suggests that some tailoring of the elements is often required or appropriate due to platform novelties.
While not addressed in this document, a similar subset-ing and profiling should occur regarding style information. xHTML assumes support for external style information (such as cascading style sheets). Subsequently, xHMTL has reduced the amount of style information specified through attributes.
This specification identifies the following DTD sets:
These sets are discussed in greater detail in subsequent sections of this document.
In addition to these sets, the later draft will contain definition of the following DTD sets:
An xHTML profile specifies the DTD sets it includes and includes additional DTD information that identifies the elements within a DTD it supports.
The w3HTML profile supports all of the xHTML DTD sets. The intent of the w3HTML profile is to provide full World Wide Web connectivity.
The w3HTML profile described in this document is based on the HTML 4.0 specification.
The bHTML profile supports the following DTD sets:
The bHTML profile does not support the docset, frameset, or tableset. In addition, there are some minor changes in the elements supported. For example, bHTML only supports the first three levels of headings (H1, H2, and H3).
The bHTML profile described in this document is based on the "Broadcast HTML" proposal currently under evaluation by the ATSC T3/S17 DASE specialist group.
The cHTML profile supports the following DTD sets:
The cHTML profile does not support the docset, eventset, fontset, frameset, or tableset. The cHTML profile described in this document is based on the "Compact HTML for Small Information Appliances" submission to the W3C.
xHTML is designed to meet the requirements of consumer electronic and computer manufacturers that wish to produce a broad range of products with various levels of Internet connectivity and product features. It is designed based on the following five principals.
xHTML started with HTML 4.0 and HTML 3.2. These elements and attributes were converted to XML, in line with the stated goals of the W3C for future HTML. Then, elements and attributes were added as necessary to meet the needs of interactive television applications, and elements and attributes that were redundant (with other HTML elements and attributes or style information) were removed.
The XML-based markup language was partitioned into DTD sets that correlated with the needs of platform developers to differentiated based on internet connectivity, memory footprint, and power management.
One of the greatest differences between consumer electronics platforms is the nature of the display devices. Computers typically display on a progressive scan monitor, set-top boxes typically display on a interlaced television, and information appliances typically display on a small black and white LCD.
In addition to different display devices, platforms typically differ based on the how the user interacts. Computers typically have a mouse and a full function keyboard, set-top boxes typically have a remote control with constrained navigation keys or cursors, and information appliances have fewer navigation keys still.
Consumer electronics manufacturers would like to deliver a range of products. Some of these devices will have no return channel to the Internet. Other devices many only have a "batch" mode return to the Internet. Still other will have full-time real-time Internet connectivity. xHTML was designed to support these different levels of Internet connectivity.
The definition of xHTML was based on these principals.
The xHTML is based on HTML 4.0. The DTD sets described above identify how the elements were partitioned. In addition, the following elements were removed:
See the appendix on xHTML Style Properties for additional information on style. The deprecation of MAP in favor of A is addressed in the section on the A element.
xHTML adds the following elements to HTML 4.0, described in detail in following sections:
xHTML adds the following attributes to existing HTML 4.0 elements:
The following sections specify the elements for each DTD set. The examples given are for the full featured DTD, profiles are likely to reduce the DTD.
For example, the A element is specified as:
<!ENTITY % a.elements "(#PCDATA | %phrase | %formctrl | object | br | event | sub | sup | span | bdo)*"> <!ELEMENT a %a.elements -- anchor --> <!ATTLIST a %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of content -- charset %charset #IMPLIED -- char encoding of linked resource -- type %contenttype #IMPLIED -- content type of linked resource -- name CDATA #IMPLIED -- named link end -- href %uri #IMPLIED -- URI for linked resource -- hreflang %languagecode #IMPLIED -- language of linked resource -- rel %linktypes #IMPLIED -- forward link types -- rev %linktypes #IMPLIED -- reverse link types -- restrict CDATA #IMPLIED -- restrict links from fwd links -- >
In the bHTML DTD, the "%a.elements" entity is defined as:
<!ENTITY % a.elements "(#PCDATA | %phrase | %formctrl | object | br | event span)*">
<!ENTITY % a.elements "(#PCDATA | %formctrl | object | br | span)*">
See Appendix A for the core DTD entities, elements, and attributes. The contents of the appendix and the contents of Appendix B define the Broadcast HTML DTD; likewise with Appendix C for the Compact HTML DTD and Appendix D for the w3HTML DTD.
The Coreset elements are those elements supported by all xHTML profiles. They generally consist of elements related to the global structure of a xHTML document, hyperlinking, and embedded content (objects).
<!ENTITY % core.attr
"id %ID #IMPLIED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #IMPLIED"
>
<!ENTITY % i18n.attr
"lang %languagecode #IMPLIED
dir (ltr|rtl) #IMPLIED"
>
Attribute definitions
Many of the xHTML share a set of common attributes. These attributes pertain to element identification, style, and internationalization.
The id attribute assigns a name to an element. This element must be unique in the document, and in the case of persistent objects, must be unique within its scope of persistence.
The class attribute assigns a class name or set of class names to an element. The class name can be used to associate style information to one or more elements. In the following example, the DIV element and the class attribute are used to render and synchronize a document:
<bhtml>
<head>
<title>NBC Nightly News</title>
<style>
p.splash { color: white; font-family: nbc-font }
div.titles { begin: 5000; synctype: par; sync: frame }
</style>
</head>
<body>
<p class="splash" style="font-size: 18">NBC Nightly News</p>
<div class="titles">
<object data="dtv:/1234/009F/data" type="image/png"/>
<p class="splash" style="font-size: 10">with Tom Brokaw</p>
</div>
</body>
</bhtml>
Unlike the TITLE element defined below, which provides information about an entire document and may only appear once, the title attribute may annotate any number of elements.
Values of the title attribute may be rendered by user agents in a variety of ways. For instance, visual browsers frequently display the title information as a "tool tip" (a short message that appears when the pointing device pauses over an object).
The style attribute specifies style information for a single element. The style sheet language of inline style rules is given by the default style sheet language. The syntax of style data depends on the style sheet language.
The lang attribute's value is a language code that identifies a natural language spoken, written, or otherwise used for the communication among people. Computer languages are explicitly excluded from language codes.
The dir attribute specifies the base direction of neutral text (i.e., text that does not have inherent directionality as defined in UNICODE and the directionality of tables).
In addition to specifying the language of a document with the lang attribute, content develoeprs may need to specify the base directionality (left-to-right or right-to-left) of portions of a document's text, of table structure, etc. This is done with the dir attribute.
The Unicode specification assigns directionality to characters and defines a (complex) algorithm for determining the proper directionality of text. If a document does not contain a displayable right-to-left character, a conforming user agent is not required to apply the Unicode bidirectional algorithm. If a document contains right-to-left characters, and if the user agent displays these characters, the user agent must use the bidirectional algorithm.
Although Unicode specifies special characters that deal with text direction, xHTML offers higher-level markup constructs that do the same thing: the dir attribute (do not confuse with the DIR element) and the BDO element. Thus, to express a Hebrew quotation, it is more intuitive to write
<blockquote lang="he" dir="rtl">...a Hebrew quotation...</blockquote>
than the equivalent with Unicode references:
״...a Hebrew quotation...״
User agents must not use the lang attribute to determine text directionality.
The dir attribute is inherited and may be overridden. Please consult the section on the inheritance of text direction information for details.
<!ENTITY % a.elements "(#PCDATA | %phrase | %formctrl | object | br | event | sub | sup | span | bdo)*"> <!ELEMENT a %a.elements -- anchor --> <!ATTLIST a %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of content -- charset %charset #IMPLIED -- char encoding of linked resource -- type %contenttype #IMPLIED -- content type of linked resource -- name CDATA #IMPLIED -- named link end -- href %uri #IMPLIED -- URI for linked resource -- hreflang %languagecode #IMPLIED -- language of linked resource -- rel %linktypes #IMPLIED -- forward link types -- rev %linktypes #IMPLIED -- reverse link types -- restrict CDATA #IMPLIED -- restrict links from fwd links -- >
Attribute definitions
Attributes defined elsewhere
Each A element defines an anchor:
Content developers may also create an A element that specifies no anchors, i.e., that doesn't specify href, name, or id. Values for these attributes may be set at a later time through procedural applications.
Style sheets can be used to associate a hyperlink to spatial subparts of an element. For example:
<object type="video/quicktime" ...> <a href="./intro.html" style="coords: 0% 0% 50% 50%" /> <a href="./goodbye.html" style="coords: 50% 50% 100% 100%" /> </object>
splits the video into two regions and associates a different hyperlink with each region. In a second example:
<object type="video/quicktime" ...> <a href="./intro.html" style="begin: 0s; end: 5s" /> <a href="./goodbye.html" style="begin: 5s; end: 10s" /> </object>
the video object is divided into two subintervals with a different hyperlink associated with each subinterval. The style properties are described in Appendix D, Broadcast Style Sheets.
The default behavior associated with a link is the retrieval or downloading of another xHTML related resource. This behavior is commonly and implicitely obtained by selecting the link (e.g., by clicking, through the remote control, keyboard input, etc.). The EVENT element also provides a mechanism for linking in response to events.
The following xHTML expert contains two links, one whose destination anchor is a xHTML document named "scene2.html" and the other whose destination anchor is a GIF image in the file "forest.gif":
<body> ...some text... <p>You find a lot more in <a href="scene2.html">chapter two</a>. See also this <a href="../images/forest.gif">map of the enchanted forest.</a></p>
By activating these links, users may visit these resources. Note that the href attribute in each source anchor specifies the address of the destination anchor with a URI.
The destination anchor of a link may be an element within a xHTML document. The destination anchor must be given an anchor name and any URI addressing this anchor must include the name as its fragment identifier.
Destination anchors in xHTML documents may be specified either by the A element (naming it with the name attribute) or by any other element (naming with the id attribute).
Thus, for example, an author might create a table of contents whose entries link to header elements H2, H3, etc., in the same document. Using the A element to create destination anchors, we would write:
<h1>Table of Contents</h1> <p><a href="#section1"gt;Introduction</a></p><br/> <p><a href="#section2">Some background</a></p><br/> <p><a href="#section2.1">On a more personal note</a></p><br/> ...the rest of the table of contents... ...the document body... <h2><a name="section1">Introduction</a></h2> ...section 1... <h2><a name="section2">Some background</a></h2> ...section 2... <h3><a name="section2.1">On a more personal note</a></h3> ...section 2.1...We may achieve the same effect by making the header elements themselves the anchors:
<h1>Table of Contents</h1> <p<>a href="#section1">Introduction</a></p><br/> <p><a href="#section2">Some background</a></p><br/> <p><a href="#section2.1">On a more personal note</a></p><br/> ...the rest of the table of contents... ...the document body... <h2 id="section1">Introduction</h2> ...section 1... <h2 id="section2">Some background</h2> ...section 2... <h3 id="section2.1">On a more personal note</h3> ...section 2.1...
By far the most common use of a link is to retrieve another xHTML related resource, as illustrated in the previous examples. However, content developers may insert links in their documents that express other relationships between resources than simply "activate this link to visit that related resource". Links that express other types of relationships have one or more link types specified in their source anchor.
The roles of a link defined by A or LINK are specified via the rel and rev attributes.
For instance, links defined by the LINK element may describe the position of a presentation within a series of presentations (much like a collection of scenes). In the following excerpt, links within the presentation entitled "Scene 5" point to the previous and next scenes:
<head> ...other head information... <title>Scene 5</title> <link rel="prev" href="scene4.bhtml"/> <link rel="next" href="scene6.bhtml"/> </head>
The link type of the first link is "prev" and that of the second is "next" (two of several recognized link types). Links specified by LINK are not rendered with the document's contents, although user agents may render them in other ways (e.g., as navigation tools).
Even if they are not used for navigation, these links may be interpreted in interesting ways. For example, a user agent might pre-load adjacent documents in order to improve perceived performance.
The retrieved resource may be handled by the user agent in several ways: by opening a new xHTML document in the same user agent window, opening a new xHTML document in a different window, starting a new program to handle the resource, etc. This behavior is generally specified by the xHTML profile. Since the A element has content (text, images, etc.), user agents may render this content in such a way as to indicate the presence of a link (e.g., by underlining the content).
The title attribute may be set for A and LINK to add information about the nature of a link. This information may be spoken by a user agent, rendered as a tool tip, cause a change in cursor image, etc.
Thus, we may augment a previous example by supplying a title for each link:
<body> ...some text... <p>You'll find a lot more in <a href="scene2.bhtml" title="Go to scene two">scene two</a>. <a href="./scene2.bhtml" title="Get scene two.">scene two</a>. See also this <a href="../images/forest.gif" title="GIF image of enchanted forest">map of the enchanted forest.</a></p> </body>
Since links may point to documents encoded with different character encodings, the A and LINK elements support the charset attribute. This attribute allows authors to advise user agents about the encoding of data at the other end of the link.
The hreflang attribute provides user agents with information about the language of a resource at the end of a link, just as the lang attribute provides information about the language of an element's content or attribute values.
Armed with this additional knowledge, user agents should be able to avoid presenting "garbage" to the user. Instead, they may either locate resources necessary for the correct presentation of the document or, if they cannot locate the resources, they should at least warn the user that the document will be unreadable and explain the cause.
<!ENTITY % base.elements "EMPTY"> <!ELEMENT base %base.elements -- document base URI --> <!ATTLIST base href %url #REQUIRED -- URI that acts as base URI -- >
Attribute definitions
Attributes defined elsewhere
Links and references to external media, applications, form-processing programs, style sheets, etc. are always specified by a URI. Relative URIs are resolved according to the base URI. The BASE element allows content developers to specify a document's base URI explicitly.
When present, the BASE element must appear in the HEAD section of the document, before any element that refers to an external resource. The scope of the BASE element is the current document.
<!ENTITY % blockquote.elements "(%block | event)+"> <!ELEMENT blockquote %blockquote.elements -- long quotation --> <!ATTLIST blockquote %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of quotation -- cite %uri #IMPLIED -- source URI of quotation -- >
Attribute definitions
Attributes defined elsewhere
The BLOCKQUOTE element designates quoted text. This example formats an excerpt from "Pieces of Time", by Peter Bogdanovich, as a blockquote.
<blockquote cite="http://www.mycom.com/bogdanovich/piecesoftime/bogart.html"> <p>His death came in the early morning and that day the papers carried the news to the world. Most of the reports were similar. Quite a few of them told it this way: "Usually he kissed his wife Lauren Bacall and said, 'Good night.' But according to Dr. Michael Flynn, this time he put his hand on her hand and murmered in his familiar brusque fashion, 'Good-bye, kid.'"</p> </blockquote>
<!ENTITY % body.elements "((%block | event )+,( ins | del)*)"> <!ELEMENT body %body.elements -- document body --> <!ATTLIST body %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The body of a document contains the document's content. Style sheets are used for affecting the rendering of content by a user agent.
<xhtml>
<head>
<title>Inside the Actors Studio</title>
<style type="text/css">
body { background: blue; color: white}
a:link { color: yellow }
a:visited { color: maroon }
a:active { color: fuchsia }
</style>
</head>
<body>
... document body ...
</body>
</xhtml>
Using external (linked) style sheets gives you the flexibility to change the presentation without revising the source xHTML document:
<xhtml> <head> <title>Inside the Actors Studio</title> <link rel="stylesheet" type="text/css" href="smartstyle.css"> </head> <body> ... document body ... </body> </xhtml>
See the STYLE element for document style information.
<!ENTITY % br.elements "EMPTY"> <!ELEMENT br %br.elements -- forced line break --> <!ATTLIST br %core.attr -- id, class, title, and style -- >
Attributes defined elsewhere
The BR element forcibly breaks (ends) the current line of text. Authors are advised to use style sheets to control text flow around floating images and other objects.
<!ENTITY % div.elements "(%block | %inline)*"> <!ELEMENT div %div.elements -- generic language and style container --> <!ATTLIST DIV %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The DIV element, in conjunction with the id and class atributes, offers a generic mechanism for adding structure to documents.
Together with the SPAN element, these elements define content to be inline (SPAN) or block-level (DIV), but impose no presentational idioms on the content. Thus, content developers may use these elements in conjunction with style sheets to tailor xHTML to their needs and tastes. Extremely minimal xHTML profiles may provide support for very few structure-related elements, using the DIV and SPAN with absolute positioning to define presentations.
Suppose, for example, that we wanted to generate a document based on a database of movie star information. Since xHTML does not include elements that identify objects such as "actor", "birthdate", etc. we use DIV and SPAN to achieve the desired structural and presentation effects:
<div id="actor-welleso" class="actor"> <p><span class="actor-name">Orson Welles</span></p> <p><span class="actor-birthday">May 6, 1915</span></p> <p><span class="fanclub">mercury@somemail.net</span></p> </div> <div id="actor-hustonw" class="actor"> <p><span class="actor-name">Walter Huston</span></p> <p><span class="actor-birthday">April 6, 1884</span></p> <p><span class="fanclub">huston@somemail.net</span></p> </div>
Style sheet descriptors can then be added to fine-tune the presentation of these database entries.
<!ENTITY % head.elements "(title,style*,base?,link*)"> <!ELEMENT head %head.elements -- document head --> <!ATTLIST head %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The HEAD element contains information about the current document, such as the title, keywords, and other data not considered document content. User agents generally do not render information that appears in the HEAD as content. They may make this information available to users through other mechanisms.
<!ENTITY % heading.elements "(%inline)*"> <!ELEMENT (%heading) %heading.elements -- heading --> <!ATTLIST (%heading) %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
A heading element briefly describes the topic of the section it introduces. The following example shows how to use the DIV element to associate a heading with the document section that follows. Doing so allows the content developer to define a style for the section (color for the background, set the font, etc.) with style sheets.
<div class="section" id="talkies"> <h1>Talkies</h1> <p>Now I'm in Hollywood -- staring in disbelief at Grauman's Chinese, trying to understand those funny-looking trees -- and it's all true, everything I'd heard, all the cliches. They make airplanes out here, and missiles. But, above all, they make movies.</p> </div> <div class="subsection" id="on-hitchcock"> <h2>Alfred Hitchcock</h2> <p>One of my first interviews was with Alfred Hitchcock, the director, who ushered me gingerly into his expansive office at Paramount Pictures; he was wearing a dark suit, white shirt, dark tie, holding a large cigar, and looking very heavy indeed.</p> </div>
This structure may be decorated with style information such that each section has a different text alignment and font size.
<head>
<title>Pieces of Time by Peter Bogdanovich</title>
<style type="text/css">
div.section { text-align: justify; font-size: 12pt }
div.subsection { text-indent: 2em }
h1 { font-style: italic; color: green }
h2 { color: green }
</style>
</head>
<!ENTITY % hr.elements "event*"> <!ELEMENT hr %hr.elements -- horizontal rule --> <!ATTLIST hr %core.attr -- id, class, title, and style -- >
Attributes defined elsewhere
The HR element causes a horizontal rule to be rendered by visual user agents. The amount of vertical space inserted between a rule and the content can be specified using style sheets.
<!ENTITY % link.elements "event*"> <!ENTITY % linktypes "(alternate|stylesheet|start|next|prev|contents|index|glossary|copyright|chapter|section|subsection|appendix|help|bookmark|trailer|titles|credits)" <!ELEMENT link %link.elements -- media-independent link --> <!ATTLIST link %core.attr -- id, class, title, and style -- %i18n.attr -- language and dir of ??? type CDATA #REQUIRED -- content type of linked resource -- href %URL #REQUIRED -- URI for linked resource -- hreflang %languagecode #IMPLIED -- language of linked resource -- rel %linktypes #IMPLIED -- forward content types -- rev CDATA #IMPLIED -- reverse link types -- >
Attribute definitions
Attributes defined elsewhere
This element specifies a link. Unlike the A element, it may only appear in the document head, although it may appear any number of times. This example illustrates how several LINK elements may appear in the HEAD section of the document. The current document is "scene2.html".
<xhtml> <head> <title>Scene 2</title> <link rel="index" href="../index.html"> <link rel="next" href="scene3.html"> <link rel="prev" href="scene1.html"> </head> ... the rest of the document ...
The link types may be used by user agents in a variety of ways. While several link types are listed below, these types may be significantly tailored to the xHTML profile. Additional information on linking is provided in the section on the A element.
Authors may use the following recognized link types, listed here with their conventional interpretations. These link types are case-insensitive, i.e., "Alternate" has the same meaning as "alternate".
User agents, search engines, etc. may interpret these link types in a variety of ways. For example, user agents may provide access to linked documents through a navigation bar.
<!ENTITY % meta.elements "EMPTY"> <!ELEMENT meta %meta.elements -- generic metainformation --> <!ATTLIST meta %i18n.attr; -- lang and dir for use with content -- http-equiv CDATA #IMPLIED -- HTTP response header name -- name CDATA #IMPLIED -- metainformation name -- content CDATA #REQUIRED -- associated information -- scheme CDATA #IMPLIED -- select form of content -- >
Attribute definitions
Attributes defined elsewhere
The META element can be used to identify properties of a document (e.g., author, expiration date, a list of key words, etc.) and assign values to those properties. This specification does not define a normative set of properties.
Each META element specifies a property/value pair. The name attribute identifies the property and the content attribute specifies the property's value.
For example, the following declaration sets a value for the Author property:
<meta name="Author" content="Dave Raggett">
<!ENTITY % object.elements "( param | %flow )*"> <!ELEMENT object %object.elements -- generic embedded object --> <!ATTLIST object %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir -- declare (declare) #IMPLIED -- declare but don't instantiate flag -- classid %uri #IMPLIED -- identifies an implementation -- codebase %uri #IMPLIED -- base URI for classid, data, archive-- data %uri #IMPLIED -- reference to object's data -- type %contenttype #IMPLIED -- content type for data -- codetype %contenttype #IMPLIED -- content type for code -- archive %uri #IMPLIED -- space separated archive list -- standby CDATA #IMPLIED -- message to show while loading -- resources CDATA #IMPLIED -- content decoder resource requirements -- remain CDATA #IMPLIED -- list of URIs for object persistence -- >
Attribute definitions
Attributes defined elsewhere
xHTML's multimedia features allow content developers to include images, procedural applications, video clips, and other content types.
For example, to include a PNG image in a document, content developers would write:
<body> <p>This is the NBC logo: <object data="nbclogo.png" type="image/png"/> </p> </body>
xHTML uses the OBJECT element as an all-purpose solution to generic object inclusion. While media-specific names could certainly be used to add clarity in reading a xHTML file, only the OBJECT element is used in this specification. Media-specific elements (such as "audio" and "image") have limited usefulness when many media types are complex (a combination of one or more "mono" media).
The OBJECT, along with the PARAM element, allows xHTML content developers to specify everything required by an object for its presentation by a user agent: source code location, initial values, and run-time data.
A user agent must interpret an OBJECT element according to the following precedence rules:
In the following example, an analog clock program is inserted into a bHTML document via the OBJECT element. The clock program requires no additional data or run-time values. The classid attribute specifies the location of the program (using a proposed digital TV URL naming scheme):
<p><object classid="dtv:/1234/009F/data"/></p>
In this example, the clock will be rendered as soon as the user agent interprets the OBJECT declaration and loads the data. It is possible to delay the rendering of an object by using media synchronization style sheet properties.
The remain attribute may be used to specify a list of URIs on which this object remains persistent. The destination location must still define or declare the object with the same id attribute, otherwise the object will not persist. The content decoder will be notified that the document page changed (through an update) and will be providing the initialization parameters. In general,it is the responsibility of the content decoder to respond to the initialization parameters as appropriate to the content type.
<!ENTITY % p.elements "(%inline)*"> <!ELEMENT p %p.elements -- paragraph --> <!ATTLIST p %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
Document-centric content developers traditionally divide their thoughts and arguments into sequences or paragraphs. The organization of information into paragraphs is not affected by how the paragraphs are presented: paragraphs that are double-justified contain the same thoughts as those that are left-justified.
In xHTML, the P element defines a paragraph. While this may be simple, the visual presentation of paragraphs is not so simple. A number of issues, both technical and stylistic, must be addressed:
The first of these issues are addressed in the following paragraphs. Written language conventions are addressed with the lang and dir attributes. Justification and formatting of paragraphs is discussed in the appendix on style sheets
The document character set includes a wide variety of white space characters. Many of these are typographic elements used in some applications to produce particular visual spacing effects. In xHTML, only the following characters are defined as white characters:
Line breaks are also white space characters. Note that although 
 and 
 are defined in[ISO10646] to unambiguously separate lines and paragraphs, respectively, these do not constitute line breaks in xHTML, nor does this specification include them in the more general category of white space characters.
This specification does not indicate the behavior, rendering or otherwise, of space characters other than those explicitly identified here as white space characters. For this reason, authors should use appropriate elements and styles to achieve visual formatting effects that involve white space, rather than space characters.
For all xHTML elements except PRE, sequences of white space separate "words" (we use the term "word" here to mean "sequences of non-white space characters"). When formatting text, user agents should identify these words and lay them out according to the conventions of the particular written language (script) and target medium.
This layout may involve putting space between words (called inter-word space), but conventions for inter-word space vary from script to script. For example, in Latin scripts, inter-word space is typically rendered as an ASCII space ( ), while in Thai it is a zero-width word separator (​). In Japanese and Chinese, inter-word space is not typically rendered at all.
Note that a sequence of white spaces between words in the source document may result in an entirely different rendered inter-word spacing (except in the case of the PRE element). In particular, user agents should collapse input white space sequences when producing output inter-word space. This can and should be done even in the absence of language information (from the lang attribute, the HTTP "Content-Language" header field (see [RFC2068], section 14.13), user agent settings, etc.).
The PRE element is used for preformatted text, where white space is significant.
A line break is defined to be a carriage return (?x000D;), a line feed (?x000A;), or a carriage return and line feed pair. All line breaks constitute white space.
Sometimes content developers will want to force a line break or prohibit a line break. The BR element is used to force a line break. The entity (  or  ) acts as a space where user agents should not cause a line break.
Tthere are two types of hyphens: the plain hyphen and the soft hyphen. The plain hyphen should be interpreted by a user agent as just another character. The soft hyphen tells the user agent where a line break can occur.
Those browsers that interpret soft hyphens must observe the following semantics: If a line is broken at a soft hyphen, a hyphen character must be displayed at the end of the first line. If a line is not broken at a soft hyphen, the user agent must not display a hyphen character. For operations such as searching and sorting, the soft hyphen should always be ignored.
The plain hyphen is represented by the "-" character (- or -). The soft hyphen is represented by the character entity reference ­ (­ or ­)
<!ENTITY % param.elements "EMPTY"> <!ELEMENT param %param.elements -- named property value --> <!ATTLIST param id CDATA #IMPLIED -- document-wide unique id -- name CDATA #REQUIRED -- property name -- value CDATA #IMPLIED -- property value -- valuetype (data|ref|object) "data" -- How to interpret value -- type %contenttype #IMPLIED -- content type for value when valuetype=ref -- >
Attribute definitions
Attributes defined elsewhere
PARAM elements specify a set of values that may be required by an object for initialization at run-time. Any number of PARAM elements may appear in the content of an OBJECT element, in any order, but must be placed at the start of the content of the enclosing OBJECT element. If the object was initialized on a previous document and is persistent (through the remain attribute), the object is not reinitialized.
<!ENTITY % pre.elements "(#PCDATA | %phrase | %formctrl | a | br | event | span | bdo)*"> <!ELEMENT pre %pre.elements -- preformatted text --> <!ATTLIST pre %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
PRE elements enclose text that is "preformatted". When handling preformatted text, visual agents:
Non-visual user agents are not required to respect extra white space in the content of a PRE element.
The following example shows a preformatted verse from Shelly's poem "To a Skylark":
&li;pre>
Higher still and higher
From the search thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
</pre>
Here is how this is typically rendered:
Higher still and higher
From the search thou springest
Like a cloud of fire;
The blue deep thou wingest,
And singing still dost soar, and soaring ever singest.
<!ENTITY % span.elements "(%inline)*"> <!ELEMENT span %span.elements -- generic language/style container --> <!ATTLIST span %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The SPAN elements, in conjunction with the id and class attributes, offesr a generic mechanism for adding structure to documents.
Together with the DIV element, these elements define content to be inline (SPAN) or block-level (DIV), but impose no presentational idioms on the content. Thus, content developers may use these elements in conjunction with style sheets to tailor xHTML to their needs and tastes. Extremely minimal xHTML profiles may provide support for very few structure-related elements, using the DIV and SPAN with absolute positioning to define presentations. See the DIV element for additional information and examples of its usage.
<!ENTITY % style.elements "(#PCDATA)*"> <!ELEMENT style %style.elements -- style info --> <!ATTLIST style %i18n.attr -- lang and dir of title -- type CDATA #IMPLIED -- content type of style language -- media CDATA #IMPLIED -- designed for use with this media -- title CDATA #IMPLIED -- advisory title -- >
Attribute definitions
Attributes defined elsewhere
The STYLE element allows content developers to put style sheet rules in the head of the document. xHTML permits any number of STYLE elements in the HEAD section of a document.
In xHTML, style sheet implementations allow a wide variety of rules in the STYLE element than in the style attribute. For example, with CSS, rules may be declared within a STYLE element for:
The following CSS style declaration puts a border around every H1 element in the presentation and centers it on the screen:
<head>
<style type="text/css">
h1 (border-width: 1; border: solid; text-align: center)
</style>
</head>
To specify that this style information should only apply to H1 elements of a specific class, we modify it as follows:
<head>
<style type="text/css">
h1.myclass (border-width: 1; border: solid; text-align: center)
</style>
</head>
<body>
<h1 class="myclass"> This H1 is affected by our style </h1>
<h1> This header is not affected by our style </h1>
</body>
To limit the scope of the style information to a single instance of H1, set the id attribute:
<head>
<style type="text/css">
#myid (border-width: 1; border: solid; text-align: center)
</style>
</head>
<body>
<h1 class="myclass"> This H1 is not affected </h1>
<h1 id="myid"> This header is affected by our style </h1>
<h1> This H1 is not affected </h1>
</body>
Although style information may be set for almost every xHTML element, two elements, DIV and SPAN are particularly useful in that they do not impose any presentation semantics (besides block level vs. inline).
When combined with style sheets, these elements allow content developers to extend xHTML indefinitely, particularly when used with the class and id attributes.
In the following example, the DIV and the class attribute are used to set the text justification for a series of paragraphs that make up the abstract section of a scientific article. This style information could be reused for other abstract sections by setting the class attribute elsewhere in the document.
<head>
<style type="text/css">
div.abstract { text-align: justify }
</style>
</head>
<body>
<div class="abstract">
<p>The Chieftain product range is our market winner for the coming year</p>
<p>Chieftain replaces the Commander range, which will remain on the price list until further notice.</p>
</div>
</body>
<!ENTITY % switch.elements "(%block | test)*"> <!ELEMENT switch %switch.elements -- switch enclosed content --> <!ATTLIST switch %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The SWITCH element is used by a content developer to specify alternative presentations. The SWITCH element, based on the SMIL 1.0 element of the same name, is used to specify a set of alternative elements from which only one acceptable element should be chosen. An element is acceptable if the content type can be decoded and all of the TEST elements evaluate to true.
As in SMIL 1.0, the elements are evaluated in the order in which they appear in the SWITCH element. The first acceptable element is selected at the exclusion of all other elements within the SWITCH.
The intended use of the SWITCH element in xHTML is different than that intended for syle sheets. Content developers use style sheets to control how content is rendered on a display; content developers use the SWITCH element to control what content is rendered on the display. For example:
<object id="a" type="text/plain" .../>
<switch>
<test name="system-receiver-profile" value="dase/high" ... >
<object id="c" .../>
</test>
<test name="system-receiver-profile" value="dase/main" ... >
<object id="d" .../>
</test>
<object id="e" .../>
</switch>
<object id="f" type="text/plain" .../>
On high profile DASE receivers, the "a" object is rendered, then the "c" object is rendered, and finally the "f" object. On main profile DASE receivers, the "d" object is rendered after the "a" object, followed by the "f" object. On all other platforms, the "e" object is rendered after the "a" object, followed by the "f" object.
<!ENTITY % test.elements "object*"> <!ELEMENT test %test.elements -- test element --> <!ATTLIST test %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for value -- disabled (disabled) #IMPLIED -- flag for disabling the test -- name CDATA #IMPLIED -- the name of the test -- value CDATA #IMPLIED -- the value required for the test to succeed -- >
Attribute definitions
Attributes defined elsewhere
The TEST element is a child of the SWITCH and is used to test a platform's capabilities and settings. If the test passes, the encapsulated object should be rendered. This is similar to the SMIL 1.0 attribute of the same name. It is provided in xHTML as an element in order to provide greater extensibility for varying xHTML profiles.
In bHTML, the TEST element can have the following values for the name attribute:
Different profiles of xHTML will likely specify different values for the name attribute.
<!ENTITY % title.elements "(#PCDATA)*">
<!ELEMENT title (#PCDATA)* -- document title -->
<!ATTLIST title
%i18n.attr -- lang and dir of document title --
>
Attributes defined elsewhere
The TITLE element is not considered part of the flow of text and should only be displayed, for example, as the page header or window title. Exactly one title is required per document. Every xHTML document, must have a TITLE element in the HEAD.
Content developers should use the TITLE element to identify the contents of a presentation. Since users often view presentations out of context, content developers should provide context-rich titles. Thus, instead of a title such as "Commercial", which doesn't provide much contextual background, content developers should supply a title such as "Free Coca-Cola T-Shirt" instead.
Titles may contain character entities (for accented characters, special characters, etc.) but may not contain other markup. Here is an example title:
<head> <title>Free Coca-Cola T-Shirt</title> ...other head elements </head> <body> ...document body... </body>
For reasons of accessibility, user agents must always make the content of the TITLE element available to users. The mechanism for doing so depends on the user agent (e.g., as a caption, spoken).
The Docset elements are those elements pertaining to document-centric profiles.
<!ENTITY % abbr.elements "(%inline)*"> <!ELEMENT abbr %abbr.elements -- abbreviated form --> <!ATTLIST abbr %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. Western languages make extensive use of acronyms such as "GmbH", "NATO", and "F.B.I.", as well as abbreviations like "M.", "Inc.", "et al.", "etc.". Both Chinese and Japanese use analogous abbreviation mechanisms, wherein a long name is referred to subsequently with a subset of the Han characters from the original occurrence. Marking up these constructs provides useful information to user agents and tools such as spell checkers, speech synthesizers, translation systems and search-engine indexers.
The content of the ABBR and ACRONYM elements specifies the abbreviated expression itself, as it would normally appear in running text. The title attribute of these elements may be used to provide the full or expanded form of the expression.
Here are some sample uses of ABBR:
<p> <abbr title="World Wide Web:>WWW</abbr> <abbr lang="fr" title="Société Nationale des Chemins de Fer"> SNCF </abbr> <abbr lang="es" title="Doña">Doña</abbr> <abbr title="Abbreviation">abbr.lt;/abbr>
Note that abbreviations and acronyms often have idiosyncratic pronunciations. For example, while "IRS" and "BBC" are typically pronounced letter by letter, "NATO" and "UNESCO" are pronounced phonetically. Still other abbreviated forms (e.g., "URI" and "SQL") are spelled out by some people and pronounced as words by other people. When necessary, authors should use style sheets to specify the pronunciation of an abbreviated form.
<!ENTITY % acronym.elements "(%inline)*"> <!ELEMENT acronym %acronym.elements -- acronym form --> <!ATTLIST acronym %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The ABBR and ACRONYM elements allow authors to clearly indicate occurrences of abbreviations and acronyms. See the ABBR element for more information.
<!ENTITY % bdo.elements "(%inline)*"> <!ELEMENT bdo %bdo.elements -- I18N BiDi over-ride --> <!ATTLIST bdo %core.attr -- id, class, style, title -- lang %languagecode #IMPLIED -- language code -- dir (ltr|rtl) #REQUIRED -- directionality -- >
Attribute definitions
Attributes defined elsewhere
The bidirectional algorithm and the dir attribute generally suffice to manage embedded direction changes. However, some situations may arise when the bidirectional algorithm results in incorrect presentation. The BDO element allows authors to turn off the bidirectional algorithm for selected fragments of text.
Consider a document containing the text:
english1 HEBREW2 english3 HEBREW4 english5 HEBREW6
but assume that this text has already been put in visual order. One reason for this may be that the MIME standard favors visual order, i.e., that right-to-left character sequences are inserted right-to-left in the byte stream. In an email, the above might be formatted, including line breaks, as:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
This conflicts with the UNICODE bidirectional algorithm, because that algorithm would invert 2WERBEH, 4WERBEH, and 6WERBEH a second time, displaying the Hebrew words left-to-right instead of right-to-left.
The solution in this case is to override the bidirectional algorithm by putting the Email excerpt in a PRE element (to conserve line breaks) and each line in a BDO element, whose dir attribute is set to LTR:
<pre> <bdo dir="LTR">english1 2WERBEH english3</bdo> <bdo dir="LTR">4WERBEH english5 6WERBEH</bdo> </pre>
This tells the bidirectional algorithm "Leave me left-to-right!" and would produce the desired presentation:
english1 2WERBEH english3 4WERBEH english5 6WERBEH
The BDO element should be used in scenarios where absolute control over sequence order is required (e.g., multi-language part numbers). The dir attribute is mandatory for this element. More details on the BDO element may be found in the HTML 4.0 specification.
<!ENTITY % del.elements "(%flow)*"> <!ELEMENT del %del.elements -- deleted text --> <!ATTLIST del %core.attr -- id, class, style, and title -- %i18n.attr -- lang and dir for encapsulated content -- cite %uri #IMPLIED -- info on reason for change -- datetime CDATA #IMPLIED -- date and time of change -- >
Attribute definitions
Attributes defined elsewhere
The INS and DEL elements are used to markup sections of the document that have been inserted or deleted with respect to a different version of a document (e.g., in draft legislation where lawmakers need to view the changes).
These two elements are unusual for xHTML in that they may serve as either block-level or inline elements (but not both). They may contain one or more words within a paragraph or contain one or more block-level elements such as paragraphs, lists and tables.
This example could be from a bill to change the legislation for how many deputies a County Sheriff can employ from 3 to 5.
<p> A Sheriff can employ <del>3</del<>ins>5</ins> deputies. </p>
The INS and DEL elements must not contain block-level content when these elements behave as inline elements.
ILLEGAL EXAMPLE: The following is not legal HTML. <p> <del><div>...block-level content...</div></del> </p>
User agents should render inserted and deleted text in ways that make the change obvious. For instance, inserted text may appear in a special font, deleted text may not be shown at all or be shown as struck-through or with special markings, etc.
See the INS element for additional information.
<!ENTITY % dfn.elements "(%inline)*"> <!ELEMENT dfn %dfn.elements -- instance definition --> <!ATTLIST bdo %core.attr -- id, class, style, title -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The DFN element specifies that this is the defining instance for a term. User agents that build non-rendered indices may wish to reference instances of this element.
<!ENTITY % ins.elements "(%flow)*"> <!ELEMENT ins %ins.elements -- inserted text --> <!ATTLIST ins %core.attr -- id, class, style, and title -- %i18n.attr -- lang and dir for encapsulated content -- cite %uri #IMPLIED -- info on reason for change -- datetime %CDATA #IMPLIED -- date and time of change -- >
Attribute definitions
Attributes defined elsewhere
The INS and DEL elements must not contain block-level content when these elements behave as inline elements. See the DEL element for an example.
User agents should render inserted and deleted text in ways that make the change obvious. For instance, inserted text may appear in a special font, deleted text may not be shown at all or be shown as struck-through or with special markings, etc.
Both of the following examples correspond to November 5, 1994, 8:15:30 am, US Eastern Standard Time.
1994-11-05T13:15:30Z 1994-11-05T08:15:30-05:00
Used with ins, this gives:
<ins datetime="1994-11-05T08:15:30-05:00"
cite="http://www.foo.org/mydoc/comments.html">
Furthermore, the latest figures from the marketing department
suggest that such practice is on the rise.
</ins>
The document "http://www.foo.org/mydoc/comments.html" would contain comments about why information was inserted into the document.
Authors may also make comments about inserted or deleted text by means of the title attribute for the INS and DEL elements. User agents may present this information to the user (e.g., as a popup note). For example:
<ins datetime="1994-11-05T08:15:30-05:00"
title="Changed as a result of Steve B's comments in meeting.">
Furthermore, the latest figures from the marketing department
suggest that such practice is on the rise.
</ins>
<!ENTITY % sub.elements "(%inline)*"> <!ELEMENT sub %sub.elements -- subscript --> <!ATTLIST sub %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The SUB element is used for subscripts. For example:
H<sub>2</sub>
See the closely related SUP element for additional examples.
<!ENTITY % sup.elements "(%inline)*"> <!ELEMENT sup %sup.elements -- superscript --> <!ATTLIST sup %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The SUP element is used for superscripts. For example:
E = mc<sup>2</sup>
Many scripts (e.g., French) require superscripts or subscripts for proper rendering. The SUB and SUP elements should be used to markup text in these cases.
<span lang="fr">M<sup>lle</sup> Dupont</span>
<!ENTITY % var.elements "(%inline)*"> <!ELEMENT var %var.elements -- instance of a variable or program element --> <!ATTLIST var %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The VAR element specifies the instance of a variable or program element.
The Eventset elements are those elements pertaining to profiles that provide bindings to procedural languages or scripts.
<!ENTITY % action.elements "(param)*"> <!ELEMENT action %action.elements -- invocation of procedural code or scripts --> <!ATTLIST action %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- charset %charset #IMPLIED -- char encoding of linked resource -- type %contenttype #REQUIRED -- content type of action language -- src %uri #IMPLIED -- URI for an external action -- defer (defer) #IMPLIED -- UA may defer execution of script -- >
Attribute definitions
Attributes defined elsewhere
The ACTION element may be used to specify the behavior that occurs in response to an event. An xHTML profile, such as bHTML, may limit the languages that may be used for writing a behavior. For example, in bHTML, only Java may be used for external procedural behaviors.
A function that responds to an "onClick" event may be identified in a manner similar to:
<event name="onClick"> <action id="a" src="dsm-cc://t3-6/menu" name="Menu.doOnClick" /> </event>
If the function takes an initialization parameter, this parameter can be added using the PARAM element.
<event name="onClick">
<action id="a" src="dsm-cc://t3-6/menu" name="Menu.doOnClick">
<param value="obj-b" value-type="object" />
</action>
</event>
In the example, above, an object with an id attribute of "obj-b" is passed to the Menu.doOnClick function
<!ENTITY % event.elements "(action)*, a"> <!ELEMENT event %event.elements -- recognize an event --> <!ATTLIST event %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- id CDATA #IMPLIED -- unique identifier to this event handler -- name CDATA #REQUIRED -- name of the event to respond to -- >
Attribute definitions
Attributes defined elsewhere
The EVENT element defines a block of behaviors that respond to an event. The events that are available to the system are defined by the profile of the system. In addition, custom events can be encoded through the name attribute. This allows external procedural codes to "insert" events through the document object model (DOM) and trigger behaviors encoded in the xHTML document.
The following bHTML example describes two behaviors. When the channel changes, the "showObject" function is called. When the user clicks on the object, the "hideObject" function is called.
<body>
<event name="onchannelchange">
<action id="showObject" src="dsm-cc://t6-3/display" name="Display.showObject" />
</event>
<object id="a" type="img/jpeg" classid="dsm-cc://t6-3/myimage.jpeg">
<event name="onclick">
<action id="hideObject" src="dsm-cc://t6-3/display" name="Display.hideObject"/>
</event>
</object>
</body>
Links may also be associated with a EVENT element. When a link, through the A element, is associated with an event, it is automatically visited when the encapsulating event occurs. For example, when the content decoder reaches the end of the media stream, the user agent hyperlinks to the next xHTML resource.
<object type="video/quicktime" ...>
<event name="onendofmedia">
<a href="scene2.html">Next Scene</a>
</event>
</object>
The user could also have selected the "Next Scene" hyperlink to transition to the next xHTML resource.
<!ENTITY % noaction.elements "(%block)+">
<!ELEMENT noaction %noaction.elements -- alternate content container
for non-event based rendering -->
<!ATTLIST noaction
%core.attr -- id, class, type, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
Attributes defined elsewhere
The NOACTION element allows authors to provide alternate content when procedural code or script is not executed. The content of a NOACTION element should only rendered by an action-aware user agent in the following cases:
User agents that do not support client-side procedural code or scripts must render this element's contents.
In the following example, a user agent that executes the ACTION will include some dynamically created data in the document. If the user agent doesn't support actions, the user may still retrieve the data through a link.
<event name="onload">
<action type="text/tcl">
...some Tcl script to insert data...
</script>
<noscript>
<p>Access the <a href="http://someplace.com/data">data.</a>
</noscript>
</event>
The Fontset elements are those elements pertaining to profiles that support more than one font. They generally consist of phrase-related elements in which the font of font style is modified.
<!ENTITY % address.elements "(%inline)*"> <!ELEMENT address %address.elements -- information on author --> <!ATTLIST address %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The ADDRESS element may be used by content developers to supply contact information for document or a major part of a document such as a form. This element often appears at the beginning or end of a document.
For example, a xHTML advertisement might include:
<address> <p>For more information on the <a href="Activity">March of Dimes Food Drive≤/a></p> <a href="../People/PerrinR/">Reginald Perrin</a> </address>
<!ENTITY % em.elements "(%inline)*"> <!ELEMENT em %em.elements -- emphasis --> <!ATTLIST em %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The EM element may be used to add structural information to text fragments. Specifically, the EM element is used to indicate an emphasis.
The presentation of phrase elements depends on the user agent. xHTML profiles may specify a particular presentation for compliance. For example, the bHTML profile specifies that text fragments encapsulated by the EM element be italicized.
<!ENTITY % kbd.elements "(%inline)*"> <!ELEMENT kbd %kbd.elements -- text to be entered by the user --> <!ATTLIST kbd %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The KBD element is used to indicate text, keyboard, or remote control keys that are entered by the user.
The presentation of phrase elements depends on the user agent. xHTML profiles may specify a particular presentation for compliance. For example, the bHTML profile specifies that text encapsulated by the KBD element be rendered with a fixed-pitch font.
<!ENTITY % strong.elements "(%inline)*"> <!ELEMENT strong %strong.elements -- strong emphasis --> <!ATTLIST strong %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The STRONG element is used to indicate text with a stronger emphasis than that indicated by the EM element.
The presentation of phrase elements depends on the user agent. xHTML profiles may specify a particular presentation for compliance. For example, the bHTML profile specifies that text encapsulated by the STRONG element be rendered in a bold font.
The Formset elements are those elements pertaining to profiles that support interactive forms. These forms may interact with a server through a return channel, or the server may be located on the same platform.
<!ENTITY % fieldset.elements "(#PCDATA, legend, (%flow | event)*)"> <!ELEMENT fieldset %fieldset.elements -- form control group --> <!ATTLIST FIELDSET %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The FIELDSET element allows content developers to group thematically related controls and labels. Grouping controls makes it easier for users to understand their purpose while simultaneously facilitating tabbing navigation for visual user agents and speech navigation for speech oriented user agents. The proper use of this element makes documents more accessible.
In this example, we create a form that one might fill out at the doctor's office. It is divided into three sections: personal information, medical history, and current medication. Each section contains controls for inputting the appropriate information.
<form action="..." method="post"> <p> <fieldset> <legend>Personal Information</legend> Last Name: <input name="personal_lastname" type="text"> First Name: <input name="personal_firstname" type="text"> Address: <input name="personal_address" type="text"> ...more personal information... </fieldset> <fieldset> <legend>Medical History</legend> <input name="history_illness" type="checkbox" value="Smallpox"> Smallpox <input name="history_illness" type="checkbox" value="Mumps"> Mumps <input name="history_illness" type="checkbox" value="Dizziness"> Dizziness <input name="history_illness" type="checkbox" value="Sneezing"> Sneezing ...more medical history... </fieldset> <fieldset> <legend>Current Medication</legend> Are you currently taking any medication? <input name="medication_now" type="radio" value="yes"> Yes <input name="medication_now" type="radio" value="no"> No If you are currently taking medication, please indicate it in the space below. <textarea name="current_medication" rows="20" cols="50"/> </fieldset> </form>
<!ENTITY % form.elements "(p | %heading | %list | pre | dl | div | noevent | blockquote | hr | table | fieldset | address | event")*> <!ELEMENT form %form.elements -- interactive form --> <!ATTLIST form %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- action %uri #REQUIRED -- server-side form handler -- method ( get | post ) "get" -- HTTP method used to submit the form-- enctype %contenttype "application/x-www-form-urlencoded" accept-charset %charsets #IMPLIED -- list of supported charsets -- >
Attribute definitions
Attributes defined elsewhere
The FORM element acts as a container for controls. It specifies:
A form can contain text and markup (paragraphs, lists, etc.) in addition to the form controls.
The following example shows a form that is to be processed by the "adduser" program when submitted. The form will be sent to the program using the HTTP "post" method.
<form action="dsm-cc://t6-1/prog/adduser" method="post"> ...form contents... </form>
The next example shows how to send a submitted form to an email address:
<form action="mailto:Kilgor.Trout@gee.whiz.com" method="post"> ...form contents... </form>
<!ENTITY % inputtype "(text | password | checkbox | radio | submit | reset | file | hidden | image | button)"> <!ENTITY % input.elements "(event)*"> <!ELEMENT input %input.elements -- form control --> <!ATTLIST input %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- type %inputtype #REQUIRED -- what kind of widget is needed -- name CDATA #IMPLIED -- submit as part of form -- value CDATA #IMPLIED -- required for radio and checkboxes -- checked (checked) #IMPLIED -- for radio buttons and check boxes -- disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED -- for text and passwd -- size CDATA #IMPLIED -- specific to each type of field -- maxlength CDATA #IMPLIED -- max chars for text fields -- src %uri #IMPLIED -- for fields with images -- accept %contenttypes #IMPLIED -- list of MIME types for file upload -- >
Attribute definitions
Attributes defined elsewhere
The control type defined by the INPUT element depends on the value of the type attribute:
name.x=x-valueand
name.y=y-valuewhere "name" is the value of the name attribute, and the "x-value" and "y-value" are the x and y coordinate values, respectively.
The following sample xHTML fragment defines a simple form that allows the user to enter a first name, last name, email address, and gender. When the submit button is activated, the form will be sent to the program specified by the action attribute.
<form action="dsm-cc://t6-2/prog/adduser" method="post"> <p> First name: <input type="text" name="firstname"/><br/> Last name: <input type="text" name="lastname"/><br/> email: <input type="text" name="email"/><br/> <input type="radio" name="sex" value="Male"/>Male<br/> <input type="radio" name="sex" value="Femail"/>Female<br/> <input type="submit" value="Send"/><input type="reset"/> </p> </form>
In this example, the Java function named verify is triggered when the "onclick" event occurs:
<form id="newuserform" action="dsm-cc://t6-2/prog/adduser" method="post">
<p>
...form contents...
<input type="button" name="updatebtn" value="Update">
<event name="onClick">
<action id="a" src="dsm-cc://t3-6/newuser" name="::Verify">
<param value="newuserform"/>
</action>
</event>
</input>
...more form contents...
</p>
</form>
<!ENTITY % label.elements "((#PCDATA | %phrase | select | textarea | a | object | br | event | sub | sub | span | bdo)* | input )"> <!ELEMENT label %label.elements -- control label text --> <!ATTLIST label %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- for CDATA #IMPLIED -- matches field ID value -- >
Attribute definitions
Attributes defined elsewhere
The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control.
Labels may be associated with a control either explicitly or implicitly. The for attribute explicitly associates a label with another control. The value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute.
This is an example of the LABEL element:
<form action="dsm-cc://t6-3/prog/add-user" method="post"> <p> <label for="firstname">First name:</label> <input type="text" id="firstname"/><br/> <label for="lastname">Last name:</label> <input type="text" id="lastname"/><br/> <label for="email">Email:</label> <input type=text" id="email"/><br/> <input type="radio" name="sex" value="Male"/>Male<br/> <input type="radio" name="sex" value="Female"/>Female<br/> <input type="submit" value="Send"/><input type="reset"/> </p> </form>
To associate a label with another control implicitly, the control element must be encapsulated by the LABEL element. In this case, the LABEL may only contain one control element. The label itself may be positioned before or after the associated control.
In this example, we implicitly assocate two labels with two text input controls:
<form action="..." method="post">
<p>
<label>First Name
<input type="text" name="firstname">
</label>
<label>
<input type="text" name="lastname">
Last Name
</label>
</p>
</form>
<!ENTITY % legend.elements "(%inline)*"> <!ELEMENT legend %legend.elements -- fieldset legend --> <!ATTLIST legend %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- >
Attributes defined elsewhere
The LEGEND element allows authors to assign a caption to a FIELDSET. The legend improves the accessibility when the FIELDSET is rendered non-visually. See the FIELDSET for an example.
<!ENTITY % optgroup.elements "(option+, event*)"> <!ELEMENT optgroup %optgroup.elements -- option group --> <!ATTLIST optgroup %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- disabled (disabled) #IMPLIED -- unavailable in this context -- label CDATA #REQUIRED -- for use in hierarchical menus -- >
Attribute definitions
Attributes defined elsewhere
The OPTGROUP element allows content developers to group choices logically. This is particularly helpful when the user must choose from a logn list of options; groups of related choices are easier to grasp and remember than a single long list of options. In xHTML, all OPTGROUP elements must be specified directly within a SELECT element (i.e., groups may not be nested).
The label attribute of the OPTGROUP element specifies the label for a group of choices. For example:
<form action="dsm-cc://t6-3/prog/someprog" method="post">
<p>
<select name="Television Tonight">
<optgroup label="FOX">
<option label="Texas Rangers Baseball (HDTV)" value="tv4_0">FOX 4.0</option>
</optgroup>
<optgroup label="NBC">
<option label="Live at Five" value="tv5_0">NBC 5.0</option>
<option label="Previews" value="tv5.1">NBC 5.1</option>
</optgroup>
<optgroup label="ABC">
<option label="Local News" value="tv8_0">ABC 8.0</option>
<option label="Sports Highlights" value="tv8.1">ABC 8.1</option>
<option label="Weather 24" value="tv8.2">ABC 8.2</option>
</optgroup>
</select>
</p>
</form>
represents the following grouping:
Television Tonight
FOX
Texas Rangers Baseball (HDTV)
NBC
Live at Five
Previews (HDTV)
ABC
Local News
Sports
Weather 24
Visual user agents may allow users to select from option groups through a hierarchical menu or some other mechanism that reflects the structure of choice.
<!ENTITY % option.elements "(#PCDATA | event)*"> <!ELEMENT option %option.elements -- selectable choice --> <!ATTLIST option %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- selected (selected) #IMPLIED -- is the option selected -- disabled (disabled) #IMPLIED -- unavailable in this context -- label CDATA #IMPLIED -- for use in hierarchical menus -- value CDATA #IMPLIED -- defaults to element content -- >
Attribute definitions
Attributes defined elsewhere
When rendering a menu choice, user agents should use the value of label attribute of the OPTION element as the choice. If this attribute is not specified, user agents should use the contents of the OPTION element.
In this example, we create a menu that allows the user to select which of seven software components to install. The first and second components are pre-selected but may be deselected by the user. The remaining components are not pre-selected. The size attribute states that the menu should only have 4 rows even though the user may select from among 7 options. The other options should be made available through a scrolling mechanism.
<!ENTITY % select.elements "((optgroup | option )+, event*)"> <!ELEMENT select %select.elements -- option selector --> <!ATTLIST select %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- name CDATA #IMPLIED -- field name -- size CDATA #IMPLIED -- rows visible -- multiple (multiple) #IMPLIED -- default is single selection -- disabled (disabled) #IMPLIED -- unavailable in this context -- >
Attribute definitions
Attributes defined elsewhere
The SELECT element creates a menu. Each choice offered by the menu is represented by an OPTION element. A SELECT element must contain at least one OPTION element.
The SELECT is followed by submit and reset button:
<form action="dsm-cc://t6-3/prog/component-select" method="post">
<p>
<select multiple size="4" name="component-select">
<option selected="true" value="component_1_a">Component_1</option>
<option selected="true" value="component_1_b">Component_2</option>
<option>Component_3</option>
<option>Component_4</option>
<option>Component_5</option>
<option>Component_6</option>
<option>Component_7</option>
</select>
<input type="submit" value="Send"/>
<input type="reset"/>
</p>
</form>
Only selected options will be successful (using the control name "compont-select"). Note that where the value attribute is set, it determines the control's initial value, otherwise it's the element's contents.
<!ENTITY % textarea.elements "(#PCDATA | event)*"> <!ELEMENT textarea %textarea.elements -- multi-line text field --> <!ATTLIST textarea %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir of encapsulated content -- name CDATA #IMPLIED -- field name -- rows CDATA #REQUIRED -- number of visible lines of text in field -- cols CDATA #REQUIRED -- visible width in average character widths disabled (disabled) #IMPLIED -- unavailable in this context -- readonly (readonly) #IMPLIED -- content is readonly -- >
Attribute definitions
Attributes defined elsewhere
The TEXTAREA element creates a multi-line text input control. User agents should use the contents of this element as the initial value of the control and should render this text initially.
This example creates a TEXTAREA control that is 20 rows by 80 columns and contains two lines of text initially. The TEXTAREA is followed by the submit and reset buttons.
<form action="http://somesite.com/prog/text-read" method="post">
<p>
<textarea name="thetext" rows="20" cols="80">
First line of initial text.
Second line of initial text.
</textarea>
<input type="submit" value="Send"/><input type="reset"/>
</p>
</form>
Setting the readonly attribute allows content developers to display unmodified text in a TEXTAREA. This differs from using standard marked-up text in a document because the value of the TEXTAREA is submitted with the form.
The Frameset elements are those elements pertaining to profiles that support frames.
<!ENTITY % frame.elements "EMPTY"> <!ELEMENT frame %frame.elements -- subwindow --> <!ATTLIST frame %core.attr -- id, class, title, and style -- longdesc %uri #IMPLIED -- link to long description (complements title) -- name CDATA #IMPLIED -- name of frame for targetting -- src %uri #IMPLIED -- source of frame content -- noresize (noresize) #IMPLIED -- allow users to resize frames? -- scrolling (yes|no|auto) "auto" -- scrollbar or none -- >
Attribute definitions
Attributes defined elsewhere
The FRAME element defines the contents and appearance of a single frame.
The src attribute specifies the initial document the frame will contain.
The following example:
<frameset cols="33%,33%,33%">
<frameset rows="*,200">
<frame src="contents_of_frame1.html"/>
<frame src="contents_of_frame2.gif"/>
</frameset>
<frame src="contents_of_frame3.html"/>
<frame src="contents_of_frame4.html"/>
</frameset>
should create a frame layout something like this:
------------------------------------------ |Frame 1 |Frame 3 |Frame 4 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | -------------| | | |Frame 2 | | | | | | | | | | | ------------------------------------------
and cause the user agent to load each file into a separate view.
The contents of a frame must not be in the same document as the frame's definition.
ILLEGAL EXAMPLE:
The following frameset definition is not legal HTML since the contents of the second frame are in the same document as the frameset.
<frameset cols="50%,50%">
<frame src="contents_of_frame1.html"/>
<frame src="#anchor_in_same_document"/>
<noframes>
...some text...
<h2><a name="anchor_in_same_document">Important Section</a></h2>
...some text...
</noframes>
</frameset>
<!ENTITY % frameset.elements "((frameset | frame)+, (event | noframes)*)"> <!ELEMENT frameset %frameset.elements -- window subdivision --> <!ATTLIST frameset %core.attr -- id, class, title, and style -- rows CDATA #IMPLIED -- list of lengths, default: 100% (1 row) -- cols CDATA #IMPLIED -- list of lengths, default: 100% (1 col) -- >
Attribute definitions
Attributes defined elsewhere
The FRAMESET element specifies the layout of the main user window in terms of rectangular subspaces.
Setting the rows attribute defines the number of horizontal subspaces in a frameset. Setting the cols attribute defines the number of vertical subspaces. Both attributes may be set simultaneously to create a grid.
If the rows attribute is not set, each column extends the entire length of the page. If the cols attribute is not set, each row extends the entire width of the page. If neither attribute is set, the frame takes up exactly the size of the page.
Frames are created left-to-right for columns and top-to-bottom for rows. When both attributes are specified, views are created left-to-right in the top row, left-to-right in the second row, etc.
The first example divides the screen vertically in two (i.e., creates a top half and a bottom half).
<frameset rows="50%, 50%"> ...the rest of the definition... </frameset>
The next example creates three columns: the second has a fixed width of 250 pixels (useful, for example, to hold an image with a known size). The first receives 25% of the remaining space and the third 75% of the remaining space.
<frameset cols="1*,250,3*"> ...the rest of the definition... </frameset>
The next example creates a 2x3 grid of subspaces.
<frameset rows="30%,70%" cols="33%,34%,33%"> ...the rest of the definition... </frameset>
For the next example, suppose the browser window is currently 1000 pixels high. The first view is allotted 30% of the total height (300 pixels). The second view is specified to be exactly 400 pixels high. This leaves 300 pixels to be divided between the other two frames. The fourth frame's height is specified as "2*", so it is twice as high as the third frame, whose height is only "*" (equivalent to 1*). Therefore the third frame will be 100 pixels high and the fourth will be 200 pixels high.
<frameset rows="30%,400,*,2*"> ...the rest of the definition... </frameset>
Absolute lengths that do not sum to 100% of the real available space should be adjusted by the user agent. When underspecified, remaining space should be allotted proportionally to each view. When overspecified, each view should be reduced according to its specified proportion of the total space.
While, framesets may be nested to any level, xHTML profiles may restrict the number of nesting levels.
In the following example, the outer FRAMESET divides the available space into three equal columns. The inner FRAMESET then divides the second area into two rows of unequal height.
<frameset cols="33%, 33%, 34%">
...contents of first frame...
<frameset rows="40%, 50%">
...contents of second frame, first row...
...contents of second frame, second row...
</frameset>
...contents of third frame...
</frameset>
Content developers may share data among several frames by including this data via an OBJECT element. Content developers should include the OBJECT element in the HEAD element of a frameset document and name it with the id attribute. Any document that is the contents of a frame in the frameset may refer to this identifier.
The following example illustrates how a script might refer to an OBJECT element defined for an entire frameset:
<xhtml> <head> <title>This is a frameset with OBJECT in the HEAD</title> <!-- This OBJECT is not rendered! --> <object id="myobject" data="data.bar"/> </head> <frameset> <frame src="bianca.html" name="bianca"> </frameset> </xhtml> <!-- In bianca.html --> <xhtml> <head> <title>Bianca's page</title> </head> <body> ...the beginning of the document... <p> <action type="text/javascript"> parent.myobject.myproperty </action> </p> ...the rest of the document... </body> </xhtml>
<!ENTITY % iframe.elements "(%flow)*"> <!ELEMENT iframe &iframe.elements -- inline subwindow --> <!ATTLIST iframe %core.attr -- id, class, style, title -- longdesc %uri #IMPLIED -- link to long description (complements title) -- name CDATA #IMPLIED -- name of frame for targetting -- src %uri #IMPLIED -- source of frame content -- scrolling (yes|no|auto) "auto" -- scrollbar or none -- >
Attribute definitions
Attributes defined elsewhere
The IFRAME element allows content developers to insert a frame within a block of text. Inserting an inline frame within a section of text is much like inserting an object via the OBJECT element: they both allow you to insert an xHTML document in the middle of another, they may both be aligned with surrounding text, etc.
The information to be inserted inline is designated by the src attribute of this element. The contents of the IFRAME element, on the other hand, should only be displayed by user agents that do not support frames or are configured not to display frames.
For user agents that support frames, the following example will place an inline frame surrounded by a border in the middle of the text.
<iframe src="foo.html" width="400" height="500" scrolling="auto" frameborder="1"> [Your user agent does not support frames or is currently configured not to display frames. However, you may visit <a href="foo.html">the related document.</a>] </iframe>
Inline frames may not be resized (and thus, they do not take the noresize attribute).
<!ENTITY % noframes.elements "(%flow)*"> <!ELEMENT noframes %noframes.elements -- alt content container for non frame-based rendering --> <!ATTLIST noframes %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The NOFRAMES element specifies content that should be displayed only when frames are not being displayed. User agents that support frames must only display the contents of a NOFRAMES declaration when configured not to display frames. User agents that do not support frames must display the contents of NOFRAMES in any case.
NOFRAMES can be used in the FRAMESET section of a frameset document. For example:
<xhtml>
<head>
<title>A frameset document with NOFRAMES</title>
</head>
<frameset cols="50%, 50%">
<frame src="main.html"/>
<frame src="table_of_contents.html"/>
<noframes>
<p>Here is the <a href="main-noframes.html">
non-frame based version of the document.</a></p>
</noframes>
</frameset>
</xhtml>
The Listset elements are those elements pertaining to profiles that support lists. While it is expected that most profiles would support lists, it is conceivable to define a platform with no inline flow algorithms, instead relying on absolute or fixed positioning (through style information). For these profiles, the Listset would not need to be supported.
<!ENTITY % dd.elements "(%flow)*"> <!ELEMENT dd %dd.elements -- definition description --> <!ATTLIST dd %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The DD element encapsulates the description of a definition in a definition list. See the DL element for a description of definition lists.
<!ENTITY % dl.elements "(dt | dd)+"> <!ELEMENT dl %dl.elements -- definition list --> <!ATTLIST dl %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The DL element specifies a definition list. Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with the DD element that contains block level content.
Here is an example:
<dl>
<dt>Dweeb</dt>
<dd>young excitable person who may mature
into a <em>Nerd</em> or <em>Geek</em></dd>
<dt>Cracker</dt>
<dd>hacker on the Internet</dd>
<dt>Nerd</dt>
<dd>male so into the Net that he forgets
his wife's birthday</dd>
</dl>
Here is an example with multiple terms and descriptions:
<dl>
<dt>Center</dt>
<dt>Centre</dt>
<dd>A point equidistant from all points
on the surface of a sphere.</dd>
<dd>In some field sports, the player who
holds the middle position on the field, court,
or forward line.</dd>
</dl>
Another application of DL, for example, is for marking up dialogues, with each DT naming a speaker, and each DD containing his or her words.
<!ENTITY % dt.elements "(%inline)*"> <!ELEMENT dt %dt.elements -- definition term --> <!ATTLIST dt %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The DT element provides the term for a definition in a definition list. See the DL for a description of definition lists.
<!ENTITY % li.elements "(%flow)*"> <!ELEMENT li %li.elements -- list item --> <!ATTLIST li %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The LI element provides the list item in an unordered or ordered list. See the UL element for a description of unordered lists and the OL element for a description of ordered lists.
<!ENTITY % ol.elements "(li)+"> <!ELEMENT ol %ol.elements -- ordered list --> <!ATTLIST ol %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The OL element is used to create an ordered list. An ordered list should contain information where the order should be emphasized, as in a recipe:
The following example specifies the above list of recipe steps:
<ol> <li>Mix dry ingredients thoroughly</li> <li>Pour in wet ingredients</li> <li>Mix for 10 minutes</li> <li>Bake for one hour at 300 degress</li> </ol>
<!ENTITY % ul.elements "(li)+"> <!ELEMENT ul %ul.elements -- unordered list --> <!ATTLIST ul %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
The UL element is used to create an unordered list. An unordered list should contain list items in which the order is irrelevant. For example, the list:
is created using the following xHTML fragment:
<ul> <li>w3HTML (full World Wide Web HTML)</li> <li>bHTML (Broadcast HTML)</li> <li>cHTML (Compact HTML)</li> <li>tHTML (Tiny HTML)</li> </ul>
The Tableset elements are those elements pertaining to profiles that support tables.
<!ENTITY % cellvalign
"valign (top|middle|bottom|baseline) #IMPLIED"
>
<!ENTITY % cellhalign
"align (left|center|right|justify|char) #IMPLIED
char CDATA #IMPLIED -- alignment char, e.g. char=':' --
charoff %length #IMPLIED -- offset for alignment char --"
>
Attribute definitions
When charoff is used to set the offset of an alignment character, the direction of offset is determined by the current text direction (set by the dir attribute). In left-to-right texts (the default), offset is from the left margin. In right-to-left texts, offset is from the right margin. Depending on the xHTML profile, user agents may not be required to support this attribute.
The table in this example aligns a row of currency values along a decimal point. We set the alignment character to "." explicitly.
<table border="1">
<colgroup>
<col/><col align="char" char="."/>
<thead>
<tr><th>Vegetable</th><th>Cost per kilo</th></tr>
</thead>
<tbody>
<TR><TD>Lettuce</td><TD>$1</td></tr>
<TR><TD>Silver carrots</td><TD>$10.50 </td></tr>
<TR><TD>Golden turnips</td><TD>$100.30</td></tr>
</tbody>
</table>
The formatted table may resemble the following:
------------------------------ | Vegetable |Cost per kilo| |--------------|-------------| |Lettuce | $1 | |--------------|-------------| |Silver carrots| $10.50| |--------------|-------------| |Golden turnips| $100.30| ------------------------------
When the contents of a cell contain more than one instance of the alignment character specified by char and the contents wrap, user agent behavior is undefined. Authors should therefore be attentive in their use of char.
Note. Visual user agents typically render TH elements vertically and horizontally centered within the cell and with a bold font weight. This behavior may be specified by the xHTML profile.
The alignment of cell contents can be specified on a cell by cell basis, or inherited from enclosing elements, such as the row, column or the table itself.
The order of precedence (from highest to lowest) for the attributes (and style) align, char, and charoff is the following:
The order of precedence (from highest to lowest) for the attribute valign (as well as the other inherited attributes lang, dir, and style) is the following:
Furthermore, when rendering cells, horizontal alignment is determined by columns in preference to rows, while for vertical alignment, rows are given preference over columns.
The default alignment for cells depends on the user agent. However, user agents should substitute the default attribute for the current directionality (i.e., not just "left" in all cases).
User agents that do not support the "justify" value of the align attribute should use the value of the inherited directionality in its place.
Note. Note that a cell may inherit an attribute not from its parent but from the first cell in a span. This is an exception to the general attribute inheritance rules.
<!ENTITY % caption.elements "(%inline)*"> <!ELEMENT caption %caption.elements -- table caption --> <!ATTLIST caption %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- >
Attributes defined elsewhere
When present, the CAPTION element's text should describe the nature of the table. The CAPTION element is only permitted immediately after the TABLE start tag. A TABLE element may only contain one CAPTION element.
Visual user agents allow sighted people to quickly grasp the structure of the table from the headings as well as the caption. A consequence of this is that captions will often be inadequate as a summary of the purpose and structure of the table from the perspective of people relying on non-visual user agents.
Content developers should therefore take care to provide additional information summarizing the purpose and structure of the table using the summary attribute of the TABLE element. This is especially important for tables without captions. Examples below illustrate the use of the summary attribute.
Visual user agents should avoid clipping any part of the table including the caption, unless a means is provided to access all parts, e.g., by horizontal or vertical scrolling. We recommend that the caption text be wrapped to the same width as the table. This may be specified by the xHTML profile.
<!ENTITY % col.elements "(event)*"> <!ELEMENT col %col.elements -- table column --> <!ATTLIST col %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- span CDATA 1 -- COL attributes affect N columns -- width %multilength #IMPLIED -- column width specification -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attribute definitions
Attributes defined elsewhere
The COL element allows content develoeprs to group together attribute specifications for table columns. The COL does not group columns together structurally -- that is the role of the COLGROUP element. COL elements are empty and serve only as a support for attributes. They may appear inside or outside an explicit column group (i.e., COLGROUP element).
The width attribute for COL refers to the width of each column in the element's span.
There are two ways to determine the number of columns in a table (in order of precedence):
It is an error if a table contains COLGROUP or COL elements and the two calculations do not result in the same number of columns.
Once the user agent has calculated the number of columns in the table, it may group them into column groups.
For example, for each of the following tables, the two column calculation methods should result in three columns. The first three tables may be rendered incrementally.
<table>
<colgroup span="3"/>
<tr><td> ... </td></tr>
...rows...
</table>
<table>
<colgroup>
<col/>
<col span="2"/>
</colgroup>
<tr><td> ... </td></tr>
...rows...
</table>
<table>
<colgroup>
<col/>
</colgroup>
<colgroup span="2"/>
<tr><td> ... </td></tr>
...rows...
</table>
<table>
<tr>
<td/><td/><td/>
</tr>
</table>
Content developers may specify column widths in three ways:
However, if the table does not have a fixed width, user agents must receive all table data before they can determine the horizontal space required by the table. Only then may this space be allotted to proportional columns.
If a content developer specifies no width information for a column, a user agent may not be able to incrementally format the table since it must wait for the entire column of data to arrive in order to allot an appropriate width.
If column widths prove to be too narrow for the contents of a particular table cell, user agents may choose to reflow the table.
The table in this example contains six columns. The first one does not belong to an explicit column group. The next three belong to the first explicit column group and the last two belong to the second explicit column group. This table cannot be formatted incrementally since it contains proportional column width specifications and no value for the width attribute for the TABLE element.
Once the (visual) user agent has received the table's data, the available horizontal space will be alloted by the user agent as follows: First the user agent will allot 30 pixels to columns one and two. Then, the minimal space required for the third column will be reserved. The remaining horizontal space will be divided into six equal portions (since 2* + 1* + 3* = 6 portions). Column four (2*) will receive two of these portions, column five (1*) will receive one, and column six (3*) will receive three.
<table>
<colgroup>
<col width="30"/>
</colgroup>
<colgroup>
<col width="30"/>
<col width="0*"/>
<col width="2*"/>
</colgroup>
<colgroup align="center">
<col width="1*"/>
<col width="3*" align="char" char=":"/>
</colgroup>
<thead>
<tr><td> ...</td></tr>
</thead>
...rows...
</table>
We have set the value of the align attribute in the third column group to "center". All cells in every column in this group will inherit this value, but may override it. In fact, the final COL does just that, by specifying that every cell in the column it governs will be aligned along the ":" character.
In the following table, the column width specifications allow the user agent to format the table incrementally:
<table width="200">
<colgroup span="10" width="15"/>
<colgroup width="*">
<col id="penultimate-column"/>
<col id="last-column"/>
</colgroup>
<thead>
<tr><td> ... </td></tr>
</thead>
...rows...
</table>
The first ten columns will be 15 pixels wide each. The last two columns will each receive half of the remaining 50 pixels. Note that the COL elements appear only so that an id value may be specified for the last two columns.
Note. Although the width attribute on the TABLE element is not deprecated, authors are encouraged to use style sheets to specify table widths.
<!ENTITY % colgroup.elements "(col | event)*"> <!ELEMENT colgroup %col.elements -- table column group --> <!ATTLIST colgroup %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- span CDATA 1 -- default number of columns in group -- width %multilength #IMPLIED -- default width for enclosed COLs -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attribute definitions
User agents must ignore this attribute if the COLGROUP element contains one or more COL elements.
This attribute is overridden for any column in the column group whose width is specified via a COL element.
Attributes defined elsewhere
The COLGROUP element creates an explicit column group. The number of columns in the column group may be specified in two, mutually exclusive ways:
The advantage of using the span attribute is that content developers may group together information about column widths. Thus, if a table contains forty columns, all of which have a width of 20 pixels, it is easier to write:
<colgroup span="40" width="20"/>
than:
<colgroup>
<col width="20"/>
<col width="20"/>
...a total of forty COL elements...
</colgroup>
When it is necessary to single out a column (e.g., for style information, to specify width information, etc.) within a group, content developers must identify that column with a COL element. Thus, to apply special style information to the last column of the previous table, we single it out as follows:
<colgroup width="20"> <col span="39"/> <col id="format-me-specially"/> </colgroup>
The width attribute of the COLGROUP element is inherited by all 40 columns. The first COL element refers to the first 39 columns (doing nothing special to them) and the second one assigns an id value to the fortieth columns so that style sheets may refer to it.
The table in the following example contains two column groups. The first column group contains 10 columns and the second contains 5 columns. The default width for each column in the first column group is 50 pixels. The width of each column in the second column group will be the minimum required for that column.
<table>
<colgroup span="10" width="50"/>
<colgroup span="5" width="0*"/>
<thead>
<tr><td> ... </td></tr>
</thead>
</table>
<!ENTITY % table.elements "(caption?, (col*|colgroup*), event*, thead?, tfoot?, tbody+)"> <!ELEMENT table %table.elements -- table element --> <!ATTLIST table %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- summary CDATA #IMPLIED -- purpose/structure for speech output-- rules %trules #IMPLIED -- rulings between rows and cols -- cellspacing %length #IMPLIED -- spacing between cells -- cellpadding %length #IMPLIED -- spacing within cells -- >
Attribute definitions
Attributes defined elsewhere
The border and frame attributes have been deprecated in favor of style sheet properties.
The cellspacing and cellpadding attributes control spacing between and within cells.
In the following example, the cellspacing attribute specifies that cells should be separated from each other and from the table frame by twenty pixels. The cellpadding attribute specifies that the top margin of the cell and the bottom margin of the cell will each be separated from the cell's contents by 10% of the available vertical space (the total being 20%). Similarly, the left margin of the cell and the right margin of the cell will each be separated from the cell's contents by 10% of the available horizontal space (the total being 20%).
<table cellspacing="20" cellpadding="20%"> <tr> <td>Data1 </td><td>Data2 </td><td>Data3</td></tr> </table>
If a table or given column has a fixed width, cellspacing and cellpadding may demand more space than assigned. User agents may give these attributes precedence over the width attribute when a conflict occurs, but are not required to.
The TABLE element contains all other elements that specify caption, rows, content, and formatting.
The following informative list describes what operations user agents may carry out when rendering a table:
The HTML table model has been designed so that, with author assistance, user agents may render tables incrementally (i.e., as table rows arrive) rather than having to wait for all the data before beginning to render.
In order for a user agent to format a table in one pass, authors must tell the user agent:
More precisely, a user agent may render a table in a single pass when the column widths are specified using a combination of COLGROUP and COL elements. If any of the columns are specified in relative or percentage terms (see the section on calculating the width of columns), authors must also specify the width of the table itself.
The directionality of a table is either the inherited directionality (the default is left-to-right) or that specified by the dir attribute for the TABLE element.
For a left-to-right table, column zero is on the left side and row zero is at the top. For a right-to-left table, column zero is on the right side and row zero is at the top.
When a user agent allots extra cells to a row (see the section on calculating the number of columns in a table), extra row cells are added to the right of the table for left-to-right tables and to the left side for right-to-left tables.
Note that TABLE is the only element on which dir reverses the visual order of the columns; a single table row (TR) or a group of columns (COLGROUP) cannot be independently reversed.
When set for the TABLE element, the dir attribute also affects the direction of text within table cells (since the dir attribute is inherited by block-level elements).
To specify a right-to-left table, set the dir attribute as follows:
<table dir="RTL"> ...the rest of the table... </table>
The direction of text in individual cells can be changed by setting the dir attribute in an element that defines the cell. Please consult the section on bidirectional text for more information on text direction issues.
<!ENTITY % tbody.elements "(tr)+"> <!ELEMENT tbody %tbody.elements -- table body --> <!ATTLIST tbody %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attributes defined elsewhere
Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
The table head and table foot should contain information about the table's columns. The table body should contain rows of table data.
When present, each THEAD, TFOOT, and TBODY contains a row group. Each row group must contain at least one row, defined by the TR element.
This example illustrates the order and structure of table heads, feet, and bodies.
<table> <thead> <tr> ...header information... </tr> </thead> <tfoot> <tr> ...footer information... </tr> </tfoot> <tbody> <tr> ...first row of block one data... </tr> <tr> ...second row of block one data... </tr> </tbody> <tbody> <tr> ...first row of block two data... </tr> <tr> ...second row of block two data... </tr> <tr> ...third row of block two data... </tr> </tbody> </table>
TFOOT must appear before TBODY within a TABLE definition so that user agents can render the foot before receiving all of the (potentially numerous) rows of data.
The THEAD, TFOOT, and TBODY sections must contain the same number of columns.
<!ENTITY % td.elements "(%flow)*"> <!ELEMENT td %td.elements -- table data cell --> <!ATTLIST td %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- abbr CDATA #IMPLIED -- abbreviation for header cell -- axis CDATA #IMPLIED -- names groups of related headers-- headers CDATA #IMPLIED -- list of id's for header cells -- scope %scope #IMPLIED -- scope covered by header cells -- rowspan CDATA 1 -- number of rows spanned by cell -- colspan CDATA 1 -- number of cols spanned by cell -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attribute definitions
Attributes defined elsewhere
Table cells may contain two types of information: header information and data. This distinction enables user agents to render header and data cells distinctly, even in the absence of style sheets. For example, visual user agents may present header cell text with a bold font. Speech synthesizers may render header information with a distinct voice inflection.
The TH element defines a cell that contains header information. The TD element defines a cell that contains data.
Cells may be empty (i.e., contain no data). For example, the following table contains four columns of data, each headed by a column description.
<table summary="This table charts the number of cups
of coffee consumed by each senator, the type
of coffee (decaf or regular), and whether
taken with sugar.">
<caption>Cups of coffee consumed by each senator</caption>
<tr>
<th>Name</th>
<th>Cups</th>
<th>Type of Coffee</th>
<th>Sugar?</th>
</tr>
<tr>
<td>T. Sexton</td>
<td>10</td>
<td>Espresso</td>
<td>No</td>
</tr>
<tr>
<td>J. Dinnen</td>
<td>5</td>
<td>Decaf</td>
<td>Yes</td>
</tr>
</table>
A user agent rendering to a tty device might display this as follows:
Name Cups Type of Coffee Sugar? T. Sexton 10 Espresso No J. Dinnen 5 Decaf Yes
Cells may span several rows or columns. The number of rows or columns spanned by a cell is set by the rowspan and colspan attributes for the TH and TD elements.
In this table definition, we specify that the cell in row four, column two should span a total of three columns, including the current column.
<table border="1">
<caption>Cups of coffee consumed by each senator</caption>
<tr>
<th>Name</th>
<th>Cups</th>
<th>Type of Coffee</th>
<th>Sugar?</th>
</tr>
<tr>
<td>T. Sexton</td>
<td>10</td>
<td>Espresso</td>
<td>No</td>
</tr>
<tr>
<td>J. Dinnen</td>
<td>5</td>
<td>Decaf</td>
<td>Yes</td>
</tr>
<tr>
<td>A. Soria</td>
<td colspan="3"><em>Not available</em></td>
</tr>
</table>
This table might be rendered on a tty device by a visual user agent as follows:
Cups of coffee consumed by each senator -------------------------------------- | Name |Cups|Type of Coffee|Sugar?| -------------------------------------- |T. Sexton|10 |Espresso |No | -------------------------------------- |J. Dinnen|5 |Decaf |Yes | -------------------------------------- |A. Soria |Not available | --------------------------------------
The next example illustrates (with the help of table borders) how cell definitions that span more than one row or column affect the definition of later cells. Consider the following table definition:
<table border="1">
<tr>
<td>1</td>
<td rowspan="2">2</td>
<td>3</td>
</tr>
<tr>
<td>4</td>
<td>6</td>
</tr>
<tr>
<td>7</td>
<td>8</td>
<td>9</td>
</tr>
</table>
As cell "2" spans the first and second rows, the definition of the second row will take it into account. Thus, the second TD in row two actually defines the row's third cell. Visually, the table might be rendered to a tty device as:
------------- | 1 | 2 | 3 | ----| |---- | 4 | | 6 | ----|---|---- | 7 | 8 | 9 | -------------
while a graphical user agent might render this as:
| 1 | 2 | 3 |
| 4 | 6 | |
| 7 | 8 | 9 |
Note that if the TD defining cell "6" had been omitted, an extra empty cell would have been added by the user agent to complete the row.
Similarly, in the following table definition:
<table border="1">
<tr>
<td>1</td>
<td>2</td>
<td>3</td>
</tr>
<tr>
<td colspan="2">4</td>
<td>6</td>
</tr>
<tr>
<td>7</td>
<td>8</td>
<td>9</td>
</tr>
</table>
cell "4" spans two columns, so the second TD in the row actually defines the third cell ("6"):
------------- | 1 | 2 | 3 | --------|---- | 4 | 6 | --------|---- | 7 | 8 | 9 | -------------
A graphical user agent might render this as:
| 1 | 2 | 3 |
| 4 | 6 | |
| 7 | 8 | 9 |
Defining overlapping cells is an error. User agents may vary in how they handle this error (e.g., rendering may vary).
The following illegal example illustrates how one might create overlapping cells. In this table, cell "5" spans two rows and cell "7" spans two columns, so there is overlap in the cell between "7" and "9":
<table border="1">
<tr>
<td>1</td>
<td>2</td>
<td>3</td>
&lot;/tr>
<tr>
<td>4</td>
<td rowspan="2">5</td>
<td>6</td>
</tr>
<tr>
<td colspan="2">7</td>
<td>9</td>
</tr>
</table>
<!ENTITY % tfoot.elements "(tr)+"> <!ELEMENT tfoot %tfoot.elements -- table footer --> <!ATTLIST tfoot %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attributes defined elsewhere
Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
The table head and table foot should contain information about the table's columns. The table body should contain rows of table data. See the TBODY element for examples of how these elements are used.
<!ENTITY % th.elements "(%flow)*"> <!ELEMENT th %th.elements -- table header cell --> <!ATTLIST th %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- abbr CDATA #IMPLIED -- abbreviation for header cell -- axis CDATA #IMPLIED -- names groups of related headers-- headers CDATA #IMPLIED -- list of id's for header cells -- scope %scope #IMPLIED -- scope covered by header cells -- rowspan CDATA 1 -- number of rows spanned by cell -- colspan CDATA 1 -- number of cols spanned by cell -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attribute definitions
Attributes defined elsewhere
The TH element defines a cell that contains header information. User agents have two pieces of header information available: the contents of the TH element and the value of the abbr attribute. User agents must render either the contents of the cell or the value of the abbr attribute. For visual media, the latter may be appropriate when there is insufficient space to render the full contents of the cell. For non-visual media abbr may be used as an abbreviation for table headers when these are rendered along with the contents of the cells to which they apply.
The headers and scope attributes also allow authors to help non-visual user agents process header information. See the TD element for examples of how the TH element is used.
<!ENTITY % thead.elements "(tr)+"> <!ELEMENT thead %thead.elements -- table header --> <!ATTLIST thead %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- %cellhalign -- horizontal alignment in cells -- %cellvalign -- vertical alignment in cells -- >
Attributes defined elsewhere
Table rows may be grouped into a table head, table foot, and one or more table body sections, using the THEAD, TFOOT and TBODY elements, respectively. This division enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
The table head and table foot should contain information about the table's columns. The table body should contain rows of table data. See the TBODY element for examples of how these elements are used.
<!ENTITY % tr.elements "(th|td)+"> <!ELEMENT tr %tr.elements -- table row --> <!ATTLIST tr %core.attr -- id, class, title, and style -- %i18n.attr -- lang and dir for encapsulated content -- %cellhalign; -- horizontal alignment in cells -- %cellvalign; -- vertical alignment in cells -- >
Attributes defined elsewhere
The TR elements acts as a container for a row of table cells.
This sample table contains three rows, each begun by the TR element:
<table summary="This table charts the number of cups
of coffee consumed by each senator, the type
of coffee (decaf or regular), and whether
taken with sugar.">
<caption>Cups of coffee consumed by each senator</caption>
<tr> ...A header row... </tr>
<tr> ...First row of data... </tr>
<tr> ...Second row of data... </tr>
...the rest of the table...
</table>
This appendix defines the entities, elements, and attributes found in all xHTML profile DTDs. This DTD does not "stand alone", rather it is combined with entities defined in following appendices to define a profile's DTD.
<!ENTITY % URL "CDATA">
<!ENTITY % languagecode "CDATA">
<!ENTITY % core.attr
"id %ID #IMPLIED
class CDATA #IMPLIED
style CDATA #IMPLIED
title CDATA #IMPLIED"
>
<!ENTITY % i18n.attr
"lang %languagecode #IMPLIED
dir (ltr|rtl) #IMPLIED"
>
<!ENTITY % contenttype "CDATA">
<!ENTITY % linktypes "CDATA" -- a space separated list of link types -->
<!ENTITY % charset "CDATA">
<!ENTITY % length "CDATA">
<!ENTITY % pixels "CDATA">
<!ENTITY % formctrl "input | select | textarea | label ">
<!ENTITY % flow "%block | %inline">
<!---------------->
<!ELEMENT a %a.elements -- anchor; a.inline is defined by the profile's DTD -- >
<!ATTLIST a
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
charset %charset #IMPLIED -- char encoding of linked resource --
type %contenttype #IMPLIED -- content type of linked resource --
name CDATA #IMPLIED -- named link end --
href %uri #IMPLIED -- URI for linked resource --
hreflang %languagecode #IMPLIED -- language of linked resource --
rel %linktypes #IMPLIED -- forward link types --
rev %linktypes #IMPLIED -- reverse link types --
restrict CDATA #IMPLIED -- restrict links from forward links --
>
<!ELEMENT base %base.elements -- document base URI -->
<!ATTLIST base
href %url #REQUIRED -- URI that acts as base URI --
>
<!ELEMENT blockquote %blockquote.elements -- long quotation -->
<!ATTLIST blockquote
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of quotation --
cite %uri #IMPLIED -- source URI of quotation --
>
<!ELEMENT body %body.elements -- document body -->
<!ATTLIST body
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT br %br.elements -- forced line break -->
<!ATTLIST br
%core.attr -- id, class, title, and style --
>
<!ELEMENT div %div.elements -- generic language and style container -->
<!ATTLIST DIV
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT head %head.elements -- document head -->
<!ATTLIST head
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT (%heading) %heading.elements -- heading -->
<!ATTLIST (%heading)
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT hr %hr.elements -- horizontal rule -->
<!ATTLIST hr
%core.attr -- id, class, title, and style --
>
<!ELEMENT link %link.elements -- media-independent link -->
<!ATTLIST link
%core.attr -- id, class, title, and style --
%i18n.attr -- language and dir of ???
type CDATA #REQUIRED -- content type of linked resource --
href %URL #REQUIRED -- URI for linked resource --
hreflang %languagecode #IMPLIED -- language of linked resource --
rel %linktype #IMPLIED -- forward content types --
rev %linktype #IMPLIED -- reverse link types --
>
<!ELEMENT meta %meta.elements -- generic metainformation -->
<!ATTLIST meta
%i18n.attr; -- lang and dir for use with content --
http-equiv CDATA #IMPLIED -- HTTP response header name --
name CDATA #IMPLIED -- metainformation name --
content CDATA #REQUIRED -- associated information --
scheme CDATA #IMPLIED -- select form of content --
>
<!ELEMENT object %object.elements -- generic embedded object -->
<!ATTLIST object
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir --
declare (declare) #IMPLIED -- declare but don't instantiate flag --
classid %uri #IMPLIED -- identifies an implementation --
codebase %uri #IMPLIED -- base URI for classid, data, archive--
data %uri #IMPLIED -- reference to object's data --
type %contenttype #IMPLIED -- content type for data --
codetype %contenttype #IMPLIED -- content type for code --
archive %uri #IMPLIED -- space separated archive list --
standby CDATA #IMPLIED -- message to show while loading --
resources CDATA #IMPLIED -- content decoder resource requirements --
remain CDATA #IMPLIED -- list of URIs for object persistence --
>
<!ELEMENT p %p.elements -- paragraph -->
<!ATTLIST p
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT param %param.elements -- named property value -->
<!ATTLIST param
id CDATA #IMPLIED -- document-wide unique id --
name CDATA #REQUIRED -- property name --
value CDATA #IMPLIED -- property value --
valuetype (data|ref|object) "data" -- How to interpret value --
type %contenttype #IMPLIED -- content type for value when valuetype=ref --
>
<!ELEMENT pre %pre.elements -- preformatted text -->
<!ATTLIST pre
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT span %span.elements -- generic language/style container -->
<!ATTLIST span
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT style %style.elements -- style info -->
<!ATTLIST style
%i18n.attr -- lang and dir of title --
type CDATA #IMPLIED -- content type of style language --
media CDATA #IMPLIED -- designed for use with this media --
title CDATA #IMPLIED -- advisory title --
>
<!ELEMENT switch %switch.elements -- switch enclosed content -->
<!ATTLIST switch
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT test %test.elements -- test element -->
<!ATTLIST test
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for value --
disabled (disabled) #IMPLIED -- flag for disabling the test --
name CDATA #IMPLIED -- the name of the test --
value CDATA #IMPLIED -- the value required for the test to succeed --
>
<!ELEMENT title (#PCDATA)* -- document title -->
<!ATTLIST title
%i18n.attr -- lang and dir of document title --
>
<!ELEMENT html (head,body) -- document root element -->
<!ATTLIST html
%i18n.attr -- lang and dir of document --
>
<!-- DOCSET ELEMENTS -->
<!ELEMENT abbr %abbr.elements -- abbreviated form -->
<!ATTLIST abbr
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT acronym %acronym.elements -- acronym form -->
<!ATTLIST acronym
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT bdo %bdo.elements -- I18N BiDi over-ride -->
<!ATTLIST bdo
%core.attr -- id, class, style, title --
lang %languagecode #IMPLIED -- language code --
dir (ltr|rtl) #REQUIRED -- directionality --
>
<!ELEMENT del %del.elements -- deleted text -->
<!ATTLIST del
%core.attr -- id, class, style, and title --
%i18n.attr -- lang and dir for encapsulated content --
cite %uri #IMPLIED -- info on reason for change --
datetime CDATA #IMPLIED -- date and time of change --
>
<!ELEMENT dfn %dfn.elements -- instance definition -->
<!ATTLIST bdo
%core.attr -- id, class, style, title --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT ins %ins.elements -- inserted text -->
<!ATTLIST ins
%core.attr -- id, class, style, and title --
%i18n.attr -- lang and dir for encapsulated content --
cite %uri #IMPLIED -- info on reason for change --
datetime %CDATA #IMPLIED -- date and time of change --
>
<!ELEMENT var %var.elements -- instance of a variable or program element -->
<!ATTLIST var
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT sub %sub.elements -- subscript -->
<!ATTLIST sub
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT sup %sup.elements -- superscript -->
<!ATTLIST sup
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!-- EVENTSET ELEMENTS -->
<!ELEMENT action %action.elements -- invocation of procedural code or scripts -->
<!ATTLIST action
id CDATA #IMPLIED -- document unique identifier for the action --
charset %charset #IMPLIED -- char encoding of linked resource --
type %contenttype #REQUIRED -- content type of action language --
src %uri #IMPLIED -- URI for an external action --
defer (defer) #IMPLIED -- UA may defer execution of script --
>
<!ELEMENT event %event.elements -- recognize an event -->
<!ATTLIST event
id CDATA #IMPLIED -- unique identifier to this event handler --
name CDATA #REQUIRED -- name of the event to respond to --
>
<!ELEMENT noaction %noaction.elements -- alternate content container for non-event based rendering -->
<!ATTLIST noaction
%core.attr -- id, class, type, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!-- FONTSET ELEMENTS -->
<!ELEMENT address %address.elements -- information on author -->
<!ATTLIST address
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT em %em.elements -- emphasis -->
<!ATTLIST em
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT kbd %kbd.elements -- text to be entered by the user -->
<!ATTLIST kbd
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT strong %strong.elements -- strong emphasis -->
<!ATTLIST strong
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!-- FORMSET ELEMENTS -->
<!ELEMENT fieldset %fieldset.elements -- form control group -->
<!ATTLIST FIELDSET
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT form %form.elements -- interactive form -->
<!ATTLIST form
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
action %uri #REQUIRED -- server-side form handler --
method ( get | post ) "get" -- HTTP method used to submit the form--
enctype %contenttype "application/x-www-form-urlencoded"
accept-charset %charsets #IMPLIED -- list of supported charsets --
>
<!ELEMENT input %input.elements -- form control -->
<!ATTLIST input
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
type %inputtype #REQUIRED -- what kind of widget is needed --
name CDATA #IMPLIED -- submit as part of form --
value CDATA #IMPLIED -- required for radio and checkboxes --
checked (checked) #IMPLIED -- for radio buttons and check boxes --
disabled (disabled) #IMPLIED -- unavailable in this context --
readonly (readonly) #IMPLIED -- for text and passwd --
size CDATA #IMPLIED -- specific to each type of field --
maxlength CDATA #IMPLIED -- max chars for text fields --
src %uri #IMPLIED -- for fields with images --
accept %contenttypes #IMPLIED -- list of MIME types for file upload --
>
<!ELEMENT label %label.elements -- control label text -->
<!ATTLIST label
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
for CDATA #IMPLIED -- matches field ID value --
>
<!ELEMENT legend %legend.elements -- fieldset legend -->
<!ATTLIST legend
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
>
<!ELEMENT optgroup %optgroup.elements -- option group -->
<!ATTLIST optgroup
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
disabled (disabled) #IMPLIED -- unavailable in this context --
label CDATA #REQUIRED -- for use in hierarchical menus --
>
<!ELEMENT option %option.elements -- selectable choice -->
<!ATTLIST option
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
selected (selected) #IMPLIED -- is the option selected --
disabled (disabled) #IMPLIED -- unavailable in this context --
label CDATA #IMPLIED -- for use in hierarchical menus --
value CDATA #IMPLIED -- defaults to element content --
>
<!ELEMENT select %select.elements -- option selector -->
<!ATTLIST select
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
name CDATA #IMPLIED -- field name --
size CDATA #IMPLIED -- rows visible --
multiple (multiple) #IMPLIED -- default is single selection --
disabled (disabled) #IMPLIED -- unavailable in this context --
>
<!ELEMENT textarea %textarea.elements -- multi-line text field -->
<!ATTLIST textarea
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir of encapsulated content --
name CDATA #IMPLIED -- field name --
rows CDATA #REQUIRED -- number of visible lines of text in field --
cols CDATA #REQUIRED -- visible width in average character widths
disabled (disabled) #IMPLIED -- unavailable in this context --
readonly (readonly) #IMPLIED -- content is readonly --
>
<!-- FRAMESET -->
<!ENTITY % ialign "(top|middle|bottom|left|right)">
<!ELEMENT frame %frame.elements -- subwindow -->
<!ATTLIST frame
%core.attr -- id, class, title, and style --
longdesc %uri #IMPLIED -- link to long description (complements title) --
name CDATA #IMPLIED -- name of frame for targetting --
src %uri #IMPLIED -- source of frame content --
noresize (noresize) #IMPLIED -- allow users to resize frames? --
scrolling (yes|no|auto) "auto" -- scrollbar or none --
>
<!ELEMENT frameset %frameset.elements -- window subdivision-->
<!ATTLIST frameset
%core.attr -- id, class, title, and style --
rows CDATA #IMPLIED -- list of lengths, default: 100% (1 row) --
cols CDATA #IMPLIED -- list of lengths, default: 100% (1 col) --
>
<!ELEMENT iframe &iframe.elements -- inline subwindow -->
<!ATTLIST iframe
%core.attr -- id, class, style, title --
longdesc %uri #IMPLIED -- link to long description (complements title) --
name CDATA #IMPLIED -- name of frame for targetting --
src %uri #IMPLIED -- source of frame content --
scrolling (yes|no|auto) "auto" -- scrollbar or none --
>
<!ELEMENT noframes %noframes.elements -- alt content container for non frame-based rendering -->
<!ATTLIST noframes
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ENTITY % list "dl | ol | ul ">
<!-- LISTSET ELEMENTS -->
<!ELEMENT dd %dd.elements -- definition description -->
<!ATTLIST dd
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT dl %dl.elements -- definition list -->
<!ATTLIST dl
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT dt %dt.elements -- definition term -->
<!ATTLIST dt
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT li %li.elements -- list item -->
<!ATTLIST li
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT ol %ol.elements -- ordered list -->
<!ATTLIST ol
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT ul %ul.elements -- unordered list -->
<!ATTLIST ul
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!-- TABLESET ELEMENTS -->
<!ENTITY % multilength "CDATA">
<!ENTITY % tframe "(void|above|below|hsides|lhs|rhs|vsides|box|border)">
<!ENTITY % trules "(none | groups | rows | cols | all)">
<!ENTITY % talign "(left|center|right)">
<!ENTITY % scope "(row|col|rowgroup|colgroup)">
<!ENTITY % cellvalign
"valign (top|middle|bottom|baseline) #IMPLIED"
>
<!ENTITY % cellhalign
"align (left|center|right|justify|char) #IMPLIED
char CDATA #IMPLIED -- alignment char, e.g. char=':' --
charoff %length #IMPLIED -- offset for alignment char --"
>
<!ELEMENT caption %caption.elements -- table caption -->
<!ATTLIST caption
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
>
<!ELEMENT col %col.elements -- table column -->
<!ATTLIST col -- column groups and properties --
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
span CDATA 1 -- COL attributes affect N columns --
width %multilength #IMPLIED -- column width specification --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT colgroup %col.elements -- table column group -->
<!ATTLIST colgroup
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
span CDATA 1 -- default number of columns in group --
width %multilength #IMPLIED -- default width for enclosed COLs --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT table %table.elements -- table element -->
<!ATTLIST table -- table element --
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
summary CDATA #IMPLIED -- purpose/structure for speech output--
rules %trules #IMPLIED -- rulings between rows and cols --
cellspacing %length #IMPLIED -- spacing between cells --
cellpadding %length #IMPLIED -- spacing within cells --
>
<!ELEMENT tbody %tbody.elements -- table body -->
<!ATTLIST tbody
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT td %td.elements -- table data cell -->
<!ATTLIST td
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
abbr CDATA #IMPLIED -- abbreviation for header cell --
axis CDATA #IMPLIED -- names groups of related headers--
headers CDATA #IMPLIED -- list of id's for header cells --
scope %scope #IMPLIED -- scope covered by header cells --
rowspan CDATA 1 -- number of rows spanned by cell --
colspan CDATA 1 -- number of cols spanned by cell --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT tfoot %tfoot.elements -- table footer -->
<!ATTLIST tfoot
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT th %th.elements -- table header cell -->
<!ATTLIST th
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
abbr CDATA #IMPLIED -- abbreviation for header cell --
axis CDATA #IMPLIED -- names groups of related headers--
headers CDATA #IMPLIED -- list of id's for header cells --
scope %scope #IMPLIED -- scope covered by header cells --
rowspan CDATA 1 -- number of rows spanned by cell --
colspan CDATA 1 -- number of cols spanned by cell --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT thead %thead.elements -- table header -->
<!ATTLIST thead
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
%cellhalign -- horizontal alignment in cells --
%cellvalign -- vertical alignment in cells --
>
<!ELEMENT tr %tr.elements -- table row -->
<!ATTLIST tr
%core.attr -- id, class, title, and style --
%i18n.attr -- lang and dir for encapsulated content --
%cellhalign; -- horizontal alignment in cells --
%cellvalign; -- vertical alignment in cells --
>
The following DTD should be combined with the xHTML DTD described above.
<!--CORESET--> <!ENTITY % heading "h1 | h2 | h3"> <!ENTITY % phrase "em | strong | kbd" > <!ENTITY % block "p | %heading | %list | pre | div | noevent | blockquote | form | hr | fieldset | address"> <!ENTITY % inline "#PCDATA | %phrase | %formctrl | a | object | br | event | span "> <!ENTITY % linktype "(alternate|stylesheet|start|next|prev|contents|index|glossary|copyright|chapter|section|subsection|appendix|help|bookmark|trailer|titles|credits)"> <!ENTITY % a.elements "(#PCDATA | %phrase | %formctrl | object | br | event | span )*"> <!ENTITY % base.elements "EMPTY"> <!ENTITY % blockquote.elements "(%block | event)+"> <!ENTITY % body.elements "(%block | event )+"> <!ENTITY % br.elements "EMPTY"> <!ENTITY % div.elements "(%block | %inline)*"> <!ENTITY % head.elements "(title,style*,base?,link*)"> <!ENTITY % heading.elements "(%inline)*"> <!ENTITY % hr.elements "event*"> <!ENTITY % link.elements "event*"> <!ENTITY % meta.elements "EMPTY"> <!ENTITY % object.elements "( param | %flow | test )*"> <!ENTITY % p.elements "(%inline)*"> <!ENTITY % param.elements "EMPTY"> <!ENTITY % pre.elements "(#PCDATA | %phrase | %formctrl | a | br | event | span)*"> <!ENTITY % span.elements "(%inline)*"> <!ENTITY % style.elements "(#PCDATA)*"> <!ENTITY % test.elements "object*"> <!ENTITY % title.elements "(#PCDATA)*"> <!--EVENTSET--> <!ENTITY % action.elements "(param)*"> <!ENTITY % event.elements "(action)*"> <!ENTITY % noaction.elements "(%block)+"> <!--FONTSET--> <!ENTITY % address.elements "(%inline)*"> <!ENTITY % em.elements "(%inline)*"> <!ENTITY % kbd.elements "(%inline)*"> <!ENTITY % strong.elements "(%inline)*"> <!ENTITY % sub.elements "(%inline)*"> <!ENTITY % sup.elements "(%inline)*"> <!--FORMSET--> <!ENTITY % fieldset.elements "(#PCDATA, legend, (%flow | event)*)"> <!ENTITY % form.elements "(p | %heading | %list | pre | div | noevent | blockquote | hr | fieldset | address | event")*> <!ENTITY % input.elements "(event)*"> <!ENTITY % inputtype "(text | password | checkbox | radio | submit | reset | file | hidden | image | button)"> <!ENTITY % label.elements "(#PCDATA | %phrase | input | select | textarea | a | object | br | event | span)*" <!ENTITY % legend.elements "(%inline)*"> <!ENTITY % optgroup.elements "(option+, event*)"> <!ENTITY % option.elements "(#PCDATA | event)*"> <!ENTITY % select.elements "((optgroup | option )+, event*)"> <!ENTITY % textarea.elements "(#PCDATA | event)*"> <!--LISTSET--> <!ENTITY % dd.elements "(%flow)*"> <!ENTITY % dl.elements "(dt | dd)+"> <!ENTITY % dt.elements "(%inline)*"> <!ENTITY % li.elements "(%flow)*"> <!ENTITY % ol.elements "(li)+"> <!ENTITY % ul.elements "(li)+">
The following DTD should be combined with the xHTML DTD described above.
<!--CORESET--> <!ENTITY % heading "h1 | h2 | h3"> <!ENTITY % block "p | %heading | %list | pre | div | blockquote | form | hr | fieldset"> <!ENTITY % inline "#PCDATA | %formctrl | a | object | br | span"> <!ENTITY % linktype "EMPTY"> <!ENTITY % a.elements "(#PCDATA | %formctrl | object | br | span)*"> <!ENTITY % base.elements "EMPTY"> <!ENTITY % blockquote.elements "(%block)+"> <!ENTITY % body.elements "(%block)+"> <!ENTITY % br.elements "EMPTY"> <!ENTITY % div.elements "(%block | %inline)*"> <!ENTITY % head.elements "(title,style*,base?,link*)"> <!ENTITY % heading.elements "(%inline)*"> <!ENTITY % hr.elements "EMPTY"> <!ENTITY % link.elements "EMPTY"> <!ENTITY % meta.elements "EMPTY"> <!ENTITY % object.elements "( param | %flow | test)*"> <!ENTITY % p.elements "(%inline)*"> <!ENTITY % param.elements "EMPTY"> <!ENTITY % pre.elements "(#PCDATA | %formctrl | a | br | span)*"> <!ENTITY % span.elements "(%inline)*"> <!ENTITY % style.elements "(#PCDATA)*"> <!ENTITY % test.elements "object*"> <!ENTITY % title.elements "(#PCDATA)*"> <!--FORMSET--> <!ENTITY % fieldset.elements "(#PCDATA, legend, (%flow)*)"> <!ENTITY % form.elements "(p | %heading | %list | pre | div | blockquote | hr | fieldset")*> <!ENTITY % input.elements "NONE"> <!ENTITY % inputtype "(text | password | checkbox | radio | submit | reset | hidden | button)"> <!ENTITY % label.elements "(#PCDATA | input | select | textarea | a | object | br | span)*" <!ENTITY % legend.elements "(%inline)*"> <!ENTITY % optgroup.elements "(option+)"> <!ENTITY % option.elements "(#PCDATA)*"> <!ENTITY % select.elements "(optgroup | option )+"> <!ENTITY % textarea.elements "(#PCDATA)*"> <!--LISTSET--> <!ENTITY % dd.elements "(%flow)*"> <!ENTITY % dl.elements "(dt | dd)+"> <!ENTITY % dt.elements "(%inline)*"> <!ENTITY % li.elements "(%flow)*"> <!ENTITY % ol.elements "(li)+"> <!ENTITY % ul.elements "(li)+">
The following DTD should be combined with the xHTML DTD described above.
<!--CORESET--> <!ENTITY % heading "h1 | h2 | h3 | h4 | h5 | h6"> <!ENTITY % phrase "em | strong | dfn | code | samp | kbd | var | cite | abbr | acronym" > <!ENTITY % block "p | %heading | %list | pre | div | noevent | blockquote | form | hr | table | fieldset | address"> <!ENTITY % inline "#PCDATA | %phrase | %formctrl | a | object | br | event | sub | sup | span | bdo"> <!ENTITY % linktype "(alternate|stylesheet|start|next|prev|contents|index|glossary|copyright|chapter|section|subsection|appendix|help|bookmark|trailer|titles|credits)"> <!ENTITY % a.elements "(#PCDATA | %phrase | %formctrl | object | br | event | sub | sup | span | bdo)*"> <!ENTITY % base.elements "EMPTY"> <!ENTITY % blockquote.elements "(%block | event)+"> <!ENTITY % body.elements "((%block | event )+,( ins | del)*)"> <!ENTITY % br.elements "EMPTY"> <!ENTITY % div.elements "(%block | %inline)*"> <!ENTITY % head.elements "(title,style*,base?,link*)"> <!ENTITY % heading.elements "(%inline)*"> <!ENTITY % hr.elements "event*"> <!ENTITY % link.elements "event*"> <!ENTITY % meta.elements "EMPTY"> <!ENTITY % object.elements "( param | %flow )*"> <!ENTITY % p.elements "(%inline)*"> <!ENTITY % param.elements "EMPTY"> <!ENTITY % pre.elements "(#PCDATA | %phrase | %formctrl | a | br | event | span | bdo)*"> <!ENTITY % span.elements "(%inline)*"> <!ENTITY % style.elements "(#PCDATA)*"> <!ENTITY % switch.elements "(%block | test)*"> <!ENTITY % test.elements "object*"> <!ENTITY % title.elements "(#PCDATA)*"> <!--DOCSET--> <!ENTITY % abbr.elements "(%inline)*"> <!ENTITY % acronym.elements "(%inline)*"> <!ENTITY % bdo.elements "(%inline)*"> <!ENTITY % del.elements "(%flow)*"> <!ENTITY % dfn.elements "(%inline)*"> <!ENTITY % ins.elements "(%flow)*"> <!ENTITY % var.elements "(%inline)*"> <!--EVENTSET--> <!ENTITY % action.elements "(param)*"> <!ENTITY % event.elements "(action)*"> <!ENTITY % noaction.elements "(%block)+"> <!--FONTSET--> <!ENTITY % address.elements "(%inline)*"> <!ENTITY % em.elements "(%inline)*"> <!ENTITY % kbd.elements "(%inline)*"> <!ENTITY % strong.elements "(%inline)*"> <!ENTITY % sub.elements "(%inline)*"> <!ENTITY % sup.elements "(%inline)*"> <!--FORMSET--> <!ENTITY % fieldset.elements "(#PCDATA, legend, (%flow | event)*)"> <!ENTITY % form.elements "(p | %heading | %list | pre | div | noevent | blockquote | hr | table | fieldset | address | event")*> <!ENTITY % input.elements "(event)*"> <!ENTITY % inputtype "(text | password | checkbox | radio | submit | reset | file | hidden | image | button)"> <!ENTITY % label.elements "(#PCDATA | %phrase | input | select | textarea | a | object | br | event | sub | sup | span | bdo)*" <!ENTITY % legend.elements "(%inline)*"> <!ENTITY % optgroup.elements "(option+, event*)"> <!ENTITY % option.elements "(#PCDATA | event)*"> <!ENTITY % select.elements "((optgroup | option )+, event*)"> <!ENTITY % textarea.elements "(#PCDATA | event)*"> <!--FRAMESET--> <!ENTITY % frame.elements "EMPTY"> <!ENTITY % frameset.elements "((frameset | frame)+, (event | noframes)*)"> <!ENTITY % iframe.elements "(%flow)*"> <!ENTITY % noframes.elements "(%flow)*"> <!--LISTSET--> <!ENTITY % dd.elements "(%flow)*"> <!ENTITY % dl.elements "(dt | dd)+"> <!ENTITY % dt.elements "(%inline)*"> <!ENTITY % li.elements "(%flow)*"> <!ENTITY % ol.elements "(li)+"> <!ENTITY % ul.elements "(li)+"> <!--TABLESET--> <!ENTITY % caption.elements "(%inline)*"> <!ENTITY % calign "(top|bottom|left|right)"> <!ENTITY % col.elements "(event)*"> <!ENTITY % colgroup.elements "(col | event)*"> <!ENTITY % table.elements "(caption?, (col*|colgroup*), event*, thead?, tfoot?, tbody+)"> <!ENTITY % tbody.elements "(tr)+"> <!ENTITY % td.elements "(%flow)*"> <!ENTITY % tfoot.elements "(tr)+"> <!ENTITY % th.elements "(%flow)*"> <!ENTITY % thead.elements "(tr)+"> <!ENTITY % tr.elements "(th|td)+">
Style sheets represent a major breakthrough for content developers, expanding their ability to improve the appearance of their presentations. In the scientific environments in which the Web was conceived, people are more concerned with the content of their documents than the presentation. In broadcast television, however, edge-to-edge control of the presentation is a critical feature for content developers.
Style sheets solve many of the layout problems of HTML and at the same time they supersede the limited range of presentation mechanisms in HTML. Style sheets make it easy to specify the amount of white space between text lines, the amount lines are indented, the colors used for the text and the backgrounds, the font size and style, synchronization of media objects, and a host of other details.
xHTML provides support for inline style information and it provides for a single external style sheet for limited cascading style sheet functionality. See the STYLE element and the style attribute for how style is applied.
bHTML style is based on CSS2. The following style properties are added to CSS2:
The accuracy of synchronization between elements in a DIV or SPAN with the synctype property of parallel is generally implementation-dependent. If the sync property is clock, the content decoders will share the same clock.
In bHTML, content decoders will make presentation timing available to other content decoders. If the sync property is frame, the content decoders for the elements will receive the presentation timing information of the "parent" block level object (or the television video). For an MPEG-2 content decoder, the frame may correlate to the MPEG-2 presentation time stamp.
If the sync property is not specified (a don't care condition) or is soft, each element has its own clock, which runs independently of the clocks of other elements with the same style.
The navigation properties describe the order in which certain objects are selected when either a tab, backwards tab, or up-down-left-right tab event occurs. Navigation properties also describe how certain objects may be selected through keyboard shortcuts and other accessibility options.
The tabbing order defines the order in which elements will receive focus when navigated by the user via the keyboard or remote control. The tabbing order may include elements nested within other elements.
Elements that may receive focus should be navigated by user agents according to the following rules:
The following elements automatically support the tabindex property: A, AREA, INPUT, OBJECT, SELECT, and TEXTAREA. In other words, if the tabindex property these elements is not specified, the tabindex is considered to be "0".
In this example, the tabbing order will be the pushbutton, the form's three INPUT elements in order (note that "field1" and the button share the same tabindex, but "field1" appears later in the character stream), and finally the link created by the A element. The "up" tab always navigates to the A element (at the top of the presentation) and the "down" tab always navigates the submit button.
<bhtml> <head> <title>A presentation with FORM</title> </head> <body> ...some text... <p>Go to the <a style="tabindex: 10; up: 10; down: 3" href="dsm-cc://t6-3/">Gateway site.</a></p> ...some more... <input style="tabindex: 1; up:10; down:3" type="button" name="get-database"> <event type="onclick"> <object src="get-database"/> </event> Get the current database. </input> ...some more... <form action="..." method="post"> <p> <input style="tabindex: 1; up: 10; down: 3" type="text" name="field1"/> <input style="tabindex: 2; up: 10; down: 3" type="text" name="field2"/> <input style="tabindex: 3; up: 10; down: 3" type="submit" name="submit"/> </p> </form> </body> </bhtml>
The actual key sequence that causes tabbing navigation or element activation depends on the configuration of the user agent (e.g., the "tab" and "arrow" keys are used for navigation, and the "enter" key is used to activate a selected element).
User agents may also define key sequences to navigate the tabbing order in reverse. When the end (or beginning) of the tabbing order is reached, user agents may circle back to the beginning (or end).
Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.
The following elements support the accesskey attribute: A, INPUT, LABEL, LEGEND, and TEXTAREA.
This example assigns the access key "U" to a label associated with an INPUT control. Typing the access key gives focus to the label which in turn gives it to the associated control. The user may then enter text into the INPUT area.
<form action="..." method="post">> <p> <label for="fuser" style="accesskey: U"> User Name </label> <input type="text" name="user" id="fuser"> </p> </form>
The invocation of access keys depends on the underlying system. For instance, on machines running Microsoft Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.
The rendering of access keys depends on the user agent. We recommend that content developers include the access key in label text or wherever the access key is to apply. User agents should render the value of an access key in such a way as to emphasize its role and to distinguish it from other characters (e.g., by underlining it).
Content developers should be aware that there is no requirement for a bHTML receiver to have an input device that provides the access key. If the receiver does not provide access keys, the user agent on that platform is not required to render the value of the access key.
This appendix contains the complete Java binding for the BHTML and BSS (Broadcast Style Sheets) document object model. The definitions are divided into Core, BSS, and BHTML.
public static final int INDEX_SIZE_ERR = 1;
public static final int WSTRING_SIZE_ERR = 2;
public static final int HIERARCHY_REQUEST_ERR = 3;
public static final int WRONG_DOCUMENT_ERR = 4;
public static final int INVALID_NAME_ERR = 5;
public static final int NO_DATA_ALLOWED_ERR = 6;
public static final int NO_MODIFICATION_ALLOWED_ERR = 7;
public static final int NOT_FOUND_ERR = 8;
public static final int NOT_SUPPORTED_ERR = 9;
public static final int INUSE_ATTRIBUTE_ERR = 10;
public abstract class DOMException extends RuntimeException {
public DOMException( int code, String message ) {
super( message );
this.code = code;
}
public static final int INDEX_SIZE_ERR = 1;
public static final int WSTRING_SIZE_ERR = 2;
public static final int HIERARCHY_REQUEST_ERR = 3;
public static final int WRONG_DOCUMENT_ERR = 4;
public static final int INVALID_NAME_ERR = 5;
public static final int NO_DATA_ALLOWED_ERR = 6;
public static final int NO_MODIFICATION_ALLOWED_ERR = 7;
public static final int NOT_FOUND_ERR = 8;
public static final int NOT_SUPPORTED_ERR = 9;
public static final int INUSE_ATTRIBUTE_ERR = 10;
public int code;
}
public interface DOMImplementation {
public boolean hasFeature( String feature, String version };
}
public interface DocumentFragment extends Node {
}
public interface Document extends Node {
public DocumentType getDocType();
public DOMImplementation getImplementation();
public Element getDocumentElement();
public Element createElement( String tagName ) throws DOMException;
public DocumentFragment createDocumentFragment();
public Text createTextNode( String data );
public Comment createComment( String data );
public CDATASection createCDATASection( String data ) throws DOMException;
public ProcessingInstruction createProcessing Instruction( String target, String data ) throws DOM Exception;
public Attribute createAttribute( String name ) throws DOMException;
public EntityReference createEntityReference( String name ) throws DOMException;
public NodeList getElementsByTagName( String tagName );
}
public interface Node {
public static final short ELEMENT_NODE = 1;
public static final short ATTRIBUTE_NODE = 2;
public static final short TEXT_NODE = 3;
public static final short CDATA_SECTION_NODE = 4;
public static final short ENTITY_REFERENCE_NODE = 5;
public static final short ENTITY_NODE = 6;
public static final short PROCESSING_INSTRUCTION_NODE = 7;
public static final short COMMENT_NODE = 8;
public static final short DOCUMENT_NODE = 9;
public static final short DOCUMENT_TYPE_NODE = 10;
public static final short DOCUMENT_FRAGMENT_NODE = 11;
public static final short NOTATION_NODE = 12;
public String getNodeName();
public String getNodeValue();
public void setNodeValue( String arg );
public short getNodeType();
public Node getParentNode();
public NodeList getChildNodes();
public Node getFirstChild();
public Node getLastChild();
public Node getPreviousSibling();
public Node getNextSibling();
public NamedNodeMap getAttributes();
public Document getOwnerDocument();
public Node insertBefore( Node newChild, Node refChild ) throws DOMException;
public Node replaceChild( Node newChild, Node oldChild ) throws DOMException;
public Node removeChild( Node oldChild ) throws DOMException;
public Node appendChild( Node newChild ) throws DOMException;
public boolean hasChildNodes();
public Node cloneNode( boolean deep );
}
public interface NodeList {
public Node item( int index );
public int getLength();
}
public interface NamedNodeMap {
public Node getNamedItem( String name );
public Node setNamedItem( Node arg ) throws DOMException;
public Node removeNamedItem( String name ) throws DOMException;
public Node item( int index );
public int getLength();
}
public interface CharacterData extends Node {
public String getData();
public void setData( String arg );
public int getLength();
public String substringData( int offset, int count ) throws DOMException;
public void appendData( String arg ) throws DOMException;
public void insertData( int offset, String arg ) throws DOMException;
public void deleteData( int offset, int count ) throws DOMException;
public void replaceData( int offset, int count, String arg ) throws DOMException;
}
public interface Attribute extends Node {
public String getName();
public boolean getSpecified();
public String getValue();
public void setValue( String arg );
}
public interface Element extends Node {
public String getTagName();
public String getAttribute( String name );
public String setAttribute( String name, String value ) throws DOMException;
public void removeAttribute( String name ) throws DOMException;
public Attribute getAttributeNode( String name );
public Attribute setAttributeNode( Attribute newAttr ) throws DOMException;
public Attribute removeAttributeNode( Attribute oldAttr ) throws DOMException;
public NodeList getElementsByTagName( String name );
public void normalize();
}
public interface Text extends CharacterData {
public Text splitText( int offset ) throws DOMException;
}
public interface Comment extends CharacterData {
}
public interface ProcessingInstruction extends Node {
public String getTarget();
public String getData();
public void setData( String arg );
}
public interface CDATASection extends Text {
}
public interface DocumentType extends Node {
public String getName();
public NamedNodeMap getEntities();
public NamedNodeMap getNotations();
}
public interface Notation extends Node {
public String getPublicId();
public String getSystemId();
}
public interface Entity extends Node {
public String getPublicId();
public String getSystemId();
public String getNotationName();
}
public interface EntityReference extends Node {
}
public interface BSSCollection {
public int getLength();
public Node item( int index );
public Node namedItem( String name );
}
public interface BSSProperties extends Element{
public String getClassName();
public void setClassName( String arg );
}
public interface BSSFontProperties extends BSSProperties {
public String getFontFamily();
public void setFontFamily( String arg );
public String getFontStyle();
public void setFontStyle( String arg );
public String getFontWeight();
public void setFontWeight( String arg );
public String getFontSize();
public void setFontSize( String arg );
}
public interface BSSColorProperties extends BSSProperties {
public String getColor();
public void setColor( String arg );
public String getFontColor();
public void setFontColor();
public String getBackgroundColor();
public void setBackgroundColor( String arg );
public String getBackgroundImage();
public void setBackgroundImage( String arg );
public String getTransparencyColorkey();
public void setTransparencyColorkey( String arg );
public String getBackgroundRepeat();
public void setBackgroundRepeat( String arg );
public String getBackgroundPosition();
public void setBackgroundPosition( String arg );
public String getTransition();
public void setTransition( String arg );
public String getTransitionStyle();
public void setTransitionStyle( String arg );
public int getTransitionDuration();
public void setTransitionDuration( int arg );
}
public interface BSSTextProperties extends BSSProperties {
public String getWordSpacing();
public void setWordSpacing( String arg );
public String getLetterSpacing();
public void setLetterSpacing( String arg );
public String getVerticalAlign();
public void setVerticalAlign( String arg );
public String getTextAlign();
public void setTextAlign( String arg );
public String getTextIndent();
public void setTextIndent( String arg );
public String getLineHeight();
public void setLineHeight( String arg );
}
public interface BSSBoxProperties extends BSSProperties {
public String getMargin();
public void setMargin( String arg );
public String getBorderColor();
public void setBorderColor( String arg );
public String getBorderStyle();
public void setBorderStyle( String arg );
public String getBorderWidth();
public void setBorderWidth( String arg );
public String getPadding();
public void setPadding( String arg );
public String getPosition();
public void setPosition( String arg );
public String getTop();
public void setTop( String arg );
public String getLeft();
public void setLeft( String arg );
public String getBottom();
public void setBottom( String arg );
public String getRight();
public void setRight( String arg );
public String getWidth();
public void setWidth( String arg );
public String getHeight();
public void setHeight( String arg );
public String getScaleOrCrop();
public void setScaleOrCrop( String arg );
public String getToSafeTitle();
public void setToSafeTitle( String arg );
public String getVisibility();
public void setVisibility( String arg );
public String getZIndex();
public void setZIndex( String arg );
}
public interface BSSClassificationProperties extends BSSProperties {
public String getWhiteSpace();
public void setWhiteSpace( String arg );
public String getListStyleType();
public void setListStyleType( String arg );
public String getListStyleImage();
public void setListStyleImage( String arg );
public String getListStylePosition();
public void setListStylePosition( String arg );
public String getCursor();
public void setCursor( String arg );
}
public interface BSSAudioProperties extends BSSProperties {
public String getAudioChannel();
public void setAudioChannel( String arg );
public String getVolume();
public void setVolume( String arg );
}
public interface BSSNavigationProperties extends BSSProperties {
public int getTabIndex();
public void setTabIndex( int arg );
public int getTabUp();
public void setTabUp( int arg );
public int getTabDown();
public void setTabDown( int arg );
public int getTabLeft();
public void setTabLeft( int arg );
public int getTabRight();
public void setTabRight( int arg );
public String getAccessKey();
public void setAccessKey( String arg );
}
public interface BSSMediaSyncProperties extends BSSProperties {
public String getBegin();
public void setBegin( String arg );
public String getDur();
public void setDur( String arg );
public String getEnd();
public void setEnd( String arg );
public String getEndSync();
public void setEndSync( String arg );
public String getRepeat();
public void setRepeat( String arg );
public String getSyncType();
public void setSyncType( String arg );
public String getSync();
public void setSyncType( String arg );
}
public interface BSSOverflowProperties extends BSSProperties {
public boolean getOverflow();
public void setOverflow( boolean arg );
public String getClip();
public void setClip( String arg );
}
public interface BHTMLCollection{
public int getLength();
public Node item( int index );
public Node namedItem( String name );
}
public interface BHTMLDocument extends Document {
public String getTitle();
public void setTitle();
public String getReferrer();
public String getDomain();
public String getURL();
public BHTMLElement getBody();
public void setBody( BHTMLElement arg );
public BHTMLCollection getObjects();
public BHTMLCollection getLinks();
public BHTMLCollection getForms();
public BHTMLCollection getAnchors();
public void open();
public void close();
public void write( String text );
public void writeln( String text );
public void getElementById( String elementId );
public void getElementsByName( String elementName );
}
public interface BHTMLElement extends Element {
public String getId();
public void setId( String arg );
public String getTitle();
public void setTitle( String arg );
public String getLang();
public void setLang( String arg );
public String getDir();
public void setDir( String arg );
public BSSCollection getStyle();
public void setStyle( BHTMLCollection arg );
public String getClassName();
public void setClassName( String arg );
}
public interface BHTMLBhtmlElement extends BHTMLElement {
public String getVersion();
public void setVersion( String arg );
}
public interface BHTMLHeadElement extends BHTMLElement {
public String getProfile();
public void setProfile( String arg );
}
public interface BHTMLLinkElement extends BHTMLElement {
public String getCharset();
public void setCharset( String arg );
public String getHref();
public void setHref( String arg );
public String getHreflang();
public void setHreflang( String arg );
public String getType();
public void setType( String arg );
public String getRel();
public void setRel( String arg );
public String getRev();
public void setRev( String arg );
public String getTarget();
public void setTarget( String arg );
}
public interface BHTMLTitleElement extends BHTMLElement {
public String getText();
public void setText( String arg );
}
public interface BHTMLBaseElement extends BHTMLElement {
public String getHref();
public void setHref( String arg );
public String getTarget();
public void setTarget( String arg );
}
public interface BHTMLStyleElement extends BHTMLElement {
public String getType();
public void setType( String arg );
}
public interface BHTMLBodyElement extends BHTMLElement {
}
public interface BHTMLFormElement extends BHTMLElement {
public BHTMLCollection getElements();
public void setElements( BHTMLCollection arg );
public int getLength();
public String getAction();
public void setAction( String arg );
public String getMethod();
public void setMethod( String arg );
public String getEnctype();
public void setEnctype( String arg );
public String getAcceptCharset();
public void setAcceptCharset( String arg );
public String getAccept();
public void setAccept( String arg );
public String getTarget();
public void setTarget( String arg );
public void submit();
public void reset();
}
public interface BHTMLSelectElement extends BHTMLElement {
public int getSelectedIndex();
public void setSelectedIndex( int arg );
public String getValue();
public void setValue( String arg );
public int getLength();
public void setLength( int arg );
public BHTMLFormElement getForm();
public BHTMLCollection getOptions();
public void setOptions( BHTMLCollection arg );
public String getName();
public void setName( String arg );
public int getSize();
public void setSize( int arg );
public boolean getMultiple();
public void setMultiple( boolean arg );
public boolean getDisabled();
public void setDisabled( boolean arg );
public void add( BHTMLElement element, BHTMLElement before );
public void remove( int index );
public void doEvent( BHTMLEventElement arg );
}
public interface BHTMLOptGroupElement extends BHTMLElement {
public BHTMLFormElement getForm();
public String getLabel();
public void setLabel( String arg );
public boolean getReadOnly();
public void setReadOnly( boolean arg );
public boolean getDisabled();
public void setDisabled( boolean arg );
}
public interface BHTMLOptionElement extends BHTMLElement {
public BHTMLFormElement getForm();
public boolean getDefaultSelected();
public void setDefaultSelected( boolean arg );
public boolean getSelected();
public void setSelected( boolean arg );
public String getValue();
public void setValue( String arg );
public String getLabel();
public void setLabel( String arg );
public String getText();
public int getIndex();
public void setIndex( int arg );
public boolean getDisabled();
public void setDisabled( boolean arg );
}
public interface BHTMLInputElement extends BHTMLElement {
public String getDefaultValue();
public void setDefaultValue( String arg );
public boolean getDefaultChecked();
public void setDefaultChecked( boolean arg );
public BHTMLFormElement getForm();
public String getType();
public String getName();
public void setName( String arg );
public String getValue();
public void setValue( String arg );
public String getSize();
public void setSize( String arg );
public int getMaxLength();
public void setMaxLength( int arg );
public boolean getChecked();
public void setChecked( boolean arg );
public String getSrc();
public void setSrc( String src );
public String getAccept();
public void setAccept( String arg );
public boolean getReadOnly();
public void setReadOnly( boolean arg );
public String getType();
public void doEvent( BHTMLEventElement arg );
}
public interface BHTMLTextAreaElement extends BHTMLElement {
public String getDefaultValue();
public void setDefaultValue( String arg );
public BHTMLFormElement getForm();
public String getName();
public void setName( String arg );
public int getRows();
public void setRows( int arg );
public int getCols();
public void setCols( int arg );
public boolean getReadOnly();
public void setReadOnly( boolean arg );
public boolean getDisabled();
public void setDisabled( boolean arg );
public void doEvent( BHTMLEventElement arg );
}
public interface BHTMLLabelElement extends BHTMLElement {
public BHTMLFormElement getForm();
public String getBhtmlFor();
public void setBhtmlFor( String arg );
}
public interface BHTMLFieldSetElement extends BHTMLElement {
public BHTMLFormElement getForm();
}
public interface BHTMLLegendElement extends BHTMLElement {
public BHTMLFormElement getForm();
}
public interface BHTMLUListElement extends BHTMLElement {
}
public interface BHTMLOListElement extends BHTMLElement {
}
public interface BHTMLDListElement extends BHTMLElement {
}
public interface BHTMLLIElement extends BHTMLElement {
}
public interface BHTMLBlockquoteElement extends BHTMLElement {
}
public interface BHTMLDivElement extends BHTMLElement {
}
public interface BHTMLParagraphElement extends BHTMLElement {
}
public interface BHTMLHeadingElement extends BHTMLElement {
}
public interface BHTMLPreElement extends BHTMLElement {
}
public interface BHTMLBRElement extends BHTMLElement {
}
public interface BHTMLAnchorElement extends BHTMLElement {
public String getName();
public void setName( String arg );
public String getHref();
public void setHref( String arg );
public String getHreflang();
public void setHreflang( String arg );
public String getType();
public void setType( String arg );
public String getRel();
public void setRel( String arg );
public String getRev();
public void setRev( String arg );
public String getRestrict();
public void setRestrict( String arg );
public String getCharset();
public void setCharset( String arg );
public String getTarget();
public void setTarget( String arg );
public void doEvent( BHTMLEventElement arg );
}
public interface BHTMLObjectElement extends BHTMLElement {
public BHTMLFormElement getForm();
public String getClassId();
public void setClassId( String arg );
public String getCodeBase();
public void setCodeBase( String arg );
public String getCodeType();
public void setCodeType( String arg );
public String getData();
public void setData( String arg );
public String getType();
public void setType();
public String getResources();
public void setResources( String arg );
public String getArchive();
public void setArchive( String arg );
public String getRemain();
public void setRemain( String arg );
}
public interface BHTMLParamElement extends BHTMLElement {
public String getName();
public void setName( String arg );
public String getValue();
public void setValue( String arg );
public String getValueType();
public void setValueType( String arg );
public String getType();
public void setType( String arg );
}
public interface BHTMLActionElement extends BHTMLElement {
public String getName();
public void setName( String arg );
public String getSrc();
public void setSrc( String arg );
public String getType();
public void setType( String arg );
}
public interface BHTMLEventElement extends BHTMLElement {
public String getName();
public void setName( String arg );
}
xHTML provides a set of elements and attributes that is based on HTML 4.0. These elements are partitioned in a collection of DTD Sets. bHTML is a profile of xHTML that contains a subset of these sets, a subset of xHTML style properties, a set of predefined event types, a set of predefined test types, a set of default content decoders, and a specification of which element attributes are recognized, their default values, and any other constraints.
The bHTML profile supports the following DTD sets:
The bHTML profile does not support the docset, frameset, or tableset. The following table specifies the elements and attributes recognized by bHTML.
| Element | Attribute | Valid? | Notes |
|---|---|---|---|
| %core | id | yes | |
| class | yes | ||
| style | yes | ||
| title | yes | ||
| %i18n | lang | yes | |
| dir | ignored | ||
| A | %core | yes | |
| %i18n | yes | ||
| charset | ignored | ||
| type | yes | ||
| name | yes | ||
| href | yes | ||
| hreflang | ignored | ||
| rel | ignored | ||
| rev | ignored | ||
| restrict | yes | default value is "none" | |
| ADDRESS | %core | yes | |
| %i18n | yes | ||
| ACTION | %core | yes | |
| %i18n | yes | ||
| charset | ignored | ||
| type | yes | application/java | |
| src | yes | ||
| defer | yes | ||
| BASE | href | yes | |
| BLOCKQUOTE | %core | yes | |
| %i18n | yes | ||
| cite | yes | ||
| BODY | %core | yes | |
| %i18n | yes | ||
| BR | %core | yes | |
| DD | %core | yes | |
| %i18n | yes | ||
| DL | %core | yes | |
| %i18n | yes | ||
| DT | %core | yes | |
| %i18n | yes | ||
| DIV | %core | yes | |
| %i18n | yes | ||
| EM | %core | yes | |
| %i18n | yes | ||
| EVENT | %core | yes | |
| %i18n | yes | ||
| name | yes | see below | |
| FIELDSET | %core | yes | |
| %i18n | yes | ||
| FORM | %core | yes | |
| %i18n | yes | ||
| action | yes | receiver-side only unless there is a return channel | |
| method | yes | ||
| enctype | yes | ||
| accept-charset | ignored | ||
| HEAD | %i18n | yes | |
| Hn | %core | yes | H4-H6 are ignored |
| %i18n | yes | ||
| HR | %core | yes | |
| INPUT | %core | yes | |
| %i18n | yes | ||
| type | yes | ||
| name | yes | ||
| value | yes | ||
| checked | yes | ||
| disabled | yes | ||
| readonly | yes | ||
| size | yes | ||
| maxlength | yes | ||
| src | yes | ||
| accept | ignored | ||
| KBD | %core | yes | |
| %i18n | yes | ||
| LABEL | %core | yes | |
| %i18n | yes | ||
| for | yes | ||
| LEGEND | %core | yes | |
| %i18n | yes | ||
| LI | %core | yes | |
| %i18n | yes | ||
| LINK | %core | yes | |
| %i18n | yes | ||
| type | ignored | ||
| href | yes | ||
| hreflang | ignored | ||
| rel | yes | alternate, stylesheet, start, next, prev, copyright, help | |
| rev | yes | alternate, stylesheet, start, next, prev, copyright, help | |
| META | %i18n | yes | |
| http-equiv | ignored | ||
| name | yes | ||
| content | yes | ||
| scheme | yes | ||
| NOACTION | %core | yes | |
| %i18n | yes | ||
| OBJECT | %core | yes | |
| %i18n | yes | ||
| declare | yes | ||
| classid | yes | ||
| codebase | yes | ||
| data | yes | ||
| type | yes | ||
| codetype | yes | ||
| archive | yes | ||
| standby | yes | ||
| resources | yes | ||
| remain | yes | ||
| OL | %core | yes | |
| %i18n | yes | ||
| OPTGROUP | %core | yes | |
| %i18n | yes | ||
| disabled | yes | ||
| label | yes | ||
| OPTION | %core | yes | |
| %i18n | yes | ||
| selected | yes | ||
| disabled | yes | ||
| label | yes | ||
| value | yes | ||
| P | %core | yes | |
| %i18n | yes | ||
| PARAM | id | yes | |
| name | yes | ||
| value | yes | ||
| valuetype | yes | ||
| type | yes | ||
| PRE | %core | yes | |
| %i18n | yes | ||
| SELECT | %core | yes | |
| %i18n | yes | ||
| name | yes | ||
| size | yes | ||
| multiple | yes | ||
| disabled | yes | ||
| SPAN | %core | yes | |
| %i18n | yes | ||
| STRONG | %core | yes | |
| %i18n | yes | ||
| STYLE | %i18n | yes | |
| type | yes | text/bss | |
| media | no | ||
| title | yes | ||
| SWITCH | %core | yes | |
| %i18n | yes | ||
| TEST | %core | yes | |
| %i18n | yes | ||
| disabled | yes | ||
| name | yes | see below | |
| value | yes | ||
| TEXTAREA | %core | yes | |
| %i18n | yes | ||
| name | yes | ||
| rows | yes | ||
| cols | yes | ||
| disabled | yes | ||
| readonly | yes | ||
| TITLE | %i18n | yes | |
| UL | %core | yes | |
| %i18n | yes |
The bHTML profile contains the style properties described in the appendix of xHTML Style Properties. The following CSS2 properties are not supported in the bHTML profile:
The EVENT defines a block of behaviors that respond to an event. The name attribute of the EVENT element specifies an event in which their is a behavior. The bHTML profile specifies the following values for the name attribute:
The bHTML profile specifies the following values for the TEST element's name attribute:
The bHTML profile specifies the following content decoders:
The bHTML profile specifies the following link types:
The Java Media Framework (JMF) provides a platform-neutral framework for displaying time-based media. The Java Media Player APIs are designed to support most standard time-based media content types, including MPEG-1, MPEG-2, Quicktime, AVI, WAV, AU, and MIDI.
This time-based media may be synchronized and presented from diverse sources using the Java Media Player APIs. Applications create a Player object that reads data from a DataSource object and renders it at a precise time. In addition to supporting preceise synchronization and presentation of time-based media, the Java Media Framework has an effective mechanism for matching DataSource objects with the appropriate Player object to handle the media to be presented.
First, the applications creates a Player object is created by calling the static method createPlayer in the javax.media.Manager class and passing a MediaLocator object:
javax.media.Manager.createPlayer( MediaLocator sourceLocator );
A MediaLocator object describes the media that the Player will display. A URL can be used for the MediaLocator.
The MediaLocator object supplied to the Manager's createPlayer method identifies the DataSource. The DataSource encapsulates the location of the media, the protocol, and the software used to deliver the media.
Second, the Manager creates a search list of DataSource class names using the protocol name contained in the MediaLocator object. Using each class name in the list, the Manager tries to create an actual DataSource object and open a connection to the location represented by the MediaLocator.
Third, once the Manager has created the correct DataSource for the media, it begins to create the actual Player object.
To create the actual player, the Manager creates a search list of MediaHandler class names using the content name from the DataSource object. Using each class name, the Manager tries to create an actual instance of the MediaHandler class and adds the DataSource object to it. Once the Manager has created the correct MediaHandler for the media by successfully adding the DataSource, the Manager tests to see if it is an instance of Player. If so, the Manager returns the object as a Player object, otherwise the process repeats recursively.
Every Player object created implements the Player interface which extends four interfaces:
The methods defined by the Controller, Duration, and Clock interfaces are not necessary to support non-time based content decoders. Rather, a new interface called Decoder is defined that extends the MediaHandler interface. In addition, a new MediaManager class is defined. The MediaManager class extends the Manager class and contains a createDecoder(MediaLocator) method, similar in function to the Manager.createPlayer(MediaLocator) method but returning a Decoder object.
The previous section explained how the Java Media Framework uses a lookup mechanism to search for the correct DataSource and matching MediaHandler. This mechanism uses Java interfaces to abstract DataSources and MediaHandlers allowing the addition of new DataSources and MediaHandlers.
In searching for DataSources and MediaHandlers, the Manager calls methods that takes the name of the protocol (or content), and constructs a fully qualified classname. For DataSources:
media.protocol.<protocol_name>.DataSource
and for MediaHandlers:
media.content.<content_name>.Handler
This name, and an associated list of package prefixes, is used to create the lists of DataSources and MediaHandlers available for a given protocol and content type. The package prefix is the top level name of the package (such as org.atsc.dase). Thus, the name of an MediaHandler called "mpeg.sys" would be:
org.atsc.dase.media.content.mpeg.sys
Adding a new DataSource or MediaHandler would involves the following steps, as defined in the Java Media Frameworkj specification:
The previous section described how to install new content decoders for time-based streaming media types (audio, video, animations, etc.). A great deal of content is neither streaming (it generally arrives on the receiver as a big chunck of data), or closely associated with time (other than when it is displayed or removed, it does not change with respect to time). The most common example of this type of "static" content are images. This section describes how image content decoders are added.
The same look up method used for time-based media can be efficiently used for adding new content decoders for static images. Additional considerations are needed, though, in order for the static image decoders to be accessed through the conventions of the Java standard graphics class library, the Abstract Windowing Toolkit (AWT).
Consider the java.awt.Image class, which represents a displayable image in a platform independent manner. An Image object is returned by the following methods:
In addition, the following methods are defined as abstract methods. Abstract methods leave the details of how an Image object is retrieved and decoded to the implementation.
In the case of the methods that take URL objects, the URL.getContent() method can be used to obtain an ImageProducer object. This object can then be passed to the Toolkit or Component.createImage(ImageProducer) method to obtain an Image object. The ImageProducer interface represents an image source. The ImageConsumer defines the methods necessary for a class that consumes image data to communicate with a class that produces image data.
The primary methods in generating an Image object are from the Toolkit, ComponentPeer, and AppletContext classes and interface. The ImageProducer interface also plays a key role in abstracting the implementation of decoding a static image.
An ImageDecoder interface extends the aforementioned Decoder interface and the ImageProducer interface. In this way, an ImageDecoder can be created with the DataSource representing the static image. The resulting ImageDecoder can then be used in any Java AWT method supporting the ImageProducer interface. In addition, the MediaManager supports the CreateImageDecoder( ImageLocator ); method which returns an ImageDecoder object. The implementation of all methods returning an Image object use the Java Media Framework lookup mechanism described above.
The following attributes are ignored in xHTML.
| Element | Deprecated Attribute | Note |
| "intrinsic events" | onclick | use EVENT and ACTION |
| ondblclick | use EVENT and ACTION elements | |
| onmousedown | use EVENT and ACTION elements | |
| onmouseup | use EVENT and ACTION elements | |
| onmouseover | use EVENT and ACTION elements | |
| onmousemove | use EVENT and ACTION elements | |
| onmouseout | use EVENT and ACTION elements | |
| onkeypress | use EVENT and ACTION elements | |
| onkeydown | use EVENT and ACTION elements | |
| onkeyup | use EVENT and ACTION elements | |
| A | accesskey | use style |
| shape | use active-region style property | |
| coords | use active-region style property | |
| tabindex | use navigation style proeprties | |
| onfocus | use EVENT and ACTION elements | |
| onblur | use EVENT and ACTION elements | |
| BODY | onload | use EVENT and ACTION elements |
| onunload | use EVENT and ACTION elements | |
| BR | clear | use clear style property |
| DIV | align | use align style property |
| FRAME | frameborder | use style |
| marginwidth | use margin style properties | |
| marginheight | use margin style properties | |
| FRAMESET | onload | use EVENT and ACTION elements |
| onunload | use EVENT and ACTION elements | |
| FORM | onsubmit | use EVENT and ACTION elements |
| onreset | use EVENT and ACTION elements | |
| Hn | align | use align style property |
| INPUT | alt | use title attribute |
| usemap | use A element | |
| tabindex | use navigation style properties | |
| accesskey | use navigation style properties | |
| onfocus | use EVENT and ACTION elements | |
| onblur | use EVENT and ACTION elements | |
| onselect | use EVENT and ACTION elements | |
| onchange | use EVENT and ACTION elements | |
| IFRAME | frameborder | use style |
| marginwidth | use margin style properties | |
| marginheight | use margin style properties | |
| align | use align style property | |
| height | use visual formatting style properties | |
| width | use visual formatting style properties | |
| LABEL | accesskey | use navigation style properties |
| onfocus | use EVENT and ACTION elements | |
| onblur | use EVENT and ACTION elements | |
| LEGEND | accesskey | use navigation style properties |
| OBJECT | height | use visual formatting style properties |
| width | use visual formatting style properties | |
| usemap | use A element | |
| tabindex | use navigation style properties | |
| P | align | use align style property |
| SELECT | tabindex | use navigation style properties |
| onfocus | use EVENT and ACTION elements | |
| onblur | use EVENT and ACTION elements | |
| onchange | use EVENT and ACTION elements | |
| SPAN | align | use align style property |
| TABLE | width | use visual formatting style properties |
| border | use border style properties | |
| frame | use border style properties | |
| TEXTAREA | tabindex | use navigation style properties |
| accesskey | use navigation style properties | |
| onfocus | use EVENT and ACTION elements | |
| onblur | use EVENT and ACTION elements | |
| onselect | use EVENT and ACTION elements | |
| onchange | use EVENT and ACTION elements |