Live data from Hacker News

Show HN: CSS Extras

github.com

31–40 of 66 posts

Re: Show HN: CSS Extras

#32

CSS is changing so fast. I guess we will see Doom in CSS shortly

This may feel true if you've re-engaged with CSS's progression in the last ~5–7 years. In reality, the last big qualitative leap was Grid in 2017.

This project is based on just one new proposed rule which won't be available in all mainstream browsers until 2027-28, and won't be safe for production use until close to the end of the decade.

Re: Show HN: CSS Extras

#34

CSS is changing so fast. I guess we will see Doom in CSS shortly

This may feel true if you've re-engaged with CSS's progression in the last ~5–7 years. In reality, the last big qualitative leap was Grid in 2017. This project is based on just one new proposed rule which won't be available in all mainstream browsers until 2027-28, and won't be safe for production use until close to the end of the decade.

In reality, CSS's big changes are a drumbeat pounding monthly: https://developer.chrome.com/blog/css-wrapped-2023 https://chrome.dev/css-wrapped-2024/

Of note from 2023: subgrids, :has, container queries, nesting... And in 2022, cascade layers (plus , I mean @scope, I mean :scope).

Re: Show HN: CSS Extras

#35
post #25

Earlier quoted context omitted.

But there are also plenty of use cases where recalculation will be valuable in the client. CSS variables cascade so a preprocessor isn't going to be able to know ahead of time what any given variable value is.

Sure, the new syntax allows doing some nifty stuff with the cascade. In practice, however, I foresee most usage being simple one-time transformations of design tokens. I suppose it is more of a theme architecturing issue.

It’s the same with Custom Properties. There are plenty of situations where they are useful at runtime, but a lot of their use is just a single definition on :root, and people really would be better served by the likes of Sass variables, because they foil all kinds of optimisations. You end up with things like color-mix(in srgb, var(--some-unreasonably-long-name), transparent) where it could have just been #1234567f. Quite apart from the runtime and memory costs, bundle size (even gzipped size) can frequently be reduced drastically by flattening eligible variables.

Re: Show HN: CSS Extras

#36
post #13
post #12

Earlier quoted context omitted.

> is it really necessary to have this as an npm package ? Is anything really necessary? Not snark: almost nothing is necessary in life but many things are convenient .

Surely a cdn is more convenient. I don't want to install an entire package manager just to 'install' 2 CSS files.

Please, no! https://csswizardry.com/2019/05/self-host-your-static-assets...

Re: Show HN: CSS Extras

#37

Welp, time to make a @function preprocessor. There is no reason for every single client to recalculate things which could have been completely or partially calculated at build time.

I used to share this sentiment (and I’m a web performance consultant by profession so very few people care about performance as much as me!), but when you consider how much calculation we _happily_ let our JS do at runtime, I don’t think forcing CSS to be static/preprocessed is worth it. And that’s not even me taking a swipe at overly-JSsed front-end; I’m talking about any runtime work that JS picks up.

Is preprocessed CSS faster? Yes. Is it meaningfully faster? Probably not.

Re: Show HN: CSS Extras

#39

I’m so confused why people are ragging on this. Why is this considered detrimental? Looks pretty good to me…

It's a post about web development on HN. Half the comments will rag incessantly, half will talk about how the web should go back to being a delivery mechanism for documents only like it's 1995 forever, someone will rant about Google for some reason. It's a neverending nightmare.

Re: Show HN: CSS Extras

#40
post #13
post #12

Earlier quoted context omitted.

> is it really necessary to have this as an npm package ? Is anything really necessary? Not snark: almost nothing is necessary in life but many things are convenient .

Surely a cdn is more convenient. I don't want to install an entire package manager just to 'install' 2 CSS files.

Sure, if you don't like Chinese users. The Great Firewall does not like at least some CDNs.

They also happen to be a great attack vector! You and your users are much better off not using them for anything but toys.

Post reply on HN