31–36 of 36 posts
Earlier quoted context omitted.
shouldn't that be foo.bar?
No, the idea is that .foo.foo increases the specificity of .foo over .bar
:root { --main-color: brown; } .foo.bar { --main-color: red; } .foo.foo { --main-color: blue; } .bar { --main-color: red; color: var(--main-color); }
anyone actually use this foo.foo method of increasing specificity? Because I think difficult to debug.
Earlier quoted context omitted.
No, the idea is that .foo.foo increases the specificity of .foo over .bar
Ok, and checking it I can see that foo.foo.foo increases specificity yet again and so on infinitum I suppose. I suppose this behavior is specified somewhere and you've read that part of the spec thus explaining how you know it, however as the class declaration is not 'foo foo bar' I think if I were to read it I would conclude that I disagreed with whatever logic was given. In fact this really seems to take away part…
Earlier quoted context omitted.
No, the idea is that .foo.foo increases the specificity of .foo over .bar
I have to also say with the introduction of variables this starts to look crazy :root { --main-color: brown; } .foo.bar { --main-color: red; } .foo.foo { --main-color: blue; } .bar { --main-color: red; color: var(--main-color); } anyone actually use this foo.foo method of increasing specificity? Because I think difficult to debug.
Earlier quoted context omitted.
That’s a good fit when each route needs a lot of custom styles and each one is developed by a separate team. However, it doesn’t really fit well if a brand-themed app is developed by a single team. Consistency is easier to maintain when styles can be reused across the application, and things like styled-components don’t work that well there since they tightly couple components to styles, so you need a theming system…
You seem to have misunderstood; Remix promotes the use of bog-standard CSS. Literally nothing about it in any way inhibits reuse of styles across the app. Not sure where you're going in critiquing styled-components.
Earlier quoted context omitted.
Ok, and checking it I can see that foo.foo.foo increases specificity yet again and so on infinitum I suppose. I suppose this behavior is specified somewhere and you've read that part of the spec thus explaining how you know it, however as the class declaration is not 'foo foo bar' I think if I were to read it I would conclude that I disagreed with whatever logic was given. In fact this really seems to take away part…
Here’s the thing: while the doubled-class ”.foo.foo” trick increases specifity over a single class, it doesn’t completely override selector specificity like !important does: you can still override anything set by ”.foo.foo” with a more specific selector like ”div.foo” or even ”.quux .foo” without having to use the duplicate classname everywhere .
Earlier quoted context omitted.
Here’s the thing: while the doubled-class ”.foo.foo” trick increases specifity over a single class, it doesn’t completely override selector specificity like !important does: you can still override anything set by ”.foo.foo” with a more specific selector like ”div.foo” or even ”.quux .foo” without having to use the duplicate classname everywhere .
sure, but foo.foo.foo overrides foo.foo or foo.bar etc. It seems sort of ridiculous.
Theme and color theme set layout and colors
.theme—-national
.color-theme—-green
article.content-theme—-education
We could use !important, but that’s just asking for trouble.
However, .foo.foo saves the day:
.color-theme—-a11y.color-theme—-a11y article
.theme—-national.color-theme—-green article.content-theme—-education