January 22nd, 2016
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: firstname.lastname@example.org
I posted this to Hacker News. I was surprised that someone did not immediately understand what I meant when I referred to HTML as the GUI of TCP/IP. Someone had surveyed 80 frontend designers and found they lacked basic knowledge of HTML and CSS. I responded:
The contrarian argument is that this signifies an important truth, that HTML never worked the way it was suppose to. In the same way that we might argue that a misunderstood product is the fault of the designer, not the user, we could argue that developers moving away from HTML is the fault of HTML, not the developers.
This has been discussed many times, both here on Hacker News as well as elsewhere. To recap that argument, HTML started life with 2 competing and conflicting goals. One goal was to become a GUI for TCP/IP packets. The other was to provide structured information, as SGML had done for publishing.
The conflict was obvious by the late 90s, and then for awhile the good folks at W3 thought that XML would provide the answer. And XML did work at providing structured data, much as SGML had for printing (though the criticism arose that attributes should have been left out of XML, as they were only useful for printing). But when XML was stretched to again try to be a GUI for TCP/IP, the system broke.
Somewhere around 2006, Sam Ruby (W3C working group co-chair) shared a wonderful anecdote on his blog that revealed how broken XHTML was. He said that he had sent his daughter an SVG image, and she wanted to share it with her friends on MySpace. But she couldn’t. Because MySpace was not XHTML compliant, and SVG could only render on XHTML compliant pages. And yet if he had sent her a gif or a jpeg, she would have been able to share it. Draconian error checking might be great for an information exchange system such as XML, but it did not work for a GUI that had to be somewhat informal.
In 2004 Mark Pilgrim wrote the great piece “XML on the Web Has Failed”:
Now it is 2016. We are looking back at 25 years of failed experience. We can clearly see that HTML and XML both failed, completely, as GUIs for TCP/IP packets.
So developers are being rational. They are “voting with their feet” (actually their minds). They don’t learn HTML because they know HTML has failed.
But HTML has failed, and it is good that developers recognize that.
After I posted this, someone responded to me:
I’m not sure I understand what you mean by a “GUI for TCP/IP” yet it seems central to your argument. I didn’t realize HTML was ever intended to be anything other than structured information.
So I explained myself further:
You have never seen HTML used to build something that a human might look at? What are you looking at right now? Aren’t you looking at a web page? Aren’t you human? Aren’t you using your eyes to see what I’ve written? Unless you “View Source” on every page you visit, you are looking at the GUI, not the structured information.
If you think HTML can be used to send structured information, I would urge to read the essay that Mark Pilgrim wrote in 2004. I posted the link before.
Also, please consider all the many arguments that Sam Ruby has made against HTML-as-structured-data. From 2005 forward, there were many people who wanted HTML5 to be an extension of XHTML, but as Sam Ruby kept asking “Why should we call something XML if it is clearly not XML?” Over the years, in his role as co-Chair of the W3C working group, he kept making the point that “draconian error checking” is part of the XML spec, and it can not be reconciled to people’s actual use of the Web. That is why HTML5 relaxed all the rules regarding validation and structure.
This is Sam Ruby in 2009:
“So, while I doubt that I will ever understand why there are people who insist on calling their pages they produce with the intention of being processed as HTML by the name “XHTML”, I can’t deny that there clearly is something that such people want. (By way of comparison, I am quite happy to say that this page is served as XHTML to browsers that support such, and as HTML to browsers that don’t). From my experience, this is tricky stuff, and not something that should be recommended lightly.)”