28228 2015-03-16 16:54:05 +0000 Specify the autocapitalize attribute 2017-12-08 22:13:46 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other All RESOLVED MOVED https://www.w3.org/Bugs/Public/show_bug.cgi?id=28747 P3 normal Unsorted 1 philipj ian annevk d ehsan eoconnor florian ian jonas js_choi mike mounir T.J.Hunt w3bugs contributor oldest_to_newest 118624 0 philipj 2015-03-16 16:54:05 +0000 Mounir Lamouri's proposal: https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md The autocapitalize attribute is already shipping in Safari and there's an Intent to Implement and Ship for Blink: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/zF8dao594fs Recent discussion on the WHATWG list: https://lists.w3.org/Archives/Public/public-whatwg-archive/2015Mar/thread.html#msg22 Bug 12409 is an earlier (rejected) request for the same feature, but that bug is for the HTML WG and so won't end up on Ian's table. 118626 1 philipj 2015-03-16 17:14:37 +0000 Feedback copied from blink-dev so that it isn't lost: The only issue I can see is in the minutiae of the states and reflection. Making the invalid value default depend on the input element state is atypical, a quick grep of the HTML spec and I can't find any other such case. Judging by WebKit's source [1] they ignore the input type for purposes of reflection. Can we do the same, and just ignore the autocapitalize attribute for input types other than text or search? [1] https://trac.webkit.org/browser/trunk/Source/WebCore/html/Autocapitalize.cpp?rev=160733 118652 2 mounir 2015-03-17 13:57:35 +0000 I would be fine in dropping support for non text/search fields given that, as far as I can tell, Safari iOS doesn't support other fields, neither does Chrome Android WIP implementation (because of Android keyboard ignoring those hints for email/url/password fields - I would bet Safari iOS doesn't for the same reasons). However, it means that the IDL attribute will return "sentences" for those types which sound a bit odd if not misleading. If that's something everyone here is fine with, I will be glad to update the proposal and my WIP implementation if that's the case. 119989 3 T.J.Hunt 2015-04-29 11:11:42 +0000 When considering this, please consider contentEditable as well as input and textarea. Thanks. 120110 4 ian 2015-05-05 21:41:39 +0000 I don't understand why this isn't just part of inputmode="". What's the use case? 120115 5 T.J.Hunt 2015-05-05 22:56:09 +0000 Thanks for considering this. I don't know why Apple invented autocapitalize when inputmode is something available in the standard. I also don't know why my Google searching for an answer to my use case only found discussion of autocapitalize, not inputmode, possibly because no browsers implement inputmode yet. I do know that I need whatever attribute to work for contentEditable, not just input. I note that inputmode does not work for textarea either, which seems an unnecessary omission. To answer you actual question: my specific use case is a simple text input widget for online scientific quizzes, so users can easily enter answers like x², 3x10⁸, H₂O, or SO₄^2-. Obviously there is JavaScript involved there, but some unwanted things that iOS does in contentEditable regions are proving hard to circumvent. 120136 6 mounir 2015-05-06 15:49:36 +0000 FWIW, Apple implemented autocapitalize years before inputmode was even a thing in HTML. 120220 7 philipj 2015-05-07 08:07:05 +0000 Safari has had autocapitalize for a long time and it's used on lots of websites, so I think it makes sense to just accept it as a standard and implement it everywhere. To me that seems far more likely to result in interop than hoping that WebKit would remove it. If autocapitalize is a strict subset of inputmode then it would of course be ideal to specify them both on top of shared concepts. Looking at https://html.spec.whatwg.org/#input-modalities:-the-inputmode-attribute I can't see a 1:1 mapping. I think this is the closest approximation: autocapitalize="none" => inputmode="verbatim" autocapitalize="characters" => ??? autocapitalize="words" => inputmode="latin-name" autocapitalize="sentences" => inputmode="latin-prose" 123029 8 annevk 2015-09-02 09:55:44 +0000 For autocapitalize="characters" is Unicode uppercase used or ASCII uppercase? Should we just invent a new inputmode that means the same thing? 123030 9 philipj 2015-09-02 10:06:53 +0000 (In reply to Anne from comment #8) > For autocapitalize="characters" is Unicode uppercase used or ASCII > uppercase? Should we just invent a new inputmode that means the same thing? I think only Unicode uppercase would make sense, otherwise I'd get to see silly things like JäGENSTEDT from time to time. As for inputmode, the problem is that autocapitalize has already shipped and is used in the wild, so supporting that will have a quick payoff. 123031 10 annevk 2015-09-02 10:10:39 +0000 I meant that if inputmode="" is going to be the mechanism through which we support this "new" attribute, we would need a new keyword for Unicode uppercase. 123033 11 philipj 2015-09-02 11:59:12 +0000 Hmm, right. It's not strictly necessary to expose that new mode via inputmode, but it would make sense. It's hard to come up with a name that fits with the existing ones, they're mostly more semantic than "uppercase". Mounir, how do you mean to implement autocapitalize=characters, what does it map to on the platform? 123034 12 mounir 2015-09-02 12:52:09 +0000 autocapitalize isn't meant to force capitalization. It's a hint to the virtual keyboard. In Chrome's implementation, it's simply telling the virtual keyboard to show uppercase characters. The user is allowed to go back to lower case ones obviously. 123035 13 philipj 2015-09-02 13:02:08 +0000 (In reply to Mounir Lamouri from comment #12) > autocapitalize isn't meant to force capitalization. It's a hint to the > virtual keyboard. In Chrome's implementation, it's simply telling the > virtual keyboard to show uppercase characters. The user is allowed to go > back to lower case ones obviously. I see. Do you think that an inputmode corresponding to autocapitalize=characters would make sense and if so what should it be called? 123058 14 mounir 2015-09-03 11:12:07 +0000 I'm not sure why it should be called anything different. 123059 15 philipj 2015-09-03 12:24:04 +0000 (In reply to Mounir Lamouri from comment #14) > I'm not sure why it should be called anything different. Do you mean it should be called inputmode=capitalize? 123072 16 mounir 2015-09-04 09:28:48 +0000 Out of curiosity, what's the rationale for introducing inputmode and how would that be different from autocapitalize? 123073 17 annevk 2015-09-04 09:32:51 +0000 See https://html.spec.whatwg.org/#attr-fe-inputmode for how it's a rough superset in terms of functionality. 123074 18 philipj 2015-09-04 09:55:10 +0000 See also comment #7. If we're further away from a mapping than it seems, then it may not be a good idea to try to build both on the same concepts. 123083 19 jonas 2015-09-04 15:14:45 +0000 Wasn't a large part of the reason for using 'autocapitalize' that it was used by lots of websites out there, and has lots of developer mindshare? I.e. that it's already a cowpath that we should pave. 123084 20 annevk 2015-09-04 15:17:46 +0000 Jonas, we should specify this attribute. The question is whether we should specify it in terms of inputmode, and if so, if inputmode should have a new value. 123098 21 mounir 2015-09-05 13:17:18 +0000 Given that inputmode isn't really implemented, I wonder if it would be better to not make autocapitalize depending on it (even if it is only editorial). 123106 22 jonas 2015-09-05 22:40:42 +0000 If we have autocapitalize=characters, then why would we also implement an inputmode which has the same behavior? 123128 23 philipj 2015-09-08 08:09:43 +0000 (In reply to Jonas Sicking from comment #22) > If we have autocapitalize=characters, then why would we also implement an > inputmode which has the same behavior? It looks like the other three autocapitalize modes do map to an inputmode. That being said, actually getting autocapitalize spec'd is more important than whether or not it's a subset of inputmode. 123129 24 jonas 2015-09-08 14:39:33 +0000 (In reply to Philip Jägenstedt from comment #23) > It looks like the other three autocapitalize modes do map to an inputmode. Have those inputmode's been shipping in any implementations? If not, can we strike them from the spec? 123137 25 philipj 2015-09-09 09:40:41 +0000 (In reply to Jonas Sicking from comment #24) > (In reply to Philip Jägenstedt from comment #23) > > It looks like the other three autocapitalize modes do map to an inputmode. > > Have those inputmode's been shipping in any implementations? If not, can we > strike them from the spec? I'm not sure. They are handled in Chromium [1] but in some ad-hoc testing I can't make them actually do anything. I'll ask the people who wrote the code. [1] https://code.google.com/p/chromium/codesearch#chromium/src/content/renderer/render_widget.cc&sq=package:chromium&type=cs&l=127&rcl=1441754958 123139 26 mounir 2015-09-09 10:47:13 +0000 Chromium does not support inputmode. 123149 27 philipj 2015-09-10 08:44:34 +0000 (In reply to Mounir Lamouri from comment #26) > Chromium does not support inputmode. I've asked those who wrote the code linked in comment #25, and apparently there is some limited support for 'kana', 'katakana', and 'full-width-latin', while all other modes "turns the IME to keyboard-direct alphabet input mode". In other words, with no real support for 'verbatim', 'latin-name' and 'latin-prose', I see no strong reason for trying to define autocapitalize in terms of inputmode. We could probably remove the overlapping modes from inputmode. Or remove inputmode entirely, if there's no implementor interest. 123151 28 mounir 2015-09-10 10:48:39 +0000 Note that my understanding is that the implementation is behind a flag on Windows. Should we have an attribute for scripts/alphabets hinting? 123154 29 jonas 2015-09-10 15:38:17 +0000 I suspect that 'inputmode' is still useful. I don't know enough to assert that "kana" and "katakana" modes are useful, but my impression is that they are. Similarly I think that a "numeric" inputmode would be good (for things like zipcode and credit card numbers). Of course, these things don't have to be implemented using inputmode, but I don't know of strong reasons not to. 123170 30 mounir 2015-09-11 10:28:36 +0000 I'm not a big fan of mixing scripts/alphabets with inputmode. For example, what happens if I have a text field in which I would like my users to type a roman characters number like MDCCCCX instead of 1910. A more common use case might be arabic websites. Arabic has its own numeral charocters (1910 => ۱۹۱۰) but all the arab world knows and uses the hindu-arabic system we use in the latin alphabet. I can imagine that there would be cases where one set of characters would be prefer over the other? 129006 31 js_choi 2017-12-08 22:10:34 +0000 Work on the autocapitalize attribute is now occurring at the WHATWG HTML GitHub repository (https://github.com/whatwg/html/pull/3273). 129007 32 d 2017-12-08 22:13:46 +0000 Thanks J.S.! I'll mark this as moved to https://github.com/whatwg/html/pull/3273 then.