HTML 5 Semantic mark-up

Hi All,

There are so many great tutorials on the web that teach HTML / HTML 5 from basic to advance. However most of these tutorials only teach you what the tags are very basically.

I haven't found a resource that teaches you how to mark-up content with semantic meaning. I know it's not rocket science but I'm concerned about how to balance semantic mark-up keep SEO principles in mind.

Does anyone have any good resources to share / website or maybe could elaborate on some examples below and share your thoughts. Thanks in advance!

Would this example be semantically correct? If not why? and how does unrelated content come into the picture?

<section>

    <h1>Matthew West</h1>
      
        <p>
            Matthew Joseph West[1] (born April 25, 1977) is an American contemporary Christian musician, singer-songwriter, and actor. He has released five studio albums and is known for his songs, "More", "You Are Everything", and "The Motions". He was nominated for five Dove Awards in 2005, two of which were for his major label debut album, Happy. West won the 2013 American Music Award for Best Contemporary Inspirational Artist.[2]
        </p>
       
        <p>
            Starting as an independent musician in the late 1990s, he released three independent albums before signing with Universal South Records. With the release of his Dove Award-winning debut album, Happy, released in 2003, his first radio single, "More", stayed at No. 1 on Christian Adult Contemporary charts for nine weeks and received two Dove Award nominations. His second album, History, was followed by a 2006 re-release of the originally independent album, Sellout.
        </p>
       
        <p>
            In addition to his main solo career, West has worked as a songwriter for many Christian musicians and groups such as Point of Grace, Mandisa, Natalie Grant, and Casting Crowns, as well as mainstream country acts, Rascal Flatts, Billy Ray Cyrus, and Vince Gill.
        </p>
       
    <h2>
        Early life
    </h2>
      
        <p>
            Matthew West was born on April 25, 1977 in Downers Grove, Illinois.[5][6] As a child he was a fan of his hometown baseball team, the Chicago Cubs, and wanted to eventually have a career in baseball.
        </p>
       
        <p>
            West wrote most of his first songs in the sanctuary of his father's church while he was at home during college breaks.[7] According to a statement by West at the 2013 Winter Jam (March 23, 2013): at a 1997 Steven Curtis Chapman concert at the Assembly Hall in Champaign, Urbana, West has said that he was crying profusely, making his friends ask him what was wrong.
        </p>
       
        <p>
            Just before graduating from Millikin University in 1999, someone from the college recommended that West attend the GMA Music in the Rockies event for aspiring musicians. Although West was not interested at first, he attended after learning that other people signed him up and paid his entrance fee.
        </p>
       
    <h2>
        Musical Career
    </h2>
      
        <p>
            On July 26, 2002,[8] only a week or two before signing a record contract with Universal South Records, West had an injury to his left arm which threatened his musical career and guitar playing. He says, "I locked myself out of my house. But I'd done that before, and I had a way of breaking in through a window. But this time, I had a really hard time getting the window open.
        </p>
       
        <p>
            I started pushing up on the window really hard and my hand broke through the glass. Blood starting spewing out of my left arm everywhere and I ran down my street screaming for help. After seeing so much blood, I went into shock and just blacked out in the middle of the street.
        </p>

</section>

HTML:

 

Why did you wrap the whole thing with a section tag?

 

Well. Since it’s HTML 5. Probably in that context article might be more fitting. It’s more of an article than a whole section.

 

I recently learned that those HTML5 tags (section, article, aside, footer, etc.) were redundant. Using h tags properly should work just fine in "sectioning out" contents.

 

If the webpage is simple enough to style the body as a container but usually I like to use these as container ect... to add extra style like a box-shadow to visually style the article.

H1 define a title right and h2 a sub title and h3 a sub title of that sub title and so on.

So basically the start of a new section should always be h1.

 

OR, the h1 defines the page title and h2 the start of a section of the page &c.. IFF the section heading is h1, what is the page level, logically? I'm with @deathshadow on on this.

gary

 

@kk5st

I agree. After listening to what @deathshadow had to say about the subject, I find the section tag and how it "resets" the header order confusing. I have subscribed to the simplicity of focusing on document structure primarily based on h tags.

 

Have you considered that it is what div and span tags are for? (and ONLY in case that adding them will make more sense?)

I am still trying to lose a bad noob habit of adding divs for nothing. The more I learn HTML/CSS, the more I realize so many examples out there use many divs and spans where existing tags will do the job.

 

For the most part, I REALLY suggest that you skip the HTML 5 "structural" tags. They are pointless redundancies, more to learn, and in accessibility terms few if any "legitimate" user-agents have implemented them properly. That means no ARTICLE, ASIDE, MAIN, NAV, SECTION, HEADER, or FOOTER.

Numbered headings indicate the start of sections and subsections, so why do we need a SECTION tag? ARTICLE is a non-grammatical abstract, so how is that relevant from a professional writing / semantics standpoint? The first H2 on a page SHOULD be the start of the main content, so why add a MAIN tag? OF COURSE Anchors are navigation, and using NAV properly still requires a UL/LI for menus (read the bloody spec), so what the hell is the point of NAV? We already have headING tags, so what's the point of HEADER? If a HR means a change in topic or subsection at the paragraph level, what's the point of FOOTER? (footers are actually presentational concepts)... and ASIDE, if semantics is supposed to be grammatical structure then the only definition of an "ASIDE" that makes sense is content related to the main section, and NOT "Oh I want this off to one side". Using it just because some unrelated content is going into a sidebar ends up as presentational -- and outright wrong -- as using tags like FONT and CENTER.

It is for these reasons -- and the dumbass ignorant HGROUP tag -- that I really don't feel the WhatWG had people competent enough to have created HTML 4 Strict's successor. It's for that reason many developers will tell you "write for 4 Strict, deploy for 5".

Remember, DIV, SPAN, and A are "semantically neutral" -- they do NOT change the grammatical/structural/semantic meaning of what they wrap; hence their purpose is to hook or group tags for styling WITHOUT SAYING WHAT THAT STYLE ACTUALLY IS. Just like how properly using classes you should say what things are or why it MIGHT be receiving style, and NOT what that style actually is.

Hence why mouth-breathing half-witted ignorant BS like class="text-center box-shadow col-4-s col-6-m" is utter and complete garbage made by people unqualified to write a single damned line of HTML or CSS. And NO I don't care if such people who polluted the web with that type of crap work for Twitter or some such. Just because they work for a big success doesn't make it any less wrong and feeble-minded.

 

With that in mind. How would googles algorithm factor all this in when it comes to ranking in the search engine.

 

Really if you're worrying about any particular search engine, you might be writing your markup wrong. Remember what Matt Cutts told us ages ago: "Write for the user, not the search engine."

The big things you could get penalized for are:

1) nonsensical structure -- if you're using the traditional 4 structure without the new tags, you're good on that. The new tags are so easy to mis-use or misapply, you're better off without the risk.

2) sizes. For the most part those new tags often get slopped in as nothing more than code bloat. Whist they can reduce the overall code if you go ape with certain selectors, it's generally not worth the headaches and most people will still end up throwing classes or ID's at them. For example, if an article can have their own <header> and <footer>, and your body has its own <header> and <footer>, how do you tell them apart? Extra nesting depth, or throwing id's and classes in there? More filesize == slower page == slight to outright nasty penalty.

3) accessibility. If you rely on those new tags, you may end up throwing extra nonsense -- like ARIA roles -- at them which is just more bloat, and most UA's don't care about... honestly, It seems to my own results like search engines don't see them.

Bottom line the drawbacks of using them aren't worth the potential risks.

End of the day the most important part in on-page search is just using the tags properly for what they were originally created for, to mimic what the terms mean or how they are used in professional writing. Paragraphs, headings, bullet point lists/selections, tabular data, proper names/legal entity titles, book titles, emphasis... and not typographical / layout reasons. That's part of why these new tags don't make sense from a "Semantic" standpoint, don't make sense from an efficiency standpoint, and are being added in places where no extra semantic meaning is needed or should even be applied -- which means the correct tag from a semantic standpoint are semantically neutral/meaningless tags such as DIV and SPAN. (only adding them as needed by the template, and not just because you're used to wrapping every blasted tag in two or three DIV...)

Part of why the content itself is king, and search engines don't give a flying purple fish about your layout! They don't see layout, they SHOULD mostly ignore your CSS. That's why putting things in a certain order is good for search, it's why establishing logical structure of your heading orders is good, it's why separation of presentation from content is good, it's why quality writing is a thousand times more important than the artsy fartsy BS marketers, advertisers, and JavaScript junkies insist on pissing on websites with. If they check your style at all, it's to verify things like display:none aren't being abused for content cloaking (which is where many JS fanboys screw up pages), or that you have a layout that isn't fixed width so as to tell small screen users to sod off.

Also, remember that whilst Google may be king of the native language English speaking world, it is not the king worldwide, that title is a toss-up between Yandex and Baidu. It's far too easy to over-focus on Crazy Goog when there are other concerns.

Hence why your best bet is to write your initial HTML as if CSS and the default appearance of the markup does not exist. Write as if you were creating for blind users on screen readers or braille readers, not as if they are sitting there at a screen seeing your full graphics, layouts, and scripting trickery. It's why you don't put presentational images (images used as part of the template, not content) in the markup in IMG tags. Then only once you have all the semantics written do you add any neutral containers like DIV and SPAN to apply the CSS, bending it to your will to create the HTML.

You do that, you're typically golden on accessibility, search rankings, and every other meaningful metric of what makes a quality website.

Which again is why starting out "Designing" a page by dicking around in photoshop, a WYSIWYG or focusing on the appearance is utterly back-assward and one of the fastest roads to failure!

 

I have a question, @deathshadow ...

What if you are required/forced by someone to use 5's "structural" tags? I mean in a very unfortunate situation where you either do it or get fired, how would you it? I just really want to see how that would look like based on your understanding of the whole HTML5 specification.

Several times in the past I would try to use the new tags and end up redoing without them ... and whenever I try to check how others do it they all do it differently.

I must agree that 4 Strict's way is so much simpler, cleaner, less nesting, more logical, easier to style and what not ... just what if?

 

HTML 5 Semantic mark-up purpose of semantic tags are easy to read both by the browsers and web developers.
And most of them are supported by all browsers. These leads to elimination of CSS for the particular division as these tags have their own CSS supported by each browser.

If you want a neat and clean code one should follow these innovative tags provided by HTML5

 

Threaten to quit, then have them find out it wasn't a threat. At least if they're not dumb enough to see the HTML 5 doctype/<head> and assume the rest is fine, which for 99.99% of all people screaming HTML 5 this, HTML 5 that, and HTML 5 some other damned thing is all you really need. (and apart from the new INPUT types are the only real benefits).

But it is a good question and might make for a good comparison, but there's a catch... the catch is related to two more things from your post.

This actually poses a question, a question related to this:

So what is this big question? WHICH HTML 5?!?

W3C or WhatWG? The 2010 WhatWG version, or the 2019 WhatWG, or the W3C 5.0, 5.1, or 5.2?

The W3C only begrudgingly accepted the WhatWG's proposal for HTML 5. The "what working group" has a bunch of really stupid ideas that are incompatible with the concept of STANDARDS or even more importantly SPECIFICATIONS! Such as removing version tracking so it's a "living document", constantly changing the meanings of tags, etc, etc. To that end there are two different groups "developing" HTML 5 with somewhat different rules on what means what. Even so the W3C's rules keep changing over the past decade.

This stems from HTML 5 being "documentative" instead of "authoritative". It documents what CAN be done and how people are using it, NOT declaring what SHOULD be done or how. The OPPOSITE of a standard, much less a specification!

An excellent example of this is the NAV tag, which was originally supposed to mark a block as "you can skip this to get to the content". Instead of that people just started slapping it in around anything that's more than one anchor, so now it means a whole shit-ton of different things detracting from the original useful purpose. To address this the MAIN tag was added because it's somehow "simpler" to have more tags in the specification and expand the defintion of the tags "meanings" than it is to tell people "no, that's not what NAV was huffing FOR!".

Another example is how nobody seemed to know under <em>ANY HTML</em> version what TFOOT was for, and when they did they slopped it in after TBODY which <strong>WAS</strong> completely incorrect! TFOOT went before TBODY so the browser could see it when dealing with page-breaks or other divisions so that it could be printed at the bottom of each break, just as THEAD is supposed to be printed at the top of each break. Now HTML 5 has gone full Gungan and made it INVALID before TBODY because people were using it wrong!



They keep dicking with things to adjust to what people are doing, instead of growing a pair and telling people WHAT to do. Aka what a "standards body" is actually for!. There's a reason the IEEE and ECMA point their fingers laughing hysterically every time the W3C tries to sit at the adults table saying "hey, we're a standards body too!"

Basically why you see so many different versions of HTML can be summarized as:

1) There are two different bodies controlling what "is" HTML 5, and they now disagree with each-other. A LOT.

2) Each of those bodies keep changing what the tags mean and/or should be used for.

3) If you make up your own use out of ignorance, it WILL get worked into the specification sooner or later.

4) Browser makers don't give a shit, they're treating them as DIV with fancy names. All those ALLEGED meanings mostly being ignored by all browser makers and other such user-agents. Few if any UA's do anything with them "semantically", xcept in a few corner cases Apple's "screen reader" tech... which is actually useless to blind people most of whom use ten year old illegal copies of JAWS. (because JAWS is the only one worth a damn to the blind, and costs a small fortune)

Much akin to how Opera was the only browser maker who offered heading or accesskeys menus. When I say "was" I mean... well, now nobody does. Opera told users needing such things to go f*** themselves when they adopted blink. Just like EVERY OTHER blasted feature Opera users got used to having. Hardly a shock the company ended up taking a swan dive into the toilet, and are now nothing more than a front for Chinese spyware.

5) Even when people use HTML 5, they don't take the time to understand the rules or semantics of any of it and just use it any-old-way making wild assumptions based on the tag's name. This is why you see <article> slopped around everything EXCEPT complete articles, SECTION wrapping ARTICLE in redundant manners, SECTION wrapping HEADER, HEADER wrapping numbered headings that are all by their lonesome, etc, etc. You can't fix stupid, and its what makes point #3 so damned dangerous. It ends up a self-feeding perpetual motion toilet flush. Sadly the avalanche has already begun, it's too late for the pebbles to vote.

6) The "specification" isn't worded for people making websites, but for people making browsers. As such there's no OFFICIAL reference that's actually useful or even correct. The closest you can find that actually makes sense is MDN . That it's MDN makes sense too as middlemen go; If anyone can convert the language meant for browser makers into language meant for web developers, it might just be a group who makes browsers.

7) There are so many scam artist BS websites out there with tutorials written by people not qualified to flap their damned yap on the subject. See the dirtbags who run W3Schools as a stunning example of this in action. One look at their "w3.css" framework should be all you need to realize not only do they have NOTHING to do with the W3C (despite the common delusion / disinformation that they are affiliated), but nobody creating their tutorials is qualified to work with -- much less tell others how to use -- HTML or CSS. Bad education is often worse than none.

Basically, HTML 5 was created by people who never embraced or understood HTML 4 Strict. At best it is a highway paved with good intentions. As always, people are more likely to get on the Highway to Hell than they are to climb the Stairway to Heaven.

So... what I'll do is I'll make three codebases when I have the time. I'll do a 'modern' template using 4 Strict under the 5 doctype, then redo it as WhatWG HTML 5 from a decade ago, AND "current" HTML 5.2 by the W3C standard. Be interesting to see how that goes.

 

There's really no taking things lightly with you, @deathshadow ... Thank you so much for what you do!

Shall we call this HTML5 Strict? LOL

Wouldn't that make older codebases technically/semantically incorrect??! Why are there two groups? I'm confused how is this even allowed (I don't know jack about the subject). Which one is the actual standard? Is there a possibility for a 5 Strict / new XHTML to happen?

I thought W3C is the only standards body and should have the full authority over HTML. So where did WhatWG come from?

I have so many questions ... LOL

 

Ayup, a situation made all the worse by the complete removal of ANY indication in the markup of WHICH version of HTML you're using. Hence why as we move forward HTML 5 is pissing on the entire concept of semantic markup from almost as on-high as "extensible" markup -- aka where people are allowed to just make up their own tags that UA's have NO way of understanding the SEMANTICS of.

The W3C is the 'official' one, but they didn't create HTML 5. Ok, history lesson.

When HTML 4 Strict -- aka "the real" HTML 4 -- was introduced, a lot of people didn't like it. Partly because the word "strict" made them think it was harder, partly because they couldn't wrap their heads around the idea of "what things look like" having ZERO business in the HTML, and more importantly because "wah wah, eyes dunz wunna lurn sumtings nu!"

At about this same time, XML was getting "hot and trendy" being thrown at EVERYTHING regardless of if it made any sense (how many of you use XMLHttpRequest with nothing but XML?), if it was efficient (It's not, it's actually quote bloated when it comes to data transmission., or if it was ACTUALLY any better than SGML. (The standard on which HTML is based). Because everyone was hopping on the XML bandwagon, the W3C felt the need to make HTML fit the XML namespace. The problem is that it would have meant new XML based pages wouldn't work in old HTML parsers.

So the end result needed to work in BOTH XML and HTML at the same time, hence XHTML 1.0 was born. It was intended as a stepping stone to going full XML in the next version... but this had multiple issues.

1) again the next version would still have not worked in legacy browsers.

2) The extensibility of XML again would have pissed on the concept of semantics. If you can make up any damned tag you want, how does ANY tag have practical grammatical or structural meanings to the user-agent? As it is we STILL deal with this with different developers just making up their own tags and attributes willy-nilly, ignoring the point of HTML altogether.

3) Microsoft -- at the time the 500 pound gorilla in the room since IE at the time was dominant -- wanted no part of it. (even though they gave us XMLHttpREquest via activeX and used XML in-house)

4) XML fanboys kept screwing up the use of XHTML 1.0 meaning that 2.0 would have been an even bigger mess. The "unclear" specification meaning of "empty" being a stunning example as trying to explain to them that <div /> is NEVER valid goes right over their heads. I'm shocked how often in bleeding edge codebases you still see people using <div/> even though it's invalid HTML or XHTML -- in ANY version!

Whilst I used to use XHTML 1.0 because we were told it was where things were heading, and I appreciated the cleaner syntax, by around 2008 it started to become apparent that it was a technological dead end.

We were promised an updated HTML was underway even when 4 Strict dropped, and XHTML wasn't it... so we waited, and waited... Oh we'll announce in 2002... 2004... 2006... Nothing. Then it came to light that a LOT of the people who were supposed to be working on the next HTML had "moved on" or been outright shown the door.

You combine the lack of adoption and irrational distaste of 4 Strict, with the train wreck of trying to make it fit the XML namespace, and the general lackadaisical attitude of the W3C on producing anything new, and, well... certain partners in the W3C, certain members of the community, and certain big names in the industry got together and said "ENOUGH" and started making their own HTML 5. This group became the "What Working Group?" -- WhatWG.

Thing is I saw major issues with the WhatWG from the start.

1) A LOT of the "irrational hatred" of 4 Strict was apparent in that they were ignoring the proper semantics and structural rules, instead layering extra structure for no GOOD reason.

2) It became painfully apparent that they didn't even grasp what half the tags were actually for structurally. See the idiotic "HGROUP" tag for putting two headings together such as for a title and tagline -- which means the second heading is NOT the start of a subsection of the first defeating the POINT of numbered headings. Or the SECTION tag resetting to H1 depth.

3) They allowed into the specification tags (like EMBED) and attributes (like TARGET) that were SPECIFICALLY rejected BY NAME in HTML 4 Strict. They were rejected for being either redundant (to OBJECT) or pissing on accessibility (shoving new windows down the user's gullet whether they want them or not, breaking conventional navigation!).

4) Getting rid of version tracking, so that it's a "living document" so who knows what standard anyone actually wrote the bloody code to.

Whilst there were plenty of good ideas like simplifying down the contents of <head>, getting rid of obvious attributes (such as type="" on <script> and <link rel="stylesheet">), the re-introduction of redundancies (EMBED), introduction of new redundancies (AUDIO, VIDEO), retention of old redundancies (IMG), and pointless new "structural" tags ended up making it look like a house of cards.

Which is why they latched onto CSS3 and the latest EMCAScript and slapped it ALL under HTML 5's banner. "Oh it's all part of HTML 5 now" was a way to take all the cool stuff from CSS3 and ECMAScript, and claim it somehow has something to do with their markup specification... that the W3C didn't create or really even show an interest in.

So how did it become a W3C standard? APPLE and Mozilla. At the time -- we're up to around '09 to '10 webkit was the new hotness, and Firefox was severely cutting into M$ share, and both threw their girth behind the WhatWG's HTML 5. This led the W3C to start evaluating it (aka lazily slapping a rubber stamp on it) with it finally hitting W3C recommendation status in 2014. This is something I think people lose sight of is that it's only been a W3C recommendation for four years, we were NOT officially supposed to even be using it on deployment websites prior to that!!!

Basically the W3C (kind of like M$) rested on its laurels with no interest in innovating, multiple parties banded together to make something instead, and then the W3C went "ok, that looks good"

... and it's been biting the W3C ever since. How can I say that? Well look at how the W3C current recommendation (5.2) has branched away from the WhatWG recommendation. First off, the W3C added versioning to their documentation. (shame it's not in the markup). Second a lot of things -- like HGROUP -- were immediately stricken. If you start reading the W3C HTML 5.2 documentation, there are disclaimers on certain elements over how it "differs" from the WhatWG implementation... but client side there's NO WAY TO DIFFERENTIATE WHICH IS IN USE!!! Hurr-durrz.

This is the result of the WhatWG's version being more based -- by some of the people who worked on its own admission -- on what people WERE doing, instead of what they SHOULD be doing. Since they were ignoring the semantics of HTML 4 Strict and instead embracing many of the wrong things people were doing with 4 Transitional -- literally meaning in transition from 1997 to 1998 practices -- they created tags to replace a lot of what people were slopping in "DIV for NOTHING" for.

From pretty much 1998 to 2010ish, the majority of web developers were still writing HTML 4 Tranny or XHTML 4 tranny. The most common site building techniques best summarized by @Dan Schulz at the time:

"The people who used to endlessly nest tables for nothing, now endlessly wrap DIV for nothing. End result ignores semantics entirely. <div> should be for grouping things for the application of style, without saying what that style is!"

People were using DIV just because they wanted a section, or an article, or for navigation. In many cases they added them for the application of style that could just as easily have been applied directly to the tag inside it, like the UL, H1, or P. You'll see this all the time in older codebases:

<div class="nav">
  <ul class="navUL">
     <li class="navLI"><a href="#" class="navLink">HOME</a></li>
     <li class="navLI"><a href="#" class="navLink">FAQ</a></li>
     <li class="navLI"><a href="#" class="navLink">CONTACT</a></li>
  </ul>
</div>

Code (markup):

When stylistically not a single damned thing is even being done to warrant the outer DIV since UL's a perfectly good block level container unto itself. Much less how if the outer element has a class or ID, and ALL the tags inside it are getting the same class, NONE of the inner elements need classes! Just look at the mental huffing midgetry that is bootcrap or w3.css for proof of that!

ALL the new HTML 5 tags do is replace those "DIV for nothing" with "new tags for NOTHING" as it's just the next step in perpetuating 1990's practices that should have died off twenty damned years ago! Especially tags like NAV which:

1) still requires the UL inside it to say it's a menu, those slopping anchors in their blindly are morons making shit up as they go. <a> is phrase level, treat it as such.It's also semantically neutral like DIV and SPAN!

2) EVERY anchor is navigation, that's kind of the POINT of the <a> tag.

Or ASIDE, which:

1) The only sense in which an "aside" would make sense from a grammatical/structural/literary standpoint is a set of text related to the main content that the content makes sense without, such as a Soliloquy or fourth wall breaking. Unless you're writing a bunch of Deadpool and Ferris Bueller slashfic, or converting the complete works of Shakespeare to HTML, NOT all that useful. Kind of like the official meaning of the ADDRESS tag, relegating it fairly useless!

2) if used just because it's a "sidebar" or something you want "off to one side" you've made the tag just as presentational as CENTER and FONT are!

Don't even get me started about FIGURE which people slop around every blasted IMG tag for nothing, or ARIA role herpaFreakingDerps like <form role="form">.

Again, endless pointless tags that serve no legitimate purpose apart from justifying bad markup practices. The only difference is they have alleged meanings that are redundant to what should probably be inside them via other tags.

Even CANVAS is silly... since it's scripting only. If it's scripting only, why the F*** does it have a tag other than <script> and <noscript>. As a placeholder for a DOM element it's ok I guess, but it sure as shine-ola has dick to do with semantics. I still say JS should be allowed to attach 2d and 3d contexts to ANY element, not just CANVAS! At BEST it's redundant to OBJECT... but then so is IMG which is why the original plans for the HTML after 4 Strict included removing the IMG tag from the spec... so as to fight vendor lock-in and/or browser makers dictating which image formats we can / cannot use.

Just like audio and video which "fought" the vendor lock-in of flash by creating vendor lock-in by whatever pet container and codecs the browser makers feel like supporting. You'd almost think that Apple and M$ -- the two rhino's in the china shop -- had personal vendetta's against Flash after LOSING the format wars. Seriously, who gave a damn about MOv (QuickTime) and AVI (Windows Video) any time after 2006? You might as well have .rm files at that point!

The real laugh of that mess being Mozilla threw its weight behind OGG, right up until it became apparent that OGG sucks and nobody other than the frothing-at-the-mouth FSF "Church of Stallman" fanboys wanted it. Talk about backing the wrong horse there Johnny! Makes sense though since Mozilla is chock full of "free as in freedom not as in beer" whackjobs. Making the Iceweasel nutters even scarier -- when the Mozilla Foundation is a bit too "corporate" for your tastes because they trademarked the name and logo. That's like creating your own splinter Jihad group as Al-Quedah is a bit too warm and fuzzy. Or splintering from the COE as it was too warm and fuzzy.

In any case, the end result is a shit-show that feels like it has no real direction, no real purpose other than "ooh look, it's new and shiny" (and that shine is wearing off), and is overall rudderless. Again, it was built based on what people WERE doing, instead of what they SHOULD be doing. It's more documentative than authoritative which makes it everything EXCEPT a "specification". A real engineer should take one look at the most recent versions -- both W3C and WhatWG -- and recoil in horror at the unmitigated GALL it takes to even use the word specification in reference to it.

As I've said before, the painful legalese and massive pointless bloat of it surely not helping matters. I mean in just about 30 years we've gone from the simple text of HTML 2, to a mess of cryptic legalese larger than the founding document of most nations! It's gone from around 32k to 2.85 megabytes as plaintext. (the single page of HTML 5.2 now coming in at 12.8 megs of markup). That is ABSURD! It has increased in size nearly 90x, whilst in terms of the number of tags and attributes it's BARELY tripled... Thanks again to a painful legalese and flowery, borderline cryptic language that has ZERO business in a "specification"!

You'd almost think there were six separate editors all with different agendas set by the parties they represent (Microsoft, Apple, Google, Paciello Group), NONE of them actually caring what we as web developers actually do with the ALLEGED "specification".

What ever happened to plain simple honest language? In this age of "If you can't say anything nice" it's ok to trash the dissenters with any language you want, but not ok for the dissenters to respond in kind. It's wrong, it's abusive, and it is done JUST to maintain the echo-chambers of like minded head bobbers and blow jobbers that borders on cult-like control. You can see it plainly at places like SitePoint or Hashnode, where the ONLY thing valued in their "communities" are suck-ups and sycophants.

It's getting so bad, any day now I expect to hear a DDOS victim referred to as an "Unwilling traffic recipient".

I wouldn't count on the W3C doing it themselves any time soon, as the past twenty YEARS have shown that's not their game. They're just looking for any crazy shit people come up with they can rubber stamp their approval on. If specifications were patents, the W3C would be the SCO Group. For all intents and purposes, they're "specification trolls". They have drifted so far from their original purpose and intent of being an open public driven standards body, that they threaten Keiichi Tsuchiya's position as drift driving consultant to the "Fast and Furious" franchise.

I've considered just doing it my damned self. I have a "bucket list" of things to remove, things to add, clarifications to make, and a general idea (as an engineer) of what a specification SHOULD look like. My health issues interfere with moving forward on it at anything resembling a decent pace though I do keep picking away at it in my spare time. Part of me says "well who are YOU to do this?" -- but I keep reminding myself who was Linus Torvalds other than a kid who learned on a VIC=20? Who was Tim Berners Lee other than just some guy at CERN. Who was Reiser other than some guy who partitioned his wife. Ok, that last one is a bad example...

We often get too caught up on who's a "big name" in the industry. Oh but they work for Google or Microsoft... oh but the Bootstrap creator worked for Twitter. Oh but they went to college for 8 years for this. As if that actually makes them more qualified than people who've worked 20 years in the trenches for dozens if not hundreds of different clients. I fall into that trap myself -- "star power" as it were. People do it all the time with Hollyweird actors/actresses. It's a hard habit to break and can lead you into buying snake oil. See "Gwenyth Paltrow", "Pat Robertson", "Donald Trump", or the douche calling himself an Avocado. Once their name is in the spotlight, it's so easy to manipulate the herd with quackery, if not outright demagoguery. Ends up being far too easy to dupe oneself into doing the programming equivalent of shoving a jade egg up the holiest of holies. Enjoy your TSS!

I don't think the WhatWG is capable of creating what I -- and many others -- think we need. The W3C certainly isn't capable of it since they've lost direction and have few if any people on staff who's JOB is to actually ride herd on the INTENT... much less actually make a new specification all on their own. (hence the lazy rubber-stamp on the WhatWG's stuff)

One thing I really think is needed is a "benevolent dictator". One person with final say and a goal of helping everyone. There's a reason Dante Giacosa and Ferdinand Porsche are legends, whilst nobody's ever heard of the boardroom full of clowns who crapped together the Pontiac Aztec. Say what you want about the FIAT 100 or original VW Beetle, but they're the Model T of their time. Cars that "normal people" could afford.

It's why I worry for Linux's future with Linus stepping down from that role. Design by committee is ALWAYS a disaster. Too many compromises, too many differing goals, and moving the goalpost far, FAR too often.

It's OK to accept new ideas and incorporate them, or to steer around the occasional iceberg, but overall you have to stick to the course or you'll never get to the destination. Right now -- to me at least -- HTML 5 feels like we're "Lost" in the Pacific with three admirals and a commodore arguing over which of the cardinal compass points we should move towards; all whilst a midshipman is trying to tell them Midway Island is in sight to the northeast.

 

@deathshadow,
Good essay. I was in the what group for a short time. I left, when I protested some suggested elements I thought redundant BS to be told they were basing on what people were doing anyway. "Paving the cowpath", as it was put. I figured I was misplaced among a bunch of silly graphic designers where we needed information science engineers (think library science).

gary

 

Which is what I was repeatedly told when I voiced my own objections at the time. Why was EMBED included? Doesn't HGROUP just justify an incorrect practice? (one of the few fights that was won!) Aren't VIDEO and AUDIO redundant to OBJECT? Why is IMG still in there. If FIGURE isn't for just mathematical or scientific figures and is for "any plate image" what makes it any different from IMG?

When the answer was "we're documenting what can be done. What people are doing" -- the implication being right or wrong, they were just documenting behaviors and techniques, and the few tags they were adding being made in support of that. That's not a specification, that's a master catalog. Good for implementation of parts, bad for design and manufacture. Just because barely even steel #2 bolts exist, doesn't mean you use them when the load requirements should be dictating a high carbon #8.

But as I've said many times, the majority of people who never grasped semantics and spent a decade or more stuck with HTML 3.2 practices under 4 tranny, just yummed that rubbish right up.

At one point, I even heard someone directly involved say "web developers aren't smart enough to do it properly anyways." -- How insulting is that. Sure, I might say incompetent, inept, and ignorant, but that's because I actually believe -- perhaps falsely -- that people can do BETTER. I would never tell anyone that they can't ever do something, just that they're currently incapable of it and need to learn more. You don't design specifications on the assumption the people designing with it are too stupid to use it, or change their existing habits to meet it.

Specifications should be AUTHORITATIVE, telling people WHAT to do, HOW to do it, and WHY. The current WhatWG / W3C specification doesn't even come CLOSE to doing that for web developers. It's just a catalog of what browser makers should be supporting. What the blazes good is a HTML specification that's not even written for the people who will use HTML on a day to day basis? In what huffing universe does that even make sense?!?

Yeah, I heard that one too. My response at the time was "Well that explains why it feels like it's built on a foundation of manure."

 

That's a history lesson for sure!! I won't pretend like I know anything. You got me thinking about all sorts of things for days ........ I did something else for many years. I wish I didn't stop coding.

Really?!!!!!! How long have you been working on it?

@kk5st

Wow!! You're all part of the history here ... Wouldja tell us more about it, please? =D

 

Not much to say on my part. I got in under html 3.2 when fancy layouts were done using nested tables and the graphics dweebs wanted everything to look like magazine pages. The stupid of having your content image bound still burns bright today. HTML 4 and CSS were great, Write your content and markup, then let the CSS do its job.

I looked forward to HTML 5 because I wanted the html syntax to be strict to reduce ambiguity and to make the markup much more helpful to JS and server-side languages' ability to manipulate. Sad to say the powers that be were going the other way.

CSS has moved forward in a generally good way, html, not so much.

Were it up to me, I'd go with a strict XHTML with the proper doctype definition* for the element and attribute extensions. I did some dev work for a small mfg co where we used xhtml extensions for data types. The mid-tier coders (PHP) and back-end coders (DB/SQL) loved it. I did too once I got the front end separated from the mid-tier with a proper templating engine.

I've been retired for almost 10 years now so my expertise is dulled by time.

gary

* For a moronically simple example of xhtml, see XHTML Doc. View the html source and the css.