This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
And the behavior for the Cyrillic, Arabic, Hebrew etc scripts is undefined.
Do you have a specific proposal to improve it?
I understand that the author of the original proposal is Japanese (thus it covers problems that arise with switching of different Japanese IME modes). More general approach to allow even layout switching would be more useful in the general, I believe. In some cases there is a need to input in different fields in different languages, having a browser doing the job certainly helps a lot.
Actually the author of the original proposal was a Swiss/British binational with no knowledge of Japanese at all. However, some people with knowledge of Japanese responded to his call for feedback and gave specific descriptions of what kinds of input modes were useful in Japanese, and specifically what the use cases for those various input modes were. Since nobody has done the same for any other locales, the spec doesn't support those other locales. If anyone has the necessary information for another locale, they need but file a bug at http://whatwg.org/newbug to describe it, and the spec will in due course be updated accordingly.
(In reply to Ian 'Hixie' Hickson from comment #3) > Actually the author of the original proposal was a Swiss/British binational > with no knowledge of Japanese at all. However, some people with knowledge of > Japanese responded to his call for feedback and gave specific descriptions > of what kinds of input modes were useful in Japanese, and specifically what > the use cases for those various input modes were. Do you have the link where the discussion (a Japanese guy proposed Japanese-IME related modes) somewhere? As we are discussing whether to remove IME related modes out of inputmode or not, I'd like to have a proper reference to the origin of those Japanese modes..
For a start, the statements in the url and email types that input is set to the user's locale make no sense. The primary use case for such inputmodes is where essentially latin text is expected, but the user's locale is a non-latin script, e.g. arabic, cyrillic, greek… Likewise, telephone numbers outside the US commonly require the "+" character to be available. Meanwhile, there are two common mappings of letters to numbers - and in any event the text doesn't give much of a clue about what to *do* with the fact that Americans are used to having phone numbers that are spelled out with words (or even that this is the actual use case - being able to use information like "dial 1-800-for-5off to comment", or somesuch).
HTML5.1 Bugzilla Bug Triage: Incubation needed Seems like we have a couple of use cases here, but nothing concrete proposed. I would like to see this improved, but we should see if we can get a successful incubation started to build some momentum first. This bug constitutes a request for a new feature of HTML. The current guidelines [1], rather than track such requests as bugs or issues, please create a proposal outlining the desired behavior, or at least a sketch of what is wanted (much of which is probably contained in this bug), and start the discussion/proposal in the WICG [2]. As your idea gains interest and momentum, it may be brought back into HTML through the Intent to Migrate process [3]. [1] https://github.com/w3c/html#contributing-to-this-repository [2] https://www.w3.org/community/wicg/ [3] https://wicg.github.io/admin/intent-to-migrate.html