In defense of functional CSS

> but it's orthogonal to the things that make Tailwind and functional css great

exactly. that's what i've been saying, and why i don't understand why "inline css" and "functional css" have been conflated.

i'm not sure why you're bringing up react -- i'm talking about the general case of writing markup. obviously you sometimes might write it directly by hand, and sometimes it might be generated for you by react components or server-side components or whatever.

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

You are correct from one point of view. But, the point I was making was that the class definitions for bg color can be contained within a single file in your application. Using `style` is completely different in that anything is possible. This is a big deal, as cutting down on possibilities/simplifying is a very important process in software engineering.

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