Add the autocorrect attribute to the HTML spec.

[whsieh]

Issue: #3595

• At least two implementers are interested (and none opposed):
  • WebKit
  • Blink
• Tests are written and can be reviewed and commented upon at:
  • Add tests for the autocorrect attribute. web-platform-tests/wpt#25073
• Implementation bugs are filed:
  • Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=1373493
  • Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1794629
  • Safari: https://bugs.webkit.org/show_bug.cgi?id=151019 (macOS only, iOS already supported previously) & https://bugs.webkit.org/show_bug.cgi?id=246344 (remaining test failures)

---

/acknowledgements.html ( diff )
/dom.html ( diff )
/form-elements.html ( diff )
/forms.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/input.html ( diff )
/interaction.html ( diff )

[othermaciej]

@whsieh to pass the participation check, you need to make your membership in https://github.com/apple-whatwg publicly visible.

[whsieh]

@whsieh to pass the participation check, you need to make your membership in https://github.com/apple-whatwg publicly visible.

Done, thanks!

[annevk]

This looks great, thanks!

I think it would be good if @kojiishi and @dtapuska took a look as well to see if it matches their expectations.

[mtrootyy]

1. The following sentence should be added.

User agents can support autocorrection of editable text, either in form controls (such as the value of textarea elements), or in elements in an editing host (e.g. using contenteditable).

Because it is difficult that all user agents support autocorrection of all natural language.
There are similar sentence in the section of "Spelling and grammar checking". (https://html.spec.whatwg.org/multipage/interaction.html#spelling-and-grammar-checking)

2. The following sentence should be added.

The autocorrect attribute never causes autocorrection to be enabled for input elements whose type attribute is in one of the URL, E-mail, or Password states.

Because autocorrection interfere with input or editing on input elements whose type attribute is in one of the URL, E-mail, or Password states.
Correct spelling as a natural language is not required on input elements whose type attribute is in one of the URL, E-mail, or Password states.
There are similar sentence in the section of "Autocapitalization". (https://html.spec.whatwg.org/multipage/interaction.html#autocapitalization:attr-autocapitalize-4)

[whsieh]

Thank you for the comments, @annevk and @mtrootyy!

I've updated the pull request accordingly, and will add a new subtest to the accompanying web-platform-tests PR that will cover autocorrection in password, email and URL fields.

[domenic]

Looking good; thanks so much for working on this!

Most comments are editorial, but there's one potentially substantial issue in the processing model, related to presence/absence of the attribute vs. its on/off state.

[annevk]

I have tried to take care of the remaining comments. I left two questions, one for @whsieh and one for @domenic. I haven't looked at whether the tests deal with the autocapitalize-and-autocorrect-inheriting elements.

[annevk]

@whsieh one more question. Why does this specifically check for the empty string? Is that not handled by the missing value default? Is the intent here that <input autocorrect form=x><form id=x autocorrect=no></form> results in no?

[whsieh]

@whsieh one more question. Why does this specifically check for the empty string? Is that not handled by the missing value default? Is the intent here that <input autocorrect form=x><form id=x autocorrect=no></form> results in no?

...that's a good question. I think I was just trying to be consistent with the behavior of the autocapitalize attribute (and state), though for autocorrect it probably makes more sense to default to "on".

[annevk]

Okay, I guess I don't care too strongly.

Another oddity I noticed is that autocapitalize doesn't return the used concept, but autocorrect does. That seems more useful so I suggest we keep that. Perhaps it's worth a note over in autocapitalize or someone more ambitious than me could try to clean it up.

[domenic]

Can we be sure that the case @annevk mentioned is tested? The tests do look pretty comprehensive, so maybe it is already :)

[annevk]

Both are tested as far as I can tell and match the current text.

[r12a]

Should autocorrection be language-dependent? How does the browser know which dictionary to use to look up words, and does it alter its triggers for lookup for a script that doesn't use spaces, such as Chinese or Japanese or Thai (the latter has spaces but for phrase separation, rather than word), or for scripts that use different punctuation marks than English? Is it able to tell which language a user is using when they fill in form fields if that user fills in forms in more than one language?

[annevk]

Much like with autocapitalization, this does not attempt to define how autocorrection works. It merely acknowledges that it's a feature of input methods such as virtual keyboards that at times is useful to disable.

[domenic]

Thanks for picking this back up! What's the reason for not using the same behavior of inheriting from the editing host as autocapitalize does?

[domenic]

Should this use "may" and "must not"?

[annevk]

I used should not as this is about UI.

[domenic]

Can we be sure that the case @annevk mentioned is tested? The tests do look pretty comprehensive, so maybe it is already :)

[annevk]

What's the reason for not using the same behavior of inheriting from the editing host as autocapitalize does?

I'm not sure, but note that autocapitalize doesn't reflect this in its getter. It's non-script-observable behavior. So in that sense we could always change this later if it turns out to be a problem. (The autocapitalize getter is worse in that it does not acknowledge URL, Email, and Password controls either. That might be something we want to try to fix, but that getter is even older so it might be high risk for little reward.)

@whsieh thoughts?

[smaug----]

How would a webpage know whether autocorrection is supported by the UA or not? Site might provide its own correction as a fallback.
I could imagine that on less common OSes and especially when using less common languages autocorrection isn't always available.
I guess there are similar issues with spellchecking too though.

[annevk]

Yeah that would apply to spellchecking and autocapitalization as well. I could see two options:

1. Don't expose these features. (As long as you can fingerprint the OS this should not add to the fingerprinting surface.)
2. Add some kind of supports() thing. (Per rationale above should also not add to the fingerprinting surface.)

I'm not sure we should do either until it becomes a concrete problem for someone though as there's also a question to what extent web developers would care about less common OSes.