Inline Scope for CSS
picostitch.com
picostitch.com
<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.
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/Web...
as other as said this feature was already present in ff only, but then noone picked it up and so it was abandoned
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.
<style scoped>
:root { /* the section style */ }
span { color: blue; }
</style>
Two resources:
* https://2023.stateofcss.com/en-US/features/
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
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.
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
Too much hassle when all you need is style scoping
@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.
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".
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
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.
16 lines for short vanilla syntax, scoped animations, and shorthand media queries like Tailwind.
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.
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.
From the SO post:
> url('javascript: eval(evil)');
But CSS is adding new features every day and sunrise again should be the sign that it is a poor abstraction.