Loss of confidence in the W3C... is it time for a new HTML?

[Jason Knight]

Please if you vote, make a post explaining your position. I may come across as dismissive sometimes, but I do listen and I do weigh all arguments as fairly as I can. We might simply disagree -- that's fine. Imagine how boring things would be if we all agreed all the time!

I have thoroughly lost what little confidence I had in the W3C when it comes to the markup "specification". As someone with an engineering background simply calling it a specification now raises the hackles on my hackles as what the WhatWG created is such a mixed bag, that I really wonder if they ever even had a plan all along, or were just throwing things at the wall to see what sticks. In a "moon dust causes cancer, I'm gonna burn life's house down with lemons" sort of way.

I saw the cracks long before the W3C accepted it, such as the idiotic (and thankfully defunct) HGROUP tag which showed the people creating HTML 5 didn't even know how to use numbered headings properly. Or the redundancy of nearly all the "structural" tags to simply using H1..H6 and HR properly.

But it has gotten even worse with some of the recent changes. Such as the pointless flipping of the tfoot/tbody order, or the warning for the use of media targets not on their list that shouldn't even exist in the first place, and other such rule changes that make HTML 5 validation as pointlessly useless as CSS validation has been the past decade and a half.

I mentioned it on (the now defunct) coding forums, discussed it in more depth on DigitalPoint, but now that I have my own forums I thought I'd throw the idea out there and see what y'all think. My initial ideas for it are:

• Be authoritative, not documentative.
  
  Tell people how to do things, not just what browser makers have implemented. This would eliminate such derpitude as the inclusion of "target" and "embed", but more importantly make the HTML specification -- the spec defining the language used to write websites -- actually be oriented towards the people who use it to write websites. Apparently this is a "radical' concept the W3C has no interest in since their version of the specification is written for browser makers, not site authors.
  
  Let me say that again, the HTML specification isn't written for the people who use HTML to write websites, it's written for browser makers, something that -- to be brutally frank -- likely shouldn't be more than a single page of instructions for 90% of the tags.
  
  
• Reduce the number of tags by focusing on what tags are FOR!
  
  This was part of HTML 4 strict and the ORIGINAL W3C "HTML next" plan. Remove pointless redundancies. People talk about how the tags deprecated in 4 strict were done so for redundancy to CSS, but that was only a small slice.
  
  Some were rejected or removed for their sheer redundancy. MENU was a list of choices, that's redundant in semantic meaning to a UL. EMBED was rejected for being accepted into the specification for being redundant to OBJECT. S/STRIKE were removed for being redundant to DEL and not the CSS. ISINDEX was dropped for INPUT. For "next" even IMG was supposed to be on the chopping block for its redundancy to OBJECT!
  
  Other tags were dumped for being bad for usability and accessibility. U for example was shown the door because underlining in web documents is supposed to mean "link", and if you have the concepts of B, I, EM, STRONG, and CITE, the grammatical / literary / semantic reasons for underlining something are also redundant. The TARGET attribute and FRAMESET tags were given a whack with a hatchet for this reason.
  
  But look at HTML 5, and many of the new tags simply bring back old redundancies. See AUDIO and VIDEO which are redundant to OBJECT. SOURCE which is redundant to OPTION. The "structural" tags of ARTICLE, ASIDE, HEADER, FOOTER, SECTION, MAIN which are redundant to just using H1..H6 and HR properly.  Worse, many of them -- like ASIDE -- are either being used in as presentational a manner as CENTER or are beign slopped around things for which any semantic / dictionary meaning of the word "aside" doesn't even apply. FIGURE / FIGCAPTION are similarly pointless and abused.
  
  As I've said more than a few times, for every legitimate improvement found in HTML 5, there are two or three things that make me question if they had any idea what they were even doing. It is very apparent that when making it they paid no heed to the intent, logic, or reason behind the changes in HTML 4 Strict.
  
  
• Clearly define what the tags are FOR and what they MEAN!
  
  This is someplace HTML has always kind of dropped the ball, though I can't blame TBL for that on the early versions. When Berners-Lee created HTML it was meant for the authors of white papers, research documents, scientific papers, and so forth. People who knew and understood the concepts of logical document structure, what headings meant and/or were for, and as such would know why headings have depths, where/why a horizontal rule should be used, the differences between a book title and emphasized text, etc, etc.
  
  Concepts completely glossed over when they shouldn't be once people who have forgotten their 4th and 5th grade English classes are let lose upon writing documents. The lack of clearly defining the roles, usage cases, and structural meanings of the tags is the number one reason we see little to no proper semantics out of the majority of developers.
  
  Something made worse whenever the W3C's idea of "fixing that" is to throw more code at the problem HOPING that people will learn to use the new code right. Here's a tip, if people can't learn to use what already exists properly, throwing more options at it isn't the bloody answer!
  
  "My God, man - drilling holes in his head's not the answer. The artery must be repaired. Now put away your butcher knives and let me save this patient before it's too late!" -- Leonard "Bones" McCoy
  
  A stunning example of this is ARIA roles, where if you read the WAI rules for them they exist to say what tag should be used when using the wrong tag... When is it possible to edit the document to add attributes but not fix the incorrect tag usage? As I said in my article on the topic "Why do these even EXIST?!?". That Aria seems to have been an attempt to re-teach semantics, the fact that even the spec says on most of them "use the correct tag INSTEAD" but people are adding them TO the correct tag -- <form role="form"> for example -- proves what an abject failure that is.
  
  Again, the fault of the fact the HTML specifications are currently not what any actual engineer would call a specification, and are written for browser makers, not those of us actually using the language in production.
  
  

That's my thoughts on it, and this IS a project I'm slowly assembling on top of all the other plates I've got spinning...

I do often question "well who am I to take on a standards body and make my own spec?" -- but who was Tim Berners-Lee when he created HTML at CERN. Ok, he worked at CERN, that's a pretty good qualification for a LOT of things!. Who was Steve Wozniak in 1976 other than some pimple-faced teenager? Who was Linus Torvalds in 1991 when he started working on Linux other than a second year college student?  People don't become "names in the industry"
by not trying to do things "above their stations". It never hurts to at least TRY.

But what do you folks think?

[coothead]

Please if you vote, make a post explaining your position.

I have read your critiques about HTML5 over the years
since it's introduction and they all made sense to me. 

Of course,  as an amateur, who just does this stuff as a
mental exercise in the hope that it may help stave off
senile dementia, my views may just be considered  the
ramblings of a feeble mind. 

For me, though,  the very sight of elements such as nav,
main, section aside, footer and some others that may
have slipped my mind really aggravates me.   

coothead

[sunfighter]

I agree with coothead and with you about your critiques. Except the last part: Header, nav, main, section, and aside, footer makes sense to me and helps cut down code.

[John_Betong]

>>> Except the last part: Header, nav, main, section, and aside, footer makes sense to me and helps cut down code.

I'm just concerned that Html6 will be simpler, drop those tags and this will mean a lot of editing to conform to the latest update.

[sunfighter]

Actually John from now on there will be no HTML6 - HTML7 nor CSS4. What is planed is introducing concepts and then slowly upgrade their status till they're gospel.

What I don't like is browsers STILL honoring old code that should have been strangled a long time ago like <center> or the align attribute. Think how slim the browsers would be, how fast they would display a page. 

[Gary-SC]

I would love to see all the redundant tags eliminated. HTML can become simpler to learn, and its clarity will improve without those unnecessary tags.

[Jason Knight]

I agree with coothead and with you about your critiques. Except the last part: Header, nav, main, section, and aside, footer makes sense to me and helps cut down code.

Those pointless, idiotic, REDUNDANT tags are what soured me on HTML 5 from the start. There's a REASON I tell people not to use them, and they cannot hurry up and die fast enough for me. These don't need to be deprecated, they need to be lit on fire and then have their ashes pissed upon -- just to be sure.

SECTION is redundant to numbered headings, HR, and DIV all in one. HEADER is redundant to the appropriate headING, ASIDE is used as presentationally as CENTER and if we used the semantic meaning of aside, it's only useful in deadpool vs. Ferris Bueller slashfic. ARTICLE is not a grammatical construct so that's pointless, MAIN is redundant to the first H2 or HR in a well formed document... about the only one filling a missing gap is FOOTER, and I can manage without it because I know how to use HR.

... and they could all be replaced by adding a "depth" attribute to HR to say what H1..H6 it's being equivalent to.

They seem to exist to complete the circle Dan Schulz joked about a decade ago. "The people who wrote endless pointless nested tables now just write endless pointless nested DIV". With HTML 5, those same people with their outdated outmoded 1990's coding methodologies just replace the DIV they don't need with HTML 5 "structural" tags they don't need.

It's the same circle-jerk, just a different circle. They are a stunning example of:

1) Documenting what people were doing instead of telling them what to do.

2) Giving up on teaching people semantics and throwing more code at the problem in the blind hope somebody will use it right.

The solution is plain as day to me, swing a giant axe at the pointless redundant tags, and clearly -- in no uncertain terms or double-speak legalese -- define what the tags MEAN!

Again, since most people don't even seem to know what H1..H6 even mean, what HR means, etc, etc... I mean lands sake we still have hordes of people who can't even keep the usage cases of B, I, EM, STRONG, and CITE straight, with many still parroting the bald faced lie of "don't ever use B and I" or worse "Well those tags are deprecated".

I see one more person out there blindly using P for what should be LABEL, putting P around lone images for Christmas only knows what, omitting LABEL because "but muh W3Fools examples!", starting a document with a H5, dumping anchors into NAV without any UL, etc, etc, I'm gonna barf.

It's bad enough my hiatal hernia has me worshiping at the porcelain throne 3 times a week.

It is a crime against engineering to call HTML 5 a specification, and it is certainly the farthest thing from the sane and rational development HTML 4 Strict was trying to give us.

Dr Smith: Oh the pain... the pain...

[goto10]

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.

Yes, TBL's minimalist approach made sense when it was just eggheads looking at each other's white papers, but now an estimated 40% of web interaction is bots talking to bots. 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...

Is everybody using the new tags correctly? Hell, no. But you could say that about any of the specs since 1.0

If you would really like to know what the tags are FOR and what they MEAN, MDN has quite good documentation on them, starting here: https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Using_HTML_sections_and_outlines

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.

Honestly, you sound like old folks yelling about the smut on TV. Just change the channel, gramps - nobody's making you watch.

[Jason Knight]

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.

Code: [Select]

<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.

Code: [Select]

<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".

[goto10]

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.

Well, I'm glad we agree on 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.

It's a pithy quote, but I'm not sure why you're bringing musings on content to a discussion about markup. In fact this is basically the entire point - content is machine readable but designed for humans. With markup the opposite is true - it's human readable but designed for machines.

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.

This kind of sounds like the point that I am making. I think maybe where we disagree is that I think semantic richness is a welcome feature, as long as it is not obligatory and plain ol' HTML of the type you espouse is still valid (which it is)

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.

Mmmm... I would put the low barrier of entry to web dev and the rather forgiving nature of browsers in general higher up the list than those - a great portion of the web is made by people with little to no interest in CS and it just works. Personally, I'm OK with that - I would rather see the web become a sprawling democratic mess of diversity than a walled garden presided over by specs-wielding zealots.
 

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.

I think you should look again. The explanations are fairly clear. Maybe you're looking for something that isn't there, though - most of the new tags don't do anything magical structurally - they're more about adding inherent meaning to markup

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.

Sure. In the same way that "on horseback" was a fine way of getting to the next town and "by candlelight" was a dandy way of reading a book at night

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.

I really don't know what to tell you, except that I think there are more important windmills to tilt against.

Again, just go to bootcrap's website, view source any of their examples...

I don't like bootstrap, and I don't respond to straw man arguments, so I'll pass.

[Jason Knight]

It's a pithy quote, but I'm not sure why you're bringing musings on content to a discussion about markup.

Because he wasn't just talking about content as it was in the context of on-page SEO. My bad for not including context, but writing for the user INCLUDES the use of semantics, It's why semantic markup was a thing before Archie was a twinkle in Emtage's eye.

Semantic markup's purpose is to let the UA deliver the grammatical meaning to the user. As such it is part of "write for the user, not the search engine" as it refers to the entire client-side building process. It is meant to take to task non-semantic markup, keyword stuffing, fancy scripted doo-dads that do not a blasted thing to enhance the user experience, etc, etc.

In fact this is basically the entire point - content is machine readable but designed for humans. With markup the opposite is true - it's human readable but designed for machines.

It's strange how folks throw around the term "machine readable" as SGML/XML -- and by extension HTML and XHTML -- are NOT machine readable formats. If you have to write a giant parser to turn them into objects, they are not in any way, shape, or form machine readable. They exist much like assembler mnemonics to be HUMAN readable ahead of what machines want.

Are the integers and floats stored in binary? Are the strings (textnodes) stored as length limited or null terminated ? Are the commands and instructions stored as binarry? No? NOT MACHINE READABLE!

It's why the XML 'database' nutters are of dubious sanity. They LOVE to call XML "machine readable" when it is nothing of the sort. Not even close, not even the same planet.

This kind of sounds like the point that I am making. I think maybe where we disagree is that I think semantic richness is a welcome feature, as long as it is not obligatory and plain ol' HTML of the type you espouse is still valid (which it is)

It think where it bothers me most is that it's just flat out redundant to what already is, so it's not adding richness; unless you mean the bloated feeling you get after eating an excessively "rich" dessert.

Semantics is good when it provides logical document structure and meanings useful to convey content to users... but you can take it too far and there are times it genuinely feels like those currently officially working on the spec won't be happy until every single word ends up wrapped with a "tag for nothing" -- I'm waiting any day for them to announce <verb>, <noun>, <adverb>, <conjunction> tags... because that's how silly article, aside, nav, etc, etc feel.

But more the issue is that these tags literally feel like they just exist for the people who still write HTML 3.2 style code, only having replaced their HTML 3 <table> with HTML 4 <div>  with HTML 5 "structure" without even considering if they actually need those extra tags in the first place.

It's a Mmmm... I would put the low barrier of entry to web dev and the rather forgiving nature of browsers in general higher up the list than those - a great portion of the web is made by people with little to no interest in CS and it just works. Personally, I'm OK with that - I would rather see the web become a sprawling democratic mess of diversity than a walled garden presided over by specs-wielding zealots.

The problem is that I think the "you must be this tall to ride" barrier has been lowered to the point that kids are falling out of the rollercoaster to their death. It's part of the near sociopathic lack of empathy that's pissing on this industry from so on-high and for so long, you'd think the Almighty just got back from a kegger.

The excessive permissiveness of the specifications, how browsers handle code, etc, etc are what gets beginners into trouble, prevents people from bothering to learn much of anything, and makes actual professionals job a thousand times harder than it needs to be.

It's a bit like the C language, where first off I'm not convinced this is a joke, but more importantly it seems crafted to make programming look harder than it is. The painfully cryptic syntax (Yeah, I'm a Wirth language guy) that has wormed its way into the norm for nearly every language since seems carefully and methodically planned to make programming as difficult as possible as some sort of L33T status symbol. A far cry from the ease and simplicity of something like Modula or Ada... so bad that if it weren't for the lack of portability, I'd say even Assembler is easier if you have macro's.

Though I'll admit learning RCA 1802 and 8080/Z80 ASM before Pascal or C may have coloured my opinion.

All this lack of emphasis on rules, or how to do things, etc, etc aren't just the antithesis of being a proper specification, it's they type of implementation where if this were architecture every building created would be a "death ray" like the "walkie talkie", or would result in outright disasters like all those beautiful span bridges that collapse with people on them every four years like clockwork. Aka what happens when you let an artist under the delusion they are a designer pretend to be an architect.
 

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.

I think you should look again. The explanations are fairly clear. Maybe you're looking for something that isn't there, though

Yeah, emphasis on semantic meaning. IT's not there. The few tags it's even mentioned on in the reference it is buried at the bottom instead of top-center and in your face. Sad when the meaning of the tag grammatically and structurally should be the be-all end-all reason of why you choose any tag other than DIV, SPAN, or A.

most of the new tags don't do anything magical structurally - they're more about adding inherent meaning to markup

If it's "inherent meaning" why do you need a tag for it? IF they don't do "anything magically structurally, why do they even need to exist?" other than as a replacement for all the tables and DIV people used for no good reason and incorrectly since the browser wars?

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.

Sure. In the same way that "on horseback" was a fine way of getting to the next town and "by candlelight" was a dandy way of reading a book at night

Well answer me this, what are these allegedly "structural" tags providing in UA's to users that the existing markup couldn't, or didn't? Not exactly a fair comparison either since it's more akin to comparing a horse (4 Strict) to a bull (5). The horse will get you there faster and probably not fight you anywhere near as much. The horse is also usually not dumb enough to drive itself straight into a tree.

I don't like bootstrap, and I don't respond to straw man arguments, so I'll pass.

Don't see what that's a strawman argument, given it's an excellent example of what happens when people who NEVER embraced semantics, design patterns, logical document structure, or any other aspect of proper HTML go and make one of these idiotic "frameworks", then through propaganda techniques convince others their BS is worth using. Garbage like bootstrap, like W3Fools w3.css, like blueprint -- and even further up the food chain like react and vue.js -- are a direct result of a lack of anything that a proper engineer would call a specification, a lack of emphasis on why HTML even has tags in the first place, and a general reek of ignorance amongst not just beginners in the field, but most of the alleged "experts" shepherding them.... right into the slaughterhouse once there's nothing left to fleece.

[John_Betong]

There's something wrong with HTML 5?

In a nutshell I find that:

• HTML5 is good
• syntax more lenient than HTML_STRICT
• https://validator.w3.org/ is very good
• additional tags and/or features are not compulsory
• a complete validated source page script is shown and can be downloaded
• DO NOT TRY TO IMPOSE YOUR OWN SYNTAX IR PARAMETERS

[Jason Knight]

syntax more lenient than HTML_STRICT

You say that like it's a good thing. It isn't. Loose syntax makes people more likely to make mistakes, and to be dismissive of mistakes. It also fails to provide a clear guide of how things SHOULD be done nor does it enforce good practices. By its very nature loose syntax is what makes bad programmers make worse mistakes, and it's why really good languages -- like ADA -- and learning languages -- like Pascal -- do not allow it!

What's the old joke about shooting yourself in the foot with programming languages?

C: You shoot yourself in the foot.

Pascal: the compiler won't let you shoot yourself in the foot.

There's something wrong with HTML 5?

additional tags and/or features are not compulsory

They are however pointless redundancies, more to learn, and lead beginners astray before they even have the slightest notion what logical document structure even is. Concepts that once you realize why HTML tags exist, should at least be familiar to anyone with at least a 5th grade education... or at least what I got for a fifth grade education in the '70's.

a complete validated source page script is shown and can be downloaded

Not sure what you even mean by that.

Mind you, HTML 5 does bring some good things to the table, but for every good thing there are two steaming piles of dung that had zero business being added to HTML in the first place. It's carte-blanche to make development a wild west show where nobody really seems to have the first blasted clue what HTML is even for, much less how to use it right.

Which just makes everyone's life harder, EVEN if they don't realize it. Hence why the natural design patterns of HTML and CSS largely go unused, whilst people just "throw more code at it" in the form of such mental derpitudes as "frameworks".

[mmerlinn]

• syntax more lenient than HTML_STRICT

Unambiguous communication of any kind, especially with computers, REQUIRES precision defined by HIGH standards.

[John_Betong]

@John_Betong
>>> syntax more lenient than HTML_STRICT

You say that like it's a good thing. It isn't. Loose syntax makes people more likely to make mistakes, and to be dismissive of mistakes. It also fails to provide a clear guide of how things SHOULD be done nor does it enforce good practices. By its very nature loose syntax is what makes bad programmers make worse mistakes, and it's why really good languages -- like ADA -- and learning languages -- like Pascal -- do not allow it!

I find that HTML5 is easier to write web pages and has some good tools for checking. Far better to be easier so that it opens the doors to beginners and hopefully they learn by their mistakes. Don;t forget we were all "Hello world" noobies once upon a time.

Pascal: the compiler won't let you shoot yourself in the foot.

As fat as being strict is concerned have you tried compiling Golang? It is so strict that even functions and variables which are declared and not used halts compilation! 

@John_Betong
>>> additional tags and/or features are not compulsory
They are however pointless redundancies, more to learn...

Have you tried or use all the PHP functions?

https://www.php.net/manual/en/indexes.functions.php

and then compare with number of Golang functions

@John_Betong
>>> a complete validated source page script is shown and can be downloaded
Not sure what you even mean by that.

Running this forum site through the CSS w3.org validation service not only highlights all errors and warnings it even shows validated source code which can be simply copied and pasted.

I think you should at least give it a try rather than waiting until you are not busy with paying customers and have time on your hands to complete the laborious refactoring task.

https://jigsaw.w3.org/css-validator/validator?uri=https%3A%2F%2Fforums.cutcodedown.com&profile=css3svg&usermedium=all&warning=1&vextwarning=&lang=en