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

Re: Support Existing Content

From: Maciej Stachowiak <mjs@apple.com>
Date: Fri, 27 Apr 2007 13:48:29 -0700
Message-Id: <2C195D85-2286-41E9-B17F-7C8D7845BDCD@apple.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 7: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.
>
> option 2.
> stop existing code. Begin HTML5 parser (starting from what we have,  
> but forking)
>
> I don't see either being a signifignatly different cost.

The biggest cost differences are not in initial development but in  
testing and ongoing maintenance. You have the following costs per mode:

- Initial qualification testing has to be done for each mode
- Ongoing maintenence cost for things like crashes and hangs
- Q/A for updates has to be done for each mode
- Each separate mode is additional potential surface area for  
security bugs
- Any change that might affect multiple modes is harder to do and  
more error-prone

I think the fallacy in your argument is really that "stop existing  
code" is possible. As long as you are shipping a code base, it has  
ongoing maintenance costs.

Regards,
Maciej
Received on Friday, 27 April 2007 20:49:28 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:43 UTC