Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
[e] (0) grammar
Fixing http://www.w3.org/Bugs/Public/show_bug.cgi?id=12200

git-svn-id: http://svn.whatwg.org/webapps@6080 340c8d12-0b0e-0410-8428-c7bf67bfef74
  • Loading branch information
Hixie committed May 5, 2011
1 parent 3b38293 commit 6afb08d
Show file tree
Hide file tree
Showing 3 changed files with 84 additions and 84 deletions.
56 changes: 28 additions & 28 deletions complete.html
Expand Up @@ -7178,18 +7178,19 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
attribute must set the content attribute to the specified literal
value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code> whose
content attribute is an <a href=#enumerated-attribute>enumerated attribute</a>, and the
IDL attribute is <dfn id=limited-to-only-known-values>limited to only known values</dfn>, then, on
getting, the IDL attribute must return the conforming value
associated with the state the attribute is in (in its canonical
case), or the empty string if the attribute is in a state that has
no associated keyword value; and on setting, the content attribute
must be set to the specified new value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code> but
doesn't fall into any of the above categories, then the getting and
setting must be done in a transparent, case-preserving manner.</p>
<p>If a reflecting IDL attribute is a <code>DOMString</code>
attribute whose content attribute is an <a href=#enumerated-attribute>enumerated
attribute</a>, and the IDL attribute is <dfn id=limited-to-only-known-values>limited to only
known values</dfn>, then, on getting, the IDL attribute must return
the conforming value associated with the state the attribute is in
(in its canonical case), or the empty string if the attribute is in
a state that has no associated keyword value; and on setting, the
content attribute must be set to the specified new value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code>
attribute but doesn't fall into any of the above categories, then
the getting and setting must be done in a transparent,
case-preserving manner.</p>

<p>If a reflecting IDL attribute is a <code title="">boolean</code>
attribute, then on getting the IDL attribute must return true if the
Expand All @@ -7199,7 +7200,7 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
set to true. (This corresponds to the rules for <a href=#boolean-attribute title="boolean
attribute">boolean content attributes</a>.)</p>

<p>If a reflecting IDL attribute is a signed integer type
<p>If a reflecting IDL attribute has a signed integer type
(<code>long</code>) then, on getting, the content attribute must be
parsed according to the <a href=#rules-for-parsing-integers title="rules for parsing
integers">rules for parsing signed integers</a>, and if that is
Expand All @@ -7212,7 +7213,7 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
a <a href=#valid-integer>valid integer</a> and then that string must be used as
the new content attribute value.</p>

<p>If a reflecting IDL attribute is a signed integer type
<p>If a reflecting IDL attribute has a signed integer type
(<code>long</code>) that is <dfn id=limited-to-only-non-negative-numbers>limited to only non-negative
numbers</dfn> then, on getting, the content attribute must be parsed
according to the <a href=#rules-for-parsing-non-negative-integers>rules for parsing non-negative
Expand All @@ -7227,7 +7228,7 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
number as a <a href=#valid-non-negative-integer>valid non-negative integer</a> and then that
string must be used as the new content attribute value.</p>

<p>If a reflecting IDL attribute is an <em>unsigned</em> integer
<p>If a reflecting IDL attribute has an <em>unsigned</em> integer
type (<code>unsigned long</code>) then, on getting, the content
attribute must be parsed according to the <a href=#rules-for-parsing-non-negative-integers>rules for parsing
non-negative integers</a>, and if that is successful, and the
Expand All @@ -7244,7 +7245,7 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
range is clamped to 2147483647 rather the normal unsigned long
maximum value of 4294967295 -->

<p>If a reflecting IDL attribute is an unsigned integer type
<p>If a reflecting IDL attribute has an unsigned integer type
(<code>unsigned long</code>) that is <dfn id=limited-to-only-non-negative-numbers-greater-than-zero>limited to only
non-negative numbers greater than zero</dfn>, then the behavior is
similar to the previous case, but zero is not allowed. On getting,
Expand All @@ -7261,7 +7262,7 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
and then that string must be used as the new content attribute
value.</p> <!-- see previous paragraph for note about the range -->

<p>If a reflecting IDL attribute is a floating point number type
<p>If a reflecting IDL attribute has a floating point number type
(<code>double</code>), then, on getting, the content attribute must
be parsed according to the <a href=#rules-for-parsing-floating-point-number-values>rules for parsing floating point
number values</a>, and if that is successful, the resulting value
Expand All @@ -7276,20 +7277,19 @@ <h4 id=reflecting-content-attributes-in-idl-attributes><span class=secno>2.8.1 <
throw an exception on setting, as <a href=#float-nan>defined
earlier</a>.</p>

<p>If a reflecting IDL attribute is of the type
<p>If a reflecting IDL attribute has the type
<code><a href=#domtokenlist>DOMTokenList</a></code> or <code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code>, then
on getting it must return a <code><a href=#domtokenlist>DOMTokenList</a></code> or
<code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code> object (as appropriate) whose
underlying string is the element's corresponding content
attribute. When the object mutates its underlying string, the
content attribute must itself be immediately mutated. When the
attribute is absent, then the string represented by the object is
the empty string; when the object mutates this empty string, the
user agent must add the corresponding content attribute, with its
value set to the value it would have been set to after mutating the
empty string. The same <code><a href=#domtokenlist>DOMTokenList</a></code> or
<code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code> object must be returned every time
for each attribute.</p>
underlying string is the element's corresponding content attribute.
When the object mutates its underlying string, the content attribute
must itself be immediately mutated. When the attribute is absent,
then the string represented by the object is the empty string; when
the object mutates this empty string, the user agent must add the
corresponding content attribute, with its value set to the value it
would have been set to after mutating the empty string. The same
<code><a href=#domtokenlist>DOMTokenList</a></code> or <code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code>
object must be returned every time for each attribute.</p>

<div class=example>

Expand Down
56 changes: 28 additions & 28 deletions index
Expand Up @@ -7203,18 +7203,19 @@ explained in the previous section, which talks about RFC 2119. -->
attribute must set the content attribute to the specified literal
value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code> whose
content attribute is an <a href=#enumerated-attribute>enumerated attribute</a>, and the
IDL attribute is <dfn id=limited-to-only-known-values>limited to only known values</dfn>, then, on
getting, the IDL attribute must return the conforming value
associated with the state the attribute is in (in its canonical
case), or the empty string if the attribute is in a state that has
no associated keyword value; and on setting, the content attribute
must be set to the specified new value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code> but
doesn't fall into any of the above categories, then the getting and
setting must be done in a transparent, case-preserving manner.</p>
<p>If a reflecting IDL attribute is a <code>DOMString</code>
attribute whose content attribute is an <a href=#enumerated-attribute>enumerated
attribute</a>, and the IDL attribute is <dfn id=limited-to-only-known-values>limited to only
known values</dfn>, then, on getting, the IDL attribute must return
the conforming value associated with the state the attribute is in
(in its canonical case), or the empty string if the attribute is in
a state that has no associated keyword value; and on setting, the
content attribute must be set to the specified new value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code>
attribute but doesn't fall into any of the above categories, then
the getting and setting must be done in a transparent,
case-preserving manner.</p>

<p>If a reflecting IDL attribute is a <code title="">boolean</code>
attribute, then on getting the IDL attribute must return true if the
Expand All @@ -7224,7 +7225,7 @@ explained in the previous section, which talks about RFC 2119. -->
set to true. (This corresponds to the rules for <a href=#boolean-attribute title="boolean
attribute">boolean content attributes</a>.)</p>

<p>If a reflecting IDL attribute is a signed integer type
<p>If a reflecting IDL attribute has a signed integer type
(<code>long</code>) then, on getting, the content attribute must be
parsed according to the <a href=#rules-for-parsing-integers title="rules for parsing
integers">rules for parsing signed integers</a>, and if that is
Expand All @@ -7237,7 +7238,7 @@ explained in the previous section, which talks about RFC 2119. -->
a <a href=#valid-integer>valid integer</a> and then that string must be used as
the new content attribute value.</p>

<p>If a reflecting IDL attribute is a signed integer type
<p>If a reflecting IDL attribute has a signed integer type
(<code>long</code>) that is <dfn id=limited-to-only-non-negative-numbers>limited to only non-negative
numbers</dfn> then, on getting, the content attribute must be parsed
according to the <a href=#rules-for-parsing-non-negative-integers>rules for parsing non-negative
Expand All @@ -7252,7 +7253,7 @@ explained in the previous section, which talks about RFC 2119. -->
number as a <a href=#valid-non-negative-integer>valid non-negative integer</a> and then that
string must be used as the new content attribute value.</p>

<p>If a reflecting IDL attribute is an <em>unsigned</em> integer
<p>If a reflecting IDL attribute has an <em>unsigned</em> integer
type (<code>unsigned long</code>) then, on getting, the content
attribute must be parsed according to the <a href=#rules-for-parsing-non-negative-integers>rules for parsing
non-negative integers</a>, and if that is successful, and the
Expand All @@ -7269,7 +7270,7 @@ explained in the previous section, which talks about RFC 2119. -->
range is clamped to 2147483647 rather the normal unsigned long
maximum value of 4294967295 -->

<p>If a reflecting IDL attribute is an unsigned integer type
<p>If a reflecting IDL attribute has an unsigned integer type
(<code>unsigned long</code>) that is <dfn id=limited-to-only-non-negative-numbers-greater-than-zero>limited to only
non-negative numbers greater than zero</dfn>, then the behavior is
similar to the previous case, but zero is not allowed. On getting,
Expand All @@ -7286,7 +7287,7 @@ explained in the previous section, which talks about RFC 2119. -->
and then that string must be used as the new content attribute
value.</p> <!-- see previous paragraph for note about the range -->

<p>If a reflecting IDL attribute is a floating point number type
<p>If a reflecting IDL attribute has a floating point number type
(<code>double</code>), then, on getting, the content attribute must
be parsed according to the <a href=#rules-for-parsing-floating-point-number-values>rules for parsing floating point
number values</a>, and if that is successful, the resulting value
Expand All @@ -7301,20 +7302,19 @@ explained in the previous section, which talks about RFC 2119. -->
throw an exception on setting, as <a href=#float-nan>defined
earlier</a>.</p>

<p>If a reflecting IDL attribute is of the type
<p>If a reflecting IDL attribute has the type
<code><a href=#domtokenlist>DOMTokenList</a></code> or <code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code>, then
on getting it must return a <code><a href=#domtokenlist>DOMTokenList</a></code> or
<code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code> object (as appropriate) whose
underlying string is the element's corresponding content
attribute. When the object mutates its underlying string, the
content attribute must itself be immediately mutated. When the
attribute is absent, then the string represented by the object is
the empty string; when the object mutates this empty string, the
user agent must add the corresponding content attribute, with its
value set to the value it would have been set to after mutating the
empty string. The same <code><a href=#domtokenlist>DOMTokenList</a></code> or
<code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code> object must be returned every time
for each attribute.</p>
underlying string is the element's corresponding content attribute.
When the object mutates its underlying string, the content attribute
must itself be immediately mutated. When the attribute is absent,
then the string represented by the object is the empty string; when
the object mutates this empty string, the user agent must add the
corresponding content attribute, with its value set to the value it
would have been set to after mutating the empty string. The same
<code><a href=#domtokenlist>DOMTokenList</a></code> or <code><a href=#domsettabletokenlist>DOMSettableTokenList</a></code>
object must be returned every time for each attribute.</p>

<div class=example>

Expand Down
56 changes: 28 additions & 28 deletions source
Expand Up @@ -6991,18 +6991,19 @@ is conforming depends on which specs apply, and leaves it at that. -->
attribute must set the content attribute to the specified literal
value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code> whose
content attribute is an <span>enumerated attribute</span>, and the
IDL attribute is <dfn>limited to only known values</dfn>, then, on
getting, the IDL attribute must return the conforming value
associated with the state the attribute is in (in its canonical
case), or the empty string if the attribute is in a state that has
no associated keyword value; and on setting, the content attribute
must be set to the specified new value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code> but
doesn't fall into any of the above categories, then the getting and
setting must be done in a transparent, case-preserving manner.</p>
<p>If a reflecting IDL attribute is a <code>DOMString</code>
attribute whose content attribute is an <span>enumerated
attribute</span>, and the IDL attribute is <dfn>limited to only
known values</dfn>, then, on getting, the IDL attribute must return
the conforming value associated with the state the attribute is in
(in its canonical case), or the empty string if the attribute is in
a state that has no associated keyword value; and on setting, the
content attribute must be set to the specified new value.</p>

<p>If a reflecting IDL attribute is a <code>DOMString</code>
attribute but doesn't fall into any of the above categories, then
the getting and setting must be done in a transparent,
case-preserving manner.</p>

<p>If a reflecting IDL attribute is a <code title="">boolean</code>
attribute, then on getting the IDL attribute must return true if the
Expand All @@ -7012,7 +7013,7 @@ is conforming depends on which specs apply, and leaves it at that. -->
set to true. (This corresponds to the rules for <span title="boolean
attribute">boolean content attributes</span>.)</p>

<p>If a reflecting IDL attribute is a signed integer type
<p>If a reflecting IDL attribute has a signed integer type
(<code>long</code>) then, on getting, the content attribute must be
parsed according to the <span title="rules for parsing
integers">rules for parsing signed integers</span>, and if that is
Expand All @@ -7025,7 +7026,7 @@ is conforming depends on which specs apply, and leaves it at that. -->
a <span>valid integer</span> and then that string must be used as
the new content attribute value.</p>

<p>If a reflecting IDL attribute is a signed integer type
<p>If a reflecting IDL attribute has a signed integer type
(<code>long</code>) that is <dfn>limited to only non-negative
numbers</dfn> then, on getting, the content attribute must be parsed
according to the <span>rules for parsing non-negative
Expand All @@ -7040,7 +7041,7 @@ is conforming depends on which specs apply, and leaves it at that. -->
number as a <span>valid non-negative integer</span> and then that
string must be used as the new content attribute value.</p>

<p>If a reflecting IDL attribute is an <em>unsigned</em> integer
<p>If a reflecting IDL attribute has an <em>unsigned</em> integer
type (<code>unsigned long</code>) then, on getting, the content
attribute must be parsed according to the <span>rules for parsing
non-negative integers</span>, and if that is successful, and the
Expand All @@ -7057,7 +7058,7 @@ is conforming depends on which specs apply, and leaves it at that. -->
range is clamped to 2147483647 rather the normal unsigned long
maximum value of 4294967295 -->

<p>If a reflecting IDL attribute is an unsigned integer type
<p>If a reflecting IDL attribute has an unsigned integer type
(<code>unsigned long</code>) that is <dfn>limited to only
non-negative numbers greater than zero</dfn>, then the behavior is
similar to the previous case, but zero is not allowed. On getting,
Expand All @@ -7074,7 +7075,7 @@ is conforming depends on which specs apply, and leaves it at that. -->
and then that string must be used as the new content attribute
value.</p> <!-- see previous paragraph for note about the range -->

<p>If a reflecting IDL attribute is a floating point number type
<p>If a reflecting IDL attribute has a floating point number type
(<code>double</code>), then, on getting, the content attribute must
be parsed according to the <span>rules for parsing floating point
number values</span>, and if that is successful, the resulting value
Expand All @@ -7089,20 +7090,19 @@ is conforming depends on which specs apply, and leaves it at that. -->
throw an exception on setting, as <a href="#float-nan">defined
earlier</a>.</p>

<p>If a reflecting IDL attribute is of the type
<p>If a reflecting IDL attribute has the type
<code>DOMTokenList</code> or <code>DOMSettableTokenList</code>, then
on getting it must return a <code>DOMTokenList</code> or
<code>DOMSettableTokenList</code> object (as appropriate) whose
underlying string is the element's corresponding content
attribute. When the object mutates its underlying string, the
content attribute must itself be immediately mutated. When the
attribute is absent, then the string represented by the object is
the empty string; when the object mutates this empty string, the
user agent must add the corresponding content attribute, with its
value set to the value it would have been set to after mutating the
empty string. The same <code>DOMTokenList</code> or
<code>DOMSettableTokenList</code> object must be returned every time
for each attribute.</p>
underlying string is the element's corresponding content attribute.
When the object mutates its underlying string, the content attribute
must itself be immediately mutated. When the attribute is absent,
then the string represented by the object is the empty string; when
the object mutates this empty string, the user agent must add the
corresponding content attribute, with its value set to the value it
would have been set to after mutating the empty string. The same
<code>DOMTokenList</code> or <code>DOMSettableTokenList</code>
object must be returned every time for each attribute.</p>

<div class="example">

Expand Down

0 comments on commit 6afb08d

Please sign in to comment.