Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

State of CSS

web.dev

Post reply on HN
Print view View original

81–90 of 234 posts

Re: State of CSS

#81

Post by arrow7000 »

yakshaving_jgt wrote: post #77
arrow7000 wrote: post #70

Earlier quoted context omitted.

Is it really "needlessly" complex if this is enabling styling that wasn't possible before? Re your second point that CSS might become a compilation target for styling... have you never heard of Sass, Less, Tailwind, or any of a million UI frameworks that provide alternative ways to write CSS, or even avoid writing it directly altogether? This isn't exactly new.

> Is it really "needlessly" complex if this is enabling styling that wasn't possible before? Many newer features that have been added over the years don't actually enable anything new. Not that I'm arguing in favour of table-based layouts either. > have you never heard of Sass, Less, Tailwind, or any of a million UI frameworks that provide alternative ways to write CSS, or even avoid writing it directly altogether? T…

How do you propose we get to such a language that is more than a superset of the status quo if CSS, the compilation target itself, is severely limited?

Re: State of CSS

#83

Post by clairity »

martin_a wrote: post #20

I find most of this useless/overcomplicated. > Cascade layers Feels like we only need this because cascading works less and less well once you start to include multiple frameworks or pieces thereof. At some point people find themselves in a jungle of !important. If you keep the cascade small and clean, you'll most likely not need that. > Container queries Probably the designs I have to implement are not complicated e…

:has() is my most anticipated as well. it has the biggest potential to not only simplify our html (e.g., divitis) but also remove the need for js compensations in many content-oriented sites. come on firefox, let's get :has() across the finish line!

container queries are also neat, but still rely on having a wrapper container, which isn't ideal--why can't i style the component itself based on its own calculated height/width rather than having to involve a parent element?

i'm still waiting for chrome to implement subgrid, which will simplify any kind of card-type layout.

i also wish we had native "mixins" (@apply had this potential, but it was removed from the spec), so we could have a bundle of styles we could inject into different declarations as a group. then you could have different sets of styles in orthogonal groups (layout, spacing, border, text, inline) that you could apply in any combination. this is especially useful if you want to style a base html element a certain way and then also have a utility class with the same style later in the stylesheet (with maybe a slight tweak) that can be applied to more than just that type of element (like s, s, and s).

edit: oh, and lch/oklch for more perceptually uniform and expanded colorspaces, combined with the new color functions (e.g., color-mix) is exciting too.

Re: State of CSS

#84

Post by yakshaving_jgt »

arrow7000 wrote: post #81
yakshaving_jgt wrote: post #77

Earlier quoted context omitted.

> Is it really "needlessly" complex if this is enabling styling that wasn't possible before? Many newer features that have been added over the years don't actually enable anything new. Not that I'm arguing in favour of table-based layouts either. > have you never heard of Sass, Less, Tailwind, or any of a million UI frameworks that provide alternative ways to write CSS, or even avoid writing it directly altogether? T…

How do you propose we get to such a language that is more than a superset of the status quo if CSS, the compilation target itself, is severely limited?

…That's the entire point of abstraction.

I'm guessing you aren't writing binary in your day to day work, are you? I'm fairly certain whichever language you're working with is more featureful and ergonomic than working directly in binary.

Similarly, Elm has a different surface area from JavaScript, and yet JavaScript is the compilation target.

CSS doesn't need to be featureful to be a compilation target.

Re: State of CSS

#85

Post by tjpnz »

reaperducer wrote: post #49
toastercat wrote: post #2

Great overview. I'm always excited by newer features to CSS that make older JS-only methods obsolete. I've also grown CSS-tooling fatigued after using SASS and PostCSS plugins for years. I've recently gone back to only using vanilla CSS on personal projects and while there are niceties I do miss (nesting) it's refreshing not having to deal with config files or waiting for stuff to compile.

I'm always excited by newer features to CSS that make older JS-only methods obsolete. I wonder if it's just about how some people's brains are wired. I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript. But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me…

Only one of those options stands a chance of rendering in my browser.

Re: State of CSS

#86

Post by andrewmcwatters »

nicoburns wrote: post #24
andrewmcwatters wrote: post #15

CSS keeps getting larger and larger which I think on its face is actually fine, since all of the standards are extended modules. So if you think about it that way, as an implementor you can choose which standards you want to incorporate and have total coverage for particular parts of the spec. But the state of CSS for implementors is still abysmal, in my opinion, and I'd like to see more of the spec formally defined…

As someone who's recently been working on an implementation of CSS Grid, and reading through a lot of CSS specs, I completely agree. There's a lot that isn't in the specs. The CSS Grid one isn't even that bad, but the spec for "flow layout" (block and inline) looks like a complete mess. An HTML5 moment for CSS would be very welcome.

Yes! You know exactly what I'm talking about!!

I'm hysterical about the state of affairs for these exact sorts of things, but comparatively almost no one is an implementor, so most people have no idea how bad it can be.

Re: State of CSS

#87

Post by 9dev »

jjcm wrote: post #78

Interesting to see a lot of negative responses here. I'm quite excited for a large amount of these items. @container queries are going to help a ton in making components more reusable - components that react to their own size rather than the browser size have been needed for a long time, and currently the only way to really do it is with the javascript observer api, which comes with huge performance tradeoffs. Color-…

I mean, you already could store Color tuples in CSS variables:

  --color-primary: 172,250,83;
  background: rgba(var(--color-primary), 0.4);
But I agree, that isn’t very intuitive.

Re: State of CSS

#88

Post by andrewmcwatters »

pjmlp wrote: post #36
andrewmcwatters wrote: post #15

CSS keeps getting larger and larger which I think on its face is actually fine, since all of the standards are extended modules. So if you think about it that way, as an implementor you can choose which standards you want to incorporate and have total coverage for particular parts of the spec. But the state of CSS for implementors is still abysmal, in my opinion, and I'd like to see more of the spec formally defined…

This is why, I can only assert I can do "fullstack" for native applications on Windows and Android, for web development I am certainly on backend side, no way I can keep track of what CSS works where, and which incantations to make divs behave like native controls.

It's also nearly 100% guaranteed that while people say they're a master at CSS, there are probably only a miniscule amount of people who have read how CSS rasterizers actually work.

I'd almost bet there are probably more people who have reimplemented OpenGL in software than people who have read and understand how CSS compositors work.

For example, if you asked someone how user agents create backing tiles for CSS, they'd look at you like you spoke in a foreign language.

You totally don't need to know this stuff, but if you were doing say, high-perf UIs in WebKit (iOS), you'd probably at least want to know how to hint to WebKit that something needs its own render target or how to minimize subtree redraw.

I built massively performant large UIs for payroll systems on iPad years ago and found that if you optimized your UI just right, you could get smooth scroll performance that showed cracks in how fast the iPad was able to draw backing tiles at the time.

You'd get whole squares black scrolled into view while WebKit asynchronously drew in elements.

Re: State of CSS

#89

Post by naillo »

lbotos wrote: post #3

Does anyone else feel like CSS has jumped the shark a bit? https://web.dev/state-of-css-2022/#accent-color Sure it's a "nice to have" but it bloats the spec? Look at the current actual implementation: https://web.dev/accent-color/#guaranteeing-contrast chrome and firefox already tint differently... How is this better than a good ol CSS variable and leaving it up to the designer to manage? Sure http://dowebsitesneedto…

I guess all these additions are incentivized by google etc loving the fact that it makes the moat to make competing browsers wider and wider. Imagine trying to make a new browser from scratch in 2022 and supporting the 20+ years of bloat like this (not to mention future plans).

Re: State of CSS

#90

Post by [deleted] »

tjpnz wrote: post #85
reaperducer wrote: post #49

Earlier quoted context omitted.

I'm always excited by newer features to CSS that make older JS-only methods obsolete. I wonder if it's just about how some people's brains are wired. I grok CSS. I won't claim to know everything about it, but I'd say I'm 90% proficient and prefer it to JavaScript. But I think this is because JavaScript somehow never fully made sense to me. I can read it and figure out what it's doing, but it was never intuitive to me…

Only one of those options stands a chance of rendering in my browser.

[deleted]
Post reply on HN