Re: [whatwg] inputmode feedback
On Mon, 3 Feb 2014, Michael[tm] Smith wrote: > Ian Hickson , 2014-01-22 00:54 +: > > > > 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? > > I personally think it's not wrong. Well, mostly not wrong, at least (see > below for what I think is one specific, fixable problem.) But I believe > one objection that others have made to the current set of modes is that > for Latin input it provides values that conflate typing-aids hints with > the script hint, while for Japanese input, it does not. Well, nobody has suggested that there are any typing aid hints applicable to Japanese input yet. The current list for Japanese (and all non-Latin- script languages) are just the list of input modes people told me were needed (since nobody has asked for anything for anything but Japanese and Latin-script languages, there's nothing for those). > That means there's at least one possibly-useful mode that inputmode > currently does make expressible: a "name" mode for kana input (to > correspond to the latin-name mode). Added. > What I mean is, what value would an author choose if they wanted to > indicate a mode for inserting human-readable kana-input human names? As of now, "kana-name". > Asking that question makes me realize that we probably don't actually > want a "-name" mode for the contact-list case anyway -- because a > Japanese user is likely to have a contact list that contains names both > in Kanji and in Latin characters. So if we really want to provide "text > prediction from the user's contact list", I think we'd probably want to > just add an script-less inputmode=contact value for that. If there was going to be a "keyboard" that consisted primarily of a contact list, I'd agree. But the keyboard will be a keyboard, and it'll autocomplete from a contact list. And thus that keyboard needs a default mode to be in. If all my friends have Latin-script names, it is inconvenient if the keyboard starts with a Russian keyboard. I presume, based on what you suggested above, that a Japanese user would find it more helpful if their keyboard started in a mode for "kana or romaji input, typically hiragana input". > Also, there are things other than human names for which namecase (aka > titlecase) is useful: For example, a field where the user is expected to > type in a book title or movie title. For those kinds of fields, you > clearly wouldn't want "text prediction from the user's contact list" > turned on also. Instead you'd just want it to be inputmode=titlecase. If users actually want auto-title-casing, then yes, we could introduce a "latin-title-case" mode, or something like that. Do they? I haven't heard of a request for this so far. > Anyway, I think the root problem might be that we have > inputmode=latin-name to begin with. I don't understand why it's a problem. > So I'd suggest either dropping it entirely, or replacing it with the two > new values inputmode=titlecase and inputmode=contact. That wouldn't give the UA the information the UA needs to pick the right keyboard. > And as far as using inputmode for specifying typing aids instead of just > script, I don't what other kinds of typing aids (other than the contact > case) would be relevant for Japanese input. The main typing aids the > spec mentions are autocapitalization, autocorrect, and text prediction. > Among those, capitalization isn't relevant for Japanese input at all. > And as far as autocorrect, in my experience at least, autocorrect isn't > a feature that's commonly used anywhere with IMEs for Japanese input, so > it's not relevant. And as far as text prediction, in Japanese IMEs text > prediction is always turned on anyway, and I can't think of cases where > a user would really care to have it turned off (or be bothered by having > it on). Right, each script has different needs. That's why these are not orthogonal concerns; they're input modalities. I don't know anything about what input modalities are needed outside of Latin script keyboards, so I rely on
Re: [whatwg] inputmode feedback
Ian Hickson , 2014-01-22 00:54 +: > 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? I personally think it's not wrong. Well, mostly not wrong, at least (see below for what I think is one specific, fixable problem.) But I believe one objection that others have made to the current set of modes is that for Latin input it provides values that conflate typing-aids hints with the script hint, while for Japanese input, it does not. That means there's at least one possibly-useful mode that inputmode currently does make expressible: a "name" mode for kana input (to correspond to the latin-name mode). What I mean is, what value would an author choose if they wanted to indicate a mode for inserting human-readable kana-input human names? It's true there's no capitalization in Japanese names (as there is with Latin names), so if all that the -name value indicated was namecase autocapitalization, we wouldn't need a kana-name value. But a UA could use the latin-name mode for more than just turning on namecase autocapitalization. For example, the spec notes that the mode could trigger "text prediction from the user's contact list". So what would an author do if they if they wanted a mode that signals both kana input and "text prediction from the user's contact list"? Asking that question makes me realize that we probably don't actually want a "-name" mode for the contact-list case anyway -- because a Japanese user is likely to have a contact list that contains names both in Kanji and in Latin characters. So if we really want to provide "text prediction from the user's contact list", I think we'd probably want to just add an script-less inputmode=contact value for that. Also, there are things other than human names for which namecase (aka titlecase) is useful: For example, a field where the user is expected to type in a book title or movie title. For those kinds of fields, you clearly wouldn't want "text prediction from the user's contact list" turned on also. Instead you'd just want it to be inputmode=titlecase. Anyway, I think the root problem might be that we have inputmode=latin-name to begin with. So I'd suggest either dropping it entirely, or replacing it with the two new values inputmode=titlecase and inputmode=contact. And as far as using inputmode for specifying typing aids instead of just script, I don't what other kinds of typing aids (other than the contact case) would be relevant for Japanese input. The main typing aids the spec mentions are autocapitalization, autocorrect, and text prediction. Among those, capitalization isn't relevant for Japanese input at all. And as far as autocorrect, in my experience at least, autocorrect isn't a feature that's commonly used anywhere with IMEs for Japanese input, so it's not relevant. And as far as text prediction, in Japanese IMEs text prediction is always turned on anyway, and I can't think of cases where a user would really care to have it turned off (or be bothered by having it on). Come to think of it, in soft keyboards on smartphones for Latin input too, text prediction is always on anyway. So maybe these days there's not much of a real need to provide a hint for a "text prediction on" typing aid -- because "text prediction on" is the default anyway. Maybe instead there's now more of a need for a "text prediction off" typing aid, I dunno. > 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
Re: [whatwg] inputmode feedback
On Mon, 27 Jan 2014, Takayoshi Kochi (河内 隆仁) wrote:
> On Wed, Jan 22, 2014 at 9:54 AM, Ian Hickson wrote:
>
> Japanese IME (e.g. Microsoft IME) has several modes for typing
> characters, divided by the category of the set of characters (kana,
> half-width-kana, alphanumeric, full-width-latin etc.), each of which has
> different purpose for representing things (e.g. imported words or
> computer programs are written in alphabets, while other Japanese text is
> written in kana and kanji, converted from kana using IME) and switching
> these submodes are critical part of (at least desktop) IMEs to
> efficiently type text with several of these sets of characters with
> alphabet-only physical keyboard. These modes are actually sub-modes of a
> specific language (Japanese) IME.
This sounds similar to how it works for Latin scripts, where for instance
you might have one mode for entering numbers and one mode for entering
text and one mode for entering URLs.
> Take a look at a Japanese blog post e.g.
> http://googlejapan.blogspot.jp/2014/01/google-chrome.html You can see
> alphabets, numbers and other Japanese characters (hiragana, katakana,
> kanji) are all used in one entry.
This again is similar to how in Latin script prose you might find segments
with URLs, others with tables of numbers, and others with text, all
combined into one document.
> So for completing the feature parity for Japanese web users against
> native applications, these modes has importance but we think inputmode
> is not an appropriate place to put it on.
Given how identical they sound to the latin script features exposed by
inputmode="", I don't understand why inputmode="" would be the wrong place
for this. It sounds eminently applicable.
> For one thing, such Japanese IME submodes are dynamic by nature (user
> can move from one to another with some key combinations or via IME
> menu). When user move focus from one field to another, the submode is
> persistent.
This is an implementation detail, right? I mean, if a user wanted to
create a platform where the IME defaulted back to kana whenever a new
control was focused, that wouldn't be wrong, it would just be a choice
they would have to implement, no?
> E.g. You have a form:
>
> Zip: [] <- alphanumeric
> Address: [] <- kanji (kana)
> Building: [] <- kanji (kana), and maybe numeric for building/room number
> etc.
> Name: [] <- kanji (kana)
> Tel: [] <- number
>
> Without any inputmode or alike, you start from zip code, you turn off
> IME (if it's on) and type in zip code, then press tab to the next field,
> IME is still off, you turn on IME to fill address, type in building and
> name. At the Tel field, you have to turn off IME (or change IME submode
> to "half-width-latin") manually, because the IME submode (at this point,
> most probably in "kana" mode) persists.
Right. This is the kind of thing we're trying to solve.
It's identical to the same problem in Latin script pages: you'd start from
the ZIP code, switch to "digit" mode, type in the ZIP code, tab to the
Address field, switch back to text mode, type that in, etc. At the Tel
field, you'd have to switch back the "digit" mode.
With inputmode="", we avoid this; the ZIP field starts in numeric mode,
the Tel field starts in a dedicated Telephone mode, the Name field
starts in the text mode but with automatic capitalisation since names in
Latin text are usually capitalised, etc.
> If "inputmode" has these Japanese IME submodes (it does), users can save
> switching modes manually when hopping from one field to another. Usually
> Japanese users are accustomed to changing these modes manually, so if
> the mode changes automatically, it may cause a surprise, but use cases
> such as inputting a lot of entries for address book repetitively, it
> would save the mode switching much.
Right, that's the idea.
> That said, though inputmode is useful to declaratively write the
> "default" expected submode for the field to be initially in, once user
> manually change the mode from the initial submode, it is not apparent
> how should the browser behave when user re-focus that field? Browser
> implementer can have several choices here:
>
> 1. Change the IME mode to what is specified as "inputmode".
> 2. Remember the last mode when the focus was there and restore the mode.
> 3. Do nothing, if the mode of the field manually changed to something else.
> 4. none of the above(?)
Same as with latin script input modes, right.
This is an implementation choice. Personally I would recommend restoring
whatever input mode was used when the user last had that field focused,
resetting when the page is reloaded. But you can do things more or less
clever here, or have it configurable, or whatever you want.
The idea, in HTML, is to provide hints to the user agent so that the user
agent can use the information about the page ("this is a numeric field",
"this is for a Latin name", "this is for kan
Re: [whatwg] inputmode feedback
Hi Ian, On Wed, Jan 22, 2014 at 9:54 AM, Ian Hickson wrote: > 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? > As you noted below, "kana" "katakana" "full-width-latin" are low-level mode details of specific language (Japanese) input method. Probably we can move these 3 modes from inputmode and make such low-level mode change available under IME API (http://www.w3.org/TR/ime-api/). 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? Usually such traits for an input field persists statically, while the modes above are dynamic one and have to explicitly modify the state of system IME. > 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? > Japanese IME (e.g. Microsoft IME) has several modes for typing characters, divided by the category of the set of characters (kana, half-width-kana, alphanumeric, full-width-latin etc.), each of which has different purpose for representing things (e.g. imported words or computer programs are written in alphabets, while other Japanese text is written in kana and kanji, converted from kana using IME) and switching these submodes are critical part of (at least desktop) IMEs to efficiently type text with several of these sets of characters with alphabet-only physical keyboard. These modes are actually sub-modes of a specific language (Japanese) IME. Take a look at a Japanese blog post e.g. http://googlejapan.blogspot.jp/2014/01/google-chrome.html You can see alphabets, numbers and other Japanese characters (hiragana, katakana, kanji) are all used in one entry. Native windows applications of course have control over such modes per input focus, and Flash (ActionScript) has similar functionality. http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/system/IME.html#conversionMode (I'm not familiar with Korean/Chinese, but from the Flash spec above, they only have IME on or off, they don't have sub-modes like Japanese - please correct me if I'm wrong). So for completing the feature parity for Japanese web users against native applications, these modes has importance but we think inputmode is not an appropriate place to put it on. For one thing, such Japanese IME submodes are dynamic by nature (user can move from one to another with some key combinations or via IME menu). When user move focus from one field to another, the submode is persistent. E.g. You have a form: Zip: [] <- alphanumeric Address: [] <- kanji (kana) Building: [] <- kanji (kana), and maybe numeric for building/room number etc. Name: [] <- kanji (kana) Tel: [] <- number Without any inputmode or alike, you start from zip code, you turn off IME (if it's on) and type in zip code, then press tab to the next field, IME is still off, you turn on IME to fill address, type in building and name. At the Tel field, you have to turn off IME (or change IME submode to "half-width-latin") manually, because the IME submode (at this point, most probably in "kana" mode) persists. If "inputmode" has these Japanese IME submodes (it does), users can save switching modes manually when hopping from one field to another. Usually Japanese users are accustomed to changing these modes manually, so if the mode changes automatically, it may cause a surprise, but use cases such as inputting a lot of entries for address book repetitively, it would save the mode switching much. That said, though inputmode is useful to declaratively write the "default" expec
Re: [whatwg] inputmode feedback
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
Re: [whatwg] inputmode feedback
[trimming the Cc list, assuming everybody's subscribed to whatwg@lists.whatwg.org] "Takayoshi Kochi (河内 隆仁)" , 2013-12-09 16:18 +0900: ... > 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. > > 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 > > 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. 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. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: [whatwg] inputmode feedback
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. 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. 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 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. On Sat, Dec 7, 2013 at 5:47 AM, Ryosuke Niwa wrote: > > On Dec 6, 2013, at 5:30 AM, 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.] > > > > "Takayoshi Kochi (河内 隆仁)" , 2013-12-06 19:53 +0900: > > > >> Just for a data point, lots of Japanese banks still make user type in > >> half-width katakana. > > > > OK, but anecdotally my limited experience as a user with Japanese bank > > sites is that the ones I use (Mizuho and Mitsui Sumitomo) don't require > > half-width katakana input anywhere. > > > > Anyway, as I guess you know, bank sites as a class (along with airline > > sites) are notorious for doing a lot of stupid things that are really bad > > for user experience -- to the point where I think bank sites as a class > > should really be considered a counter-example of good design. > > > >> Here are some random examples: > >> > >> http://www.tominbank.co.jp/for_kojin/mobile/topics_hankaku-kana.html > >>> 「受取人名（半角カナ）」は、半角30字以内で入力してください。 > >> > >> http://www.shinkin.co.jp/okayama/ibandhib/bizib/02_faq/faq_07.html > >>> これらのカナ略語は*全て半角文字で入力*して下さい。 > >>> 実際の振込画面から振込先の会社名を入力する際は、*全て半角カナで入力*してください > >> > >> http://www.yamanashibank.co.jp/anser-web/B-KM-009/help.html > >>> 半角30文字以内で入力してください > > > > I see. So I concede that unfortunately such sites do seem to exist. But > > instead of just accepting that, I think we ought to be asking why and > doing > > some general evangelism to make it clear that's bad practice and also > doing > > some evangelism with specific sites to try to get them to quit doing > that. > > > > What I would seriously like to see instead is an example of even one > single > > good thoughtfully-designed site that's actually requiring half-width kana > > input for some good reason. Just one. > > The problem with banking websites is that they tend to use old > mainframe/database that stores data > in half-width kana in the backend, and maximum length, etc… are different > between full-width and > half-width kana characters. e.g. it's hard to explain to the users that ガ > is considered as two characters > (as it will consist of カ and ゛) when it's visually one character. > > Unfortunately, I can't think of a good way to convince major banks in > Japan to use full-width kana > in their databases and inter-bank transactions. > > - R. Niwa > > -- Takayoshi Kochi
Re: [whatwg] inputmode feedback
On Dec 6, 2013, at 5:30 AM, 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.] > > "Takayoshi Kochi (河内 隆仁)" , 2013-12-06 19:53 +0900: > >> Just for a data point, lots of Japanese banks still make user type in >> half-width katakana. > > OK, but anecdotally my limited experience as a user with Japanese bank > sites is that the ones I use (Mizuho and Mitsui Sumitomo) don't require > half-width katakana input anywhere. > > Anyway, as I guess you know, bank sites as a class (along with airline > sites) are notorious for doing a lot of stupid things that are really bad > for user experience -- to the point where I think bank sites as a class > should really be considered a counter-example of good design. > >> Here are some random examples: >> >> http://www.tominbank.co.jp/for_kojin/mobile/topics_hankaku-kana.html >>> 「受取人名（半角カナ）」は、半角30字以内で入力してください。 >> >> http://www.shinkin.co.jp/okayama/ibandhib/bizib/02_faq/faq_07.html >>> これらのカナ略語は*全て半角文字で入力*して下さい。 >>> 実際の振込画面から振込先の会社名を入力する際は、*全て半角カナで入力*してください >> >> http://www.yamanashibank.co.jp/anser-web/B-KM-009/help.html >>> 半角30文字以内で入力してください > > I see. So I concede that unfortunately such sites do seem to exist. But > instead of just accepting that, I think we ought to be asking why and doing > some general evangelism to make it clear that's bad practice and also doing > some evangelism with specific sites to try to get them to quit doing that. > > What I would seriously like to see instead is an example of even one single > good thoughtfully-designed site that's actually requiring half-width kana > input for some good reason. Just one. The problem with banking websites is that they tend to use old mainframe/database that stores data in half-width kana in the backend, and maximum length, etc… are different between full-width and half-width kana characters. e.g. it's hard to explain to the users that ガ is considered as two characters (as it will consist of ｶ and ﾞ) when it's visually one character. Unfortunately, I can't think of a good way to convince major banks in Japan to use full-width kana in their databases and inter-bank transactions. - R. Niwa
Re: [whatwg] inputmode feedback
[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.] "Takayoshi Kochi (河内 隆仁)" , 2013-12-06 19:53 +0900: > Just for a data point, lots of Japanese banks still make user type in > half-width katakana. OK, but anecdotally my limited experience as a user with Japanese bank sites is that the ones I use (Mizuho and Mitsui Sumitomo) don't require half-width katakana input anywhere. Anyway, as I guess you know, bank sites as a class (along with airline sites) are notorious for doing a lot of stupid things that are really bad for user experience -- to the point where I think bank sites as a class should really be considered a counter-example of good design. > Here are some random examples: > > http://www.tominbank.co.jp/for_kojin/mobile/topics_hankaku-kana.html > > 「受取人名（半角カナ）」は、半角30字以内で入力してください。 > > http://www.shinkin.co.jp/okayama/ibandhib/bizib/02_faq/faq_07.html > > これらのカナ略語は*全て半角文字で入力*して下さい。 > > 実際の振込画面から振込先の会社名を入力する際は、*全て半角カナで入力*してください > > http://www.yamanashibank.co.jp/anser-web/B-KM-009/help.html > > 半角30文字以内で入力してください I see. So I concede that unfortunately such sites do seem to exist. But instead of just accepting that, I think we ought to be asking why and doing some general evangelism to make it clear that's bad practice and also doing some evangelism with specific sites to try to get them to quit doing that. What I would seriously like to see instead is an example of even one single good thoughtfully-designed site that's actually requiring half-width kana input for some good reason. Just one. > I am hesitant to get into endless debate how half-width-kana should be > here, but... I'm hesitant too but since we're building a platform that's going to be around for a long long time going forward, so I'm also hoping we don't end up perpetuating use of half-width kana if it's bad practice that we want to move everybody away from. > If most people can agree that it should not be widely used any more on > the web, I would think that it should be intentionally added to the spec > explicitly stating that "this mode is discouraged" in red and > intentionally not implement on any browser. (half joke, half serious) If your goal is to get this in the HTML spec, good luck with convincing Hixie to spec it out like that :-) > I think lobbying every IME vendor to drop half-width-kana is not worth > it, as half-width-kana will live in Unicode and the legacy probably will > not extinguish at least until the end of my life, even with the speed of > the internet. Well, we have a problem in Japan of a lot sites and people still choosing not to use Unicode even for new uses. We don't solve that problem for the future by continuing to add things that make it easier for them to keep creating new non-Unicode content. And as far as the legacy problem, it's not clear to me exactly what that problem is or how it relates to what we need to do now. I mean, I think what we're considering here is the use-case/requirement for half-width kana *input*. I agree that we need to continue supporting half-width kana display and storage and whatever. But that does not mean we should be making it easier for sites to force users to input content in half-width kana. And as long as users still have an OS IME (or third-party app) that lets them input half-width kana, then we are anyway not preventing them from being able to do that when bad sites force that on them. I'm just saying we should not further bake half-width kana input it into Web platform. > Some brave IME implementor tried to exclude half-width-kana but it ended > up with having third-party half-width-kana typing apps, which is kind of > ironic: http://kuracyan.net/archives/10751 Sad. (The existence of those third-party apps, I mean.) I see the mention on that guy's blog that people are visiting his site because they want to know how to type with half-width kana on their iPhones, but nowhere do I see any explanation of why they want to type anywhere with half-width kana. Anyway, like I said at the beginning of this message, I guess we should maybe better take this discussion off-list for now and meet up for lunch or something to talk more about it. --Mike > On Fri, Dec 6, 2013 at 6:27 PM, Michael[tm] Smith wrote: > > > Yoichi Osato , 2013-12-06 15:46 +0900: > > > > > 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. > > > For web developers that want to manage IME state like native > > applications, > > > the inputmode attribute lacks some modes > > > like "half-width-katakana". > > > > What modes other than "half-width-katakana" are we lacking? > > > > > But it might cause more confusing to add such attributes to inputmode. > > > > I think it might cause even more confus
Re: [whatwg] inputmode feedback
Just for a data point, lots of Japanese banks still make user type in half-width katakana. Here are some random examples: http://www.tominbank.co.jp/for_kojin/mobile/topics_hankaku-kana.html > 「受取人名（半角カナ）」は、半角30字以内で入力してください。 http://www.shinkin.co.jp/okayama/ibandhib/bizib/02_faq/faq_07.html > これらのカナ略語は*全て半角文字で入力*して下さい。 > 実際の振込画面から振込先の会社名を入力する際は、*全て半角カナで入力*してください http://www.yamanashibank.co.jp/anser-web/B-KM-009/help.html > 半角30文字以内で入力してください I am hesitant to get into endless debate how half-width-kana should be here, but... If most people can agree that it should not be widely used any more on the web, I would think that it should be intentionally added to the spec explicitly stating that "this mode is discouraged" in red and intentionally not implement on any browser. (half joke, half serious) I think lobbying every IME vendor to drop half-width-kana is not worth it, as half-width-kana will live in Unicode and the legacy probably will not extinguish at least until the end of my life, even with the speed of the internet. Some brave IME implementor tried to exclude half-width-kana but it ended up with having third-party half-width-kana typing apps, which is kind of ironic: http://kuracyan.net/archives/10751 On Fri, Dec 6, 2013 at 6:27 PM, Michael[tm] Smith wrote: > Yoichi Osato , 2013-12-06 15:46 +0900: > > > 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. > > For web developers that want to manage IME state like native > applications, > > the inputmode attribute lacks some modes > > like "half-width-katakana". > > What modes other than "half-width-katakana" are we lacking? > > > But it might cause more confusing to add such attributes to inputmode. > > I think it might cause even more confusion to add half-width-katakana input > support to any new IME-related API or UI, anywhere. In particular, it might > cause people to think that half-width katakana is actually useful to them > or needed for something these days. Which it's not, as far as I can see. > > Have you identified any actual current use cases for half-width katakana > input? > > In particular, any uses cases for half-width katakana input on the Web? > > > We are discussing to propose IME mode management as new API. > > Its mode contains "alphabet, kana, katakana, full-width-latin, > > half-width-katakana" as a native OS provides. > > I don't think the fact that OS IMEs provide support for half-width katakana > input means that it's necessary or useful for us to provide half-width > katakana input support in any new IME APIs for the Web. > > If the goal is to have consistency with OS IMEs, then I think a better > solution at this point would be to lobby OS IME vendors to finally drop > support for half-width katakana input. > > --Mike > > -- > Michael[tm] Smith http://people.w3.org/mike > -- Takayoshi Kochi
Re: [whatwg] inputmode feedback
Yoichi Osato , 2013-12-06 15:46 +0900: > 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. > For web developers that want to manage IME state like native applications, > the inputmode attribute lacks some modes > like "half-width-katakana". What modes other than "half-width-katakana" are we lacking? > But it might cause more confusing to add such attributes to inputmode. I think it might cause even more confusion to add half-width-katakana input support to any new IME-related API or UI, anywhere. In particular, it might cause people to think that half-width katakana is actually useful to them or needed for something these days. Which it's not, as far as I can see. Have you identified any actual current use cases for half-width katakana input? In particular, any uses cases for half-width katakana input on the Web? > We are discussing to propose IME mode management as new API. > Its mode contains "alphabet, kana, katakana, full-width-latin, > half-width-katakana" as a native OS provides. I don't think the fact that OS IMEs provide support for half-width katakana input means that it's necessary or useful for us to provide half-width katakana input support in any new IME APIs for the Web. If the goal is to have consistency with OS IMEs, then I think a better solution at this point would be to lobby OS IME vendors to finally drop support for half-width katakana input. --Mike -- Michael[tm] Smith http://people.w3.org/mike
Re: [whatwg] inputmode feedback
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. 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. 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. We think Chrome extension API is good for first then standardize as DOM event. On Tue, Sep 17, 2013 at 9:43 AM, Ian Hickson wrote: > On Tue, 13 Aug 2013, Yoichi Osato wrote: > > > > I have questions about some inputmode attributes. > > In the desktop case, full-width-latin, kana and katakana look to intend > > user local IME. Right? > > I'm not sure what this means exactly. > > > > I think whether IME is on or off is very important to user because some > > IME have state and show some window to input character. It is much > > different from alphabetic direct keyboard input. See > > > https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section > > At least Chinese and Korean IME have state. > > inputmode="" isn't intended to directly decide how the UI works, e.g. > whether an IME, or what kind of IME, is provided. However, it is intended > to let browsers make the decision on what kind of IME to provide. > > > > In this point we should add attributes corresponding to chinese and > korean. > > I don't know whether there are any other such a IME but I think many non > > English native people input in alphabet or hir/her native language. > > I would be very happy to add such things, but I don't know what the needs > are in those languages. I've been waiting for someone to elaborate on what > exactly is needed. > > > > So should we add "native" attribute? > > When would you use it? > > > On Tue, 13 Aug 2013, Ryosuke Niwa wrote: > > > > I think we need to separate the use case for controlling IME mode and > > hinting UA as to which type of text/script will be entered as Mounir > > suggested in the original email. > > I don't understand what the difference is. > > > > And I agree that we need to address Chinese and Korean IME use cases if > > we're adding Japanese IME use cases. Also, IME behavior is very > > different depending on whether you're using pinyin or zhuyin/bopomofo in > > Chinese IME so we might need to differentiate those two as well. > > Ok. What are the kinds of input tha Chinese and Korean Web sites need? > > > > On Mar 1, 2013, at 7:30 AM, Mounir Lamouri wrote: > > > On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote: > > >> That said, even though authors of web apps may want to force the IME > > >> mode or its script mode for user's sake, it may cause user's > > >> confusion as they are so accustomed to change mode manually where > > >> such mode is required. So if a web app sets some mode, the user may > > >> toggle it back to unintended mode and get frustrated. > > > > > > I tend to agree. In one hand, I believe that users might get irritated > > > if they can't control the inputmode but in another hand, forcing it > > > might fulfil use cases where authors use Javascript to force a user to > > > type in uppercase for example (that happens in a few forms). > > > > On the other hand, inputmode is supposedly only a hint, right? It > > doesn't affect the validation state of input elements. Given that, how > > does it address such a use case? > > I don't understand the concern here. The attribute is indeed a hint; it > doesn't tell the browser what UI to show, only what the page thinks the > user will want to enter. > > > > > On 21/02/13 01:14, Ryosuke Niwa wrote: > > >> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri > > >> wrote: > > >>> To conclude, Mozilla is interested in implementing this set of > > >>> keywords: verbatim, text, name, prose and digit (or numeric). > > >> > > >> Why is name not an input type? > > >> > > >> How does one decide whether a given semantics should be introduced as > > >> a type or a mode? > > > > > > I tend to prefer over > > type='name'> because , for the moment would be > > > nothing else but a text field with an address book autocompletion. I > > > would prefer to have 'tel' that way instead of having it a type FWIW. > > > > But isn't type=email also a text field with autocompletion, no? I agree > > that the UI might be similar on desktop browsers, but it could be > > completely different on mobile operating systems where UA could show a > > custom keyboard suitable to type in human names as opposed to arbitrary > > text. > > > > How is that different from type=email where UA is supposed to assist > > user type in an email address? > > Yeah, I don't really understand the suggestion above. > > > > It's not like we do a rigorous patte
Re: [whatwg] inputmode feedback
On Tue, 13 Aug 2013, Yoichi Osato wrote: > > I have questions about some inputmode attributes. > In the desktop case, full-width-latin, kana and katakana look to intend > user local IME. Right? I'm not sure what this means exactly. > I think whether IME is on or off is very important to user because some > IME have state and show some window to input character. It is much > different from alphabetic direct keyboard input. See > https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section > > At least Chinese and Korean IME have state. inputmode="" isn't intended to directly decide how the UI works, e.g. whether an IME, or what kind of IME, is provided. However, it is intended to let browsers make the decision on what kind of IME to provide. > In this point we should add attributes corresponding to chinese and korean. > I don't know whether there are any other such a IME but I think many non > English native people input in alphabet or hir/her native language. I would be very happy to add such things, but I don't know what the needs are in those languages. I've been waiting for someone to elaborate on what exactly is needed. > So should we add "native" attribute? When would you use it? On Tue, 13 Aug 2013, Ryosuke Niwa wrote: > > I think we need to separate the use case for controlling IME mode and > hinting UA as to which type of text/script will be entered as Mounir > suggested in the original email. I don't understand what the difference is. > And I agree that we need to address Chinese and Korean IME use cases if > we're adding Japanese IME use cases. Also, IME behavior is very > different depending on whether you're using pinyin or zhuyin/bopomofo in > Chinese IME so we might need to differentiate those two as well. Ok. What are the kinds of input tha Chinese and Korean Web sites need? > On Mar 1, 2013, at 7:30 AM, Mounir Lamouri wrote: > > On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote: > >> That said, even though authors of web apps may want to force the IME > >> mode or its script mode for user's sake, it may cause user's > >> confusion as they are so accustomed to change mode manually where > >> such mode is required. So if a web app sets some mode, the user may > >> toggle it back to unintended mode and get frustrated. > > > > I tend to agree. In one hand, I believe that users might get irritated > > if they can't control the inputmode but in another hand, forcing it > > might fulfil use cases where authors use Javascript to force a user to > > type in uppercase for example (that happens in a few forms). > > On the other hand, inputmode is supposedly only a hint, right? It > doesn't affect the validation state of input elements. Given that, how > does it address such a use case? I don't understand the concern here. The attribute is indeed a hint; it doesn't tell the browser what UI to show, only what the page thinks the user will want to enter. > > On 21/02/13 01:14, Ryosuke Niwa wrote: > >> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri > >> wrote: > >>> To conclude, Mozilla is interested in implementing this set of > >>> keywords: verbatim, text, name, prose and digit (or numeric). > >> > >> Why is name not an input type? > >> > >> How does one decide whether a given semantics should be introduced as > >> a type or a mode? > > > > I tend to prefer over > type='name'> because , for the moment would be > > nothing else but a text field with an address book autocompletion. I > > would prefer to have 'tel' that way instead of having it a type FWIW. > > But isn't type=email also a text field with autocompletion, no? I agree > that the UI might be similar on desktop browsers, but it could be > completely different on mobile operating systems where UA could show a > custom keyboard suitable to type in human names as opposed to arbitrary > text. > > How is that different from type=email where UA is supposed to assist > user type in an email address? Yeah, I don't really understand the suggestion above. > It's not like we do a rigorous pattern matching to validate email > addresses either. Actually, we do, or at least the spec does. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On Thu, 6 Jun 2013, Jonas Sicking wrote: > On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson wrote: > > 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. > > I think a really important question is if this is understandable to > authors. There's also a big risk that if these modes aren't noticeably > different in initial implementations, it will be hard to add such > differences later. I agree that those are concerns. I don't know how to resolve them. I'm certainly open to clearer names. I don't think "titlecase" is a better name, as it either implies that we only capitalise every first letter and forego much of the potential helpfulness that "latin-name" can provide. I don't think "autocapitalized" should imply "autocorrect" in the way that "latin-prose" should. "latin-prose" vs "latin-name" seem straight-forward enough; I agree that "latin" is confusing in that context, though once you explain that "latin" is the basis of "latin-prose" and "latin-name", I think it becomes clear. Other suggestions welcome. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On Aug 12, 2013, at 11:28 PM, Yoichi Osato wrote: > I have questions about some inputmode attributes. > In the desktop case, full-width-latin, kana and katakana look to intend > user local IME. Right? > I think whether IME is on or off is very important to user because some IME > have state and show some window to input character. > It is much different from alphabetic direct keyboard input. > See > https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section > At least Chinese and Korean IME have state. > In this point we should add attributes corresponding to chinese and korean. > I don't know whether there are any other such a IME but I think many non > English native people input in alphabet or hir/her native language. > So should we add "native" attribute? I think we need to separate the use case for controlling IME mode and hinting UA as to which type of text/script will be entered as Mounir suggested in the original email. And I agree that we need to address Chinese and Korean IME use cases if we're adding Japanese IME use cases. Also, IME behavior is very different depending on whether you're using pinyin or zhuyin/bopomofo in Chinese IME so we might need to differentiate those two as well. On Mar 1, 2013, at 7:30 AM, Mounir Lamouri wrote: > On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote: >> That said, even though authors of web apps may want to force the IME > mode or >> its script mode for user's sake, it may cause user's confusion as they are >> so accustomed to change mode manually where such mode is required. >> So if a web app sets some mode, the user may toggle it back to unintended >> mode >> and get frustrated. > > I tend to agree. In one hand, I believe that users might get irritated > if they can't control the inputmode but in another hand, forcing it > might fulfil use cases where authors use Javascript to force a user to > type in uppercase for example (that happens in a few forms). On the other hand, inputmode is supposedly only a hint, right? It doesn't affect the validation state of input elements. Given that, how does it address such a use case? > On 21/02/13 01:14, Ryosuke Niwa wrote: >> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri > wrote: >>> To conclude, Mozilla is interested in implementing this set of keywords: >>> verbatim, text, name, prose and digit (or numeric). >> >> Why is name not an input type? >> >> How does one decide whether a given semantics should be introduced as > a type or a mode? > > I tend to prefer over type='name'> because , for the moment would be > nothing else but a text field with an address book autocompletion. I > would prefer to have 'tel' that way instead of having it a type FWIW. But isn't type=email also a text field with autocompletion, no? I agree that the UI might be similar on desktop browsers, but it could be completely different on mobile operating systems where UA could show a custom keyboard suitable to type in human names as opposed to arbitrary text. How is that different from type=email where UA is supposed to assist user type in an email address? It's not like we do a rigorous pattern matching to validate email addresses either. - R. Niwa
Re: [whatwg] inputmode feedback
I have questions about some inputmode attributes. In the desktop case, full-width-latin, kana and katakana look to intend user local IME. Right? I think whether IME is on or off is very important to user because some IME have state and show some window to input character. It is much different from alphabetic direct keyboard input. See https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html#composer-section At least Chinese and Korean IME have state. In this point we should add attributes corresponding to chinese and korean. I don't know whether there are any other such a IME but I think many non English native people input in alphabet or hir/her native language. So should we add "native" attribute? Following Ian's graph: http://wiki.whatwg.org/wiki/Text_input_keyboard_mode_control How about this? User Default Input Method - Latin text verbatim -- Latin name --- Latin prose - Native language (includes like Hiragana, Hanja, which are first character set in each native language) -- Latin Full Width -- Katakana -- (some modes that is not first character set in native language) On Mon, Aug 12, 2013 at 6:26 PM, Takayoshi Kochi (河内 隆仁) wrote: > +Yoichi Osato, who is working on implementing inputmode spec for Blink and > Chromium. > > > On Fri, Jun 7, 2013 at 8:04 AM, Jonas Sicking wrote: > >> On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson wrote: >> > 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. >> >> I think a really important question is if this is understandable to >> authors. There's also a big risk that if these modes aren't noticeably >> different in initial implementations, it will be hard to add such >> differences later. >> >> / Jonas >> > > > > -- > Takayoshi Kochi >
Re: [whatwg] inputmode feedback
+Yoichi Osato, who is working on implementing inputmode spec for Blink and Chromium. On Fri, Jun 7, 2013 at 8:04 AM, Jonas Sicking wrote: > On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson wrote: > > 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. > > I think a really important question is if this is understandable to > authors. There's also a big risk that if these modes aren't noticeably > different in initial implementations, it will be hard to add such > differences later. > > / Jonas > -- Takayoshi Kochi
Re: [whatwg] inputmode feedback
On Thu, Jun 6, 2013 at 2:08 PM, Ian Hickson wrote: > 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. I think a really important question is if this is understandable to authors. There's also a big risk that if these modes aren't noticeably different in initial implementations, it will be hard to add such differences later. / Jonas
Re: [whatwg] inputmode feedback
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. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On 15/02/13 08:28, Takayoshi Kochi (河内 隆仁) wrote:
> As you probably know, there is also 'ime-mode' CSS style which IE/FF
> implements
> (and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode),
> which makes this more complex to use.
Is that implemented by some vendors?
> 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.
> That said, even though authors of web apps may want to force the IME
mode or
> its script mode for user's sake, it may cause user's confusion as they are
> so accustomed to change mode manually where such mode is required.
> So if a web app sets some mode, the user may toggle it back to unintended
> mode
> and get frustrated.
I tend to agree. In one hand, I believe that users might get irritated
if they can't control the inputmode but in another hand, forcing it
might fulfil use cases where authors use Javascript to force a user to
type in uppercase for example (that happens in a few forms).
Maybe if it was named @inputhint and the user was allowed to change the
input mode, it would be clearer?
On 15/02/13 09:45, Jonas Sicking wrote:
> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri
wrote:
>> Basically, the Mozilla's inputmode attribute is describing behaviour,
>> the allowed value are mostly self-explanatory: auto, uppercase,
>> lowercase, titlecase, autocapitalized, digit and numeric.
>
> What's the difference between "auto" and "autocapitalized"?
'auto' would be the default value.
>> To conclude, Mozilla is interested in implementing this set of keywords:
>> verbatim, text, name, prose and digit (or numeric).
>
> I have to say, these feel a lot less understandable than the types
> currently implemented in x-inputmode.
There is a confusion here. Firefox OS v1 isn't going to implement the
list mentioned above. It is going to be some kind of subsets of what the
WHATWG specification has. But I do not think we should take into account
what Firefox OS implements in that discussion.
> 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"?
I think 'titlecase' can be added later. It's not in opposition with
'name' because 'name' is not really title case (think of "Anne van K.")
and it will do autocompletion from the contact book ideally.
'lowercase' could also be added later. I just don't see much use cases
for it.
Regarding 'autocapitalized', I do not think the name is great. Apple has
"autocapitalized={on,off,word,sentence,character}" if I recall
correctly. It's probably clearer but "inputmode=autocapitalized" is
probably not that much self explanatory.
> I take it verbatim and name would disable any spelling corrections,
Yes.
> and name would also titlecase?
'name' would try to get the casing correct and auto-complete from the
contact book.
> But the difference between text and
> prose seems really hard to understand. I can't even understand the
> actual behavioral difference (which is what authors actually care
> about) reading the spec, much less guessing by the name.
I think the difference between 'verbatim' and 'text' is good to have.
Should we fix the spec and the naming?
On 21/02/13 01:14, Ryosuke Niwa wrote:
> On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri
wrote:
>> To conclude, Mozilla is interested in implementing this set of keywords:
>> verbatim, text, name, prose and digit (or numeric).
>
> Why is name not an input type?
>
> How does one decide whether a given semantics should be introduced as
a type or a mode?
I tend to prefer over because , for the moment would be
nothing else but a text field with an address book autocompletion. I
would prefer to have 'tel' that way instead of having it a type FWIW.
--
Mounir
Re: [whatwg] inputmode feedback
On Wed, 20 Feb 2013, Ryosuke Niwa wrote: > > Why is name not an input type? There's a section that discusses it a bit: http://whatwg.org/html#the-difference-between-the-field-type,-the-autofill-field-name,-and-the-input-modality -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inputmode feedback
On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri wrote: > To conclude, Mozilla is interested in implementing this set of keywords: > verbatim, text, name, prose and digit (or numeric). Why is name not an input type? How does one decide whether a given semantics should be introduced as a type or a mode? On Feb 15, 2013, at 12:28 AM, Takayoshi Kochi (河内 隆仁) wrote: > Hello Mounir, > > On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri wrote: > >> Regarding the three Japanese specific types, it is not clear if >> inputmode is the best way to solve the use cases intended to be solved. >> Actually, 'kana' and 'katakana' are trying to give a hint about the >> script that has to be used which seems to be orthogonal with the other >> types. We could allow inputmode to have a set of values but that would >> make the behaviour way more complex so I wonder if we couldn't try to >> solve that problem with another attribute like inputscript. >> > "three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"? > > I agree that it is weird 'kana' and 'katakana' are listed as inputmode > attribute, and 'inputscript' sounds more reasonable place where they should > be listed. Given the text in the spec "[t]he inputmode content attribute is an enumerated attribute that specifies what kind of input mechanism would be most helpful for users entering content into the form control," it makes sense for input mode to include kana and katakana. On the other hand, I'm surprised to find that these modes are very specific to Japanese. - R. Niwa
Re: [whatwg] inputmode feedback
On Wed, Feb 13, 2013 at 11:29 AM, Mounir Lamouri wrote: > Hi, > > Mozilla did implement an inputmode attribute for the element a > few months ago and the HTML specification has been updated after that to > introduce that attribute. Given that the specification and our > implementation was not matching, we decided to delay the release of that > feature [1] and not advertise it. We unfortunately had to push a > "x-inputmode" attribute in Firefox OS because our UI needed that feature > but we expect to replace this with a proper inputmode implementation as > soon as possible. > > Basically, the Mozilla's inputmode attribute is describing behaviour, > the allowed value are mostly self-explanatory: auto, uppercase, > lowercase, titlecase, autocapitalized, digit and numeric. What's the difference between "auto" and "autocapitalized"? > To conclude, Mozilla is interested in implementing this set of keywords: > verbatim, text, name, prose and digit (or numeric). I have to say, these feel a lot less understandable than the types currently implemented in x-inputmode. 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"? 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. I can't even understand the actual behavioral difference (which is what authors actually care about) reading the spec, much less guessing by the name. / Jonas
Re: [whatwg] inputmode feedback
Hello Mounir, On Thu, Feb 14, 2013 at 4:29 AM, Mounir Lamouri wrote: > Regarding the three Japanese specific types, it is not clear if > inputmode is the best way to solve the use cases intended to be solved. > Actually, 'kana' and 'katakana' are trying to give a hint about the > script that has to be used which seems to be orthogonal with the other > types. We could allow inputmode to have a set of values but that would > make the behaviour way more complex so I wonder if we couldn't try to > solve that problem with another attribute like inputscript. > > "three Japanese specific types"? 'kana', 'katakana', and 'full-width-latin"? I agree that it is weird 'kana' and 'katakana' are listed as inputmode attribute, and 'inputscript' sounds more reasonable place where they should be listed. As you probably know, there is also 'ime-mode' CSS style which IE/FF implements (and still proposed in CSS3 UI at http://www.w3.org/TR/css3-ui/#ime-mode), which makes this more complex to use. 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). That said, even though authors of web apps may want to force the IME mode or its script mode for user's sake, it may cause user's confusion as they are so accustomed to change mode manually where such mode is required. So if a web app sets some mode, the user may toggle it back to unintended mode and get frustrated. -- Takayoshi Kochi
[whatwg] inputmode feedback
Hi, Mozilla did implement an inputmode attribute for the element a few months ago and the HTML specification has been updated after that to introduce that attribute. Given that the specification and our implementation was not matching, we decided to delay the release of that feature [1] and not advertise it. We unfortunately had to push a "x-inputmode" attribute in Firefox OS because our UI needed that feature but we expect to replace this with a proper inputmode implementation as soon as possible. Basically, the Mozilla's inputmode attribute is describing behaviour, the allowed value are mostly self-explanatory: auto, uppercase, lowercase, titlecase, autocapitalized, digit and numeric. Autocapitalized is capitalizing words at the beginning of a sentence and the difference between digit and numeric is whether or not there should be a decimal separator and numeric operators available. The attribute as specified in HTML seems to focus on use cases, it provides more semantic and takes into account the handling of suggestions/corrections. However, the current set of values seems overly complex. 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" but in none of those situations "latin" is mandatory. The first one could be "text": we want to have typing aid enabled and any other feature related to entering some basic non-formatted text. (The difference between "verbatim" and this type is weak and "text" might not be the best way to improve this.) The second one is simply "name": whatever the script is, we want to enter a name in this field. The last one is "latin-prose": like the others, the use case is to write some formatted-text, the script shouldn't have any impact. Regarding the three Japanese specific types, it is not clear if inputmode is the best way to solve the use cases intended to be solved. Actually, 'kana' and 'katakana' are trying to give a hint about the script that has to be used which seems to be orthogonal with the other types. We could allow inputmode to have a set of values but that would make the behaviour way more complex so I wonder if we couldn't try to solve that problem with another attribute like inputscript. Mozilla's implementation has 'numeric' and 'digit' and 'numeric' in the HTML specification seems to match what we called 'digit'. It is not very important but I believe it would be nicer to have 'numeric' renamed 'digit' to make things clearer and to keep the 'numeric' keyword available in case of we need it later. 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. Finally, it is not clear why 'tel', 'email' and 'url' are available. Actually, tel would make sense if it wasn't already implemented as a type (because the type is mostly an inputmode) but all of those inputmode already have an associated type. The specification even say "rarely necessary" and suggest to use the type. Why adding those keywords in the first place then? I feel like we shouldn't add stuff that we do not believe is useful. If it happens to be useful, we should listen to feedback and see if we can fix the types (like make it easier to have them not validate). To conclude, Mozilla is interested in implementing this set of keywords: verbatim, text, name, prose and digit (or numeric). We would be interested to hear from other vendors. Is anybody planning to implement inputmode? if that's the case, which set of keywords is going to be implemented? Feedback is welcome :) [1] This is definitely working with Firefox Android Nightly, I don't know for other channels. Thanks, -- Mounir
