Is HTML5 based on false assumptions?

The transition from existing to future Web technology needs to be smooth or the Web could break. When HTML5 was conceived, it was taken for granted that the future specification (i.e. the language itself) needs to be backwards and forwards compatible. All design decisions in HTML5 are influenced by these two assumptions. If these assumptions are false and there are better alternatives for a smooth transition of the technology, is HTML5 a big design mistake?

The backwards compatibility false assumption

Backwards compatibility is when new Web browsers are able to render old Web pages. The authors of HTML5 falsely assumed that it is the specification (i.e. future markup language) that needs to be backwards compatible, when in fact user-agents can be made backwards compatible. So specifications don't need to be backwards compatible if future Web browsers are backwards compatible by supporting old and new specifications.

The forwards compatibility false assumption

Forwards compatibility is when old Web browsers are able to gracefully accept new languages written to new specifications. The authors of HTML5 falsely assumed that it is the specification (i.e. future markup language) that needs to be forwards compatible when in fact it is better to manage forward compatibility by phasing out old technology and creating tools to transform new languages into old ones.

Old Web browsers do not need to be supported forever. The passage of time makes forward compatibility a temporary issue. For example, does anyone test Web pages in Netscape 4 or Internet Explorer 5 anymore? No. So forward compatibility of Web technology is a matter of managing the phase out of older browsers.

HTML5 achieves forwards compatibility by causing old Web browsers to ignore new elements or fools them into treating these new/unknown elements as elements that they know. There are other options. One solution is to transform future languages written to new specs into old languages, using technology similar to XSLT. This feature can be added to future Web servers and can be made transparent to most users. Alternatively, such a feature can be added to existing Web browsers right now, in order to make them forwards compatible, while the really old browsers that lack this feature will be naturally phased out by the time that the new specifications are ready.

So specifications don't need to be forwards compatible if there is a temporary way to transform languages written to new specifications into old languages.

Why have these false assumptions been made?

The authors of HTML5 are smart guys, so why have they made false assumptions? The only explanation that comes to mind is that this is happening because only one group of stakeholders in future Web technology (the browser vendors) is steering the decisions that will evolve the Web. When this happens, you limit your options and get tunnel vision. The browser vendors only have one tool in their mind - the browser - and when you only have a hammer, everything looks like a nail.

The consequences of false assumptions

Backwards and forwards compatibility is a principle that keeps the Web from breaking. But there are multiple ways to achieve backwards and forwards compatibility. Using the specification (HTML5) to achieve compatibility puts significant constraints on the innovation of future Web technology. Because of this, current problems with HTML cannot be fixed in HTML5. No significant semantics can be added to HTML5. No extensibility can be added to HTML5. New accessibility features cannot be added to HTML5. HTML5 cannot be made more secure.

It's time to do a project evaluation of HTML5

A project evaluation is a way to objectively assess HTML5, determine if it is producing the desired outcome, and if it is the correct way forward. So, let's use this method to re-examine the assumption that the specification should be backwards and forwards compatible. Are there better alternatives? Let's have a real conversation amongst all stakeholders about all the options available to improve Web technology without breaking the current Web. Let's examine how all stakeholders in future Web technology can help manage the transition from the old to the new Web.

Public comments

1. Posted by Jason Grant
on Tuesday 2009-11-24 at 04:23:02 PST

Very good point. I agree totally. I think the world has come to a point where a significantly better version of HTML should be speced out, rather than trying to patch up old and outdated stuff.

One of the big paradoxes with HTML5 even is the fact that patchy (or non existant) support from IE means that the spec itself is not as widely supported as HTML5 spec authors tend to portray around the web.

Ah well ... seems like we are likely to be on XHTML1.0 Strict for a while yet.

2. Posted by Rimantas
on Tuesday 2009-11-24 at 06:49:02 PST

That's a good example of a blog post written on false assumptions: I mean YOUR false assumptions about HTML5.
How about taking some time to read the spec?
First point: the spec describes how to parse markup, even invalid markup in consistent manner, which was not addressed in the previous specifications.

Forward compatibility: this is complete bullshit. I am not even sure what are you talking about there, but it looks like you are going to convert entire web as it exists today to some new markup? Good luck with that.

"Why have these false assumptions been made?" They were not. You just made this stuff up, it has little to do with HTML5 itself.

"The consequences of false assumptions" — another load of bullshit. Have you heard about video? Canvas? ARIA?

"It's time to do a project evaluation of HTML5". Indeed. Go spend some time reading the spec, and less writing nonsenses.

@Jason Grant. Funny you say that. Are you aware, that IE does not support XHTML even in the lates version?

3. Posted by Martin Kliehm
on Tuesday 2009-11-24 at 07:58:54 PST

Sorry Vlad, I have to disagree. You say that forwards compatibility is not required because HTML5 could be rewritten on the server side to HTML4. That's a false assumption because the requirements cannot be detected and because it doubles the amount of work:

1) How would you detect which HTML version is supported by the browser? User agent sniffing frequently fails.

2) You suggest to rewrite HTML5 to HTML4 using XSLT. Even if (1) wouldn't technically prevent this, it would require a site-specific XSLT and different CSS for styling the content. That's *a lot* of additional work that nobody wants to pay for. So I'm afraid you can't avoid graceful degradation, not breaking older browsers as long as they are relevant.

Cheers,
Martin

4. Posted by Vlad Alexander
on Tuesday 2009-11-24 at 09:22:16 PST

Rimantas wrote: "the spec describes how to parse markup"

This should have been done in a W3C Note because only a small number of tool vendors are interested in this.

Rimantas wrote: "... it looks like you are going to convert entire web as it exists today to some new markup"

No, the opposite - temporarily convert new/future languages into HTML 4.

Rimantas wrote: "Have you heard about video? Canvas? ARIA?"

This is supposed to be major innovation?

Martin Kliehm wrote: "How would you detect which HTML version is supported by the browser?"

Detection is easy. Future specs should have their own MIME types. So any request with MIME type "text/html" will transforms future markup into HTML4.

Martin Kliehm wrote: "You suggest to rewrite HTML5 to HTML4 using XSLT ... it would require a site-specific XSLT"

No, it would not require site-specific XSLT because there are very few ways that you can transform new markup into old. The XSLT could be generic and would be built into the Web server. This is similar to the Save As feature in Word 2007 when saving to Word 2000 format - there is only one practical way to do this.

Martin, I am suggesting using transformation approach as a temporary/transitional measure because it would be an acceptable trade-off for significant innovation in how the Web works. In any case, we should be exploring all the options to innovate the technology of the Web.

5. Posted by NatalieMac
on Tuesday 2009-11-24 at 14:21:53 PST

There was a sort of revolutionary spec that assumed a perfect world and attempted to rewrite HTML from the ground up. It was called xHTML 2 and it was abandoned in favor of the more grounded and more real world spec called HTML 5.

You've got billions if not trillions of web sites out there, and no inconsiderable amount of them were and are produced by inferior WYSIWYG technologies by people with little or no understanding of specs or the way the web works.

I think you want a huge revolution in web technology and what you're getting is a more gradual evolution of the technology - though you have to admit, the pace of change is still moving along at a good clip. There *is* innovation. I see HTML 5 as giving us better ways to do many of the things people are already doing - things that the creators of the HTML 3.2 and HTML 4.0 and xHTML 1.0 specs didn't even dream of. Maybe the real innovation isn't on the spec side but by the people building the web, and then the specs have to catch up.

6. Posted by Breton
on Tuesday 2009-11-24 at 14:45:38 PST

Natalie is right. What you're suggesting is essentially XHTML 2.0, and that was already tried, and it failed.

If you want to write an XHTML 2.0 browser though, go ahead, be my guest. I eagerly await your far superior solution to sweep the web by storm. I will check back in a year to see how you are progressing.

7. Posted by Vlad Alexander
on Tuesday 2009-11-24 at 16:46:26 PST

Breton wrote: "What you're suggesting is essentially XHTML 2.0, and that was already tried, and it failed."

Are those the only options - pursue the mismanaged policies of XHTML 2.0 or repeat the failures of HTML? Here is what I suggest and which has not been tried before: we start with a list of features we want the future Web to have, bring on board all those who have a stake in the future of Web technology, and then determine the best path to take in order to achieve these features.

8. Posted by mattur
on Friday 2009-11-27 at 04:13:17 PST

This article does not provide any evidence to support your claim that HTML5 people are operating under false assumptions. You just assert it's true, then argue that your opinions are better than theirs "in fact" because of this.

Could I disprove your opinions by baselessly asserting that you are making false assumptions? Or would you find that a pathetically weak and deeply unconvincing way for me to disagree with you?

Just because someone believes option A is the best (or least worst) option does not mean they think option A is the only option. They may think option B has already been tried and failed comprehensively, for example. Or they may think option B will take over at some point in the future, but option A offers important benefits in the meantime and should be pursued for that reason.

Nothing is stopping you from working on your alternative vision for the future-web. What we will absolutely not tolerate though, is you lot freezing the current-web for another 12 flippin' years while you do so... ;-)

9. Posted by Vlad Alexander
on Friday 2009-11-27 at 11:01:47 PST

mattur wrote: "Just because someone believes option A is the best (or least worst) option does not mean they think option A is the only option."

My statement is based on the actions of the HTML5 team rather than their personal thoughts. As far as I am aware, the HTML5 team has not had a comprehensive and public discussion about all the possible ways to transition from existing to future technology.

mattur wrote: "Nothing is stopping you from working on your alternative vision for the future-web"

This would result in creating the same problem that the browser vendors are creating now - a specification conceived and controlled by one group of people that ignores the needs of other groups. Future Web technology must be designed in co-operation with all the stakeholders in the future Web technology.

Comments are closed for this article.

Rebuilding The Web