- From: Matthew Ratzloff <matt@builtfromsource.com>
- Date: Mon, 12 Mar 2007 10:00:10 -0700 (PDT)
On Sun, March 11, 2007 7:57 pm, Ian Hickson wrote: >> The Web has done great so far without it? When "strict" mode was >> introduced, all existing websites didn't suddenly start rendering under >> it. It was opt-in. Versioning is just a formalized way of opting into >> a certain rendering method. > > Strict mode isn't versioning, per se; it's a toggle between two modes > which was basically required to get around the problem of the standards > not lining up with reality and the browsers being unable to both comply to > standards and render legacy content. It's tempting to think that browser makers will get it right the first time, but I'm not sure I believe it. <!DOCTYPE HTML> might introduce headaches when Microsoft or Mozilla or somebody realize they've had a bug in their rendering engine for a couple of years that people depend on now. Does that DOCTYPE now become <!DOCTYPE HTML STRICT>? What happens then when HTML 6 is introduced? > HTML5 doesn't need such a rendering mode flag because it doesn't introduce > incompatibilities (by design). Sure, but can you guarantee that also for HTML 6, HTML 7? > As a rule, versioning is a very bad design strategy. Implementors are > forced to support every version that is used by content. If versions are > different from each other, then that basically means a new implementation > per version. If there are five versions, then browser vendors end up > having to support five browsers instead of one. Given how much difficulty > browser vendors have supporting just the one browser (or one-and-a-bit, > with quirks mode), I would hate to force them to support, over the years, > dozens of different versions. Versioning is a great strategy if implemented well. Any reasonable implementation would have a base rendering engine and then browser differences would extend off of it. A new version would mean you change only what differs between versions. Like products, browser makers could set a cut-off date for new support requests for older versions of HTML. For example, when HTML 7 comes out, browser makers wouldn't be obligated to correct HTML 5-specific bugs anymore. They would support, at most, maybe two versions (one primary, one secondary). In effect, I'm suggesting a structure like this: --Base rendering engine | +- HTML 4 quirks mode +- HTML 5 (renders HTML 4 strict as well) -Matt
Received on Monday, 12 March 2007 10:00:10 UTC