[nemetroid]

Surely date widgets that behave subtly different depending on what website you’re currently visiting would be more confusing.

> Date controls aren't context sensitive like humans would write dates, they're client-culture-settings sensitive.

For what it’s worth, whenever I have to write a date on an American-authored form, I use YYYY-MM-DD, as do all my colleagues.

[emn13]

Definitely not, from experience. Browser widgets need to be context sensitive, not client sensitive. There are (at least!) two simple reasons to see that: firstly, non-browser site provided controls are more common, and those are context sensitive, so it's quite unusual and surprising when a date-widget suddenly is not context sensitive merely because it's using the browser default. Secondly, date controls display dates even when unopened, and in that mode - the default, initial mode upon page load - they look like plain text with some mild styling to indicate interactivity. Dates in plain text should behave like other dates in plain text - i.e. context-sensitively.

To reiterate, there is an obvious, correct implementation here: let the site specify the content culture much like it does the language, and fall back to the user's choice when unspecified. The spec is asking for user confusion and data corruption as-is, which contributes to why usage of date controls remains fairly low.