I was recently doing some very specific web scraping of some very public very static documents. About 25% of them use a soup of divs with hashes for class names. Not a <main> or <article> or <section> in sight. I am fine with the idea of what tailwind does but like at least using semantic tags where appropriate could be a thing.
There's also the issue that whatwg pretty much stopped adding new semantic elements; if I'm not mistaken, only <search> and <dialog> were added in the last decade, after the introduction of HTML5. <main>, <section> and <article> are increasingly being overloaded to the point of meaninglessness.
The most cited example of one that's clearly missing is <comment> for user-added content, but there are probably dozens we could add that could help deal with the div soup. By not adding any new elements, whatwg is essentially saying "You're not going to be able to use these the existing tags to fully add proper semantics anyway, so why try?"
You can grumble at web developers in general for things like div soup, but the hostility towards tailwind is misplaced. Hashed classes aren’t even tailwind, and the tools that generate them are not the problem either.
That's totally orthogonal to Tailwind though; there's nothing that precludes you from combining semantic elements with it. The only thing that would make a dev reach for <div class="m-2"> instead of <article class="m-2"> is the dev's own (lack of) taste. It's no different than writing out separate CSS or using inline styles.
I do sympathise as someone who has to scrape content from time to time, but that doesn't sound like a problem for the author of the content or something that impacts their intended user.
I'm pretty sure unreadable class names are a byproduct, but perhaps some people may also consider it a feature, of their particular build process.
so they may very well have semantic tags in their development environment. Of course debugging things becomes more difficult for the developer as well unless there is some sort of lookup table to tell them that class .uv.le in the browser maps to .user.name in their codebase, in which case it only becomes marginally slower for some cases.
Tbh there's nothing really wrong with that. You don't need stuff like article or section if you set the right attributes. Often easier to just use divs to get the structure right, and figure out the meaning later.
And there's 'nothing wrong' with just writing code with variables named 'a1, a2, a3'. But when some poor sod has to dig through your mess to figure out what you had in mind it turns out that having an easier to discern logical structure to your code (or html) makes it better. I've dug through a lot of html. And there's a ton of ugly code smell out there. Layers and layers of "I don't really know what I'm doing but I guess it looks okay and I'll make it make sense later". I'm sure it pays the bills for someone. But it makes me sad.
I don't think "separation of concerns" is entirely dead. Ideally, the CSS is readable and maintainable, and that implies structure. If you have a bunch of (co-)related components, you don't want to find/replace tailwind class names when you need to change the layout. So you separate that part of the layout in classes based on (layout!) functionality. You can see that as "concerns."
Okay. I personally don’t care for anyone so chronically online that they think that their interactions with other similarly chronically online people is at all representative of the userbase of something as immensely widely used as Tailwind.
Whatever the professional equivalent of ‘touching grass’ is, I suggest you do that at your earliest convenience.
You can separate concerns without violating locality of behavior, and that’s exactly what tailwind does.
It admittedly does not do a good job at being very DRY but I think that’s poorly applied to HTML/CSS in general, and the most DRY css is often over abstracted to the point of becoming nigh uninterpretable.
When I write CSS, I most often do not want the locality of behavior. I instead want uniformity of behavior, hence "semantic" styles. Even the trivial light / dark mode switching is pain with Tailwind, when classes like "color-gray-200" are routinely applied.
I’d somewhat agree with you there, but I usually use variables for uniformity. I do see arguments against tailwind but find anytime I’ve tried to do anything else it just feels like bikeshedding on internals for the same end result.
Really what I want to see is beautiful TDD for CSS so that uniformity can be enforced, but I’m not sure that exists.
I can't believe this isnt better understood. Style definitions on reusable components are good. The idea that your css doesn't have to know about your html just creates tons of problems and complexity. Global themes and reusable styled are fine.
If we are talking about statically defined html then sure. make your global css files.
SoC is how all maintainable software is built. A function for A, a class for B, DDD-spec'd modules and features, databases on separate machines, API definitions, queuing systems, event systems, load balancing, web servers.
You don't even need to think of the web to see how content and presentation are different. Try editing a text file with hard line breaks in and you'll quickly understand how presentation and content are orthogonal.
Please don’t be so condescending. We all know what separation of concerns is.
The comment said “web development”, and it’s inarguably that in the history of web development there have been at least a couple of major misapplications of separation of concerns, which have had practically everlasting negative consequences.
Read what you’re replying to before you reply to it.
I was recently doing some very specific web scraping of some very public very static documents. About 25% of them use a soup of divs with hashes for class names. Not a <main> or <article> or <section> in sight. I am fine with the idea of what tailwind does but like at least using semantic tags where appropriate could be a thing.
There's also the issue that whatwg pretty much stopped adding new semantic elements; if I'm not mistaken, only <search> and <dialog> were added in the last decade, after the introduction of HTML5. <main>, <section> and <article> are increasingly being overloaded to the point of meaninglessness.
The most cited example of one that's clearly missing is <comment> for user-added content, but there are probably dozens we could add that could help deal with the div soup. By not adding any new elements, whatwg is essentially saying "You're not going to be able to use these the existing tags to fully add proper semantics anyway, so why try?"
You can grumble at web developers in general for things like div soup, but the hostility towards tailwind is misplaced. Hashed classes aren’t even tailwind, and the tools that generate them are not the problem either.
That's totally orthogonal to Tailwind though; there's nothing that precludes you from combining semantic elements with it. The only thing that would make a dev reach for <div class="m-2"> instead of <article class="m-2"> is the dev's own (lack of) taste. It's no different than writing out separate CSS or using inline styles.
I do sympathise as someone who has to scrape content from time to time, but that doesn't sound like a problem for the author of the content or something that impacts their intended user.
that's a problem for accessibility too
2 replies →
I'll add that writing userscripts became more challenging b/c of this phenomenon.
I'm pretty sure unreadable class names are a byproduct, but perhaps some people may also consider it a feature, of their particular build process.
so they may very well have semantic tags in their development environment. Of course debugging things becomes more difficult for the developer as well unless there is some sort of lookup table to tell them that class .uv.le in the browser maps to .user.name in their codebase, in which case it only becomes marginally slower for some cases.
Not defending it, but this is most likely a cause of using some enterprise CMS like Adobe AEM which is notorious for doing stuff like this.
Its not right, but a lot of times CMS's are horrifically bad at adding content without a slew of nested, auto-generated <div>'s.
Wait until sites start rendering to canvas. You will yearn for the days of div soup.
why should they? this has been a worry for some time, but I don't see it happening
3 replies →
Tbh there's nothing really wrong with that. You don't need stuff like article or section if you set the right attributes. Often easier to just use divs to get the structure right, and figure out the meaning later.
And there's 'nothing wrong' with just writing code with variables named 'a1, a2, a3'. But when some poor sod has to dig through your mess to figure out what you had in mind it turns out that having an easier to discern logical structure to your code (or html) makes it better. I've dug through a lot of html. And there's a ton of ugly code smell out there. Layers and layers of "I don't really know what I'm doing but I guess it looks okay and I'll make it make sense later". I'm sure it pays the bills for someone. But it makes me sad.
Well, it does help if you expect sight impaired people with software to find the site useful.
1 reply →
Exactly this.
I wonder if the people downvoted you realize that HN is basically just a big table and a bunch of div, and they use this very site just fine?
6 replies →
It's a choice. The dominant paradigms choose not to.
I disagree. And that makes me the loser here
I agree, it’s a choice. So is the opposite. Complaining about other people’s choice of doing things on the web is the choice I’m actually tired of.
Read something else then.
2 replies →
Another loser here to second you
I wrote these libraries like
https://github.com/kristopolous/db.js and https://github.com/kristopolous/evda in the early 2010s. I spent months on them
I was all in. I swore off touching front end in 2022. It's terrible now
1 reply →
I don't think "separation of concerns" is entirely dead. Ideally, the CSS is readable and maintainable, and that implies structure. If you have a bunch of (co-)related components, you don't want to find/replace tailwind class names when you need to change the layout. So you separate that part of the layout in classes based on (layout!) functionality. You can see that as "concerns."
Components are the tool you’re looking for. For the rest there’s CSS variables. Soon we may have @mixin.
I don't use Tailwind, it's a solution to a problem I don't have.
I can understand how it might be useful for certain types of web development, e.g. landing pages where the content and styles are tightly coupled.
So as a technology, it's OK. But my god its userbase is toxic and obnoxious.
Okay. I personally don’t care for anyone so chronically online that they think that their interactions with other similarly chronically online people is at all representative of the userbase of something as immensely widely used as Tailwind.
Whatever the professional equivalent of ‘touching grass’ is, I suggest you do that at your earliest convenience.
What an absurdly absolutist statement.
The majority of its userbase is no longer made of humans though.
You can separate concerns without violating locality of behavior, and that’s exactly what tailwind does.
It admittedly does not do a good job at being very DRY but I think that’s poorly applied to HTML/CSS in general, and the most DRY css is often over abstracted to the point of becoming nigh uninterpretable.
When I write CSS, I most often do not want the locality of behavior. I instead want uniformity of behavior, hence "semantic" styles. Even the trivial light / dark mode switching is pain with Tailwind, when classes like "color-gray-200" are routinely applied.
I’d somewhat agree with you there, but I usually use variables for uniformity. I do see arguments against tailwind but find anytime I’ve tried to do anything else it just feels like bikeshedding on internals for the same end result.
Really what I want to see is beautiful TDD for CSS so that uniformity can be enforced, but I’m not sure that exists.
2 replies →
I can't believe this isnt better understood. Style definitions on reusable components are good. The idea that your css doesn't have to know about your html just creates tons of problems and complexity. Global themes and reusable styled are fine.
If we are talking about statically defined html then sure. make your global css files.
SoC is how all maintainable software is built. A function for A, a class for B, DDD-spec'd modules and features, databases on separate machines, API definitions, queuing systems, event systems, load balancing, web servers.
You don't even need to think of the web to see how content and presentation are different. Try editing a text file with hard line breaks in and you'll quickly understand how presentation and content are orthogonal.
Please don’t be so condescending. We all know what separation of concerns is.
The comment said “web development”, and it’s inarguably that in the history of web development there have been at least a couple of major misapplications of separation of concerns, which have had practically everlasting negative consequences.
Read what you’re replying to before you reply to it.