The Coming HTML Flame Wars

I like to read the blog Joel on Software and he recently published an article “Martian Headsets” where he talks about the upcoming IE 8 and the decision the development team is trying to make about how to render legacy documents and not have people think a page is broken while still supporting web standards. Not a good problem to have and Microsoft will probably take heat for whatever decision they make, primarily because they are Microsoft. So now, since I love the smell of my scorched flesh from responding to flame wars like this, here’s my 2 cents for all of those two readers out there, or at least I hope I have readers.

First off, I believe the analogy that Joel is trying to use is flawed. He is comparing the API for a Martian MP3 player to the API that specifies HTML. He goes into a long description of the development of headsets and keeping backwards compatibility while adding new features and how all these vendors are causing problems.

In reality, I don’t see the problem as the headset or the player. The problem lies with the songs or in the case of the web, with the HTML pages. And making sure that an HTML document specifies a doctype at the top isn’t going to help one bit. If authors did stick only with HTML tags dealing only with text, pages from the early 90’s are going to display just as well as pages developed sometime last month. And if you go the Wayback Archives and randomly select a page from say 1997, I would guess that other than some problems with some images, you should be able to view that page and make sense of it no matter what modern browser you use.

Where the problem creeps in is with two small tags contained within HTML that can suddenly render a page useless in one browser while having it look great in another browser. The two tags are script and style. And the reason that these tags cause problems is that they are a loop hole that allow developers to do more things within a browser without having to use only boring HTML only type tags. Suddenly the world opens up and developers are given more control over what appears in the browser and they were able to make it more like a desktop application.

However, there wasn’t just one browser development team adding in features, there were two primary ones. And this is where problems developed. In order to try and gain a competitive edge, each company added in features using the script tag that weren’t going to be immediately supported in the other browser. And here’s the thing, unless they chose to follow some other standard within the script tag, there is nothing in the HTML standard that is going to prevent them from exploiting that loophole. If they choose to add in code into their browser that can render a holographic laser image singing “God Bless America” in your browser, the current standard won’t stop them.

And because developers of web pages thought the functionality was either cool, easy to implement or both, web pages got developed that worked only in one browser. Other browsers may choose to implement the same functionality, but that won’t help you as you look at the gibberish in Sanskrit that is scrolling across your screen instead of the dancing hologram while you are waiting for version Next.

Now someone comes along with an idea that specifying a tag at the front of the HTML will help in straightening out the mess and clarify what type of HTML should be displayed. The problem is that most of the HTML isn’t the problem. It’s all the dynamic interaction and the display of the data that is causing the problem. And the loophole still exists that will allow someone in the future to add dynamic capability in one browser that won’t work in the other browser. So long as a tag like script exists in HTML, there is going to be a loophole and someone is going to try and push the edge of the development. That isn’t necessarily a bad thing, but it is an annoying thing for web developers and for users.

Myself, in thinking it over, I’m glad there is a loophole. If there hadn’t been, we wouldn’t have the rich variety of pages that we do now or they would all be flash type pages or applets that weren’t necessarily changing how developers view the problem of developing for the web. And as far as the IE 8 developers at Microsoft, I’d say go ahead and put in the doctype tag but understand that it only applies to the tags themselves and not necessarily what is contained within those two tags, script and style.