Hacker News Reader

Comment by clan | Hacker News Reader

Is there no middle ground?

I love the clean approach with classless. Documents do have a structure and is makes it easy to change by just swapping out the CSS without touching the document.

But could you not just add the class only when you really really need to break the structure? The middle ground for me would to do my utmost to avoid classes within reason. So as few exceptions as possible. I know this is selling elastic bands by the meter.

On the other end you have Tailwind CSS. I know many are happy with it and find it has a nice developer velocity. But I find it overly verbose and "framework of the day"-ish.

So for me it is classless until my head hurts. Then I'll sprinkle in a class to get work done.

View on HN

It depends a lot on the rate of change of the document.

Documents that experience little change don't need classes because their structure is reliable.

Documents that change often have unreliable structures, and will require frequent updates to the CSS rules to match structure changes. Using classes insulates the CSS from the document structure, mitigating the need to update CSS as the document evolves.

It also depend your development strategy. If using Vue components and writing the CSS in the same file as a dedicated, small-scoped components, it's practical to update the CSS references alongside the document changes. But when there's distance between the HTML and the CSS, or there are components in use who's structures may change unpredictably (such as from 3rd party libraries), classes provide a safer reference.

There's no need to have an ideology of using classes or not using classes. The practical approach is to assess the nature of your work, the rate of change of the documents, and to adopt practices built around those assessments.

The vast majority of the time, if my document structure changes, I want the presentation to change too. It may depend some on how complex the document structure is... I usually advocate for simpler structures. I agree that one should assess and adopt practices applicable to what they are building.

My middle ground is semantic classes but also use the element names, as they are already semantic. I use IDs only for JavaScript. No hierarchical class names, no Tailwind, no code compressing, no Uglifiers. My code shall be a pleasure to read and modify.

My proposed viable middle ground approach would be to adopt markdown as an intermediate representation and use some build process to generate the final output. As long as the input is markdown, it doesn't matter if the final output from the build process maintains tight coupling between structure and styling. That said, if the primary benefit of the no-class approach was intended to facilitate development, this method—which introduces an additional build step—would be counterproductive.

Reply on news.ycombinator.com