- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 27 Apr 2007 13:48:29 -0700
- To: Gareth Hay <gazhay@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
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