11 ms·

Inline Scope for CSS

Izkata 2y ago
Firefox is planning on it: https://bugzilla.mozilla.org/show_bug.cgi?id=1830512 https://bugzilla.mozilla.org/show_bug.cgi?id=1830512
- oefrha 2y ago
  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://caniuse.com/style-scoped https://github.com/whatwg/html/issues/552 https://github.com/whatwg/html/issues/552
- sureIy 2y ago
  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/WebExtensions/manifest.json/background https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
  - _ZeD_ 2y ago
    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
  - iforgotmysocks 2y ago
    Surprising that Firefox is lagging behind Safari
  - chrismorgan 2y ago
    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.
dmix 2y ago
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.
mikae1 2y ago
> 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.
omeid2 2y ago
At some point, we really have to kill CSS.
- onion2k 2y ago
  You can stop using it today if you want to.
  - omeid2 2y ago
    That is as good as saying "stop using Google" when it is everywhere on the web. But CSS is adding new features every day and sunrise again should be the sign that it is a poor abstraction.
emmanueloga_ 2y ago
> 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://2023.stateofcss.com/en-US/features/ * https://tailwindcss.com/ 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 https://developer.mozilla.org/en-US/docs/Web/CSS/isolation
- mdhb 2y ago
  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.
  - troupo 2y ago
    In component-based apps/systems C in CSS is often the last thing you want, if you ever want that.
    - deleted 2y ago
      [deleted]
    - mdhb 2y ago
      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.
SynnVoid 2y ago
For now, as Firefox support is not yet good, We can use nested rules in CSS. HTML: <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.
- notpushkin 2y ago
  Svelte does a similar thing: when a component is compiled, it gets a scope class, and its own styles are placed in that scope.
- setr 2y ago
  Is this not the same as having a class with a unique name, and applying it to a parent div
  - SynnVoid 2y ago
    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
  - dgraph_advocate 2y ago
    [dead]
ashycre 2y ago
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.
ximm 2y ago
Friendly reminder that inline CSS is unsafe and should be avoided. https://stackoverflow.com/questions/41925390 https://stackoverflow.com/questions/41925390
- grardb 2y ago
  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.
- audiodude 2y ago
  Wait WTF, `javascript:` URLs are acceptable in the CSS `url` property?? From the SO post: > url('javascript: eval(evil)');
geenat 2y ago
May also be interesting to people here: https://github.com/gnat/css-scope-inline https://github.com/gnat/css-scope-inline 16 lines for short vanilla syntax, scoped animations, and shorthand media queries like Tailwind.
pseudosavant 2y ago
This seems perfect for JSX. You still use CSS (it uses _cascading_) but it is scoped locally like inline.
akira2501 2y ago
I wish they made this an attribute on the <style> element. <style scoped> :root { /* the section style */ } span { color: blue; } </style> The whole :scope inside @scope is odd to me.
- nness 2y ago
  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.
- wolframkriesing 2y ago
  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.
deleted 2y ago
[deleted]

Firefox is planning on it: https://bugzilla.mozilla.org/show_bug.cgi?id=1830512 https://bugzilla.mozilla.org/show_bug.cgi?id=1830512

oefrha 2y ago
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://caniuse.com/style-scoped https://github.com/whatwg/html/issues/552 https://github.com/whatwg/html/issues/552
sureIy 2y ago
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/WebExtensions/manifest.json/background https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
- _ZeD_ 2y ago
  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
- iforgotmysocks 2y ago
  Surprising that Firefox is lagging behind Safari
- chrismorgan 2y ago
  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.

dmix 2y ago

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.

mikae1 2y ago

> 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.

omeid2 2y ago

At some point, we really have to kill CSS.

onion2k 2y ago
You can stop using it today if you want to.
- omeid2 2y ago
  That is as good as saying "stop using Google" when it is everywhere on the web. But CSS is adding new features every day and sunrise again should be the sign that it is a poor abstraction.

emmanueloga_ 2y ago

> 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://2023.stateofcss.com/en-US/features/ * https://tailwindcss.com/ 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 https://developer.mozilla.org/en-US/docs/Web/CSS/isolation

mdhb 2y ago
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.
- troupo 2y ago
  In component-based apps/systems C in CSS is often the last thing you want, if you ever want that.
  - deleted 2y ago
    [deleted]
  - mdhb 2y ago
    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.

SynnVoid 2y ago

For now, as Firefox support is not yet good, We can use nested rules in CSS. HTML: <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.

notpushkin 2y ago
Svelte does a similar thing: when a component is compiled, it gets a scope class, and its own styles are placed in that scope.
setr 2y ago
Is this not the same as having a class with a unique name, and applying it to a parent div
- SynnVoid 2y ago
  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
- dgraph_advocate 2y ago
  [dead]

ashycre 2y ago

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.

ximm 2y ago

Friendly reminder that inline CSS is unsafe and should be avoided. https://stackoverflow.com/questions/41925390 https://stackoverflow.com/questions/41925390

grardb 2y ago
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.
audiodude 2y ago
Wait WTF, `javascript:` URLs are acceptable in the CSS `url` property?? From the SO post: > url('javascript: eval(evil)');

geenat 2y ago

May also be interesting to people here: https://github.com/gnat/css-scope-inline https://github.com/gnat/css-scope-inline 16 lines for short vanilla syntax, scoped animations, and shorthand media queries like Tailwind.

pseudosavant 2y ago

This seems perfect for JSX. You still use CSS (it uses _cascading_) but it is scoped locally like inline.

akira2501 2y ago

I wish they made this an attribute on the <style> element. <style scoped> :root { /* the section style */ } span { color: blue; } </style> The whole :scope inside @scope is odd to me.

nness 2y ago
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.
wolframkriesing 2y ago
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.

deleted 2y ago

[deleted]