- From: Ian Hickson <ian@hixie.ch>
- Date: Thu, 6 Jun 2013 21:08:02 +0000 (UTC)
- To: Mounir Lamouri <mounir@lamouri.fr>, Takayoshi Kochi (河内 隆仁) <kochi@google.com>, Jonas Sicking <jonas@sicking.cc>
- Cc: whatwg@lists.whatwg.org
On Wed, 13 Feb 2013, Mounir Lamouri wrote: > > To begin with, I think we should get rid of the "latin" prefix. The > three modes with that prefix are "latin", "latin-name" and "latin-prose" (Also "full-width-latin".) > but in none of those situations "latin" is mandatory. While I think it's appealing, from an abstract perspective, to view the script and mode as orthogonal here, it seems to me that in reality keyboard combine them into a single UI. I fear that separating them would lead to a lot of meaningless combinations being possible. In general, though, this is not my area of expertise and I'm happy to defer to whatever is implemented (as with anything else). (I looked at iOS and Android and considered just mapping all the values to HTML keywords, but that would have made the actual list even more complex, so I just hit the highlights.) > Mozilla's implementation also includes 'uppercase' which is a common use > case in the web and could be interesting but it isn't as important as > other types so it can be kept aside for later. The priority for us here > being to make the Web Platform competitive with native apps on Mobile. What's the difference between these two, and why is "digit" a better name for it than "numeric"? > Finally, it is not clear why 'tel', 'email' and 'url' are available. Mostly it's for letting people build custom UIs (e.g. a Web component that implements type=tel). On Fri, 15 Feb 2013, Jonas Sicking wrote: > > Using semantic names might give us the warm fuzzies, but is there really > any semantic use we will get out of these that we wouldn't by using > "lowercase", "titlecase" or "autocapitalized"? The reason I used the more "semantic" names is that the names like "lowercase", "titlecase" or "autocapitalized" aren't accurate. For example, you can hit shift in "lowercase" mode to get uppercase. You can have a "titlecase" mode that doesn't capitalise every word (e.g. it recognises the "van" in "van Kesteren"). A value that is explicitly for names can use a different dictionary than one that is just for capitalised text (e.g. derived from the user's contact list). And so on. > I take it verbatim and name would disable any spelling corrections, > and name would also titlecase? But the difference between text and > prose seems really hard to understand. In the spec, "verbatim" does not correction at all, e.g. passwords; "latin" is for human-to-computer communications, e.g. free-form text search fields, and would do spelling correction and automatically inserting spaces between words in swiping keyboards, etc; and "latin-prose" is intended for human-to-human communications, with aggressive automatic typing correction, e.g. text prediction and automatic capitalisation at the start of sentences. On Fri, 1 Mar 2013, Mounir Lamouri wrote: > > > > People may want to control IME input mode like the way Flash can, > > > > http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html > > but it it is unfortunate that controlling IME from web apps is so > > distributed (CSS, input attribute, DOM lv3 compositionevent and IME > > API). > > As I see it @inputmode isn't here to be a feature like this but maybe > Hixie had a different vision when he wrote the specs for it. inputmode="" is mainly intended to control what keyboard to use on mobile devices. > Maybe if it was named @inputhint and the user was allowed to change the > input mode, it would be clearer? Everything in HTML is a hint. The user's always in control. I haven't changed the spec for now, but as noted above, I don't a priori object to making changes, even radical changes, to this part of the spec, if they make sense. :-) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 6 June 2013 21:08:30 UTC