RE: contentEditable=minimal

> From: Robin Berjon [mailto:robin@w3.org]
> 
> I think we agree at the high level but might disagree over smaller details. You
> seem to want something that would roughly resemble the
> following:
> 
> BeforeSelectionChange
> {
>    direction:  "forward"
> , step:       "word"
> }
> 
> whereas I would see something capturing information more along those lines:
> 
> BeforeSelectionChange
> {
>    oldRange:  [startNode, startOffset, endNode, endOffset] , newRange:
> [startNode, startOffset, endNode, endOffset] }
> 
> I think that the latter is better because it gives the library the computed
> range that matches the operation, which as far as I can imagine is what you
> actually want to check (e.g. check that the newRange does not contain
> something unselectable, isn't outside a given boundary, etc.).
> 
> The former requires getting a lot of details right in the spec, and those would
> become hard to handle at the script level. On some platforms a triple click (or
> some key binding) can select the whole line. This not only means that you
> need direction: "both" but also that the script needs a notion of line that it
> has no access to (unless the Selection API grants it). What makes up a "word"
> as a step also varies a lot (e.g.
> I tend to get confused by what Office apps think a word is as it doesn't match
> the platform's idea) and there can be interesting interactions with language
> (e.g. is "passive-aggressive" one word or two? What about "co-operation"?).
> 
> But maybe you have a use case for providing the information in that way that
> I am not thinking of?

This seems like it's getting pretty close to the browser just doing the selection. A browser would still have to figure out what the selection should look like in the version you suggest. Instead, maybe each site could decide what is thinks is a word ("passive" or "passive-agressive"). The line example is good, so maybe we should have a 'line' level selection just like the 'word' level?

> >> Not all of those are separate, though. Voice input is just an input
> >> (or beforeinput) that's more than one character long. There's nothing
> >> wrong with that. So is pasting (though you need cleaning up).
> >> Composition you need to handle, but I would really, really hope that
> >> the platform gives you a delete event with a range that matches what
> >> it is expected to delete rather than have you support all the
> >> modifiers (which you'll get wrong for the user as they are platform
> >> specific). As seen in the code gist I posted, given such a delete
> >> event the scripting is pretty simple.
> >
> > I agree, except that I don't know why we want paste to fire two
> > 'intention' events (paste and input). Seems like we should make it
> > clear that the intention is insert text (type, voice, whatever),
> > remove text (delete, including what text to remove), or paste (so you
> > can clean it up).
> 
> I don't think we want to fire both paste and input, but if my reading is correct
> that is the case today (or expected to be — this isn't exactly an area of high
> interop).

Yes my understanding is that today you get both. I'm not arguing against that as the events stand today, but when we talk about 'Intention Events' as an abstract type with certain properties like commandName, I think you should only get one of those (paste or command or beforeinput), and I'm suggesting that it should be paste in this case.

Ben

Received on Monday, 2 June 2014 21:01:33 UTC