Hacker News Reader

Comment by donatj | Hacker News Reader

They makes a very poor case IMHO, and come off as just preaching to the choir.

> Make no mistake: just because style composition is performed in the HTML document doesn’t mean it’s done in HTML.

That is 100% what that means. Sure, you could make .font-italic do anything, yet if it turns everything bold or anything other than italic it’s a horrible sin.

Make no mistake, you are editing your HTML to adjust styling. It’s “done in html”.

Truly semantic CSS has been dead for around a decade, killed by the likes of Bootstrap. God I miss it. I miss the goal of just cleanly naming things what they are, not how they look. Taking pride in the quality of the HTML, versus today’s rush to get an MVP out the door as quick as possible.

View on HN

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

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.

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

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

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 100% agree with your opinion on “utility-first CSS”.

I wouldn’t declare CSS dead though. Some folks, like myself, continue to do things the right (IMHO) way. I sometimes even consider creating a new site like CSS Zen Garden (haven’t bothered to check whether such already exists)... imagine the creations people could make nowadays.

I also use Bootstrap, and I love it, but I don’t use it to design my apps / websites; I use it for its utilities (responsive utilities, form styles, etc.). I realize there are smaller frameworks for this purpose, and I sometimes use them also. I still design most of the internal layout from scratch (e.g., I don’t use “cards” and other shortcuts to bypass meaningful design, etc.).

Maybe I just have an unusual learning style, or haven't gotten the right resources, but I've found traditional, semantic CSS to have a brutal learning curve. When you're trying to build complex apps, you're constantly rearranging your taxonomy of classes to break down the page into an appropriate logical hierarchy. I appreciate that in principle this is a good thing to do, and once you get good at it there is less rewriting, but when you're trying to learn all of the other aspects of this craft at the same time, it can be a draining experience.

And I mean this on the scale of years, not just the 6-12 month "just getting the basics" stage of learning to be a dev.

If we still had the position of "front end developer" in the old sense of writing HTML, CSS, and maybe some light JS, that's someone who could dedicate their resources to mastering semantic CSS. Sometimes I wish there was still a job like that, but for whatever historical reasons, at most companies what we have is a combined role called "front end developer" that involves fairly heavy duty development with client side frameworks like React, but also all of the HTML and CSS stuff. And asking these folks to get good at the semantic side of CSS at the same time as learning all the rest, is asking a lot. Maybe worth it, but it's no joke.

I should have mentioned that I don’t apply the semantic concepts completely and dogmatically. They just act as a guiding philosophy.

I definitely have to agree that the complexity of “front end development”, as a role, has increased drastically, meaning there is much less time to dedicate to learning and applying these types of traditionalist techniques, compared to pragmatically and quickly implementing things with heavy framework usage.

I also think there is a bit of a vicious circle with that mindset. When people use frameworks they tend to build more complicated things than they might without those frameworks, which makes plain ol’ CSS/ JS look like an untenable solution. When I think of building an app with plain CSS and JS with only jQuery, I think of it as a helpful constraint that will lead to simpler code and simpler functionality, not to mention what could be megabytes less of tools and frameworks that users will need to load.

Exactly. The other thing is that the tools you use define how you think. Nobody is using HTML properly, it is as if the only elements are div and span. Why can't we have people using the full vocabulary?

If you only think in terms of div and span with a gigantic mess of CSS making it look like a web page then you are never going to write good content.

Content means articles with sections with asides, headers, details and summaries and regular HTML goodness such as lists. If you can write your content in a sensibly structured way then you can style the elements consistently with a minimal amount of classes.

Also to add to the mix is CSS variables. People that aren't using them in their CSS for making pages responsive are just not using CSS sensibly and are doomed to use a hacky scheme to manage untold bloat-CSS.

Reply on news.ycombinator.com