6 ms·

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, t

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. [0] https://adamwathan.me/css-utility-classes-and-separation-of-concerns/ https://adamwathan.me/css-utility-classes-and-separation-of-...

blauditore 8y ago
> 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.
- darekkay 8y ago
  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.
  - wvenable 8y ago
    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.
    - darekkay 8y ago
      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;".
      - wvenable 8y ago
        > 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.
  - deleted 8y ago
    [deleted]
meandmycode 8y ago
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.

blauditore 8y ago

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

darekkay 8y ago
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.
- wvenable 8y ago
  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.
  - darekkay 8y ago
    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;".
    - wvenable 8y ago
      > 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.
- deleted 8y ago
  [deleted]

meandmycode 8y ago

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.