Bug 179133 - Behavior of autocapitalize attribute with no value does not match documentation in Safari HTML Reference
Summary: Behavior of autocapitalize attribute with no value does not match documentati...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: Safari 11
Hardware: iPhone / iPad iOS 11
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-01 12:15 PDT by Ryan Landay
Modified: 2017-12-09 15:21 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Landay 2017-11-01 12:15:10 PDT
I am a Google engineer working on adding support in Chrome for Android for the autocapitalize attribute on contenteditable elements, as has been added to iOS Safari in WebKit bug 164538:
https://bugs.webkit.org/show_bug.cgi?id=164538

The Chromium tracking bug for this is:
https://crbug.com/776618

As part of this work, I'm also trying to clean up all our other behavioral differences with WebKit's autocapitalize implementation. The changes I'm planning to make are explained here:
https://docs.google.com/document/d/1pBwWacGm8GsPHCJDbJ3PZ2l1ywz_dACO3sMh5hUmD7E/edit?usp=sharing

I noticed that the Safari HTML Reference for the autocapitalize attribute:
https://developer.apple.com/library/content/documentation/AppleApplications/Reference/SafariHTMLRef/Articles/Attributes.html#//apple_ref/doc/uid/TP40008058-autocapitalize

states "If the autocapitalize attribute is present but no value is specified (as in <input autocapitalize>), the default value is sentences....For all other form controls, the default value is inherited from the enclosing form element."

This doesn't seem to match the behavior that Safari currently implements. Safari seems to effectively ignore the autocapitalize attribute when no value is specified, since it falls back to whatever the default would've been instead of actually interpreting it as if "sentences" were specified. The only case I know of where iOS Safari pays attention to the attribute (i.e., autocapitalization is supported on the element; the documentation *also* states the autocapitalize is supported on <input>s of type password with the default "none", but at least with the default iOS keyboard, autocapitalization seems to be always disabled) but the default wouldn't be sentences is when an <input> element of type "text" or "search" is inside a form with autocapitalize disabled:

<form autocapitalize="none">
    <input autocapitalize>
</form>

In this case, the <input> element essentially ignores the autocapitalize attribute with empty value and instead inherits "none".

Can you please either change the implementation to match the documentation, or (which I think probably makes more sense), update your documentation to match the implementation? We will most likely make the Chrome implementation match what you decide here.