[whatwg] Normalization of user selections

Fri Jun 17 11:41:47 PDT 2011

Since I've somehow managed to send from the wrong address again for
the third time in 48 hours, here's yet another resent mail, probably
to be followed by a fourth when I respond to Boris' response and Gmail
auto-selects my non-list address again for the from address instead of
my list address:

On Thu, Jun 16, 2011 at 3:09 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:
> What if we had foo<b></b><i></i>bar?

Well, what's the use-case?

> Yes, I think all selection modified by user should be normalized by default.
>  I'm talking more about programmatically set selection.  I think we'll need
> to preserve programmatically set selection ranges instead of always storing
> normalized ranges.

Normalizing the selection even when the author sets it is helpful
because it prevents authoring mistakes. For instance, if the author
wants to put the cursor at the end of an element, they might just do
getSelection().collapse(el, el.childNodes.length). But if the element
happens to be foo , that's not what the author wants: if the
user types, it will insert text on a new line, when the actually
has no visual effect and the cursor should go before it. So it would
help authors if foo {} were automatically normalized to
foo{} .

( handling in this sort of situation is an absolute nightmare,
incidentally. I handle the really common cases currently in my
algorithms, but anything trivially different like
foo will cause tons of stuff to break. It's
on my todo list, but there's only so much I can do without writing
some explicit and complicated description based on the CSS box model .
. .)

Still, since IE and Gecko already don't normalize, and we now have two
WebKit people against normalizing (you and Roland -- although Ojan in
favor), it seems like not normalizing is the more plausible path.
However, I'd still like to normalize author-set selections somewhat.
At a minimum, for instance, we could guarantee that a selection's
boundary point is always in a Text or Element node that descends from
a Document.  That would be a big simplification by itself.  Does
anyone object to that?

On Thu, Jun 16, 2011 at 3:12 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> 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 don't know.  I'm happy to hear suggestions.

On Thu, Jun 16, 2011 at 3:30 PM, Ojan Vafai <ojan at chromium.org> wrote:
> 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.

And all browser engines except Gecko now, too.  I got it from your
writeup about 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);

Ouch, that looks very unpleasant.  What's the exact use-case here?

On Fri, Jun 17, 2011 at 4:01 AM, Roland Steiner
<rolandsteiner at google.com> wrote:
> FWIW, I'm with Ryosuke on this one - NOT preserving programmatically set
> selections seems very dangerous to me, esp. if it's just for the sake of
> making it easier on the implementors. That way, neither the user NOR the
> programmer has complete control over what is happening in detail.

As I note above, there are benefits to authors too -- we can avert
some types of mistakes.  An explicit normalize() method as Ryosuke
suggests would only help authors who actually use it.  But as I said,
given feedback so far, it looks like I'll be going for only minimal
normalization of author-set selections.

> Exactly my thoughts. It's unfortunate that whether 2 different positions in
> the DOM correspond to the same visual position cannot be determined by
> looking at the DOM only - for example, there may be margins or even
> auto-generated content around elements, that *do* neatly separate them.

Yeah, it's really depressing how huge and elaborate the CSS dependency
would have to be to fully account for all this sort of stuff.
Realistically, I think the spec is going to have to be defined in
terms of the DOM with only minimal CSS interaction -- although of
course it needs some -- and we'll have to accept that there will be
failures in corner cases.  I don't want to have to go down the path of
talking about things like containing blocks and so on.  If nothing
else, a JavaScript test implementation would be impossible, since lots
of these CSS concepts aren't exposed to JavaScript.  I've been relying
very heavily on my test implementation to judge whether the spec is
correct.

Fortunately, in typical contenteditable scenarios, there's really very
little in the way of CSS.  So we can just pretend that there are no
margins on inline elements, no generated content, etc. and it
shouldn't make a big difference to typical use-cases.  In particular,
I'm mostly concerned with contenteditable features being able to
handle content created by contenteditable features, with only limited
non-default styles (like changing the default font or removing margins
from paragraphs) and maybe some things you'd expect from hand-editing
(like collapsed whitespace nodes).  Maybe the API should be amenable
to more complicated markup, to the extent that makes sense for
WYSIWYG, but that can be pushed off to a later date.