Style like a BOSS. New css preprocessor.
github.com
github.com
maybe it's my unfamiliarity with BEM, but it looks like a total nightmare. marking up HTML as XML or JSON? what? using underscores for nested selectors instead of, say, cascading? BEM looks like a framework made entirely from bad practices. i am not typically this critical but BEM seems severely misguided.
the problem is not incompatibility with CSS. the problem is that its incompatible with the way anyone actually uses CSS. to be particular- the way it treats the nesting of selectors by relying on underscore separation instead of standard cascading.
to be clear, i don't take offense with BOSS. if you're using BEM, BOSS seems like a fine solution. i do however take offense to BEM directly, and as an extension, comparing BOSS to LESS or SASS.
BOSS expands nesting with underscore separation only in case of BEM selectors (Blocks, Elements, Modifiers)
But it uses cascading with all other selectors, see "test/standard.boss" and "test/standard.css"
This gives some restrictions to Blocks' names, but it's not a big problem, cause normally you won't give block a name which matches existing HTML tag.
The same restrictions are for Modifiers (pseudo-selectors) if it exists, then pseudo, else Modifier.
If you use SASS or LESS and happy with them, you don't need BOSS. But you may take a look at it, 'cause it has simpler syntax for mixins and variables, which is more CSSy.
So BOSS is more like a superset to SASS and LESS, their features + some new stuff + simpler syntax.
Using JSON, for example. JSON's a serialisation format, not designed to be written by mere mortals. They seem to have got it working but I would see it as a recipe for disaster.
Disclaimer: this is my first look at BEM, but I've designed and lived with CSS frameworks that started with the similar goals (fast to develop, multiple authors, reusable structure and code) and ended with similar structure (ok, not the HTML as XML bits).
Much of BEM's selector design seems to flow from the principles that 1) the cascade is difficult to manage, and 2) a single very-specific class is easier to write and maintain than combining multiple single-purpose classes. BEM selectors encourage a modular approach to creating very-specific selectors, unlike the traditional 'semantic' approach of uniquely describing the expected content without acknowledging definitions or purposes shared by other elements.
But despite all of that, I agree with you - this sort of approach is a total nightmare to implement. But that's because, well, CSS isn't very good. It's a real bitch to do anything significant in scope or sophistication, really.
Preprocessors have made it possible to move beyond severely basic limitations (thank goodness for Sass mixins, extends, control directives, bubbling media queries oh my!). But that developers must concern themselves with the cascade for every single definition with no affordable method of ignoring it is madness. The only truly effective recourse is a non-trivial approach like BEM, religiously applied.
Frankly, the quality of native mobile apps has pushed web development aspirations to a level that we are absolutely dependent on style guides and methodologies like BEM, SMACSS, and the lot. Part of me misses the good old days of simple 'semantic' CSS, and maybe it's just the writing-too-late-at-night talking, but the better part of me is really excited about the opportunity for true IDEs paired with preprocessor-empowered, standardized coding methodologies.
If you've ever used OOCSS, you can see how naming can become an issue when it comes to code readability. If I have a module called ".nav" with subset items such as ".nav-item" or ".nav-link" it's easy to understand. ".nav" is the parent module, ".nav-item" and ".nav-link" are elements that make up the ".nav" module. But when you start getting into modifiers, naming gets hairy. For example, I can have a vertical nav or a horizontal nav. So how do I name those variants? ".nav.vertical"? ".vertical" by itself just isn't descriptive of what it belongs to. Plus, other modules may also have vertical arrangements. So then ".nav.nav-vertical"? The readability decreases as you use ".nav-vertical" for a modifier but ".nav-item" for a building element.
So, the value of the BEM approach is that it just provides a standardized way to name your modules, elements, and modifiers so that you have code that is easier to comprehend just by looking at it. Now, do I happen to like their specific naming convention? Not really. But it does work for them.
I feel like this project was built with the naming convention aspect of BEM in mind, and isn't really associated with the XML/JSON implementation aspect of it. So, for that, it's kind of nice (though you could really do the same thing with Sass or LESS as long as you were just mindful of following the naming conventions - BOSS just makes it easier because it takes that responsibility off of you).
To me, this project makes a lot of sense and isn't really hard to understand, but that's because I have an understanding of other CSS preprocessors and BEM. If you didn't know about either of those things, I can see how this project would be very confusing and unapproachable.
that all said, i'd like to substitute my articulation for your own: "Now, do I happen to like their specific naming convention? Not really. But it does work for them."
You can even expand all "border-radius: " to all vendor prefixed --border-radius declarations with ease.
Also you don't need special chars to determine a variable (but you may use "$" if you like)
(Example courtesy of this East Wing podcast episode on SASS: http://theeastwing.net/episodes/26-bermon).
If you want to have declarations of "button" in "button-primary" you can just write <button class="button button-primary">
But is you want to reuse some fancy image-border "button" and "input", so they may have nothing in common, except that image-border. You can create a mixin with desired declarations for all browser, and then use it in your code as simple as "fancy-image-border: url('image.png')". And all rulesets, that have this "fancy-image-border" will then get a list of declarations in place of this mixin.
So you see, the syntax is pretty simple and matches CSS-syntax. You don't need @extends or smth else, you just have to know the name of mixin declaration.
Sass and Stylus both have feature the other one is lacking, and Less has the feature of being able to run in the browser during development.
Maybe we need a CSS preprocessor with regular CSS as a starting point, but with syntactic macros or something.
Then you can use syntactic sugar: variables, declaration mixins, nesting, arithmetic (with type coercion, by the way)
What BOSS does is make it easier to use the CSS selector naming conventions set up in BEM (which, to me, is the value of the BEM approach as I really dislike the HTML abstraction).
I, for one, like the concept of standardizing naming conventions. I'm not a complete fan of BEM, specifically, but I can't argue that it doesn't work.
BOSS seems like it's a tool for people who want to use BEM-style naming conventions in their CSS preprocessors, and, for that, I'd say it works pretty well.
Though, I must admit, I'm not a huge fan of certain aspects of this syntax. The mixins, in particular, I dislike. The mixin is declared as a function: mixin(param1, param2). However, the call to that mixin isn't called like a function, it's called as a key/value pair: mixin: param1, param2. To me, it's just a bit of cognitive dissonance that isn't necessary. Just maintain the function aspect of it - you don't need to make it look like a normal key/value pair (though I get the idea, to have all properties for a selector appear as consistent as possible).
Also, I personally like the unique variable identifier, such as $, that's used in Sass. It keeps you from accidentally using reserved keywords. For example, what would happen if I did the following: sans-serif = Helvetica, Arial, sans-serif. Would it try to implement the second "sans-serif" as the variable value and end up with an infinite loop of "Helvetica, Arial, Helvetica, Arial, Helvetica, Arial..."? Regardless of what actually happens, using the $ for variables is a clear indicator that the item is, indeed, a variable and not a native CSS property, value, reserved word, whatever.
If I have to tutor or bring in a CSS person (but a pre-processor newbie) to my team, it's very easy to start off, "It's pretty much CSS. Just start off with using Variables. We can then take on other interesting stuffs." Once, you can persuade a designer (helping her with the setup) to start using them, it's amazing how many of them won't go back to doing RAW CSS after LESS or SASS.
As for BOSS, it looks like one has to study and learn a totally different stuff than CSS. I browse through the test codes and it isn't really welcoming!
Ex. you wan only arithmetic operations to write "10px + 10%", you are welcome to do so, or use only variables.
Ruleset nesting works like in SASS or LESS with small addition of BEM, but it's totally compatible with CSS selectors. And you may not use nesting if you don't want to.