HTML5 introduced a bunch of "semantic" HTML tags to markup content. To this day I still haven't figured out what are the practical implications of using them at all, so I've come here ask.
What I know: screen readers may announce/make use of main/article/section/aside/nav/search/del/ins because they have default ARIA settings.
What I want to know: who ELSE consumes these tags and for what, and who is consuming:
1. and
2.
3. and
4. and
5. and
6.
7.
8. and the cite attribute of
9.
10.
Because if nobody is consuming these, it's hard to see a point in bothering with all these tags at all. I know for a fact Wordpress and many other CMS's just wrap every image in a which goes against the spec, so I assume whoever tried to consume that to make figures go into a sidebar or something probably just gave up because the markup of most the web is wrong, but what about the rest? Because, I don't know if you've seen this, but the spec[1] says you should mark up a menu with this atrocity:
File|Eat Apple...
And I have no idea why would anyone bother with such complicated markup instead of just using , because... if nobody would write code like this, why would anyone write a program to read code like this that nobody is writing?
I think I've read that should work like an ATOM feed, but is anyone parsing as if they were feed items? I mean, as a general-purpose solution. If it's done for a single site that's not really markup-level semantics, that's like site-level semantics, you could have just used a selector based on the class that site used for its articles, for example. Is that all this is? A shorthand for class="..."?
HTML is one of those things that sounds easy to write, except almost nobody knows how to do it or why they should. At best people are super ecstatic when they can figure out how to make it visually pleasing.
The point of semantic HTML is that it benefits everybody equally by providing well described content for all readers. This is the purpose of accessibility. For visual readers this means the browser provides some default presentation that enhances the quality of output with minimal effort to the developer. For users reliant upon screen readers it means the content is communicated with greater precision and clarity. For bots it means stronger acceptance of your content versus other competing sites.
Honestly, HTML is past its prime. Most developers cannot be bothered to figure this stuff out, and cannot be figured how to use the browser's compile target (the DOM), and so much more. Instead most developers are entirely reliant on enormous frameworks and HTTP to do absolutely everything for them. Its like reading a menu is too challenging so instead buying the restaurant and kitchen staff. Its exchanging one set of problems for another at 10x the expense and then crying when people point this out. None of this is challenging, but... the world is filled with non-challenges that people would rather go to war to avoid.
👤 unconed
Yes, if you read how certain tags are actually intended/supposed to be used, you realize that semantic HTML is mostly nonsense. You can't extract a list of articles from a page by looking for `` tags, because there are all sorts of other 'acceptable' uses, none of which any web developer in the wild actually knows, let alone applies rigorously.
It's just a bunch of rules that some ivory tower people made up, which have little to no correspondence to the much more useful questions of:
- what kind of information do people wish to extract from an HTML document?
- what kind of information does accessibility software need to extract from an HTML document?
- what does the typical structure of a web page in the wild look like?
- what kind of information cannot be inferred from natural context and requires annotations?
W3 standards are, on the whole, pretty much garbage. The parts that aren't garbage are the parts that were standardized in the wild, from things people were already doing spontaneously.
Also, the entire 'semantic html' movement was mostly a fad where people who never used a screenreader gushed about how much more accessible their HTML was because it used the morally pure, new, progressive HTML tags. It was masturbation.
Everyone acted like people actually care about the HTML for the webpages they visit, but the reality is, they don't. Not even web developers. Unless they are explicitly paid to satisfy some government accessibility guidelines.
👤 1attice
Blind people depend on them. They tend to be used more (by web devs) than ARIA properties, IIRC, so I'm told it helps a lot.
👤 marbu
> 1. and
Pandoc will generate html code using these elements when you use implicit_figures feature:
You can see an example how it looks like in this post from my blog, there are no css tweaks for figure or it's caption (I use static site generator based on pandoc):
And personally I find that better compared to alternative solution consisting of multiple div elements.
👤 bjourne
All of this is part of the semantic web quagmire. To make web pages machine readable. I.e parseable in an unambiguous way. It never caught on because it is trivial to parse web pages anyway and if you wanted something machine readable, you'd publish your data in json or something. But it's proponents haven't given up yet and are still working on making the web truly semantic.
👤 redavni
Great question. When the "Semantic Web" hype train rolled through back in the day, I asked the same question. I got a lot of hand-wavey answers about search engine understanding semantics of markup. Also if you use instead of you are a barbarian.
In theory, more information would be easier for a language model to extract meaning from though.
👤 TomaszZielinski
CSS frameworks like Bootstrap provide nice default styles for many of those semantic tags, that convey their meaning.
And then using them becomes almost habitual.
Personally I like to use "semantically correct" tags, as that somehow feels right. But then with a CSS framework it's easier than using a "wrong" tag, which you would have to manually restyle.
👤 perilunar
> it's hard to see a point in bothering with all these tags at all
What? It's easier than using custom markup that you then need to style appropriately. Why would you not use them? Why would you use instead of ?
> the spec[1] says you should mark up a menu with this atrocity...
No it doesn't. That's a specific example of indicating keys to press in a menu. Menus generally are marked up as lists inside a nav element.