W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Support Existing Content

From: Elliott Sprehn <esprehn@gmail.com>
Date: Fri, 27 Apr 2007 17:16:04 -0400
Message-Id: <AD3D1F87-62BF-4E04-9140-163A79B5194A@gmail.com>
Cc: Henri Sivonen <hsivonen@iki.fi>, Lachlan Hunt <lachlan.hunt@lachy.id.au>, Doug Schepers <doug.schepers@vectoreal.com>, public-html@w3.org
To: Gareth Hay <gazhay@gmail.com>
On Apr 27, 2007, at 10:48 AM, Gareth Hay wrote:

>
>
> On 27 Apr 2007, at 15:35, Henri Sivonen wrote:
>
>>
>>> Surely any browser manufacturer is always going to have a mode  
>>> that will render older pages.
>>> What is preventing them having an HTML5 mode, which may or may  
>>> not build upon their previous engine.
>> ...
>>> Why is this a problem?
>>
>> The problem from the browser vendor point of view is the increased  
>> cost of code development and the increased cost of quality assurance.
>>
> Ok, I 've asked before, so I'll ask again, how?
>
> option 1.
> Add HTML5 on top of current code, adding more complexity to current  
> code base.

As I understand it the Webkit, Gecko and Presto engines all are  
manageable at this point. The very quick implementation of HTML5  
features in Opera proves that its not an insurmountable task to  
extend them. We can't speak for Trident since we don't have the code  
and conjecture of its capabilities in the context of what we can  
suggest in this spec just sets up big road blocks.

Regardless it has already been proven that the current browser  
engines and their developers are capable of implementing the new  
features without succumbing to some complexity barrier.

>
> option 2.
> stop existing code. Begin HTML5 parser (starting from what we have,  
> but forking)

I'm pretty sure this would be much more expensive in terms of the man  
power, implementation time and the amount of testing required since  
now everything has to happen in two (or more) places. No browser  
vendor can cease to fix bugs or add extensions in the older engine,  
certainly not considering how wide spread HTML4 is.

>
> I don't see either being a signifignatly different cost.
>

I do, and you also missed #3. For a new hypothetical browser vendor  
to have to implement Quirks, Almost Standards, Standards and HTML5  
modes is going to raise the cost of entry for the new browser vendor  
incredibly high. They have no existing code base to fork.

We already have that problem now with how complicated supporting web  
content is, and adding more modes just exacerbates the problem. If  
HTML5 engines can parse and render HTML4 we can avoid making this worse.

In short; I definitely support the "Support Existing Content" principal.

- Elliott
Received on Friday, 27 April 2007 21:16:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:53 GMT