Since I'm again mid-insomnia (hey, 30 hours and counting), been away from posting here for a week, being utterly unproductive in terms of writing code at this moment, and a friend suggested I explain this in further detail, let's just cover the WHY "made up tags" and classes/ID's are NEVER actually "semantic" and many of the implications and situations that arise as a result.

There are those who will claim that classes and ID's can serve a HTML semantic purpose. Typically these are the same people who say things like "Semantics is just for SEO", or "semantic markup is new and experimental" or other such nonsense.

Again, semantic markup is why HTML was created back in '89, 5 years before the first search engine that actually looked at the markup -- webcrawler -- even existed, and was reinforced as a concept and was pretty much the point of HTML 4 Strict back in '97. The "oh it's a new concept" folks make me laugh, particularly when they use HTML 5 or CSS 3 which are newer than semantics by decades.

Hence the people who say those types of things are either making it up, or making it up. Or they might be making it up. There's even the slight possibility, they're making it up.

The point of semantic markup is that all but a handful of tags have meanings. Those meanings exist so that a "user agent" -- software that turns HTML into something a user can digest -- can best convey those meanings within the limitations of the device or the user.

That's why B means "would be bold in a professionally written document such as for a legal entity" and not "show this text as bold". It's why I means "would be italic in a professionally written document such as a book title when not being CITEd" and not "show this text as italic". That the default appearance matches the intent is by design, but it's not what the tag means. Just as EM and STRONG mean "emphasis" and "more emphasis" respectively, a semantic meaning that is more appropriate than B and I in some cases, and utterly inappropriate in others.

This is why the jokers who keep saying B and I are "deprecated" and to only use EM and STRONG are equally clueless and basically lying either intentionally, parroting what they heard, or just plain ignorant on the topic.

Same reason that TABLE is for tabular data, and why the people who magically turned "don't use tables for layout" into "never use tables" are equally ill-informed.

Classes and ID's have no list of predefined meanings, so they have no semantics for any user-agent. Full stop, do not pass go, do not collect $100.

In case you missed it, a browser is a user-agent, but a UA isn't always a browser.

In that same way, "extensible" HTML tags where you use DTD's to add your own elements are equally non-semantic. The UA may receive instructions via other means to determine what to do with them, and figure out how to handle them in terms of default layout, but they lack actual definition in the official specification and as such are just as semantically meaningless as DIV and SPAN.

It is for that reason specifications like SGML and XML do not have semantics unless you use a defined subset of predefined tags. That's all HTML is, a set of predefined tags with meanings (semantics) in a SGML namespace. XHTML is just HTML reformulated to fit a valid XML namespace, with the option in XHTML 1.0 to be compatible with both XML and SGML simultaneously.

These concepts are poorly covered most places if touched upon at all. Worse, far, far too few people seem to be able to grasp it. There's just so much made up unfounded nonsense about what semantic markup is, what it is for, when it came into being, how useful it is, and how to go about using it. Hence why so many websites attempts at using HTML is semantic gibberish.

... and users with accessibility needs suffer as a result. Search rankings can suffer as a result (though really good content quality can overcome this). Site owners often suffer the result and don't even know it, wondering why they have so many problems, difficulties, and long term costs.

As I said before there are only a handful of tags in current specifications that have no semantic meaning. DIV, SPAN, COL, COLGROUP, STYLE, SCRIPT, MAP, AREA, PARAM, and Anchor.

DIV and SPAN exist for the application of style in a neutral manner that does not disturb the semantics. Without them much of what we do wouldn't be possible, but that does not mean you just dive for them every time you want to do something. Every effort should be made to expend what can be done with your semantic tags first, resorting only to adding those tags when you need to either to group multiple semantic tags as a section for unified style without slopping classes onto everything, or for an effect that cannot be achieved within the semantic scope.

The rest all exist to create behaviors, the third prong of the design and development trident: Semantics; Behavior; Style.

Anchors and AREA do not change the meaning of the text they wrap or imply any extra meaning atop it, it just makes that section a hyperlink. SCRIPT and STYLE do not contain any information that is relevant as content and should be ignored. This is why inside SCRIPT and STYLE tags any inlined code used to be hidden inside comments. The rarely used COL and COLGROUP exist to set table behavior guides for non-CSS browsers. They really should be stricken from HTML at this point. PARAM contains information for a OBJECT that isn't actually treated as content. So on and so forth.

HTML 5's NAV used to be semantically neutral, meaning "the user agent can skip this section to get to the content" but with more recent versions they revised that to behave more how people were incorrectly using it. The W3C is weird that way. These days rather than trying to create a guide to make websites better, they just document what people are doing, shrugging, and going "oh well" ... that's no way to build a specification. Now it means "This section contains links to parts of this page or other pages".

Though the original meaning lives on as a note... and I quote:

User agents (such as screen readers) that are targeted at users who can benefit from navigation information being omitted in the initial rendering, or who can benefit from navigation information being immediately available, can use this element as a way to determine what content on the page to initially skip or provide on request (or both).

I actually like this new wording as it is a marked improvement over previous iterations, but I'm still not sold on there being any real point to this or that this is the way to go about improving the usability/accessibility of site navigation.

Either way it's still a pointless redundancy. Really? Anchors are links to other places? Who knew?!?. Under the old definition it was redundant to either the MAIN tag, or the first H2 or HR on the page if not using HTML 5's silly SECTION tag... or the first H1 inside the first SECTION tag. phew, they've introduced too many different ways of doing what we've been able to do cleanly and simply since 1989.

Likewise one of its other notes gives a bit more of a purpose:

Not all groups of links on a page need to be in a NAV element — the element is primarily intended for sections that consist of major navigation blocks. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases; while a NAV element can be used in such cases, it is usually unnecessary.

Ends up reminiscent of what accesskey menus were supposed to be for, but since only one browser engine (presto, aka classic Opera) ever actually implemented them properly, and current browser makers seem to have no interest or motivation to implement said functionality, using it inside your "header" area is just as "unnecessary" as putting it inside your footer. Just like all the other HTML 5 tags that not one legitimate UA seems to treat as anything more than a glorified DIV.

... and even if what it claimed to do served any purpose and was actually implemented by browsers, the people blindly dumping Anchors into NAV without any other formatting or text are missing that whilst yes, it now says the section is navigation, it doesn't imply anything else such as structure. Hence the note in the specification -- and I quote:

In cases where the content of a NAV element represents a list of items, use list markup to aid understanding and navigation.

Hence why you don't just dump a bunch of anchors in there any-old-way... like most of Bootstrap's code examples do and why I say the people who created and maintain bootstrap don't know enough HTML to be telling others how to build websites. All you end up with then is a gibberish run-on sentence.

Not that I know anything about writing long convoluted run-on sentences, but at least mine make sense.

Bottom line, semantics is actually really easy, really powerful, and exists so that websites are useful to as many end users as possible. If you aren't using it, aren't leveraging it, and aren't taking it into consideration, you're pretty much doing it all wrong completely missing the point.

It's easy, people make it hard. Through misunderstandings, misinformation, and a lack of comprehension and focus. It's all part of how so many developers refuse to take HTML seriously, saying it's not a real programming language. Saying the semantics isn't that important...

... and that's what's truly infuriating about all the lame excuses and apologetics for things that ignore semantics and all the other aspects of competent development practices.

Not to dig into using the "repeat for emphasis" and "call-back" tropes, but...

As I keep saying such willful ignorance and outright refusal to even acknowledge the advantages is for all intents and purposes telling large groups of visitors to websites that "you don't matter to me!"

The people making up excuses for boostrap and other HTML/CSS frameworks? They're telling potential visitors to their sites that "You don't matter to me!"

Those coming up with reasons to justify CSR or other scripting-only functionality with no fallback options? They're telling potential visitors to their sites that "You don't matter to me!"

All the folks who claim there's nothing wrong with using WYSIWYGS or starting out with a PSD or other image as their starting point? They're telling potential visitors to their sites that "You don't matter to me!"

But I'm the one being insulting by challenging that. Yes a lot of what I just said isn't popular. Yes a lot of what I just said is upsetting to those who've never been exposed to these concepts and instead were packed full of sand by bad sources. Yes a lot of people just don't want to hear or accept any of this, rejecting the facts no matter how much you quote the specifications, cite examples, or show better ways of doing things.

That's the truth for you. People would rather accept the comfortable lie than an uncomfortable truth. Hence why I often compare those who reject these concepts to science deniers. There is that same level of deeply ingrained confirmation bias mated to a willful embracing of the comfortable lie. Even when the result of said lie can be painfully uncomfortable.