`
`wae
`
`XHTML"™1.0: The Extensible HyperText Markup
`Language
`
`A Reformulation of HTML 4.0 in XML 1.0
`
`W3C Proposed Recommendation 10 December 1999
`
`This version:
`htto://Awww.w3.org/TR/1999/PR-xhtml1-19991210
`(Postscript version, PDF version, ZIP archive, or Gzip'd TAR archive)
`Latest version:
`http:/Awww.w3.org/TR/xhtml1
`Previous versions:
`http://www.w3.org/TR/1999/WD-xhtml1-19991124
`http:/Awww.w3.org/TR/1999/PR-xhtml1-19990824
`Authors:
`See acknowledgements.
`
`
`
`software licensing rules apply.
`
`Abstract
`
`This specification defines XHTML 1.0, a reformulation of HTML 4.0 as an XML 1.0
`application, and three Q'T.Ds corresponding to the ones defined by HTML 4.0. The semantics
`of the elements and their attributes are defined in the W3C Recommendation for HTML 4.0.
`These semantics provide the foundation for future extensibility of XHTML. Compatibility with
`existing HTML user agents is possible by following a small set of guidelines.
`
`Status of this document
`
`This section describes the status of this documentat the time ofits publication. Other
`documents may supersede this document. Thelatest status of this documentseries is
`maintainedat the W3C.
`
`This specification is a Proposed Recommendation of the HTML Working Group. It is a
`
`revision of the Proposed Recommendation dated 24 August 1999 incorporating changes as a
`result of comments from the Proposed Recommendation review, and comments and further
`
`[|rrtetsnsverineesangstewsogmnmySm
`
`1
`
`Exhibit 1039
`Samsung v. DoDots
`IPR2023-00701
`
`1
`
`Exhibit 1039
`Samsung v. DoDots
`IPR2023-00701
`
`
`
`
`On 10 December 1999, this document enters a Proposed Recommendation review period.
`From that date until 8 January 2000, W3C Advisory Committee representatives are
`encouraged to review this specification and return commentsin their completed ballots to
`w3c-html-review@w3.org. Please send any comments of a confidential nature in separate
`email to w3t-html@w3.org, whichis visible to the Team only.
`
`No soonerthan 14 daysafter the end of the review period, the Director will announce the
`document's disposition: it may become a W3C Recommendation (possibly with minor
`changes), it may revert to Working Draft status, or it may be dropped as a W3C workitem.
`
`Publication as a Proposed Recommendation does not imply endorsement by the W3C
`membership. Thisis still a draft document and may be updated, replaced or obsoleted by
`other documentsat any time. It is inappropriate to cite W3C Proposed Recommendation as
`other than "workin progress.”
`
`This document has been producedaspart of the W3C HTML Activity. The goals of the HTML
`Working Group (members only) are discussed in the HTML Working Group charter (members
`only).
`
`Alist of current W3C Recommendations and other technical documents can be found at
`htto:/Avww.w3.oraq/TR.
`
`Public discussion on }{T.Ml, features takes place on the mailing list www-html@ws3.org
`(archive). The W3Cstaff contact for work on HTML is Dave Raggett.
`
`Please report errors in this document to www-html-editor@w3.org.
`
`Thelist of known errors in this specification is available at http://www.w3.org/1999/12/PR-
`xhtml1-19991210-errata.
`
`Contents
`
`1. What is XHTML?
`1.1 What is HTML 4.0?
`1.2 What is XML?
`1.3 Why the need for XHTML?
`2. Definitions
`2.1 Terminology
`2.2 General Terms
`3. Normative Definition of XHTML 1.0
`3.1 Document Conformance
`3.2 User Agent Conformance
`4. Differences with HTML 4.0
`5. Compatibility Issues
`5.1 Internet Media Types
`6. Future Directions
`6.1 ModularizingHTML
`6.2 Subsets and Extensibility
`6.3 Document Profiles
`Appendix A. DTDs
`Appendix B. Element Prohibitions
`
`
`Appendix D. Acknowledgements
`
`2
`
`
`
`Appendix E. References
`
`1. What is XHTML?
`
`XHTML is a family of current and future document types and modulesthat reproduce, subset,
`and extend HTML 4.0 [HTML]. XHTML family document types are XML based, and ultimately
`are designed to work in conjunction with XML-based useragents. The details of this family
`and its evolution are discussed in more detail in the section on Future Directions.
`
`XHTML 1.0 (this specification) is the first document type in the XHTML family.It is a
`reformulation of the three HTML 4.0 documenttypesas applications of XML 1.0 [XML].It is
`intended to be used as a languagefor content that is both XML-conforming and, if some
`simple guidelines are followed, operates in HTML 4.0 conforming user agents. Developers
`who migrate their content to XHTML 1.0 will realize the following benefits:
`
`e XHTML documents are XML conforming. As such, they are readily viewed, edited, and
`validated with standard XML tools.
`e XHTML documents can be written to to operate as well or better than they did before in
`existing HTML 4.0-conforming user agents as well as in new, XHTML 1.0 conforming
`user agents.
`e XHTML documents canutilize applications (e.g. scripts and applets) that rely upon
`either the HTML Document Object Model or the XML Document Object Model [DOM].
`As the XHTML family evolves, documents conforming to XHTML 1.0 will be morelikely
`to interoperate within and among various XHTML environments.
`
`The XHTML family is the next step in the evolution of the Internet. By migrating to XHTML
`today, content developers can enter the XML world with all of its attendant benefits, while still
`remaining confident in their content’s backward and future compatibility.
`
`1.1 What is HTML 4.0?
`
`HTML 4.0 [HTML] is an SGM. (Standard Generalized Markup Language) application
`conformingto International Standard JSO 8879, and is widely regarded as the standard
`publishing language of the World Wide Web.
`
`SGML is a languagefor describing markup languages, particularly those usedin electronic
`document exchange, document management, and document publishing. HTML is an
`exampleof a language defined in SGML.
`
`SGML has been around since the middle 1980's and has remained quite stable. Much ofthis
`stability stems from the fact that the language is both feature-rich and flexible. This flexibility,
`however, comesata price, and that price is a level of complexity that has inhibited its
`adoptionin a diversity of environments, including the World Wide Web.
`
`HTML, as originally conceived, was to be a languagefor the exchange ofscientific and other
`technical documents, suitable for use by non-documentspecialists. HTML addressed the
`problem of SGML complexity by specifying a small set of structural and semantic tags
`suitable for authoring relatively simple documents. In addition to simplifying the document
`structure, HTML added support for hypertext. Multimedia capabilities were addedlater.
`
`In a remarkably short space of time, HTML becamewildly popular and rapidly outgrewits
`original purpose. Since HTML's inception, there has been rapid invention of new elements for
`use within HTML (as a standard) and for adapting HTML to vertical, highly specialized,
`3
`
`3
`
`
`
`markets. This plethora of new elements hasled to compatibility problems for documents
`acrossdifferent platforms.
`
`Asthe heterogeneity of both software and platformsrapidly proliferate,it is clear that the
`suitability of 'classic’ HTML 4.0 for use on these platforms is somewhatlimited.
`
`1.2 What is XML?
`
`XML™is the shorthandfor Extensible Markup Language,andis an acronym of Extensible
`Markup Language [XML].
`
`XML wasconceived as a meansof regaining the powerandflexibility of SGML without most
`of its complexity. Although a restricted form of SGML, XML nonetheless preserves most of
`SGML's powerand richness,andyetstill retains all of SGML's commonly used features.
`
`While retaining these beneficial features, XML removes manyof the more complex features
`of SGML that make the authoring and design of suitable software both difficult and costly.
`
`1.3 Why the need for XHTML?
`
`The benefits of migrating to XHTML 1.0 are described above. Some ofthe benefits of
`migrating to XHTML in general are:
`
`« Document developers and useragent designers are constantly discovering new ways
`to expresstheir ideas through new markup. In XML, it is relatively easy to introduce
`new elements or additional elementattributes. The XHTML family is designed to
`accommodate these extensions through XHTML modulesand techniques for
`developing new XHTML-conforming modules(described in the forthcoming XHTML
`Modularization specification). These moduleswill permit the combination of existing and
`new feature sets when developing content and when designing new useragents.
`e Alternate ways of accessing the Internet are constantly being introduced. Some
`estimates indicate that by the year 2002, 75% of Internet documentviewing will be
`carried out on thesealternate platforms. The XHTML family is designed with general
`user agent interoperability in mind. Through a new user agent and documentprofiling
`mechanism, servers, proxies, and user agents will be able to perform best effort content
`transformation. Ultimately, it will be possible to develop XHTML-conforming content that
`is usable by any XHTML-conforming user agent.
`
`2. Definitions
`
`2.1 Terminology
`
`The following terms are usedin this specification. These terms extendthe definitions in
`[RFC2119] in ways based uponsimilar definitions in ISO/IFG 9945-1:1990 [POSIX.1]:
`
`Implementation-defined
`A value or behavioris implementation-defined whenitis left to the implementation to
`define [and document] the corresponding requirements for correct document
`construction.
`
`May
`
`With respect to implementations, the word "may"is to be interpreted as an optional
`feature that is not required in this specification but can be provided. With respect to
`4
`
`4
`
`
`
`Document Conformance, the word "may" meansthat the optional feature must not be
`used. The term "optional" has the samedefinition as "may".
`
`Must
`
`In this specification, the word "must"is to be interpreted as a mandatory requirement on
`the implementation or on Strictly Conforming XHTML Documents, depending upon the
`context. The term "shall" has the same definition as "must".
`Reserved
`A value or behavior is unspecified, but it is not allowed to be used by Conforming
`Documents nor to be supported by a Conforming User Agents.
`Should
`With respect to implementations, the word "should"is to be interpreted as an
`implementation recommendation, but not a requirement. With respect to documents,
`the word "should"is to be interpreted as recommended programmingpractice for
`documents and a requirementfor Strictly Conforming XHTML Documents.
`Supported
`Certain facilities in this specification are optional. If a facility is supported, it behaves as
`specified by this specification.
`Unspecified
`Whena value or behavior is unspecified, the specification defines no portability
`requirementsfora facility on an implementation even when faced with a documentthat
`usesthe facility. A document that requires specific behavior in such an instance, rather
`than tolerating any behavior whenusingthatfacility, is not a Strictly Conforming XHTML
`Document.
`
`2.2 General Terms
`
`Attribute
`Anattribute is a parameter to an element declared in the DTD. An attribute's type and
`value range, including a possible default value, are defined in the DTD.
`
`DTD
`
`A DTD, or documenttype definition, is a collection of XML declarations that, as a
`collection, defines the legal structure, elements, and attributes that are available for use
`in a documentthat complies to the DTD.
`Document
`Adocumentis a stream of data that, after being combined with any otherstreamsit
`references, is structured such thatit holds information contained within e/ements that
`are organized as defined in the associated DTD. See Document Conformance for more
`information.
`Element
`An element is a documentstructuring unit declared in the DTD. The element's content
`modelis defined in the DTD, and additional semantics may be defined in the prose
`description of the element.
`Facilities
`Functionality includes elements, attributes, and the semantics associated with those
`elements and attributes. An implementation supporting that functionality is said to
`provide the necessary facilities.
`Implementation
`An implementation is a system that providescollection of facilities and services that
`supports this specification. See User Agent Conformance for moreinformation.
`Parsing
`Parsing is the act whereby a documentis scanned, and the information contained
`within the documentis filtered into the context of the elements in which the information
`is structured.
`Rendering
`
`5
`
`
`
`Rendering is the act wherebythe information in a documentis presented. This
`presentation is done in the form most appropriate to the environment(e.g. aurally,
`visually, in print).
`User Agent
`Auseragent is an implementation that retrieves and processes XHTML documents.
`
`See User Agent Conformance for more information.
`Validation
`Validation is a process whereby documentsare verified against the associated DTD,
`ensuring that the structure, use of elements, and useof attributes are consistent with
`the definitions in the DTD.
`Well-formed
`A documentis well-formed whenit is structured according to the rules defined in
`Section 2.1 of the XML 1.0 Recommendation [XML]. Basically, this definition states that
`elements, delimited by their start and end tags, are nested properly within one another.
`
`3. Normative Definition of XHTML 1.0
`
`3.1 Document Conformance
`
`This version of XHTML providesa definition of strictly conforming XHTML documents, which
`are restricted to tags and attributes from the XHTML namespace. See Section 3.1.2 for
`information on using XHTML with other namespaces, for instance, to include metadata
`expressed in RDFwithin XHTML documents.
`
`3.1.1 Strictly Conforming Documents
`
`A Strictly Conforming XHTML Documentis a documentthat requires only thefacilities
`described as mandatory in this specification. Such a document must meetall of the following
`criteria:
`
`1. It must validate against one of the three DTDs found in Appendix A.
`
`2. The root element of the document must be <htmi>.
`
`3. The root element of the document must designate the XHTML namespaceusing the
`xmins attribute [XMLNAMES]. The namespace for XHTML is defined to be
`http: //www.w3.org/1999/xhtm1.
`
`4. There must be a DOCTYPE declaration in the documentprior to the root element. The
`public identifier included in the DOCTYPE declaration must reference one of the three
`DTDs found in Appendix A using the respective Formal Public Identifier. The system
`identifier may be changedto reflect local system conventions.
`
`<!DOCTYPE html
`PUBLIC "-//W3C//DTD XHTML 1.06 Strict//EN"
`"http: //www.w3.org/TR/1999/PR-xhtm11-19991216/DTD/xhtml1-strict.dtd>
`
`<!DOCTYPE html
`PUBLIC "-//W3C//DTD XHTML 1.@ Transitional//EN”
`"http: //www.w3.org/TR/1999/PR-xhtm11-19991210/DTD/xhtml1-transitional.dtd>
`
`<!DOCTYPE html
`PUBLIC "-//W3C//DTD XHTML 1.6 Frameset//EN"
`"http: //www.w3.org/TR/1999/PR-xhtm11-19991216/DTD/xhtml1-frameset .dtd>
`6
`
`6
`
`
`
`Here is an example of a minimal XHTML document.
`
`</html>
`
`<?xml version="1.0" encoding="UTF-8"?>
`<!DOCTYPE html
`PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
`“http: //www.w3.org/TR/1999/PR-xhtm11-19991210/DTD/xhtml1-strict.dtd">
`<html xmlins="http: //www.w3.org/1999/xhtm1l" xml:lang="en" lang="en">
`<head>
`<title>Virtual Library</title>
`</head>
`<body>
`<p>Moved to <a href="http://vlib.org/">vlib.org</a>.</p>
`</body>
`
`Note that in this example, the XML declaration is included. An XML declaration like the one
`aboveis not required in all XML documents. XHTML documentauthors are strongly
`encouraged to use XML declarationsin all their documents. Such a declaration is required
`whenthe character encoding of the documentis other than the default UTF-8 or UTF-16.
`
`3.1.2 Using XHTML with other namespaces
`
`The XHTML namespace maybe used with other XML namespacesas per [XMLNAMES]},
`although such documents are notstrictly conforming XHTML 1.0 documents as defined
`above. Future work by W3Cwill address ways to specify conformance for documents
`involving multiple namespaces.
`
`The following example showsthe way in which XHTML 1.0 could be usedin conjunction with
`the MathML Recommendation:
`
`</html>
`
`<html xmlns="http: //www.w3.org/1999/xhtm1l" xml:lang="en" lang="en">
`<head>
`<title>A Math Example</title>
`</head>
`<body>
`<p>The following is MathML markup:</p>
`<math xmlns="http: //www.w3.org/1998/Math/MathML">
`<apply> <log/>
`<logbase>
`<cen> 3 </cn>
`</logbase>
`<ci> x </ci>
`</apply>
`</math>
`</body>
`
`The following example showsthe wayin which XHTML 1.0 markup could be incorporated
`into another XML namespace:
`
`
`<?xml version="1.0" encoding="UTF-8"?>
`<!-- initially, the default namespace is "books" -->
`<book xmlns='urn:loc.gov: books"
`xmlns : isbn='urn: ISBN: @-395-36341-6' xml:lang="en" lang="en">
`<title>Cheaper by the Dozen</title>
`<isbn: number>1568491379</isbn:number>
`
`7
`
`
`
`<notes>
`<!-- make HTML the default namespace for a hypertext commentary -->
`<p xmlns='http: //www.w3.org/1999/xhtm1" >
`This is also available <a href="http://ww.w3.org/">online</a>.
`
`</p>
`</notes>
`</book>
`
`
`3.2 User Agent Conformance
`
`Aconforming user agent must meetall of the following criteria:
`
`1.
`
`~]
`
`In order to be consistent with the XML 1.0 Recommendation [XML], the user agent
`must parse and evaluate an XHTML documentfor well-formedness. If the user agent
`claims to be a validating user agent, it must also validate documents againsttheir
`referenced DTDs according to [XML].
`
`. Whenthe user agentclaims to support facilities defined within this specification or
`required by this specification through normative reference, it must do so in ways
`consistent with the facilities’ definition.
`. When a user agent processes an XHTML documentas generic XML, it shall only
`recognizeattributes of type 1p (e.g. the id attribute on most XHTML elements) as
`fragmentidentifiers.
`. If a user agent encounters an elementit does not recognize, it must render the
`element's content.
`. If a user agent encountersan attribute it does not recognize, it must ignore the entire
`attribute specification (i.e., the attribute and its value).
`. If a user agent encounters an attribute value it doesn't recognize, it must use the default
`attribute value.
`. If it encounters an entity reference (other than one of the predefined entities) for which
`the User Agent has processed nodeclaration (which could happenif the declaration is
`in the external subset which the User Agent hasn't read), the entity reference should be
`rendered as the characters (starting with the ampersand and ending with the semi-
`colon) that make up the entity reference.
`. When rendering content, User Agents that encounter characters or character entity
`references that are recognized but not renderable should display the document in such
`a waythatit is obvious to the user that normal rendering has not taken place.
`. The following characters are defined in [XML] as whitespace characters:
`o Space ( )
`°o Tab (	)
`o Carriage return (
)
`o Line feed (
)
`
`The XML processornormalizes different system's line end codesinto one single line-
`feed character, that is passed up to the application. The XHTML user agentin addition,
`musttreat the following characters as whitespace:
`
`o Form feed ()
`o Zero-width space (​)
`
`In elements where the 'xml:space’attribute is set to 'preserve’, the user agent must
`leave all whitespace characters intact (with the exception of leading andtrailing
`whitespace characters, which should be removed). Otherwise, whitespace is handled
`according to the following rules:
`
`o All whitespace surrounding block elements should be removed.
`8
`
`8
`
`
`
`°
`
`oOo
`
`o Comments are removedentirely and do not affect whitespace handling. One
`whitespace character on either side of a commentis treated as two white space
`characters.
`Leading andtrailing whitespace inside a block element must be removed.
`Line feed characters within a block element must be converted into a space
`(except whenthe 'xml:space'attribute is set to 'preserve’).
`o Asequence of white space characters must be reduced to a single space
`character (except whenthe 'xml:space'attribute is set to 'preserve’).
`With regard to rendition, the User Agent should renderthe content in a manner
`appropriate to the languagein whichthe contentis written. In languages whose
`primary script is Latinate, the ASCII space characteris typically used to encode
`both grammatical word boundaries and typographic whitespace; in languages
`whosescript is related to Nagari (e.g., Sanskrit, Thai, etc.), grammatical
`boundaries may be encoded using the ZW 'space' character, but will not typically
`be represented by typographic whitespace in rendered output; languages using
`Arabiform scripts may encode typographic whitespace using a space character,
`but may also use the ZW spacecharacter to delimit ‘internal’ grammatical
`boundaries (what look like words in Arabic to an English eye frequently encode
`several words,e.g. 'kitAbuhum' = 'kitAbu-hum' = 'book them' == their book); and
`languagesin the Chinesescript tradition typically neither encode such delimiters
`nor use typographic whitespacein this way.
`
`Whitespacein attribute values is processed according to [XML].
`
`4. Differences with HTML 4.0
`
`Dueto the fact that XHTML is an XML application, certain practices that were perfectly legal
`in SGML-based HTML 4.0 [HTML] must be changed.
`
`4.1 Documents must be well-formed
`
`Well-formedness is a new conceptintroduced by [XML]. Essentially this meansthatall
`elements must either have closing tags or be written in a special form (as described below),
`and thatall the elements must nest.
`
`Although overlappingisillegal in SGML,it was widely tolerated in existing browsers.
`
`<p>here is an emphasized <em>paragraph.</p></em>
`
`CORRECT: nested elements.
`
`<p>here is an emphasized <em>paragraph</em>.</p>
`
`INCORRECT: overlapping elements
`
`4.2 Elementand attribute names must be in lower case
`
`XHTML documents must use lower case for all HTML element and attribute names. This
`difference is necessary because XML is case-sensitive e.g. <li> and <LI> are different tags.
`9
`
`9
`
`
`
`4.3 For non-empty elements, end tags are required
`
`In SGML-based HTML 4.0 certain elements were permitted to omit the end tag; with the
`elements that followed implying closure. This omission is not permitted in XML-based
`XHTML. All elements other than those declared in the DTD as Empty must have an endtag.
`
`CORRECT: terminated elements
`
`p>here is a paragraph.</p><p>here is another paragraph.</p>
`
`INCORRECT: unterminated elements
`
`<p>here is a paragraph.<p>here is another paragraph.
`<table rows=3>
`
`4.4 Attribute values must always be quoted
`
`All attribute values must be quoted, even those which appearto be numeric.
`
`CORRECT: quotedattribute values
`
`table rows="3">
`
`INCORRECT: unquotedattribute values
`
`4.5 Attribute Minimization
`
`XML doesnot support attribute minimization. Attribute-value pairs must be written in full.
`Attribute names such as compact and checked cannot occur in elements without their value
`being specified.
`
`CORRECT: unminimizedattributes
`
`dl compact="compact">
`
`INCORRECT: minimizedattributes
`
`4.6 Empty Elements
`
`Empty elements must either have an end tag orthe start tag must end with />. For instance,
`
`<br/> OF <hr></hr>. See HTML Compatibility Guidelines for information on ways to ensurethis
`10
`
`10
`
`
`
`is backward compatible with HTML 4.0 user agents.
`
`CORRECT: terminated empty tags
`
`<br/><hri/>
`
`<br><hr>
`
`INCORRECT: unterminated empty tags
`
`4.7 Whitespace handling in attribute values
`
`In attribute values, user agents will strip leading andtrailing whitespace from attribute values
`and map sequencesof one or more whitespace characters (including line breaks) to a single
`inter-word space (an ASCII space character for western scripts). See Section 3.3.3 of [XML].
`
`4.8 Script and Style elements
`
`In XHTML, the script and style elements are declared as having #Pcpata content. As a result,
`< and & will be treated as the start of markup, and entities such as &1t; and & will be
`recognized as entity references by the XML processorto < and & respectively. Wrapping the
`contentof the script or style element within a cbata marked section avoids the expansionof
`these entities.
`
`</script>
`
`<script>
`<! [CDATA[
`« unescaped script content ...
`]]>
`
`CDATA sections are recognized by the XML processor and appear as nodesin the Document
`Object Model, see Section 1.3 of the DOM Level 1 Recommendation [DON].
`
`Analternative is to use external script and style documents.
`
`4.9 SGML exclusions
`
`SGML givesthe writer of a DTD the ability to exclude specific elements from being contained
`within an element. Such prohibitions (called "exclusions") are not possible in XML.
`
`For example, the HTML 4.0 Strict DTD forbids the nesting of an ‘a’ element within another‘a’
`element to any descendant depth. It is not possible to spell out such prohibitions in XML.
`Even though these prohibitions cannot be defined in the DTD, certain elements should not be
`nested. Asummary of such elements and the elements that should not be nested in them is
`found in the normative Appendix B.
`
`4.10 The elements with ‘id' and 'name’ attributes
`
`11
`
`11
`
`
`
`HTML 4.0 defined the name attribute for the elementsa, applet, frame, iframe, img, ANd map.
`HTML 4.0 also introduced the id attribute. Both of these attributes are designed to be used
`as fragmentidentifiers.
`
`In XML, fragmentidentifiers are of type 1p, and there can only be a single attribute of type 1p
`per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type rp. In order to
`ensure that XHTML 1.0 documentsare well-structured XML documents, XHTML 1.0
`documents MUSTusethe id attribute when defining fragmentidentifiers, even on elements
`that historically have also had a nameattribute. See the HTML Compatibility Guidelines for
`information on ensuring such anchors are backwards compatible when serving XHTML
`documents as media type text/html.
`
`Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will
`be removed in a subsequentversion of XHTML.
`
`5. Compatibility Issues
`
`Although thereis no requirement for XHTML 1.0 documents to be compatible with existing
`user agents, in practice this is easy to accomplish. Guidelines for creating compatible
`documents can be found in Appendix C.
`
`5.1 Internet Media Type
`
`Asof the publication of this recommendation, the general recommended MIME labeling for
`XML-basedapplications has yet to be resolved.
`
`
`However, XHTML Documents which follow the guidelines set forth in Appendix C, "HTML
`Compatibility Guidelines" may be labeled with the Internet Media Type "text/html", as they are
`compatible with most HTML browsers. This document makes no recommendation about
`MIME labeling of other XHTML documents.
`
`6. Future Directions
`
`XHTML 1.0 provides the basis for a family of document typesthat will extend and subset
`XHTML,in order to support a wide range of new devices and applications, by defining
`modules and specifying a mechanism for combining these modules. This mechanism will
`enable the extension and sub-setting of XHTML 1.0 in a uniform way through the definition of
`new modules.
`
`6.1 Modularizing HTML
`
`As the use of XHTML movesfrom thetraditional desktop user agents to otherplatforms,it is
`clear that not all of the XHTML elementswill be required on all platforms. For example a
`hand held device or a cell-phone may only support a subset of XHTML elements.
`
`The process of modularization breaks XHTML up into a series of smaller element sets. These
`elements can then be recombined to meet the needs ofdifferent communities.
`
`These moduleswill be defined in a later W3C document.
`
`6.2 Subsets and Extensibility
`
`12
`
`
`
`Modularization brings with it several advantages:
`
`e
`
`e
`
`e
`
`e
`
`It provides a formal mechanism for sub-setting XHTML.
`
`It provides a formal mechanism for extending XHTML.
`
`It simplifies the transformation between documenttypes.
`
`It promotes the reuse of modules in new documenttypes.
`
`6.3 Document Profiles
`
`Adocumentprofile specifies the syntax and semantics of a set of documents. Conformance
`to a documentprofile provides a basis for interoperability guarantees. The documentprofile
`specifies the facilities required to process documentsof that type, e.g. which image formats
`can be used, levels of scripting, style sheet support, and so on.
`
`For product designers this enables various groupsto define their own standard profile.
`
`For authorsthis will obviate the need to write several different versions of documents for
`different clients.
`
`For special groups such as chemists, medical doctors, or mathematicians this allows a
`special profile to be built using standard HTML elements plus a group of elements geared to
`the specialist's needs.
`
`Appendix A. DTDs
`
`This appendix is normative.
`
`These DTDs and entity sets form a normative part of this specification. The complete set of
`DTDfiles together with an XML declaration and SGML Open Catalogis includedin the Zipfile
`for this specification.
`
`A.1 DocumentType Definitions
`
`These DTDs approximate the HTML 4.0 DTDs. It is likely that when the DTDs are
`modularized, a method of DTD construction will be employed that corresponds moreclosely
`to HTML 4.0.
`
`e XHTML-1.0-Strict
`
`« XHTML-1.0-Transitional
`
`e XHTML-1.0-Frameset
`
`A.2 Entity Sets
`
`The XHTML entity sets are the same as for HTML 4.0, but have been modified to be valid
`XML 1.0 entity declarations. Note the entity for the Euro currency sign (€ or € Or
`@AC; ) is defined as part of the special characters.
`
`e Latin-1 characters
`
`13
`
`13
`
`
`
`e Special characters
`
`e Symbols
`
`Appendix B. Element Prohibitions
`
`This appendix is normative.
`
`The following elements have prohibitions on which elements they can contain (see Section
`4.9). This prohibition applies to all depths of nesting, i.e. it contains all the descendant
`elements.
`
`a
`
`pre
`
`cannotcontain other a elements.
`
`cannotcontain the img, object, big, small, sub, or sup elements.
`button
`cannot contain the input, select, textarea, label, button, form, fieldset, iframe OF isindex
`elements.
`
`label
`
`form
`
`cannotcontain other label elements.
`
`cannot contain other form elements.
`
`Appendix C. HTML Compatibility Guidelines
`
`This appendix is informative.
`
`This appendix summarizes design guidelines for authors who wish their XHTML documents
`to render on existing HTML user agents.
`
`C.1 Processing Instructions
`
`Be awarethat processinginstructions are rendered on some user agents. However, also note
`that when the XML declaration is not included in a document, the document can only use the
`default character encodings UTF-8 or UTF-16.
`
`C.2 Empty Elements
`
`Include a space beforethe trailing / and > of empty elements,e.g. <br />, <hr /> and <img
`src="karen. jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements,e.g.
`<br />, aS the alternative syntax <br></br> allowed by XML gives uncertain results in many
`existing user agents.
`
`C.3 Element Minimization and Empty Element Content
`
`Given an emptyinstance of an element whose content modelis not empty (for example, an
`emptytitle or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />).
`
`C.4 Embedded Style Sheets and Scripts
`14
`
`14
`
`
`
`Use external style sheets if your style sheet uses < or & or ]]> or --. Use external scriptsif
`your script uses < or & or ]]> or --. Note that XML parsers are permitted to silently remove the
`contents of comments. Therefore, the historical practice of "hiding" scripts and style sheets
`within comments to make the documents backward compatible is likely to not work as
`expected in XML-based implementations.
`
`C.5 Line Breaks within Attribute Values
`
`Avoid line breaks and multiple whitespace characters within attribute values. These are
`handled inconsistently by user agents.
`
`C.6 Isindex
`
`Don't include more than one isindex element in the document head. The isindex elementis
`deprecated in favor of the input element.
`
`C.7 The lang and xml: 1ang Attributes
`
`Use both the lang and xml:lang attributes when specifying the languageof an element. The
`value of the xml:lang attribute takes precedence.
`
`C.8 FragmentIdentifiers
`
`In XML, URIs [REC2396] that end with fragmentidentifiers of the form "#foo" do not refer to
`elements with an attribute name="foo"; rather, they refer to elements with anattribute defined
`to be of type 1D, e.g., the id attribute in HTML 4.0. Many existing HTML clients don't support
`the use of 1p-type attributes in this way, so identical values may be supplied for both of these
`attributes to ensure maximum forward and backward compatibility (e.g., <a id="foo"
`name="foo">...</a>).
`
`Further, since the set of legal values for attributes of type 1p is much smaller than for those of
`type cpata, the type of the name attribute has been changed to nmTokeEn.This attribute is
`constrained suchthat it can only have the same valuesas type 1D, or as the Name production
`in XML 1.0 Section 2.5, production 5. Unfortunately, this constraint cannot