4 ms·

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 i

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.

lvivski 14y ago
BOSS is compatible with standard CSS selector syntax, you don't have to use BEM features if you don't want to.
- catshirt 14y ago
  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.
  - lvivski 14y ago
    You are partially right. I've added a test with simple selectors: classnames, pseudo. 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"
    - deleted 14y ago
      [deleted]
    - catshirt 14y ago
      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?
      - lvivski 14y ago
        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.
- deleted 14y ago
  [deleted]
- roryokane 14y ago
  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.
  - lvivski 14y ago
    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.
FuzzyDunlop 14y ago
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.
harlanlewis 14y ago
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.
russelluresti 14y ago
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.
- catshirt 14y ago
  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."

lvivski 14y ago

BOSS is compatible with standard CSS selector syntax, you don't have to use BEM features if you don't want to.

catshirt 14y ago
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.
- lvivski 14y ago
  You are partially right. I've added a test with simple selectors: classnames, pseudo. 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"
  - deleted 14y ago
    [deleted]
  - catshirt 14y ago
    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?
    - lvivski 14y ago
      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.
deleted 14y ago
[deleted]
roryokane 14y ago
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.
- lvivski 14y ago
  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.

FuzzyDunlop 14y ago

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.

harlanlewis 14y ago

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.

russelluresti 14y ago

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.

catshirt 14y ago
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."