Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

In defense of functional CSS

mikecr.it

Post reply on HN
Print view View original

31–40 of 246 posts

Re: In defense of functional CSS

#31

Post by dsego »

sklivvz1971 wrote: post #6

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" clas…

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.

Re: In defense of functional CSS

#33

Post by madeofpalk »

jekrb wrote: post #26
madeofpalk wrote: post #14

Earlier quoted context omitted.

Sure it does. It tells you that it looks like a Button, with some primary variation styles.

Which is useful, but that's the extent of the depth of information I'm getting. I like that functional CSS lets me see "how something is" over "what something is."

Isn't this the same as regular programming? When you have a function called updateUser(), that doesn't tell you every single thing about its implementation, nor do we expect it to.

Re: In defense of functional CSS

#34

Post by ekzy »

Flenser wrote: post #28

What about theming/branding so that you can make your enterprise web-app fit in with each of your clients other web-apps? If your class names are semantic like profile-card it's easy to have a branding css file for each client. If your class names are functional like m-5 p-5 text-gray-light bg-gray-darker border border-gray-light you're going to... what? make code changes for each client? Obviously if the website is…

It's all about tradeoffs, there are no silver bullets. If your class name is like profile-card then it could be simpler... until it's not. Because it turns out that one of your client profile-card needs to behave slightly differently on hover or whatever. In theory, profile-card is a great idea, in practice it can be a headache

Re: In defense of functional CSS

#35

Post by ian1321 »

I used this technique in my previous startup. I even had shell scripts that generated my LESS files.

One of the driving philosophies was that when one saw a CSS class, they should easily be able to find it's definition in the source. Another driving philosophy was that one should easily be able to determine what the class is doing.

This lead to classes like `u-centered`. The `u` tells me it's in the utils.less file. Classes starting with `l-` were layout classes, `t-` text classes, etc..

I had classes like this:

u-{max,min}-width-{xxs,xs,s,m,l,xl,xxl}

t-white

u-bg-red (red background)

t-h3

l-container-{xxs,xs,s,m,l,xl,xxl}

You get the picture.

(The nice thing about xl and xs is that you can keep adding x's as you need.)

I found it to be very effective. I understand the arguments that it kind of defeats the purpose of CSS, but I think CSS is pretty easy to mess up, and this give you a solid, consistent structure to work with.

Of course, I didn't follow this style 100%. There were some cases where it just made sense to use a more semantic style, but I found those case to be few and far between.

Re: In defense of functional CSS

#36

Post by hownowbrowncow »

Yikes.

I agree that this might help you move quickly when starting a project and might be a fine approach for a small prototype or personal site (or, more unkindly, in a consulting project). But you pay a huge cost: maintainability. There is no encapsulation at all, not to mention the pain of having all these generic classes floating around, colliding with anything that might accidentally match. I’ve worked on projects like this where huge HAML views chain many of these functional CSS classes. It makes it very difficult to accommodate new external components or design updates which I would say are pretty much inevitable in any product company. Even if you don’t add anything new, good luck updating the entire system to adjust the padding on all buttons unless you were disciplined enough to truly create encapsulating classes (which is really the opposite approach of functional CSS anyway).

I really think CSS modules got it right (or similar approaches where you have a unique class name per component). Our team approaches component styles like a UIView in iOS—it should render acceptably with reasonable constraints. This means any parent component / view can render this and set display: block, flex, etc and the contents should largely adapt. These days this is pretty easy with flexbox and grid. Even better—you can ensure that the markup classes stay private to you and only allow modifications through JS (or mark some classes as :global). Even better than that—your components can adopt delegation or renderProps to allow parent views to replace / modify with their own markup so everything in the component can truly be encapsulated.

Re: In defense of functional CSS

#37

Post by stan_rogers »

ekzy wrote: post #34
Flenser wrote: post #28

What about theming/branding so that you can make your enterprise web-app fit in with each of your clients other web-apps? If your class names are semantic like profile-card it's easy to have a branding css file for each client. If your class names are functional like m-5 p-5 text-gray-light bg-gray-darker border border-gray-light you're going to... what? make code changes for each client? Obviously if the website is…

It's all about tradeoffs, there are no silver bullets. If your class name is like profile-card then it could be simpler... until it's not. Because it turns out that one of your client profile-card needs to behave slightly differently on hover or whatever. In theory, profile-card is a great idea, in practice it can be a headache

It's never not simpler.

Re: In defense of functional CSS

#38

Post by nailer »

naasking wrote: post #22
nailer wrote: post #11

Earlier quoted context omitted.

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.

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

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

Re: In defense of functional CSS

#39

Post by Flenser »

DanielBMarkham wrote: post #23

Neat. Now add a way to hierarchically roll-up these micro-classes into semantic classes behind the scenes (Perhaps in webkit?). Compile things so you only carry-around the css micro-classes you've used, and make a flag to either deploy using the semantic or micro class method. Best of both worlds. There are also some other mix-and-match ways of doing this. Where the real value is separating the tiny CSS adjustments y…

You could do this with SASS or LESS.

Make all the "functional" classes as abstract mixins or placeholder selectors (in SASS parlance), and then use them to define your concrete semantic classes.

Re: In defense of functional CSS

#40

Post by weego »

This stuff never scales. No one can remember the class names, no one want's to search through the examples and style guides for a project, no one want's to standardise naming of their own hacks etc and so you start of with good intentions and end up with a lot of duplication and a whole lot of shit.

CSS is an expressive markup. You shouldn't try to turn it into programming.

Post reply on HN