[whatwg] Using the HTML5 DOCTYPE as a new quirksmode switch

Mon Mar 12 10:00:10 PDT 2007

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