Skip to content
Permalink
Browse files

[e] (0) Try to warn implementors about XSLT.

Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=11090

git-svn-id: http://svn.whatwg.org/webapps@6049 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information...
Hixie committed May 3, 2011
1 parent a447bad commit e7303de88d59c250acff3d22d61c79a9bd1e021c
Showing with 212 additions and 42 deletions.
  1. +68 −15 complete.html
  2. +68 −15 index
  3. +76 −12 source

<header class=head id=head><p><a class=logo href=http://www.whatwg.org/ rel=home><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
<hgroup><h1>Web Applications 1.0</h1>
<h2 class="no-num no-toc">Living Standard &mdash; Last Updated 2 May 2011</h2>
<h2 class="no-num no-toc">Living Standard &mdash; Last Updated 3 May 2011</h2>
</hgroup><p>You can take part in this work. <a href=http://www.whatwg.org/mailing-list>Join the working group's discussion list.</a></p>
<p><strong>Web designers!</strong> We have a <a href=http://blog.whatwg.org/faq/>FAQ</a>, a <a href=http://forums.whatwg.org/>forum</a>, and a <a href=http://www.whatwg.org/mailing-list#help>help mailing list</a> for you!</p>
<!--<p class="impl"><strong>Implementors!</strong> We have a <a href="http://www.whatwg.org/mailing-list#implementors">mailing list</a> for you too!</p>-->
<ol>
<li><a href=#scriptingLanguages><span class=secno>4.3.1.1 </span>Scripting languages</a></li>
<li><a href=#restrictions-for-contents-of-script-elements><span class=secno>4.3.1.2 </span>Restrictions for contents of <code>script</code> elements</a></li>
<li><a href=#inline-documentation-for-external-scripts><span class=secno>4.3.1.3 </span>Inline documentation for external scripts</a></ol></li>
<li><a href=#inline-documentation-for-external-scripts><span class=secno>4.3.1.3 </span>Inline documentation for external scripts</a></li>
<li><a href=#scriptTagXSLT><span class=secno>4.3.1.4 </span>Interaction of <code>script</code> elements and XSLT</a></ol></li>
<li><a href=#the-noscript-element><span class=secno>4.3.2 </span>The <code>noscript</code> element</a></ol></li>
<li><a href=#sections><span class=secno>4.4 </span>Sections</a>
<ol>
<li><dfn id=text><code>Text</code></dfn> interface</li>

<li><dfn id=dom-domimplementation-createdocument title=dom-DOMImplementation-createDocument><code>createDocument()</code></dfn> method</li>
<li><dfn id=dom-document-createelement title=dom-Document-createElement><code>createElement()</code></dfn> method</li>
<li><dfn id=dom-document-createelementns title=dom-Document-createElementNS><code>createElementNS()</code></dfn> method</li>
<li><dfn id=dom-document-getelementbyid title=dom-Document-getElementById><code>getElementById()</code></dfn> method</li>
<li><dfn id=dom-node-insertbefore title=dom-Node-insertBefore><code>insertBefore()</code></dfn> method</li>

</dd>


<dt><code title=dom-Document-createElement>Document.createElement()</code></dt>
<dt><code title=dom-Document-createElement><a href=#dom-document-createelement>Document.createElement()</a></code></dt>

<dd>

the argument before creating the requisite element. <span class=impl>Also, the element created must be in the <a href=#html-namespace-0>HTML
namespace</a></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><a href=#dom-element-tagname>tagName</a></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><a href=#dom-node-localname>localName</a></code> attribute.</p>
<p class=note>This doesn't apply to <code title=dom-Document-createElementNS><a href=#dom-document-createelementns>Document.createElementNS()</a></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><a href=#dom-element-tagname>tagName</a></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><a href=#dom-node-localname>localName</a></code> attribute.</p>

</dd>

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>


<p class=note>The definition of <a href=#concept-n-noscript title=concept-n-noscript>scripting is disabled</a> means
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
title="dom-XSLTProcessor-transformToDocument">transformToDocument</code>
feature,--> and scripts that are first inserted by a script into a
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
<code><a href=#document>Document</a></code> that was created using the <code title=dom-DOMImplementation-createDocument><a href=#dom-domimplementation-createdocument>createDocument()</a></code>
API. <a href=#refsXHR>[XHR]</a> <a href=#refsDOMPARSER>[DOMPARSER]</a> <!--<a
href="#refsXSLTP">[XSLTP]</a>--> <a href=#refsDOMCORE>[DOMCORE]</a></p>
</div>


<div class=impl>

<h5 id=scriptTagXSLT><span class=secno>4.3.1.4 </span>Interaction of <code><a href=#script>script</a></code> elements and XSLT</h5>

<p><i>This section is non-normative.</i></p>

<p>This specification does not define how XSLT interacts with the
<code><a href=#script>script</a></code> element (or, indeed, how XSLT processing
triggers the <a href=#stop-parsing>stop parsing</a> steps, how it interacts with
the <a href=#navigate title=navigate>navigation</a> algorithm, or how it
fits in with the <a href=#event-loop>event loop</a>). 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="">&lt;?xml-stylesheet?&gt;</code> processing instruction and
the browser implements a direct-to-DOM transformation,
<code><a href=#script>script</a></code> elements created by the XSLT processor need to
be marked <a href=#parser-inserted>"parser-inserted"</a> and run in document order
(modulo scripts marked <code title=attr-script-defer><a href=#attr-script-defer>defer</a></code>
or <code title=attr-script-async><a href=#attr-script-async>async</a></code>), asynchronously
while the transformation is occurring.</li>

<li><p>The <code title=dom-XSLTProcessor-transformToDocument>XSLTProcessor.transformToDocument()</code>
method adds elements to a <code><a href=#document>Document</a></code> that is not in a
<a href=#browsing-context>browsing context</a>, and, accordingly, any
<code><a href=#script>script</a></code> elements they create need to have their
<a href=#already-started>"already started"</a> flag set in the <a href=#prepare-a-script>prepare a
script</a> algorithm and never get executed (<a href=#concept-bc-noscript title=concept-bc-noscript>scripting is disabled</a>). Such
<code><a href=#script>script</a></code> elements still need to be marked
<a href=#parser-inserted>"parser-inserted"</a>, though, such that their <code title=dom-script-async><a href=#dom-script-async>async</a></code> IDL attribute will return
false in the absence of an <code title=attr-script-async><a href=#attr-script-async>async</a></code> content attribute.</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><a href=#dom-document-createelementns>document.createElementNS()</a></code>.
For instance, it needs to create <code><a href=#script>script</a></code> elements that
aren't <a href=#parser-inserted>"parser-inserted"</a> and that don't have their
<a href=#already-started>"already started"</a> flag set, so that they will execute
when the fragment is inserted into a document.</li>

</ul><p>The main distinction between the first two cases and the last
case is that the first two operate on <code><a href=#document>Document</a></code>s and the
last operates on a fragment.</p>

</div>



<h4 id=the-noscript-element><span class=secno>4.3.2 </span>The <dfn><code>noscript</code></dfn> element</h4>

83 index

<header class=head id=head><p><a class=logo href=http://www.whatwg.org/ rel=home><img alt=WHATWG height=101 src=/images/logo width=101></a></p>
<hgroup><h1 class=allcaps>HTML</h1>
<h2 class="no-num no-toc">Living Standard &mdash; Last Updated 2 May 2011</h2>
<h2 class="no-num no-toc">Living Standard &mdash; Last Updated 3 May 2011</h2>
</hgroup><p>You can take part in this work. <a href=http://www.whatwg.org/mailing-list>Join the working group's discussion list.</a></p>
<p><strong>Web designers!</strong> We have a <a href=http://blog.whatwg.org/faq/>FAQ</a>, a <a href=http://forums.whatwg.org/>forum</a>, and a <a href=http://www.whatwg.org/mailing-list#help>help mailing list</a> for you!</p>
<!--<p class="impl"><strong>Implementors!</strong> We have a <a href="http://www.whatwg.org/mailing-list#implementors">mailing list</a> for you too!</p>-->
<ol>
<li><a href=#scriptingLanguages><span class=secno>4.3.1.1 </span>Scripting languages</a></li>
<li><a href=#restrictions-for-contents-of-script-elements><span class=secno>4.3.1.2 </span>Restrictions for contents of <code>script</code> elements</a></li>
<li><a href=#inline-documentation-for-external-scripts><span class=secno>4.3.1.3 </span>Inline documentation for external scripts</a></ol></li>
<li><a href=#inline-documentation-for-external-scripts><span class=secno>4.3.1.3 </span>Inline documentation for external scripts</a></li>
<li><a href=#scriptTagXSLT><span class=secno>4.3.1.4 </span>Interaction of <code>script</code> elements and XSLT</a></ol></li>
<li><a href=#the-noscript-element><span class=secno>4.3.2 </span>The <code>noscript</code> element</a></ol></li>
<li><a href=#sections><span class=secno>4.4 </span>Sections</a>
<ol>
<li><dfn id=text><code>Text</code></dfn> interface</li>

<li><dfn id=dom-domimplementation-createdocument title=dom-DOMImplementation-createDocument><code>createDocument()</code></dfn> method</li>
<li><dfn id=dom-document-createelement title=dom-Document-createElement><code>createElement()</code></dfn> method</li>
<li><dfn id=dom-document-createelementns title=dom-Document-createElementNS><code>createElementNS()</code></dfn> method</li>
<li><dfn id=dom-document-getelementbyid title=dom-Document-getElementById><code>getElementById()</code></dfn> method</li>
<li><dfn id=dom-node-insertbefore title=dom-Node-insertBefore><code>insertBefore()</code></dfn> method</li>

</dd>


<dt><code title=dom-Document-createElement>Document.createElement()</code></dt>
<dt><code title=dom-Document-createElement><a href=#dom-document-createelement>Document.createElement()</a></code></dt>

<dd>

the argument before creating the requisite element. <span class=impl>Also, the element created must be in the <a href=#html-namespace-0>HTML
namespace</a></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><a href=#dom-element-tagname>tagName</a></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><a href=#dom-node-localname>localName</a></code> attribute.</p>
<p class=note>This doesn't apply to <code title=dom-Document-createElementNS><a href=#dom-document-createelementns>Document.createElementNS()</a></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><a href=#dom-element-tagname>tagName</a></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><a href=#dom-node-localname>localName</a></code> attribute.</p>

</dd>

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>


<p class=note>The definition of <a href=#concept-n-noscript title=concept-n-noscript>scripting is disabled</a> means
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
title="dom-XSLTProcessor-transformToDocument">transformToDocument</code>
feature,--> and scripts that are first inserted by a script into a
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
<code><a href=#document>Document</a></code> that was created using the <code title=dom-DOMImplementation-createDocument><a href=#dom-domimplementation-createdocument>createDocument()</a></code>
API. <a href=#refsXHR>[XHR]</a> <a href=#refsDOMPARSER>[DOMPARSER]</a> <!--<a
href="#refsXSLTP">[XSLTP]</a>--> <a href=#refsDOMCORE>[DOMCORE]</a></p>
</div>


<div class=impl>

<h5 id=scriptTagXSLT><span class=secno>4.3.1.4 </span>Interaction of <code><a href=#script>script</a></code> elements and XSLT</h5>

<p><i>This section is non-normative.</i></p>

<p>This specification does not define how XSLT interacts with the
<code><a href=#script>script</a></code> element (or, indeed, how XSLT processing
triggers the <a href=#stop-parsing>stop parsing</a> steps, how it interacts with
the <a href=#navigate title=navigate>navigation</a> algorithm, or how it
fits in with the <a href=#event-loop>event loop</a>). 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="">&lt;?xml-stylesheet?&gt;</code> processing instruction and
the browser implements a direct-to-DOM transformation,
<code><a href=#script>script</a></code> elements created by the XSLT processor need to
be marked <a href=#parser-inserted>"parser-inserted"</a> and run in document order
(modulo scripts marked <code title=attr-script-defer><a href=#attr-script-defer>defer</a></code>
or <code title=attr-script-async><a href=#attr-script-async>async</a></code>), asynchronously
while the transformation is occurring.</li>

<li><p>The <code title=dom-XSLTProcessor-transformToDocument>XSLTProcessor.transformToDocument()</code>
method adds elements to a <code><a href=#document>Document</a></code> that is not in a
<a href=#browsing-context>browsing context</a>, and, accordingly, any
<code><a href=#script>script</a></code> elements they create need to have their
<a href=#already-started>"already started"</a> flag set in the <a href=#prepare-a-script>prepare a
script</a> algorithm and never get executed (<a href=#concept-bc-noscript title=concept-bc-noscript>scripting is disabled</a>). Such
<code><a href=#script>script</a></code> elements still need to be marked
<a href=#parser-inserted>"parser-inserted"</a>, though, such that their <code title=dom-script-async><a href=#dom-script-async>async</a></code> IDL attribute will return
false in the absence of an <code title=attr-script-async><a href=#attr-script-async>async</a></code> content attribute.</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><a href=#dom-document-createelementns>document.createElementNS()</a></code>.
For instance, it needs to create <code><a href=#script>script</a></code> elements that
aren't <a href=#parser-inserted>"parser-inserted"</a> and that don't have their
<a href=#already-started>"already started"</a> flag set, so that they will execute
when the fragment is inserted into a document.</li>

</ul><p>The main distinction between the first two cases and the last
case is that the first two operate on <code><a href=#document>Document</a></code>s and the
last operates on a fragment.</p>

</div>



<h4 id=the-noscript-element><span class=secno>4.3.2 </span>The <dfn><code>noscript</code></dfn> element</h4>

0 comments on commit e7303de

Please sign in to comment.
You can’t perform that action at this time.