how does cE=typing handle autocorrect and spelling suggestions?

[teleclimber]

Have a look at issue #28 for the start of this discussion. Summary: we thought of limiting AC's effect to individual text nodes, @rniwa strongly opposed.

In my opinion contentEditable=typing should allow editor devs to leverage the UA/OS spellchecker and autocorrect. Also, the end-user's experience using such an editor should be similar to using a native rich text editor (same red squiggles, same OS-native popup balloons etc...)

We may have to spec an Autocorrect Intent that passes enough information for the editor dev to do the replacement operation themselves. The AC Intent would fire when:

• UA/OS decides to automatically correct text as the user types
• the user right-clicks on incorrect text and selects a replacement word from the popup menu.

If AC works across partially-styled text (as Safari currently does) then AC has the potential to delete DOM Elements, therefore the default behavior of this intent under cE=typing should be "do nothing".

As an editor dev I suspect I would be able to perform the correction in the DOM if given:

• the Range representing the original text content that is incorrect (the misspelled word)
• the unstyled, plain-text proper spelling as a simple character string.

This would be a bit more work for editor devs compared to text-node only AC, but the upsides are:

• more control for editor dev
• better UX for users

Thoughts?

[rniwa]

I think providing enough information for editors to take care of autocorrection makes sense. I just hope that we can come up with a single API that works for both IME and autocorrection so that editors don't have to deal with each case separately.

[johanneswilm]

Investigating a bit, I am now less sure. The spell checking offered by most popular browsers today is rather primitive because it doesn't take context into account and when a word is more than two letters off, no good suggestions are offered at all.

Additionally, the spell checking is automatically disabled when the right lick menu is overridden and when the text editor is just a little bit more complex than the most primitive possible, it's also impossible to use.

Also, the spell checker language has to be switched by the user and the web editor programmer has no influence on it.

All in all it seems like an ultra broken concept. I am not sure what the security issues for the browser developers are, except that on Mac OS X the spell checker seems for some browsers to be the system spell checker which have had custom words added and I guess some users would add their most secret passwords into their spell checker(?) Somehow it seems this just won't be resolved. The various proposals made that "just let the browser handle it" or "tell the browser about extra dictionary terms" seem rather unrealistic if we are talking about more than just a very primitive editor with no custom controls.

However, what are the alternatives?

There is server side spell checking (Aspell/Pspell based), the way some CKeditor and TinyMCE plugins offer it. There are also some commercial subscription services for grammar checking such as grammarly. All of these will be rather unacceptable for all projects wanting to offer either A) an offline solution or B) don't want to create a lot of server traffic to provide a function that the users computer really has built-in already.

There are also at least two open source client side solutions: http://code.google.com/p/bjspell/ (not updated since 2009) and https://github.com/cfinke/Typo.js/ (still being hacked on). Both are based on Hunspell. These should provide exactly what editor developers will want. The downside is that the end user needs to download dictionary files (700kb-2MB for western European languages) when visiting a site, and at the same time they will likely have bunch of dictionaries bundled with their OS or browser already. The good thing is that download costs go down and will continue to go down, so with time this issue will be of less importance.

Taking all this together, I would suggest to either completely disable spell checking or add it in the least possible invasive way. Text nodes suddenly changing outside of the control of the editor seem like rather invasive, but it's a lot better than random DOM structures changing, empty text nodes disappearing or text nodes being randomly split or merged. The most important part is that the spell checking can be turned off (as it can today).

[rniwa]

I think we can provide a way for editors to specify where & when spellchecking can be performed so that the apps could provide enough context. However, providing the list of potential correction candidates won't be acceptable in terms of privacy and security.

It appears to me that we need a generic "Replace" device-independent event that gets used for spellchecking & IME.

[BenjamP]

I agree with that Ryosuke. A replace event could require that the site ensure that the selection is completely contained inside a single text node in order to have a default action. It could then handle IME, spellchecking, and maybe overtype.

[rniwa]

That's a good point! We could even throw some error if the selection is anchored across non-text nodes inside the default event action.

[johanneswilm]

@rniwa : Just out of curiosity, could you explain what those security issues are? I mean I get that if using the right word to correct, the js program may be able to find out that the user has added a specific word to his custom dictionary. Is this the security concern? And could it not be handled like access to camera and other devices?

Such an event as you describe is better than nothing, but still I think the usefulness of this kind of spell checking for the kind of editors that can make use of contenteditable=typing over contenteditable=true, will be very limited.

[rniwa]

The problem is that the user could reveal sensitive information such as the full name, physical mailing address, etc... And unfortunately, most user wouldn't understand the implication of such a security warning dialog/sheet. It's a fundamentally broken security model.

I will strongly object to any API that provides the list of possible correction candidates.

[BenjamP]

I don't think this task force is working on spellchecking, so let's be careful not to get off topic here. We should decide only if browser spellchecking should be available in ce=typing or not. If so we can also decide how to enable it.

[johanneswilm]

@BenjamP : Yes, but understanding what the security is is fundamental to understanding why this cannot be added in some other way. If it could be enabled to javascript in general, then it would be a strong argument for not making spellchecking available in ce=typing at all.

[BenjamP]

Ok, that's fair. I don't think we want to take a dependency on that though.

[johanneswilm]

@BenjamP : I think you will have a much easier time convincing editor developers that the browser needs to take care of spell checking, once it has been properly explained why this is a security concern for the browser.

[johanneswilm]

@rniwa They would add their full name to the dictionary?
Ok, so I guess if a user somewhere in the app gives his name as "Benjamin H." then the app could use the spell checker to check for everything from "Hansen" to "Huntsville" and if one of those doesn't give an error when it usually would (given the browser), then there is a certain likelihood that the person's name is "Benjamin H..." . Is that the concern?

[BenjamP]

It's a security concern for the user because names (including first/last name only), places, etc are likely to be personally identifiable. If a user wants to type them, that's fine. But a browser shouldn't just give access to them.

[johanneswilm]

@BenjamP : Ok, and it is your experience that user will add these to their dictionaries and there is no way to exclude the personalized part of the dictionary when offering spell checking? If this is the case and users tend to add passwords and credit card numbers, etc. to their personal dictionaries, then I do understand your guys'es concern and I don't think any editor project will request of you guys to give them access to the spell checker.

If the idea is that ce=typing is to replace ce=true entirely eventually, then adding it the way you suggested makes most sense. Just make sure that the disabling of spell checking and auto correcting is simple and consistent.

[johanneswilm]

I am not sure I understand the security concern, but lets just accept this as something only implementers understand.

I take it that everyone agrees that the site needs to be able to enable/disable auto correct and spell checking, whereas language selection of auto correct and spell checking is something only the user controls, correct?

Are the attributes autocomplete, autocorrect, autocapitalize and spellcheck enough? And it is OK to only have this for text nodes inside the elements with those attributes and an event that is triggered when one of those four has taken place and the contents of a text node have changed?