Last Comment Bug 1312 - "Standard" compatibility mode needs to be hooked to DOCTYPE
: "Standard" compatibility mode needs to be hooked to DOCTYPE
(py8ieh:snarf test cases for eviltest...
: css1
Product: Core
Classification: Components
Component: HTML: Parser (show other bugs)
: Trunk
: x86 Windows 95
: P2 normal (vote)
: M14
Assigned To: rickg
: Jan Carpenter
: Andrew Overholt [:overholt]
: 2072 (view as bug list)
Depends on:
Blocks: 2749 html4.01 8780 34662
  Show dependency treegraph
Reported: 1998-11-08 13:28 PST by Angus Davis
Modified: 2008-10-22 01:03 PDT (History)
12 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

HTML snippet that shows which mode you're in (change the doctype to test...) (496 bytes, text/html)
1999-09-26 21:05 PDT, David Baron :dbaron: ⌚️UTC-10
no flags Details
Proposed patch (2.61 KB, patch)
1999-11-27 04:00 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Splinter Review
Proposed patch: inserting a space character (763 bytes, patch)
2000-02-18 06:04 PST, Masatoshi Kimura [:emk]
no flags Details | Diff | Splinter Review

Description Angus Davis 1998-11-08 13:28:16 PST
A DOCTYPE of HTML 4/5/etc. should make compatiblity mode work. Currently the
only way to enable compatibility mode is in debug builds through a menu item.

Also, for cases where changing the DOCTYPE isn't appropriate, we should support
a "META" tag for accomplishing the same thing.
Comment 1 cpratt 1998-12-02 12:02:59 PST
*** Bug 1562 has been marked as a duplicate of this bug. ***
Comment 2 leger 1999-02-03 08:09:59 PST
Setting all current Open/Normal to M4.
Comment 3 Paul MacQuiddy 1999-03-05 23:12:59 PST
per leger, assigning QA contacts to all open bugs without QA contacts according
to list at
Comment 4 Jan Carpenter 1999-03-10 13:41:59 PST
reassigning qacontact to gem (HTML Parser)
Comment 5 rickg 1999-05-14 15:21:59 PDT
*** Bug 2072 has been marked as a duplicate of this bug. ***
Comment 6 Hixie (not reading bugmail) 1999-05-17 16:47:59 PDT
Bug 2072 pointed to these test pages:
Comment 7 Hixie (not reading bugmail) 1999-05-26 06:28:59 PDT
Note. This is currently making QA of standards compliance issues difficult
(eg, verification of bug 2749 is awaiting doctype-controlled compat mode).

Also, a DOCTYPE of HTML 4/5/etc. should make _standard_ mode work. It is an
HTML _3_ DOCTYPE that should enable compatibility mode.
Comment 8 Matthew Tuck [:CodeMachine] 1999-08-05 03:16:59 PDT
This is currently marked M10, but knowing how bugs slip milestones, I'll say
that I don't think a beta should go out without this, since if it's introduced
later, you might get more people complaining you've broken their HTML 4 pages by
not having quirks mode, while it worked in previous versions.  This should
really be P1 I think, since the longer you delay the harder it will be to
Comment 9 Nicholas Cull 1999-08-28 19:05:59 PDT
This should include the new HTML 4.01 DOCTYPE (assuming the spec gets past
the proposed recommendation stage):


See for details.
Comment 10 David Baron :dbaron: ⌚️UTC-10 1999-09-01 11:48:59 PDT
The following FPIs should definitely trigger strict mode:

"ISO/IEC 15445:1999//DTD HyperText Markup Language//EN"
"ISO/IEC 15445:1999//DTD HTML//EN"

"-//W3C//DTD XHTML 1.0 Strict//EN"
"-//W3C//DTD XHTML 1.0 Transitional//EN"
"-//W3C//DTD XHTML 1.0 Frameset//EN"

"-//W3C//DTD HTML 4.01//EN"

And probably in
"-//W3C//DTD HTML 4.0//EN"

How will this be future compatible?  Should you, instead, compile a list of
known other doctypes and recognize any doctype not on that list (or none at all)
as quirks, so that all new doctypes will be standard mode?  If you want to do
this, I could help compile the list.

I think you should decide on this soon and annouce it very publicly.
Comment 11 Hixie (not reading bugmail) 1999-09-01 17:12:59 PDT
David, your last-but-one paragraph makes no sense. :-)
Comment 12 David Baron :dbaron: ⌚️UTC-10 1999-09-01 17:48:59 PDT
It makes perfect sense to me.  :-)   For others, it might help if you change
"known other" to "other known" and remove the "not" in the second line.

What I was saying is that since there are all sorts of quirky doctypes out
there, but anything that's new should probably be standard mode, we might want
to do the recognition based on:
 * quirks if no doctype or an old doctype
 * standard if new/unknown doctype
but this would require a really good list of "old" doctypes since there are some
weird ones floating around.
Comment 13 Hixie (not reading bugmail) 1999-09-01 18:20:59 PDT
That's what I thought you meant. I agree (as usual...).

Rick: Which method do you wish to use? If you wish to use the "all known old,
invalid and missing doctypes => quirks, everything else => standard" idea,
which I would recommend, I suggest you say so relatively quickly so that we can
start fielding doctypes from the web.
Comment 14 harishd 1999-09-10 11:16:59 PDT
Assigning bug to myself.
Comment 15 harishd 1999-09-15 13:37:59 PDT
Hooked up parser mode to document DTD mode.

Here is a gist:
 FPIs mapped to STRICT mode are:

  "-//W3C//DTD HTML 4.0//EN"
  "-//W3C//DTD HTML 4.01//EN"
  "-//W3C//DTD HTML 4.0x//EN" (x=>Any number) - Any comments ?
  "-//W3C//DTD HTML 4.0 UNKNOWN//EN" (UNKNOWN could be NOQUIRKS,...etc.,)

Other known FPIs are mapped to QUIRKS mode.
Comment 16 David Baron :dbaron: ⌚️UTC-10 1999-09-15 13:40:59 PDT
To what are *unknown* FPIs mapped?
Comment 17 harishd 1999-09-15 13:43:59 PDT
If HTML 4.0 is not found in the DOCTYPE string then a unknown FPI would be
mapped to quirks.

i.e., "-//W3C//DTD STANDARD//EN" -> This would be mapped to quirks!!
Comment 18 David Baron :dbaron: ⌚️UTC-10 1999-09-15 13:52:59 PDT
You should map the ISO doctypes to strict too, as I mentioned above.
Comment 19 harishd 1999-09-15 17:50:59 PDT
ISO doctypes are hooked up too :)

The following FPIs are also mapped to strict DTD:

"ISO/IEC 15445:1999//DTD HyperText Markup Language//EN"
"ISO/IEC 15445:1999//DTD HTML//EN"

Marking bug FIXED.
Comment 20 David Baron :dbaron: ⌚️UTC-10 1999-09-15 17:52:59 PDT
Does the presence of any of:
 * an XML declaration "<?xml version="1.0"?>"
trigger strict mode?  They should, because XHTML can be sent as text/html.
Comment 21 Hixie (not reading bugmail) 1999-09-26 16:24:59 PDT
I've written a quick script to test this:
It doesn't do XML or alternative mime types yet.

If anyone can think of any things that are affected by compat vs std mode, other
than CSS table inheritance, then please send them to me and I'll add them to the
script's output.
Comment 22 Hixie (not reading bugmail) 1999-09-26 16:38:59 PDT
Something else that triggers NavQuirks is the string "Transitional" in the FPI,
if its an HTML4 FPI. So the following:
   "-//W3C//DTD HTML 4.0 UKNOWN Transitional UNKNOWN//EN"
...triggers Quirks Mode. However, on non-transitional FPIs, the string NOQUIRKS
always triggers standard mode, so the following will be in Standard mode:
   ";sal hasl;dgh sadFG NOQUIRKS sdg;jaadhf ljkerhyt "
Seems ok to me. David?
Comment 23 David Baron :dbaron: ⌚️UTC-10 1999-09-26 21:05:59 PDT
Created attachment 1878 [details]
HTML snippet that shows which mode you're in (change the doctype to test...)
Comment 24 Masatoshi Kimura [:emk] 1999-09-29 01:21:59 PDT
* an XML declaration "<?xml version="1.0"?>"
does not trigger strict mode yet.
I'm using the [1999092808] build on a Windows NT 4.0 (Service Pack 5) system.
Comment 25 leger 1999-09-29 13:13:59 PDT
Clearing FIXED resolution due to reopen of this bug.
Comment 26 Peter Linss 1999-09-29 13:20:59 PDT
All XML pages should ALWAYS be in standard mode. There are no quirks to mimic
Comment 27 David Baron :dbaron: ⌚️UTC-10 1999-09-29 16:47:59 PDT
I believe the issue here is pages sent as text/html (technically HTML, not XML)
that contain an XML declaration or an XHTML doctype.  I agree that these should
be in standard mode.  That is, the XHTML doctypes should be recognized for
standard mode and any HTML page that begins with an XML declaration in
accordance with the XML spec (must it be on the first line, or something, or can
comments be before it????) should also be in standard mode.
Comment 28 Masatoshi Kimura [:emk] 1999-10-02 17:53:59 PDT
Should HTML 4.01 Transitional or HTML 4.0x Transitional trigger standard mode?
I think they should, because these are "new" doctypes.
Comment 29 Hixie (not reading bugmail) 1999-10-05 14:42:59 PDT
Actually, yeah, TRANSITIONAL should always trigger STRICT mode. A good reason
for this is that the CSS1 Test Suite uses the Transitional DTD... :-)
Comment 30 harishd 1999-10-06 14:54:59 PDT
Hooked up DOCTYPES ( all of 'em..I hope :) )

Marking FIXED.
Comment 31 Masatoshi Kimura [:emk] 1999-10-22 07:09:59 PDT
HTML 4.0x Frameset still triggers quirks mode.
Comment 32 Hixie (not reading bugmail) 1999-10-22 23:28:59 PDT
...As do any "transitional" DTDs.
IMHO all HTML4.x DTDs should trigger standard mode, including Transitional
and Frameset.

Comment 33 David Baron :dbaron: ⌚️UTC-10 1999-10-23 07:31:59 PDT
I disagree, perhaps, since some authoring tools may be generating files with
these DTDs.
Comment 34 Masatoshi Kimura [:emk] 1999-10-23 12:44:59 PDT
I think this is the best:
HTML 4.0 Transitional and Frameset: trigger quirks mode.
HTML 4.0 Strict: triggers standard mode.
HTML 4.01 and 4.0x: always trigger standard mode.
Comment 35 harishd 1999-10-28 20:05:59 PDT
Marking bug FIXED.
Comment 36 Masatoshi Kimura [:emk] 1999-11-27 03:59:59 PST
Mode detection still does not work correctly in some cases.
see the
Comment 37 Masatoshi Kimura [:emk] 1999-11-27 04:00:59 PST
Created attachment 3060 [details] [diff] [review]
Proposed patch
Comment 38 leger 1999-11-29 13:32:59 PST
Clearing FIXED resolution due to reopen.
Comment 39 leger 1999-11-29 14:09:59 PST
Moving to M12 since M11 is over and this has been reopened.
Comment 40 John Morrison 1999-12-16 17:12:59 PST
This may not be the best place this, but ... On the topic of "other" DTDs (FPI?)
I noticed this one: <!DOCTYPE HTML PUBLIC "-//SoftQuad Software//DTD HoTMetaL
PRO 6.0::19990601::extensions to HTML 4.0//EN" "hmpro6.dtd"> in a file.

I don't know if this is HTML 4.0 STRICT, but I would guess it's pretty tight,
since Softquad began as an SGML company.
Comment 41 rickg 1999-12-20 17:41:59 PST
Moving to m14.
Comment 42 fahrner 2000-01-16 18:25:59 PST
If the idea is to phase out Quirks, we're coming at this backwards. Instead of defaulting to Quirks
and establishing conditions for Strict to kick in, we should default to Strict and establish
conditions for Quirks. The problem with the former approach (defaulting to Quirks) is that the list
of conditions for Strict will always be too short and prone to obsolescence as new document
types come into use.

So the default should be Strict, with the following conditions triggering Quirks:
* the document has no doctype (most HTML).
* the document has a doctype in wide use at the time of beta 1. A catalog needs to be made. I
expect that it will have no more than 20 doctypes (2.0, 3.2, IETF flavors, etc).
* HTML 4.0 Strict should not be in the Quirks catalog, even if it is in wide use.
* HTML 4.0 Transitional should trigger Quirks if the declaration contains no URL, and Strict if it
does. This tends to characterize the difference between bogus and trustworthy usage, but is
obviously not watertight. Composer omits the URL. The CSS1 Test Suite uses it. This is a
compromise, of
Comment 43 Hixie (not reading bugmail) 2000-01-17 17:55:59 PST
Todd: I agree. (BTW, your comment was cut short again.)
Harish: What do you think?
Comment 44 David Baron :dbaron: ⌚️UTC-10 2000-01-17 18:03:59 PST
I strongly agree.  Note that I also proposed the idea on 09/01/99 11:48
(above).  I think I feel more strongly about it now.
Comment 45 fahrner 2000-01-18 12:58:59 PST
I don't know why my posts get clipped. It's always been only the last word, btw.

I didn't read carefully enough. Yes, David proposed this first.

I will begin gathering doctypes for the quirks catalog.

This is a bogus sentence; perhaps it will be clipped; perhaps not.
Comment 46 David Baron :dbaron: ⌚️UTC-10 2000-01-24 08:16:25 PST
I started a list of doctypes at:

Any comments?  (I put the potentially controversial items in each list first.) 
I got the list of DTDs from the catalogs of the two known validators.
Comment 47 Hixie (not reading bugmail) 2000-01-24 10:01:40 PST
Looks good.

I would suggest adding the (techically invalid?) FPI "CNavDTD" to the list of 
FPIs that should enable quirks mode. This would be an explicit "enable the 
Compatability Navigator-DTD parsing mode" FPI.

I also suggest that the line which reads:
...should also include:
   o Any 'DOCTYPE HTML PUBLIC "..." SYSTEM "..."'.
i.e., when _both_ an FPI and a URI are given, we should trigger standard mode,
regardless of the FPI.

David, you can probably express that better than me. ;-)

BTW, David, once that document becomes more stable, e-mail it to me and I'll
make each line link to the relevant test case generated by my script.
Comment 48 David Baron :dbaron: ⌚️UTC-10 2000-01-24 12:31:25 PST
Ian - I don't think what you said about SYSTEM makes sense.  At least, judging
from XML, the syntax for the external subset of the DTD comes in two forms:

PUBLIC PubidLiteral SystemLiteral
SYSTEM SystemLiteral

So what I'm saying is that, when it takes the first form, we should ignore the
SystemLiteral (since there are lots of variants, like REC-html40 vs
REC-html40-9712?? vs REC-html40-9804?? vs html4 vs html40 vs html401 vs
1999/REC-html401-9912?? (not to mention the WDs and PRs) in the filename) and
base quirks mode on the PubidLiteral.  When it takes the second form, we should
assume strict mode.  (Should we also assume strict mode if there exists an
internal subset?)


However, I wish I had the SGML syntax handy...
Comment 49 Hixie (not reading bugmail) 2000-01-24 13:24:22 PST
SGML allows these syntaxes (from memory, 'my' copy of Goldfarb is in my room):

   1: PUBLIC PubidLiteral 
   2: PUBLIC PubidLiteral SystemLiteral
   3: SYSTEM SystemLiteral

With case 1, we should use the PubidLiteral to decide Quirks mode.
With case 2, we should IMHO _always_ use standard mode.
With case 3, we should always use standard mode.

The reasoning behind case 2 (which my last comment was trying to make, although
I unfortunately got the syntax wrong) is that the CSS1 test suite uses this 
syntax (IIRC).

In XML mode, we should _always_ assume standard mode. In HTML mode, I don't
believe internal subsets would have any effect, so we should probably ignore
them and not worry about them affecting standard/quirk mode selection.
Comment 50 David Baron :dbaron: ⌚️UTC-10 2000-01-24 16:18:58 PST
(2) can't trigger strict mode in general - I think it's nearly as common as (1),
since it's the syntax recommended by the HTML specs.  That's why the CSSTS uses

Internal subsets are certainly an SGML feature, since XML is a subset of SGML. 
However, they're very rarely used, and they could be a harmless way of making an
old doctype cause strict mode.  (Although I guess there should really be a META
NAME="mozilla-mode" ... or something...)
Comment 51 Hixie (not reading bugmail) 2000-01-24 21:58:13 PST
If we don't use standard mode for (2), then we will show bugs in the CSS1TS 
even though they are there only for compatability. The CSS1TS uses doctypes
in the form:

   <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"

I am not convinced that that DOCTYPE is all that common. Are you sure there are
many legacy pages that use that DOCTYPE? Could you list some high profile ones?
Comment 52 David Baron :dbaron: ⌚️UTC-10 2000-01-25 07:23:39 PST
I think there are a good number of pages that use it.  I'm not sure this is
entirely about high profile pages.  (Could you list some high profile pages that
use DOCTYPEs at all?)  I searched around, and found the following pages with
DOCTYPEs.  They are marked (1) for no SystemLiteral, and (2) for SystemLiteral,

(2) (which uses a custom DTD with a PublicID, which should
perhaps be added to my list...)

There are slightly more (1) than (2), but there are still quite a few (2).  I
don't think we should worry about the CSS1 test suite.  The test suite may well
change in response to Mozilla and MacIE5.

Adding css1 keyword because this bug affects conformance to css1.
Comment 53 David Baron :dbaron: ⌚️UTC-10 2000-02-07 16:59:55 PST
Nominating for beta1 because I think the first beta should have something that
we think will be the eventual solution, so we can get feedback on it.  The
eventual solution will probably need a lot of fine-tuning, so it would be good
to get feedback from the beta.  This is a *very* important issue on which to get
feedback, because it determines many parts of the behavior of the entire layout
Comment 54 rickg 2000-02-08 22:31:46 PST
Note: I've loosened up the rules a bit. As of (my next checkin) ANY doctype that 
reads "HTML 4.xx" AND "transitional" will now render in quirks mode. I can't see 
any other satisfactory answer.
Comment 55 harishd 2000-02-09 11:18:48 PST
Assigning to rickg since he has a fix in hand :)
Comment 56 rickg 2000-02-13 11:00:22 PST
Here's the final call. For a navigator product, backward compatibility with an 
eye toward the future is essential -- and so the goal is NOT to phase out quirks 
mode inasmuch as it means "be compatible with extent content on the web". So by 
default, we're going to behave in quirks mode unless the DTD instructs us to do 

The lastest update causes HTML 4.xx transitional to be quirks. The other list of 
quirks are cited in this bug. Strict mode will be enabled for XML documents 
(obviously), XHTML and dtd's with the STRICT keyword. 
Comment 57 Masatoshi Kimura [:emk] 2000-02-18 06:03:19 PST
I must reopen this bug because of a simple mistake rather than a compatibility 
ISO doctypes are not hooked up correctly.
We need a space charactor between "ISO/IEC" and "15445:1999" since 
StripWhiteSpace() is no longer called.
Comment 58 Masatoshi Kimura [:emk] 2000-02-18 06:04:29 PST
Created attachment 5415 [details] [diff] [review]
Proposed patch: inserting a space character
Comment 59 Hixie (not reading bugmail) 2000-02-18 16:55:21 PST
The current heuristics are as follows:

1. Use QUIRKS mode for any document matching:
   1. ... <!DOCTYPE ... -//W3C//DTD ... HTML 4 ... TRANSITIONAL ...
   2. ... <!DOCTYPE ... -//W3C//DTD ... HTML 4 ... FRAMESET ...
   3. ... <!DOCTYPE ... -//W3C//DTD ... HTML 4 ... LATIN1 ...
   4. ... <!DOCTYPE ... -//W3C//DTD ... HTML 4 ... SYMBOLS ...
   5. ... <!DOCTYPE ... -//W3C//DTD ... HTML 4 ... SPECIAL ...

2. Failing those, use STRICT mode for documents matching:
   1. ... <!DOCTYPE ... -//W3C//DTD ... HTML 4 ... 
   2. ... <!DOCTYPE ... -//W3C//DTD ... XHTML ... TRANSITIONAL ...
   3. ... <!DOCTYPE ... -//W3C//DTD ... XHTML ... STRICT ...
   4. ... <!DOCTYPE ... -//W3C//DTD ... XHTML ... FRAMESET ...
   5. ... <!DOCTYPE ... ISO/IEC 15445:1999 ...
   6. ... ?XML ...
   7. ... NOQUIRKS ...

3. Failing those, use OTHER mode if the "PARSE_MODE" environment
   variable matches "other"

4. Failing that, use QUIRKS mode.

I have a few concerns about the code at the moment...

1. Why are not _all_ XHTML doctypes accepted as STRICT?

2. What about HTML 5, should such a thing ever come out?

3. 495   PRInt32 theEnd=theBuffer.FindChar(kGreaterThan,theIndex+1);
   What happens if it doesn't find the ">"?

4. Are the following lines not completely redundant?:
   518   theSubIndex=theBuffer.Find("HTML",PR_TRUE,theSubIndex+18);
   519   if(kNotFound==theSubIndex)
   520     theSubIndex=theBuffer.Find

5. David thinks the following should trigger STRICT mode:
   2. A DOCTYPE declaration without a DTD, i.e., <!DOCTYPE HTML>. 
   3. A DOCTYPE declaration with an internal subset 
   At the moment they are all Quirks mode. I don't mind either way,
   but what do you think, David?
Comment 60 rickg 2000-02-19 21:02:55 PST
ian: here are the answers to your questions:

0. your tests proved that 4.0 without any specifier was erroneously STRICT
1. All XHTML should be STRICT.
2. We'll have to rev more than the mode detection code if HTML5 is ever released
3. I've correct the bug where we don't find '>'
4. That code has been eliminated
5. pages without DOCTYPE absolutely CANNOT be dealt with as strict. That would 
mean that the *vast* majority of pages on the web today. 
Comment 61 David Baron :dbaron: ⌚️UTC-10 2000-02-19 21:15:03 PST
Rick - some responses:

 0) What do you mean?   "DTD HTML 4.0" is part of the FPI for HTML 4.0 strict. 
The word "Strict" does not appear in the FPI.

 5) Nobody was proposing that.
Comment 62 Hixie (not reading bugmail) 2000-02-20 06:29:12 PST
> 0. your tests proved that 4.0 without any specifier was erroneously STRICT
Like David said, we need this for the Strict DTD.

> 1. All XHTML should be STRICT.
Agreed. This means that the following:

    (theBuffer.Find("STRICT",PR_TRUE,theSubIndex)   >kNotFound)   ||
    (theBuffer.Find("FRAMESET",PR_TRUE,theSubIndex) >kNotFound))

...can be changed to simply:


> 2. We'll have to rev more than the mode detection code if HTML5 is ever
>    released
Not necessarily, because HTML 5 should be backwards compatible. The point is
at the moment we actually _break_ if someone uses the hypothetical HTML5 DTD,
so we are not forwards-compatible _at_all_.

Having said that, I have no idea how we could check for HTML 5, 6, 7, 8... DTDs
in a way which would not also catch some of the quirky DTDs listed on David's 

> 3. I've correct the bug where we don't find '>'
> 4. That code has been eliminated

> 5. pages without DOCTYPE absolutely CANNOT be dealt with as strict.
>    That would mean that the *vast* majority of pages on the web today. 

However, I was referring to:
   2. A DOCTYPE declaration without a DTD, i.e., <!DOCTYPE HTML>. 
   3. A DOCTYPE declaration with an internal subset 
Personally I do not see the point of using Standard mode with those as opposed
to quirk mode. Number 1 may well occur on legacy documents and is not 
recommended by the HTML specs. Number 2 is more likely to mean HTML2 than any
other version. And Number 3 is probably too complicated since one can just use
a strict FPI to get that effect, and that is simpler. David?

6. The problem reported by VYV03354 is still an issue of course. (See above)

BTW, if anyone is wondering which function we are talking about, see:
Comment 63 rickg 2000-02-25 20:14:11 PST
Policy aside, which at some point becomes a judgement call, I've addressed all 
the remaining issues that Ian has raised (in my last checkin).

If further issues arise, let's start anew.
Comment 64 Jan Carpenter 2000-03-14 17:55:07 PST
removing "fixed" and adding "crash" to keywords
Comment 65 Jan Carpenter 2000-03-14 17:56:06 PST
dang it, wrong bug.  Returning to verified/fixed.
Comment 66 Jan Carpenter 2000-03-14 17:56:23 PST
Comment 67 Scott A. Colcord 2000-03-31 14:49:53 PST
(Noted for cross-reference) Bug 31933 has some details on why this 
configuration makes it impossible to create Transitional documents that work 
according to W3C specs.

Note You need to log in before you can comment on or make changes to this bug.