- From: CVS User egraff <cvsmail@w3.org>
- Date: Tue, 07 Jan 2014 22:41:46 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/html-polyglot
In directory roscoe:/tmp/cvs-serv31256
Modified Files:
html-polyglot.html
Log Message:
Language edits to section 2 for increased readability
--- /sources/public/html5/html-polyglot/html-polyglot.html 2014/01/07 21:48:39 1.19
+++ /sources/public/html5/html-polyglot/html-polyglot.html 2014/01/07 22:41:46 1.20
@@ -108,12 +108,14 @@
<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
+ <p> Polyglot markup is a means to an end – <dfn id="dfn-robustness">robustness</dfn>.
+ <!-- We should have a more precise definition of robust -->
+ 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>
+ that other relevant specs have not already 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
@@ -130,24 +132,33 @@
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
+ This requirement is not only because of the documented benefits
+ that in turn have 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.
+ NB, the HTML-specific benefits are described in HTML5 [[!HTML5]].
+ </p>
+ <p> 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>
+ rules doesn’t require the encoding to be explicitly declared.
+ This in turn has the benefit that any HTML-invalid XML
+ encoding declaration can reliably be skipped without causing any side-effects.
+ For example, if someone 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 be 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
+ But even if the document can be expected to be parsed and validated by tools that fully conform to HTML5,
+ <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
+ 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>
Received on Tuesday, 7 January 2014 22:41:49 UTC