The Evolution of Scalable CSS
frontendmastery.com
The Evolution of Scalable CSS
1–10 of 59 posts
Re: The Evolution of Scalable CSS
#2> The Evolution of Scalable CSS
The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? They are the next step in the evolution of scalable CSS, and yet they are noticeably absent from the discussion.
Re: The Evolution of Scalable CSS
#3There's still no good way of publishing an npm package with multiple components, stylesheets per component, and transitive consumers using only the stylesheets for the components they reference while rendering fully server side. CSS is still not scalable.
Re: The Evolution of Scalable CSS
#4> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…
> Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components?
I feel like, at least with that one, was left behind because there's some work left to do in that regard.
For the redesign of my portfolio, miler.codeberg.page, I used icons I did for the previous one (and did some new ones, but all are a bunch of s in a single file) but instead of "injecting" the SVG code in the HTML I tried to use them from CSS as pseudoelements (as a 'content' fragment identifier) and style them (stroke color).
The state of things right now, as I learned, is that it's impossible to do that - neither with some obscure parameter within the SVG fragment identifiers. I had to do some crop filter trickery to "change" their stroke color.
Re: The Evolution of Scalable CSS
#5My favorite implementation of CSS systems has to be elm-css. Your CSS is just normal elm code included in your view code. E.g. everything is an expression, so can import reusable CSS, compose it from different blocks, have functions calculating the CSS runtime etc. Then runtime the rules are compiled to classes and applied to the elements.
One nice thing about this is that instead of using classes, you can instead statically import the definition and apply it to your element, making it even fail compilation time if you remove some global styling some component still relies on.
And the CSS itself is typed. So the project will not compile if you write invalid css.
Re: The Evolution of Scalable CSS
#6> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…
> Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? I feel like, at least with that one, was left behind because there's some work left to do in that regard. For the redesign of my portfolio, miler.codeberg.page, I used icons I did for the previous one (and did some new ones, but all are a bunch of s in a single file) but instead of "injecting" the SVG code in…
> I tried to use them from CSS as pseudoelements (as a 'content' fragment identifier) and style them (stroke color).
Isn't this just the general problem of loading an svg as an image via a link as opposed to injecting it into the DOM as inline svg? How would any of the existing CSS approaches help (or how would web components hider) this one?
Re: The Evolution of Scalable CSS
#7My favorite implementation of CSS systems has to be elm-css. Your CSS is just normal elm code included in your view code. E.g. everything is an expression, so can import reusable CSS, compose it from different blocks, have functions calculating the CSS runtime etc. Then runtime the rules are compiled to classes and applied to the elements. One nice thing about this is that instead of using classes, you can instead st…
For anyone else trying to understand how this fits in, it's either the "Inline Styles" section or the "CSS in JS" section, as long as you use typescript and follow the same rules mentioned here
Re: The Evolution of Scalable CSS
#8> The Evolution of Scalable CSS The evolution of practices described in this article is followed up to about ten yeas ago... and then stops, followed by Tailwind. Where is consideration of web components with shadow DOM, which solve the CSS encapsulation problem, the naming problem, and the dead code problem? Where is treatment of CSS variables that pierce the shadow DOM and allow global theming of such components? T…
Indeed. It's web components and the shadow DOM that fix all of this.
Re: The Evolution of Scalable CSS
#9My favorite implementation of CSS systems has to be elm-css. Your CSS is just normal elm code included in your view code. E.g. everything is an expression, so can import reusable CSS, compose it from different blocks, have functions calculating the CSS runtime etc. Then runtime the rules are compiled to classes and applied to the elements. One nice thing about this is that instead of using classes, you can instead st…
For anyone else trying to understand how this fits in, it's either the "Inline Styles" section or the "CSS in JS" section, as long as you use typescript and follow the same rules mentioned here
If I were to explain it in terms of react, it would be to use everywhere. Except that you also can define nested stuff, media queries, hover/active states, pseudo-elements etc. So yeah, syntactically a bit more like CSS in JS / JSS, but much more ergonomic, and much more easily composable.
Re: The Evolution of Scalable CSS
#10There's still no good way of publishing an npm package with multiple components, stylesheets per component, and transitive consumers using only the stylesheets for the components they reference while rendering fully server side. CSS is still not scalable.
This is what native CSS module scripts solve.
You can import CSS directly into JavaScript modules:
import styles from './styles.css' assert {type: 'css'};
Live example: https://lit.dev/playground/#gist=f0bdd3b5db5e4a404297e695305...