[Webkit-unassigned] [Bug 179133] New: Behavior of autocapitalize attribute with no value does not match documentation in Safari HTML Reference

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=179133

            Bug ID: 179133
           Summary: Behavior of autocapitalize attribute with no value
                    does not match documentation in Safari HTML Reference
           Product: WebKit
           Version: Safari 11
          Hardware: iPhone / iPad
                OS: iOS 11
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: HTML Editing
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: rlanday at chromium.org
                CC: wenson_hsieh at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20171101/afa71725/attachment.html>