Add autocorrect content attribute to HTMLElement

[rniwa]

Like autocapitalize, autocorrect would turn on/off autocorrection on iOS. It would be good to have this iOS feature standardized.

[annevk]

From @cvrebert in https://www.w3.org/Bugs/Public/show_bug.cgi?id=28747:

Safari docs: https://developer.apple.com/library/safari/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocorrect
MDN docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input#attr-autocorrect

[domenic]

@dtapuska any interest in helping with this?

[kojiishi]

+1, I'm interested in this in Blink. /cc @yosinch

[nixkuroi]

I recommend also adding "no-punctuate" option, bringing options to off|on|no-punctuate.

No-punctuate would imply that autocorrect is on, but removes the sometimes tedious problem of removing punctuation whenever two spaces are pressed.

Currently, to disable this behavior, it's all or nothing at the OS level (detailed here: http://osxdaily.com/2012/07/03/stop-the-period-automatically-typing-in-ios/)

[dtapuska]

Blink supports this on HTMLElement although the value isn't in the IDL; it is queried on the focused element.. See https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/editing/ime/InputMethodController.cpp?type=cs&l=1342

I support getting this spec'd. "on" and "off" are the only attribute values Blink supports (which appears to be case sensitive so there are likely some changes to Blink)

[jfbrennan]

Anyone know if an autoselect attr - selects input, textarea value upon focus, deselects on blur, probably applies to contenteditable elements as well...? Has this been considered?

Ready to get started if there isn't already work being done.

[annevk]

@jfbrennan that's probably best discussed in a separate issue. There's nothing on file that I know of.

[jfbrennan]

@annevk yes, will do. Thanks

[jfbrennan]

#3627, would appreciate feedback and sorry @rniwa for intruding here ;)

[Jokero]

Autocorrect was working in blink (android) some time ago https://bugs.chromium.org/p/chromium/issues/detail?id=303883, but not now https://bugs.chromium.org/p/chromium/issues/detail?id=901839.
Maybe it was accidentally broken

[othermaciej]

We are about to add autocorrect to Mac Safari, since we found it is required for compatibility with Twitter for any browser that does autocorrection. Mac Safari might be the only browser to currently do so by default (following macOS platform convention).

We're interested in getting this attribute into the spec if there is still multi-implementer interest. What is specifically needed for a concrete proposal?

[domenic]

A spec PR would be ideal. spellcheck might be a useful precedent to align with, especially given how it has default states. autocapitalize is more recent and simpler in some ways (despite its many states), so probably also worth looking at.

[annevk]

The other thing that's needed is tests, as per https://whatwg.org/working-mode#changes. (Suspect Maciej is aware of this, but others might not be.)

[othermaciej]

Someone from the WebKit team is looking at putting together a PR along the lines Domenic suggested, and I let them know that tests will also be expected for the PR to be approved,

[r12a]

It's probably useful for content authors to turn off autocorrection for certain contexts, but iiuc the spec also will allow them to turn it on.

In that case, how is the relationship between language/orthography and autocorrection handled? For example, i wouldn't want my input of centre to be corrected to center, and as someone who works with more than one language i often struggle with search and text autocorrectors that don't even give me a choice to confirm a correction.

Should the HTML spec have any text to indicate that autocorrection, if turned on, must take into consideration the language of the text around the form element? Would it make sense to go further, like CSS does for hyphenation, to say that it only works if a language is declared?

Also, on a slightly different tack, should the spec allow or allude to a need for users to override the settings of the content author (eg. turn off AC if it is producing problems)?

[rniwa]

It's probably useful for content authors to turn off autocorrection for certain contexts, but iiuc the spec also will allow them to turn it on.

In that case, how is the relationship between language/orthography and autocorrection handled? For example, i wouldn't want my input of centre to be corrected to center, and as someone who works with more than one language i often struggle with search and text autocorrectors that don't even give me a choice to confirm a correction.

Should the HTML spec have any text to indicate that autocorrection, if turned on, must take into consideration the language of the text around the form element? Would it make sense to go further, like CSS does for hyphenation, to say that it only works if a language is declared?

Also, on a slightly different tack, should the spec allow or allude to a need for users to override the settings of the content author (eg. turn off AC if it is producing problems)?

FWIW, iOS implementation doesn't turn off autocorrection if the user had manually turned it off. See the proposed spec text at whsieh@3214ff2#diff-36cd38f49b9afa08222c0dc9ebfe35ebR74483:

The user agent is permitted to automatically correct spelling errors while the user types. Whether spelling is automatically corrected while typing left for the user agent to decide, and may depend on the element as well as the user's preferences.

[zcorpan]

There's a concrete proposal now in #5841 , so removing the needs concrete proposal label.

Adding document conformance since this addition will need implementation in conformance checkers (@sideshowbarker) and impacts documentation (@whatwg/documentation).