HTML 5 and the W3C, Going to Hell in a Handbasket
Ever since HTML 5 was introduced I’ve bemoaned how it undoes so much of the intent and good practices of HTML 4 Strict.
New redundant tags like <section>, <header>, <video>, and <audio>. Elements like <embed> that should NEVER have been allowed into HTML in the first place. Etc, Etc.
They even introduced — then quickly deprecated — the <hgroup> tag proving the WHATWG didn’t know enough HTML to be making the new specification!
Don’t get me wrong there are a number of improvements, or things I can live with even if I don’t 100% approve…
But over the past ten years it feels like every blasted month I find one more thing that makes me want to tell the W3C to suck it.
A situation only further exacerbated by the lack of versioning in the markup.
Problem #1, Nothing To Track Versions?
There is no way to tell which version of HTML 5 is in use in a document. They treat it all — every revision past and present — as one giant “living document”. This means that what was completely valid HTML 5 eight years ago can fail validation today. What passed HTML 5 validation months ago can fail validation today. What passed HTML 5 validation YESTERDAY can fail validation today.
But worse, what’s completely valid HTML 5 today can and probably will be in all likelihood invalid tomorrow! Which is why this “living document” BS just adds to why HTML 5 is NOT a specification.
I have a background that includes some engineering, and to even call this a “specification” without specifying versions in the result as a reference? That’s NOT something specifications should do.
Problem #2, Documentative, not Authoritative
Playing again to engineering, a specification should tell you what to do, and what not to do. It’s ok to document what has been done in the past, but that’s not what a specification is for!
And yet, HTML 5 started life as “documentation” and many people claim that’s why it’s ok for tags like <embed> to have been magically accepted into it, even though it’s redundant to <object> and is for doing things (like including Java) that we have ZERO blasted business doing any time after 2010.
Even at the start when the WhatWG started making HTML 5 without the W3C’s approval (the W3C had their own now abandoned project) the folks working on it admitted they were just documenting what people were doing, and making tags to match that, instead of creating an ACTUAL specification that tells people what to — and what not to — do.
And on those grounds, that’s a strike against HTML 5 being a specification either.
Problem #3, Except When It Is Authoritative
… on all the wrong things!
The one place HTML 5 can be authoritative is when it comes to “validation”. But so many of the “minor” changes of what’s “invalid” are pointless, pedantic, and break backwards compatibity not because it’s an “improvement’, but because some know-nothing who didn’t understand why something is/was decided it was “bad”. Given all the outdated, outmoded, half-assed garbage they allow to validation, it’s shocking how many good practices, or acceptable features, or even just reasons certain tags and attributes exists are told to go suck an egg… because. Because they said so without legitimate reason.
Example #1, <tbody> and <tfoot>
An easy example of this is the order of <tfoot> and <tbody>. Traditionally in every version of HTML in the past <tfoot> goes FIRST so that user-agents like printers, teletypes, and so forth can extract it for page building — appending it to the top of EVERY page, not just at the start of the <table> — ahead of time to speed up render.
Now that’s confusing to some people, so I can see allowing it when the table is mostly for screen media. I’m ok with that… but disallowing the old structure altogether? Why? You WANT to make it harder to work with print media?
As such, what was a well formed table is now malformed JUST because “wah wah, yew put teh TFOOT first which was first for a REASON but now we hatesies eets!?!” Yeah, screw that.
Example #2, “projection” and “tv” Media Targets
Some of you — even those versed in HTML — are probably going “what’s a media target?”. It’s what your media=”” attribute on a <link rel=”stylesheet”> or <style> tag is for. It says what device types the included stylesheet is for.
Whenever you see a stylesheet that lacks media=””, or is set to media=”all”, what you are looking at is developer ignorance, incompetence, and ineptitude. I’m so sure your screen layout makes perfect sense for print, tty, speech/aural/etc.
Under 4 Strict, there was no predefined list of “use these and nothing else” because the whole idea of media=”” was for user-agent makers to be able to define ones for any past, present, or future devices. Being able to add your own for your own UA’s is part and parcel of why it exists. Whilst sure there are many standard ones, “print”, “speech”, etc, there are non-standard ones as well that should be considered valid, because what media targets are valid should be NONE of the specification’s flipping business.
They want to recommend some, that’s fine.
Thing is, “projection” and “tv” were valid types, and are used by many kiosks, set-top devices, consoles, and so forth. It is used on those UA’s so that if missing, they try to apply their own rules atop your style, much akin to the crap we disable with <meta name=”viewport”>.
And now they’re invalid. First they spent a few years throwing warnings, now it’s an outright error.
Given I still have to support some sites and HTML stacks on decade old or older thin-clients whilst still doing modern stuff, this too is unacceptable bull.
And again, these values shouldn’t even be any of the specification’s business because it defeats a good chunk of why the attribute even exists!
Example #3, <meta name=”x-ua-compatible”>
aka “Microsoft Proprietary Bullcookies”
Once again, the WhatWG / W3C have failed to grasp the reasons tags were even created in the first place, and in the process pissed on any chance at future proofing. Truly disturbing when they’re the ones tasked with and taking authority for this stuff.
<meta> exist as a means for developers and UA makers to add THEIR OWN name/value pairs to a document. Doesn’t matter if that user-agent is a specific browser, a search engine, a data scraper, etc, etc. The whole point of the tag is so that anyone can make their own non-content data for other purposes.
Whilst it’s fine and dandy for them to make recommendations, they’ve gone and — in their allegedly documentative alleged “specification” — explicitly said that the “only valid x-ua-compatible value is IE=edge”.
Well herpafreakingderp there numbnuts.
Setting IE=edge is pointless nonsense anyways; the ONLY reason you should set that value is if your site is on the compatibility blacklist where it’s forcing an earlier renderer. If that’s the case you’ve got bigger problems. It’s scary how many codebases blindly include it even though no modern website should need it.
All “IE=edge” does is tell Internet Explorer to use the most recent rendering standard it supports. Aka what should be the default behavior anyways! Despite wild nonsensical claims, it doesn’t magically make old versions of IE behave like newer ones. That some people even say that shows how little they understand how any of this stuff works!
Setting it to older UA’s is useful in a myriad of ways. One of the best being:
<meta
http-equiv="X-UA-Compatible"
content="IE=9"
>
<!--[if !IE]>-->
<link
rel="stylesheet"
href="templates/default/screen.css"
media="screen,projection,tv"
>
<!--<![endif]-->What does that do? Setting the X-UA to IE=9 re-enables conditional comments in IE 10 and 11, where normally they don’t work. With them back on we can choose not to send a “incompatible with IE” modern CSS to the browser. This way the page can fall-back on the default HTML behaviors, or we can use an “[if IE]” to send them a reduced but still attractive stylesheet.
It’s a very simple way to deal with graceful degradation for IE if you’ve bothered making the page fully functional if CSS or JS are missing. For those who don’t get it, that’s something you SHOULD be trying to do on websites before you even THINK about applying style or client-side scripting!
And now that too is “invalid” according to HTML 5 validation. A valid value according to Microsoft who created the bloody thing, a browser vendor proprietary META, a tag who’s values are supposed to be open for UA and site makers to use however they like… Is invalid.
You want proof the current W3C doesn’t even understand their own bloody specifications, there you go! They can take that bit of wankery and shove it.
Example #4, <SECTION> Needs a Numbered Heading?
The entire point of <section> being a different tag from <div> is to mark a .. well, section. But the entire point of a numbered heading is to mark the start of a section…. thus a section is everything between numbered headings of the same depth.
This is why I’ve said from day one that SECTION is redundant to H2..H6.
Now they have the validation throwing a warning when your SECTION lack a numbered heading, at which point WHY DOES THIS TAG EVEN EXIST!?!
This too seems to be a “recent” HTML change that wasn’t just done for no good reason, it seems to defeat why the (pointlessly redundant) tag was even added in the first place. If <section> isn’t a replacement for using numbered headings, what the blazes is it for then that DIV doesn’t do?
So Basically….
What they’re telling us is that it’s documentative of what you can do in a browser, but don’t you DARE do these completely valid things that browsers support. Schizophrenic much?
Problem #4, It’s Not For “Us”
The HTML specification is not written for people who write HTML.
Let that idea sink in for a moment. That’s not a joke, or an exaggeration. The W3C even admits it, saying if as a developer you want to learn or understand HTML, you should go to MDN.
This is because the HTML specification is written for the creators of user-agents, such as browser makers. As such, the official documentation of the core language used to build websites is not written for people who write websites.
Instead, they blindly hope that third parties will pick up the slack. This too guts the notion that HTML 5 is actually a specification.
This extends to the language used in the alleged specification as well, where the use of double-talk, words that don’t mean what they think they mean, etc, etc. It overall feels like it was written in Finnish, translated to Japanese by a Russian, then Google translated back to Engrish moist goodry, me love you long time.
Take a word as simple as “empty”. Think you know what it means? Well, for the entire history of HTML it doesn’t mean what you think.
<div></div>Is NOT what the HTML specification means by an empty tag. That’s why all the know-nothing XML fanboys trying to <div /> in XHTML just have invalid code.
In HTML an “empty” tag means one that CANNOT wrap content — like BR, HR, IMG, META, LINK, etc — not one that doesn’t contain content.
That’s stupid. A stupid made worse by HTML 5 where there attempt to “fix it” by calling them void. Void meaning empty or nothing defeating the point of the blasted change.
Another is the term “deprecated” which yes, means “disapproved of” but it doesn’t mean “forbidden” or “stop using”. If anything it makes it sound like we’re talking down to the tags like a disapproving parent. I suspect that they meant “depreciated” — reduced in value or of no value — but after years of being wrong refuse to admit it. See Commodore’s “KERNAL”, or the “SR-71” for real world examples of that in action.
In the face of such confusing terminology, is it any wonder 90%+ of the HTML out there is non-semantic junk?
And that’s where things go pear shaped. This general lack of guidance on proper use of the language by the very document that defines it. We rely on third parties to shape our understanding when there’s no excuse for that.
I bet you dimes to dollars if the HTML and CSS “specifications” were ACTUAL specifications written for people who write websites, using clear plain English with a well thought out intent, using authoritative language and acting as an actual guide for people who use the damned thing, other “Guidelines” like the WCAG would be superfluous. Likely also put duplicitous web-rot dirtbags like W3Schools out of business in the process.
HTML is supposed to be for device neutral delivery of content to all users. That sounds a hell of a lot like accessibility, so why the blazes are the accessibility rules a separate ruleset. Even more insulting is that they come right out and say it: “Web Content Accessibility Guidelines”. For normies, just the word “guideline” says “this isn’t a specification” and “Go ahead and ignore this” when if ANYTHING should be a specification, it’s accessibility. So much so that the parts relating to proper semantics have no business being separate from the definition of the language itself.
You shouldn’t have to go to an entirely separate document from the one defining the language, just to find out how to use tags like H1..H6 properly!
… and sorry, but most of you are NOT using numbered headings properly! FAR FROM IT!!!
Problem #5, Undoing Decades of Progress
Folks often forget that most of what was deprecated — ugh, that word — in HTML 4 Strict were simple redundancies. Indeed the original plan for HTML 5 — before the WhatWG even existed — was to continue this trend.
NAV was redundant to UL. EMBED and APPLET were redundant to OBJECT which is why one was stricken and the other not accepted. S and STRIKE were redundant to DEL and lacked semantic meaning. Even IMG was on the chopping block as it too is redundant to OBJECT.
Tags were also removed for a lack of semantic meaning in addition to their redundancy to CSS. The CENTER tag being a stunning example of presentational junk that lacked semantic meaning. There is no literary or professional writing reason for text to be centered.
And make no mistake, semantic markup exists to replicate professional writing norms so the UA can best determine how to convey the meaning. It is for the user-agent, not the programmers. Part and parcel of why HTML 5’s new ability to let users just willy-nilly make up their own tags is utter ermagahd aherpaderp trash too.
You can see it in all the pointless redundancies that were added. VIDEO and AUDIO are redundant to object. ARTICLE and SECTION are redundant to DIV and numbered headings and are utterly meaningless semantically. ASIDE would/should be semantic if used for literary asides, but that’s only useful if you’re transcribing the bard or deadpool/Ferris Beuller scripts. The way people use ASIDE is 100% presentational markup, meaning “off to one side” — basically making it as presentational and stupid as CENTER was! HEADER and FOOTER are redundant to divisions in the code numbered headings and horizontal rules are supposed to imply.
These new tags are NOT semantic, no matter how many people claim they are, and they replicate existing functionality. Or at least what would be existing functionality if browser makers got off their asses and finished implementing HTML 4 properly. It’s really sad the only browser engine that actually implemented semantic markup properly and leveraged it for users — Presto (Opera 12/earlier) — is now defunct. Seriously, Opera‘s lazy conversion to Blink — little more than slapping the big red O on Chromium — was a giant middle finger to those of us who chose Opera for a reason. Hardly a shock it’s now for all intents and purposes Chinese malware.
Now, I’m not saying many of the new tags — section, header, footer, nav, etc, etc — are bad, or wrong… they do let me use less classes. It’s just could we PLEASE stop pretending they have ANYTHING to do with semantics or accessibility?
Problem #6, Validation Tools Become Meaningless
When the ALLEGED “specification” becomes riddled with willy-nilly nonsensical junk, it gets hard to find legitimate errors in the forest of inanity. For example it might spew out 50+ errors at you, but when 48 of those are things like the latest spec versions ignoring why certain tags even exist, sticking its nose into things that shouldn’t even be any of HTML’s business, and as a developer who cares about compatibility you’re pretty much going to flip off… finding that ONE actual error you’re looking for like missing/malformed closing tags, typo’s in tag or attribute names, etc, etc, becomes a chore.
Which is why a lot of developers now tell HTML validation to go suck an egg just like they spent most of the ‘00’s telling the same to CSS validation.
I liken it to JavaScript “linters” which always start out with the noblest of intentions, but then usually shart themselves with petty, stupid, and often ignorant whims of the tool’s creator. See such mind-numbingly dumbass complaints linters spew up like Yodish, drop-through on CASE(one of the entire reasons to use case!), so on and so forth. By the time you disable all that trash the linter stops doing anything of value.
Markup validation is now in that same boat. Valid HTML 5 is now trash because the language itself is going all sorts of bizarro-land, nonsensical directions.
Conclusion
I have never had a lot of confidence in the W3C. When talking standards bodies they’re kind of like the cousin who shows up unexpected on Christmas and ends up at the kiddie table. Even the ECMA doesn’t take them seriously — see the middle finger they gave the W3C over the attempt to make HTML/CSS/JS ALL fit under HTML’s umbrella — Actual engineers point and laugh whenever the topic of web standards come up.
This lack of confidence has only been amplified the past eight to ten years, and now I honestly think that they may have grown a bit long in the tooth. They’re making pointless changes that don’t help make the web better, loosening up their alleged standard instead of making it clearer, cleaner, and simpler, and seem to have zero genuine interest in working towards actual improvements in web development for those who REALLY matter. People who make websites, and the people who visit them!
This can be seen in how they basically spent a decade dragging their heels on making a proper HTML 5, blindly accepted the WhatWG’s version with zero real review, and now make pointless little “dicking around” changes instead of putting actual effort into genuine improvements. In fact, the existence of the WhatWG and how they took on responsibility for making a new HTML without the W3C’s influence? That shows that they too neither expected nor respected the official standards body’s intent or resolve.
I think it may be time for the W3C to just step down, or for some of us to get together, take a page from the WhatWG’s playbook, and supplant them.
