HTML5: The Battlefield Remains of an Unnecessary War, Part 6

Discussion Point 3: When Things are Fucked Up, It Usually Starts At the Top.

Another problem with tracing is that you may end up losing focus on your original intent.  You started off wanting a full circle, but your trace left you with an elliptical pattern.

At the top level of any HTML 5 document are three elements: HTML, HEAD, and BODY.  According to the HTML 5 specification, paragraph 4.1.1.(The html element):

The html element represents the root of an html document.

Additionally, the XML 1.0 (Fifth Edition) specification, paragraph 2 (Documents) states:

A document begins in the “root” or document entity.

This makes good sense when you consider that the W3C was steering the web towards a more strict and extensible means of using markup. In this case, the two specifications are cooperating.

Here is where things begin to fall apart for the W3C in their endeavor to trace the work of the WHATWG.

The html element neither has any strong native semantics nor ARIA role assigned to it.

Instead, the W3C assigns the ARIA role DOCUMENT to the body element. Wait a minute. Within the same specification, the W3C states that the html element is the root of an html document, but at the same time assigns the DOCUMENT role to the body element.

But that’s not all. Here is what the ARIA 1.0 specification has to say about the DOCUMENT (role) (third paragraph):

Authors SHOULD set the role of document on the element that encompasses the entire document.

At this point the ARIA specification agrees with XML 1.0 and the definition of the html element in HTML 5, but soon detours when trying to conceal a recognized fuck up:

If the document role applies to the entire web page, authors SHOULD set the role of document on the root node for content, such as the body element in HTML or svg element in SVG.

The root node for content? When did we start recognizing a root node for content? The html element applies to the entire web page; the body element does not. The W3C appears to be looking for any way to make something simple complicated.

Here’s why assigning the DOCUMENT role to the body element doesn’t make sense and this is from the ARIA 1.0 specification discussing how to label a document:

If the document includes the entire contents of the web page, use the host language feature for title or label, such as the title element in both HTML and SVG. This has the effect of labeling the entire document.

The TITLE element is part of the HEAD element in HTML 5. If the title element is understood to label the entire document, then why is the body element given the DOCUMENT role as it is a sibling of the head element?

What is obvious is that whoever decided to assign the DOCUMENT role to the body element was looking at an html document from a visual or presentational perspective. Since the content of the body is what the user sees, then it is the document.

This is wrong, not only due to the W3C’s own specifications, but also due to the fact that the head element contains other information (metadata) important to the same document. Taken as a whole, the head and body element are critical to representing an HTML document.

Just as the WHATWG did with the B and I tags, the W3C has adopted the same “dazzle them with bullshit” mentality by trying to devise some kind of root element for content to justify away a known error.

This is what happens when you base a specification or living standard on no real standard: you end up setting fires all over the place.

End of discussion point 3

HTML5: The Battlefield Remains of an Unnecessary War, Part 5

Discussion Point 2: Inheriting Another’s Imperfections

Have you even ran with a group of runners and, instead of keeping your head up and watching where you were going, you lowered your tired head and kept your eyes on the heels in front of you?

Where did you end up when you finally raised your head?

In developing HTML 5, the W3C decided to lower its head (or kowtow) and follow the heels (pun intended) of the WHATWG. HTML 5 is an example of the mislead leading the misguided or vice versa (the situation is so chaotic).

The original agenda of the W3C during the time of XHTML 2 was to remove all presentational elements from the markup language and create more semantic, or meaningful elements.

When the W3C decided to shelve XHTML 2 and follow the lead of the WHATWG, here is what actually happened:

Former presentational element B (bold) was given not a meaningful, but meaningless description.

Former presentation element I (italic) was also made ambivalent like the B element.

New element MARK is simply an example of a presentational cake given a layer of bullshit icing.

Reading the description of these elements, I cannot help but to recall a often used phrase: If you can’t dazzle them with brilliance, then baffle them with bullshit.

The B and I elements, or tags, have always been used for presentational purposes. No one cared much about semantics or they would have used the STRONG and EM tags instead. No, folks wanted a particular appearance without having to put too much thought into it.

The WHATWG decided to accommodate the lazy coders by using all the intellect at its disposal to come up with descriptions to go over the top of level heads in order to keep junk in the specification. The result is that folks will simply say “F— it!” and, like turds, go with the flow.

The W3C did not have to allow these obvious transgressions against real semantics in the HTML 5 specification, but (like I said before about tracing) they became so caught up with following the HTML Living Standard, that they were led into a meaningless wall.

Take a look at this excerpt from paragraph 4.12.4 (Conversations) of the HTML 5 specification:

Authors who need to mark the speaker for styling purposes are encouraged to use span or b.

The brilliant think tank at the W3C is advising coders to use B for styling purposes. I thought B was made semantic…there were so many words from academia used to redefine it…and now you are telling me to use it for styling?

End of discussion point 2

HTML5: The Battlefield Remains of an Unnecessary War, Part 4

Discussion Point 1: When the Foundation of the Core is 80% Bullshit and 10% Concrete

SGML is a standard.

SGML defines the rules for organizing and tagging documents. Previous versions of HTML (before HTML 4.01 and XHTML 1.1) were based on SGML.

HTML Living Standard from the WHATWG’s camp is not based on the SGML standard. No foundational standard has been declared for this so-called living standard. How can something be a standard when it is not based on a solid standard?

HTML Living Standard is the first level of bullshit.

I remember in art class the teacher telling me not to trace my circles from other students’ drawings. She told me that tracing will inherit the imperfections of something that may already have imperfections.

The computer clock or other consumer timing devices are often based on a standard timing mechanism: the atomic clock. This way, everybody can be synced up properly. If a computer based its timings on its owner’s wristwatch, chaos would reign over the web world.

HTML5 from the W3C is based on HTML Living Standard, which is not based on any known standard (don’t be fooled by the specifications name). Therefore, HTML5 was doomed from its creation to inherit and magnify the imperfections already prevalent in HTML Living Standard.

HTML5 is the second level of bullshit.

No rational thinking person on the face of planet Earth can deny this fact.

End of discussion point 1

HTML5: The Battlefield Remains of an Unnecessary War, Part 3

Preamble

Intellect does not breed wisdom. Proper use of intelligence demonstrates wisdom.

This war between the sluggish defenders of the W3C and the renegades of the WHATWG is not a fairytale. If you examine the different HTML specifications from each camp, you will bear witness to the first shot of pettiness:

Read the history of HTML5 from the W3C’s specification [History].

Read the history of HTML from the WHATWG’s specification [History].

The level of unprofessionalism becomes evident near the end of each camp’s historical account of their specifications.

End of preamble

HTML5: The Battlefield Remains of an Unnecessary War, Part 2

Prelude

To understand this war between the W3C and its usurping members, the WHATWG, consider the well-known television show, Survivor.

Survivor (based solely on my recollection) is a show based on people plucked from their comfortable living conditions and placed in an uncomfortable environment. The winner of the competition, or survivor, is supposedly the person who demonstrated a keen survival prowess and overcame several difficult challenges.

In other words, the winner performed better than the rest.

If you ever watched the show, you will know that this is not the case. The winner is actually decided by the manipulative actions of the weakest challenger and his or her ability to form alliances with other challengers (with questionable self-esteem issues). Backstabbing is the commodity for winning the competition as the winner will have betrayed the trust of every other challenger to end up as the last survivor standing.

Yes, the show is indeed a great lesson in physical endurance and cooperation

End of prelude

HTML5: The Battlefield Remains of an Unnecessary War, Part 1

Prologue

Based on my understanding, the W3C is the host to HTML and its different dialects (XHTML, for example).

A small group of renegades sponsored by major corporations with proprietary interests decided to take a free technology and make it more exclusive than open (whatever the hell open means these days).

In times of war, citizens will have to choose sides, or their choices will be made for them when faced with obstacles as a result of the war. Side with the W3C (with its brigades of sluggish defenders) or the WHATWG (the aforementioned renegades)?

Not being an expert in web technologies nor in business, I tend to search for  fundamental aspects leading to such a turbulent affair. A couple of well-known facts come to mind.

The W3C is a member organization where members actually pay to become a part of.

The parties involved in the WHATWG are members of the W3C.

So, what was the issue surrounding the fracturing of a core technology of the web: the future direction of HTML?

Based on my understanding, the W3C wanted the HTML specification to have a more XML flavor and the WHATWG had other plans in mind. This is where things start to get petty (and I mean that in the derogatory sense of the word).

See, XML requires documents to be well-formed. Not surprisingly, browsers can parse (and subsequently render) a webpage coded in XML faster and more efficiently than those coded in non-X versions of HTML. Thus, XML puts the responsibility of professional webpage coding in the hands of web authors instead of relying on best-guess fixes by browsers.

On the surface, the war between the W3C and the WHATWG seems to be where one side wants to move the web towards a more professional, extensible, and open direction and the other side wants to continue accommodating sloppy coding practices and hard work by the browsers.

But things don’t always appear as they do on the surface, do they?

End of prologue

The W3C: A Consortium of Sluggish Defenders

Recently, I was told that the W3C is nothing but a collection of companies (Google being mentioned specifically).  This came from a gentleman belonging to an accessibility consultant group that has amongst its members a few individuals who have contributed to W3C’s specifications.

The W3C is not an abstraction of the web.  The W3C is simply a collection of individuals…real people.  Some of these individuals represent companies, corporations, and small businesses.  Some may just be experts in a field of interest important to the overall development of the web.

Most of these individuals are sluggish defenders.

What is a sluggish defender?

Sluggish defenders have been around for ages.  You know who they are, but may have referred to them by different labels.

Sluggish defenders are the folks who will celebrate and support a person or idea when things are going well, but cower in silence when faced with adversaries or opposing views.

Are you familiar with the phrase fair-weather friend?

Wait.  This sounds like something from my high school days?

Exactly.  Sluggish defenders tend to follow the popular crowd even when they know it is wrong.  Wanting to be part of the in-the-know-and-hanging-around-the-water-cooler crowd is very important to a sluggish defender.

They will invest time and effort into a product (for whatever reasons) and promote the product initially with pride and joy.  When enough opponents of the product voice their discontent, the sluggish defender will turn tail and run, often denigrating his own product in the process.

I have witnessed this from people involved in the development of RDFa and JSON-LD. (No need for names because particular individuals are not the point of this post).  I have read comments from folks involved in creating XHTML 1.1 and XML 1.1 turning against their own product when encountering others with differing views.

Ok, so they changed their minds and switched sides. No big deal.

Here is the problem.  A sluggish defender has the effect of making pure gold appear as aluminum foil.  Often, sluggish defenders are attacked not with valid arguments or actual corrections, but en masse by those who simply are hanging with the cool guys.

Fear of losing the status of subject-matter expert is what actually motivates the sluggish defender to switch his stance; not intellectual awareness.

At this point, the sluggish defender, as a representative of his own work, has rendered his product ineffective and invalid.  By choosing to remain silent, or cowering in the midst of opponents to gain popularity, the sluggish defender has defeated his own product before it could even make it out the gates.

Don’t believe me?

I challenge you to take a look at the names on specifications coming out of the W3C’s camp.  Then visit the personal pages of some of the editors and contributors.  Observe how some of them will make mention of their contributions to the W3C, especially if they had some direct input into a specification.  Particularly, look at some of the more controversial recommendations (for example, XML, XHTML, RDF, ARIA, and the like).

Visit the forums these contributors frequent and observe their riding-the-fence approach when addressing opposition (Google Plus is one good place to start).

So, what is the W3C?

In theory, the W3C is a collection of subject-matter experts: highly knowledgeable in their related fields, highly professional in their approach to web development, and non-political when it comes to moving the web forward.

In actuality, the W3C is a collection of sluggish defenders: experts at clever witticism, highly knowledgeable of another person’s shortcomings, very unprofessional in their approach to collaboration, and too political to actually get anything done.

Each sluggish defender represents the W3C as a real, physical entity.  Each person who has contributed to and exploited the resources of the W3C represents that brand.

If the W3C was run by Sun Tzu, the web would be decades ahead of schedule.