This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
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.
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
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.
When considering this, please consider contentEditable as well as input and textarea. Thanks.
I don't understand why this isn't just part of inputmode="". What's the use case?
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<sup>2</sup>, 3x10<sup>8</sup>, H<sub>2</sub>O, or SO<sub>4</sub><sup>2-</sup>. Obviously there is JavaScript involved there, but some unwanted things that iOS does in contentEditable regions are proving hard to circumvent.
FWIW, Apple implemented autocapitalize years before inputmode was even a thing in HTML.
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"
For autocapitalize="characters" is Unicode uppercase used or ASCII uppercase? Should we just invent a new inputmode that means the same thing?
(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.
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.
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?
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.
(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?
I'm not sure why it should be called anything different.
(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?
Out of curiosity, what's the rationale for introducing inputmode and how would that be different from autocapitalize?
See https://html.spec.whatwg.org/#attr-fe-inputmode for how it's a rough superset in terms of functionality.
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.
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.
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.
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).
If we have autocapitalize=characters, then why would we also implement an inputmode which has the same behavior?
(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.
(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?
(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
Chromium does not support inputmode.
(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.
Note that my understanding is that the implementation is behind a flag on Windows. Should we have an attribute for scripts/alphabets hinting?
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.
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?
Work on the autocapitalize attribute is now occurring at the WHATWG HTML GitHub repository (https://github.com/whatwg/html/pull/3273).
Thanks J.S.! I'll mark this as moved to https://github.com/whatwg/html/pull/3273 then.