[whatwg] HTML Editing Commands spec minor clarifications

[Aryeh Gregor]

Thanks for the feedback!

On Wed, May 11, 2011 at 1:39 PM, Tim Down <timdown at gmail.com> wrote:
> In section 11, the HTML Editing Commands spec says the following:
>
> "When execCommand() is invoked, the user agent must take the action
> from the list below given by commandId on the context object's first
> range."
>
> I have two questions about this:
>
> 1. What is the "context object" here? According to the linked
> definition, it sounds like it should be document, but I assume it
> should be the Selection object.

Yeah, sorry -- that's a mistake.  I changed it to "the first range of
the Selection given by invoking getSelection() on the context object":

http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=0b0da5bf830dcfc7f7c3a873123b3710e1b52c84

Thanks for the correction.

> 2. Assuming the context object is the Selection, what is the "first
> range"? I assume this is the range obtained by calling getRangeAt(0)
> on the selection as specified by the new Range spec. This "first
> range" won't always match current browser reality since Gecko orders
> ranges in a selection in document order rather than in order of
> addition to the selection, as noted in the spec.

I have a todo about this in the DOM Range spec:

"""
The addRange(range) method must add the given range to the list of
selections, at the end (so the newly added Range is the new last
Range). Duplicates are not prevented; a Range may be added more than
once in which case it appears in the list more than once, which (for
example) will cause stringification to return the Range's text twice.

XXX: This is wrong. First of all, no one but Gecko even allows
multiple ranges per selection. Second of all, Gecko stores the ranges
sorted by their starts in tree order, not related to the order they
were added. Third of all, Gecko doesn't allow overlapping ranges, so
if you add a range that overlaps an existing range, it removes or
alters existing ranges in the list to avoid overlap, sometimes even
splitting an existing range in two. We need to specify this, or else
specify saner behavior if we expect anyone to actually follow it. We
also need to account for the fact that non-Gecko browsers might not be
interested in supporting multiple ranges per selection, maybe by
explicitly allowing that: see discussion.
"""
http://html5.org/specs/dom-range.html#dom-selection-addrange

Really the whole idea of multiple Ranges per Selection is underdefined
right now, since AFAIK only Gecko supports it at all, and the way it
does it is weird and we don't really want to spec it, and other
engines don't seem to want to implement it anyway.  So I might get to
that at some point, but for now I'm not really paying attention to it.
 My current focus is on getting the execCommand() algorithms right --
I'm leaving API details for later.

IIRC, my testing did actually show that Gecko affects the first range,
meaning the first range ordered by start.  (Also IIRC, Gecko doesn't
permit overlapping ranges, so the start is always unique.)  But I've
added a todo here also, pointing out the possible error:

http://aryeh.name/gitweb.cgi?p=editcommands;a=commitdiff;h=93e928f08347078c8518e428338e9e8606a5eb66

Actually, it would make most sense to just affect all ranges in the
selection, and I wouldn't be surprised if the current Gecko behavior
is an accident.