Inline Scope for CSS(picostitch.com)
picostitch.com
Inline Scope for CSS
https://picostitch.com/tidbits/2024/10/inline-scope-for-css/
42 comments
Is this not the same as having a class with a unique name, and applying it to a parent div
Quite the same if you use nested css on the div.class-name-here. The diff is in the semantic. My post was about using nested CSS to "emulate" @scope
Svelte does a similar thing: when a component is compiled, it gets a scope class, and its own styles are placed in that scope.
Firefox is planning on it: https://bugzilla.mozilla.org/show_bug.cgi?id=1830512
That’s ironic. Firefox once had scoped CSS which no one else picked up, so it was removed. Now it’s the last mover.
https://caniuse.com/style-scoped
https://github.com/whatwg/html/issues/552
https://caniuse.com/style-scoped
https://github.com/whatwg/html/issues/552
They're always planning things and always last at things. Even for the most visible and painful cross-browser issues, they always last. One thing being service workers on extensions: available in Chrome since 2020 and we're closing 2024 still without them in Firefox.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
Firefox is absolutely not always last at things. Chrome, Safari and Firefox are all often first, and all often last.
Chrome tends to ship things its team comes up with first, and things the rest come up with last. (This should not be considered surprising, for any team.) It tends to ship things half-baked (specification incomplete, or buggy implementation, though that latter isn’t as common as it was ten years ago), and often things both Safari and Firefox deem harmful. Firefox and Safari tend more to ship things only when they’re complete (specification and their implementation).
Especially in cases like this, Firefox was the first mover (<style scoped>), but then (simplifying the story slightly) Chrome nudged development in a different direction (because of Shadow DOM considerations, I think), and so Firefox eventually removed what they’d done and saying they’d wait until the dust had really settled before implementing again.
Chrome tends to ship things its team comes up with first, and things the rest come up with last. (This should not be considered surprising, for any team.) It tends to ship things half-baked (specification incomplete, or buggy implementation, though that latter isn’t as common as it was ten years ago), and often things both Safari and Firefox deem harmful. Firefox and Safari tend more to ship things only when they’re complete (specification and their implementation).
Especially in cases like this, Firefox was the first mover (<style scoped>), but then (simplifying the story slightly) Chrome nudged development in a different direction (because of Shadow DOM considerations, I think), and so Firefox eventually removed what they’d done and saying they’d wait until the dust had really settled before implementing again.
That's because nowadays the "standards" is "just what chrome does", and the other browsers can only catch up.
Witch is easy for edge, opera and the others chrome-clones, but not straightforward for the rest - aka ff.
as other as said this feature was already present in ff only, but then noone picked it up and so it was abandoned
as other as said this feature was already present in ff only, but then noone picked it up and so it was abandoned
Surprising that Firefox is lagging behind Safari
I wish they made this an attribute on the <style> element.
<style scoped>
:root { /* the section style */ }
span { color: blue; }
</style>
I agree, when I saw the <style scoped> I also thought this would have been the coolest. But I guess there have been considerations and discussions about it. I just don't know where.
I guess @scope > :scope would help you know what the CSS is doing even if you don't know where the CSS is being inserted... but I can't imagine that being a problem in practice.
> I am not tightly following what's going on in CSS land, since blogs are not the thing and mailing lists became spam lists I don't know where to "listen".
Two resources:
* https://2023.stateofcss.com/en-US/features/
* https://tailwindcss.com/
Keeping track of TailwindCSS updates is nice, even for non-users: since they "live and breathe" CSS, seeing what they are up to is a good strategy to stay current with CSS developments.
Apart from discovering new things, I also learned some obscure CSS features from TW. For instance, I learned about the "isolation" property [1], which is useful for managing stacking contexts in those hair-tearing situations where the "z-index" won't cooperate as expected.
--
1: https://developer.mozilla.org/en-US/docs/Web/CSS/isolation
Two resources:
* https://2023.stateofcss.com/en-US/features/
* https://tailwindcss.com/
Keeping track of TailwindCSS updates is nice, even for non-users: since they "live and breathe" CSS, seeing what they are up to is a good strategy to stay current with CSS developments.
Apart from discovering new things, I also learned some obscure CSS features from TW. For instance, I learned about the "isolation" property [1], which is useful for managing stacking contexts in those hair-tearing situations where the "z-index" won't cooperate as expected.
--
1: https://developer.mozilla.org/en-US/docs/Web/CSS/isolation
I really wouldn’t say Tailwind does anything that resembles living and breathing CSS.
Their entire value proposition is making shit copy and pastable by ignoring the “C” in CSS and then doing further things to kind of reduce how much you need to know about writing CSS like just making everything a class for example.
I know a lot of people like it but it’s considered a very flawed solution in a lot of ways by people who have a decent working knowledge of CSS to begin with.
Don’t get me wrong I see the appeal of it but the implementation I think leaves a lot to be desired.
Their entire value proposition is making shit copy and pastable by ignoring the “C” in CSS and then doing further things to kind of reduce how much you need to know about writing CSS like just making everything a class for example.
I know a lot of people like it but it’s considered a very flawed solution in a lot of ways by people who have a decent working knowledge of CSS to begin with.
Don’t get me wrong I see the appeal of it but the implementation I think leaves a lot to be desired.
> I really wouldn’t say Tailwind does anything that resembles living and breathing CSS.
@scope itself doesn't resemble traditional CSS. In fact, @scope is not even generally available, since FF doesn't implement it yet.
> Their entire value proposition is making shit copy and pastable by ignoring the “C” in CSS
The scoping problem in CSS is well-known, and one could argue that the "C" in CSS can often be one of its biggest flaws. Cascading is complex and hard to use. I like how @scope addresses this issue!
If you have the problem that @scope solves (and you'll have it if you write non-trivial webapp), and you want something that will work today across browsers, an alternative solution you should try is Tailwind.
> and then doing further things to kind of reduce how much you need to know about writing CSS
I've been thinking of TW as an "APL for CSS": it is this cool shorthand system where a bunch of little utility classes can generate a lot of CSS properties for you. But you still 100% need to understand what your shorthand is doing.
> Don’t get me wrong, I see the appeal of it, but the implementation I think leaves a lot to be desired.
No tool is perfect, but in my experience, Tailwind has made building complex web apps a lot more enjoyable.
> I know a lot of people like it but it’s considered a very flawed solution in a lot of ways by people who have a decent working knowledge of CSS to begin with.
I wasn’t swayed by the popularity of Tailwind or the opinions of CSS experts. I decided to form my own opinion, and I'm glad I did! (I was skeptical too for a long time).
I’m typically a late adopter—I prefer to wait until the rough edges of a tool have been smoothed out, but/and I've been using TW 4.0 (in alpha) for about three months, and even with a long career of writing CSS in more traditional way, and also things like Sass, CSS-in-JS, etc, etc, my current assessment is that TW is a more enjoyable way to write web apps.
--
Locality of behavior is the main thing that makes it so enjoyable for me. Things like shadow DOM and @scope are steps in that direction. Maybe someday newer web standards will make TW obsolete, but for now, it is my preferred way to style web apps.
@scope itself doesn't resemble traditional CSS. In fact, @scope is not even generally available, since FF doesn't implement it yet.
> Their entire value proposition is making shit copy and pastable by ignoring the “C” in CSS
The scoping problem in CSS is well-known, and one could argue that the "C" in CSS can often be one of its biggest flaws. Cascading is complex and hard to use. I like how @scope addresses this issue!
If you have the problem that @scope solves (and you'll have it if you write non-trivial webapp), and you want something that will work today across browsers, an alternative solution you should try is Tailwind.
> and then doing further things to kind of reduce how much you need to know about writing CSS
I've been thinking of TW as an "APL for CSS": it is this cool shorthand system where a bunch of little utility classes can generate a lot of CSS properties for you. But you still 100% need to understand what your shorthand is doing.
> Don’t get me wrong, I see the appeal of it, but the implementation I think leaves a lot to be desired.
No tool is perfect, but in my experience, Tailwind has made building complex web apps a lot more enjoyable.
> I know a lot of people like it but it’s considered a very flawed solution in a lot of ways by people who have a decent working knowledge of CSS to begin with.
I wasn’t swayed by the popularity of Tailwind or the opinions of CSS experts. I decided to form my own opinion, and I'm glad I did! (I was skeptical too for a long time).
I’m typically a late adopter—I prefer to wait until the rough edges of a tool have been smoothed out, but/and I've been using TW 4.0 (in alpha) for about three months, and even with a long career of writing CSS in more traditional way, and also things like Sass, CSS-in-JS, etc, etc, my current assessment is that TW is a more enjoyable way to write web apps.
--
Locality of behavior is the main thing that makes it so enjoyable for me. Things like shadow DOM and @scope are steps in that direction. Maybe someday newer web standards will make TW obsolete, but for now, it is my preferred way to style web apps.
You're right in that it undoes the cascading bit, but that's the bit that a lot of people don't want. The updates to CSS are rarely about how it cascades, so it _does_ follow the majority of updates.
Also, if you look at the docs, the mapping between class and styles are the first thing you're given. IMO it doesn't hide anything about the models browsers use to build things like grids, for example
Also, if you look at the docs, the mapping between class and styles are the first thing you're given. IMO it doesn't hide anything about the models browsers use to build things like grids, for example
Depends on the website. For my personal blog it is the most amazing thing. For a web application it is the most annoying thing.
In component-based apps/systems C in CSS is often the last thing you want, if you ever want that.
I know people get incredibly upset whenever this gets mentioned because suddenly they DO want it again but that was a big part of what “web components” were. When you need that level of isolation you can get it for free without any extra work.
Web Components are doing much more with isolation than just isolating styles.
You don't want/need to kill your a11y, form participation, and a bunch of other things (and laboriously solve them with Javascript) just because you want to scope your styles
You don't want/need to kill your a11y, form participation, and a bunch of other things (and laboriously solve them with Javascript) just because you want to scope your styles
[deleted]
This guy is absolutely right - the C in CSS stands for cascading.
What Tailwind is doing is rewriting the whole thing that CSS is and putting it into easy-to-write classes. This could be handy to you, yes, but unfortunately you're missing the whole point of CSS which is to have cascaded stylings.
To help you understand this a little bit better, one could have a look at why CSS was invented and where it comes from:
In the desktop publishing world (books, newspapers, etc.) this kind of cascading layout rules were used long before there was the first HTML page on the web. This should be nothing to be mixed up with regular programming. Change your view on that thing and you will understand.
It may sound harsh but Tailwind is a way to tell "I'm a programmer, I don't understand CSS and I'm not further interested into".
What Tailwind is doing is rewriting the whole thing that CSS is and putting it into easy-to-write classes. This could be handy to you, yes, but unfortunately you're missing the whole point of CSS which is to have cascaded stylings.
To help you understand this a little bit better, one could have a look at why CSS was invented and where it comes from:
In the desktop publishing world (books, newspapers, etc.) this kind of cascading layout rules were used long before there was the first HTML page on the web. This should be nothing to be mixed up with regular programming. Change your view on that thing and you will understand.
It may sound harsh but Tailwind is a way to tell "I'm a programmer, I don't understand CSS and I'm not further interested into".
Cascading may be good for publishing, but the many benefits of cascading don't really play in your favor when you are trying to use the web as a platform to make _applications_. Documents are mostly static; apps have a lot of moving parts. Apps are a lot more complex than documents.
dangsux(1)
[deleted]
New "alternate" way to do things is always welcome I suppose. This looks slightly better than declaring the style right in the style attribute of an HTML element.
Oh this could be useful. I've been thinking a lot about this recently.
I built some older features in Vue with <style> tags in components (SFC, single-file components) and we used Vite to do builds, which extracts all the CSS from individual .vue files into .css files for production deployment. But we also had serverside CSS that didn't need that fancy stuff. So I've been wanting to move to a much simpler CSS system. Just letting esbuild do typescript/Vue and let CSS be CSS. But one of the only drawbacks was losing the automatic CSS scoping, not having to write wrapper .classes/BEM inside components was nice.
So this would certainly help migrate away from JS dependencies + spaghetti BEM CSS.
And even more meta I think the general trend in the frontend world is moving away from pure JS-driven frontends back to defaulting to server powered views, with JS tooling only used where it's absolutely needed (high interactivity) without the whole frontend being isolated in a separate build system. So backend devs don't need to worry about JS build pipelines for simple HTML stuff... which they should be trusted to do.
I built some older features in Vue with <style> tags in components (SFC, single-file components) and we used Vite to do builds, which extracts all the CSS from individual .vue files into .css files for production deployment. But we also had serverside CSS that didn't need that fancy stuff. So I've been wanting to move to a much simpler CSS system. Just letting esbuild do typescript/Vue and let CSS be CSS. But one of the only drawbacks was losing the automatic CSS scoping, not having to write wrapper .classes/BEM inside components was nice.
So this would certainly help migrate away from JS dependencies + spaghetti BEM CSS.
And even more meta I think the general trend in the frontend world is moving away from pure JS-driven frontends back to defaulting to server powered views, with JS tooling only used where it's absolutely needed (high interactivity) without the whole frontend being isolated in a separate build system. So backend devs don't need to worry about JS build pipelines for simple HTML stuff... which they should be trusted to do.
May also be interesting to people here: https://github.com/gnat/css-scope-inline
16 lines for short vanilla syntax, scoped animations, and shorthand media queries like Tailwind.
16 lines for short vanilla syntax, scoped animations, and shorthand media queries like Tailwind.
> See caniuse for the support, at the time of writing caniuse says 82% support globally. Sounds quite good.
That's one way of making it sound good. Saying: “it won't work on Firefox” makes it sound worse. But perhaps OP wasn't implying it's production ready.
That's one way of making it sound good. Saying: “it won't work on Firefox” makes it sound worse. But perhaps OP wasn't implying it's production ready.
This seems perfect for JSX. You still use CSS (it uses _cascading_) but it is scoped locally like inline.
Friendly reminder that inline CSS is unsafe and should be avoided. https://stackoverflow.com/questions/41925390
Just to make sure I'm not missing anything: All of that essentially only applies to user/untrusted input, right? i.e. if I have a static website with inline CSS (or JS), there's no security concern.
In that case, I'm not sure I'd consider inline CSS "unsafe." But it's interesting to see how CSS can be exploited in the same way that JS can be.
In that case, I'm not sure I'd consider inline CSS "unsafe." But it's interesting to see how CSS can be exploited in the same way that JS can be.
Wait WTF, `javascript:` URLs are acceptable in the CSS `url` property??
From the SO post:
> url('javascript: eval(evil)');
From the SO post:
> url('javascript: eval(evil)');
[deleted]
<my-custom-element> <p>This is a paragraph</p> </my-custom-element>
CSS:
my-custom-element { p { color: blue; } }
By choosing a unique name for the custom element, we achieve near the same functionality as @scope.