
Furnish JavaScript - Let the classes on DOM elements generate the CSS for you - kamranahmedse
https://github.com/Idnan/furnish-js
======
Kequc
This introduces a layer of abstraction and makes everything more difficult to
read and understand.

It cannot be as powerful as just using css. It may even require mixing the two
together. It doesn't make sense because these aren't what classes are for. If
I have an "item box" I want the markup to reflect that by assigning it the
class named "item-box."

~~~
erikpukinskis
You're almost certainly right, but I love that they're doing the experiment. I
think, particularly with tools as heavily used as CSS, that we poke around and
try different ways of organizing the code. That's how we evolve towards better
and better ways of architecting our code.

Sometimes you really do come across an alternate language that is better in
little ways and equally expressive.

------
frik
or you just inline CSS?

    
    
      <p class="fs14px mt25 mb0 ml2em br30%">You can combine formulas as well</p>
    

vs

    
    
      <p style="font-size:14px; margin-top:25px; margin-bottom:0; margin-left:2em; border-radius:30%;">inline css</p>

~~~
Semiapies
Seriously, that's all it is.

It's JavaScript to accomplish what the browser will already do for you with
little savings in typing. A plain-vanilla CSS file would be less work!

~~~
erikpukinskis
There may be some memory benefits to caching the styles.

------
jameslk
Wouldn't it be easier to just go back to using HTML tables and <font>, <i>,
<b>, and <blink> tags? I know this comes off snarky, but there is a reason why
we try to keep the presentation layer out of the structure, as much of a
burden as it is. A long time ago, that enlightenment began for me with
csszengarden.com and I have never gone back.

~~~
andrewmcwatters
On a similar note, remember XHTML? Remember the industry widely agreeing HTML
wasn't XML? Sure there's the structure portion of that equation, but now
custom tags are commonplace and it's almost like we're back where we started,
but now people have changed their stance.

It's hard to read the industry when people are throwing out thorough
progressive enhancement in favor of thick client SPAs, when not too long ago
people praised development practices that ensured JavaScript was not a
necessity for experiencing the web.

I feel like we nearly had everything perfect, but then new frameworks and
tooling came around and challenged these things. We're in a better place now I
think, but we've left behind some great development practices, too.

------
tylermauthe
Interesting idea, basically a DSL for inline CSS declarations. This is
effectively the same thing as using a style tag, but the syntax is more terse.

Might be interesting to run this in Node and have it actually output a CSS
sheet of all the selectors you use -- a sort of compilation step to build a
sheet of just the stuff you need and to take advantage of the performance
benefits of plain-old-CSS.

------
aplummer
This is about as serious an anti-pattern as I've seen in css.

------
skewart
As lots of comments have pointed out this is pretty useless in its current
form. However, the general idea and direction is certainly worthwhile - a
light and simple solution for the universal pain point that is CSS.

A few ideas for where to take it come to mind:

Ditch the JS and just write a library of generic CSS classes that solve common
use cases. Crucially these have to provide at least _some_ abstraction above
raw CSS styles (e.g. "always-centered-vertically" and not "margin-left").
There are lots of these libraries out there already, but maybe there is room
for something a little less opinionated, or lower level, or higher level, or
whatever than what you get with, say, Bootstrap.

Keep JavaScript in the mix but use it at build time, not in the browser. Maybe
you scan the source to see which classes are actually used and dynamically
generate a .css file to send to the client that only includes those classes
and no others. Or maybe you could use JS to do some fancier layout solving -
depending on the structure of the dom elements in the source - to generate
correct CSS attributes to support the abstraction.

I'm not super familiar with the state of CSS tools, so maybe things like what
I'm describing already exist by the dozens. I just know that CSS is a pain,
and I appreciate anyone who wants to make working with it easier.

------
jasonszhao
And semantic markup is just thrown in the trash And forsaken?

~~~
keville
Don't worry, it's got company down in the bin along with Separation Of Content
And Presentation.

I guess if you only make HTML email templates, this is the library for you!

~~~
mschuster91
> I guess if you only make HTML email templates, this is the library for you!

No JS in html emails, it doesn't work at all.

~~~
kjax
Another poster hinted at a intermediate step to map the declarations to inline
styles, so perhaps in that situation it'd work. Really though, it's unlikely
that someone would be manually constructing email templates at such a volume
to make that approach worthwhile.

------
WiseWeasel
This is pretty close to how I typically code sites, with a collection of
commonly used formatting classes defined in my CSS like 'margin-b10',
'padding-3pc', 'padding-h10' (left and right), etc. I have a fairly long list
of those I typically bring from one project to the next, for one-off use
throughout. I still use more comprehensively defined classes for widgets and
content types, but for things like spacing out inputs on the same line, these
are pretty handy.

Not sure how well this is going to work with the CSS being applied by JS after
the render; I suspect it would tend to suffer from FOUCs. It would be nice to
see an example implementation to allay those concerns. I do like the basic
pattern though, as long as it's used sparingly. I find it more convenient to
add classes like these than to use inline styling, even if there's no
operational advantage, as these format classes are often applied in addition
to other classes.

~~~
dheera
What's the point of creating a class called 'margin-b10'? Why not just inline
your CSS, i.e. style="margin-bottom:10px;"?

Creating a class called margin-b10 is tantamount to the following C code:

    
    
        int one = 1, two = 2, three = 3;
    

And then using 'one', 'two', and 'three' instead of 1, 2, 3.

~~~
WiseWeasel
Because there are a few paddings and margins that are used repeatedly, and
it's convenient. Clearfixes and floats are another common use case. An anchor
that I want to look like a button might have classes like "button orange
float-r margin-r20".

~~~
dheera
If you're repeatedly using 10px paddings, it doesn't really save anything to
name your classes 'padding-10px'. Inlining your CSS is just as efficient.
Plus, if you have to change your styling, e.g. from 10px to 12px, all of a
sudden you have to change both the definition of the class AND the name of the
class, which is a mess. And if you don't, you have a class called
'padding-10px' that is actually 12px and that is a real mess.

If you're naming your classes to create abstractions, i.e. 'article-box' or
'navbar-section' then it makes a lot more sense.

------
itslennysfault
It's all the bad aspects of inline styles with half the readability and as an
added bonus it's slower because the styles aren't applied until JS parses the
entire DOM. Am I missing something or is this really the worst idea?

------
dnewcome
This is basically the Atomic CSS idea [1]. Yes it violates separation of
concerns, but it does a good job at getting the page weight down.

[1] [http://acss.io](http://acss.io)

~~~
aplummer
What on earth, that is published by Yahoo!? Putting aside separation of
concerns, what about the lack of DRY and maintainability of that.

------
andrewingram
How...

* ...does the page look before the JavaScript loads

* ...do you handle media queries, pseudo selectors, pseudo elements

* ...is this better than inline styles (only one I can think of immediately is support for stuff like autoprefixer, but that isn't needed for any of the provided functionality)

Basically, what's the benefit here? Is is just to avoid using inline styles?
Has the anti-inline-style dogma become so strong that we basically invent a
version of inline styles just to get around using them?

------
atrophying
It's the ghost of HTML 3.2, now with excess DOM manipulation!

Oh god now I'm having flashbacks to <tr align="center"><td colspan="3"
nowrap><img src="spacer.gif" height="100" width="150"></td></tr> make it stop.

------
bryanrasmussen
The only way that something like this would be beneficial is if it was a set
of classes that did common necessary calculations of margins, positions etc.
in relation to some context setting class.

However I doubt it would good enough that I wouldn't hate it and refuse to use
it.

------
dplgk
How's the performance?

~~~
joshfraser
Not good, because the JavaScript blocks the rendering.

------
klouczers
Looks like shortcuts for inline styles. Even not all of them.

