Hacker News Reader

Comment by aaronbrethorst | Hacker News Reader

I agree with a lot of this rant, but life is too short to care about `<section>`, `<header>`, and most other tags. If your content is highly legible to users—especially if they use assistive technologies—then it simply should not matter. The CSS Zen Garden is dead and it's time to till it and start over.

View on HN

Semantic content is also about being legible for computers though. Even though it looks good to users, some might also care about it being defined well for machines and automated processes.

FWIW, Google explicitly says it mostly ignores semantic HTML [0]:

> Having your headings in semantic order is fantastic for screen readers, but from Google Search perspective, it doesn't matter if you're using them out of order. The web in general is not valid HTML, so Google Search can rarely depend on semantic meanings hidden in the HTML specification.

And a typical business web page likely won't have many "automated processes" it wants to accommodate except for search engine crawlers.

[0] https://developers.google.com/search/docs/fundamentals/seo-s...

Completely wrong.

It says that the order of h* tags is not relevant. Which was also part of Html5 Outline spec.

H* tags are not the only semantic tags.

So it could also mean that they work with Html5 outline spec and value semantic tags, which allows them to ignore the order of h* tags.

So them saying that they ignore the order of h doesnt necessarily means that they ignore all semantic tags.

Well, I'm inclined to interpret "Google Search can rarely depend on semantic meanings hidden in the HTML specification" as meaning exactly what it says. After all, Google's own pages are made of <div>-soup, so I'd hardly imagine that they discriminate against it in others' pages.

Unless you have explicit statements or hard evidence to the contrary?

Regions are a part of the accessibility requirements, which are mandated by law. And the number of lawsuits is constantly rising. https://www.ada.gov/resources/web-guidance/#when-the-ada-req...

I think the idea is that the tags and the aria roles make it more legible to users using assistive technologies. For a significant number of aria roles, e.g. article, the recommended way to get that role is to use the corresponding HTML element. <section> is just a generic element but <header> has a banner role. Now admittedly there are a lot of HTML elements and a lot of aria roles, and I am not sure screen readers actually have different behavior for every role, but just by making a reasonable stab at it, you are doing better than many major corporations. (some of which have been sued over accessibility concerns)

I've heard of a philosophy that instead of a million unique tags that do mostly nothing, modern HTML should use only <div> and <span> instead.

Yep. <div>, <span>, and JavaScript. If you actually want a simpler web stack, that's the way to do it.

Unfortunately you can't draw a table of number using just divs. It's just too slow and your users will notice. For tables of data, you have to use tables.

I'm sure it's true for lots of other elements.

You can, you just have to set their "display" properties [0] to "table", "table-row", etc. The whole point of CSS is to divorce styling from the particular HTML tags.

[0] https://developer.mozilla.org/en-US/docs/Web/CSS/display

If you're going that minimalist, then why even have two tags (div, span) in your toolset when their only difference is display:block vs display:inline

Nope, that results in significant extra complexity because now you have to implement all the stuff that the browser does for the other tags so that your website works the way people expect. (and you will get it wrong)

IMO it's fair to say to colleagues that you're free to use any HTML tags as long as you take responsibility for them by knowing all of their idiosyncrasies.

Then it wouldn't be HTML.

It'd be a weird structural language you could really only express whether something is a block or inline.

Hard disagree on that personally. But I guess it depends what industry you’re in.

Life’s too short is a cop-out especially because it doesn’t take longer to use a semantic tag rather than a div.

With “life’s too short” you can justify pretty much everything.

Cost vs. benefit. If the ARIA roles are all in order (which can admittedly be a pretty big "if"), there's no user-facing benefit to semantic HTML over arbitrary HTML with the same style.

What cost? What’s the cost of typing a different tag?

The "cost" in many of these front-end frameworks is having to manage HTML tags at all, instead of generating them automatically from some higher-level specification.

Also, you have to remember whether any of them might have a different default style in the browser than what you'd get from a regular div/span.

Is that really a thing? I’m genuinely asking because I have zero experience with this type of setups since I don’t need to use them and prefer to work in other ways.

The idea behind frameworks like Flutter and React Native is that you can specify the document as a tree of high-level components, which can then be rendered either as a web page or as a mobile app. In that case, there's simply no equivalent to the semantic HTML tags on the other platforms, so you'd end up with a big impedance mismatch if you tried to force them in there. (Though of course, such tools are definitely targets of OP's derision.)

I see. Interesting. But what’s the benefit of using a tool like that if you’re only targeting the web as a platform?

None, unless you (or your team) is already familiar with it, I'd imagine. I think some (like Flutter) are designed to have similar markup regardless of which or how many platforms a particular project uses.

But don't take my word on any specific examples, I don't have any real experience outside of normal web React (which does give you full control over the HTML elements, except of course for third-party components).

Again, very interesting. Thank you for the insight. Appreciate it.

>I agree with a lot of this rant, but life is too short to care about `<section>`, `<header>`, or any other tag.

Yeah I gave up on that fight a long, long time ago. The semantic web was an admirable dream that never had a chance.

Yo, they don't even have a table of contents element. How can you say you love semantic documents and not have table of contents. And no bibliography either.

A TOC is a nested ordered list. You can make that today by nesting <ol>.

And then wrap that in a <nav> element.

No. That's just a nested ordered list. The difference that occurs when we all agree that it's also a ToC is night and day. You can also create custom elements, but again, if nobody has consensus on the meaning of those elements then they're just elements.

That means that as a client I am not empowered to automatically display your content in a new way.

What’s a TOC if not a list? At a document level, if you were to build a TOC in word for example, wouldn’t you use a list?

And why would you display a TOC differently as a client? A TOC is a list of items and should be displayed as that imo.

A ToC is more important than a list and should build a graph to other parts of your document. If the only agreement we have is that something is a list, then we've reduced the semantic meaning of a list to the question of whether we should have visual signifiers like bullet points or numbers.

I want the niceness of Wikipedia generalized elsewhere but abstracted by my client or browser. The more we agree on the precise meaning of elements, the more we are empowered to programatically redesign or interact with content.

Screen readers actually do generate a couple of different things that you could consider a ToC from the semantic meaning of various tags. If you structure your document properly, it's not a terribly difficult task for the browser to generate it. Apple showed that Safari 18's reader mode is going to have one, actually.

Semantic HTML elements and the semantic web are not the same thing. The semantic web was about linked data and RDF and suchlike.

Reply on news.ycombinator.com