51–60 of 66 posts
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.
Earlier quoted context omitted.
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 preprocess…
An optimisation I've always wondered about for transforming/translating/animating elements: is it faster to use JS translations or animation API directly on the element (e.g. style.transform / element.animate), or updating CSS variables with JS to let the CSS engine reposition inheriting elements? In the context of animations, I'd intuit the latter but would be open to hearing why.
Obvious question: are CSS functions Turing complete?
Kinda clever, actually.
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.
What goes in some people's mind when they come up with these ugly conventions and rules?
It is time to reject this ugly double dash prefix kebab-cased variables names. PHP looks better in comparison. What goes in some people's mind when they come up with these ugly conventions and rules?
CSS is becoming the new JavaScript.
It would be quite nice to see some more "killer" uses of this new feature that aren't just "we removed some duplication and... saved less than 1% of our loc". And maybe there are some really compelling ones... I think the only really useful one I see here is `--abs`, which really should just be built-in.
abs() exists with cross-browser support: https://developer.mozilla.org/en-US/docs/Web/CSS/abs There are also other non-custom math functions like round() which can be very useful.
Whoo. I’ll be the first hyper negative prototypical HN commenter. I’m glad I don’t work on browser engines for a living. CSS is getting more complex and spaghetti-capable by the day. > Currently only supported in Chrome 141+. The @function rule is going through the W3C standardization process and will be available in other browsers soon. Also, pretty tired of Chrome effectively front-running standards as a not-so-sub…
One person's front-running is another's reference implementation. Although, yes, CSS is getting more complex because everything on the web is. What's the last standard feature to really be taken away after actually existing in the wild for a while? XHTML and Flash (effectively a standard if not in reality)?
It is time to reject this ugly double dash prefix kebab-cased variables names. PHP looks better in comparison. What goes in some people's mind when they come up with these ugly conventions and rules?
Utility based libraries tend to avoid this these days and use simpler names, but those are also supposed to be your root libraries, not your custom CSS.