Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: to add the attribute format for input times #4523

Open
FANMixco opened this issue Apr 11, 2019 · 7 comments
Open

Proposal: to add the attribute format for input times #4523

FANMixco opened this issue Apr 11, 2019 · 7 comments
Labels
addition/proposal New features or enhancements i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. needs implementer interest Moving the issue forward requires implementers to express interest topic: forms

Comments

@FANMixco
Copy link

I have seen multiple questions of the issue of 12/24 format in the forums for input types, some browsers recognized the configuration, others just totally ignore it and it doesn't matter what you do, it's complex to deal forcing developers to use 3rd party plugins because the situation makes unusable in many cases the input time control, for example:

I tried building a small app with an input type in Android:

https://stackoverflow.com/questions/55621090/lang-attribute-ignored-in-android-webview

But it didn't work because in Poland there is 24h format and not 12, but because my emulators use en-US, it didn't matter, yes, I could switch the regional settings, but it's a huge work, it will be good to have a mandatory option or at least make a proposal that the lang should be respected to simplify the work and promote the usage of these controls regularly among developers, avoiding 3rd party solutions or our own plugins.

Thank you in advance for your support.

P.S.
There is even an issue related since 6 years ago in Chromium that proves how important is to have an alternative to encourage Browser vendors to provide an option:

https://bugs.chromium.org/p/chromium/issues/detail?id=263320

@FANMixco FANMixco changed the title Proposal attribute format for input time Proposal: to add the attribute format for input times Apr 11, 2019
@annevk annevk added addition/proposal New features or enhancements topic: forms labels Apr 11, 2019
@annevk
Copy link
Member

annevk commented Apr 11, 2019

https://html.spec.whatwg.org/#input-impl-notes already recommends implementations using the language specified by the web developer, but also, this is ultimately up to implementations as they get to decide what the UX is they want to present to their users.

@FANMixco
Copy link
Author

https://html.spec.whatwg.org/#input-impl-notes already recommends implementations using the language specified by the web developer, but also, this is ultimately up to implementations as they get to decide what the UX is they want to present to their users.

Hi @annevk thanks for your answer and I partially agree, but if there is no any attribute, I think vendors can skip it as the case of Chromium project that no reply and the point has been opened for years and might not change in the near future.

@annevk annevk added the i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. label Apr 11, 2019
@annevk
Copy link
Member

annevk commented Apr 11, 2019

To be clear, the attribute would be lang, that's what dictates the "language" concept. Perhaps form controls should have a dedicated locale attribute or some such though. Seems worth considering.

@kidwm
Copy link

kidwm commented Feb 19, 2022

@annevk It would be very useful that <input type="date"> to have dedicated locale attribute to support Intl.DateTimeFormat format, for example ja-JP-u-ca-japanese.

@aphillips
Copy link
Contributor

@kidwm lang can already support language tags with Unicode Locale extensions and is already built-in. There doesn't seem to be a use case for having a separate locale attribute. Under what circumstances would you want the lang and locale to be different from one another? (I agree that page authors might want to set it on the <input type="date"> to be different from the rest of the page, but that's different)

@kidwm
Copy link

kidwm commented Jan 31, 2024

@aphillips
Copy link
Contributor

@kidwb Thanks! I think my response might not have been clear. I agree and want very much for browsers to localize native controls to match the page experience my HTML page is trying to create. The question is, how, as a page author, can I get that experience?

Here are some examples of what that might look like.

In this one, there is an additional attribute locale as suggested elsewhere in this issue. I don't think locale makes sense, because it's not actually different from lang and I can't think of any cases in which lang and locale should be different:

<input type="date" lang="ja" locale="ja-JP-u-ca-japanese">

In this one, I just use lang, which is already built in.

<input type="date" lang="ja-JP-u-ca-japanese">

This one shows inheritance (in this case from the <p> tag), which I think is an important consideration. The second example shows having an input in a different language (locale) from the paragraph. The third one shows having the input set using the default (which is probably the user-agents's locale).

<p lang="ja-JP-u-ca-japanese">何日がご希望ですか?<input type="date"></p>
<p lang="ja-JP-u-ca-japanese">何日がご希望ですか?<input type="date" lang="en-US"></p>
<p lang="ja-JP-u-ca-japanese">何日がご希望ですか?<input type="date" lang=""></p>

Inheritance would allow all of the inputs (not just <input type="date"> to have their locale set by setting lang on the <html> tag:

<html lang="ja-JP-u-ca-japanese">
...
<input type="date">
...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addition/proposal New features or enhancements i18n-tracker Group bringing to attention of Internationalization, or tracked by i18n but not needing response. needs implementer interest Moving the issue forward requires implementers to express interest topic: forms
Development

No branches or pull requests

4 participants