Can you elaborate on what you mean by date ordering?
I suppose that the ordering of dates is independent of locale.
The locale rules for the date format are simple:
the DOM value property of the field is a string in YYYY-MM-DD format, independent of locale.
The date display format and what the text input accepts depend on browser locale.
Conversion happens automatically and the text input is shown in a way that indicates locale on desktop, least I remember (e.g. dots for European format, slashes for US). If a user enters "1.5.2011" in a browser with German locale, HTMLInputElement.value would be the string "2011-05-01" (invisible to the user).
I honestly can't think of any better choices, the only thing missing is some attribute to eplicitly control display locale. Which is probably by design, as it would be abused to override system/browser locale and create confusion.
I once replaced a Vue date picker library in a web app with native date inputs for UX reasons (e.g. typable dates, reliable visibility of the picker when fields are near window borders, mobile UI...) and users were reportedly happy with that.
Admittedly, it was mainly a desktop app.
So, long story short: the only problem I see here is the mobile modal date picker UX.
And thankfully, it can be improved in the future because it's part of the OS and not controlled by the website.
All of this is thankfully resolved by the spec choice to stick to a specific ISO string format for the value property.
You are talking about locale-dependent formats - which is why the value property of the input element conforms to ISO 8601 YYYY-MM-DD and guarantees that the values are predictably sortable.
There is no other meaningful ordering of dates other than sorting chronologically.
HTMLInputElement with type=date honestly does everything right given the constraints.
As said, this post is a valid complaint about mobile native UI, no less no more.
The problem isn't the machine-readable encoding that indeed happens to use the ISO YMD ordering, its that you can have a site that's in language/culture X, which includes dates related to whatever events or moments are relevant, but also includes a form with a date-field ordering that is _different_ from that of the text and possibly date fields, and _different_ from the convention in language/culture X.
Actual human language is context sensitive. The user's date formatting preference is almost a non-sequitur even as a concept. People fundamentally can't pick whatever date formatting they want in general-purpose content; they'll need to be able to understand whatever is the norm in that context. And in most contexts while there are various date forms, they're usually not (problematically) ambiguous. As long as a user stays within one date-formatting bubble, that's fine, but it just works really poorly if a user does not. Within an application that's primarily concerned with dates and in which every date is a specially typed value, like say a calendar - sure, date formatting preferences are feasible. That however describes a rather small fraction of the overall web. And the textual, machine-comprehensible hypertext web itself, while eating the world, is itself still only part of culture; dates are visible in videos, images, books, magazines, etc - and they make sense in those contexts _in context_ - i.e. _not_ using the client's date formatting preferences.
If a user's date-formatting preferences were to really have meaning on the web, you'd need to ensure that even dates in plain text or written summaries satisfy that formatting, and hope that videos and images rarely are mixed with such text. But that's just not the norm, and likely completely impractical; it'll never happen, especially not given the reality that many dates are manually written by humans without any markup at all. And where software tries to "fix" that - well, you get disasters like Excel, which is notorious for causing insidious data-corruption by trying to guess data-types in pretty creative and unhelpful ways.
In practice that's not what sites _actually_ do. They either have really simplistic date handling, in which case date controls can be confusing but rare enough that it's not hugely impactful, _or_ they use custom date controls (the actual norm). And that makes browser date controls _even_ worse, because those will then unpredictably not use the context culture, but instead the client's culture - unlike most sites, which don't use input type=date as far as I can tell.
The correct solution would be to allow a site to specify the site's culture and formatting settings, much like language can be specified. And if none is specified: sure, fall back to the user's date preference.
I suppose that the ordering of dates is independent of locale.
The locale rules for the date format are simple: the DOM value property of the field is a string in YYYY-MM-DD format, independent of locale.
The date display format and what the text input accepts depend on browser locale.
Conversion happens automatically and the text input is shown in a way that indicates locale on desktop, least I remember (e.g. dots for European format, slashes for US). If a user enters "1.5.2011" in a browser with German locale, HTMLInputElement.value would be the string "2011-05-01" (invisible to the user).
I honestly can't think of any better choices, the only thing missing is some attribute to eplicitly control display locale. Which is probably by design, as it would be abused to override system/browser locale and create confusion.
I once replaced a Vue date picker library in a web app with native date inputs for UX reasons (e.g. typable dates, reliable visibility of the picker when fields are near window borders, mobile UI...) and users were reportedly happy with that.
Admittedly, it was mainly a desktop app.
So, long story short: the only problem I see here is the mobile modal date picker UX. And thankfully, it can be improved in the future because it's part of the OS and not controlled by the website.