- From: Ian Hickson <ian@hixie.ch>
- Date: Wed, 22 Jan 2014 00:54:47 +0000 (UTC)
- To: Yoichi Osato <yoichio@google.com>, "Michael[tm] Smith" <mike@w3.org>, Takayoshi Kochi (河内 隆仁) <kochi@google.com>, Ryosuke Niwa <rniwa@apple.com>
- Cc: WHAT Working Group <whatwg@lists.whatwg.org>
- Message-ID: <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com>
On Fri, 6 Dec 2013, Yoichi Osato wrote: > > Our Google Japan members working around IME discussed about inputmode. > > Proposal: > 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 queries - 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 other scripts 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 to provide. 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 > comments.] 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)? > https://www.w3.org/Bugs/Public/show_bug.cgi?id=23961 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 > prediction". > > 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. `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 22 January 2014 00:55:12 UTC