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.