6 ms·

This 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

by sklivvz1971 8y ago

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

nailer 8y ago
This. In addition, it means you have to edit multiple things to change how something looks. If .login-box is now going to be larger but green, you'd normally just edit the CSS to change that. With visual classes, you might have to modify the HTML to add/remove/change classes, then also edit the CSS. Or maybe only the HTML. Or maybe only the CSS. It's hard to know.
- naasking 8y ago
  > If .login-box is now going to be larger but green, you'd normally just edit the CSS to change that. No you don't, you can edit the one LESS/SASS/whatever file, and rebuild to reflect the change in your custom class that mixes in the desired properties, done. Or you do the same in your HTML templating language. All of the code reuse patterns you're used to from regular programming are applicable here, and that's why it's better. Also, if you're in a larger team with separation of responsibilities, then the UI-focused person can make the change without you without having to understand CSS. Functional CSS is considerably more flexible.
  - nailer 8y ago
    I think you misread my comment. By 'normally' I mean using regular 'CSS controls how something looks' HTML, and not using visual class names (that this author calls 'functional CSS').
    - naasking 8y ago
      I quoted the wrong sentence, I meant to reply to the "you'd have to edit the HTML" aspect. Functional CSS lets you wrap up composite styles in various ways, similar to abstracting a function in normal programming, so you don't necessarily have to do this. You can though, and it's often simpler to do so.
collyw 8y ago
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.
- lucideer 8y ago
  You can introduce implicit coupling in any app (i.e. in a non-CSS programming language). It's bad practice in both cases. This kind of separation doesn't magically make your frontend code good, it just gives you the freedom to architect it well. Whether you do is up to you. Admittedly it is very difficult to find an example where this has been done well, but this is I guess why we have abominations like AMP.
  - collyw 8y ago
    Sure it is bad design, I won't argue with you on that. But the other thing is that we rarely upgrade just CSS, usually we get a whole new front end, or even more likely a whole new app.
dsego 8y ago
In my experience, more often than not, the opposite is happening. The designer wants the same widget to have a slightly different style in different places. Then you either give it some additional class for context or use helper classes. Benefits of either approach seem to be moot. Reusability suffers in any case.
- have_faith 8y ago
  I've found this is (usually) solved with soft skills. I just talk to the designer and explain we have all these very similar components already and it will help with the visual consistency if we follow an existing convention OR update the existing convention to use the new style (giving them the option to choose let's them stay in control of the design). They are usually very understanding as they don't always consider these things.
  - WorldMaker 8y ago
    It's also rarely a surprise that if you ask "why did you special case this particular [button/widget]?" to some designers the answer turns out to be "I didn't have a good template and just redrew it" or "I don't know, I was just freehanding that because I was in the flow".

nailer 8y ago

This. In addition, it means you have to edit multiple things to change how something looks. If .login-box is now going to be larger but green, you'd normally just edit the CSS to change that. With visual classes, you might have to modify the HTML to add/remove/change classes, then also edit the CSS. Or maybe only the HTML. Or maybe only the CSS. It's hard to know.

naasking 8y ago
> If .login-box is now going to be larger but green, you'd normally just edit the CSS to change that. No you don't, you can edit the one LESS/SASS/whatever file, and rebuild to reflect the change in your custom class that mixes in the desired properties, done. Or you do the same in your HTML templating language. All of the code reuse patterns you're used to from regular programming are applicable here, and that's why it's better. Also, if you're in a larger team with separation of responsibilities, then the UI-focused person can make the change without you without having to understand CSS. Functional CSS is considerably more flexible.
- nailer 8y ago
  I think you misread my comment. By 'normally' I mean using regular 'CSS controls how something looks' HTML, and not using visual class names (that this author calls 'functional CSS').
  - naasking 8y ago
    I quoted the wrong sentence, I meant to reply to the "you'd have to edit the HTML" aspect. Functional CSS lets you wrap up composite styles in various ways, similar to abstracting a function in normal programming, so you don't necessarily have to do this. You can though, and it's often simpler to do so.

collyw 8y ago

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.

lucideer 8y ago
You can introduce implicit coupling in any app (i.e. in a non-CSS programming language). It's bad practice in both cases. This kind of separation doesn't magically make your frontend code good, it just gives you the freedom to architect it well. Whether you do is up to you. Admittedly it is very difficult to find an example where this has been done well, but this is I guess why we have abominations like AMP.
- collyw 8y ago
  Sure it is bad design, I won't argue with you on that. But the other thing is that we rarely upgrade just CSS, usually we get a whole new front end, or even more likely a whole new app.

dsego 8y ago

In my experience, more often than not, the opposite is happening. The designer wants the same widget to have a slightly different style in different places. Then you either give it some additional class for context or use helper classes. Benefits of either approach seem to be moot. Reusability suffers in any case.

have_faith 8y ago
I've found this is (usually) solved with soft skills. I just talk to the designer and explain we have all these very similar components already and it will help with the visual consistency if we follow an existing convention OR update the existing convention to use the new style (giving them the option to choose let's them stay in control of the design). They are usually very understanding as they don't always consider these things.
- WorldMaker 8y ago
  It's also rarely a surprise that if you ask "why did you special case this particular [button/widget]?" to some designers the answer turns out to be "I didn't have a good template and just redrew it" or "I don't know, I was just freehanding that because I was in the flow".