I think that the point that a lot of people miss with HTML5 is that part of the thinking is to make content on the web understandable to machines.
That's part of what semantics has been from day one. Instructions for machines to deliver content to users, conveying the meaning of what things are -- or would be -- in a properly written document.
but now an estimated 40% of web interaction is bots talking to bots
Which is more problem than usefulness -- and remember what Matt Cutts told us about that.
Write for the user, not the search engine. This also could be expanded to "write for the user, not the machine". These new "structural" tags do nothing of the sort. Quite the opposite. they seem to exist just for the people who used to write "DIV for nothing" or simply can't be bothered to use H1..H6 and HR properly.
. Between the crawlers and indexers, the screen readers and the who knows what else that's alot of traffic that's looking at that <span>holding the caption underneath the <div> holding the graph and saying to itself... well, here are two pieces of... content...
Being semantically neutral, you shouldn't be using either SPAN or DIV if you care about meaning, they are hooks for style without saying WHAT that style is. Hence, meaning should be conveyed by the tags with semantic meaning INSIDE them. This plays particularly to things like screen readers and search engines, who shouldn't give a flying purple fish what your DIV or SPAN are there for... or even your anchors if we're talking semantics since <a> doesn't change the meaning of the text inside it.
Hence part of the progressive enhancement approach being writing your semantic markup
BEFORE you start slopping in DIV / SPAN or throwing CSS at it... that's the second step after writing your content in a logical order as if HTML and CSS don't even exist.
- 1) Content of value in a logical order as if HTML and CSS don't exist
- 2) Apply semantic markup, this does not mean neutral containers like DIV and SPAN
- Apply CSS adding DIV and SPAN only as and where needed to create the semi-fluid elastic desktop layout.
- narrow the window until the layout doesn't fit, re-adust with media query at the offending width... in EM so it's elastic
- Repeat step 4 until around 16em (aka 256px if you're a normal font user, 320px for someone like me)
- Enhance the already working page with JS if and only as needed.
Is everybody using the new tags correctly? Hell, no. But you could say that about any of the specs since 1.0
Which is the fault of poorly written specifications, specifications written for UA writers and not website writers, false assumptions on what tags are for (and it's NOT appearance), and the fallout from the browser wars, and the plathora of bad references and outright dirtbags like W3Schools.
MDN has quite good documentation on them
MDN is quite good, but that doesn't fix deep rooted issues over nobody -- even MDN -- REALLY knowing what any of the tags are for because the "specification" itself is NOT a flipping specification. By ANY stretch of the imagination. We're all left to just blindly guess, and that's a big part of the problem I'd like to address.
Particularly with asshattery like ASIDE where the tag is either as presentational as CENTER, or so uselessly narrow in definition it makes ADDRESS look good.
Change is hard sometimes. One piece of solace for you people I guess is that all those old tags still work and do a perfectly fine job at displaying content to humans and if that's all you care about nobody's forcing you to use the new ones.
They're also fine and dandy for machines, possibly better because they relate to the document structure in a way that header/footer/nav/aside, etc, etc are utterly and pointlessly redundant to.
... and I'm not saying all of HTML 5 is bad. The new INPUT types and attributes, many of the new attributes like HIDDEN, manifests, reduced header footprint, etc, etc, are all steps forward.
It's just annoying to see a dozen or so tags that offer zero improvement and just making the specification bigger instead of clearer. Especially since the "endless tables for nothing" that turned into "endless DIV for nothing" today exists as "endless allegedly structural tags for nothing" in terms of people slopping extra containers in where they aren't needed.
Again, just go to bootcrap's website, view source any of their examples, and recoil in horror at the 3i. What's the 3i? Ignorance, incompetence, and ineptitude. If such train wreck laundry lists of how NOT to write HTML are the norm, the vague to dismissive attitude of the W3C towards the people using their alleged "specifications" to build websites are directly at fault.
... or look at the default templates for most CMS and forums.
Hence why my bucket list of tags that need to go is:
CANVAS -- this is a behavior that 1) should be able to be attached to any element by applying the context, and 2) has nothing to do with document structure or the user. This is scripting-only behavior and as such has no reason to be in the markup. You want something in there to tell the user there might be something else going on, that's NOSCRIPT's flipping job.
I like what CANVAS does, but there is NO reason for it to be a tag.
AUDIO, VIDEO, EMBED, SOURCE, IMG -- all redundant to OBJECT and PARAM. There's not a single blasted thing being done there to warrant needing a separate tag for those elements.
Though OBJECT needs to be pared down, with that classid trash kicked to the curb.
ARTICLE, ASIDE, HEADER, FOOTER, MAIN, NAV, SECTION -- all redundant to H1..H6, HR, and in NAV's case every damned anchor is navigation and/or the skipping behavior is the first H2 or HR's flipping job... just as MAIN is redundant to same.
The only two I might consider retaining is FOOTER and MAIN... just so there's an opposite to the headings, and as sometimes your main content can't always be that first H2 -- though flex's ORDER often fixes that rather handily... as such I remain a "hard sell" on those.
STYLE -- there is ZERO reason to include static style in the markup. The only reason I might retain it is for those rare cases where you have some sort of scripting that needs style before ONLOAD fires. Other than that said tag really has little business on a website as it results in missed caching opportunities. This is where I think "PageSpeed Insights" has really become full of manure telling people to use said tag, slowing down their pages and wasting bandwidth all for some sort of MYTH about it rendering faster.
Much like the garbage we heard about tables rendering "slower" or being "problematic" where if a 40mhz 386 running windows 3.1 and IE 4 could handle a table, saying it has speed issues in the age where even my blasted cheap $100 BluBoo phone has 20 times the speed is a serious whiskey tango foxtrot.
Though in both STYLE and CANVAS' case the expedient answer would be to retain them, but make them "scripting only" elements. They should only be added to the document by JavaScript and never exist static in the markup itself. Kind of like classes on BODY.
TARGET -- this attribute is accessibility and usability trash. With framesets being dead for the same reason, you shouldn't be running around shoving new tabs/windows down the users gullet. It's a pain in the ass on mobile, interfering with conventional navigation for everyone, and if the user wants a new tab they can ctrl+click or middle click. It needs to go JUST like how it was gone in 4 Strict.
... and that's really a good part of the problem. This isn't about being "old" or not liking what's new, most of this junk reeks badly of having been made by people refusing to let go of HTML 3.2, which is why so much of it feels more like the worst of the browser-wars era specifications than steps forward. I've had more than a few people say "You're acting like it's 2003" -- well that's better than acting like it's 1996!
Again, there's a reason that the folks who seem to love HTML 5 the most are the ones who still seem to just write HTML 3.2, spent 1998 to 2010 slopping it out under 4 Tranny -- literally meaning "in transition from 1997 to 1998 practices" -- and today just slop HTML 5's lip-service doctype atop the same bloated, outdated and outmoded practices.
Just look at bootcrap... or the default turdpress template... or 99% of all third party turdpress templates... Or the default forum skin for most every forum system.
Including SMF's mess I'm fighting with at the moment.
But in general the removal of all the cruft above to drag things back to what 4 Strict was trying to give us will make all our lives easier. And that includes accessibility UA's like screen readers / braille readers, or even search engines. In general 90%+ of the problems that crop up in HTML would disappear if people would stop slopping endless pointless presentational classes at anything, understood the most basic of the semantic concepts that used to be 4th and 5th grade English class, and weren't wasting 50k of markup for every 8k's JOB.
Now, not all my ideas are about ripping things out. I do think there are some things that should have been there from day one, or at least added to keep parser version support under control.
Take how verison="" was removed from SCRIPT, or how the WhatWG wants to go full Gungan removing version information from HTML with their living document BS.
I'm thinking a "polyfill" attribute for SCRIPT and LINK, that says what version of the spec the polyfill is there to drag the page up to.
<script src="fixECMA17.js" polyfill="ECMA 2017"></script>
<script src="fixHTML.5.2.js" polyfill="HTML 5.2"></script>
If the browser supports ECMAScript 2017, don't load the first script. If it supports HTML 5.2, don't load the second script.
<link
rel="stylesheet"
href="noGridLayout.css"
polyfill="CSS 3 Grid Layout Module"
media="screen,projection,tv"
>
But of course that requires the specification to have actual version tracking and a consistent numbering and naming system... something you're unlikely to get with that half-tweeted "living document" chazerei.
I want to see improvements, I want to see changes, and much of HTML 5 is a colossal step BACKWARDS in this regard reeking of having been made by people who never embraced the improvements HTML 4 Strict brought to the table. No, instead they went "That 4 tranny looks really appealing".