Intent to Ship: “inputmode” attribute support for html input elements

[Brian White]

Contact emails

bcw...@google.com, yoi...@chromium.org, ko...@chromium.org

PM: kenji...@chromium.org

Spec

http://www.w3.org/html/wg/drafts/html/master/forms.html#input-modalities:-the-inputmode-attribute

Summary

The inputmode content attribute is an enumerated attribute that specifies what kind of input mechanism would be most helpful for users entering content into the text form control.

Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/topic/blink-dev/KjKEZ5Ga3k8/discussion

Is this feature supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

None

Compatibility Risk

There have been several different proposals for how “inputmode” should be used (X-Forms, for example) but the web seems to have settled on the “single enumeration value” supported here.

OWP launch tracking bug?

None.  This is being enabled so that the value can be passed to IME and used for auto-capitalization support.  https://codereview.chromium.org/720313004/

Link to entry on the feature dashboard

None.  Driving auto-capitalization request is here: http://code.google.com/p/chromium/issues/detail?id=116152

[bcw...@google.com]

I just realized that there is an entry on the "feature dashboard":

https://www.chromestatus.com/feature/6225984592281600

[Rick Byers]

Non-owner LGTM.  This is an important piece of missing functionality for the web on mobile devices.

Curious: how close does this spec get to the full keyboard configurability available in Android / iOS native keyboard APIs?  Or at least, do we have any idea of what fraction of the typical native mobile app use cases this will satisfy?  I'm curious about the future path here.

[Douglas Stockwell]

A demo would really help with this intent. The links here do not explain how our implementation behaves. For example, for which of the keywords in the spec do we alter the input behavior, and how does that vary across platforms?

[Brian White]

Non-owner LGTM.  This is an important piece of missing functionality for the web on mobile devices.

Curious: how close does this spec get to the full keyboard configurability available in Android / iOS native keyboard APIs?  Or at least, do we have any idea of what fraction of the typical native mobile app use cases this will satisfy?  I'm curious about the future path here.

"inputmode" is abstract and high-level; it defines the nature of the text being entered (e.g. "it's a proper name", "it's a telephone number", etc.).  It's up to us to translate this as we want into behavior.  It is lacking in flexibility, though, because a developer couldn't ask for a proper name that isn't capitalized.  It also doesn't work for non-latin keyboards.

On the other side, if new keyboard capabilities appear, they could be activated by this tag with no additional work by developers.  This is both good and bad as suddenly the behavior is different from what the developer expected and tested, possibly for the better and possibly for the worse.

In my personal opinion, this method mimics original web tags such as "<strong>" and "<em>" that provided intent and left the behavior up to the browser.  As we all know, these went by the wayside as developers prefer explicit controls such as "<b>" and "<i>".  Following this same logic, I think "inputmode" is an example of trying something that history has shown to be not what people want and Safari's "autocapitalize" attribute is the better choice.  Developers will choose values based on the (current) behavior they want rather than what the value actually means.  But I don't have a say in the standard.  :-)

As for the explicit question of what fraction of use-cases will be satisfied by this: probably most but it's very difficult to say for sure given that what everybody asks for is explicit auto-capitalization control rather than defining their specific use-case.  It seems this attribute is not currently in wide use (while "autocapitalize" is, including by Google's own services) and thus will require developers to update all their code to take advantage of it.

  Brian
  bcw...@google.com
-----------------------------------------------------------------------------------------
Treat someone as they are and they will remain that way.
Treat someone as they can be and they will become that way.

[Brian White]

A demo would really help with this intent. The links here do not explain how our implementation behaves. For example, for which of the keywords in the spec do we alter the input behavior, and how does that vary across platforms?

There is nothing to see.  (cue Operative walking off-set)  This feature doesn't actually do anything but recognize the attribute and decode it.  I don't believe there is code anywhere that makes use of the value.

I have a CL for Android Chrome that will examine the value and use it to set the auto-capitalization feature of the Android Keyboard.

https://codereview.chromium.org/720313004/

-- Brian

[Daniel Bratell]

On Wed, 07 Jan 2015 16:13:55 +0100, 'Brian White' via blink-dev <blin...@chromium.org> wrote:

Non-owner LGTM.  This is an important piece of missing functionality for the web on mobile devices.

Curious: how close does this spec get to the full keyboard configurability available in Android / iOS native keyboard APIs?  Or at least, do we have any idea of what fraction of the typical native mobile app use cases this will satisfy?  I'm curious about the future path here.

"inputmode" is abstract and high-level; it defines the nature of the text being entered (e.g. "it's a proper name", "it's a telephone number", etc.).  It's up to us to translate this as we want into behavior.  It is lacking in flexibility, though, because a developer couldn't ask for a proper name that isn't capitalized.  It also doesn't work for non-latin keyboards.

The spec seems to support at least Latin keyboards and some east Asian keyboards.

This is quite useful for pages because touch devices are not good enough at input and to get better they need to have more information about what the user is supposed to do. And in the phone environment it's an old problem with proprietary solutions (for instance Presto supports the istyle[1] attribute).

I can't be the only one that gets annoyed by keyboards trying to auto-correct non-language strings?

Whether this is the optimal solution, probably not (I see things I don't like), but after 10+ years of browsers on phones any standard solution feels better than to keep looking for another 10 years.

/Daniel

[1] https://www.nttdocomo.co.jp/english/service/developer/make/content/browser/html/tag/istyle.html

[Rick Byers]

On Wed, Jan 7, 2015 at 10:13 AM, Brian White <bcw...@google.com> wrote:

Non-owner LGTM.  This is an important piece of missing functionality for the web on mobile devices.

Curious: how close does this spec get to the full keyboard configurability available in Android / iOS native keyboard APIs?  Or at least, do we have any idea of what fraction of the typical native mobile app use cases this will satisfy?  I'm curious about the future path here.

"inputmode" is abstract and high-level; it defines the nature of the text being entered (e.g. "it's a proper name", "it's a telephone number", etc.).  It's up to us to translate this as we want into behavior.  It is lacking in flexibility, though, because a developer couldn't ask for a proper name that isn't capitalized.  It also doesn't work for non-latin keyboards.

On the other side, if new keyboard capabilities appear, they could be activated by this tag with no additional work by developers.  This is both good and bad as suddenly the behavior is different from what the developer expected and tested, possibly for the better and possibly for the worse.

In my personal opinion, this method mimics original web tags such as "<strong>" and "<em>" that provided intent and left the behavior up to the browser.  As we all know, these went by the wayside as developers prefer explicit controls such as "<b>" and "<i>".  Following this same logic, I think "inputmode" is an example of trying something that history has shown to be not what people want and Safari's "autocapitalize" attribute is the better choice.  Developers will choose values based on the (current) behavior they want rather than what the value actually means.  But I don't have a say in the standard.  :-)

This sentiment worries me.  You, as the implementer in one of the worlds most popular browsers absolutely has a big say in the standard!  If you think the standard is wrong (especially if we're the one going first and not following for interoperability with IE, Safari or Mozilla) then it's your obligation to give your feedback to the standards group and avoid implementing it until you think it's a good API!

What's the status in the other browsers?  If we go first, that's sending a signal to them saying we like the API and we want them to also implement it as spec'd.

So before we ship this, can you please follow up with the working group regarding your concerns?  You can approach the W3C HTML5 group and/or the WHATWG list (if the two html5 specs differ, we tend to follow the WHATWG one in blink).  Ideally they'll be able to change your mind and convince you this is really the right design for the long-term of the web (I don't have enough context to have an opinion myself).

Of course it may be the case that reasonable people can disagree on this point, and that either option is pretty good and better than the alternative of endless fighting and so we should just implement the consensus even if it's not exactly what we would have designed ourselves.

We could also also try to standardize Safari's autocapitalize attribute (even if it's redundant with input mode) and implement only it.  Arguments like "x% of top N websites already use autocapitalize so it's a defacto standard already that should be specified" seem likely to carry a lot of weight.

[Brian White]

Non-owner LGTM.  This is an important piece of missing functionality for the web on mobile devices.

Curious: how close does this spec get to the full keyboard configurability available in Android / iOS native keyboard APIs?  Or at least, do we have any idea of what fraction of the typical native mobile app use cases this will satisfy?  I'm curious about the future path here.

"inputmode" is abstract and high-level; it defines the nature of the text being entered (e.g. "it's a proper name", "it's a telephone number", etc.).  It's up to us to translate this as we want into behavior.  It is lacking in flexibility, though, because a developer couldn't ask for a proper name that isn't capitalized.  It also doesn't work for non-latin keyboards.

On the other side, if new keyboard capabilities appear, they could be activated by this tag with no additional work by developers.  This is both good and bad as suddenly the behavior is different from what the developer expected and tested, possibly for the better and possibly for the worse.

In my personal opinion, this method mimics original web tags such as "<strong>" and "<em>" that provided intent and left the behavior up to the browser.  As we all know, these went by the wayside as developers prefer explicit controls such as "<b>" and "<i>".  Following this same logic, I think "inputmode" is an example of trying something that history has shown to be not what people want and Safari's "autocapitalize" attribute is the better choice.  Developers will choose values based on the (current) behavior they want rather than what the value actually means.  But I don't have a say in the standard.  :-)

This sentiment worries me.  You, as the implementer in one of the worlds most popular browsers absolutely has a big say in the standard!  If you think the standard is wrong (especially if we're the one going first and not following for interoperability with IE, Safari or Mozilla) then it's your obligation to give your feedback to the standards group and avoid implementing it until you think it's a good API!

(ever wish you'd just remained silent?  :-) 

To be clear, I didn't implement this (where "this" is "inputmode support in Blink").  I was told that "inputmode" is the standard and so I must use "inputmode" for handing Android auto-capitalize settings (which requires enabling it in Blink since it's currently only experimental).

https://code.google.com/p/chromium/issues/detail?id=116152

My original CL that added support to Blink for Safari's "autocapitalize" attribute was reverted because "it's not standard".

 

What's the status in the other browsers?  If we go first, that's sending a signal to them saying we like the API and we want them to also implement it as spec'd.

According to...

http://www.wufoo.com/html5/attributes/23-inputmode.html

https://status.modern.ie/

http://compatibility.shwups-cms.ch/de/home?&property=__createdObjects.input.inputmode

... the state of support is pretty much unchanged since it was a year ago.  I.E. nobody

 

So before we ship this, can you please follow up with the working group regarding your concerns?  You can approach the W3C HTML5 group and/or the WHATWG list (if the two html5 specs differ, we tend to follow the WHATWG one in blink).  Ideally they'll be able to change your mind and convince you this is really the right design for the long-term of the web (I don't have enough context to have an opinion myself).

Of course it may be the case that reasonable people can disagree on this point, and that either option is pretty good and better than the alternative of endless fighting and so we should just implement the consensus even if it's not exactly what we would have designed ourselves.

They're entitled to their wrong opinions!  :-D

This whole thing has been discussed over many years.  At one point, it was proposed that "inputmode" take multiple values to separate language from modification ("x-forms") but that was eventually rejected for the current proposal.

Don't get me wrong.  I think "inputmode" is good for what it does (or rather, could do).  I'm just not convinced that extrapolating auto-cap settings from its values is the best way because I fear that developers will choose the inputmode value that gives them the auto-cap settings they want even if that value causes (now or in the future) other behaviors that aren't ideal.

 

So this is the consensus.  I didn't want to start any (more) fighting about it.  I just felt it was fair to cover all the bases.

We could also also try to standardize Safari's autocapitalize attribute (even if it's redundant with input mode) and implement only it.  Arguments like "x% of top N websites already use autocapitalize so it's a defacto standard already that should be specified" seem likely to carry a lot of weight.

This was suggested back in April, 2011 and eventually rejected in favor of "inputmode".

https://www.w3.org/Bugs/Public/show_bug.cgi?id=12409

  Brian

[Rick Byers]

On Wed, Jan 7, 2015 at 12:18 PM, 'Brian White' via input-dev <inpu...@chromium.org> wrote:

Non-owner LGTM.  This is an important piece of missing functionality for the web on mobile devices.

Curious: how close does this spec get to the full keyboard configurability available in Android / iOS native keyboard APIs?  Or at least, do we have any idea of what fraction of the typical native mobile app use cases this will satisfy?  I'm curious about the future path here.

"inputmode" is abstract and high-level; it defines the nature of the text being entered (e.g. "it's a proper name", "it's a telephone number", etc.).  It's up to us to translate this as we want into behavior.  It is lacking in flexibility, though, because a developer couldn't ask for a proper name that isn't capitalized.  It also doesn't work for non-latin keyboards.

On the other side, if new keyboard capabilities appear, they could be activated by this tag with no additional work by developers.  This is both good and bad as suddenly the behavior is different from what the developer expected and tested, possibly for the better and possibly for the worse.

In my personal opinion, this method mimics original web tags such as "<strong>" and "<em>" that provided intent and left the behavior up to the browser.  As we all know, these went by the wayside as developers prefer explicit controls such as "<b>" and "<i>".  Following this same logic, I think "inputmode" is an example of trying something that history has shown to be not what people want and Safari's "autocapitalize" attribute is the better choice.  Developers will choose values based on the (current) behavior they want rather than what the value actually means.  But I don't have a say in the standard.  :-)

This sentiment worries me.  You, as the implementer in one of the worlds most popular browsers absolutely has a big say in the standard!  If you think the standard is wrong (especially if we're the one going first and not following for interoperability with IE, Safari or Mozilla) then it's your obligation to give your feedback to the standards group and avoid implementing it until you think it's a good API!

(ever wish you'd just remained silent?  :-) 

To be clear, I didn't implement this (where "this" is "inputmode support in Blink").  I was told that "inputmode" is the standard and so I must use "inputmode" for handing Android auto-capitalize settings (which requires enabling it in Blink since it's currently only experimental).

https://code.google.com/p/chromium/issues/detail?id=116152

My original CL that added support to Blink for Safari's "autocapitalize" attribute was reverted because "it's not standard".

Yep, but that's not necessarily hard to fix - at least for the WhatWG spec.  Eg. if you can collect some concrete data that shows that LOTS of websites are already using autocapitalize (within Google you can use cookbook/ for this), then that may be a compelling enough argument to add it to the spec (given how simple it is).  Once you have a bit of data, you can just send it to the WhatWG list and see what people say.  Personally I'd rather Chrome immediately get the benefit of the work developers have done for Safari here - especially if we don't have a strong reason to feel the Safari API is flawed.

What's the status in the other browsers?  If we go first, that's sending a signal to them saying we like the API and we want them to also implement it as spec'd.

According to...

http://www.wufoo.com/html5/attributes/23-inputmode.html

https://status.modern.ie/

http://compatibility.shwups-cms.ch/de/home?&property=__createdObjects.input.inputmode

... the state of support is pretty much unchanged since it was a year ago.  I.E. nobody

Right, and even IE is just "under consideration".  So we really are going first here - we should be sure then that it's a programming pattern we want to encourage and support indefinitely, and not just settling for something that's not terrible.

tkent@ you're an expert on this stuff and had some opinions on the bug, right?  Do you prefer the design of inputmode to Safari's existing API for this scenario?

I agree we need an API for this (years ago!), but we'll probably have trouble getting an LGTM to ship without folks who have dug into it saying they believe it's a good API for the scenario we're working to solve, or without some other major browser shipping it first :-).

So before we ship this, can you please follow up with the working group regarding your concerns?  You can approach the W3C HTML5 group and/or the WHATWG list (if the two html5 specs differ, we tend to follow the WHATWG one in blink).  Ideally they'll be able to change your mind and convince you this is really the right design for the long-term of the web (I don't have enough context to have an opinion myself).

Of course it may be the case that reasonable people can disagree on this point, and that either option is pretty good and better than the alternative of endless fighting and so we should just implement the consensus even if it's not exactly what we would have designed ourselves.

They're entitled to their wrong opinions!  :-D

This whole thing has been discussed over many years.  At one point, it was proposed that "inputmode" take multiple values to separate language from modification ("x-forms") but that was eventually rejected for the current proposal.

Don't get me wrong.  I think "inputmode" is good for what it does (or rather, could do).  I'm just not convinced that extrapolating auto-cap settings from its values is the best way because I fear that developers will choose the inputmode value that gives them the auto-cap settings they want even if that value causes (now or in the future) other behaviors that aren't ideal.

 

So this is the consensus.  I didn't want to start any (more) fighting about it.  I just felt it was fair to cover all the bases.

It may be the consensus of the W3C HTML WG (or at least was a few years ago when these debates were happening).  But the fact that no other browser has implemented it (including Safari which has an existing alternative API) suggests there may not be as much consensus among implementers as you might be assuming.  I'd hate, for example, for us to implement this then Safari to say they're not going to because they prefer their existing API and argue the standard should be updated to include their API.

[Simon Pieters]

On Wed, 07 Jan 2015 19:54:22 +0100, Rick Byers <rby...@chromium.org> wrote:

> Yep, but that's not necessarily hard to fix - at least for the WhatWG
> spec. Eg. if you can collect some concrete data that shows that LOTS of
> websites are already using autocapitalize (within Google you can use
> cookbook/ for this), then that may be a compelling enough argument to add
> it to the spec (given how simple it is). Once you have a bit of data,
> you

> can just send it to the WhatWG list <https://whatwg.org/mailing-list> and
> see what people say.

In github search I see 2,994 matches for inputmode and 18,343 matches for
autocapitalize (limiting to language:HTML)

https://github.com/search?l=html&q=inputmode&ref=searchresults&type=Code&utf8=✓
https://github.com/search?l=html&q=autocapitalize&ref=searchresults&type=Code&utf8=✓


In http://webdevdata.org/ data set 2013-09-01 102,000 pages, I see 6
instances of inputmode and 629 instances of autocapitalize.

$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -Eio
"<(input|textarea)(\s[^>]+)?\sinputmode" >> ../inputmode.txt
$ find . -type f -print0 | xargs -0 -P 4 -n 40 grep -Eio
"<(input|textarea)(\s[^>]+)?\sautocapitalize" >> ../autocapitalize.txt


httparchive can also be checked, I will leave that as an exercise to the
reader. :-)

--
Simon Pieters
Opera Software

[Brian White]

tkent@ you're an expert on this stuff and had some opinions on the bug, right?  Do you prefer the design of inputmode to Safari's existing API for this scenario?

Since it was tkent who asked that I revert the "autocapitalize" in favor of "inputmode" and told me how to do an "intent to ship" of existing code...  I'll take a wild guess that he's in favor of doing it this way.  :-)

[Mounir Lamouri]

I am really surprised to see this Intent to Ship. A couple of months
ago, I asked whether this was still being worked on and was told there
was no plan to ship. The bug has been assigned to me even [1].

In the meantime, I have been working on a solution for this problem and
talked to Jonas Sicking from Mozilla at TPAC and some devrel folks at
Google. The solution we have been drafting would be something mostly
re-using Safari proprietary attributes. Unfortunately, I didn't get
enough cycles to finalize a proposal. We need to figure out which parts
of the Safari attributes we want to standardize (some seem highly used
but deprecated) and what needs to be added.

In general, I don't think there is a wide support for inputmode from
browser vendors.

[1] https://crbug.com/244688

-- Mounir

> Link to entry on the feature dashboard <http://www.chromestatus.com/>

>
> None. Driving auto-capitalization request is here:
> http://code.google.com/p/chromium/issues/detail?id=116152
>

> To unsubscribe from this group and stop receiving emails from it, send an
> email to blink-dev+...@chromium.org.

[Rick Byers]

On Thu, Jan 8, 2015 at 6:16 AM, 'Brian White' via blink-dev <blin...@chromium.org> wrote:

tkent@ you're an expert on this stuff and had some opinions on the bug, right?  Do you prefer the design of inputmode to Safari's existing API for this scenario?

Since it was tkent who asked that I revert the "autocapitalize" in favor of "inputmode" and told me how to do an "intent to ship" of existing code...  I'll take a wild guess that he's in favor of doing it this way.  :-)

My reading of the bug was that he was saying we don't ship non-standard APIs so the only way to move forward without any new standards was inputmode.  I didn't see him explicitly say that he thinks inputmode is a better API for your scenario than autocapitalize ;-) 

[Rick Byers]

On Thu, Jan 8, 2015 at 11:10 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Jan 8, 2015 at 6:16 AM, 'Brian White' via blink-dev <blin...@chromium.org> wrote:

tkent@ you're an expert on this stuff and had some opinions on the bug, right?  Do you prefer the design of inputmode to Safari's existing API for this scenario?

Since it was tkent who asked that I revert the "autocapitalize" in favor of "inputmode" and told me how to do an "intent to ship" of existing code...  I'll take a wild guess that he's in favor of doing it this way.  :-)

My reading of the bug was that he was saying we don't ship non-standard APIs so the only way to move forward without any new standards was inputmode.  I didn't see him explicitly say that he thinks inputmode is a better API for your scenario than autocapitalize ;-) 

Ah, I see tkent@ is on leave until the end of January.  Sounds like Mounir has a ton of context and a plan here anyway, so you guys should talk offline and circle back here with a plan you both like.  It's a shame you guys hadn't talked earlier - sounds like he could have saved you a lot of frustration ;-)

[Dimitri Glazkov]

On Thu, Jan 8, 2015 at 8:35 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Jan 8, 2015 at 11:10 AM, Rick Byers <rby...@chromium.org> wrote:

On Thu, Jan 8, 2015 at 6:16 AM, 'Brian White' via blink-dev <blin...@chromium.org> wrote:

tkent@ you're an expert on this stuff and had some opinions on the bug, right?  Do you prefer the design of inputmode to Safari's existing API for this scenario?

Since it was tkent who asked that I revert the "autocapitalize" in favor of "inputmode" and told me how to do an "intent to ship" of existing code...  I'll take a wild guess that he's in favor of doing it this way.  :-)

My reading of the bug was that he was saying we don't ship non-standard APIs so the only way to move forward without any new standards was inputmode.  I didn't see him explicitly say that he thinks inputmode is a better API for your scenario than autocapitalize ;-) 

Ah, I see tkent@ is on leave until the end of January.  Sounds like Mounir has a ton of context and a plan here anyway, so you guys should talk offline and circle back here with a plan you both like.  It's a shame you guys hadn't talked earlier - sounds like he could have saved you a lot of frustration ;-)

FWIW, SGTM. BBQ.

[Tab Atkins Jr.]

On Thu, Jan 8, 2015 at 6:10 AM, Mounir Lamouri <mou...@lamouri.fr> wrote:
> I am really surprised to see this Intent to Ship. A couple of months
> ago, I asked whether this was still being worked on and was told there
> was no plan to ship. The bug has been assigned to me even [1].
>
> In the meantime, I have been working on a solution for this problem and
> talked to Jonas Sicking from Mozilla at TPAC and some devrel folks at
> Google. The solution we have been drafting would be something mostly
> re-using Safari proprietary attributes. Unfortunately, I didn't get
> enough cycles to finalize a proposal. We need to figure out which parts
> of the Safari attributes we want to standardize (some seem highly used
> but deprecated) and what needs to be added.
>
> In general, I don't think there is a wide support for inputmode from
> browser vendors.
>
> [1] https://crbug.com/244688

On the other hand, I'd prefer we continue with inputmode if possible.
I don't want to have to try and guess at what kind of attributes are
name-like to people in non-English countries; that's something much
better done by one person in the browser.

~TJ