Short URL: http://html5.org/r/6049
| SVN | Bug | Comment | Time (UTC) |
|---|---|---|---|
| 6049 | 11090 | Try to warn implementors about XSLT. | 2011-05-03 01:10 |
Index: source
===================================================================
--- source (revision 6048)
+++ source (revision 6049)
@@ -2345,6 +2345,8 @@
<li><dfn><code>Text</code></dfn> interface</li>
<li><dfn title="dom-DOMImplementation-createDocument"><code>createDocument()</code></dfn> method</li>
+ <li><dfn title="dom-Document-createElement"><code>createElement()</code></dfn> method</li>
+ <li><dfn title="dom-Document-createElementNS"><code>createElementNS()</code></dfn> method</li>
<li><dfn title="dom-Document-getElementById"><code>getElementById()</code></dfn> method</li>
<li><dfn title="dom-Node-insertBefore"><code>insertBefore()</code></dfn> method</li>
@@ -12718,14 +12720,15 @@
namespace</span></span>.</p>
<p class="note">This doesn't apply to <code
- title="">Document.createElementNS()</code>. Thus, it is possible,
- by passing this last method a tag name in the wrong case, to
- create an element that appears to have the same tag name as that
- of an element defined in this specification when its <code
- title="dom-Element-tagName">tagName</code> attribute is examined, but that
- doesn't support the corresponding interfaces. The "real" element
- name (unaffected by case conversions) can be obtained from the
- <code title="dom-Node-localName">localName</code> attribute.</p>
+ title="dom-Document-createElementNS">Document.createElementNS()</code>.
+ Thus, it is possible, by passing this last method a tag name in
+ the wrong case, to create an element that appears to have the same
+ tag name as that of an element defined in this specification when
+ its <code title="dom-Element-tagName">tagName</code> attribute is
+ examined, but that doesn't support the corresponding interfaces.
+ The "real" element name (unaffected by case conversions) can be
+ obtained from the <code
+ title="dom-Node-localName">localName</code> attribute.</p>
</dd>
@@ -12917,6 +12920,10 @@
unaffected.) <a href="#refsXSLT10">[XSLT10]</a></p> <!-- note:
version matters for this ref -->
+ <p class="note">There are also additional comments regarding the
+ interaction of XSLT and HTML <a href="#scriptTagXSLT">in the
+ <code>script</code> element section</a>.</p>
+
</div>
@@ -16536,11 +16543,10 @@
that, amongst others, the following scripts will not execute:
scripts in <code>XMLHttpRequest</code>'s <code
title="dom-XMLHttpRequest-responseXML">responseXML</code>
- documents, scripts in <code>DOMParser</code>-created
- documents, <!--scripts in documents created by
- <code>XSLTProcessor</code>'s <code
+ documents, scripts in <code>DOMParser</code>-created documents,
+ scripts in documents created by <code>XSLTProcessor</code>'s <code
title="dom-XSLTProcessor-transformToDocument">transformToDocument</code>
- feature,--> and scripts that are first inserted by a script into a
+ feature, and scripts that are first inserted by a script into a
<code>Document</code> that was created using the <code
title="dom-DOMImplementation-createDocument">createDocument()</code>
API. <a href="#refsXHR">[XHR]</a> <a
@@ -17332,7 +17338,65 @@
</div>
+ <div class="impl">
+ <h5 id="scriptTagXSLT">Interaction of <code>script</code> elements and XSLT</h5>
+
+ <!--END dev-html--><p><i>This section is non-normative.</i></p><!--START dev-html-->
+
+ <p>This specification does not define how XSLT interacts with the
+ <code>script</code> element (or, indeed, how XSLT processing
+ triggers the <span>stop parsing</span> steps, how it interacts with
+ the <span title="navigate">navigation</span> algorithm, or how it
+ fits in with the <span>event loop</span>). However, in the absence
+ of another specification actually defining this, here are some
+ guidelines for implementors, based on existing implementations:</p>
+
+ <ul>
+
+ <li><p>When an XSLT transformation program is triggered by an <code
+ title=""><?xml-stylesheet?></code> processing instruction and
+ the browser implements a direct-to-DOM transformation,
+ <code>script</code> elements created by the XSLT processor need to
+ be marked <span>"parser-inserted"</span> and run in document order
+ (modulo scripts marked <code title="attr-script-defer">defer</code>
+ or <code title="attr-script-async">async</code>), asynchronously
+ while the transformation is occurring.</p></li>
+
+ <li><p>The <code
+ title="dom-XSLTProcessor-transformToDocument">XSLTProcessor.transformToDocument()</code>
+ method adds elements to a <code>Document</code> that is not in a
+ <span>browsing context</span>, and, accordingly, any
+ <code>script</code> elements they create need to have their
+ <span>"already started"</span> flag set in the <span>prepare a
+ script</span> algorithm and never get executed (<span
+ title="concept-bc-noscript">scripting is disabled</span>). Such
+ <code>script</code> elements still need to be marked
+ <span>"parser-inserted"</span>, though, such that their <code
+ title="dom-script-async">async</code> IDL attribute will return
+ false in the absence of an <code
+ title="attr-script-async">async</code> content attribute.</p></li>
+
+ <li><p>The <code
+ title="dom-XSLTProcessor-transformToFragment">XSLTProcessor.transformToFragment()</code>
+ method needs to create a fragment that is equivalent to one built
+ manually by creating the elements using <code
+ title="dom-document-createElementNS">document.createElementNS()</code>.
+ For instance, it needs to create <code>script</code> elements that
+ aren't <span>"parser-inserted"</span> and that don't have their
+ <span>"already started"</span> flag set, so that they will execute
+ when the fragment is inserted into a document.</p></li>
+
+ </ul>
+
+ <p>The main distinction between the first two cases and the last
+ case is that the first two operate on <code>Document</code>s and the
+ last operates on a fragment.</p>
+
+ </div>
+
+
+
<h4>The <dfn><code>noscript</code></dfn> element</h4>
<dl class="element">