Recent from talks
Nothing was collected or created yet.
XHTML
View on Wikipedia| XHTML | |
|---|---|
| Filename extension |
.xhtml, .xht, .xml, .html, .htm |
| Internet media type |
application/xhtml+xml |
| Uniform Type Identifier (UTI) | public.xhtml |
| UTI conformation | public.xml |
| Developed by | WHATWG |
| Initial release | 26 January 2000 |
| Type of format | Markup language |
| Extended from | XML, HTML |
| Standard | HTML LS |
| Open format? | Yes |
| HTML |
|---|
| HTML and variants |
| HTML elements and attributes |
| Editing |
| Character encodings and language |
| Document and browser models |
| Client-side scripting and APIs |
| Graphics and Web3D technology |
| Comparisons |
Extensible HyperText Markup Language (XHTML) is part of the family of XML markup languages which mirrors or extends versions of the widely used HyperText Markup Language (HTML), the language in which Web pages are formulated.
While HTML, prior to HTML5, was defined as an application of Standard Generalized Markup Language (SGML), a flexible markup language framework, XHTML is an application of XML, a more restrictive subset of SGML. XHTML documents are well-formed and may therefore be parsed using standard XML parsers, unlike HTML, which requires a lenient, HTML-specific parser.[1]
XHTML 1.0 became a World Wide Web Consortium (W3C) recommendation on 26 January 2000. XHTML 1.1 became a W3C recommendation on 31 May 2001. XHTML is now referred to as "the XML syntax for HTML"[2][3] and being developed as an XML adaptation of the HTML living standard.[4][5]
Overview
[edit]XHTML 1.0 was "a reformulation of the three HTML 4 document types as applications of XML 1.0".[6] The World Wide Web Consortium also simultaneously maintained the HTML 4.01 Recommendation. In the XHTML 1.0 Recommendation document, as published and revised in August 2002, the W3C commented that "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 remaining confident in their content's backward and future compatibility."[6]
However, in 2005, the Web Hypertext Application Technology Working Group (WHATWG) formed, independently of the W3C, to work on advancing ordinary HTML not based on XHTML. The WHATWG eventually began working on a standard that supported both XML and non-XML serializations, HTML5, in parallel to W3C standards such as XHTML 2.0. In 2007, the W3C's HTML working group voted to officially recognize HTML5 and work on it as the next generation HTML standard.[7] In 2009, the W3C allowed the XHTML 2.0 Working Group's charter to expire, acknowledging that HTML5 would be the sole next-generation HTML standard, including both XML and non-XML serializations.[8] Of the two serializations, the W3C suggests that most authors use the HTML syntax, rather than the XHTML syntax.[9]
The W3C recommendations of both XHTML 1.0 and XHTML 1.1 were retired on 27 March 2018,[10][11] along with HTML 4.0,[12] HTML 4.01,[13] and HTML5.[14]
Motivation
[edit]XHTML was developed to make HTML more extensible and increase interoperability with other data formats.[15] In addition, browsers were forgiving of errors in HTML, and most websites were displayed despite technical errors in the markup; XHTML introduced stricter error handling.[16] HTML 4 was ostensibly an application of Standard Generalized Markup Language (SGML); however the specification for SGML was complex, and neither web browsers nor the HTML 4 Recommendation were fully conformant to it.[17] The XML standard, approved in 1998, provided a simpler data format closer in simplicity to HTML 4.[18] By shifting to an XML format, it was hoped HTML would become compatible with common XML tools;[19] servers and proxies would be able to transform content, as necessary, for constrained devices such as mobile phones.[20] By using namespaces, XHTML documents could provide extensibility by including fragments from other XML-based languages such as Scalable Vector Graphics and MathML.[21] Finally, the renewed work would provide an opportunity to divide HTML into reusable components (XHTML Modularization) and clean up untidy parts of the language.[22]
Relationship to HTML
[edit]There are various differences between XHTML and HTML. The Document Object Model (DOM) is a tree structure that represents the page internally in applications, and XHTML and HTML are two different ways of representing that in markup. Both are less expressive than the DOM – for example, "--" may be placed in comments in the DOM, but cannot be represented in a comment in either XHTML or HTML – and generally, XHTML's XML syntax is more expressive than HTML (for example, arbitrary namespaces are not allowed in HTML). XHTML uses an XML syntax, while HTML uses a pseudo-SGML syntax (officially SGML for HTML 4 and under, but never in practice, and standardized away from SGML in HTML5). Because the expressible contents of the DOM syntax are slightly different, there are some changes in actual behavior between the two models. Syntax differences, however, can be overcome by implementing an alternate translational framework within the markup.
First, there are some differences in syntax:[23]
- Broadly, the XML rules require that every element be closed, either with a separate closing tag (e.g.
</div>) or by using the self-closing syntax (e.g.<br/>), while HTML syntax permits some elements to be unclosed because either they are always empty (e.g.<input>) or their end can be determined implicitly ("omissibility", e.g.<p>). - XML is case-sensitive for element and attribute names, while HTML is not.
- Some shorthand features in HTML are omitted in XML, such as (1) attribute minimization, where attribute values or their quotes may be omitted (e.g.
<option selected>or<option selected=selected>, while in XML this must be expressed as<option selected="selected">); (2) element minimization may be used to remove elements entirely (such as<tbody>inferred in a table if not given); and (3) the rarely used SGML syntax for element minimization ("shorttag"), which most browsers do not implement.[24] - There are numerous other technical requirements surrounding namespaces and precise parsing of whitespace and certain characters and elements. The exact parsing of HTML in practice has been undefined until recently; see the HTML5 specification ([HTML5]) for full details, or the working summary (HTML vs. XHTML).
In addition to the syntactical differences, there are some behavioral differences, mostly arising from the underlying differences in serialization. For example:
- Behavior on parse errors differs. A fatal parse error in XML (such as an incorrect tag structure) causes document processing to be aborted.
- Most content requiring namespaces will not work in HTML, except the built-in support for SVG and MathML in the HTML5 parser along with certain magic prefixes such as
xlink. - JavaScript processing is different in XHTML, with minor changes in case sensitivity to some functions, and further precautions to restrict processing to well-formed content. Scripts must not use the
document.write()method; it is not available for XHTML. TheinnerHTMLproperty is available, but will not insert non-well-formed content. On the other hand, it can be used to insert well-formed namespaced content into XHTML. - Cascading Style Sheets (CSS) are also applied differently. Due to XHTML's case-sensitivity, all CSS selectors become case-sensitive for XHTML documents.[25] Some CSS properties, such as backgrounds, set on the
<body>element in HTML are 'inherited upwards' into the<html>element; this appears[clarification needed] not to be the case for XHTML.[26]
Adoption
[edit]The similarities between HTML 4.01 and XHTML 1.0 led many websites and content management systems to adopt the initial W3C XHTML 1.0 Recommendation. To aid authors in the transition, the W3C provided guidance on how to publish XHTML 1.0 documents in an HTML-compatible manner, and serve them to browsers that were not designed for XHTML.[27][28]
Such "HTML-compatible" content is sent using the HTML media type (text/html) rather than the official Internet media type for XHTML (application/xhtml+xml). When measuring the adoption of XHTML to that of regular HTML, therefore, it is important to distinguish whether it is media type usage or actual document contents that are being compared.[29][30]
Most web browsers have mature support[31] for all of the possible XHTML media types.[32] The notable exception is Internet Explorer versions 8 and earlier by Microsoft; rather than rendering application/xhtml+xml content, a dialog box invites the user to save the content to disk instead. Both Internet Explorer 7 (released in 2006) and Internet Explorer 8 (released in March 2009) exhibit this behavior.[33] Microsoft developer Chris Wilson explained in 2005 that IE7's priorities were improved browser security and CSS support, and that proper XHTML support would be difficult to graft onto IE's compatibility-oriented HTML parser;[34] however, Microsoft added support for true XHTML in IE9.[35]
As long as support is not widespread, most web developers avoid using XHTML that is not HTML-compatible,[36] so advantages of XML such as namespaces, faster parsing, and smaller-footprint browsers do not benefit the user.[37][38][39]
Criticism
[edit]In the early 2000s, some Web developers began to question why Web authors ever made the leap into authoring in XHTML.[40][41][42] Others countered that the problems ascribed to the use of XHTML could mostly be attributed to two main sources: the production of invalid XHTML documents by some Web authors and the lack of support for XHTML built into Internet Explorer 6.[43][44] They went on to describe the benefits of XML-based Web documents (i.e. XHTML) regarding searching, indexing, and parsing as well as future-proofing the Web itself.
In October 2006, HTML inventor and W3C chair Tim Berners-Lee, introducing a major W3C effort to develop a new HTML specification, posted in his blog that "[t]he attempt to get the world to switch to XML ... all at once didn't work. The large HTML-generating public did not move ... Some large communities did shift and are enjoying the fruits of well-formed systems ... The plan is to charter a completely new HTML group."[45] The current HTML5 working draft says "special attention has been given to defining clear conformance criteria for user agents in an effort to improve interoperability ... while at the same time updating the HTML specifications to address issues raised in the past few years." Ian Hickson, editor of the HTML5 specification criticizing the improper use of XHTML in 2002,[40] is a member of the group developing this specification and is listed as one of the co-editors of the current working draft.[46]
Simon Pieters researched the XML-compliance of mobile browsers[47] and concluded "the claim that XHTML would be needed for mobile devices is simply a myth".
Versions of XHTML
[edit]XHTML 1.0
[edit]
application/xhtml+xml.December 1998 saw the publication of a W3C Working Draft entitled Reformulating HTML in XML. This introduced Voyager, the codename for a new markup language based on HTML 4, but adhering to the stricter syntax rules of XML. By February 1999 the name of the specification had changed to XHTML 1.0: The Extensible HyperText Markup Language, and in January 2000 it was officially adopted as a W3C Recommendation.[48] There are three formal Document Type Definitions (DTD) for XHTML 1.0, corresponding to the three different versions of HTML 4.01:
- XHTML 1.0 Strict is the XML equivalent to strict HTML 4.01, and includes elements and attributes that have not been marked deprecated in the HTML 4.01 specification. As of November 2015[update], XHTML 1.0 Strict is the document type used for the homepage of the website of the World Wide Web Consortium.
- XHTML 1.0 Transitional is the XML equivalent of HTML 4.01 Transitional, and includes the presentational elements (such as
center,fontandstrike) excluded from the strict version. - XHTML 1.0 Frameset is the XML equivalent of HTML 4.01 Frameset, and allows for the definition of frameset documents—a common Web feature in the late 1990s.
The second edition of XHTML 1.0 became a W3C Recommendation in August 2002.[49]
Modularization of XHTML
[edit]Modularization provides an abstract collection of components through which XHTML can be subsetted and extended. The feature is intended to help XHTML extend its reach onto emerging platforms, such as mobile devices and Web-enabled televisions. The initial draft of Modularization of XHTML became available in April 1999, and reached Recommendation status in April 2001.[50]
The first modular XHTML variants were XHTML 1.1 and XHTML Basic 1.0.
In October 2008 Modularization of XHTML was superseded by XHTML Modularization 1.1, which adds an XML Schema implementation. It was superseded by a second edition in July 2010.[51]
XHTML 1.1: Module-based XHTML
[edit]XHTML 1.1 evolved out of the work surrounding the initial Modularization of XHTML specification. The W3C released the first draft in September 1999; the Recommendation status was reached in May 2001.[52] The modules combined within XHTML 1.1 effectively recreate XHTML 1.0 Strict, with the addition of ruby annotation elements (ruby, rbc, rtc, rb, rt and rp) to better support East-Asian languages. Other changes include the removal of the name attribute from the a and map elements, and (in the first edition of the language) the removal of the lang attribute in favor of xml:lang.
Although XHTML 1.1 is largely compatible with XHTML 1.0 and HTML 4, in August 2002 the Working Group issued a formal Note advising that it should not be transmitted with the HTML media type.[53] With limited browser support for the alternate application/xhtml+xml media type, XHTML 1.1 proved unable to gain widespread use. In January 2009 a second edition of the document (XHTML Media Types – Second Edition) was issued, relaxing this restriction and allowing XHTML 1.1 to be served as text/html.[54]
The second edition of XHTML 1.1 was issued on 23 November 2010, which addresses various errata and adds an XML Schema implementation not included in the original specification.[55] (It was first released briefly on 7 May 2009 as a "Proposed Edited Recommendation"[56] before being rescinded on 19 May due to unresolved issues.)
XHTML Basic
[edit]Since information appliances may lack the system resources to implement all XHTML abstract modules, the W3C defined a feature-limited XHTML specification called XHTML Basic. It provides a minimal feature subset sufficient for the most common content-authoring. The specification became a W3C recommendation in December 2000.[57]
Of all the versions of XHTML, XHTML Basic 1.0 provides the fewest features. With XHTML 1.1, it is one of the two first implementations of modular XHTML. In addition to the Core Modules (Structure, Text, Hypertext, and List), it implements the following abstract modules: Base, Basic Forms, Basic Tables, Image, Link, Metainformation, Object, Style Sheet, and Target.[58][59]
XHTML Basic 1.1 replaces the Basic Forms Module with the Forms Module and adds the Intrinsic Events, Presentation, and Scripting modules. It also supports additional tags and attributes from other modules. This version became a W3C recommendation on 29 July 2008.[60]
The current version of XHTML Basic is 1.1 Second Edition (23 November 2010), in which the language is re-implemented in the W3C's XML Schema language. This version also supports the lang attribute.[61]
XHTML-Print
[edit]XHTML-Print, which became a W3C Recommendation in September 2006, is a specialized version of XHTML Basic designed for documents printed from information appliances to low-end printers.[62]
XHTML Mobile Profile
[edit]XHTML Mobile Profile (abbreviated XHTML MP or XHTML-MP) is a third-party variant of the W3C's XHTML Basic specification. Like XHTML Basic, XHTML was developed for information appliances with limited system resources.
In October 2001, a limited company called the Wireless Application Protocol Forum began adapting XHTML Basic for WAP 2.0, the second major version of the Wireless Application Protocol. WAP Forum based their DTD on the W3C's Modularization of XHTML, incorporating the same modules the W3C used in XHTML Basic 1.0—except for the Target Module. Starting with this foundation, the WAP Forum replaced the Basic Forms Module with a partial implementation of the Forms Module, added partial support for the Legacy and Presentation modules, and added full support for the Style Attribute Module.
In 2002, the WAP Forum has subsumed into the Open Mobile Alliance (OMA), which continued to develop XHTML Mobile Profile as a component of their OMA Browsing Specification.
XHTML Mobile Profile 1.1
[edit]To this version, finalized in 2004, the OMA added partial support for the Scripting Module and partial support for Intrinsic Events. XHTML MP 1.1 is part of v2.1 of the OMA Browsing Specification (1 November 2002).[63]
XHTML Mobile Profile 1.2
[edit]This version, finalized on 27 February 2007, expands the capabilities of XHTML MP 1.1 with full support for the Forms Module and OMA Text Input Modes. XHTML MP 1.2 is part of v2.3 of the OMA Browsing Specification (13 March 2007).[63]
XHTML Mobile Profile 1.3
[edit]XHTML MP 1.3 (finalized on 23 September 2008) uses the XHTML Basic 1.1 document type definition, which includes the Target Module. Events in this version of the specification are updated to DOM Level 3 specifications (i.e., they are platform- and language-neutral).
XHTML 1.2
[edit]The XHTML 2 Working Group considered the creation of a new language based on XHTML 1.1.[64] If XHTML 1.2 was created, it would include WAI-ARIA and role attributes to better support accessible web applications, and improved Semantic Web support through RDFa. The inputmode attribute from XHTML Basic 1.1, along with the target attribute (for specifying frame targets) might also be present. The XHTML2 WG had not been chartered to carry out the development of XHTML1.2. Since the W3C announced that it does not intend to recharter the XHTML2 WG,[8] and closed the WG in December 2010, this means that the XHTML 1.2 proposal would not eventuate.
XHTML 2.0
[edit]Between August 2002 and July 2006, the W3C released eight Working Drafts of XHTML 2.0, a new version of XHTML able to make a clean break from the past by discarding the requirement of backward compatibility. This lack of compatibility with XHTML 1.x and HTML 4 caused some early controversy in the web developer community.[65] Some parts of the language (such as the role and RDFa attributes) were subsequently split out of the specification and worked on as separate modules, partially to help make the transition from XHTML 1.x to XHTML 2.0 smoother. The ninth draft of XHTML 2.0 was expected to appear in 2009, but on 2 July 2009, the W3C decided to let the XHTML2 Working Group charter expire by that year's end, effectively halting any further development of the draft into a standard.[8] Instead, XHTML 2.0 and its related documents were released as W3C Notes in 2010.[66][67]
New features to have been introduced by XHTML 2.0 included:
- HTML forms were to be replaced by XForms, an XML-based user input specification allowing forms to be displayed appropriately for different rendering devices.
- HTML frames were to be replaced by XFrames.
- The DOM Events were to be replaced by XML Events, which uses the XML Document Object Model.
- A new list element type, the
nlelement type, was to be included to specifically designate a list as a navigation list. This would have been useful in creating nested menus, which are currently created by a wide variety of means like nested unordered lists or nested definition lists. - Any element was to be able to act as a hyperlink, e. g.,
<li href="articles.html">Articles</li>, similar to XLink. However, XLink itself is not compatible with XHTML due to design differences. - Any element was to be able to reference alternative media with the
srcattribute, e. g.,<p src="lbridge.jpg" type="image/jpeg">London Bridge</p>is the same as<object src="lbridge.jpg" type="image/jpeg"><p>London Bridge</p></object>. - The
altattribute of theimgelement was removed: alternative text was to be given in the content of theimgelement, much like theobjectelement, e. g.,<img src="hms_audacious.jpg">HMS <span class="italic">Audacious</span></img>. - A single heading element (
h) was added. The level of these headings was determined by the depth of the nesting. This would have allowed the use of headings to be infinite, rather than limiting use to six levels deep. - The remaining presentational elements
i,bandtt, still allowed in XHTML 1.x (even Strict), were to be absent from XHTML 2.0. The only somewhat presentational elements remaining were to besupandsubfor superscript and subscript respectively because they have significant non-presentational uses and are required by certain languages. All other tags were meant to be semantic instead (e. g.strongfor strong emphasis) while allowing the user agent to control the presentation of elements via CSS (e.g. rendered as boldface text in most visual browsers, but possibly rendered with changes of tone in a text-to-speech reader, larger + italic font per rules in a user-end stylesheet, etc.). - The addition of RDF triple with the
propertyandaboutattributes to facilitate the conversion from XHTML to RDF/XML.
XHTML5
[edit]HTML5 grew independently of the W3C, through a loose group of browser manufacturers and other interested parties calling themselves the WHATWG, or Web Hypertext Application Technology Working Group. The key motive of the group was to create a platform for dynamic web applications; they considered XHTML 2.0 to be too document-centric, and not suitable for the creation of internet forum sites or online shops.[68]
HTML5 has both a regular text/html serialization and an XML serialization, which is also known as XHTML5.[69] The language is more compatible with HTML 4 and XHTML 1.x than XHTML 2.0, due to the decision to keep the existing HTML form elements and events model. It adds many new elements not found in XHTML 1.x, however, such as section and aside tags.
The XHTML5 language, like HTML5, uses a DOCTYPE declaration without a DTD. Furthermore, the specification deprecates earlier XHTML DTDs by asking the browsers to replace them with one containing only entity definitions for named characters during parsing.[69]
Semantic content in XHTML
[edit]XHTML+RDFa is an extended version of the XHTML markup language for supporting RDF through a collection of attributes and processing rules in the form of well-formed XML documents. This host language is one of the techniques used to develop Semantic Web content by embedding rich semantic markup.
Valid XHTML documents
[edit]An XHTML document that conforms to an XHTML specification is said to be valid. Validity assures consistency in document code, which in turn eases processing, but does not necessarily ensure consistent rendering by browsers. A document can be checked for validity with the W3C Markup Validation Service (for XHTML5, the Validator. nu Living Validator should be used instead). In practice, many web development programs provide code validation based on the W3C standards.
Root element
[edit]The root element of an XHTML document must be html, and must contain an xmlns attribute to associate it with the XHTML namespace. The namespace URI for XHTML is http://www.w3.org/1999/xhtml. The example tag below additionally features an xml:lang attribute to identify the document with a natural language:
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="ar">
DOCTYPEs
[edit]In order to validate an XHTML document, a Document Type Declaration, or DOCTYPE, may be used. A DOCTYPE declares to the browser the Document Type Definition (DTD) to which the document conforms. A Document Type Declaration should be placed before the root element.
The system identifier part of the DOCTYPE, which in these examples is the URL that begins with http://, need only point to a copy of the DTD to use, if the validator cannot locate one based on the public identifier (the other quoted string). It does not need to be the specific URL that is in these examples; in fact, authors are encouraged to use local copies of the DTD files when possible. The public identifier, however, must be character-for-character the same as in the examples.
XML declaration
[edit]A character encoding may be specified at the beginning of an XHTML document in the XML declaration when the document is served using the application/xhtml+xml MIME type. (If an XML document lacks encoding specification, an XML parser assumes that the encoding is UTF-8 or UTF-16, unless the encoding has already been determined by a higher protocol.)
For example:
<?xml version="1.0" encoding="UTF-8" ?>
The declaration may be optionally omitted because it declares its encoding the default encoding. However, if the document instead makes use of XML 1.1 or another character encoding, a declaration is necessary. Internet Explorer prior to version 7 enters quirks mode, if it encounters an XML declaration in a document served as text/html.
Backward compatibility
[edit]XHTML 1.x documents are mostly backward compatible with HTML 4 user agents when the appropriate guidelines are followed. XHTML 1.1 is essentially compatible, although the elements for ruby annotation are not part of the HTML 4 specification and thus generally ignored by HTML 4 browsers. Later XHTML 1.x modules such as those for the role attribute, RDFa, and WAI-ARIA degrade gracefully in a similar manner.
XHTML 2.0 is significantly less compatible, although this can be mitigated to some degree through the use of scripting. (This can be simple one-liners, such as the use of document.createElement() to register a new HTML element within Internet Explorer, or complete JavaScript frameworks, such as the FormFaces implementation of XForms.)
Examples
[edit]The following are examples of XHTML 1.0 Strict, with both having the same visual output. The former one follows the HTML Compatibility Guidelines of the XHTML Media Types Note while the latter one breaks backward compatibility, but provides cleaner markup.[54]
| Media type | Example 1 | Example 2 |
|---|---|---|
| application/xhtml+xml | SHOULD | SHOULD |
| application/xml | MAY | MAY |
| text/xml | MAY | MAY |
| text/html | MAY | SHOULD NOT |
Example 1.
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>XHTML 1.0 Strict Example</title>
<script type="text/javascript">
//<![CDATA[
function loadpdf() {
document.getElementById("pdf-object").src="http://www.w3.org/TR/xhtml1/xhtml1.pdf";
}
//]]>
</script>
</head>
<body onload="loadpdf()">
<p>This is an example of an
<abbr title="Extensible HyperText Markup Language">XHTML</abbr> 1.0 Strict document.<br />
<img id="validation-icon"
src="http://www.w3.org/Icons/valid-xhtml10"
alt="Valid XHTML 1.0 Strict"/><br />
<object id="pdf-object"
name="pdf-object"
type="application/pdf"
data="http://www.w3.org/TR/xhtml1/xhtml1.pdf"
width="100%"
height="500">
</object>
</p>
</body>
</html>
Example 2.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>XHTML 1.0 Strict Example</title>
<script type="application/javascript">
<![CDATA[
function loadpdf() {
document.getElementById("pdf-object").src="http://www.w3.org/TR/xhtml1/xhtml1.pdf";
}
]]>
</script>
</head>
<body onload="loadpdf()">
<p>This is an example of an
<abbr title="Extensible HyperText Markup Language">XHTML</abbr> 1.0 Strict document.<br />
<img id="validation-icon"
src="http://www.w3.org/Icons/valid-xhtml10"
alt="Valid XHTML 1.0 Strict"/><br />
<object id="pdf-object"
type="application/pdf"
data="http://www.w3.org/TR/xhtml1/xhtml1.pdf"
width="100%"
height="500"></object>
</p>
</body>
</html>
Notes:
- The "loadpdf" function is actually a workaround for Internet Explorer. It can be replaced by adding
<param name="src" value="http://www.w3.org/TR/xhtml1/xhtml1.pdf"/>within<object>. - The
imgelement does not get anameattribute in the XHTML 1.0 Strict DTD. Useidinstead.
Cross-compatibility of XHTML and HTML
[edit]HTML5 and XHTML5 serializations are largely inter-compatible if adhering to the stricter XHTML5 syntax, but there are some cases in which XHTML will not work as valid HTML5 (e.g., processing instructions are non-existent in HTML, are treated as comments, and close on the first >, whereas they are fully allowed in XML, are treated as their own type, and close on ?>).[70]
See also
[edit]References
[edit]- ^ Graff, Eliot (7 May 2014). "Polyglot Markup: A robust profile of the HTML5 vocabulary". W3C. Archived from the original on 16 June 2022. Retrieved 17 October 2015.
- ^ "Writing documents in the XML syntax". HTML Living Standard. WHATWG. Archived from the original on 7 July 2023.
- ^ "The XML syntax". HTML: The Living Standard. WHATWG. Archived from the original on 5 June 2023.
- ^ "HTML vs. XHTML". whatwg.org.
- ^ "The WHATWG Blog". whatwg.org. 25 July 2010.
- ^ a b "XHTML 1.0 Specification, Section 1: What is XHTML?". World Wide Web Consortium. 2000-01-26. Retrieved 2007-06-16.
- ^ "results of HTML 5 text, editor, name questions". W3C.
- ^ a b c "Frequently Asked Questions (FAQ) about the future of XHTML". w3.org.
- ^ "HTML5 Working Draft, Section 1.6: HTML vs XHTML". World Wide Web Consortium. 2011-01-13. Retrieved 2011-02-16.
- ^ "XHTML™ 1.0 The Extensible HyperText Markup Language (Second Edition) Publication History". World Wide Web Consortium. 27 March 2018.
- ^ "XHTML™ 1.1 - Module-based XHTML - Second Edition Publication History". World Wide Web Consortium. 27 March 2018.
- ^ "HTML 4.0 Publication History". World Wide Web Consortium. 27 March 2018.
- ^ "HTML 4.01 Publication History". World Wide Web Consortium. 27 March 2018.
- ^ "HTML5 Publication History". World Wide Web Consortium. 27 March 2018.
- ^ "XHTML 1.0 Specification, Section 1.1: Why the need for XHTML?". World Wide Web Consortium. 2000-01-26. Retrieved 2007-06-16.
- ^ Pilgrim, Mark. "How Did We Get Here? - Dive Into HTML5". diveintohtml5.info. Archived from the original on 2021-03-08. Retrieved 2016-06-11.
- ^ Arjun Ray (1999-10-06). "Dropping the Normative Reference to SGML (was: I-D ACTION.)". Archived from the original on 2021-02-25. Retrieved 2008-12-29.
... However, since ISO 8879 does not afford applications the leeway to prohibit internal subsets, it follows that the letter of the HTML [4] spec automatically disentitles it to be a conforming SGML application...
- ^ Tina Holmboe (2008-10-06). "XHTML—Myths and Reality". The Developer's Archive. Archived from the original on 2017-01-12. Retrieved 2008-12-29.
... Since the design goals of XML itself partially mirrored those of the original HTML, it was logical for work to begin on formulating an XML–based markup language...
- ^ Kip Hampton (2001-01-10). "Creating Web Utilities Using XML::XPath". XML.com. Retrieved 2008-12-29.
... The problem: You want to take advantage of the power and simplicity that XML tools can offer, but you face a site full of aging HTML documents. The solution: Convert your documents to XHTML and put Perl and
XML::XPathto work... - ^ Jean-Luc David (2004-04-14). "Developing Wireless Content using XHTML Mobile". XML.com. Retrieved 2008-12-29.
... A useful feature of XHTML is that it can be manipulated as XML. Extensible Stylesheet Language Templates can be used to transform XHTML into WML or any other proprietary mobile formats...
- ^ "Namespaces Crash Course". Mozilla Developer Center. Archived from the original on 2008-10-02. Retrieved 2008-12-29.
... It has been a long-standing goal of the W3C to make it possible for different types of XML-based content to be mixed together in the same XML file. For example, SVG and MathML might be incorporated directly into an XHTML-based scientific document...
- ^ Steven Pemberton (2004-07-21). "HTML and XHTML Frequently Answered Questions". World Wide Web Consortium. Retrieved 2008-12-29.
... with an XML-based HTML other XML languages could include bits of XHTML, and XHTML documents could include bits of other markup languages. We could also take advantage of the redesign to clean up some of the more untidy parts of HTML and add some new needed functionality, like better forms...
- ^ Clark, James (1997-12-15). "Comparison of SGML and XML". World Wide Web Consortium Note.
- ^ "Shorthand markup". HTML 4, Appendix B: Performance, Implementation, and Design Notes. W3C. Retrieved 30 September 2011.
- ^ "Case Sensitivity". SitePoint Pty. Ltd. Retrieved 30 September 2011.
- ^ Wilson, Nicholas (29 May 2010). "CSS differences between XHTML and HTML".
- ^ "XHTML 1.0 Specification, Appendix C: HTML Compatibility Guidelines". World Wide Web Consortium. 2000-01-26. Retrieved 2007-06-16.
- ^ "XHTML Media Types, W3C Working Group Note". World Wide Web Consortium. 2002-08-01. Retrieved 2008-06-12.
- ^ "Meta and Inline Tags that Google Understands | Google Search Central".
- ^ Greta de Groat (2002). "Perspectives on the Web and Google: Monika Henzinger, Director of Research, Google", Journal of Internet Cataloging, Vol. 5(1), pp. 17-28, 2002.
- ^ Early implementations (such as Mozilla 0.7 and Opera 6.0, both released in 2001) do not incrementally render XHTML as it is received over the network, giving a degraded user experience; see the Mozilla Web Author FAQ. Later browsers such as Opera 9.0, Safari 3.0, and Firefox 3.0 do not have this issue.
- ^ "XHTML media type test - results". w3.org.
- ^ Chris Wilson (2005-09-15). "The <?xml> prolog, strict mode, and XHTML in IE". Retrieved 2007-06-16.
I've also been reading comments for some time in the IEBlog asking for support for the "application/xml+xhtml" MIME type in IE. I should say that IE7 will not add support for this MIME type – we will, of course, continue to read XHTML when served as "text/html", presuming it follows the HTML compatibility recommendations.
- ^ Chris Wilson (2005-09-15). "The <?xml> prolog, strict mode, and XHTML in IE". Retrieved 2007-06-16.
...If we tried to support real XHTML in IE 7 we would have ended up using our existing HTML parser (which is focused on compatibility) and hacking in XML constructs. It is highly unlikely we could support XHTML well in this way; in particular, we would certainly not detect a few error cases here or there, and we would silently support invalid cases. This would, of course, cause compatibility problems based on parser error handling in the future, which XML is explicitly trying to avoid; we don't want to cause another mess like the one with current HTML error handling (rooted in compatibility with earlier browsers – you can blame me for that personally somewhat, but not IE). I would much rather take the time to implement XHTML properly after IE 7, and have it be truly interoperable...
- ^ Hachamovitch, Dean (2019-03-16). "HTML5, Hardware Accelerated: First IE9 Platform Preview Available for Developers". IEBlog on Microsoft Developer Network. Microsoft. Retrieved 2010-03-22.
...At this time, we're looking for developer feedback on our implementation of HTML5's parsing rules, Selection APIs, XHTML support, and inline SVG. Within CSS3, we're looking for developer feedback on IE9's support for Selectors, Namespaces, Colors, Values, Backgrounds and Borders, and Fonts....
- ^ "List of XHTML Sites (the X-Philes)". Archived from the original on 2008-11-20. Retrieved 2008-08-26.
- ^ "In 2007, 37 leaders in search engine optimisation concluded that having keywords in the keywords attribute is little to none." Sanger. nu blog, September 9, 2008, Retrieved August 2 2011 Archived February 21, 2009, at the Wayback Machine
- ^ "Meta used for SEO". 18 December 2015. Archived from the original on March 31, 2016. Retrieved March 18, 2016.
- ^ Danny Sullivan, How To Use HTML Meta Tags Archived 2008-09-13 at the Wayback Machine, Search Engine Watch, December 5, 2002
- ^ a b Ian Hickson, a former developer of the Opera browser and cofounder of the WHATWG (2002-09-08). "Sending XHTML as text/html Considered Harmful". Retrieved 2007-06-16.
- ^ Anne van Kesteren, a developer of the Opera browser (2004-06-13). "XHTML is invalid HTML". Retrieved 2007-06-16.
- ^ Maciej Stachowiak, a developer of Apple's Safari browser (2006-09-20). "Understanding HTML, XML, and XHTML". Retrieved 2007-06-16.
- ^ Brad Fults (2005-12-21). "Sending XHTML as text/HTML Considered Harmful to Feelings". Retrieved 2008-09-13.
There are not nearly as many disadvantages (if any) to sending XHTML as text/HTML as [Ian Hickson] claims and the advantages I mentioned above make it well worth using in my humble opinion. There are some subtle footnotes and parentheticals [in Hickson's article] indicating that the harmfulness only applies to authors that don't know the pitfalls of this practice, but much like the "Do not eat" label on the little packets of silica gel, Ian's advisory seems to be common sense and not worth mentioning to any author who actually knows what XHTML is and how to write it.
- ^ Paul McDonald (2007-06-30). "The case for XHTML". Archived from the original on 2008-08-08. Retrieved 2008-09-13.
Some people say XHTML on the Web has failed, but I say it is our biggest success in the fight for Web Standards. ... XHTML is a good thing for the web, though, and it's a shame that people are trying to make a case against it. To prove this, I'll flesh out the myth for you and then show you why XHTML is the best thing since sliced bread when it comes to our fight for Web Standards. ... So to conclude, sending XHTML as text/html causes no damage or harm anywhere today, as long as your XHTML does validate. And, if you want Web Standards to become more and more widespread, stick to using XHTML and validate your pages.
- ^ Tim Berners-Lee (2006-10-27). "Reinventing HTML". Archived from the original on 2007-06-09. Retrieved 2007-06-16.
Some things are clearer with the hindsight of several years. It is necessary to evolve HTML incrementally. The attempt to get the world to switch to XML, including quotes around attribute values and slashes in empty tags and namespaces all at once didn't work. The large HTML-generating public did not move, largely because the browsers didn't complain. Some large communities did shift and are enjoying the fruits of well-formed systems, but not all. It is important to maintain HTML incrementally, as well as continue a transition to [a] well-formed world, and develop more power in that world.
"The plan is to charter a completely new HTML group. Unlike the previous one, this one will be chartered to do incremental improvements to HTML, as also in parallel XHTML. It will have a different chair and staff contact. It will work on HTML and xHTML together. We have strong support for this group, from many people we have talked to, including browser makers. - ^ Ian Hickson; David Hyatt (2011-01-13). "HTML5: A vocabulary and associated APIs for HTML and XHTML". Retrieved 2011-02-16.
- ^ Simon Pieters. "Results of mobile tests". Retrieved 2009-10-31.
- ^ "XHTML 1.0: The Extensible HyperText Markup Language, W3C Recommendation 26 January 2000". World Wide Web Consortium. 2000-01-26. Retrieved 2008-07-19.
- ^ "XHTML 1.0 The Extensible HyperText Markup Language (Second Edition)". World Wide Web Consortium. 2002-08-01. Retrieved 2008-07-19.
- ^ "Modularization of XHTML, W3C Recommendation 10 April 2001". World Wide Web Consortium. 2001-04-10. Retrieved 2008-07-19.
- ^ "XHTML Modularization 1.1 - Second Edition, W3C Recommendation 29 July 2010". World Wide Web Consortium. 2010-07-29. Retrieved 2010-12-31.
- ^ "XHTML 1.1 - Module-based XHTML, W3C Recommendation 31 May 2001". World Wide Web Consortium. 2001-05-31. Retrieved 2008-07-19.
- ^ "XHTML Media Types, W3C Working Group Note 1 August 2002". World Wide Web Consortium. 2002-08-01. Retrieved 2008-07-19.
- ^ a b "XHTML Media Types – Second Edition, W3C Working Group Note 16 January 2009". World Wide Web Consortium. 2009-01-16. Retrieved 2009-01-28. This document supersedes the HTML Compatibility Guidelines originally found in XHTML 1.0 Appendix C.
- ^ "XHTML 1.1, XHTML Basic 1.1, XHTML Print Recommendations Revised". W3C NEWS ARCHIVE: 2010. World Wide Web Consortium. Retrieved 12 December 2010.
- ^ "XHTML 1.1 - Module-based XHTML – Second Edition". World Wide Web Consortium. 2009-05-07. Archived from the original on 2009-05-12. Retrieved 2009-05-25.
- ^ "XHTML Basic, W3C Recommendation 19 December 2000". World Wide Web Consortium. 2000-12-19. Retrieved 2008-07-19.
- ^ "XHTML Flavors comparisons". World Wide Web Consortium. 2007-01-09. Retrieved 2013-01-30.
- ^ XHTML Basic. W3.org. Retrieved on 2013-07-17.
- ^ XHTML Basic 1.1. W3.org. Retrieved on 2013-07-17.
- ^ "XHTML Basic 1.1 - Second Edition". w3.org.
- ^ "XHTML-Print, W3C Recommendation 20 September 2006". World Wide Web Consortium. 2006-09-20. Retrieved 2008-07-19.
- ^ a b "OMA Browsing Archive". OMA Releases. Open Mobile Alliance Ltd. 26 September 2011.
- ^ "[XHTML] Agenda: 2008-07-09". w3.org.
- ^ See both XHTML 2.0 Considered Harmful and XHTML 2.0 Considered Hopeful by browser developer Tantek Çelik, who criticizes early drafts of XHTML 2.0 for the absence of the
styleattribute and theciteelement. Developer Daniel Glazman offers similar criticism, but also shows support for some backward-incompatible changes such as the decision to remove theinsanddelelements. - ^ "XHTML 2.0, W3C Working Group Note 16 December 2010". World Wide Web Consortium. 2010-12-16. Retrieved 2010-12-31.
- ^ "XHTML2 Working Group Documents Published as W3C Notes". World Wide Web Consortium. 2010-12-16. Retrieved 2010-12-31.
- ^ Ian Hickson (2008-01-22). "HTML 5, 1.1.2. Relationship to XHTML2". World Wide Web Consortium. Retrieved 2008-07-19.
... XHTML2... defines a new HTML vocabulary with better features for hyperlinks, multimedia content, annotating document edits, rich metadata, declarative interactive forms, and describing the semantics of human literary works such as poems and scientific papers... However, it lacks elements to express the semantics of many of the non-document types of content often seen on the Web. For instance, forum sites, auction sites, search engines, online shops, and the like, do not fit the document metaphor well and are not covered by XHTML2... This specification aims to extend HTML so that it is also suitable in these contexts...
- ^ a b "9 The XHTML syntax — HTML5". w3.org.
- ^ HTML vs. XHTML, WHATWG Wiki
Notes
[edit]- ^ According to Wayback Machine, Wikipedia began using
<!DOCTYPE html>on 18 September 2012; before that,<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">was used, starting from June of 2004.
External links
[edit]- The XML syntax for HTML from WHATWG
- W3C's XHTML recommendations and working group, all superseded
- Links dealing with the MIME type of XHTML documents:
- Beware of XHTML
- Sending XHTML as text/html Considered Harmful
- Serving up XHTML with the correct MIME type
- The Road to XHTML 2.0: MIME Types – Mark Pilgrim (3/19/2003). Includes examples for conditionally serving
application/xhtml+xmlusing PHP, Python, and Apache (via URL rewriting). - Mozilla Web Author FAQ: How is the treatment of application/xhtml+xml documents different from the treatment of text/html documents? – summarizes one web browser's XHTML processing mode
- Empty elements in SGML, HTML, XML, and XHTML
- Heptagrama's Basic XHTML 1.0 Strict Tutorial Archived 2010-09-26 at the Wayback Machine
- W3C's Markup Validator
- HTML to XHTML conversion library for .NET
XHTML
View on Grokipediaapplication/xhtml+xml for parsing as XML while supporting the same semantics as HTML's text/html syntax, thus enabling polyglot markup that validates under both parsers.[4] This integration ensures XHTML's ongoing relevance for applications requiring XML compliance, such as content syndication and server-side generation, though HTML5's flexible syntax has become predominant for general web authoring.[4]
Definition and Fundamentals
Definition and Core Principles
XHTML, or Extensible HyperText Markup Language, is a family of XML-based markup languages that reformulate the semantics of HTML while strictly adhering to the rules of XML 1.0.[1][5] As an application of XML, XHTML maintains the core structure and meaning of HTML documents but requires them to be well-formed, ensuring compatibility with XML parsers and tools.[1] This reformulation allows XHTML to serve as a bridge between the forgiving nature of traditional HTML and the rigorous syntax of XML, facilitating more reliable processing and validation of web content.[1] At its core, XHTML emphasizes well-formedness as a foundational principle, mandating that all elements have properly closed tags (e.g., using<br/> for empty elements), that tag and attribute names are in lowercase, and that elements are correctly nested without overlap.[1] Attribute values must always be quoted, and documents must include a single root element, typically <html>.[1] XHTML documents may include an XML declaration at the beginning, such as <?xml version="1.0" encoding="UTF-8"?>, to specify the XML version and character encoding, though it is optional when defaults apply.[6] Additionally, XHTML promotes extensibility through the use of XML namespaces, primarily the default namespace http://www.w3.org/1999/xhtml, which enables the integration of custom elements or attributes from other vocabularies without conflict.[7][5] A key design goal is the separation of content from presentation, achieved by discouraging inline styling and scripting in favor of external resources like CSS and JavaScript, thereby enhancing maintainability and accessibility.[1]
Developed by the World Wide Web Consortium (W3C), XHTML was created to combine HTML's widespread flexibility with XML's precision, improving parsing accuracy and preparing web documents for future technologies.[1] This approach supports document reuse within broader XML ecosystems, such as embedding SVG graphics directly into XHTML pages or incorporating data islands for structured XML data exchange.[5] By enforcing these principles, XHTML enables developers to build more robust, interoperable web applications that can leverage XML's ecosystem for advanced functionalities like vector graphics and mathematical notation.[5]
Purpose and Relationship to HTML
XHTML was developed primarily to reformulate HTML 4.01 as an application of XML 1.0, addressing the limitations of HTML's forgiving syntax that often led to inconsistent rendering across browsers due to error-tolerant parsing.[1] This stricter approach enforces well-formed XML rules, such as lowercase element and attribute names, mandatory closing tags, and properly quoted attributes, which promotes greater interoperability and simplifies authoring by reducing reliance on browser-specific quirks.[8] By aligning with XML, XHTML facilitates integration with XML-based tools for automation, such as XSLT for transformations and validation processors, enabling more robust content management and extensibility in web development.[1] In its relationship to HTML, XHTML 1.0 serves as a direct semantic equivalent to HTML 4.01, mapping its three document type definitions—Strict, Transitional, and Frameset—into XML formats while preserving the core semantics of elements and attributes as defined in the HTML 4 specification.[1] It is not intended as a replacement for HTML but rather as an alternative formulation that can be served using the MIME type application/xhtml+xml to invoke XML parsers in supporting user agents, contrasting with HTML's traditional text/html type.[9] When served as text/html, XHTML 1.0 documents can maintain compatibility with legacy HTML browsers by following specific serving and authoring guidelines.[10] This XML-centric syntax allows XHTML documents to be embedded within other XML vocabularies or to incorporate modules from them, fostering a modular ecosystem that extends beyond traditional HTML constraints.[8] A key advantage of XHTML is its potential for compatibility with both HTML and XML parsers when adhering to guidelines that ensure consistent interpretation across syntaxes, maintaining backward compatibility with legacy HTML browsers while enabling XML processing.[10] Conceptually, XHTML advances web standards by emphasizing semantic markup over presentational elements, which enhances accessibility, supports diverse device rendering, and aligns with the broader evolution toward structured, machine-readable content on the web.[1]History and Development
Origins and Early Standardization
XHTML emerged in the late 1990s as a response to the limitations of HTML 4.0, which was published as a W3C Recommendation on December 18, 1997, and highlighted the growing need for greater compatibility with emerging XML technologies.[11] The standardization of XML 1.0 on February 10, 1998, provided a foundational framework for this shift, as XML offered a more rigorous, extensible markup language derived from the Standard Generalized Markup Language (SGML), upon which HTML itself was originally based.[12] Recognizing these opportunities, the W3C's HTML Working Group initiated the reformulation of HTML 4 as an XML application to enhance interoperability and future extensibility while preserving HTML's core semantics.[1] This reformulation process was driven by the desire to bridge HTML's SGML roots with XML's stricter syntax, effectively positioning XHTML as a pure XML subset that could leverage XML's parsing advantages without introducing new features.[12] In a pivotal decision, the W3C membership chose to freeze further evolution of traditional HTML after version 4.01, redirecting efforts toward XML-based alternatives to support the web's transition to more modular and device-agnostic content delivery. This pivot underscored XHTML's role as a transitional standard, enabling HTML documents to be processed as valid XML while maintaining backward compatibility through equivalent document type definitions (DTDs).[1] The early standardization culminated in the proposal of XHTML 1.0 on December 10, 1999, following collaborative work within the HTML Working Group under the W3C's HTML Activity.[13] It achieved W3C Recommendation status on January 26, 2000, marking the official endorsement of XHTML 1.0 as the first in its family of document types—a direct reformulation of HTML 4's three variants (Strict, Transitional, and Frameset) as XML 1.0 applications.[14] This milestone reflected the W3C's strategic emphasis on XML's potential to unify web markup with broader data exchange standards, setting the stage for XHTML's adoption in content authoring and processing tools.[1]Key Milestones and Evolution
Following the initial standardization of XHTML 1.0 in 2000, which reformulated HTML 4 as an XML application, key advancements in the early 2000s focused on modularity to support diverse implementations. XHTML Basic 1.0, published as a W3C Recommendation on December 19, 2000, provided a lightweight subset of XHTML modules tailored for resource-constrained devices such as mobile phones and PDAs, including essential elements for text, images, forms, and basic linking while omitting complex features like frames and scripts. This profile emphasized minimalism to ensure compatibility with low-bandwidth and limited-processing environments. In 2001, the W3C advanced XHTML's flexibility through two interconnected milestones. The Modularization of XHTML 1.0 specification, released as a Recommendation on April 10, 2001, decomposed XHTML into abstract modules—covering structure, text, hypertext, lists, object inclusion, forms, tables, images, and more—enabling the creation of customizable subsets or extensions via XML Document Type Definitions (DTDs). This framework facilitated tailored document types for specific use cases, promoting reusability and interoperability across XML-based applications. Building directly on this, XHTML 1.1 became a W3C Recommendation on May 31, 2001, as a module-based reformulation of XHTML 1.0 Strict, excluding deprecated frames and incorporating Ruby annotations for East Asian typography while adhering strictly to XML syntax rules.[2] The mid-2000s saw the application of modularization to specialized profiles, reflecting XHTML's adaptation to emerging technologies like printing and mobile web access. XHTML-Print, standardized as a W3C Recommendation on September 20, 2006, defined a profile optimized for low-cost printers and mobile printing scenarios, incorporating CSS Print Profile elements to handle page-based output without full-page buffering. Similarly, the XHTML Mobile Profile 1.0, released by the Open Mobile Alliance in 2001 and updated to version 1.1 in 2004,[15] leveraged W3C modularization for compact, device-friendly markup suitable for early mobile browsers, focusing on basic structure and avoiding resource-intensive features. Parallel to these profiles, the W3C initiated XHTML 2.0 in 2002 as a Working Draft, aiming to overhaul XHTML with enhanced semantics, such as role attributes for better accessibility, new elements likeVersions and Variants
XHTML 1.0
XHTML 1.0, published as a W3C Recommendation on January 26, 2000, represents a reformulation of HTML 4.01 as an application of XML 1.0, preserving the semantics of HTML while enforcing stricter XML syntax rules to enhance document structure and extensibility.[1] This specification introduces three Document Type Definitions (DTDs)—Strict, Transitional, and Frameset—mirroring those in HTML 4.01 to accommodate different levels of compatibility with legacy content: the Strict DTD prohibits deprecated elements and attributes to promote cleaner markup, Transitional allows some deprecated features for easier migration, and Frameset supports frame-based layouts.[1] These DTDs enable developers to validate documents against varying degrees of adherence, facilitating a gradual shift from HTML practices.[1] Key features of XHTML 1.0 include mandatory structural elements that align with XML requirements, such as the XML declaration at the document's start, typically<?xml version="1.0" encoding="UTF-8"?>, which specifies the version and character encoding.[1] The root <html> element must include the xmlns attribute set to "http://www.w3.org/1999/xhtml" to declare the document's namespace, ensuring proper recognition by XML parsers.[1] Additionally, all elements must be properly nested and closed—non-empty elements require both opening and closing tags (e.g., <p>...</p>), while void elements like line breaks must be self-closing (e.g., <br />)—preventing common HTML ambiguities and enabling robust parsing.[1] A DOCTYPE declaration referencing one of the three DTDs is also required immediately after the XML declaration to invoke validation.[1]
The significance of XHTML 1.0 lies in its role as the foundational and first widely adopted version of the XHTML family, serving as a bridge for migrating legacy HTML content to XML-based technologies and enabling the use of XML tools like parsers and XSLT for transformations.[18] It garnered broad industry support from companies including IBM, Microsoft, and Netscape, with implementations integrated into early web authoring tools and browsers, marking a pivotal step toward device-independent and modular web content.[18] For backward compatibility with HTML 4 user agents, XHTML 1.0 documents can be served with the text/html MIME type when following specific guidelines, such as avoiding XML-specific features in that mode, though the Strict variant discourages deprecated elements to encourage modern practices.[1] This compatibility, combined with the option for application/xhtml+xml MIME type in XML-aware environments, positioned XHTML 1.0 as a transitional standard that connected the present web to future XML-driven developments, as noted by W3C Director Tim Berners-Lee: "XHTML 1.0 connects the present Web to the future Web."[1][18]
XHTML 1.1 and Modularization
XHTML 1.1, published as a W3C Recommendation on May 31, 2001, with a second edition released on November 23, 2010, defines a strict, module-based document type that builds directly on the XHTML 1.0 Strict variant while eliminating legacy HTML compatibility features.[2][19] This version serves as the foundation for future XHTML family extensions, emphasizing XML conformance over backward compatibility with HTML 4 deprecated elements and attributes.[20] A key departure is the complete removal of frameset functionality and other obsolete features, such as the<frameset> element, to promote cleaner, forward-compatible markup.[20] For XHTML 1.1 documents to be processed as true XML rather than tag-soup HTML, they must be served with the application/xhtml+xml MIME type, as specified in the XHTML Media Types recommendation.
The modularization framework underpinning XHTML 1.1 allows the language to be decomposed into reusable components, facilitating the creation of tailored document types without relying solely on monolithic DTDs. XHTML Modularization 1.1, which became a W3C Recommendation on October 8, 2008, and received a second edition on July 29, 2010, standardizes this approach by providing an abstract specification of XHTML elements and attributes organized into modules, with implementations available via both XML Document Type Definitions (DTDs) and XML Schemas.[21] This enables developers and standards bodies to subset or extend XHTML for specific use cases, such as device-limited environments, by combining only the necessary modules rather than the full language set.[5]
XHTML Modularization 1.1 divides the language into 22 abstract modules, including core ones like the Structure Module (which defines foundational elements such as html, head, body, and title), the Text Module (covering semantic elements like p, div, em, and strong), and the Tables Module (encompassing table, tr, td, and th).[22] Other notable modules include the Forms Module for input handling, the Image Module for multimedia integration, and the Scripting Module for dynamic behavior.[22] By assembling these modules, custom vocabularies can be composed, allowing XHTML to integrate with other XML namespaces or adapt to specialized profiles while maintaining semantic consistency.[5] This flexibility also supports internationalization efforts through dedicated modules, such as the Internationalization Module (for language and direction attributes), the Ruby Annotation Module (for East Asian typographic conventions), and the Bi-directional Text Module (for handling right-to-left scripts).[22] Overall, the modular design promotes reusability and extensibility, positioning XHTML 1.1 as a robust XML-based evolution suited for diverse applications beyond traditional web authoring.[5]
XHTML Basic and Specialized Profiles
XHTML Basic 1.0, published as a W3C Recommendation on December 19, 2000, serves as a lightweight subset of XHTML 1.0 tailored for resource-constrained devices such as personal digital assistants (PDAs) and early mobile phones.[23] It incorporates essential modules for document structure, basic text elements (like paragraphs and headings), hyperlinks, and image inclusion, while excluding advanced features such as frames, applets, and complex tables to minimize processing and memory requirements.[23] This design enables broader interoperability across diverse platforms, including those with limited bandwidth and computational power, by leveraging the XML-based syntax of XHTML for stricter parsing and validation.[23] Building on this foundation, XHTML Basic 1.1 was advanced through the W3C's development process, reaching Candidate Recommendation status in 2007 and becoming a full Recommendation on July 29, 2008.[24] It aligns with Web Content Accessibility Guidelines (WCAG) 1.0 by recommending practices for accessible tables and forms, ensuring better support for users with disabilities on constrained devices.[24] This version was particularly adopted in early smartphones and embedded systems, where its modular structure allowed efficient rendering without overwhelming hardware limitations.[25] Specialized profiles extend XHTML Basic to address niche environments. XHTML-Print 1.0, a W3C Recommendation from September 20, 2006, augments the Basic profile with print-oriented modules, including support for margins, page breaks, and basic pagination controls, to facilitate output on low-cost printers without full-page buffering. Similarly, the XHTML Mobile Profile, developed by the Open Mobile Alliance (OMA), provides tailored enhancements for mobile browsing; version 1.0 was specified in October 2001 as a superset of XHTML Basic, adding elements like improved form controls.[26] Subsequent iterations—1.1 (August 2004), 1.2 (February 2007), and 1.3 (March 2011, as an approved candidate)—introduced scripting compatibility (e.g., ECMAScript Mobile Profile) and advanced input modes for touch interfaces, while preserving XHTML compliance.[15][27][28] These profiles, derived from the modularization framework introduced in XHTML 1.1, prioritize reduced implementation footprints—often suitable for devices with minimal storage and processing capabilities—while ensuring documents remain valid XHTML instances.[2] By selectively combining modules, they enable targeted optimizations, such as omitting deprecated elements or legacy scripting, to support efficient delivery in bandwidth-limited scenarios without sacrificing core extensibility.[24]XHTML 2.0 and Abandoned Efforts
XHTML 2.0 was developed as a Working Draft by the W3C's HTML Working Group, with the first public draft released in August 2002 and subsequent iterations continuing through 2009, aiming to establish a pure XML-based markup language to supplant HTML entirely.[29] The specification emphasized semantic structure over presentational elements, introducing features such as the<section> element for defining document sections and a generic <h> element to replace numbered headings like <h1> through <h6>, thereby promoting more flexible and meaningful content organization.[30]
Key innovations in XHTML 2.0 included a deliberate lack of backward compatibility with prior HTML versions to enable a clean XML foundation, alongside new elements like <replace> for dynamically updating content in client-side applications.[30] It also introduced the role attribute module, which allowed authors to annotate elements with semantic roles to enhance accessibility, enabling user agents to better interpret and adapt content for assistive technologies.[31]
Development efforts were abandoned when the XHTML 2 Working Group's charter expired on December 31, 2009, without renewal, as the W3C shifted resources to HTML5 to address broader web deployment needs; the final document was published as a non-normative Working Group Note in December 2010, never advancing to Recommendation status.[17][16] Although XHTML 2.0 influenced semantic elements in HTML5, such as <nav> and <article>, it faced criticism for overlooking practical browser implementation and real-world authoring realities due to its strict, incompatible design.[32]
XHTML5 and Integration with HTML5
XHTML5 refers to an informal designation for documents that conform to the HTML5 vocabulary while adhering to XML syntax rules, enabling them to be parsed validly as both HTML and XHTML.[33] This polyglot markup approach ensures that the same byte stream produces identical document object models (DOMs) when processed by HTML or XML parsers, with minor exceptions for namespace differences.[34] By employing lowercase element and attribute names, self-closing tags for void elements, and quoted attribute values, XHTML5 documents leverage HTML5's semantic elements like<article> and <section> within a strict XML framework.[35]
The integration of XHTML5 with HTML5 reflects the evolution of web standards, where the W3C's HTML5 Recommendation, finalized in October 2014, established HTML5 as a living standard maintained primarily by the WHATWG, effectively superseding standalone XHTML specifications. In this ecosystem, XHTML serialization serves as an optional XML-based concrete syntax for HTML5, allowing documents to be transmitted using the application/xhtml+xml MIME type while remaining compatible with HTML5's core features.[33] Although pure XHTML efforts like XHTML 2.0 were abandoned, elements of its modularization influenced the flexible extension mechanisms in HTML5's XML syntax.[4]
As of 2025, XHTML5 finds practical application in the EPUB 3.3 specification, where content documents must use XHTML conforming to HTML5's XML syntax, particularly for fixed-layout publications that require precise control over structure.[36] This usage supports embedding extensions via namespaces, such as MathML for mathematical expressions, ensuring interoperability in digital publishing workflows.[37] However, maintenance of XHTML5 tooling remains limited, with warnings from the publishing community about potential risks in toolkit support, including funding challenges for validation tools like EPUBCheck and possible ecosystem fragmentation if shifts toward pure HTML5 occur.[38]
A key advantage of XHTML5 is its flexibility in content negotiation, permitting the same document to be served as text/html for broad browser compatibility or as application/xhtml+xml for XML-aware processors, thereby bridging legacy HTML environments with modern XML-based applications.[39] This dual-serving capability enhances robustness in mixed ecosystems, though it requires careful authoring to avoid parser discrepancies.[34]
Technical Specifications
Syntax Rules and Validation
XHTML, as an application of XML, enforces strict syntax rules to ensure documents are well-formed and parsable by XML processors. Unlike HTML, which tolerates certain errors through tag soup parsing, XHTML requires precise adherence to XML syntax, including lowercase element and attribute names due to XML's case sensitivity.[1] Key syntax rules include mandatory quoting for all attribute values, such as<img src="image.jpg" alt="Description" />, and prohibition of attribute minimization; for example, boolean attributes must be explicitly set like checked="checked" rather than simply checked.[1] Reserved characters in content and attributes must be escaped, with ampersands represented as &, less-than signs as <, and greater-than signs as > when not part of tags.[1] Void elements, which cannot contain content, require explicit closure either with a trailing slash like <br /> or a matching end tag like <hr></hr>.[1]
For elements like <script> and <style>, content must be handled carefully to avoid XML parsing conflicts; in strict XHTML mode, special characters within these elements should be escaped, though CDATA sections can be used to include unescaped content like JavaScript code, as in <script><![CDATA[alert("Hello");]]></script>.[1]
Validation of XHTML documents ensures compliance with these rules and the chosen document type definition (DTD). Documents must be well-formed XML, meaning every start tag has a corresponding end tag, elements are properly nested, and no undeclared entities are used.[1] The W3C Markup Validation Service provides a tool to check XHTML against official DTDs, reporting errors such as unclosed tags or invalid attributes.[40]
For modular versions like XHTML 1.1, validation can also employ XML Schema Definitions (XSD) derived from the XHTML Modularization framework, allowing verification of subsetted or extended profiles against schema modules.[5] This stricter validation process promotes robust authoring but demands more rigorous development practices.
A significant conceptual difference from HTML lies in error handling: XML parsers, used for XHTML, treat syntax errors as fatal and halt processing immediately, preventing partial rendering and enforcing complete well-formedness to avoid unpredictable behavior.[1]
Document Structure and Elements
XHTML documents follow a strict hierarchical structure defined as an XML application, beginning with the root element<html xmlns="http://www.w3.org/1999/xhtml">, which declares the default namespace for XHTML elements.[41] This root element encapsulates the entire document and contains two primary child elements: <head>, which holds metadata such as the required <title> element and optional elements like <link> for stylesheets or external resources, and <body>, which encompasses the visible content of the document.[41]
The core elements in XHTML are organized into sets that facilitate structured content creation, including block-level elements such as <div> for generic divisions and <p> for paragraphs, which establish the document's layout flow.[1] Inline elements like <span> for non-semantic grouping and <a> for hyperlinks allow precise styling or functionality within text blocks.[1] Forms are supported through elements like <form> for overall form containers and <input> for user inputs, enabling interactive data collection.[1] Semantic elements, such as <ul> for unordered lists and <table> for tabular data, provide meaning beyond presentation, aiding accessibility and search engines.[1]
XHTML's modular design allows these element sets to be combined flexibly, as outlined in the XHTML Modularization specification, which defines abstract modules for structure, text, and other categories that can be subsetted or extended to suit specific needs.[5] To integrate foreign vocabularies, such as SVG for graphics, namespaces are employed via attributes like xmlns:svg="http://www.w3.org/2000/svg", enabling seamless embedding of elements from other XML-based languages within the XHTML document.[42]
Unlike HTML, XHTML requires all elements to be properly nested with explicit closing tags, eliminating implicit closures—for instance, paragraphs must be explicitly closed rather than inferred by subsequent block elements.[43] This enforces the syntax rules for XML compliance, ensuring documents are well-formed and parseable as XML.[43]
DOCTYPE Declarations and XML Features
XHTML documents, as XML applications, incorporate specific declarations to define their structure, encoding, and namespace bindings, distinguishing them from traditional HTML while enabling advanced XML processing. The DOCTYPE declaration is mandatory in both XHTML 1.0 and XHTML 1.1, serving to reference the appropriate Document Type Definition (DTD) for validation. In XHTML 1.0, it precedes the root<html> element and must use one of three public identifiers corresponding to Strict, Transitional, or Frameset variants; for example, the Strict variant is declared as <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">. [1] XHTML 1.1, leveraging modularization, employs a single DOCTYPE that references a composite modular DTD: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">. [2] This modular approach assembles XHTML from independent modules, allowing for customized document types without a monolithic DTD.
An optional XML processing instruction, <?xml version="1.0" encoding="UTF-8"?>, may appear at the document's start to specify the XML version and character encoding, though it is strongly recommended for clarity. [1] This declaration becomes mandatory if the document's encoding differs from the XML defaults of UTF-8 or UTF-16, ensuring parsers correctly interpret non-default encodings without relying on external protocols like HTTP headers. [1] The absence of this declaration restricts documents to UTF-8 or UTF-16, influencing how servers select MIME types such as application/xhtml+xml for proper XML-based rendering.
XHTML binds the default namespace to the XHTML namespace URI, http://www.w3.org/1999/xhtml, typically via the attribute xmlns="http://www.w3.org/1999/xhtml" on the root <html> element, ensuring all unprefixed elements belong to this namespace. [44] This binding facilitates embedding other XML vocabularies, such as MathML or SVG, as "XML islands" through prefixed namespaces (e.g., xmlns:math="http://www.w3.org/1998/Math/MathML"), enabling compound documents without conflicts. [1] Entity references in XHTML are limited to the five predefined XML entities (&, <, >, ", ') plus those declared in the DTD's entity sets (e.g., for Latin-1 characters), prohibiting undefined HTML-style entities to maintain strict XML conformance. [1]
These features support XML processing instructions beyond the declaration, such as stylesheets via <?xml-stylesheet type="text/xsl" href="style.xsl" rel="nofollow"?>, and allow validation against XML Schemas in addition to DTDs. For instance, XHTML 1.0 provides corresponding XML Schemas for its DTD variants, offering an alternative validation mechanism that leverages Schema's richer type system for stricter enforcement. [45]
Compatibility and Implementation
Backward Compatibility with HTML
XHTML 1.0 was designed as a reformulation of HTML 4 in XML syntax, enabling backward compatibility with existing HTML user agents when served with thetext/html media type.[1] HTML parsers, which are tolerant of certain XML-like features in XHTML, can render such documents effectively if authors adhere to specific compatibility guidelines outlined in the specification's Appendix C. These guidelines ensure that XHTML documents mimic HTML 4 behavior, allowing legacy browsers to process them without significant errors.[46]
A key technique for compatibility involves avoiding XML-only features that HTML parsers do not recognize, such as the XML declaration (<?xml version="1.0" encoding="UTF-8"?>) or processing instructions, which could trigger quirks mode or parsing failures in older browsers like Internet Explorer 6.[9] Instead, documents should include a proper DOCTYPE declaration, such as the one for XHTML 1.0 Strict (<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">), and be served via HTTP with Content-Type: text/html; charset=utf-8. For elements that are empty in HTML, like <br>, authors should use self-closing syntax with a space before the slash (<br />) to prevent misinterpretation by HTML parsers, while ensuring all tags are properly closed and attributes are quoted—requirements inherent to XHTML but tolerated in strict HTML contexts.[46]
The transitional variant of XHTML 1.0 further enhances backward compatibility by incorporating deprecated HTML 4 attributes and elements, such as target on <a> tags or <center>, through its DTD, allowing a smoother migration path for legacy content without breaking rendering in HTML browsers.[1] Browsers employ "tag soup" recovery mechanisms—error-tolerant parsing strategies developed for malformed HTML—that effectively ignore XHTML's stricter syntax rules, such as case-sensitivity or mandatory closures, when the document is served as text/html, treating it as forgiving HTML input.[46] This recovery process ensures visual fidelity but may not preserve semantic precision, as the resulting DOM could differ from XML parsing outcomes.
Among XHTML 1.0 variants, the Strict DTD offers the highest semantic compatibility with HTML 4, excluding deprecated features while aligning element and attribute definitions closely with the HTML specification.[1] However, achieving full XML compliance, including strict validation and namespace awareness, requires serving documents as application/xhtml+xml to XHTML-aware user agents, as older HTML browsers lack native XML parsing support and may fail or degrade performance otherwise.[9] Brief references to syntax differences, such as lowercase element names in XHTML versus HTML's case-insensitivity, underscore the need for these guidelines to bridge the formats.[46]
Cross-Browser and Cross-Format Compatibility
XHTML 1.0 documents, when served with the MIME type text/html, are universally supported across all major web browsers because they conform to HTML 4.01 syntax and are rendered identically to HTML documents. This backward compatibility ensures broad rendering consistency without requiring special handling. However, when served strictly as XML with the MIME type application/xhtml+xml, support is more limited historically; for instance, Mozilla Firefox has provided full support since version 1.5 in 2004, Apple Safari since version 3.0 in 2007, Google Chrome since version 4.0 in 2010, and Microsoft Edge (Chromium-based) since its 2019 release, allowing native XML parsing and stricter error handling.[47] Internet Explorer versions up to 11 lack native support for application/xhtml+xml, falling back to treating such documents as HTML or displaying parsing errors, which necessitated workarounds like serving as text/html or using polyfills for legacy environments.[8] In terms of cross-format compatibility, XHTML integrates seamlessly with Cascading Style Sheets (CSS), as the same selectors and properties apply to XHTML elements as they do to HTML, enabling consistent styling across browsers that support CSS Levels 2 and beyond. Similarly, JavaScript interoperability is robust through the Document Object Model (DOM) Level 2 and higher, where XHTML documents expose the same node-based API for scripting, though older Internet Explorer versions required additional configuration for XML namespace awareness due to their limited native XML support. These integrations maintain functional parity with HTML, but strict XHTML serving can introduce quirks in pre-2010 browsers if XML-specific features like well-formedness are enforced. By 2025, all major contemporary browsers— including the latest versions of Chrome, Firefox, Safari, and Edge—handle polyglot XHTML5 documents seamlessly, as these are valid HTML5 when served as text/html and valid XHTML5 when served as application/xhtml+xml, with full support for HTML5 features and fallbacks for legacy rendering modes.[34] Legacy support remains viable through techniques like conditional comments or content negotiation to serve appropriate MIME types based on user agents, ensuring cross-browser reliability without compromising strict XML compliance.[48] A key advantage of XHTML's XML foundation is its use of namespaces, which facilitate the creation of compound documents by embedding other XML vocabularies, such as MathML for mathematical notation, within XHTML structures. For example, declaring the MathML namespace URI (http://www.w3.org/1998/Math/MathML) allows browsers supporting XML namespaces—like Firefox, Safari, and Chrome—to render embedded [49] This modular approach, defined in the XHTML Modularization specification, promotes consistent handling in environments that parse XHTML as XML, though it requires careful namespace prefixing to avoid conflicts in mixed-format scenarios.Current Adoption and Practical Applications
In 2025, XHTML adoption for general web development remains low, having been largely superseded by HTML5, with over 95% of active websites utilizing HTML5 elements for their enhanced multimedia and semantic capabilities.[50] The W3C has limited maintenance of XHTML specifications to errata corrections since 2010, following the second edition of XHTML 1.1, which addressed known issues and added XML Schema support without introducing new features.[51] XHTML persists in niche digital publishing standards, particularly the EPUB 3.4 specification, published as a W3C Working Draft in October 2025, where it serves as the XML syntax for HTML content documents in both reflowable and fixed-layout formats.[52] Reflowable EPUB content relies on XHTML for flexible, adaptive rendering across devices, while fixed-layout uses it for precise, pre-paginated designs controlled by metadata, ensuring compatibility with the publishing ecosystem despite discussions on allowing pure HTML5 syntax.[52] However, concerns have arisen in 2025 regarding potential deprecation of XHTML support in core development toolkits for EPUB, as the format's lack of active maintenance increases risks of fragmented tooling.[53] Practical applications of XHTML continue in legacy mobile and embedded systems through profiles like XHTML Mobile Profile 1.0, designed for resource-constrained devices, though it is now considered obsolete in favor of modern alternatives. In print and publishing, XHTML-Print remains relevant for low-cost, driverless printing environments, enabling top-to-bottom rendering on basic printers without full-page buffering.[54] For accessibility tools and strict authoring, polyglot markup—combining XHTML's XML syntax with HTML5—facilitates robust, well-formed documents that enhance semantic structure and screen reader compatibility without adding unique accessibility mandates.[34] XHTML also functions as an XML bridge in e-learning standards like SCORM, where tools such as the eLearning XHTML editor support content creation for sharable objects in training modules.[55] In digital preservation, XHTML is recommended by institutions like the Library of Congress for archiving web content due to its XML conformance, allowing validation and processing with standard tools for long-term structural integrity.[56]Challenges and Criticisms
Technical Limitations
XHTML's foundation in XML imposes a strict syntax that significantly increases authoring complexity compared to HTML. Unlike HTML, which permits tag omission for certain elements such as<p> or <li> based on context, XHTML requires explicit closing tags for all non-void elements to ensure well-formedness, leading to more verbose code and higher potential for errors during manual authoring.[1] This rigidity stems from XML's case-sensitive nature and mandatory attribute quoting, where even minor deviations—like unquoted values or uppercase tags—result in parsing failures.[1]
A key technical drawback is XHTML's poor error recovery mechanisms. While HTML parsers employ forgiving algorithms that attempt to reconstruct a document tree from malformed input, allowing browsers to render content despite syntax errors, XHTML documents must be perfectly well-formed; any violation triggers a fatal parsing error with no recovery, potentially rendering the entire page unusable in XML-compliant user agents.[57] This lack of tolerance contrasts sharply with HTML's robustness, making XHTML less suitable for dynamic or user-generated content where imperfections are common.[57]
Performance limitations arise from XML's parsing overhead. XHTML requires XML parsers, which are generally slower than HTML-specific parsers due to stricter validation checks and namespace handling; for instance, benchmarks show XML parsing via DOMParser can take up to four times longer than HTML parsing for large documents.[58] Additionally, XHTML documents tend to have larger file sizes because of mandatory self-closing tags for void elements (e.g., <img src="example.jpg" alt="Example" /> instead of <img src="example.jpg" alt="Example">), adding extra characters without functional benefit in most cases.[59]
Compatibility issues further compound these challenges, particularly with void elements. In XHTML, elements like <hr /> must use self-closing syntax to comply with XML rules, but when served as text/html (common for broader compatibility), HTML5 parsers ignore the trailing slash without causing inconsistencies or broken layouts for void elements, though it is redundant and can confuse developers. True strict XHTML parsing requires serving with an XML MIME type like application/xhtml+xml.[60] [61] XHTML's modular subsets, such as XHTML Basic, support scripting through optional modules including <script> elements for inline JavaScript (with XML-specific escaping like CDATA), though designed for resource-constrained environments which may limit advanced features.[1] [62]
Finally, XHTML's over-reliance on schemas and DTDs for validation introduces unnecessary complexity for simple documents. While these mechanisms enable extensibility, they require authors to reference external declarations in the DOCTYPE, which can bloat processing requirements and complicate deployment in environments without schema support, diverging from the lightweight nature of basic HTML pages.[1]
