Furnish JavaScript - Let the classes on DOM elements generate the CSS for you | Hacker News Reader

Furnish JavaScript - Let the classes on DOM elements generate the CSS for you

github.com

30 pointskamranahmedse29 comments

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

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.

or you just inline CSS?

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

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

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!

There may be some memory benefits to caching the styles.

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.

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.

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.

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

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.

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

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!

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

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.

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.

I wrote something similar a while ago (https://gist.github.com/lorefnon/ddb1880e64d8e1071bb0) -- never intended to use this in production but had a good laugh with co-workers when I showed it to them.

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.

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

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.

Horribly, that sort of thing has been done by inexperienced programmers told to use constants instead of hard-coding numbers into their code...

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?

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

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

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?

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.

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.

How's the performance?

Not good, because the JavaScript blocks the rendering.

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

Reply on news.ycombinator.com