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

131–140 of 234 posts

Re: State of CSS

#131

Post by RunSet »

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…

I suspect google wants Turing-complete CSS to make it easier to invade privacy when javascript is disabled.

Letting the world's largest advertising corporation be in charge of browser standards is probably not the best idea.

Re: State of CSS

#132

Post by alvarlagerlof »

activitypea wrote: post #128
arrow7000 wrote: post #74

Earlier quoted context omitted.

No. If you have to write styling in JS I can guarantee that it will be far more brittle, less performant, and way more susceptible to FOUCs, reflows, jank, and potentially deadlocks of conflicting resizing elements than the equivalent in CSS.

All of which is preferable to an ever-growing spec whose pace makes it impossible for a newcomer to enter the browser space.

JavaScript simply shouldn't handle a lot of layout. It's not running in sync with the layout engine in css.

Re: State of CSS

#133

Post by nicoburns »

asiachick wrote: post #120
andrewmcwatters wrote: post #86

Earlier quoted context omitted.

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.

IIRC the way someone reimplemented flexbox was to take the layout tests and iterate until their implementation passed. https://yogalayout.com/

Yes, but the fact that someone had to do this makes it clear that the spec isn't complete. A complete spec would state the algorithm unambiguously. You might still need to fix bugs based on tests, but you shouldn't need to be working about behaviour because it's unspecified.

Re: State of CSS

#134

Post by Dma54rhs »

jandrese wrote: post #107
asiachick wrote: post #105

Earlier quoted context omitted.

crapping on tables was arguably correct. flexbox and grid allow for responsive designs (work on phone and desktop). Table based layouts do not.

Crapping on tables is fine. Offering no replacement was not.

Everything old still works?

Re: State of CSS

#135

Post by jozzy-james »

TheRealPomax wrote: post #102
9dev wrote: post #40

Earlier quoted context omitted.

The sweet spot for me is Vite, which comes with PostCSS built-in, and the nesting plug-in which follows the CSS spec. Vite takes care of the boring stuff, I can write vanilla CSS with nested declarations in it, and it just works.

But what Vite didn't have to do anything because CSS already comes with nesting? CSS nesting was proposed over eleven years ago, and is only today finally making it into a single browser, behind an experimental flag. Three major preprocessing languages were invented and two of those (mostly) died off again in the mean time. We shouldn't need preprocessing here, we should have had nesting ten years ago =)

to be fair, preprocessing comes with some other QoL things that I don't see CSS being able to support natively, namely mixins with math functions.

edit: don't get me wrong, i'd love to be 100% native CSS, but there are some things where preprocessors shine

Re: State of CSS

#136

Post by 323 »

andrewmcwatters wrote: post #88
pjmlp wrote: post #36

Earlier quoted context omitted.

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, the…

Why does a payroll system UI need game-engine level performance?

Re: State of CSS

#137

Post by TheRealPomax »

jozzy-james wrote: post #135
TheRealPomax wrote: post #102

Earlier quoted context omitted.

But what Vite didn't have to do anything because CSS already comes with nesting? CSS nesting was proposed over eleven years ago, and is only today finally making it into a single browser, behind an experimental flag. Three major preprocessing languages were invented and two of those (mostly) died off again in the mean time. We shouldn't need preprocessing here, we should have had nesting ten years ago =)

to be fair, preprocessing comes with some other QoL things that I don't see CSS being able to support natively, namely mixins with math functions. edit: don't get me wrong, i'd love to be 100% native CSS, but there are some things where preprocessors shine

Right, but the only reason they shine is because they do something we all want but isn't in the spec. So getting it into the spec should absolutely be the goal here =D

Re: State of CSS

#138

Post by fleddr »

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 that address core needs and gaps. In particular scaling CSS in large applications, with things like @layers, @scope and container queries.

The second goal seems to be to make CSS preprocessors obsolete.

Compliments to whoever is working on this. My favorite upcoming one has to be toggle, controversial or not, the idea that for simple interactions you don't even require JS anymore is a good development.

The luxury problem this creates is the slow adoption rate. Something extraordinarily powerful as grid is still barely used. Old habits die hard.

Re: State of CSS

#139

Post by jetzzz »

What's the purpose of having 4 linear color spaces (srgb-linear, xyz, xyz-d50, xyz-d65) for interpolation? Linear interpolation is exactly the same in any linear space. Indeed, in provided gradient examples these 4 look the same.

Re: State of CSS

#140

Post by encryptluks2 »

laundermaf wrote: post #116
encryptluks2 wrote: post #28

Can't believe paged media isn't really supported yet. Trying to do anything like line numbers for legal documents or page numbers is an absolute nightmare.

Page media has been supported for decades. Line numbers aren’t strictly related to page media. It’s hard to complain about the lack of in-depth support for a media that isn’t meant to display “the web”. I do agree that it could be better. They have been adding print-related features though, at least I remember some in CSS3. CSS Colors Level 4 includes cmyk functions.

I don't think "it isn't meant" is accurate anymore. The browser has become meant for all things including document creation and styling. The @page counter feature although documented isn't supported by any browser from what I can tell at this point.
Post reply on HN