Post

Anthony Frehner
@frehner.me

THIS COMMON CSS FEATURE TANKS YOUR PERFORMANCE!!1!1! Ok, how was that for a flamebait headline? For real, though, let's talk about `@property` Do you lazy load content to improve performance? Did you know that, if your lazily-loaded CSS includes `@property`, you're causing a full dom restyle?

5 reposts33 likes

Anthony Frehner
@frehner.me

If you have a large DOM / heavy content / lots of features running when that happens, that can really hurt. So, what if we could have a non-global `@property` at-rule to limit the restyling to just what was loaded? frehner.me/blog/non-glo... THIS IS NOT "SCOPED" `@property`!

frehner.meA proposal for non-global @property at-rulesWithout changing how CSS Custom Properties behave, let's see if we can optimize how they perform when lazily loaded and defined within a selector.
Anthony Frehner
@frehner.me

I don't want to change how CSS Custom Properties cascade; I don't want to "stop" the value cascade at a certain point. Don't bring the word "scope" into this! haha. I just want a non-global `@property`, that only applies to a selector, and that doesn't cause a full DOM restyle when loaded.

Anthony Frehner
@frehner.me

This would help wonderfully with lazy loading content via your framework of choice (e.g. React.lazy), and/or HTML's new `<template for="">` "out-of-order patching", etc etc I just want teams to own their own `@property` at-rules, lazy load them, and not affect the rest of the page when doing so.

Anthony Frehner
@frehner.me

Thoughts? Reactions? Also, I included a whole section of references, because there has been a lot of talk about "scoped" CSS vars, and why they can't work. And I wanted to be clear that this proposal isn't that. Haha.

Ilja
@fubits.dev

„how was that for a flamebait headline?” - I’m here for this because you certainly care! 💪