W3C home > Mailing lists > Public > whatwg@whatwg.org > March 2013

Re: [whatwg] inputmode feedback

From: Mounir Lamouri <mounir@lamouri.fr>
Date: Fri, 01 Mar 2013 15:30:41 +0000
Message-ID: <5130C9A1.2020200@lamouri.fr>
To: whatwg@lists.whatwg.org
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 <mounir@lamouri.fr>
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 <mounir@lamouri.fr>
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 <input type='text' inputmode='name'> over <input
type='name'> because <input type='name'>, 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
Received on Friday, 1 March 2013 15:31:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 1 March 2013 15:31:09 GMT