1646304 - input[type=date] with value NOT in format yyyy-mm-dd

Status: UNCONFIRMED

(Core :: Layout: Form Controls, enhancement)

Description

[txc]

Attachment: 3 versions for value-format in input type date

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

Simple input type=date field with value="01.07.2020"

Actual results:

input-field shows "TT.MM.JJJJ" (but still has value="01.07.2020")

Expected results:

input-field should show "01.07.2020"

If i give value="2020-07-01" - is shows correct "01.07.2020".
I need dates shown formated to dd.mm.YYYY - of course i give the value this format and the browser should handle with it. Using e.g. Safari - value is shown like it is.

If i use US date-format mm/dd/YYYY - same happens.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

As far as I can tell, the format is locale dependent: https://searchfox.org/mozilla-central/rev/2c1092dc68c63f7bad6da6a03c5883a5ab5ff2ca/toolkit/content/widgets/datetimebox.js#740-794 / https://searchfox.org/mozilla-central/rev/2c1092dc68c63f7bad6da6a03c5883a5ab5ff2ca/toolkit/content/widgets/datetimebox.js#90

For other stuff like <input type=number>, we respect the lang attribute first, maybe we should do that for date as well?

Zibi / Jonathan, do any of you have strong opinions on this? I can see the value on just respecting the user's locale.

Comment 3

[Jonathan Kew [:jfkthame]]

It looks to me from https://html.spec.whatwg.org/multipage/input.html#date-state-(type=date) as though only the ISO format yyyy-mm-dd is supposed to be accepted for the value of an <input type=date> element: "User agents must not allow the user to set the value to a non-empty string that is not a valid date string", where "valid date string" is defined by https://html.spec.whatwg.org/multipage/common-microsyntaxes.html#dates.

What I'm seeing in Nightly, at least, is that if I try to set the value to a date in en-US or en-GB format, for example <input type=date value="01/03/2020">, inspecting the value attribute returns an empty string, not the string I set.

Allowing the value to be set in some other format -- especially a format that is dependent on the user's locale -- seems risky: it's likely to lead to confusion when scripts written assuming a certain locale are run on users' machines where a different locale is in effect.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

Sure, I was talking about displaying the value. <input type=date lang="en-GB"> would display differently from <input type=date lang=es>.

Comment 5

[Zibi Braniecki [:zbraniecki][:gandalf]]

Allowing the value to be set in some other format -- especially a format that is dependent on the user's locale -- seems risky: it's likely to lead to confusion when scripts written assuming a certain locale are run on users' machines where a different locale is in effect.

I agree. We have very bad experience with trying to parse different date formats. The standards today often focus on minimizing that risk and I expect this standard to also have this motivation.

Sure, I was talking about displaying the value. <input type=date lang="en-GB"> would display differently from <input type=date lang=es>.

That's different than this bug's description. The user is asking about date parsing, not displaying.

On the topic of lang attribute the spec says:

Browsers are encouraged to use user interfaces that present dates, times, and numbers according to the conventions of either the locale implied by the input element's language or the user's preferred locale. Using the page's locale will ensure consistency with page-provided data. 

This is a really bizarre sentence which recommends using input's lang attribute, or user's locale, but then states that using page's locale will ensure consistency.

It seems (maybe?) that the spec recommends respecting lang attribute, so I think we should. As to what to do in an absence of that attribute is confusing to me.

Comment 6

[Jonathan Kew [:jfkthame]]

It's not really clear in my mind whether respecting the lang attribute when displaying <input type=date> would be a good thing. If I set my locale to en-GB, I expect dates throughout my system to be displayed in dd/mm/yyyy format; it's potentially pretty confusing if some pages (which happen to have lang=en-US) end up using mm/dd/yyyy in their input elements.

I'm aware, as an en-GB user, that when I read US English pages (e.g. news sites) they'll often give dates in the en-US form, and I have to make the appropriate mental conversion. But <input type=date> is a UI widget that I tend to think of more as part of my local platform -- which is configured as en-GB -- than as part of the "foreign-locale" page. Just like the browser respects my local (system) choice of keyboard layout when I'm typing in a text area, I'm inclined to think it should respect my local choice of date format when using a date input widget.

I'm not sure what to think here... I can see a possible argument for consistency with the context of the page, but it's not at all clear-cut.

Comment 7

[Emilio Cobos Álvarez (:emilio)]

Right, I tend to agree, though when I removed the code in <input type=number> that localized based on the lang attribute I ended up having to revert due to the high amount of dupes, see bug 1622221.