Re: inputmode attribute

and this https://github.com/whatwg/html/issues/1897

On Tue, Aug 1, 2017 at 12:35 PM, Takayoshi Kochi <kochi@google.com> wrote:

> FYI, these days discussion on GitHub issues could get more attention than
> in this mailing list,
> and I found existing one at the whatwg html tracker https://github.com/
> whatwg/html/issues/1626
>
> On Mon, Jul 31, 2017 at 10:41 PM, Lars Solberg <lars.solberg@gmail.com>
> wrote:
>
>> Correct. Fields viewed on mobile should be able to give hints about which
>> keyboard to use, without forcing the datatype.
>> Mobile could use the hinted keyboard as default, but still give the user
>> a way to switch the layout.
>>
>> The problem is basically that "there are no current way using a numeric
>> pad on keyboard, without giving (often) too much constraints on the field."
>>
>> The spec contains all sorts of things nowadays, but it feels like the
>> some of the most basics have been forgotten :)
>>
>> On Mon, Jul 31, 2017 at 5:06 AM, Takayoshi Kochi <kochi@google.com>
>> wrote:
>>
>>> So you want a more hint-like attribute, rather than enforcement of the
>>> type, right?
>>> I think "inputmode" attribute originally introduced for such purpose,
>>> but has not gained
>>> enough interest from browser implementors, unfortunately.
>>>
>>> The original one was introduced before the mobile-first era, so we may
>>> reconsider the spec
>>> from the current architecture of input for modern mobile environment.
>>>
>>> A bit of history...
>>>
>>> As far as I know, once Chrome tried to implement some of Japanese
>>> IME-related modes in inputmode,
>>> but the effort was abandoned due to low interest and feasibility for
>>> non-Windows platforms, especially
>>> mobile platforms.
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=248482
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=244688
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=642800
>>> At least we should remove the script-specific types (e.g. japanese-kana)
>>> from the spec.
>>>
>>> Other modes have overlap with type= attribute (e.g. type=number), and
>>> type= is currently
>>> the preferred way of specifying the type of the input (also the spec is
>>> saying so).
>>> IIUC Android Chrome implements type=number.
>>>
>>> I'd think this kind of modality should not be specified via CSS, as it
>>> has nothing to do with styles.
>>>
>>> (FYI, IME related mode settings were available in IE and Firefox via
>>> CSS.
>>> https://developer.mozilla.org/en-US/docs/Web/CSS/ime-mode
>>> https://bugs.chromium.org/p/chromium/issues/detail?id=4490
>>> which I think, is a wrong approach, either)
>>>
>>>
>>> On Fri, Jul 28, 2017 at 5:56 PM, Lars Solberg <lars.solberg@gmail.com>
>>> wrote:
>>>
>>>> Hello
>>>>
>>>> I am trying to figure out the story of the inputmode attribute for the
>>>> <input> element.
>>>> I'm seeing discussions about that attribute long back (5-10 years), and
>>>> based on https://caniuse.com/#feat=input-inputmode, it was supported
>>>> back in firefox 17-20.
>>>>
>>>> But what happened to it? Why are no browsers adopting it? Giving hints
>>>> to mobile platforms about which keyboardtype to use seams very powerful.
>>>> Using type=number sets a lot of other limitations on the field.
>>>>
>>>> The best way would be to set hints like this using css.
>>>>
>>>> Is there a work in progress here?
>>>> Is, and will it be type=inputmode that is the way to do this, including
>>>> it's limitations?
>>>> Will there be a bigger standard for controlling things like this on
>>>> mobile devices, as it becomes more popular?
>>>>
>>>> Best regards
>>>>   Lars
>>>>
>>>
>>>
>>>
>>> --
>>> Takayoshi Kochi
>>>
>>
>>
>
>
> --
> Takayoshi Kochi
>



-- 
Takayoshi Kochi