W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

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

From: Ryosuke Niwa <rniwa@webkit.org>
Date: Wed, 11 Jan 2012 09:27:53 -0800
Message-ID: <CABNRm62tigwgkeNnexkpAn0Q00GCXSdb5sFwonoNUnTOrf4MNA@mail.gmail.com>
To: Aryeh Gregor <ayg@aryeh.name>
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 8:41 AM, Aryeh Gregor <ayg@aryeh.name> wrote:

> Anne asked me to investigate how exactly Ranges are added to
> Selections (bug:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=15470).  It turns out
> browsers mostly don't interoperate.  One interesting thing I found out
> is that in Gecko, if no one calls
> addRange/removeRange/removeAllRanges, rangeCount is always exactly
> one.  This means getRangeAt(0) will never throw.  This is actually
> great, because it avoids a common authoring bug -- rangeCount is
> rarely 0 in any browser, so authors often will call getRangeAt(0)
> unconditionally, which risks throwing IndexSizeError.  I plan to
> change the spec to match Gecko, in requiring that user-created
> selections always have exactly one range (which is initially collapsed
> at (document, 0)).

Does gecko returns a Range at (document, 0) for getRange(0) in such cases?

I'd like to go further, though.  addRange() already doesn't allow more
> than one range per spec -- if there's an existing range, it replaces
> it.  How about removeRange() and removeAllRanges() remove the range
> and then add a new one collapsed at (document, 0)?  The common pattern
> of remove(All)Range(s) followed by addRange will still work the same,
> because addRange will replace the dummy range.  But now rangeCount
> will *always* be 1, so getRangeAt(0) will *never* throw.  This seems
> like it would prevent an entire class of authoring bugs (although I'm
> admittedly not totally sure about compat impact).
> Also, while I'm at it, how about collapsing at
> (document.documentElement, 0) instead of (document, 0)?  This has the
> minor added benefit of avoiding Selection boundary points that aren't
> in an Element or Text node, which again makes things simpler for
> authors.

This would change the behavior of removing ranges in design mode. Removing
the range will move the caret to the top of the document.

- Ryosuke
Received on Wednesday, 11 January 2012 17:35:21 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC