41–50 of 66 posts
I’m so confused why people are ragging on this. Why is this considered detrimental? Looks pretty good to me…
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 preprocess…
In the context of animations, I'd intuit the latter but would be open to hearing why.
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.
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.
I’m so confused why people are ragging on this. Why is this considered detrimental? Looks pretty good to me…
(I'm not weighing in on the validity of this position, just reporting what I perceive the position itself to be.)
Obvious question: are CSS functions Turing complete?
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.
(I work with CSS browser performance, although animations is not my primary field)
Obvious question: are CSS functions Turing complete?
CSS in general is Turing complete if you allow running multiple frames, although it requires ugly hacks. See e.g. https://codepen.io/propjockey/pen/dywNyBQ, which is quite insane IMO.
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)?
Obvious question: are CSS functions Turing complete?