This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 26695 - Request that user agents implement the inputmode attribute BEFORE removing the selection properties/methods on extended HTML5 input types
Summary: Request that user agents implement the inputmode attribute BEFORE removing th...
Status: RESOLVED WORKSFORME
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: PC Windows NT
: P2 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL:
Whiteboard: blocked awaiting response from Stephe...
Keywords:
Depends on:
Blocks:
 
Reported: 2014-08-29 20:08 UTC by stephen.cunliffe
Modified: 2016-01-24 05:23 UTC (History)
4 users (show)

See Also:

Attachments

Description stephen.cunliffe 2014-08-29 20:08:37 UTC 
A conflict in the current spec creates a dilemma that shouldn't really occur.

With HTML5 input types like "number", "email", "tel", "url" web application developers can specify these field types and get an "automatic WIN!" for usability as they will launch the applicable on screen software based keyboards. (e.g. a number pad for number, a keyboard with the "@" symbol available for easy access when using an "email" field)

In *most* other aspects these fields behave just like a type "text" field does.

However after these new input types were created the spec changed (or at least the implementation of the spec in the real world changed) and properties and methods that are/were available on a "text", "password" or "textarea" input field were lost.

These properties/methods are:
select()
selectionStart
selectionEnd
selectionDirection
setSelectionRange()

As shown here in the specs:http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#the-input-element

This causes problems in the real world as there are tons of implementations that used these properties/methods to manipulate/inject values. When web sites/apps "updated" the input field type to "number" (for example) the user experience on mobile devices (phones/tablets) dramatically improved... however if a user agent updates to match the spec (as Chrome did) then all JavaScript that attempts to get or set selection (caret) position information fails.

Originally I had hoped that this bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=24796 or one of the similar ones would address this issue but they became polarized on mixed issues and thus hit a stalemate.

TL;DR

There is an inputmode attribute http://www.whatwg.org/specs/web-apps/current-work/multipage/forms.html#attr-fe-inputmode that would provide the INTENDED behavior if set:

<input type="text" inputmode="numeric"/>

That would obviously keep the JavaScript selection properties/methods of a text field HOWEVER also gain the usability of providing the correct keyboard on mobile/touchscreen devices. e.g. best of both worlds!

Sadly the inputmode attribute support is (as of the time of writing this) zero:
http://caniuse.com/#search=inputmode

Thus in order to gain the benefits of a numeric keyboard on a field we have to use hacky workarounds like this: http://stackoverflow.com/a/22382364/6144

By strongly requesting that user agents implement and honor the inputmode attribute BEFORE removing any selection properties/methods we will all benefit from this.

This is really important for any browser that has yet to remove these APIs and even more-so for those that have already dropped them.
Comment 1 Ian 'Hixie' Hickson 2014-08-29 22:33:54 UTC 
No APIs were removed. type=number previously didn't exist. When it was added, it was added with a set of APIs. At no point did those APIs include text selection, and at no point were those APIs therefore removed.

If I had some magical wand that could convince the browser vendors to implement the spec, I'd be all over that. Unfortunately, I don't.

I'm not really following what you're asking here though. What's the use case that you want to support that isn't supported? You say you need those methods, but why? In bug 24796 comment 40, my suggestion was specifically to file bugs describing what you are trying to implement that you can't implement.
Comment 2 stephen.cunliffe 2014-08-29 23:11:38 UTC 
Sorry if it wasn't clear...

I want to be able to use all the text selection methods /properties that I can use on a text, password, textarea... but CANT on a number field because the spec SAYS I can't. 

This (spec difference) was missed as an issue by web developers because it just worked in all browsers by default. However since Chrome REMOVED their implementation in order to comply with the spec... and other browsers **might** follow suit we NEED a way to prompt for a numeric input but retain our API access to the field.

If browser vendors implement the inputmode attribute then we can fallback to the text field type to get our API access back AND still get the usability feature of presenting the numeric keyboard.
Comment 3 Ian 'Hixie' Hickson 2014-09-02 17:20:21 UTC 
I understand that that is what you want. There are other requirements as well, which prevent that, as discussed in bug 24796.

The point of my request in bug 24796 comment 40 was to file new bugs that didn't just ask for the same API to be made available, but that _instead_ described one specific reason why you want that API, so we can see if there's another way to address that need explicitly. That is, the request was to file new bugs for each use case, describing the problem (e.g. "my users want to be able to enter numbers using focusable button widgets instead of using the keyboard, because...") rather than the desired solution ("expose the selection API on type=number").

I'm marking this bug as a dupe of bug 24796 since it essentially devolved to the same argument. However, I encourage you to file a new bug that does describe a use case without mentioning the solution you'd currently like to see. If you just want to argue for that solution, then bug 24796 is the place to do it (but unless you have some new novel argument, I don't think we're going to make progress that way).

*** This bug has been marked as a duplicate of bug 24796 ***
Comment 4 stephen.cunliffe 2014-09-02 20:32:58 UTC 
I'm at a total loss of how I can make this more clear but I'll try.

Developers want to be able to use text selection properties/methods on input fields that accept text input - e.g. Not "radio", "checkbox", "button", "select" etc.

The reasons why... don't really matter (but if you insist I would be glad to supply several examples - anywhere but not in this bug (or the releated bu's) thread as every "chat" about them derails the topic).

Since there seems to be no intention to "port" these selection methods from input type="text", type="password", type="undefined", and textarea to the newer HTML5 input types of "tel", "url", "email", and "number" what I'm asking is that.


Since the current spec's full implementation does not include these extremely useful APIs (arguments to go into the other bug) - I'd like to request that the "inputMode" attribute be implemented *first* to ensure that developers can use the inputMode to invoke the *correct* keyboard without having to sacrifice the JS APIs they are currently using.


These 2 bugs are totally different.


1.) The other bug 24796 is about the discussion as to what the spec should state. Do we really want to have these APIs on the fields or not?

2.) This bug is about the fact that **CURRENTLY** many developers *ALREADY* want/use the combination of JS selection API access to a field **AND** the correct mobile software keyboard to appear for a field based on its intended datatype.



I suspect that bug #1 will be debated endlessly (it might as well be spaces vs. tabs) until we either add the APIs or shut them down. I really hope that they come back but I've almost given up on that debate.

However... #2 is the pragmatic counter issue.  Ignoring the debate as to *if* these new fields should have this API... the fact is that developers were already using it until the spec implementation broke their usage. (Again ignoring the debate)... there is an intentional solution already baked into the HTML5 spec for an attribute called "inputMode" that lets developers tell the User Agent that they *WANT* a specific keyboard - yet does not enforce the restrictions of the new HTML5 input field types.  Thus for the interim (since sites/apps are live in production right now) if browser vendors implement the inputMode attribute before restricting the JS APIs on the new HTML5 input fields developers can handle their UI needs (and keep customers happy) while the debate on bug #1 rages on.
Comment 5 Ian 'Hixie' Hickson 2014-09-03 17:12:47 UTC 
> Developers want to be able to use text selection properties/methods on input
> fields that accept text input

Yes, of that there is no doubt. Equally, there are good reasons why this is not generally possible.


> The reasons why... don't really matter

The reasons why are the _only_ thing that matters.


> (but if you insist I would be glad to supply several examples - anywhere but not 
> in this bug (or the releated bugs) thread as every "chat" about them derails the 
> topic).

Yes, please, do supply these examples. Ideally, create a new bug for each such example, so that we can make sure we address each one individually.


> Since the current spec's full implementation does not include these
> extremely useful APIs (arguments to go into the other bug) - I'd like to
> request that the "inputMode" attribute be implemented *first* to ensure that
> developers can use the inputMode to invoke the *correct* keyboard without
> having to sacrifice the JS APIs they are currently using.

I would like nothing more than for the spec to be implemented, but this is the wrong bug system to ensure that that happens. You have to approach each browser vendor and ask them to implement these features. I don't have a magic wand that makes browsers implement things in the spec.
Comment 6 Ian 'Hixie' Hickson 2014-09-18 20:55:01 UTC 
(In reply to stephen.cunliffe from comment #0)
> 
> By strongly requesting that user agents implement and honor the inputmode
> attribute BEFORE removing any selection properties/methods we will all
> benefit from this.

The spec says they MUST do this already. I don't know how much more we can do.

Do you have a concrete proposal that would resolve your request on this bug?