In defense of functional CSS
mikecr.it
In defense of functional CSS
1–10 of 246 posts
Re: In defense of functional CSS
#2Found myself in agreement up until the concept of "semantic CSS class names". If you want semantic markup, then CSS is absolutely not the place to implement it IMHO.
Re: In defense of functional CSS
#3Font + colour scheme made this article unreadable.
Re: In defense of functional CSS
#4We did this for a project a few years ago and it was alright. In the end we decided against doing it again purely because the DOM became so extreme with one-rule classes that it became a nightmare to read the templates. So much noise.
For building things out and prototyping it was amazing though.
On the plus side our css file was so tiny.
Re: In defense of functional CSS
#5Font + colour scheme made this article unreadable.
I found the background colour a bit easier on the eyes personally. The font is a bit ugly though.
Re: In defense of functional CSS
#6This seems to misunderstand the basics of why we have CSS in the first place, to separate "how something appears" from "what something is", and suggests to mix the two.
The obvious result is that you would end up with similar objects with different styles. A button with "main" role should have a consistent style across instances, not be green in one place and grey in another because you forgot to add the "green" class. Also changing the color of "main" buttons from green to blue should not entail changing each usage of the "green" class to a usage of a "blue" class.
Re: In defense of functional CSS
#7Found myself in agreement up until the concept of "semantic CSS class names". If you want semantic markup, then CSS is absolutely not the place to implement it IMHO.
It doesn't seem to me that the author defends semantic class names
Re: In defense of functional CSS
#8This seems to misunderstand the basics of why we have CSS in the first place, to separate "how something appears" from "what something is", and suggests to mix the two. The obvious result is that you would end up with similar objects with different styles. A button with "main" role should have a consistent style across instances, not be green in one place and grey in another because you forgot to add the "green" clas…
I often wonder how useful this septation actually is. Most of the apps I have worked on seem to be horribly coupled despite separate css.
Re: In defense of functional CSS
#9Most of the "a lot to love" points are also hit by BEM/SMACSS. In regard to this point:
>You never have to deal with one instance of a thing needing a slightly different style than the other instances, which screws up your reusable classes.
...what I found was that just as often, I'd need a new Atomic class different in a subtle way from existing ones, and this was annoying to implement because
a) it expands the kludge-dictionary of short class names you have to memorize, but often in a way that's too situational for anyone to actually memorize it, meaning the next time someone runs into the same problem they will re-invent the same solution rather than reread the entire list of Atomic classes to see if one exists, and
b) the whole point of Atomic is that I shouldn't have to be writing CSS, and I was, all the time.
Re: In defense of functional CSS
#10Why is this named "functional" CSS?
Something like "const FIVE = 5" doesn't seem to capture the essence of functional programming either?