Remove input[type=datetime]

[tkent-google]

https://html.spec.whatwg.org/multipage/forms.html#date-and-time-state-(type=datetime)

Because there is no implementation now though Presto Opera had it.
We don't have a plan to implement it in Blink.

Presto: All input types were supported.
Blink: datetime is not supported.
Edge 13.10586: datetime is not supported.
Mobile Safari: datetime is not supported.
Mobile Firefox: month, week, datetime, and datetime-local are not supported.
Desktop Safari: date, datetime, datetime-local, month, time, and week are not supported.
Desktop Firefox: date, datetime, datetime-local, month, time, and week are not supported.

[annevk]

I guess it's too late to rename datetime-local to datetime. Bit of a shame. Would making them an alias work?

[foolip]

Relevant use counters:

• InputTypeDateTimeFallback for when type=datetime falls back to the behavior of type=text.
• InputTypeDateTimeLocal for type=datetime-local.

Both are counted only when the computed style is is not visibility:hidden. (Not sure why, there are many other ways to not be visible.)

[annevk]

From that it seems that neither is really used. @hober, do you have views on this? @travisleithead?

[tkent-google]

We received multiple bug reports when we introduced a regression of input[type=datetime-local] in Blink. So, I think it has real users, and we won't remove it.

[annevk]

Alright, I guess removing datetime first would be good. We can always reconsider later if we want to make it an alias for datetime-local.

[tkent-google]

😄 Thanks!

[annevk]

Thank you for the suggestion!

[stuartpb]

What's the new (existing) suggested best practice for unambiguous time point entry now? Have a datetime-local alongside a dropdown for picking the time zone?

[foolip]

That or an entirely custom component, I guess.

[domenic]

FWIW that's what Outlook does :)