State of CSS

Post by miiiiiike » Fri, Oct 21, 2022, 9:17 PM UTC

soperj wrote: post #143

fleddr wrote: post #138

It's so interesting, these waves of CSS improvements. Before the flexbox/grid arrival, there were years of near-zero progress. The flexbox/grid release, uniquely coordinated across browsers (for once), was an excellent milestone, but not really a movement. These last 2 years though feel almost like a revolution in comparison to CSS's history. Somebody is pushing very hard. These are some very serious improvements tha…

It's so annoying to me that there's one browser that's holding everyone back. They also make it so that no one can use anything but their browser engine on mobile phones so they're harder to ignore.

Post by [deleted] » Fri, Oct 21, 2022, 9:20 PM UTC

miiiiiike wrote: post #151

soperj wrote: post #143

Earlier quoted context omitted.

It's so annoying to me that there's one browser that's holding everyone back. They also make it so that no one can use anything but their browser engine on mobile phones so they're harder to ignore.

This is repeated over and over again, but, it’s not true when it comes to Safari’s support for CSS. Now, requiring a Mac to debug JS on mobile Safari.. That’s irritating.

Post by soperj » Fri, Oct 21, 2022, 9:23 PM UTC

the_gastropod wrote: post #144

soperj wrote: post #143

Earlier quoted context omitted.

It's so annoying to me that there's one browser that's holding everyone back. They also make it so that no one can use anything but their browser engine on mobile phones so they're harder to ignore.

Reading between the lines, it seems like you're suggesting Safari is that browser holding everyone back. The Compatibility section in this article doesn't seem to support that.

Post by easrng » Fri, Oct 21, 2022, 9:33 PM UTC

clairity wrote: post #69

lbotos wrote: post #50

Earlier quoted context omitted.

Right, my point is, we've now introduced this new attribute for "browser elements" instead of saying now checkboxes support background-color, color, etc. And let the designer do the work. Lean on the primitives we already have, enable flexibility, and if someone wants to make a SaSS wrapper or CSS function to do it, enable that vs. more random places for browsers to diverge on "standards". It plays out like this: "Oh…

i believe the problem with form elements like checkboxes is that they are 'replaced elements', which the browser defers to the underlying operating system, and that's why it requires a "hack" like accent-color rather than direct styling. this is also why you can't use ::before and ::after on form elements (to do things like add a 'required' indicator using css only).

Post by easrng » Fri, Oct 21, 2022, 9:42 PM UTC

lbotos wrote: post #67

irrational wrote: post #61

Earlier quoted context omitted.

For this? No. Years ago we were working on a project and the default color of the form elements was a real sticking point. For some of them we ended up rolling our own, but others we just suffered with the default. Accent-color would have solved a problem we spent months working on and agonizing over.

See my reply below: https://news.ycombinator.com/item?id=33289468 If you were able to style the element with "classic" CSS primitives like border/background/color would that not have also solved the problem without introducing new syntax with new quirks?

  input[type="range"]::-moz-range-thumb,
  input[type="range"]::-webkit-slider-thumb {
    background-color: red;
  }

  input[type="range"]::-moz-range-thumb {
    background-color: red;
  }
  input[type="range"]::-webkit-slider-thumb {
    background-color: red;
  }