As a standard that never really throws anything away, I wonder if, for certain applications, HTML has outlived it’s usefulness.
The web applications we build tomorrow look to contain fairly sophisticated graphical effects and the like, but I’m wondering how much processing time is wasted by the browser trying to allow for all sorts of markup.
I mean, nothing ever goes away in HTML, and the browsers that have the worst mistakes in their history - the IE family - has been plagued with the effects of shedding off options never part of the standard. But the standard itself has had trouble shedding off things that were a bad idea or have been eclipsed, such as the layout tags <center><font> et al, or the frameset tags.
In the end we have 6 core machines just barely providing better performance than machines from 12 years ago to a degree because of the outright crap the browsers must sort through to get to valid code.
And the problem is compounded by the fact that when a site fails to display most users blame the browser (if they are aware of what a browser is). This dates back to the first web war between Netscape and Microsoft. Every browser wants to be the hero - reading through the code and bending over backwards to try to resolve and execute at least some of the bad code.
XHMTL was supposed to fix this with a stricter syntax, but Microsoft’s failure to implement it correctly stillbirthed it and made it a joke.
HTML is with us and will be here to stay for a long while, but I can’t help but wonder if it should be left behind by professionals in favor of a stricter markup language that has an emphasis on the speed by which the browser can parse it - the result being driven by two factors. First, version numbering that means something - and major version numbers of the standard have NO obligation to be backwards compatible so that there is a mechanic to remove bad ideas from the standard (Cause face it, in 20 years someone is still going to be putting <center> tags in the webpage).
This would unlock a lot of processing power wasted on HTML’s shortcomings, ambiguity and bloated state that is, frankly, NEVER going away. Maybe its snobbish of me to say so, but HTML should be left to the amateurs who dabble on the web and professionals whose livelihood depends on accurate and faster results should get a markup language that delivers that speed. Similar enough to HTML not to be a pain to learn, but unforgiving in its parsing such that if you don’t close a tag that should be closed, you don’t get a page, and so on.
The world needs both. I wouldn’t have learned what I have if HTML was unforgiving and difficult to use. But I have progressed beyond such childish coddling and now it’s getting in my way. I’d love to have a markup language that doesn’t display until it’s valid. I’d love to have a scripting language that allows me to set a variable’s datatype as needed and which doesn’t contain legacy calls to support half a dozen technologies no one uses anymore.
At some point I think the legacy garbage in HTML is going to stifle it’s growth to the point where this divorce between amateur markup and professional markup will be forced.
As for the drop of version number of HTML, this is VERY dangerous. It is a return to the situation as it was in 1996. If HTML doesn’t have a version number then people will begin to code to browsers again. With no milestones version numbers to mark features that can be expected to be found across multiple browsers, we will see a return to the days of “Site best viewed in [insert web page owner’s pet browser here.]”
While browser implementation of standard versions has never been perfect, it gave you a ballpark estimate of which browsers would run the page. Without the version number it becomes a blind guess.
