--- a/editing.html Thu Jul 28 13:52:28 2011 -0600
+++ b/editing.html Thu Jul 28 14:12:05 2011 -0600
@@ -270,13 +270,6 @@
"collapsed block prop", but there's lots of other special-case handling
scattered about. Feedback appreciated. How do browsers handle this?
- <li>Where methods take a value, I've decided they should throw SYNTAX_ERR
- instead of doing nothing if the value makes no sense. As a rule, this
- doesn't match browsers. I think it's more useful to authors, however,
- especially since in many cases, the command's effect isn't currently
- interoperable anyway. I'll switch them back to doing nothing if implementers
- think this is a problem.
-
<li>The CSS styling flag is an issue. Currently authors are forced to turn
it entirely on or entirely off. If it's on, it produces stuff like <code title=""><span style=font-weight:bold></code> instead of <code title=""><b></code>, while if it's off, it produces stuff like <code title=""><font color=red></code> instead of <code title=""><span
style=color:red></code>. The issue is that authors might want a mix, like
@@ -2417,7 +2410,7 @@
<li>If <var title="">value</var> is not a valid CSS color, prepend "#" to it.
<li>If <var title="">value</var> is still not a valid CSS color, or if it is
- currentColor, raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code> exception.
+ currentColor, abort these steps and do nothing.
<li><a href="#set-the-selection's-value">Set the selection's value</a> to <var title="">value</var>.
</ol>
@@ -2470,8 +2463,8 @@
start, with the text equal to the link URL. Other browsers don't do it, so I
don't either. -->
<ol>
- <li>If <var title="">value</var> is the empty string, raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code>
- exception.
+ <li>If <var title="">value</var> is the empty string, abort these steps and do
+ nothing.
<!--
Firefox 4b11 and Chrome 11 dev both silently do nothing in this case.
IE 9 RC and Opera 11 both treat the request literally. Gecko and WebKit
@@ -2479,9 +2472,6 @@
to link to a relative URL resolving to the current document. If they really
want to, they can always specify "#" for the value, or the author can rewrite
it, so it's not like this makes the API less useful.
-
- As in other cases, I raise a SYNTAX_ERR instead of silently failing, because
- I think that's more useful. See issues.
-->
<li>For each <a href=#editable>editable</a> <code class=external data-anolis-spec=html title="the a element"><a href=http://www.whatwg.org/html/#the-a-element>a</a></code> element that has an <code class=external data-anolis-spec=html title=attr-hyperlink-href><a href=http://www.whatwg.org/html/#attr-hyperlink-href>href</a></code>
@@ -2602,8 +2592,8 @@
respecifying non-interoperable behavior anyway.
-->
<ol>
- <li>If <var title="">value</var> is the empty string, raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code>
- exception.
+ <li>If <var title="">value</var> is the empty string, abort these steps and do
+ nothing.
<li><a class=external data-anolis-spec=html href=http://www.whatwg.org/html/#strip-leading-and-trailing-whitespace>Strip leading and trailing whitespace</a>
from <var title="">value</var>.
@@ -2661,7 +2651,7 @@
<li>If <var title="">value</var> is not one of the strings "xx-small", "x-small",
"small", "medium", "large", "x-large", "xx-large", "xxx-large", and is not a
- valid CSS absolute length, then raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code> exception.
+ valid CSS absolute length, then abort these steps and do nothing.
<!--
Not sure this is the best way to do it. We don't want to allow relative
lengths, because those can have very weird user-visible behavior. For
@@ -2817,7 +2807,7 @@
<li>If <var title="">value</var> is not a valid CSS color, prepend "#" to it.
<li>If <var title="">value</var> is still not a valid CSS color, or if it is
- currentColor, raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code> exception.
+ currentColor, abort these steps and do nothing.
<!-- currentColor is bad for the same reason as relative font sizes. It will
confuse the algorithm, and doesn't seem very useful anyway. -->
@@ -2868,7 +2858,7 @@
<li>If <var title="">value</var> is not a valid CSS color, prepend "#" to it.
<li>If <var title="">value</var> is still not a valid CSS color, or if it is
- currentColor, raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code> exception.
+ currentColor, abort these steps and do nothing.
<!-- currentColor is bad for the same reason as relative font sizes. It will
confuse the algorithm, and doesn't seem very useful anyway. For hiliteColor
you could conceive of it being useful, but it will still confuse the
@@ -5782,8 +5772,8 @@
<li>Let <var title="">value</var> be <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#converted-to-ascii-lowercase>converted to
ASCII lowercase</a>.
- <li>If <var title="">value</var> is not a <a href=#formattable-block-name>formattable block name</a>, raise a
- <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code> exception.
+ <li>If <var title="">value</var> is not a <a href=#formattable-block-name>formattable block name</a>, abort
+ these steps and do nothing.
<!--
Opera 11.10 throws NOT_SUPPORTED_ERR for bad elements, all other tested
browsers ignore the input. Testing in IE9, Firefox 4.0, Chrome 13 dev, and
@@ -6459,8 +6449,8 @@
<p><a href=#action>Action</a>:
<ol>
- <li>If <var title="">value</var> is the empty string, raise a <code class=external data-anolis-spec=domcore title=dom-DOMException-SYNTAX_ERR><a href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#dom-domexception-syntax_err>SYNTAX_ERR</a></code>
- exception.
+ <li>If <var title="">value</var> is the empty string, abort these steps and do
+ nothing.
<!-- Similar logic to createLink, except even more compelling, since an HTML
document linking to itself as an image is just silly. In fact, the current
HTML spec instructs UAs to not even try displaying the image, and just fail
--- a/implementation.js Thu Jul 28 13:52:28 2011 -0600
+++ b/implementation.js Thu Jul 28 14:12:05 2011 -0600
@@ -2894,7 +2894,7 @@
// "If value is not a valid CSS color, prepend "#" to it."
//
// "If value is still not a valid CSS color, or if it is currentColor,
- // raise a SYNTAX_ERR exception."
+ // abort these steps and do nothing."
//
// Cheap hack for testing, no attempt to be comprehensive.
if (/^([0-9a-fA-F]{3}){1,2}$/.test(value)) {
@@ -2903,7 +2903,7 @@
if (!/^(rgba?|hsla?)\(.*\)$/.test(value)
&& !parseSimpleColor(value)
&& value.toLowerCase() != "transparent") {
- throw "SYNTAX_ERR";
+ return;
}
// "Set the selection's value to value."
@@ -2932,9 +2932,9 @@
//@{
commands.createlink = {
action: function(value) {
- // "If value is the empty string, raise a SYNTAX_ERR exception."
+ // "If value is the empty string, abort these steps and do nothing."
if (value === "") {
- throw "SYNTAX_ERR";
+ return;
}
// "For each editable a element that has an href attribute and is an
@@ -3046,21 +3046,21 @@
commands.fontsize = {
action: function(value) {
- // "If value is the empty string, raise a SYNTAX_ERR exception."
+ // "If value is the empty string, abort these steps and do nothing."
if (value === "") {
- throw "SYNTAX_ERR";
+ return;
}
value = normalizeFontSize(value);
// "If value is not one of the strings "xx-small", "x-small", "small",
// "medium", "large", "x-large", "xx-large", "xxx-large", and is not a
- // valid CSS absolute length, then raise a SYNTAX_ERR exception."
+ // valid CSS absolute length, then abort these steps and do nothing."
//
// More cheap hacks to skip valid CSS absolute length checks.
if (["xx-small", "x-small", "small", "medium", "large", "x-large", "xx-large", "xxx-large"].indexOf(value) == -1
&& !/^[0-9]+(\.[0-9]+)?(cm|mm|in|pt|pc)$/.test(value)) {
- throw "SYNTAX_ERR";
+ return;
}
// "Set the selection's value to value."
@@ -3142,7 +3142,7 @@
// "If value is not a valid CSS color, prepend "#" to it."
//
// "If value is still not a valid CSS color, or if it is currentColor,
- // raise a SYNTAX_ERR exception."
+ // abort these steps and do nothing."
//
// Cheap hack for testing, no attempt to be comprehensive.
if (/^([0-9a-fA-F]{3}){1,2}$/.test(value)) {
@@ -3151,7 +3151,7 @@
if (!/^(rgba?|hsla?)\(.*\)$/.test(value)
&& !parseSimpleColor(value)
&& value.toLowerCase() != "transparent") {
- throw "SYNTAX_ERR";
+ return;
}
// "Set the selection's value to value."
@@ -3170,7 +3170,7 @@
// "If value is not a valid CSS color, prepend "#" to it."
//
// "If value is still not a valid CSS color, or if it is currentColor,
- // raise a SYNTAX_ERR exception."
+ // abort these steps and do nothing."
//
// Cheap hack for testing, no attempt to be comprehensive.
if (/^([0-9a-fA-F]{3}){1,2}$/.test(value)) {
@@ -3179,7 +3179,7 @@
if (!/^(rgba?|hsla?)\(.*\)$/.test(value)
&& !parseSimpleColor(value)
&& value.toLowerCase() != "transparent") {
- throw "SYNTAX_ERR";
+ return;
}
// "Set the selection's value to value."
@@ -5908,10 +5908,10 @@
// "Let value be converted to ASCII lowercase."
value = value.toLowerCase();
- // "If value is not a formattable block name, raise a SYNTAX_ERR
- // exception."
+ // "If value is not a formattable block name, abort these steps and do
+ // nothing."
if (formattableBlockNames.indexOf(value) == -1) {
- throw "SYNTAX_ERR";
+ return;
}
// "Block-extend the active range, and let new range be the result."
@@ -6532,9 +6532,9 @@
//@{
commands.insertimage = {
action: function(value) {
- // "If value is the empty string, raise a SYNTAX_ERR exception."
+ // "If value is the empty string, abort these steps and do nothing."
if (value === "") {
- throw "SYNTAX_ERR";
+ return;
}
// "Let range be the active range."
--- a/source.html Thu Jul 28 13:52:28 2011 -0600
+++ b/source.html Thu Jul 28 14:12:05 2011 -0600
@@ -196,13 +196,6 @@
"collapsed block prop", but there's lots of other special-case handling
scattered about. Feedback appreciated. How do browsers handle this?
- <li>Where methods take a value, I've decided they should throw SYNTAX_ERR
- instead of doing nothing if the value makes no sense. As a rule, this
- doesn't match browsers. I think it's more useful to authors, however,
- especially since in many cases, the command's effect isn't currently
- interoperable anyway. I'll switch them back to doing nothing if implementers
- think this is a problem.
-
<li>The CSS styling flag is an issue. Currently authors are forced to turn
it entirely on or entirely off. If it's on, it produces stuff like <code
title><span style=font-weight:bold></code> instead of <code
@@ -2397,7 +2390,7 @@
<li>If <var>value</var> is not a valid CSS color, prepend "#" to it.
<li>If <var>value</var> is still not a valid CSS color, or if it is
- currentColor, raise a [[SYNTAX_ERR]] exception.
+ currentColor, abort these steps and do nothing.
<li><span>Set the selection's value</span> to <var>value</var>.
</ol>
@@ -2451,8 +2444,8 @@
start, with the text equal to the link URL. Other browsers don't do it, so I
don't either. -->
<ol>
- <li>If <var>value</var> is the empty string, raise a [[SYNTAX_ERR]]
- exception.
+ <li>If <var>value</var> is the empty string, abort these steps and do
+ nothing.
<!--
Firefox 4b11 and Chrome 11 dev both silently do nothing in this case.
IE 9 RC and Opera 11 both treat the request literally. Gecko and WebKit
@@ -2460,9 +2453,6 @@
to link to a relative URL resolving to the current document. If they really
want to, they can always specify "#" for the value, or the author can rewrite
it, so it's not like this makes the API less useful.
-
- As in other cases, I raise a SYNTAX_ERR instead of silently failing, because
- I think that's more useful. See issues.
-->
<li>For each <span>editable</span> [[a]] element that has an [[href]]
@@ -2583,8 +2573,8 @@
respecifying non-interoperable behavior anyway.
-->
<ol>
- <li>If <var>value</var> is the empty string, raise a [[SYNTAX_ERR]]
- exception.
+ <li>If <var>value</var> is the empty string, abort these steps and do
+ nothing.
<li><span data-anolis-spec=html>Strip leading and trailing whitespace</span>
from <var>value</var>.
@@ -2642,7 +2632,7 @@
<li>If <var>value</var> is not one of the strings "xx-small", "x-small",
"small", "medium", "large", "x-large", "xx-large", "xxx-large", and is not a
- valid CSS absolute length, then raise a [[SYNTAX_ERR]] exception.
+ valid CSS absolute length, then abort these steps and do nothing.
<!--
Not sure this is the best way to do it. We don't want to allow relative
lengths, because those can have very weird user-visible behavior. For
@@ -2798,7 +2788,7 @@
<li>If <var>value</var> is not a valid CSS color, prepend "#" to it.
<li>If <var>value</var> is still not a valid CSS color, or if it is
- currentColor, raise a [[SYNTAX_ERR]] exception.
+ currentColor, abort these steps and do nothing.
<!-- currentColor is bad for the same reason as relative font sizes. It will
confuse the algorithm, and doesn't seem very useful anyway. -->
@@ -2849,7 +2839,7 @@
<li>If <var>value</var> is not a valid CSS color, prepend "#" to it.
<li>If <var>value</var> is still not a valid CSS color, or if it is
- currentColor, raise a [[SYNTAX_ERR]] exception.
+ currentColor, abort these steps and do nothing.
<!-- currentColor is bad for the same reason as relative font sizes. It will
confuse the algorithm, and doesn't seem very useful anyway. For hiliteColor
you could conceive of it being useful, but it will still confuse the
@@ -5785,8 +5775,8 @@
<li>Let <var>value</var> be <span data-anolis-spec=domcore>converted to
ASCII lowercase</span>.
- <li>If <var>value</var> is not a <span>formattable block name</span>, raise a
- [[SYNTAX_ERR]] exception.
+ <li>If <var>value</var> is not a <span>formattable block name</span>, abort
+ these steps and do nothing.
<!--
Opera 11.10 throws NOT_SUPPORTED_ERR for bad elements, all other tested
browsers ignore the input. Testing in IE9, Firefox 4.0, Chrome 13 dev, and
@@ -6465,8 +6455,8 @@
<p><span>Action</span>:
<ol>
- <li>If <var>value</var> is the empty string, raise a [[SYNTAX_ERR]]
- exception.
+ <li>If <var>value</var> is the empty string, abort these steps and do
+ nothing.
<!-- Similar logic to createLink, except even more compelling, since an HTML
document linking to itself as an image is just silly. In fact, the current
HTML spec instructs UAs to not even try displaying the image, and just fail
--- a/tests.js Thu Jul 28 13:52:28 2011 -0600
+++ b/tests.js Thu Jul 28 14:12:05 2011 -0600
@@ -3953,19 +3953,15 @@
specCell.firstChild.removeAttribute("spellcheck");
specCell.lastChild.textContent = "Exception: " + e;
- // If it's "SYNTAX_ERR", then we threw it, so all is well. Otherwise,
- // flag as an alert.
- if (e !== "SYNTAX_ERR") {
- specCell.parentNode.className = "alert";
- specCell.lastChild.className = "alert";
- if (typeof e == "object" && "stack" in e) {
- specCell.lastChild.textContent += " (stack: " + e.stack + ")";
- }
-
- // Don't bother comparing to localStorage, this is always wrong no
- // matter what.
- return;
+ specCell.parentNode.className = "alert";
+ specCell.lastChild.className = "alert";
+ if (typeof e == "object" && "stack" in e) {
+ specCell.lastChild.textContent += " (stack: " + e.stack + ")";
}
+
+ // Don't bother comparing to localStorage, this is always wrong no
+ // matter what.
+ return;
}
if (command != "multitest") {