[html5] r1450 - /
whatwg at whatwg.org
whatwg at whatwg.org
Thu Apr 17 13:13:11 PDT 2008
Author: ianh
Date: 2008-04-17 13:13:10 -0700 (Thu, 17 Apr 2008)
New Revision: 1450
Modified:
index
source
Log:
[] (0) Define what happens when you have an unexpandable entity reference; also various minor editorial issues
Modified: index
===================================================================
--- index 2008-04-15 19:43:26 UTC (rev 1449)
+++ index 2008-04-17 20:13:10 UTC (rev 1450)
@@ -24,7 +24,7 @@
<h1 id=html-5>HTML 5</h1>
- <h2 class="no-num no-toc" id=working>Working Draft — 15 April 2008</h2>
+ <h2 class="no-num no-toc" id=working>Working Draft — 17 April 2008</h2>
<p>You can take part in this work. <a
href="http://www.whatwg.org/mailing-list">Join the working group's
@@ -1975,9 +1975,7 @@
requirements and implementation conformance requirements. User agents are
not free to handle non-conformant documents as they please; the processing
model described in this specification applies to implementations
- regardless of the conformity of the input documents.</p>
- <!--XXX quite possible that
- this is stated twice. check for whether this is a dupe. -->
+ regardless of the conformity of the input documents.
<p>User agents fall into several (overlapping) categories with different
conformance requirements.
@@ -2212,8 +2210,9 @@
were fully expanded when implementing this specification. For example, if
a requirement talks about an element's child text nodes, then any text
nodes that are children of an entity reference that is a child of that
- element would be used as well.</p>
- <!-- XXX unexpandable entities? -->
+ element would be used as well. Entity references to unknown entities must
+ be treated as if they contained just an empty text node for the purposes
+ of the algorithms defined in this specification.
<h4 id=common><span class=secno>1.3.1 </span>Common conformance
requirements for APIs exposed to JavaScript</h4>
@@ -2317,8 +2316,9 @@
handles those and other things, like alt=""?</p>
<!-- This section is currently here exclusively so that we crossref
to textContent. XXX also add event-click, event-change,
- event-DOMActivate, etc, here, and just have the section be a general
- "defined in other specifications" section -->
+ event-DOMActivate, etc, here, once DOM3 Events is ready for that,
+ and just have the section be a general "defined in other
+ specifications" section -->
<p>The interface <dfn id=domtimestamp><code>DOMTimeStamp</code></dfn> is
defined in DOM3 Core. <a href="#refsDOM3CORE">[DOM3CORE]</a>
@@ -2457,16 +2457,13 @@
<p>A DOM attribute is said to be <em>getting</em> when its value is being
retrieved (e.g. by author script), and is said to be <em>setting</em> when
- a new value is assigned to it.</p>
- <!-- XXX
- define this in terms of [[Get]] and [[Put]] ? -->
+ a new value is assigned to it.
<p>If a DOM object is said to be <dfn id=live>live</dfn>, then that means
that any attributes returning that object must always return the same
object (not a new object each time), and the attributes and methods on
that object must operate on the actual underlying data, not a snapshot of
- the data.</p>
- <!-- XXX should define "same instance of" to mean JS===. -->
+ the data.
<p>The terms <em>fire</em> and <em>dispatch</em> are used interchangeably
in the context of events, as in the DOM Events specifications. <a
@@ -45115,21 +45112,16 @@
<tr> <td> <code title="">glyphref</code> <td> <code title="">glyphRef</code>
<tr> <td> <code title="">lineargradient</code> <td> <code title="">linearGradient</code>
<tr> <td> <code title="">radialgradient</code> <td> <code title="">radialGradient</code>
- <!--<tr> <td> <code title="">solidcolor</code> <td> <code title="">solidColor</code> (SVG 1.2)-->
-
- <table>
- <tbody>
- <tr>
- <td> <code title="">textpath</code>
-
- <td> <code title="">textPath</code>
+ <!- -<tr> <td> <code title="">solidcolor</code> <td> <code title="">solidColor</code> (SVG 1.2)- ->
+ <tr> <td> <code title="">textpath</code> <td> <code title="">textPath</code>
</table>
- <p>If the <a href="#current4">current node</a> is an element in the <a
- href="#svg-namespace">SVG namespace</a>, <span>adjust SVG
- attributes</span> for the token. (This fixes the case of SVG attributes
- that are not all lowercase.)</p>
- -->
+ <p>If the <span>current node</span> is an element in the <span>SVG
+ namespace</span>, <span>adjust SVG attributes</span> for the
+ token. (This fixes the case of SVG attributes that are not all
+ lowercase.)</p>
+-->
+
<p><a href="#adjust">Adjust foreign attributes</a> for the token. (This
fixes the use of namespaced attributes, in particular XLink in SVG.)</p>
Modified: source
===================================================================
--- source 2008-04-15 19:43:26 UTC (rev 1449)
+++ source 2008-04-17 20:13:10 UTC (rev 1450)
@@ -236,8 +236,7 @@
requirements. User agents are not free to handle non-conformant
documents as they please; the processing model described in this
specification applies to implementations regardless of the
- conformity of the input documents.</p> <!--XXX quite possible that
- this is stated twice. check for whether this is a dupe. -->
+ conformity of the input documents.</p>
<p>User agents fall into several (overlapping) categories with
different conformance requirements.</p>
@@ -499,7 +498,9 @@
specification. For example, if a requirement talks about an
element's child text nodes, then any text nodes that are children of
an entity reference that is a child of that element would be used as
- well.</p> <!-- XXX unexpandable entities? -->
+ well. Entity references to unknown entities must be treated as if
+ they contained just an empty text node for the purposes of the
+ algorithms defined in this specification.</p>
<h4>Common conformance requirements for APIs exposed to
@@ -625,8 +626,9 @@
<!-- This section is currently here exclusively so that we crossref
to textContent. XXX also add event-click, event-change,
- event-DOMActivate, etc, here, and just have the section be a general
- "defined in other specifications" section -->
+ event-DOMActivate, etc, here, once DOM3 Events is ready for that,
+ and just have the section be a general "defined in other
+ specifications" section -->
<p>The interface <dfn><code>DOMTimeStamp</code></dfn> is defined in
DOM3 Core. <a href="#refsDOM3CORE">[DOM3CORE]</a></p>
@@ -765,8 +767,7 @@
<p>A DOM attribute is said to be <em>getting</em> when its value is
being retrieved (e.g. by author script), and is said to be
- <em>setting</em> when a new value is assigned to it.</p> <!-- XXX
- define this in terms of [[Get]] and [[Put]] ? -->
+ <em>setting</em> when a new value is assigned to it.</p>
<p>If a DOM object is said to be <dfn>live</dfn>, then that means
that any attributes returning that object must always return the
@@ -774,8 +775,6 @@
methods on that object must operate on the actual underlying data,
not a snapshot of the data.</p>
- <!-- XXX should define "same instance of" to mean JS===. -->
-
<p>The terms <em>fire</em> and <em>dispatch</em> are used
interchangeably in the context of events, as in the DOM Events
specifications. <a href="#refsDOM3EVENTS">[DOM3EVENTS]</a></p>
@@ -42287,7 +42286,7 @@
<tr> <td> <code title="">glyphref</code> <td> <code title="">glyphRef</code>
<tr> <td> <code title="">lineargradient</code> <td> <code title="">linearGradient</code>
<tr> <td> <code title="">radialgradient</code> <td> <code title="">radialGradient</code>
- <!--<tr> <td> <code title="">solidcolor</code> <td> <code title="">solidColor</code> (SVG 1.2)-->
+ <!- -<tr> <td> <code title="">solidcolor</code> <td> <code title="">solidColor</code> (SVG 1.2)- ->
<tr> <td> <code title="">textpath</code> <td> <code title="">textPath</code>
</table>
More information about the Commit-Watchers
mailing list