Hacker News Reader

Comment by klum | Hacker News Reader

> God I miss it. I miss the goal of just cleanly naming things what they are, not how they look.

I think utility-first CSS has its benefits as well as it's drawbacks, but just regarding the statement above: wouldn't you say that when naming things for the purpose of targeting them with styling, what they look like is indeed what they are?

As in, referring to, for example, ".comment" and ".testimonial" in your CSS, when those classes have been added purely for the purpose of styling the elements as what is commonly called a media component, could be considered less semantic than just naming them according to how they look -- as that's the reason for naming them in this case?

(I think these are two different ways of looking at the issue, none of which is clearly the right or wrong one.)

View on HN

> wouldn't you say that when naming things for the purpose of targeting them with styling, what they look like is indeed what they are?

What do you mean? A "comment" is likely to stay a "comment" forever, whereas its bold'ness or italic'ness can/will likely change relatively often.

Well, yes. So, in the hypothetical situation where classes are added just for styling, is it a given that the correct way to name it is a way that stays the same when the styling changes?

And therein lies the problem. You don't add classes just for styling. This is terrible practice that I thought we'd stopped doing.

> in the hypothetical situation where classes are added just for styling

OK, a style-based class naming system

> is it a given that the correct way to name it is a way that stays the same when the styling changes

Not with a style-based naming system, in that case it's ok for the class name to change, and you can expect it to change often, which a lot of people argue is ok.

But like @welly said, herein lies the problem, or preference. The argument is exactly about whether you should name things in unchanging "decoupled" ways, or whether that doesn't work out in practice and it's simpler to just have utility styles.

I might be wrong, but I have the definite impression that semantic CSS was invented mainly by people working in publishing, so typical semantic class names map to content types you would create in a CMS. The developer mainly controls the CSS and users generate most of the HTML. Developers who work on app-like experience might be less interested in this style of semantic CSS because users are extremely constrained in how they can influence the layout anyway.

You're naming stuff as a comment or a testimonial or whatever else because that's what they are. The html defines what a component is and the css then describes what a comment or a testimonial looks like. You seem to have it the wrong way round.

It is certainly not semantic to name elements according to how they look. What if a div with classes that define the colour, the font size, the horizontal alignment etc. are later changed to be aligned right rather than left? Do you change your css class of "align-left" to a float: right? No. You don't. You name your component to describe its purpose and style the component as required.

I'd say the class name can be semantic whether it's semantic with regards to the components function, its form or something else. It's not self-evident to me that a name given to something in order to affect its form should be semantic with regards to its function, not its form.

As I understand utility-first CSS, changing the classes as in your example is very much what you might do. Why would this make sense? Because the situation where we want to "change how this component looks in the sidebar, but keep it the same as before in the footer", or "show this component slightly differently in a new context, without changing its appearance in its old contexts" is much more common than the situation where we want to change the look of a component everywhere it appears. In this case, utility-first CSS makes it very easy to make all these small, "one-off" changes.

> I think utility-first CSS has its benefits as well as it's drawbacks

What drawbacks?

You add a class called font-bold which adds a bold style to the element. Your client decides the element should be italic not bold. You then have to go back and change all your bold elements to use font-italic.

That's not a drawback at all. First, you would replace those font-bold with font-italic (assuming you name the utilities like that) and problem solved. You don't need to change .font-bold and add font-style: italic; in the font-bold class. That's they convinience of utilities: they aren't mutable.

What if you have 500 pages which need to have font-bold replacing with font-italic? Or more? 1000 pages?

Sure, you can probably write a script but if you name your elements semantically, you potentially only have to change it once.

Reply on news.ycombinator.com