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

161–170 of 246 posts

Re: In defense of functional CSS

#161

Post by yakshaving_jgt »

toastercat wrote: post #118
yakshaving_jgt wrote: post #113

Earlier quoted context omitted.

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.

I never said it has anything to do with the pipe operator, and I did not mean to imply that it is a direct equivalent to the pipe operator. But just as the pipe operator allows you to compose multiple pure functions, the idea with atomic CSS classes is that you are able to compose "pure" classes. The quotes are important here. Obviously, they are not 100% comparable. CSS is not a programming language.

It's a weak analogy.

In programming, `f . g . h` is not the same as `h . f . g`.

In CSS, `` is the same as ``.

In programming, the order in which you define functions is not important — it's the order in which you use them which is important.

In CSS, it is the exact opposite.

To further drive the point home: assuming the names of these classes aren't lying, what colour is the text of this element?

foo

It depends on the order in which the classes were defined. This also demonstrates why "pure" is a poor choice of word when describing anything to do with CSS. Nothing here is "pure".

Re: In defense of functional CSS

#162

Post by gyrgtyn »

darekkay wrote: post #67
jonahx wrote: post #63

Earlier quoted context omitted.

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…

One possible solution is in the article - nothing prevents you from using: with "profile-card" being use just for identifying the component. Other than that, I rarely go through HTML without Dev Tools, which shows me exactly what a certain div is for.

var profileCard = "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light"

Re: In defense of functional CSS

#163

Post by dsego »

tambourine_man wrote: post #130

Problem is, defining quantity in the class name doesn’t work. .m10 may be fine for desktop but not for mobile. Then you’ll have media queries which define .m10 as margin: 5px or something, which is nuts. You could go for unspecified .mSmall etc, but in real life, things tend to be more specific and messier, in my experience.

In bootstrap 4 you get responsive variants like .m-sm-1 and .m-lg-1. Then you can have class="m-3 m-sm-1" to have different margins for mobile and desktop.

Re: In defense of functional CSS

#164

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…

There's another active post right now [1] where Tailwind's creator has been addressing these understandable initial reactions.

TLDR: Tailwind is utility-FIRST not utility-ONLY, and its `@apply` directive and approach to composition means you can exercise a lot of control without every element requiring so much "noise".

Don't get me wrong, I'm not saying there's only one good way to do things and this is obviously it; rather, it's worth overcoming one's initial revulsion to look at what's possible, bc it is in fact quite elegant.

[1] https://news.ycombinator.com/item?id=18084013

Re: In defense of functional CSS

#165

Post by recursive »

dsego wrote: post #153
lgessler wrote: post #91

Earlier quoted context omitted.

Yeah, I really don't get it. As for this part: > when you get into a situation where one of the buttons needs to have slightly more margin-top than the others, then it's easy to fix You can have this with semantic classnames. In fact, that's exactly what the "cascading"[1] part of "cascading style sheets" was intended to solve. [1]: http://cssspecificity.com/

Cascading is bad and creates more problems than it solves.

This is definitely the opposite of my experience.

Re: In defense of functional CSS

#166

Post by dsego »

dsego wrote: post #153
lgessler wrote: post #91

Earlier quoted context omitted.

Yeah, I really don't get it. As for this part: > when you get into a situation where one of the buttons needs to have slightly more margin-top than the others, then it's easy to fix You can have this with semantic classnames. In fact, that's exactly what the "cascading"[1] part of "cascading style sheets" was intended to solve. [1]: http://cssspecificity.com/

Cascading is bad and creates more problems than it solves.

I see the downvotes already coming. Cascading is bad, it makes it hard or impossible to restructure things and move markup around. And then you have to fight specificity. An example from my work where someone put a bunch of tags under `.new-style` like `.new-style h1` and applies to every container which needs those new styles. Now if I add my component to that container, it completely breaks encapsulation because `.my-component-title` gets overridden by `.new-style h1`. And then you fight that with something ridiculous like repeating classes `.my-component-title.my-component-title`.

Re: In defense of functional CSS

#167

Post by achairapart »

dwaite wrote: post #146
achairapart wrote: post #137

Earlier quoted context omitted.

Most of the people commenting are missing one of the major point in "functional CSS": Keep specifity low = lower code size, less side-effects, higher maintainability. Yes, you add bits of complexity in the HTML, but you also gain almost no specifity on the CSS side.

Could you elaborate on this more? All three of these points seem counterintuitive to me. 1. "profile-card" takes fewer bytes than "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light", so the space-savings of not defining profile-card within the CSS seems to be lost the more you reuse semantic styles within your HTML. 2. "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" and "profile-card"…

1. Think about this: You have to write or customize .profile-card for every project, with "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" you're writing 0 lines of CSS. Zero. All your CSS will be your utility framework (sizes around 5~15kb) and it will never increase in size. Now, tell me you never seen a two year project where CSS alone reached 2+Mb because at every edit someone added another class to the list...

Also: When you gzip your HTML those repeated classes will compress pretty well.

2. Yes, you're right! Same specifity for the example in question. My point was more in general. Think @extend[0], nested selectors in SCSS. They look less scarier than "m-5 p-5 text-gray-light bg-gray-darker border border-gray-light" but they do not always do good.

And I can tell you'll have no side effects: If you look at the HTML only, what ".profile-card" does? Does it add padding, typography, borders, transitions? How do you extend it? I can't tell. But I know for sure that "m-5" will add margin and margin only. "bg-gray-darker" will add background-color and background-color only. And so on. Every class does only one thing. They don't overlap. Once you memorize the simple naming convention you can't go wrong.

3. Why it looks harder to maintain? Do you all really get scared by a few, readable, classes? Also, classes are no meant to be semantic or content-dependent[1].

At the end, I don't want to defend to death this practice. Maybe it's a concept that is hard to explain (and the OP tried a bit lightly) but I assure you, there are concrete benefits in using this approach. Many may not like it, and it's completely fine, but it's not the hell most of you are shouting here.

Peace! :)

[0]: https://webinista.com/updates/dont-use-extend-sass/ [1]: http://nicolasgallagher.com/about-html-semantics-front-end-a...

Re: In defense of functional CSS

#168

Post by Izkata »

ashelmire wrote: post #155
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…

> - How many times do I have to change all the buttons on my app? When making a styling change like this, it's typical to change it app-wide. > - 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? I can change the border-radius on all of my buttons, and they will all change, and still have their color-specif…

> Phew! A component just for a button. What a twist! I don't think most people are making components for each html element. In fact, I'd say this is pretty redundant and overengineering things in a bad way.

Welcome to the world of web components. This is actually really common, especially in React with css modules - this way you can use your custom button without even having to think about the CSS (or any extra complexity like tooltips and accessibility), even from a common library used across projects.

Re: In defense of functional CSS

#169

Post by bsaul »

matt4077 wrote: post #105
bsaul wrote: post #17

I’m about to start writing a very simple html page ( think search panel + result table underneath) after having stayed out of html for a few years. What are the current best practices regarding css tools and framework that could make my life easier ?

HTML + CSS, pure and simple. Don't overthink. Frameworks like bootstrap were useful back when they started: column layout (and other popular patterns) were hard to achieve, and each browser (and version) had their own quirks to work around. Today, CSS Grid and Flexbox are easier and more powerful than any framework, and aside from bleeding-edge features the major browsers have converged.

thanks, indeed last time i checked (a few years ago), flexbox weren't really widespread. I think i'll stick to that.

Re: In defense of functional CSS

#170

Post by RussianCow »

ashelmire wrote: post #155
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…

> - How many times do I have to change all the buttons on my app? When making a styling change like this, it's typical to change it app-wide. > - 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? I can change the border-radius on all of my buttons, and they will all change, and still have their color-specif…

> Phew! A component just for a button. What a twist! I don't think most people are making components for each html element. In fact, I'd say this is pretty redundant and overengineering things in a bad way. Guess what - html has these nifty components called buttons too, and you can also style them. Wouldn't any minor change to your button component require then passing in props (just like classes)? doesn't really seem better than to me.

We use custom components like this at work, and it actually works quite nicely because you get to see all the different "types" of buttons at a glance by looking at the prop types. Using the component looks something like this:

I've found that it's helpful for enforcing consistency, so that you have to go out of your way to apply custom styles to a button (which isn't required 95% of the time). Plus, it helps abstract things that don't have anything to do with the HTML element but are often tied together, like being able to automatically make a button a link without having to wrap it in an tag:

It's all minor stuff, but it enforces consistency and keeps you from having to think about CSS classes at all most of the time.

Post reply on HN