4 ms·

You want to explain your examples? Because what I see is: - A working element that only got half assed/ignored by one provider (Apple, but who's surprised?) w

You want to explain your examples? Because what I see is: - A working element that only got half assed/ignored by one provider (Apple, but who's surprised?) which meant polyfills for years to fix it. - A niche element, there are plenty of those? - A relatively new element that solves a lot of issues with Z layer, accessibility etc and is a good basis for other components/libraries to use for their styled/enhanced modal dialogs.

BrainVirus 4y ago
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..

BrainVirus 4y ago

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..