[whatwg] Normalization of user selections

On Thu, Jun 16, 2011 at 12:12 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 6/16/11 3:00 PM, Aryeh Gregor wrote:
>
>> Assuming we don't match WebKit/Opera here, though, does everyone agree
>> we should still place constraints on what selections can be generated
>> by *user* actions?  E.g., if you have<b>foo</b>bar, and the user
>> places the cursor in between "foo" and "bar" by any means, it should
>> always be inside the<b>, not outside.
>
>
Links are another tricky case. <a>foo</a>bar. If the cursor is between "foo"
and "bar" typing should go after the link, not inside. It's unfortunate, but
it's definitely what the majority of users expect. Right now, WebKit has a
nasty hack where we move the cursor outside the link when you type in this
case.


> This is an interesting situation which is the inverse of the bidi problem.
>  In the bidi case there is a single point in the DOM which corresponds to
> two different user-perceived selection positions.  In this case, a single
> user-perceived selection position corresponds to multiple (could be more
> than 2) points in the DOM....
>
> As an actual user of editors, by the way, the #1 thing that pisses me off
> about wysiwyg editors is precisely having situations like the one above and
> wanting to be able to make the text be "<b>foo</b>orbar" in some cases but
> "<b>foopy</b>bar" in others.  Wysisyg editors tend to be terrible at this
> sort of thing.  Is that something that's inevitable, or can we do better
> here?


I agree it's unfortunate. I'm not sure we can do better though. The
advantage of Aryeh's suggested normalization is that it matches nearly every
popular word processor on the market, so is most likely to match user
expectations.

I agree that the most sane thing for both users and developers is to
normalize. In general, it's very confusing to users for a visible position
to result in multiple possible outcomes. It's something that is very
difficult to get right as a web developer adding a small amount of extra
functionality on top of contentEditable.

That said, I would like there to be declarative control over how the
normalization happens. For example, if I'm writing a custom widget, whether
typing should go inside or outside is different depending on the widget.

This is probably not the best API, but here's a concrete proposal to control
selection normalization at the end of an node.:
document.setSelectionNormalization(INSIDE/OUTSIDE, varargs of selectors);

Ojan

Received on Thursday, 16 June 2011 12:30:18 UTC