Not another CSS preprocessor :( LESS vs SASS was bad enough, then we got Stylus, now another one? Why couldn't this BEM feature be built on top of an existing thing?
LESS ans SASS are bad. They have strange syntax for mixins and variables. BOSS's mixins are hust sets of declarations and it is really easy to use 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)
LESS uses ".class" extendig dor mixins. It's totally wrong, you don't need to extend a class, 'cause you can assign multiple classnames to a DOM node. The only thing you need to extend is a set of declarations (properties), so you create a new declaration which contains all declarations you need, so that you can reuse them.
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.
You can also just do button[class^=button] and use class names like "button-primary". It would be less repetitive code in the output CSS and less in the HTML. I'm so glad attribute selectors are actually OK to use now.
BOSS already has regular CSS as a starting point. If you give regular CSS to it's input you get this css in output (with some indentation changes 'caused by parsing process)
Then you can use syntactic sugar: variables, declaration mixins, nesting, arithmetic (with type coercion, by the way)
first of all, it doesn't seem fair to call this simply a "css preprocessor" since it doesn't seem applicable to any css i've ever written; those selectors are insane. (EDIT: though, as lvivski points out below, it seems possible to use BOSS without the BEM features).
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.
your statement on compatibility is only a half truth.
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.
thanks for clearing that up. for what it's worth the readme fails to explain this, and now i'm actually left with more questions. if a selector with no preceding notation is reserved for BEM blocks- how would i reference an element by tag?
there is a list off all HTML tags, if a tag with that name exists, it will be treated as a TAG, if it doesn't, it will be treated as a BEM block. That simple.
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.
BOSS’s ‘&’ operator’s underscore-adding feature is useful only if you use BEM. BOSS’s other features, such as block nesting and the “darken” function, already exist in other CSS preprocessors. Thus, if you’re not going to use BEM, you have no reason to use BOSS – you should use Stylus or LESS, since they have the same features but have bigger ecosystems.
In simple cases `&` is just replaces by parent selector (Like in SASS or LESS), only some cases are treated as BEM nesting (pseudo-selector that doesn't exist, etc).
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.
I had trouble actually reading and comprehending the examples. It's easy to write poor, unmaintainable CSS and HTML; but this doesn't, in my opinion, offer a solution to that.
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.
It does seem odd that a preprocessor would adhere to (or even promote) a single methodology, but it's a testament to the value of Sass, Less, and the rest that they've grown to the point that new branches can sprout.
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.
BEM, to me, comes in two parts. There's the CSS naming conventions and then there's implementation. I dislike the implementation of BEM using XML or JSON, I think it's kind of obscure on how everything works. However, I do like BEM for the CSS aspect of it. Basically, BEM is a particular style of OOCSS. All it really offers (from the CSS point-of-view) is a standardized way to name your modules (or "blocks" in BEM).
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.
you're right- while unnecessarily verbose... i tried to explain that my concerns lie with BEM itself and not BOSS.
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."
I've done quite a bit of my share with LESS. My default is Sass. With the recent Sass 3.2, there are lots of awesome stuffs.
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!
BOSS is completely compatible with standard CSS syntax. You can use as less or as many features as you want.
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.
well, yes. CSS has variables syntax too (http://dev.w3.org/csswg/css-variables/) but for the time of compiling you don't know anything about the runtime, so you can't calculate things like "10em + 5px" 'cause EM's absolute value depends on many things, so I had to separate "real" css calculations and "fake" ones
After reading the comments, I think a lot of people are getting hung up on the implementation aspect of BEM using XML/JSON to determine markup and such. From what I can see (and this is just my take on it), the BOSS project doesn't require you use any aspect of that type of implementation.
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.
30 comments
[ 5.0 ms ] story [ 34.8 ms ] threadYou 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)
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."
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.
http://www.w3.org/TR/css3-values/#calc-notation
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.