Comment by adamwathan | Hacker News Reader

Comment by adamwathan | Hacker News Reader

Parent Full thread

I used to think this way until reading this article by Nicolas Gallagher:

http://nicolasgallagher.com/about-html-semantics-front-end-a...

These days I'm quite convinced trying to author your markup such that you can redesign a site by applying a different stylesheet has the dependencies backwards.

If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building.

Your HTML documents are already coupled to your project, so rather than writing CSS that's coupled to that HTML, I've found it to work much better to author CSS from a mindset that the CSS knows nothing about the document it's trying to style.

This leads to writing what I call "library-style" CSS, where you are almost trying to build your own Bootstrap or similar; something that you could actually use on multiple projects if you wanted.

A class like "download-book" is not very useful if you have multiple buttons in a project that are meant to look the same way and not all of them trigger a book download.

I disagree. I find that SASS mixins provide the same reusability as classes but in a much cleaner way. True, it makes your HTML and CSS very coupled, but it does provide you with a true clean separation of content and presentation.

I find

  // style.scss
  @mixin button($color, $size) { ... }

  .download-book {
    @include button(
      $color: red,
      $size: big
    );
  }

  .send-email {
    @include button(
      $color: blue,
      $size: small
    );
  }

  // index.html
  <button class="download-book">Download book</button>
  <button class="send-email">Send email</button>

much cleaner than

  // style.scss
  .button { ... }
  .red { ... }
  .blue { ... }
  .big { ... }
  .small { ... }

  // index.html
  <button class="button big red">Download book</button>
  <button class="button small blue">Send email</button>

1. When you change the visual aspect of an element, you go to the stylesheet and don't go adding/removing classes from the content layer (HTML).

2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller.

Of course, your CSS file becomes a lot bigger. But when enabling compression, the stylesheets using mixins turn out to be smaller (see https://tech.bellycard.com/blog/sass-mixins-vs-extends-the-d...). Also, your HTML file is likely smaller too when using semantic classes.

I agree with your point of view as well. With Vue, I am writing all my styles in a .vue file which contains a component composed of style, markup, and js. It's incredibly clean and easy to maintain.

>> Of course, your CSS file becomes a lot bigger.

If you use something like webpack and you start splitting code based on the page you are on, this problem goes away as well.

I find that only place the 2nd case makes sense is if you are writing a CSS framework like Bootstrap. Otherwise, I find this way writing CSS increasingly rare.

> 2. When using generic names like "button", "big", "small", etc... I always find myself in a naming conflict at some point. The likelihood of semantic names having conflicts is much smaller.

css-modules[0] are a nice solution to this. Your nice, simple class names like "button" are transformed as part of build process to something less likely to collide, like "ltuZCYvCyDVU_2kG0Sspr":

[0]: https://github.com/css-modules/css-modules

I find tha the library-style "button" "red" "blue" "big" example prevents me from having to flip over and maintain CSS with every HTML change.

Yet your first example has everyone editing CSS files and appending new classes to it all the time, which in my experience is the fastest way to end up with unmaintainable CSS.

Mixins sounded good to me at first, but I've only experienced less maintainability when the CSS was too clever.

A class called "download-book" wouldn't be semantic either.

A semantic choice of classes should represent the roles that things have in the UI hierarchy: if a "book download" button is the main action of the page, it should have a class of, say "main-action", possibly with an extra "download" class to show UI specific to download actions.

If a "book download" button is just an action, for example a button that is repeated multiple times in a table, then it needs a different class, like "action", still possibly with "download".

This is exactly like properly written HTML is semantic, elements represent hierarchical roles ("nav", "footer"), not their look, nor their content.

that misses the point.

parent described things like moving the navbar to the left when the html can have it before or after the content on the dom. can you use float:left?

Strongly disagree, and the primary reason is that semantic HTML makes your source and stylesheets readable and easy to navigate and change for that reason. That is, setting aside technical arguments about re-usability for a moment, it's disastrous to have to look at a large codebase in this style:

    <div class="red pull-left pb3">
    <div class="grid row">
    <div class="col-xs-4">

when you could look at this:

    <div class="basket">
    <div class="product">
    <div class="searchResults">

The latter, aside from sparing your brain endless visual noise, makes it instantly clear how the html maps to the page elements.

Taken from http://maintainablecss.com/chapters/semantics/

> If you try to keep visual information out of your HTML, you end up authoring stylesheets designed to nimbly navigate your DOM structure to precisely target elements to style in a way that makes your CSS extremely coupled to the particular site you are building.

As for this technical argument, it's flatly untrue. Writing semantic HTML and the coupling you are referring to are completely orthogonal as long as you are using a tool like Sass / postCSS / etc to author your CSS.

Thing is, if you're using Angular (or most likely any of the hot SPA frameworks out there), you don't need semantic CSS class names, since the model bindings will make the meaning quite clear.

You're ignoring GPPs argument though, 'basket', 'product' and 'searchResults' aren't reusable. From the POV of a dev on your team (who knows the framework), I know how to change 'pull-left', 'row', 'col-xs-4' to get the result I want without CSS spelunking.

My answer was implicit is the final comment. The purpose of those elements is not re-use. It's clarity. The re-use happens in the Sass (or other preprecessor) code. Somewhere in your Sass, you define "basket" as a "pull-left; row; col-xs-4" or even higher level constructs which you plan to re-use... that's up to you.

The point is they are orthogonal issues. Creating re-usable chunks of CSS does not suddenly absolve you of the responsibility to make your HTML readable. You can do either one without the other, but you should be doing both.

I agree you can write your Sass like that and 'do both', and I'm all for writing good Sass and building up higher level abstractions for re-use where you can.

However, there's no denying the reusability of classes like 'col-xs-4', despite the knee jerk hatred of that 'non-semantic' class from some in this thread, and I maintain that if all you needed was a col-xs-4 and your team know what col-xs-4 is, then why not just stick it in your HTML.

It doesn't make it less 'readable' for your team, and they're the primary audience.

> You can do either one without the other, but you should be doing both.

I guess I'm disagreeing you should always be doing both. Do both (create a new semantic class-name) where it makes sense. But when you already have a reusable class that does the job, and all of your team will understand, just use it.

To change it, I'll have to go spelunking through either the HTML or the CSS, and if I was a designer, I'd probably pick the CSS. Looking for the 'product' class and tweaking a few properties sounds much nicer than figuring out how I need to change 'col-xs-4'. I'd rather have a conversation with the layout engine than struggle with some middle-man generic CSS framework like Bootstrap - it's simpler and more flexible (imo).

The lower-level abstraction (raw CSS) vs the higher level (bootstrap's grid) is more flexible. It's not simpler though, which is why the abstraction is worth learning. With a grid framework, you can make changes at a common level of abstraction that your teammates will understand. Because I guarantee the way you'd implement the equivalent behaviour in raw CSS is not how I would, and now we have both styles in the codebase (complexity).

Also yet to meet one of these 'designers' that would rather change CSS than HTML. And logically ... you can't understand CSS without understanding HTML, so preferring to make the change in CSS is just an arbitrary decision.

You could look at "basket", "product", and "searchResults", except that it tells me absolutely nothing as a dev about what it looks like. You shouldn't be using your CSS classes to tag sections, that's what id is for. And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.

> except that it tells me absolutely nothing as a dev about what it looks like.

That's because it shouldn't be.

> You shouldn't be using your CSS classes to tag sections, that's what id is for

No, you might can have multiple "products" on the page.

> And now, if I want to change the "basket" style, I'm praying that I didn't break something on the other side of the application. So in order to mitigate that issue, you end up nesting your CSS for safety and now you've re-created your HTML structure with CSS rules and it's incredibly inflexible to changes. I've found that semantic CSS classes are a pipe dream that never pans out.

Absolutely none of this true if you use Sass (or an equivalent) properly.

> That's because it shouldn't be.

Why not? Who's reading my HTML? It's not there to be read by a user. HTML is for devs. They're the ones that deal with it.

> No, you might can have multiple "products" on the page.

True, in that case you would use a CSS class with no styling if you need code to select the block.

> Absolutely none of this true if you use Sass (or an equivalent) properly.

It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).

> HTML is for devs. They're the ones that deal with it.

Correct. You make it readable the same reason you make any code readable.

> It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).

No. The whole point is if you use SASS properly you don't have to nest anything unless you want to.

> The whole point is if you use SASS properly you don't have to nest anything unless you want to.

I don't follow at all. One of the biggest selling points of Sass is being able to nest styles. If you don't need to nest styles, then Sass doesn't get you much. But once you start nesting, your CSS is coupled to your HTML. That's absurd.

it may be "a big selling point," but you're being sold a bill of goods.

using sass as you describe is an anti-pattern.

the important thing that sass allows you to do (which CSS should have built in, but doesn't) is to apply chunks of style to a named class. that is, precisely to decouple naming, styling, and html structure. you do this in sass with @extend or @include.

practically, this means i can take canned styles of my own making or from libraries like bootstrap, and then define my semantically named classes in terms of them. this allows composition at any level of granularity, total control over the units of re-use, and clear, readable markup.

I'm not convinced you can just call using a major feature of sass an "antipattern"... Without nesting, what you've described is essentially utility classes abstracted an extra level away under pretty names. Might as well get rid of that layer because it makes false promises. You'll end up reusing that CSS class and then find out that the usage in one area needs a slightly different markup. Cue nesting/extra CSS classes with slightly different names, etc.

There's this dream that you will need to "reskin" your application often, and be able to reuse a bunch of CSS classes all over your codebase. Instead what I've found is that it's better to think of your application as consisting of components with their own styling. Component-oriented frameworks like React are moving in this direction. Take a look at the styled-components library.

> HTML is for devs. They're the ones that deal with it.

As devs, we can view this html through a browser and use in-browser dev tools to view the associated CSS. There's no need to explain the style in the HTML.

You can still do that when you use utility classes. The benefit is that now you have a guarantee that you can drop a view anywhere in the application and have it render the same. I can restructure the HTML without worrying that I broke styling in an edge case.

> It doesn't matter what you use, you can nest your CSS by hand or with Sass. Either way, you now have CSS tightly coupled to your HTML structure and it can be hell to change. I'm literally dealing with this right now (we use sass).

There is no way for you to mess up something at the other end of your web app if you use specific sass files for specific web pages. The 'basket' class can be defined as one thing on the page for selling baskets, and it can be defined completely differently on some other page where baskets are, idk, displayed in some other way.

Single Page Applications. Reusable components. Both of these make CSS harder to manage, and semantic classes start becoming a problem.

Please elaborate. I don't see how having a library of SASS mixins that you mix in to make specific CSS classes for specific purposes make anything harder to manage? If anything, decomposing things to smallest common denominator makes it easier to build better and more versatile CSS for your apps.

It's not the sass mixins that makes things harder to manage. The problem is having nested CSS rules that cause your CSS to become tightly coupled to the structure of HTML. Then when the HTML changes, you have to rethink the relationships. And if you're not using nesting, then isn't what you described just utility classes abstracted one level away?

Reply on news.ycombinator.com