Re: contentEditable=minimal

On 23/05/2014 21:32 , Jonas Sicking wrote:
> On Fri, May 23, 2014 at 4:43 AM, Robin Berjon <robin@w3.org> wrote:
>> On 23/05/2014 12:28 , Jonas Sicking wrote:
>>> And on mobile autocorrect of misspelled words is common, though that
>>> can probably be handled by moving the selection to the misspelled word
>>> and then writing the fixed word.
>>
>> Autocorrect should be handled like composition. Composition is pretty much
>> what happens whenever you type some stuff and some other stuff comes out.
>> (Technical definition.)
>
> I sadly don't think it's that simple. When compositing chinese
> characters, or characters like ü, an underline should be rendered
> during the composition and then removed once a character (or set of
> characters) is selected. This underline should not appear when typing
> on a mobile keyword, even if it supports autocorrect.
>
> It's not clear to me if the difference is just one of styling, or if
> there are semantic differences as well.

Semantically, autocorrect and compositing really are the same thing. How 
that gets rendered may be another story, but I'll point out that there 
are mobile UIs in which the word being typed is underlined.

Note that if there is a degree of refinement such that we may want to 
make it possible for authors to style compositing-for-characters and 
compositing-for-autocorrect, then that ought to go into the styling system.

We /could/ consider adding a field to compositing events that would 
capture some form of ontology of input systems. But I think that's sort 
of far-fetched and we can get by with the above. (And yes, I'm using 
"ontology" on purpose. It wouldn't look good :)

>>> Though one interesting edge case there is what happens if the page
>>> adjusts the selection as it's being moved to the word autocorrect
>>> wants to fix?
>>
>> I'm sorry, I don't understand the case you're thinking of?
>
> My assertion is that we don't want to use compositing events when
> typing on a keyboard which has autocorrect. (This might be a wrong
> assertion in which case none of this matters). Rather than composition
> events we fire events like:
>
> insert 'c'
> insert 'a'
> insert 'g'
> selection moved to start at index 0 and end at index 3
> insert 'cat'
> insert ' '
>
> However we've previously said that pages should be able to cancel or
> adjust selection moves. The question is what happens if the page
> changes the selection when autocorrect attempts to select the word to
> be fixed.

Gotcha, and indeed you are correct. If autocorrect were implemented as a 
change of the selection followed by an insert of the correction, the 
application could unwillingly interfere with the selection and cause 
mayhem. But even if that weren't the case this would feel pretty hacky. 
Maybe you are thinking of this because on recent Androids when you 
autocorrect there's an animation that more or less makes it look like 
that's what's going on?

Honestly, I really think that compositing events are the right 
abstraction here. We can get finicky on style tweaks, but they work for 
all compositing systems I can think of admittedly not *that* many but 
still quite a few). They would even work for T9!

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

Received on Friday, 23 May 2014 20:37:46 UTC