[whatwg] inputmode feedback
ian at hixie.ch
Tue Jan 21 16:54:47 PST 2014
On Fri, 6 Dec 2013, Yoichi Osato wrote:
> Our Google Japan members working around IME discussed about inputmode.
> Remove "kana", "katakana" and "full-width-latin" from inputmode attribute.
> Because above attributes and others are independent as others say.
I don't really understand. What is independent?
The idea of the inputmode="" attribute is that it gives the mode that is
most likely to be needed by the user when providing input. There's various
modes that seem to make sense:
- inserting raw latin-script characters, like passwords, product codes
- inserting human-readable latin-script short-form text, like search
- inserting human-readable latin-script human names
- inserting human-readable latin-script long-form text, like blog posts
- inserting numeric data, like credit card numbers
- inserting text in other scripts, of which I know nothing
- inserting human-readable latin-script text within long-form text in
You don't use the same kind of keyboard for inserting raw latin-script
characters as for inserting Japanese long-form prose, so it makes sense to
me that they'd use different input modes.
Why is this wrong?
> For web developers that want to manage IME state like native
> applications, the inputmode attribute lacks some modes like
> "half-width-katakana". But it might cause more confusing to add such
> attributes to inputmode.
I'm not sure exactly what you mean by "manage IME state like native
applications". Can you elaborate? Do you mean provide custom IMEs? Do you
mean have low-level control over the specific keyboard or other input
facilities provided by the OS?
The idea here is to provide no low-level control, but to give high-level
hints to the browser, as with everything else in HTML. This is how we
achieve device- and platform-independence.
> We are discussing to propose IME mode management as new API. Its mode
> contains "alphabet, kana, katakana, full-width-latin,
> harf-width-katakana" as a native OS provides.
This seems like a lower-level feature than what inputmode="" is intended
On Fri, 6 Dec 2013, Michael[tm] Smith wrote:
> [Maybe we should take this discussion off-list or talk about it some
> time soon over lunch or something. For now though, here are some
I very much encourage people to discuss this on this list, as that is a
great way for me (and others) to learn about this stuff. :-)
On Mon, 9 Dec 2013, Takayoshi Kochi (河内 隆仁) wrote:
> Probably the reason some Japanese banks still use half-width kana is
> what Ryosuke said, but as Mike saw in Mizuho and Mitsui Sumitomo, they
> are moving away from forcing user to type in half-width kana directly,
> they convert on server side - I think this is a good trend.
> Aside from banking, I guess there are still people who *want* to type in
> Japanese in half-width kana, e.g. "キター" can implicitly add some
> nuances against "キター".
> My position is that we allow end-users to type-in whatever they want,
> but server side people should try to accept users' input as widely as
> possible and validate or normalize themselves.
inputmode="" isn't intended to prevent specific input modes from being
selected by the user. Are there use cases that we want to support for
explicitly selecting half-width kana? I'm happy to add it if it is
helpful. The discussion seemed to suggest we should encourage UAs not to
support it; if that's what we want to do, I don't think we should spec it.
> The point that Yoichi wanted to make was to extract IME-related part of
> 'intputmode' spec and move out of inputmode, or at least separate the
> discussion about IME-related modes and other modes, otherwise the
> discussion will never go anywhere.
I'm not sure I understand what you consider IME-related and what is not.
Can you elaborate on this?
> How about using this bug as a starting point of the discussion (although
> it's on w3c bugzilla)?
That's a bug on the W3C HTML5 spec, so it isn't one that I'm tracking. I
encourage you to post on this list or to file a new bug if you prefer to
discuss things on a bug system: http://whatwg.org/newbug (it also uses
the W3C Bugzilla, but a different component)
> Ben Bucksh (cc'ed) pointed out in the bug entry that inputmode has at
> least 3 aspects (script/language, data type, typing aid). There is room
> for discussion whether we should split inputmode into every orthogonal
> modes, but whether we split or not, we would like to separate discussion
> whether each mode is good or not into these categories.
The inputmode="" attribute only has one aspect: what does the user want to
enter. This can impact many things, including the script, the language,
the kinds of keys that are visible, the kinds of typing aids enabled, the
source(s) of autocomplete data, and so on. There are many different
platforms that can use inputmode="": a mobile visual device might use an
on-screen keyboard or on-screen handwriting recognition widget, a desktop
computer might use a fully-fleged IME system, a speech-based system might
do everything using speech recognition and use the input mode to decide
what dictionaries to use for recognition and what scripts to use for
transcribing the results.
Exposing all these aspects to the author is a losing proposition: authors
would frequently make mistakes, forget certain classes of users or
devices, fail to test on all possible platforms, etc. The solution is to
use the high-level semantic approach used elsewhere by HTML, and thus just
provide a high-level description of the kind of input that is expected,
letting the user agent translate this into the appropriate settings for
the OS-level input system.
On Mon, 16 Dec 2013, Michael[tm] Smith wrote:
> As I commented in bug 23961, the value of the inputmode attribute was
> originally specified as taking a list of tokens, where one token is
> optionally the name of a script like "latin" and the rest of the tokens
> were optional modifiers.
> So you could imagine a value like inputmode="latin titlecase
> I'm not saying I think the use cases actually merit changing the
> inputmode microsyntax to be a list of tokens like that. But it might be
> preferable to introducing yet more attributes.
We originally had this in Wbe Forms 2.0, but it is far more complex than
necessary, IMHO. Authors don't need that level of control in the vast
majority of cases.
Ian Hickson U+1047E )¥._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. ¥ _¥ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg