8 ms·

Style like a BOSS. New css preprocessor.

21 points by lvivski 14y ago

lvh 14y ago
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?
- lvivski 14y ago
  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)
  - beatpanda 14y ago
    I don't know, LESS seems to work for me. The syntax doesn't seem significantly different than LESS.
    - lvivski 14y ago
      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.
      - nilliams 14y ago
        Believe SASS can do what you're describing with @extend and %silent directive: http://codepen.io/bpainter/pen/FxHEm http://codepen.io/bpainter/pen/FxHEm (Example courtesy of this East Wing podcast episode on SASS: http://theeastwing.net/episodes/26-bermon http://theeastwing.net/episodes/26-bermon).
        lvivski 14y ago
        BOSS uses different approach. 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.
        criswell 14y ago
        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.
- jacobr 14y ago
  I love Sass, but CSS preprocessing is not a solved problem, and I can see how this helps if you're using Yandex' BEM principle. 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.
  - lvivski 14y ago
    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)
catshirt 14y ago
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
Brajeshwar 14y ago
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!
- lvivski 14y ago
  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.
  - deleted 14y ago
    [deleted]
  - robin_reala 14y ago
    Standard CSS syntax for arithmetic operations is the calc() operator: http://www.w3.org/TR/css3-values/#calc-notation http://www.w3.org/TR/css3-values/#calc-notation
    - lvivski 14y ago
      well, yes. CSS has variables syntax too (http://dev.w3.org/csswg/css-variables/ 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
russelluresti 14y ago
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.
nkozyra 14y ago
I think this is unnecessary, clumsy and inelegant. I don't see a single reason to look at this over LESS/SASS.

21 points by lvivski 14y ago

lvh 14y ago

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?

lvivski 14y ago
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)
- beatpanda 14y ago
  I don't know, LESS seems to work for me. The syntax doesn't seem significantly different than LESS.
  - lvivski 14y ago
    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.
    - nilliams 14y ago
      Believe SASS can do what you're describing with @extend and %silent directive: http://codepen.io/bpainter/pen/FxHEm http://codepen.io/bpainter/pen/FxHEm (Example courtesy of this East Wing podcast episode on SASS: http://theeastwing.net/episodes/26-bermon http://theeastwing.net/episodes/26-bermon).
      - lvivski 14y ago
        BOSS uses different approach. 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.
        criswell 14y ago
        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.
jacobr 14y ago
I love Sass, but CSS preprocessing is not a solved problem, and I can see how this helps if you're using Yandex' BEM principle. 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.
- lvivski 14y ago
  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)

catshirt 14y ago

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

Brajeshwar 14y ago

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!

lvivski 14y ago
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.
- deleted 14y ago
  [deleted]
- robin_reala 14y ago
  Standard CSS syntax for arithmetic operations is the calc() operator: http://www.w3.org/TR/css3-values/#calc-notation http://www.w3.org/TR/css3-values/#calc-notation
  - lvivski 14y ago
    well, yes. CSS has variables syntax too (http://dev.w3.org/csswg/css-variables/ 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

russelluresti 14y ago

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.

nkozyra 14y ago

I think this is unnecessary, clumsy and inelegant. I don't see a single reason to look at this over LESS/SASS.