Wow, this gets some real hate on HN. I highly recommend reading [0] instead (which is by the way linked in the main article).
If you're writing HTML by hand, then yes, it will be a PITA changing all those "bg-blue" Profile Cards using functional CSS (while it's just a single change when using .profile-card instead). In reality, it's not the functional CSS being the issue, but the markup duplication. 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.
There is no silver bullet. If you design web sites, try some templating language to extract your components. If you develop web apps, take any modern framework like React, which enforces using reusable components. If you still prefer writing HTML by hand, then yes, functional CSS is not for you.
It's a much better article, but really jumps the shark by the end, and the reasoning to convince become very unsound, like suggesting you'd only end up with ridiculous classes like 'image-card-with-a-full-width-section-and-a-split-section' .. but no I wouldn't.. I wouldn't ever put layout in a class name (full width), I'd call it the hero, priority or whatever it was semantically, which is a discussion with the ui/ux members of the team.
Composing utility classes via css (ala, what many have done for years since sass/less) is one thing, but then collapsing the component class all the way back to the html I really can only describe as jumping the shark, it's gone beyond logic.
> 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 use 15 functional classes to clutter the HTML.
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 the most logical approach but proper semantic classes allow me to work at a higher level than individual styles.
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;".
> 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).
I would call these "padding-small" or "padding-big" in that case. Of course, a better way would probably be to abstract that even further in actual purpose rather than style.
> Inline styles don't respect media queries, which basically rules out responsive design
I question how you could have style-like-classes like pt-10 and be responsive at the same time. So this style is padding-top: 10px as it's name suggests except on mobile. That makes no sense.
> Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue)
That's fine. Although why limit yourself to calling the class "blue" when you could call it "brand-color" and actually be able to change it something other than blue in the future.
> Inline styles cause specificity issues, since they trump separate stylesheets.
I don't think you want your "pt-10" style to be "trumped" by another style otherwise that would be confusing. So again this is not an advantage to this style.
> Inline styles don't support print-specific styles.
Again, it would be confusing if "pt-10" suddenly didn't apply when printed.
> 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.
So the advantage is you get to type 5-10 fewer characters per element you apply it to?
> Inline styles are a pain to type. Compare class="f-sm bg-blue" to style="font-size: 10px; background-color: #0000ff;".
Only if you know all the classes that actually exist for the particular project you are working on. Does f-md exist? Is really "fd-small" in this project? My editor will autocomplete inline styles so they might actually be easier to type.
>> 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).
>I would call these "padding-small" or "padding-big" in that case. Of course, a better way would probably be to abstract that even further in actual purpose rather than style.
This is perfectly fine. Functional CSS does not enforce any naming. In Bootstrap it's just "p-1" through "p-5". But I would rather go with more semantic names, too.
>> Inline styles don't respect media queries, which basically rules out responsive design
>I question how you could have style-like-classes like pt-10 and be responsive at the same time. So this style is padding-top: 10px as it's name suggests except on mobile. That makes no sense.
Following your example, you can have "padding-small" with different paddings on Desktop and Mobile. Which is not possible using inline styles. For Bootstrap you get media query suffixes for many classes. One common usage is "d-flex flex-column flex-md-row", which makes an element "flex", with column direction on mobile and row direction on desktop. Handy for simple use cases like that.
>> Inline styles aren't limited to pre-defined options, meaning you can still end up with 90 different shades of blue)
>That's fine. Although why limit yourself to calling the class "blue" when you could call it "brand-color" and actually be able to change it something other than blue in the future.
Again, I think you're mistaking a single Functional CSS implementation (like the one used by the author) with the concept itself. You are not forced to use color names and numbers in your functional CSS class names. And I fully agree that semantic naming is way better.
>> Inline styles cause specificity issues, since they trump separate stylesheets.
>I don't think you want your "pt-10" style to be "trumped" by another style otherwise that would be confusing. So again this is not an advantage to this style.
What the author means: using only functional classes, you know exactly that your "pt-10" padding is not overwritten (unless you use another "pt" class by mistake). With "traditional" classes, you can't be sure of that. And more often than not you will get problems with the cascade, especially in bigger projects with many developers. That's where all the "!important" hacks are coming from.
>> Inline styles don't support print-specific styles.
>Again, it would be confusing if "pt-10" suddenly didn't apply when printed.
You can do much more with CSS than adding padding ;) Hiding elements for print is the main use case here. You can't achieve this with inline styles only. A "print-hidden" utility class can do that.
>> 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.
>So the advantage is you get to type 5-10 fewer characters per element you apply it to?
No, the advantage is that you can use only pre-defined, reusable, atomic definitions. If the style guide says there are only 2 types of padding ("padding-small" and "padding-big"), you won't be able to set another padding using functional CSS only. With inline styles, you can do whatever you want. This also applies to raw CSS stylesheets. That's why pre-processors are so valuable - you can define your SASS/LESS/whatever variables and achieve the same effect. And before you ask: "then why do I need functional CSS in the first place?" - it's because of the other advantages, like not having to use a pre-processor or defining/importing a stylesheet in the first place.
>> Inline styles are a pain to type. Compare class="f-sm bg-blue" to style="font-size: 10px; background-color: #0000ff;".
> Only if you know all the classes that actually exist for the particular project you are working on. Does f-md exist? Is really "fd-small" in this project? My editor will autocomplete inline styles so they might actually be easier to type.
If you don't know all the classes, then you need to know all the style guide values. Otherwise, how do you implement a consistent-looking design? Take our "only 2 padding values defined" example. You will have to look stuff up, be it functional class names, traditional class names, SASS variables or simply the values to be used. Also, my editor will autocomplete functional CSS classes, too.
> I think you're mistaking a single Functional CSS implementation (like the one used by the author) with the concept itself.
Honestly at some point what you describe I would just describe as normal CSS.
Functional CSS is classes based on their visual function rather than an abstract concept. This the definition. But the more semantic your names are the less they related to an actual visual function.
If on mobile you don't apply any padding then your padding CSS class is a lie. And if you don't call it "padding" in some way then it's not Functional CSS. I also think conceptually having a few utility classes like "print-visible" or "print-invisible" is not really applying Functional CSS as an overall concept.
If you're writing HTML by hand, then yes, it will be a PITA changing all those "bg-blue" Profile Cards using functional CSS (while it's just a single change when using .profile-card instead). In reality, it's not the functional CSS being the issue, but the markup duplication. 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.
There is no silver bullet. If you design web sites, try some templating language to extract your components. If you develop web apps, take any modern framework like React, which enforces using reusable components. If you still prefer writing HTML by hand, then yes, functional CSS is not for you.
[0] https://adamwathan.me/css-utility-classes-and-separation-of-...