

Style like a BOSS. New css preprocessor. - lvivski
https://github.com/lvivski/boss

======
catshirt
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
BOSS is compatible with standard CSS selector syntax, you don't have to use
BEM features if you don't want to.

~~~
catshirt
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
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"

~~~
catshirt
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
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.

------
lvh
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?

~~~
jacobr
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
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)

------
russelluresti
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.

------
Brajeshwar
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
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.

~~~
robin_reala
Standard CSS syntax for arithmetic operations is the calc() operator:

<http://www.w3.org/TR/css3-values/#calc-notation>

~~~
lvivski
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

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

