--- a/editcommands.html Tue Jun 28 11:57:05 2011 -0600
+++ b/editcommands.html Tue Jun 28 12:07:01 2011 -0600
@@ -2469,6 +2469,21 @@
value</a> of each returned <a class=external data-anolis-spec=domcore href=http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#concept-node title=concept-node>node</a> to <var title="">value</var>.
</ol>
+<p><a href=#value>Value</a>: The <a href=#effective-value>effective value</a> of the <a href=#active-range>active
+range</a>'s <a class=external data-anolis-spec=domrange href=http://html5.org/specs/dom-range.html#concept-range-start title=concept-range-start>start</a> <a class=external data-anolis-spec=domrange href=http://html5.org/specs/dom-range.html#concept-boundary-point-node title=concept-boundary-point-node>node</a>.
+
+<p class=note>This cannot be null, since the boundary point node of a selection
+must always be either an element or a text node that's the child of an element.
+<!--
+This seems to match Opera 11.11 exactly. Chrome 14 dev returns boolean false
+consistently, bizarrely enough. Firefox 6.0a2 seems to follow the same idea as
+the spec, but it likes to return "transparent", including sometimes when the
+answer really clearly should not be "transparent". IE9 throws exceptions most
+of the time for backColor, so I can't say for sure, but in the few cases where
+it doesn't throw it returns a random-looking number, so I'll assume it's crazy
+like for foreColor.
+-->
+
<p><a href=#relevant-css-property>Relevant CSS property</a>: "background-color"
--- a/implementation.js Tue Jun 28 11:57:05 2011 -0600
+++ b/implementation.js Tue Jun 28 12:07:01 2011 -0600
@@ -2915,6 +2915,19 @@
for (var i = 0; i < nodeList.length; i++) {
setNodeValue(nodeList[i], "hilitecolor", value);
}
+ }, value: function() {
+ // "The effective value of the active range's start node."
+ //
+ // Opera uses a different format, so let's be nice and support that for
+ // the time being (since all this computed value stuff is underdefined
+ // anyway).
+ var value = getEffectiveValue(getActiveRange().startContainer, "hilitecolor");
+ if (/^#[0-9a-f]{6}$/.test(value)) {
+ value = "rgb(" + parseInt(value.slice(1, 3), 16)
+ + "," + parseInt(value.slice(3, 5), 16)
+ + "," + parseInt(value.slice(5), 16) + ")";
+ }
+ return value;
}, relevantCssProperty: "backgroundColor"
};
//@}
--- a/source.html Tue Jun 28 11:57:05 2011 -0600
+++ b/source.html Tue Jun 28 12:07:01 2011 -0600
@@ -2445,6 +2445,21 @@
value</span> of each returned [[node]] to <var>value</var>.
</ol>
+<p><span>Value</span>: The <span>effective value</span> of the <span>active
+range</span>'s [[startnode]].
+
+<p class=note>This cannot be null, since the boundary point node of a selection
+must always be either an element or a text node that's the child of an element.
+<!--
+This seems to match Opera 11.11 exactly. Chrome 14 dev returns boolean false
+consistently, bizarrely enough. Firefox 6.0a2 seems to follow the same idea as
+the spec, but it likes to return "transparent", including sometimes when the
+answer really clearly should not be "transparent". IE9 throws exceptions most
+of the time for backColor, so I can't say for sure, but in the few cases where
+it doesn't throw it returns a random-looking number, so I'll assume it's crazy
+like for foreColor.
+-->
+
<p><span>Relevant CSS property</span>: "background-color"
<!-- @} -->