- From: Aryeh Gregor <ayg@aryeh.name>
- Date: Wed, 11 Jan 2012 14:55:39 -0500
- To: Ryosuke Niwa <rniwa@webkit.org>
- Cc: Ehsan Akhgari <ehsan@mozilla.com>, Simon Pieters <simonp@opera.com>, Anne van Kesteren <annevk@opera.com>, W3C WebApps WG <public-webapps@w3.org>
On Wed, Jan 11, 2012 at 12:27 PM, Ryosuke Niwa <rniwa@webkit.org> 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 Gecko/WebKit): http://dvcs.w3.org/hg/editing/rev/6aaa4b8455c9 I also added a test for the latter condition, and filed a Gecko bug (WebKit is also now buggy per spec): http://dvcs.w3.org/hg/editing/raw-file/6aaa4b8455c9/selecttest/unload.html https://bugzilla.mozilla.org/show_bug.cgi?id=717339 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 change. On Wed, Jan 11, 2012 at 11:54 AM, Boris Zbarsky <bzbarsky@mit.edu> 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 code. 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