Hacker News Reader

Comment by IgorPartola | Hacker News Reader

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.

View on HN

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

tailwind is very much not a problem for accessibility? if your content is semantic and you add the appropriate aria tags, whether or not you have 300 classes or 1 will make no difference for screen readers

No, it really isn’t. Use of Tailwind has no bearing on the semantics of your HTML. You’re conflating two completely different things.

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

It already happened. WASM. And it's generally been used well.

There's an active proposal for rendering html in canvas to control styling. Text rendering and accessibility are main focuses for the proposal.

https://github.com/WICG/html-in-canvas

I thought it was being done for web apps like Google Docs now, and I thought one of Microsoft's cross-platform toolkits used <canvas> too (though I don't think this toolkit itself will see broad adoption).

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.

Well, it does help if you expect sight impaired people with software to find the site useful.

That's why I said setting the right attributes. You can make a fully featured accessible website using only divs.

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.

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?

As a user, I don't care.

As a disabled user with a screen reader, I might care.

As a developer tasked with maintaining it after the original dev left, I most certainly would care a great deal.

Except that as a developer you have access to the original source code where things are well structured. It only turns into div soup after the React/Vue code gets compiled down to HTML+CSS+JS that can run on any browser.

As a developer you maintain the source templates, not the compiled/generated HTML. The HTML is messy doesn't mean the source templates are so.

Semantic web is basically "please think of the crawlers."

Besides the points raised here, I think it's worth noting that using stuff like the article tag does not necessarily make things easier to maintain. You do indeed get a lower line count, but you're coupling the structure and meaning. Sometimes that's fine, but a11y can be tricky to get right and it's often easier to push it off until you've got something working first.

It's possible to know that HN is basically a big table, use the site just fine, and still recognise that there are disadvantages to that approach.

And it's nearly impossible to customize any part of the layout with user styles because of that.

Reply on news.ycombinator.com