Add the autocorrect attribute

[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)
• MDN: Define the autocorrect attribute as standard mdn/content#35593

---

/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.

[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?

[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.

[annevk]

Thanks for the nudge @danielhjacobs. This clearly got lost. I rebased this (again) and added commits to account for recent HTML refactoring efforts. At least as far as the bots are concerned this is now in a state where it can be merged, but I'll double check in the next WHATNOT call I can attend.

[annevk]

@smaug---- @masayuki-nakano I think this is ready now, but happy to wait a bit so you can take a look as well before it lands.

[makotokato]

As long as looking the implementations of both Blink and WebKit, it is on by default.

Someone may want on-by-default like spellcheck attribute, but it is OK for me.