.default-button(){ // properties }
.component-a button { background-color: red; }
.component-b button { .default-button(); color: green; }
It can be done, it's just most examples of this type of thing is more along the lines of "I want to do it my way!", which is not always a proper way to go about things.
They decided to use the name `.calendar`. Was that safe? Nope, their user #3 had an "upcoming events" calendar using the same class name that totally breaks when the datepicker CSS is included on the page. Should they make sure to prefix all their class names with their name? What if someone else with the same name also decides to do this? What if they make a new alternate datepicker, must they add the version number/descriptor too?
This is probably one of the reasons why we don't yet have separate reusable components with minimal overridable styles for the web (instead we have only entire pre-styled frameworks)
If styles had scope and HTML had a way to import them, we could say `import calendar from "path/to/file"`, then use the calendar style on our component and be sure that there is no way its going to leak outside of outside its lexical scope. Web components will fix this (html imports, scoped stylesheets). But web components aren't ready yet.
Let me ask you a different question though: is there a reason for the "oh god, not JS" sentiment? The solution is potentially even simpler than CSS: styles are defined as variables containing JSON objects, they're exported as a module, and can be imported and used by any component and mixed freely. No cascading/selector rules, no priorities, no overrides. When HTML CSS and JS share scope, things become much simpler.
I used to hate CSS. I still think it is very flawed, just google how to center something and watch all the blogs pop up.
But rather than cursing it the rest of my dev days, I took the time to learn it and structure it properly. I now never spend longer than a few minutes trying to resolve a css bug.
Ideas like the OPs only procrastinate someone's true problem, which is they don't know how to properly work with the technology that they are forced to work with.
The reason I would say no to a JS solution is simply because you are adding yet another step to the render of the page, more code for the browser to parse, and in the end results in the same issues you started with as they are only masked. This is just an attempt to make something work in a fashion it was designed to do. I'd rather fix the problem at the source instead of adding another layer to the problems.
But in the end, no matter what fancy JS code that comes up it still has to render out the CSS exactly as the browser expects it to be. That means that whatever this thing generates, people who know CSS can hand-code the exact same thing. Any problems that exists for CSS exists in this as well, it just masked so it's not readily apparent.
See font-awesome for an example of what I mean by library (yes, they prefix everything with `fa-` which is fine until the bootstrap team comes up with a FizzActivity widget in bootstrap, which you wont be able to use together with fontawesome)
What happens if two developers namespace their class in the same way in JS? Well, with CommonJS this is pretty much impossible (import by path), and even without CommonJS there is no incentive to do it as you can easily pick a huge namespace without it affecting anyone. Just adding `var shortName = long.namespace.containing.shortName;` fixes the long name without that short name having effects anywhere else in the code or any of the inner functions (components) you may call, because... lexical scope.
And sure, we can hand-code everything in assembly too - after all thats what compilers do anyway. But that doesn't mean that the higher level language has all the problems that assembly has. A tool like this can do a lot of the job for you, by generating unique names and letting you refer to them via any (variable) name you like.
It seems to me your main problem is how do you have people who don't know what they are doing perform like an experienced developer/designer.
Example 1:
<div class="component-a"><button></button><div class="component-b"><button></button></div></div>
Example 2:
<div class="component-b"><button></button></div>
Result:
The <button> wrapped in div.component-b for both above examples will render exactly the same, ignoring html structure.
If this tool is the solution, that the CSS it generates is the best way to do things, then why not code the CSS that way in the first place?
EDIT: As I'm seeing elsewhere in this thread; why exactly is globals bad in CSS?
e.g.
my-namespace {
.button {
color: red;
}
.another-button {
color: blue;
}
}
The problem with this approach is that you need to declare the namespace in DOM somehow, and depending on the project that can either be easy or rather difficult. I used this technique when I ported a stand-alone application with classes just like ".button" to be a single page in a larger application, and it worked fine.
Anyway, I do think that CSS should have a proper solution to modularization.
EDIT: Now that I could open the link (it didn't open for me previously), I now see that this approach doesn't solve the problem with the article, since it doesn't support nested namespaces. (Although a hacky solution would be a 'reset all rules' helper in the inner namespace).
As for your example not working with the approach, that's one of the problems as I see it with these solutions. The fancy, complicated approach apparently doesn't support one of the basics of CSS which would go a long way to fixing the problem as they see it.
I prefer to have a button class, for example in react that when instanced renders all the time the same. It boundles it's css within, just like this lib.
http://lesscss.org/features/#features-overview-feature-names...
I haven't personally used it, though.
Another solution would be have a "button.less" like this:
comp-a, comp-b, comp-c {
.button {
}
}I have a hunch some consensus will evolve that will use Java/AS3 namespace prefixes to enable sharing, so instead of .button you'll have something like .com-github-dougmartin-button.
True, this is not something that happens often, and we can mostly get away with namespaces. But that's not the point. The point is that lexical scope is a tried and proven (by years of research, in multiple languages) solution to this problem which doesn't have any of these quirks. And JS has lexical scope.
There is nothing that this library can do that I cannot hand-code in CSS myself. Because it has to generate the CSS that the browser expects to get, which is not hard to do.