This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Latin and kana are orthogonal to things like "autocorrect off". Likewise, "email" belongs in type, and is already standardized and accepted cross-browser there, but inputmode has it as well - again: orthogonal. So, the current spec has 3 or more orthogonal aspects in the same field: 1. script/language (latin, kana...) 2. data type (text, numbers, email, url) 3. typing aids 3.1. completion / text prediction 3.2. correction 3.3. capitalization 3.4. spell checking They are orthogonal, because I can have completion, correction and even capitalization for names (using the user's address book) and for text (using a dictionary). They'd use different algorithms, but still the type (name, text) is a different aspect from whether I want the computer helping my type or not. That all doesn't seem well-thought out, and Mozilla thinks so, too: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038914.html This whole definition of inputmode seems off, because in my usecase, it is actually "prose" text that the user enters. But the prose contains special abbreviations and terms that I need to recognize, and Firefox OS' autocorrect wrongly "corrects" these, too, rendering this form and app feature useless. So, I actually *do* want to say that it's "prose" text (inputmode="prose"), I just want to tell Firefox OS to get out of the way. An autocorrect="off" seems like a much better way to turn off one specific malfunctioning feature than saying inputmode="verbatim", which would disable all typing aids. I have nothing the autocomplete suggestions that Firefox OS shows in the row above the virtual keyboard, but inputmode="verbatim" disables these as well. This is why I think that autocorrect on/off/default should be a boolean (3-state) flag, which is independent from any other dimensions like language or data type.
I propose to split up the different aspects: For 1. above: * inputscript="latin"/"kana" etc. default is chosen by browser based on language of page and user. See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038914.html For 2. above: * type="email"/"url"/"text" As already specced For 3. above: * autocorrect="off" (change words that the user already typed) * autocapitalization="off" * spellcheck="off" (underline misspelled, with aids to correct on user action) * typingaids="off" (Swipe, word suggest; not changing letters the user typed) I'm not sure about this last one.
*** Bug 23953 has been marked as a duplicate of this bug. ***
Correction: > I have nothing the autocomplete suggestions ... [In this use case,] I have nothing against the autocomplete suggestions ...
(In reply to Ben Bucksch from comment #1) > I propose to split up the different aspects: > > For 1. above: > * inputscript="latin"/"kana" etc. > default is chosen by browser based on language of page and user. > See > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org//2013-February/038914. > html > > For 2. above: > * type="email"/"url"/"text" > As already specced > > For 3. above: > * autocorrect="off" (change words that the user already typed) > * autocapitalization="off" > * spellcheck="off" (underline misspelled, with aids to correct on user > action) > * typingaids="off" (Swipe, word suggest; not changing letters the user typed) > I'm not sure about this last one. Before adding any more new attributes, I think it'd be a good idea to see if the stakeholders (especially the implementors) are interested in extending the syntax of the existing inputmode attribute to allow for things like what you have in your category 3. That's actually the way that the inputmode attribute was originally specified, when it first appeared in the XForms spec, and then in the XHTML Basic spec, and then in Web Forms 2.0. The original idea was that the attribute value could contain a list of tokens: an optional script token and one more modifier tokens: http://www.w3.org/TR/2003/PR-xforms-20030801/sliceE.html#mode-modifiers So you could have value like inputmode="latin titlecase typingaids".
In fact, that's how it's currently defined. I'm saying that this is broken. It should not included orthogonally different aspects. No browser implements it, apart from Mozilla, and even Mozilla people think that's broken. I think that can count as your "implementor stakeholders'" position statement.
(In reply to Ben Bucksch from comment #5) > In fact, that's how it's currently defined. It's defined as having a value that's a single keyword, not a list of tokens.
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#input-modalities:-the-inputmode-attribute Yes, OK. I took "latin-name" as 2 tokens, but yes, it's a single keyword. I'm arguing that they shouldn't even be in the same attribute, as that will only cause confusion. Kana and autocorrect are 2 completely different concerns for page authors.
To change conversion mode like Kana and Katakana is served by platform APIs. Other functions like spell checking and capitalization is served by an browser. Web developers must concern about above 2 sided conditions to know how an user agent supports inputmode attribute.
I'm definitely interested in improving the current spec. It seems hard to understand for latin scripts, and it doesn't seem to work well for bilingual people or websites (you can't provide hints for japanese text and latin text at the same time). That said, I don't have great ideas for how to improve the current state of affairs.
Jonas, what about my comment 1?
HTML5.1 Bugzilla Bug Triage: Moved to Github issue: https://github.com/w3c/html/issues/269 To file additional issues please use the W3C HTML5 Issue tracker: https://github.com/w3c/html/issues/new Thanks!