Re: [editing] Avoiding selections with no corresponding range, to simplify authoring

On Wed, Jan 11, 2012 at 12:27 PM, Ryosuke Niwa <> wrote:
> Does gecko returns a Range at (document, 0) for getRange(0) in such cases?

Okay, it looks like my testing before was off.  Actually, all browsers
have no range in the selection initially.  But I was testing in Live
DOM Viewer, which didn't fully reset the document state when the
source code changed, because not all browsers clear the selection's
range on unload.  I fixed the spec to require the range to initially
be null (like all browsers), and specified that the range has to be
reset to null when the document is unloaded (like IE/Opera, not like

I also added a test for the latter condition, and filed a Gecko bug
(WebKit is also now buggy per spec):

Since we seem to have interop on the selection's rangeCount initially
being 0, I'm no longer enthusiastic about changing that.  I'm fine
with leaving the spec as-is now, unless implementers would prefer to

On Wed, Jan 11, 2012 at 11:54 AM, Boris Zbarsky <> wrote:
> Then you have to handle the case when document.documentElement is null.
> And yes, this has come up before; there are scripts out there that remove
> documentElements, do some stuff, insert new documentElements, etc.
> . . .
> This would happen anyway if you set up a selection inside
> document.documentElement and someone removes the documentElement; the normal
> range algorithm will give you endpoints inside the Document.  so you really
> can't enforce this condition.

Well, yes, and you can also do addRange() with whatever you like.  But
we can at least try to make the condition rarer, so bugs are less
likely to crop up in practice when authors inevitably write incorrect

Anyway, as noted, I retract my suggestion for other reasons, unless
someone else is still interested.

Received on Wednesday, 11 January 2012 19:56:36 UTC