6 ms·

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

30 points by kamranahmedse 11y ago

tylermauthe 11y ago
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.
dplgk 11y ago
How's the performance?
- joshfraser 11y ago
  Not good, because the JavaScript blocks the rendering.
frik 11y ago
or you just inline CSS? You can combine formulas as well vs inline css
- Semiapies 11y ago
 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 11y ago
 There may be some memory benefits to caching the styles.
WiseWeasel 11y ago
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.
- lf-non 11y ago
  I wrote something similar a while ago (https://gist.github.com/lorefnon/ddb1880e64d8e1071bb0 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.
- dheera 11y ago
  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.
  - Semiapies 11y ago
    Horribly, that sort of thing has been done by inexperienced programmers told to use constants instead of hard-coding numbers into their code...
  - WiseWeasel 11y ago
    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".
Kequc 11y ago
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 11y ago
  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.
jasonszhao 11y ago
And semantic markup is just thrown in the trash And forsaken?
- keville 11y ago
  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 11y ago
    > 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 11y ago
      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.
aplummer 11y ago
This is about as serious an anti-pattern as I've seen in css.
klouczers 11y ago
Looks like shortcuts for inline styles. Even not all of them.
itslennysfault 11y ago
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 11y ago
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 11y ago
  What on earth, that is published by Yahoo!? Putting aside separation of concerns, what about the lack of DRY and maintainability of that.
jameslk 11y ago
Wouldn't it be easier to just go back to using HTML tables and , , , 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 11y ago
 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.
andrewingram 11y ago
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 11y ago
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.
bl4ckdu5t 11y ago
What's the benefit of this over having utility classes right in the CSS?
bryanrasmussen 11y ago
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.
skewart 11y ago
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.

30 points by kamranahmedse 11y ago

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.

dplgk 11y ago

How's the performance?

joshfraser 11y ago
Not good, because the JavaScript blocks the rendering.

frik 11y ago

or you just inline CSS? You can combine formulas as well vs inline css

Semiapies 11y ago
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 11y ago
  There may be some memory benefits to caching the styles.

WiseWeasel 11y ago

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.

lf-non 11y ago
I wrote something similar a while ago (https://gist.github.com/lorefnon/ddb1880e64d8e1071bb0 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.
dheera 11y ago
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.
- Semiapies 11y ago
  Horribly, that sort of thing has been done by inexperienced programmers told to use constants instead of hard-coding numbers into their code...
- WiseWeasel 11y ago
  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".

Kequc 11y ago

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 11y ago
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.

jasonszhao 11y ago

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

keville 11y ago
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 11y ago
  > 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 11y ago
    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.

aplummer 11y ago

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

klouczers 11y ago

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

itslennysfault 11y ago

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 11y ago

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 11y ago
What on earth, that is published by Yahoo!? Putting aside separation of concerns, what about the lack of DRY and maintainability of that.

jameslk 11y ago

Wouldn't it be easier to just go back to using HTML tables and , , , 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 11y ago
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.

andrewingram 11y ago

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 11y ago

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.

bl4ckdu5t 11y ago

What's the benefit of this over having utility classes right in the CSS?

bryanrasmussen 11y ago

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.

skewart 11y ago

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.