34 ms·

Input for dates has many issues with styling, cross-browser compatibility and various formats/locales. Meter has a nonsensical data model and no standard way o

Input for dates has many issues with styling, cross-browser compatibility and various formats/locales. Meter has a nonsensical data model and no standard way of styling it. Dialog is a half-assed element that's useless without large amount of styling and code. For its sake they've added an additional form method, which will likely break many older JS libraries. Mind you, we're talking about controls that have been faked or implemented on the web by developers for at least two decades. This is pitiful.

ikiris 4y ago
https://xkcd.com/927/ https://xkcd.com/927/
inopinatus 4y ago
In practice, I’m pretty happy with how dialog turned out. I certainly do not find it needing a “large amount of styling and code” to obtain immediate utility. I’ll readily agree, however, that the meter element is trash, and date input an underspecified UX crapshoot. My biggest beef with Apple’s standards engagement, however, is their intransigent and ill-considered refusal to implement customised built-in elements.
tehbeard 4y ago
Your first two points are valid, and a wider issue with styling form pseudo element internals, though I'll contest letting date visualize as the user's locale is a better option than forcing American month/day/year weirdness on the rest of us. You're wrong on dialog though. It's not half assed, it's the core functionality needed for a dialog, no more. It makes very few assumptions abouts you want your dialogs to look, or behave with closing/opening. You only have to build atop it, rather than strip it back (e.g. Like how you have to strip/reset lists to use as nav menu elements) I've styled them and it's usually less css than equivalent bootstrap or homegrown dialogs. I also doubt your claims that the new form method will break older js being a real problem. The method just allows js to get a standard way of how a dialog closed. I just don't see when you'd use old js that might have issues to handle that..

ikiris 4y ago

https://xkcd.com/927/ https://xkcd.com/927/

inopinatus 4y ago

In practice, I’m pretty happy with how dialog turned out. I certainly do not find it needing a “large amount of styling and code” to obtain immediate utility. I’ll readily agree, however, that the meter element is trash, and date input an underspecified UX crapshoot. My biggest beef with Apple’s standards engagement, however, is their intransigent and ill-considered refusal to implement customised built-in elements.

tehbeard 4y ago

Your first two points are valid, and a wider issue with styling form pseudo element internals, though I'll contest letting date visualize as the user's locale is a better option than forcing American month/day/year weirdness on the rest of us. You're wrong on dialog though. It's not half assed, it's the core functionality needed for a dialog, no more. It makes very few assumptions abouts you want your dialogs to look, or behave with closing/opening. You only have to build atop it, rather than strip it back (e.g. Like how you have to strip/reset lists to use as nav menu elements) I've styled them and it's usually less css than equivalent bootstrap or homegrown dialogs. I also doubt your claims that the new form method will break older js being a real problem. The method just allows js to get a standard way of how a dialog closed. I just don't see when you'd use old js that might have issues to handle that..