[whatwg] HTML Editing Commands spec minor clarifications

[Tim Down]

On 12 May 2011 19:06, Aryeh Gregor <Simetrical+w3c at gmail.com> wrote:
> 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.

I did some simple tests yesterday that confirm that Gecko generally
acts only the first range, and was slightly surprised. I would expect
it to affect all ranges in the selection. However, when you select
multiple table cells in Gecko (which always creates a range for each
selected cell, regardless of whether or not you use the Ctrl key),
calling document.execCommand() acts on each range. Only the state of
the first range is taken into consideration when deciding what state
the selection has, meaning that for a binary command such as Bold, all
selected cells are switched to the opposite state to that of the first
selected cell.

Tim