On 23/05/2014 21:32 , Jonas Sicking wrote:
On Fri, May 23, 2014 at 4:43 AM, Robin Berjon <ro...@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
