- From: CVS User lsilli <cvsmail@w3.org>
- Date: Thu, 05 Sep 2013 04:26:44 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/html-xhtml-author-guide
In directory roscoe:/tmp/cvs-serv3634/html-xhtml-author-guide
Modified Files:
html-xhtml-authoring-guide.html
Log Message:
Fixing another structure bug that creeped in.
--- /sources/public/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html 2013/09/05 03:37:47 1.132
+++ /sources/public/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html 2013/09/05 04:26:44 1.133
@@ -1,76 +1,76 @@
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-US" lang="en-US" >
<head>
- <title>Polyglot Markup: A robust profile of the HTML5 vocabulary</title>
- <meta charset="utf-8" />
- <script class="remove" src="http://www.w3.org/Tools/respec/respec-w3c-common" async=""></script>
- <script class="remove">
- var respecConfig = {
- specStatus: "ED",
- shortName: "html-polyglot",
- publishDate: "2013-09-03",
- previousPublishDate: "2010-10-19",
- previousMaturity: "WD",
- edDraftURI: "http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html",
- // lcEnd: "2009-08-05",
- editors: [
- { name: "Eliot Graff", company: "Microsoft Corporation" },
- { name: "Leif H. Silli", company: "&METODIUS DA"}
- ],
- wg: "HTML working group",
- wgURI: "http://www.w3.org/html/wg/",
- wgPublicList: "public-html",
- wgPatentURI: "http://www.w3.org/2004/01/pp-impl/40318/status"
- };
- </script>
-<style>table.simple tr>*:first-child{text-align:right;}
-table.simple th code{color:yellow;font-weight:bold;font-size:larger;}
-table.simple [colspan="2"]{text-align:center;}
-table.simple [colspan="3"]{text-align:center;}
-ul.inline-list {white-space:normal}
-ul.inline-list li {display:inline;}
-ul.inline-list li:after {content:",";}
-ul.inline-list li:last-child:after {content:"";}
-</style>
+ <title>Polyglot Markup: A robust profile of the HTML5 vocabulary</title>
+ <meta charset="utf-8" />
+ <script class="remove" src="http://www.w3.org/Tools/respec/respec-w3c-common" async=""></script>
+ <script class="remove">
+ var respecConfig = {
+ specStatus: "ED",
+ shortName: "html-polyglot",
+ publishDate: "2013-09-03",
+ previousPublishDate: "2010-10-19",
+ previousMaturity: "WD",
+ edDraftURI: "http://dev.w3.org/html5/html-xhtml-author-guide/html-xhtml-authoring-guide.html",
+ // lcEnd: "2009-08-05",
+ editors: [
+ { name: "Eliot Graff", company: "Microsoft Corporation" },
+ { name: "Leif H. Silli", company: "&METODIUS DA"}
+ ],
+ wg: "HTML working group",
+ wgURI: "http://www.w3.org/html/wg/",
+ wgPublicList: "public-html",
+ wgPatentURI: "http://www.w3.org/2004/01/pp-impl/40318/status"
+ };
+ </script>
+ <style>table.simple tr>*:first-child{text-align:right;}
+ table.simple th code{color:yellow;font-weight:bold;font-size:larger;}
+ table.simple [colspan="2"]{text-align:center;}
+ table.simple [colspan="3"]{text-align:center;}
+ ul.inline-list {white-space:normal}
+ ul.inline-list li {display:inline;}
+ ul.inline-list li:after {content:",";}
+ ul.inline-list li:last-child:after {content:"";}
+ </style>
</head>
<body>
<section id="abstract">
- A document that uses <a title="polyglot markup">polyglot markup</a> is a document that is a stream of bytes that parses into identical document trees
- (with some exceptions, as noted in the <a href="#introduction">Introduction</a>) when processed as HTML and when processed as XML.
- Polyglot markup that meets a well-defined set of constraints is interpreted as compatible, regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification.
- Polyglot markup uses a specific DOCTYPE, namespace declarations, and a specific case—normally lower case but occasionally camel case—for element and attribute names.
- Polyglot markup uses lower case for certain attribute values.
- Further constraints include those on void elements, named entity references, and the use of scripts and style.
-<!--End section: Abstract-->
+ A document that uses <a title="polyglot markup">polyglot markup</a> is a document that is a stream of bytes that parses into identical document trees
+ (with some exceptions, as noted in the <a href="#introduction">Introduction</a>) when processed as HTML and when processed as XML.
+ Polyglot markup that meets a well-defined set of constraints is interpreted as compatible, regardless of whether they are processed as HTML or as XHTML, per the HTML5 specification.
+ Polyglot markup uses a specific DOCTYPE, namespace declarations, and a specific case—normally lower case but occasionally camel case—for element and attribute names.
+ Polyglot markup uses lower case for certain attribute values.
+ Further constraints include those on void elements, named entity references, and the use of scripts and style.
+ <!--End section: Abstract-->
</section>
<section id="sotd">
- <p>
- This document summarizes design guidelines for authors who wish their XHTML or HTML documents to validate on both HTML and XML parsers.
- This specification is intended to be used by web authors, particularly authors who want to serve receivers which may have either (but not both) XML or HTML parsers available.
- This commonly arises in legacy systems and content syndication.
- Polyglot is one of several transition mechanisms from legacy XML to HTML5 and this document serves to describe it accurately.
- </p>
- <p>
- No recommendation is made in this document or by the W3C regarding whether or not to publish polyglot content.
- In general, authors are encouraged to publish HTML content using HTML5 syntax and media types
- (either HTML syntax and <code>text/html</code>, or XHTML syntax and <code>application/xhtml+xml</code>).
- </p>
- <p>
- This document is not a specification for user agents and creates no obligations on user agents.
- Note that this recommendation does not define how HTML5-conforming user agents should process HTML documents.
- Nor does it define the meaning of the Internet Media Type <code>text/html</code>.
- For user agent guidance and for these definitions, see [[!HTML5]] and [[!RFC2854]].
- </p>
- <p>
- Please submit bugs for this document by using the W3C's public bug database (<a href="http://www.w3.org/Bugs/Public/">
- http://www.w3.org/Bugs/Public/</a>) with the product set to <kbd>HTML WG</kbd> and the component set to
- <kbd>HTML/XHTML Compatibility Authoring Guide (ed: Eliot Graff)</kbd>.
- If you cannot access the bug database, submit comments by email to the mailing list noted below.
- </p>
-<!--End section: Status of This Document-->
+ <p>
+ This document summarizes design guidelines for authors who wish their XHTML or HTML documents to validate on both HTML and XML parsers.
+ This specification is intended to be used by web authors, particularly authors who want to serve receivers which may have either (but not both) XML or HTML parsers available.
+ This commonly arises in legacy systems and content syndication.
+ Polyglot is one of several transition mechanisms from legacy XML to HTML5 and this document serves to describe it accurately.
+ </p>
+ <p>
+ No recommendation is made in this document or by the W3C regarding whether or not to publish polyglot content.
+ In general, authors are encouraged to publish HTML content using HTML5 syntax and media types
+ (either HTML syntax and <code>text/html</code>, or XHTML syntax and <code>application/xhtml+xml</code>).
+ </p>
+ <p>
+ This document is not a specification for user agents and creates no obligations on user agents.
+ Note that this recommendation does not define how HTML5-conforming user agents should process HTML documents.
+ Nor does it define the meaning of the Internet Media Type <code>text/html</code>.
+ For user agent guidance and for these definitions, see [[!HTML5]] and [[!RFC2854]].
+ </p>
+ <p>
+ Please submit bugs for this document by using the W3C's public bug database (<a href="http://www.w3.org/Bugs/Public/">
+ http://www.w3.org/Bugs/Public/</a>) with the product set to <kbd>HTML WG</kbd> and the component set to
+ <kbd>HTML/XHTML Compatibility Authoring Guide (ed: Eliot Graff)</kbd>.
+ If you cannot access the bug database, submit comments by email to the mailing list noted below.
+ </p>
+ <!--End section: Status of This Document-->
</section>
<!--
@@ -81,181 +81,179 @@
-->
<section id="introduction" class="informative"><h2>Introduction</h2>
-<p>It is sometimes valuable to be able to serve HTML5 documents that are also well formed XML documents.
-An author may, for example, use XML tools to generate a document, and they and others may process the document using XML tools.
-The language used to create documents that can be parsed by both HTML and XML parsers is called <a title="polyglot markkup">polyglot markup</a>.
-<a title="polyglot markup">Polyglot markup</a> is the overlap language of documents that are both HTML5 documents and XML documents.
-It is recommended that these documents be served as either <code>text/html</code> (if the content is transmitted to an HTML-aware user agent)
-or <code>application/xhtml+xml</code> (if the content is transmitted to an XHTML-aware user agent).
-Other permissible MIME types are <code>text/xml</code>, <code>application/xml</code>,
-and any MIME type whose subtype ends with the four characters "<code>+xml</code>". [[!XML-MT]]</p>
-<!--end general-->
-<section id="scope">
-<h3>Scope</h3>
-<p>Polylglot markup is a <em><a title="robustness">robust</a></em> – but entirely <em>optional</em> – profile of the HTML vocabulary.
- All web content need not be authored in <a>polyglot markup</a> and it is primarily an option
- for authors wanting to increase the <a title="robustness">robustness</a> of their documents.
-<a title="polyglot markup">Polyglot markup</a> works best, and can be a beneficial option, in controlled environments and for authoring tools.</p>
-<p><a title="polyglot markup">Polyglot markup</a> is ideal for publishing when there's a strong desire to serve both HTML and XML tool chains
-without simultaneously having to maintain dual copies of the content: one in HTML and a second in XHTML.
-In addition, a single <a>polyglot markup</a> output requires less infrastructure to produce than to produce both HTML and XHTML output for the same content.
-<a title="polyglot markup">Polyglot markup</a> is also be beneficial when lightweight processes—such as
-quick testing or even hand-authoring—are applied to content intended to be published both as HTML and XHTML,
-especially if that content is not sent through a tool chain.</p>
-
-<p class="note">XML-based HTML tools or systems intended for the most general contexts of use cannot <strong><em>depend</em></strong> on polyglot input: for maximum flexibility,
- such tools should use the technique of using an HTML parser that produces an XML-compatible DOM or event stream.</p>
-</section>
-<!--end scope-->
-<section id="robust">
- <h3>Robustness</h3>
-
- <p>Polyglot markup is a means to an end – <dfn id="dfn-robustness">robustness</dfn>. It is not a goal in itself. However, authors do not need
- to understand these benefits in order to use and benefit from this syntax. But neither does anyone
- need to exaggerate its benefits. For instance, <a title="polyglot markup">polyglot markup</a> does not add semantics. Polyglot markup does,
- however, work to <em>preserve</em> semantics, including during the authoring process. Polyglot markup
- also doesn’t ensure accessibility - as it does not add any requirements
- that other relevant specs have not allready added. But it can work to <em>preserve</em> accessibility.</p>
-
- <p>The motivation behind, and reason for <a title="polyglot markup">polyglot markup</a> to exist as a specification, is its widely supported
- <a title="robustness">robustness</a>. With <a title="robustness">robust</a> (also known as conservative) markup, authors can <q cite="http://www.w3.org/TR/WCAG20/#robust">
- maximize compatibility with current and future user agents</q> and authoring tools. [[!WCAG20]]</p>
-
- <p>Polyglot markup seeks to define constraints on the serialization of a DOM tree in a <a title="robustness">robust</a> manner that
- is likely to retain semantics when said serialization is reparsed using a variety of parsers, be
- they full featured and bug free HTML5 parsers, somewhat HTML-aware parsers, and even XML parsers.
- </p>
-
- <p> For the most part, <a title="polyglot markup">polyglot markup</a> is just a pure deduction of the validity constraints and syntax requirements that
- HTML and XHTML dictate, many of which took polyglotness into consideration when they were added to HTML5.
- However, for reasons of <a title="robustness">robustness</a>, the spec sometimes goes a little further than the principle of the lowest common
- denominator would have required.</p>
-
- <p> For instance, included in the set of constraints on the serialization is the requirement to use the UTF-8 encoding.
- This requirement is not only because of the documented benefits (the HTML-specific benefits are described in HTML5 [[!HTML5]]) –
- which in turn has lead the HTML5 specification to recommend
- that all new documents use UTF-8, but also because it is the sole encoding that <em>every</em> parser, be it an HTML parser or
- an XML parser, is required to support. Also, UTF-8 might in some situations be the sole <em>HTML-conforming</em> option, since it is one of
- only two encodings (the other being UTF-16, with its own, separate set of well-known issues) for which XML well-formed
- rules doesn’t require the encoding to be explicitly declared. This in turn has the benefit that the anyhow HTML-invalid XML
- encoding declaration kan reliably be skipped without causing any side-effects. E.g. if one opted to use the <code>KOI8-R</code>,
- encoding, then, as a side-effect of HTML-conformance and XML well-formedness requirements, the author would have
- been forced to rely on a higher protocol (such as MIME <code>Content-Type</code>) in order to support XML parsers. By requiring
- UTF-8, this side-effect is avoided. And so, while not the only theoretical possibility, the choice of
- UTF-8 as the sole option, is justified by the underlying principle of <a title="robustness">robustness</a>.</p>
-
- <p>Using <a title="robustness">robust</a> syntax can enable documents to be parsed more reliable in less capable parsers.
- But even if the document can be expected to be parsed and validated by fully HTML5 conforming tools,
- <a title="polyglot markup">polyglot markup</a> adds <a title="robustness">robustness</a>. As an example, when serialized as HTML, the closing tag for
- the <code>p</code> element is entirely optional and will be inferred if not present. But inclusion of
- closings tags, as required by XML and, thus, by <a title="polyglot markup">polyglot markup</a>, cause no harm beyond a minor increase
- in transfer size (an increase often mitigated by compression), but does
- allow validators to detect situations where the implicit closing rules
- don't match what the author intended.
- </p>
- <p class="note">
- Polyglot markup is not defined as ”robust markup” because the XML-based polyglot markup
- syntax is not the only way to increase <a title="robustness">robustness</a>.
- For instance, an HTML validator or an authoring tool could require all tags to be closed even if
- this is not required by the HTML syntax. But then again, <a title="polyglot markup">polyglot markup</a>, being valid
- XML, has some sometimes practical benefits which such a custom setup alone would not have.
- </p>
-</section>
-<!--end robust-->
-</section>
-<!-- end intro-->
+ <p>It is sometimes valuable to be able to serve HTML5 documents that are also well formed XML documents.
+ An author may, for example, use XML tools to generate a document, and they and others may process the document using XML tools.
+ The language used to create documents that can be parsed by both HTML and XML parsers is called <a title="polyglot markkup">polyglot markup</a>.
+ <a title="polyglot markup">Polyglot markup</a> is the overlap language of documents that are both HTML5 documents and XML documents.
+ It is recommended that these documents be served as either <code>text/html</code> (if the content is transmitted to an HTML-aware user agent)
+ or <code>application/xhtml+xml</code> (if the content is transmitted to an XHTML-aware user agent).
+ Other permissible MIME types are <code>text/xml</code>, <code>application/xml</code>,
+ and any MIME type whose subtype ends with the four characters "<code>+xml</code>". [[!XML-MT]]</p>
+ <!--end general-->
+ <section id="scope">
+ <h3>Scope</h3>
+ <p>Polylglot markup is a <em><a title="robustness">robust</a></em> – but entirely <em>optional</em> – profile of the HTML vocabulary.
+ All web content need not be authored in <a>polyglot markup</a> and it is primarily an option
+ for authors wanting to increase the <a title="robustness">robustness</a> of their documents.
+ <a title="polyglot markup">Polyglot markup</a> works best, and can be a beneficial option, in controlled environments and for authoring tools.</p>
+ <p><a title="polyglot markup">Polyglot markup</a> is ideal for publishing when there's a strong desire to serve both HTML and XML tool chains
+ without simultaneously having to maintain dual copies of the content: one in HTML and a second in XHTML.
+ In addition, a single <a>polyglot markup</a> output requires less infrastructure to produce than to produce both HTML and XHTML output for the same content.
+ <a title="polyglot markup">Polyglot markup</a> is also be beneficial when lightweight processes—such as
+ quick testing or even hand-authoring—are applied to content intended to be published both as HTML and XHTML,
+ especially if that content is not sent through a tool chain.</p>
+ <p class="note">XML-based HTML tools or systems intended for the most general contexts of use cannot <strong><em>depend</em></strong> on polyglot input: for maximum flexibility,
+ such tools should use the technique of using an HTML parser that produces an XML-compatible DOM or event stream.</p>
+ </section>
+ <!--end scope-->
+ <section id="robust">
+ <h3>Robustness</h3>
+
+ <p>Polyglot markup is a means to an end – <dfn id="dfn-robustness">robustness</dfn>. It is not a goal in itself. However, authors do not need
+ to understand these benefits in order to use and benefit from this syntax. But neither does anyone
+ need to exaggerate its benefits. For instance, <a title="polyglot markup">polyglot markup</a> does not add semantics. Polyglot markup does,
+ however, work to <em>preserve</em> semantics, including during the authoring process. Polyglot markup
+ also doesn’t ensure accessibility - as it does not add any requirements
+ that other relevant specs have not allready added. But it can work to <em>preserve</em> accessibility.</p>
+
+ <p>The motivation behind, and reason for <a title="polyglot markup">polyglot markup</a> to exist as a specification, is its widely supported
+ <a title="robustness">robustness</a>. With <a title="robustness">robust</a> (also known as conservative) markup, authors can <q cite="http://www.w3.org/TR/WCAG20/#robust">
+ maximize compatibility with current and future user agents</q> and authoring tools. [[!WCAG20]]</p>
+
+ <p>Polyglot markup seeks to define constraints on the serialization of a DOM tree in a <a title="robustness">robust</a> manner that
+ is likely to retain semantics when said serialization is reparsed using a variety of parsers, be
+ they full featured and bug free HTML5 parsers, somewhat HTML-aware parsers, and even XML parsers.
+ </p>
+ <p> For the most part, <a title="polyglot markup">polyglot markup</a> is just a pure deduction of the validity constraints and syntax requirements that
+ HTML and XHTML dictate, many of which took polyglotness into consideration when they were added to HTML5.
+ However, for reasons of <a title="robustness">robustness</a>, the spec sometimes goes a little further than the principle of the lowest common
+ denominator would have required.</p>
+
+ <p> For instance, included in the set of constraints on the serialization is the requirement to use the UTF-8 encoding.
+ This requirement is not only because of the documented benefits (the HTML-specific benefits are described in HTML5 [[!HTML5]]) –
+ which in turn has lead the HTML5 specification to recommend
+ that all new documents use UTF-8, but also because it is the sole encoding that <em>every</em> parser, be it an HTML parser or
+ an XML parser, is required to support. Also, UTF-8 might in some situations be the sole <em>HTML-conforming</em> option, since it is one of
+ only two encodings (the other being UTF-16, with its own, separate set of well-known issues) for which XML well-formed
+ rules doesn’t require the encoding to be explicitly declared. This in turn has the benefit that the anyhow HTML-invalid XML
+ encoding declaration kan reliably be skipped without causing any side-effects. E.g. if one opted to use the <code>KOI8-R</code>,
+ encoding, then, as a side-effect of HTML-conformance and XML well-formedness requirements, the author would have
+ been forced to rely on a higher protocol (such as MIME <code>Content-Type</code>) in order to support XML parsers. By requiring
+ UTF-8, this side-effect is avoided. And so, while not the only theoretical possibility, the choice of
+ UTF-8 as the sole option, is justified by the underlying principle of <a title="robustness">robustness</a>.</p>
+
+ <p>Using <a title="robustness">robust</a> syntax can enable documents to be parsed more reliable in less capable parsers.
+ But even if the document can be expected to be parsed and validated by fully HTML5 conforming tools,
+ <a title="polyglot markup">polyglot markup</a> adds <a title="robustness">robustness</a>. As an example, when serialized as HTML, the closing tag for
+ the <code>p</code> element is entirely optional and will be inferred if not present. But inclusion of
+ closings tags, as required by XML and, thus, by <a title="polyglot markup">polyglot markup</a>, cause no harm beyond a minor increase
+ in transfer size (an increase often mitigated by compression), but does
+ allow validators to detect situations where the implicit closing rules
+ don't match what the author intended.
+ </p>
+ <p class="note">
+ Polyglot markup is not defined as ”robust markup” because the XML-based polyglot markup
+ syntax is not the only way to increase <a title="robustness">robustness</a>.
+ For instance, an HTML validator or an authoring tool could require all tags to be closed even if
+ this is not required by the HTML syntax. But then again, <a title="polyglot markup">polyglot markup</a>, being valid
+ XML, has some sometimes practical benefits which such a custom setup alone would not have.
+ </p>
+ </section>
+ <!--end robust-->
+</section>
+<!-- end intro-->
<section id="syntax">
<h2>The syntax of polyglot markup</h2>
<section id="principles"><h3>Principles</h3>
- <p>
- <dfn>Polyglot markup</dfn> results in:
- </p>
- <ul>
- <li>a valid HTML document. [[!HTML5]]</li>
- <li>a <a href="http://www.w3.org/TR/2008/PER-xml-20080205/#sec-well-formed">well-formed XML</a> document. [[!XML10]]</li>
- <li>identical DOMs when processed as HTML and when processed as XML, with some notable exceptions: HTML and XML parsers generate different DOMs for some
- <code>xml</code> (<code>xml:lang</code>, <code>xml:space</code>, and <code>xml:base</code>),
- <code>xmlns</code> (<code>xmlns=""</code> and <code>xmlns:xlink=""</code>), and <code>xlink</code> (such as <code>xlink:href</code>) attributes.
- XML requires and HTML5 permits these attributes in certain locations and the attributes are preserved by HTML parsers. The exception must not break the requiremetn to be a valid HTML document.
- </li>
- </ul>
- <p>
- <a title="polyglot markup">Polyglot markup</a> is not constrained:
- </p>
- <ul>
- <li>to be <a href="http://www.w3.org/TR/2008/PER-xml-20080205/#dt-valid">valid XML</a>. [[!XML10]]</li>
- <li>by conformance to any XML DTD.</li>
- </ul>
- <p>
- <a title="polyglot markup">Polyglot markup</a> is scripted according to the rules of XML (does not use <code>document.write</code>, for example)
- and excludes HTML elements that are impossible to replicate in an XML parser (does not use the <code>noscript</code> element, for example).
- <a title="polyglot markup">Polyglot markup</a> triggers non-quirks mode in HTML parsers,
- as non-quirks mode is closest to XML-mode rendering, in regard to both DOM and CSS.
- <a title="polyglot markup">Polyglot markup</a> results in the same encoding and the same language in both HTML-mode and XML-mode.
- </p>
-
- <p>
- <a title="polyglot markup">Polyglot markup</a>, itself being valid HTML5,
- supports extensibility as it is defined in
- <a href="http://www.w3.org/TR/html5/infrastructure.html#extensibility">Section 2.2.3 Extensibility</a> of HTML5,
- so long as the extension does not violate the rules of <a>polyglot markup</a>. [[!HTML5]]
- In addition, being well formed XML, <a>polyglot markup</a> can be extended when it is served as <code>application/xhtml+xml</code>.
- </p>
-</section>
-<!--End section: principles-->
+ <p>
+ <dfn>Polyglot markup</dfn> results in:
+ </p>
+ <ul>
+ <li>a valid HTML document. [[!HTML5]]</li>
+ <li>a <a href="http://www.w3.org/TR/2008/PER-xml-20080205/#sec-well-formed">well-formed XML</a> document. [[!XML10]]</li>
+ <li>identical DOMs when processed as HTML and when processed as XML, with some notable exceptions: HTML and XML parsers generate different DOMs for some
+ <code>xml</code> (<code>xml:lang</code>, <code>xml:space</code>, and <code>xml:base</code>),
+ <code>xmlns</code> (<code>xmlns=""</code> and <code>xmlns:xlink=""</code>), and <code>xlink</code> (such as <code>xlink:href</code>) attributes.
+ XML requires and HTML5 permits these attributes in certain locations and the attributes are preserved by HTML parsers. The exception must not break the requiremetn to be a valid HTML document.
+ </li>
+ </ul>
+ <p>
+ <a title="polyglot markup">Polyglot markup</a> is not constrained:
+ </p>
+ <ul>
+ <li>to be <a href="http://www.w3.org/TR/2008/PER-xml-20080205/#dt-valid">valid XML</a>. [[!XML10]]</li>
+ <li>by conformance to any XML DTD.</li>
+ </ul>
+ <p>
+ <a title="polyglot markup">Polyglot markup</a> is scripted according to the rules of XML (does not use <code>document.write</code>, for example)
+ and excludes HTML elements that are impossible to replicate in an XML parser (does not use the <code>noscript</code> element, for example).
+ <a title="polyglot markup">Polyglot markup</a> triggers non-quirks mode in HTML parsers,
+ as non-quirks mode is closest to XML-mode rendering, in regard to both DOM and CSS.
+ <a title="polyglot markup">Polyglot markup</a> results in the same encoding and the same language in both HTML-mode and XML-mode.
+ </p>
+
+ <p>
+ <a title="polyglot markup">Polyglot markup</a>, itself being valid HTML5,
+ supports extensibility as it is defined in
+ <a href="http://www.w3.org/TR/html5/infrastructure.html#extensibility">Section 2.2.3 Extensibility</a> of HTML5,
+ so long as the extension does not violate the rules of <a>polyglot markup</a>. [[!HTML5]]
+ In addition, being well formed XML, <a>polyglot markup</a> can be extended when it is served as <code>application/xhtml+xml</code>.
+ </p>
+ </section>
+ <!--End section: principles-->
</section>
-<section id="writing"><h3>Writing HTML documents</h3>
+<section id="writing"><h2>Writing HTML documents</h2>
<section id="PI-and-xml" class="section">
-<h2>Processing instructions and the XML declaration</h2>
-<p>
- Processing Instructions and the XML Declaration are both forbidden in <a>polyglot markup</a>.
-</p>
-<!--End section: Processing Instructions and the XML Declaration-->
+ <h3>Processing instructions and the XML declaration</h3>
+ <p>
+ Processing Instructions and the XML Declaration are both forbidden in <a>polyglot markup</a>.
+ </p>
[1672 lines skipped]
Received on Thursday, 5 September 2013 04:26:46 UTC