On May 23, 2014, at 1:37 PM, Robin Berjon <ro...@w3.org> wrote: > 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.
They are not. Word substations and input method compositions are semantically different operations. > 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. Just because they're treated the same way in one platform doesn't allow us to treat them same in all platforms. It's crucial for editors on the Web to be able to use the same UI for on the platforms that do differentiate the two. > 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. In older versions of Windows, for example, the browser itself can't figure out what kind of style is used by IME. Korean and Japanese IME on Windows, for example, use bolded lines and dotted lines for opposite purposes. And we get bug reports saying that WebKit's rendering for Korean IME is incorrect because we decided to follow Japanese IME's convention. > 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 :) In my opinion, it's a requirement that input methods work and look native on editors that use this new API. IME is not a nice-to-have feature. It's a feature required for billions of people to type any text. >> 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! I strongly disagree. - R. Niwa
