- From: CVS User egraff <cvsmail@w3.org>
- Date: Thu, 09 Jan 2014 01:16:49 +0000
- To: public-html-commits@w3.org
Update of /sources/public/html5/html-polyglot
In directory roscoe:/tmp/cvs-serv12207
Modified Files:
html-polyglot.html
Log Message:
Edited through example 13
--- /sources/public/html5/html-polyglot/html-polyglot.html 2014/01/08 00:44:58 1.21
+++ /sources/public/html5/html-polyglot/html-polyglot.html 2014/01/09 01:16:49 1.22
@@ -754,7 +754,7 @@
<p>Syntactically, the polyglot subset is found by</p>
- <ul><li><em>either</em> <strong>limiting the content to <dfn>safe content</dfn></strong>, that
+ <ul><li><em>either</em> <strong>limiting the content to <dfn>safe text content</dfn></strong>, that
is, text that gets interpreted the same way in HTML and in XML.</li>
<li><em>or</em> trying to <strong>even out the constraints differences</strong> by
wrapping the contents in a <code>CDATA</code> section. The <code>CDATA</code> code is then seen as text
@@ -768,28 +768,32 @@
guarantee that the content is <a title="safe content">safe</a>.</p>
<section id="safe-text-content">
- <h5>The safe text content option</h5>
- <p>The <dfn>safe text content</dfn> option comes in two variants:</p>
+ <h5>Options for delivering safe text content</h5>
+ <p><a title="polyglot markup">Polyglot markup</a> can deliver <a>safe text content</a> both externally and internally.
+ </p>
<ul>
- <li>The <strong>external <a>safe text content</a></strong> variant. This implies to include the scripts or stylesheet by linking to an
- external file rather than including all the code
- in-line. External files are parsed as the respective script or stylesheet, and are thus not limited
- by the safe text content restrictions.
+ <li><strong>External <a>safe text content</a>.</strong>
+ <a title="polyglot markup">Polyglot markup</a> can include scripts or stylesheets
+ by linking to external files rather than including the code in-line.
+ External files are parsed as the respective script or stylesheet and are thus not limited
+ by the same restrictions as safe text content.
<figure>
- <figcaption>Using external <a title="safe content">safe content</a>.</figcaption>
<pre class="example highlight"
><!-- Ways to link to external scripts or stylesheets --><br/><script src="external.js" ></script><br
/><link href="external.css" rel="stylesheet"/><br
/><style>@import "external.css";</style></pre>
</figure>
</li>
- <li>The <strong>inline <a>safe text content</a></strong> variant. This option implies abstaining from using characters and constructs
- which HTML and XML interpret differently, namely the characters <code><</code> and <code>&</code>
- as well as the <code>CDATA</code> end mark string – <code>]]></code>. <a title="polyglot markup">Polyglot markup</a>
- is agnostic as to whether one uses a character entity or a numeric character reference, as long as it is valid.
- For <a>polyglot markup</a>, there is no difference between <code>&amp;</code> and <code>&#x3C;</code>.
+ <li><strong>Inline <a>safe text content</a>.</strong>
+ <a title="polyglot markup">Polyglot markup</a> does not use characters or constructs
+ that are interpreted differently in HTML and XML.
+ This means not using the characters <code><</code> and <code>&</code>
+ as well as the <code>CDATA</code> end mark string – <code>]]></code>.
+ <a title="polyglot markup">Polyglot markup</a>
+ is agnostic as to whether one uses character entities or a numeric character references,
+ so long as they are valid.
+ That is, for <a>polyglot markup</a>, there is no difference between <code>&amp;</code> and <code>&#x3C;</code>.
<figure>
- <figcaption>Using inline <a title="safe content">safe text content</a></figcaption>
<pre class="example highlight"><!-- Unsafe content: < and & are not escaped<br
/> This code is not XML well-formed. --><br/><style>q::before{content:"<";}</style><br/><script>var a = "&";</script>
@@ -805,9 +809,8 @@
</li>
</ul>
<figure>
- <figcaption>An example of inline safe text content in <code>script</code></figcaption>
<pre class="example highlight"
- ><!-- The following the example is <a>polyglot markup</a> because there are no ambiguous strings within the <code>script</code> element. --><br
+ ><!-- The following example of inline script is <a>polyglot markup</a> because there are no ambiguous strings within the <code>script</code> element. --><br
/><script>document.body.appendChild(document.createElement("div"));</script></pre>
</figure>
@@ -817,32 +820,35 @@
</p>
</section>
<section id="safe-CDATA-content">
- <h5>The safe CDATA content option</h5>
- <p>The safe CDATA option wraps the raw text content in <code>CDATA</code> section <strong>but(!)</strong> instead
- of permitting <em>any</em> content (except the very CDATA end mark string – <code>]]></code>), only the
+ <h5>Safe CDATA content</h5>
+ <p><a title="polyglot markup">Polyglot markup</a> accepts raw text content wrapped in a <code>CDATA</code> section;
+ <strong>however</strong> instead of permitting <em>any</em> content (except the very CDATA end mark string – <code>]]></code>), only the
subset that corresponds to the particular raw text element’s HTML constraints is permitted. See the “HTML interpretation”
column in the <a href="#ambiguous-table">parsing differences table above</a> – all the cells with the text ”uninterpreted”
are also uninterpreted as CDATA and thus constitutes the safe subset of CDATA.</p>
- <p>But while CDATA evens out the constraints, it introduces a new problem: When consumed as HTML, the start and end mark of the
+ <p>Wrapping raw text in a CDATA section introduces a new problem: when consumed as HTML, the start and end mark of the
CDATA section is seen by the script or stylesheet interpreter and can thus cause syntax errors or even halt the script
- and stylesheet execution. The way to deal with it is to comment out the CDATA start and end mark
- using the comment methods of the script or stylesheet language. Additionally, if e.g. <code>script</code> is used as a
- coding block container, it may be necessary to even comment out the scripting/styling comments by hiding them
- inside a XML comment.</p>
+ and stylesheet execution.
+ A solution is to comment out the CDATA start and end marks by using the comment methods of the script or stylesheet language.
+ Additionally, such as when <code>script</code> is used as a coding block container,
+ it may be necessary to even comment out the scripting/styling comments by hiding them inside an XML comment.</p>
<section id="CDATA-rules-raw-text">
- <h6>Safe CDATA usage rules</h6>
- <p>These rules assumes that CDATA is of limited use for CSS.</p>
+ <h6>Safe rules for CDATA use</h6>
+ <p>These rules assume that CDATA is of limited use for CSS.</p>
<p>General rules:</p>
<ul>
- <li> The CDATA section is subject to HTML’s restrictions on <code><script></code>/<code><style></code></li>
- <li> Only one CDATA section permitted per raw text element</li>
+ <li> The CDATA section is subject to HTML’s restrictions on <code><script></code> and <code><style></code>.</li>
+ <li> There can be only one CDATA section per raw text element.</li>
<li> Before the CDATA section there can only be one node - preferrably only one line of code, which may
- consist of whitespace, or an XML comment or a construct of the scripting/styling language (usually
+ consist of whitespace, or an XML comment, or a construct of the scripting/styling language (usually
a comment of the scripting/styling language).</li>
- <li> After the CDATA section: Same rules as for before the CDATA section.</li>
- </ul><p>The <code>]]></code> string:</p>
+ <li> After the CDATA section there can only be one node - preferrably only one line of code, which may
+ consist of whitespace, or an XML comment, or a construct of the scripting/styling language (usually
+ a comment of the scripting/styling language).</li>
+ </ul>
+ <p>The <code>]]></code> string:</p>
<ul>
<li> is always commented out if <code><![CDATA[</code> is commented out.</li>
<li> is never commented out if <code><![CDATA[</code> is not commented out.</li>
@@ -853,9 +859,9 @@
<li><code><![CDATA[</code> - without commenting it out.
<pre class="example highlight"><script type="not-CSS-and-not-JS"><![CDATA[foo]]></script></pre>
<ul>
- <li> Important: Not conforming as 'text/css' or 'text/javascript' content when parsed as HTML.</li>
- <li> Advantage: Can be useful for type="text/html" and templating in general. Svelte - saves bytes. Puristic.</li>
- <li> Disadvantage: scripting languages might need to be tuned to support it.</li></ul>
+ <li> Important: This is not conforming as 'text/css' or 'text/javascript' content when parsed as HTML.</li>
+ <li> Advantage: This can be useful for type="text/html" and templating in general, as it saves bytes.</li>
+ <li> Disadvantage: Scripting languages might need to be tuned to support it.</li></ul>
</li>
<li><code>//<![CDATA[</code> - pure scripting language level commenting out. Comment starts in the node before the CDATA section:
<pre class="example highlight"><script>//<![CDATA[ FOO; //]]></script></pre>
Received on Thursday, 9 January 2014 01:16:51 UTC