5 ms·

>this really strikes me as evidence that something is wrong with the http standardization process. The overall decision-making around how the web works is insa

>this really strikes me as evidence that something is wrong with the http standardization process. The overall decision-making around how the web works is insane and getting more insane by the year. We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Worse, some problems are finally solved in such a half-assed way that it's almost worse than having no solution at all. (Input type="date", meter element, dialog element etc.) This is not at all what I imagined the field would look like when I entered it nearly two decades ago.

pixl97 4y ago
>We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Why is this surprising? Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. Add to that large numbers of groups will have their own set of opinions on what the best solution is, and it will conflict with some ideas.
- BrainVirus 4y ago
  >Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. This is completely backwards. Universal problems on the web are routinely solved by everyone designing a standard website. They often have fairly standard solutions. Browser vendors routinely fail to generalize the experience of run-of-the-mill web developers. It's not about engineering. It's about misaligned incentives and operating from a bad frame of reference.
modeless 4y ago
> We have fairly trivial and absolutely universal problems unsolved for decades This describes most areas of applied computer science, honestly. Language design, build systems, operating systems, etc. When standards and/or widely used systems are involved, nothing is trivial. And the web is the most widely used and most standards-based system out there.
tehbeard 4y ago
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..

pixl97 4y ago

>We have fairly trivial and absolutely universal problems unsolved for decades, while browsers get crammed full of features that aren't used by 99.9% of websites. Why is this surprising? Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. Add to that large numbers of groups will have their own set of opinions on what the best solution is, and it will conflict with some ideas.

BrainVirus 4y ago
>Universal problems are hard to solve otherwise it wouldn't be a universal problem in the first place. This is completely backwards. Universal problems on the web are routinely solved by everyone designing a standard website. They often have fairly standard solutions. Browser vendors routinely fail to generalize the experience of run-of-the-mill web developers. It's not about engineering. It's about misaligned incentives and operating from a bad frame of reference.

modeless 4y ago

> We have fairly trivial and absolutely universal problems unsolved for decades This describes most areas of applied computer science, honestly. Language design, build systems, operating systems, etc. When standards and/or widely used systems are involved, nothing is trivial. And the web is the most widely used and most standards-based system out there.

tehbeard 4y ago

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