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

221–230 of 246 posts

Re: In defense of functional CSS

#221

Post by criswell »

err4nt wrote: post #203
criswell wrote: post #120

Earlier quoted context omitted.

This is how you can do all of that: class="hover:red" -> .hover\:red:hover { color: red } class="before:red" -> .before\:red::before { color: red } class="medium:red" -> @media (min-width: 500px) { .medium\:red { color: red } The important thing though is it doesn't need to be used for everything. I think it makes a lot of sense for structural stuff. When you dig into like, children of a hovered element I can see it…

How come people who do this only ever use class names? Why not invent your own data attribute like data-hover="red" where you create new namespaces for things like hover, or pseudo classes, why it it always only ever class names?

Totally talking without thinking about it too much here:

The classList API makes modifications to the class property very easily.

You'd be essentially limited to one identifier in attribute selectors. You can't really select from multiple identifiers with a data attribute without doing like:

  [data-hover*="foo"]
which would search for "foo" anywhere in the attribute, which could mean incorrect substring matches.

Chaining attribute selectors would be rough too:

  [data-hover*="foo"][data-hover*="bar"] {}
vs

  .foo.bar {}

Re: In defense of functional CSS

#222

Post by strken »

yakshaving_jgt wrote: post #113
toastercat wrote: post #89

Earlier quoted context omitted.

> How is this any different from saying "don't write functions, just repeat the same 10 lines the function would have in each place you'd use the function"? I think it is more comparable to using function composition, hence the whole "Functional CSS" moniker. The idea is using multiple atomic "functions" (in this case, in the form of classes) to transform an element by composing. Think like the pipe operator in Elixi…

It's actually nothing to do with the pipe operator in Elixir. In any programming language, the order in which you compose functions is important. In CSS — and in keeping with your analogy — the order in which "functions" are defined is important.

This is a really interesting discussion because it makes me wonder what CSS could have been like if it had cascaded per-element according to the order of classes.

Re: In defense of functional CSS

#224

Post by chrisweekly »

jonahx wrote: post #63
chrisweekly wrote: post #21

Functional CSS is a terrific approach. Tailwind in particular is exemplary. Absent this approach, in web projects of nearly any size, the CSS inevitably grows and becomes increasingly difficult to maintain. It takes very very few cases of "I'll just write a bit more CSS" as the default solution to bug fixes or changing requirements, before the best-intentioned design system becomes a brittle nightmare. Whereas functi…

so i'm on board with your central concern here. my issue with functional css is that your markup has no semantics. you can't just look at it and know what things are by their names. ie, what the hell is that thing described by all those styles? versus: and i know immediately what it is, and can instantly map the markup to what i see on the page. you just lose too much by not having that imo. i really like composing s…

"... your markup has no semantics. you can't just look at it and know what things are, by their names."

Huh? I think you've got it exactly backwards. My React components all have semantic names. In contrast, you're apparently using raw HTML "div" elements and relying solely on your style classes' names for semantics. You can certainly do that (with or without functional css) but it's orthogonal to the things that make Tailwind and functional css great, and your complaint makes me wonder about your setup; it's almost as if you're hand-writing and maintaining static HTML identical to what you see with "view source". Are we both talking about styling web applications?

Re: In defense of functional CSS

#225

Post by [deleted] »

darekkay wrote: post #99
blauditore wrote: post #81

Earlier quoted context omitted.

> If I extract a real reusable ProfileCard component, I can apply functional CSS to it exactly once. If the color changes, it's just a single place I need to look into. Then you're basically moving re-use from CSS to HTML templates. And if both exist only once, it shouldn't matter where you have to adjust that one line.

You're right. My main point was to separate your code by purpose instead of technology. That's where component-based development is heading to. If you're using components, then you're still free to choose one or another CSS aproach, but most functional CSS downsides don't apply anymore. My team in fact combines both approaches. I don't need to define a CSS component just to add some margin, but I am also free not to…

[deleted]

Re: In defense of functional CSS

#226

Post by HelloNurse »

naasking wrote: post #74
HelloNurse wrote: post #46

Earlier quoted context omitted.

Both "solutions" don't address the problem of repeated class names, they just help repeating them in a correct but not less obscene way. Bloated markup cannot be defended.

Yes they do, at least in a way that's no worse than every other CSS toolkit in widespread use. And there's nothing "correct" or "incorrect" about it. I suggest reading [1] if you want some real data on the usefulness of functional CSS. [1] https://hackernoon.com/full-re-write-with-tachyons-and-funct...

I mean "correct" in the formal sense that every element gets the intended style, which is possible even with bad design and bad technology.

Re: In defense of functional CSS

#227

Post by darekkay »

wvenable wrote: post #192
darekkay wrote: post #99

Earlier quoted context omitted.

You're right. My main point was to separate your code by purpose instead of technology. That's where component-based development is heading to. If you're using components, then you're still free to choose one or another CSS aproach, but most functional CSS downsides don't apply anymore. My team in fact combines both approaches. I don't need to define a CSS component just to add some margin, but I am also free not to…

I don't understand why I'd use functional CSS over inline styles. With inline styles I have editor auto-complete, no confusion as to whether it "pt-10" or "pt-15" even exists. I make pretty heavy use of cascades and don't put classes on every single HTML tag and try and keep my HTML as semantic as possible even though I actually do have components for every button. I will put an inline style of something if that is t…

For me, it's about atomic design. I want to use predefined, reusable values only. So I'm only able to use "pt-10" for 10px and "pt-20" for 20px (as an example). With inline styles, nothing prevents me from using "padding-bottom: 11px" (which may not be defined in the style guide).

Also, from the article:

- Inline styles don't respect media queries, which basically rules out responsive design

- Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue)

- Inline styles cause specificity issues, since they trump separate stylesheets.

- Inline styles don't support print-specific styles.

- Inline styles can't address pseudo-elements (such as ::before and ::after)

- Inline styles can't apply to multiple elements. Utility classes can define .bg-blue once and have it apply to many things, which leads to shorter markup and quicker rendering speed.

- Inline styles are a pain to type. Compare class="f-sm bg-blue" to style="font-size: 10px; background-color: #0000ff;".

Re: In defense of functional CSS

#228

Post by ian1321 »

wvenable wrote: post #196
ian1321 wrote: post #35

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

Seems like a waste of time when you can just do style="background: red;". You're not adding anything to CSS you're just renaming and enumerating all the style attributes and values. I think it makes sense in small doses but I think once you're using shell scripts to generate all these combinations you've lost the plot.

There's a big difference between class="u-bg-red" and style="background: red;". The big difference being that the class make it so that it is first-class application idea.

And I think that may be one of the larger points here. CSS can be simple, and using techniques like this forces it to stay that way. You have to take a step back and understand what we're trying to do as engineers. I would argue that being able to quickly understand code (e.g. the context to understand a line of code is small) should be a top priority of most software project.

Re: In defense of functional CSS

#229

Post by darth_mastah »

batmansmk wrote: post #139
crazygringo wrote: post #68

How is this any different from saying "don't write functions, just repeat the same 10 lines the function would have in each place you'd use the function"? The real kicker: > "I don't want to have to repeat the same 20 classes on every single button." That's understandable. I will say that there's a chance that repeating those 20 classes can actually be somewhat valuable, because when you get into a situation where on…

Disclaimer: we have been using functional css for about 2 years. Let's review the main use case you present "I want to tweak all buttons on the site, I tweak it in one place": - How many times do I have to change all the buttons on my app? - Does changing one class work to change all buttons in practice? Don't I end up having the color overloaded 3 times, cascading over and leaking in 5 others spots? - Are most of my…

I've been working with the front end for over a decade now in small and big teams, with different approach to CSS. I've seen things go horribly wrong for all the seemingly good reasons. Bloated CSS, people fearing to make any changes to existing "semantic" classes, people making changes to existing classes and introducing unforeseeable bugs in remote parts of the application, you name it. In my view nothing beats functional CSS. It's simple, pragmatic, easy to read and understand. And most importantly it'd hard to introduce hidden bugs with this approach.

Re: In defense of functional CSS

#230

Post by [deleted] »

darth_mastah wrote: post #229
batmansmk wrote: post #139

Earlier quoted context omitted.

Disclaimer: we have been using functional css for about 2 years. Let's review the main use case you present "I want to tweak all buttons on the site, I tweak it in one place": - How many times do I have to change all the buttons on my app? - Does changing one class work to change all buttons in practice? Don't I end up having the color overloaded 3 times, cascading over and leaking in 5 others spots? - Are most of my…

I've been working with the front end for over a decade now in small and big teams, with different approach to CSS. I've seen things go horribly wrong for all the seemingly good reasons. Bloated CSS, people fearing to make any changes to existing "semantic" classes, people making changes to existing classes and introducing unforeseeable bugs in remote parts of the application, you name it. In my view nothing beats fun…

[deleted]
Post reply on HN