W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2010

[Bug 11360] Document.compatMode semantics not specified

From: <bugzilla@jessica.w3.org>
Date: Sun, 21 Nov 2010 09:55:32 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PK6dw-0002Xk-OV@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11360

Ms2ger <Ms2ger@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #5 from Ms2ger <Ms2ger@gmail.com> 2010-11-21 09:55:32 UTC ---
(In reply to comment #4)
> (In reply to comment #3)
> > Indeed, there is no special value for limited-quirks mode. This is intentional:
> > there is only one difference between limited- and no-quirks mode, which is the
> > handling of table cells that only contain images. (In particular, whether room
> > is left for descenders, the bottom-most part of letters such as "g" or "j".)
> > 
> > All of this is only specified because sites rely on it. Trying to read any more
> > into it is probably a waste of time. (Including the strings returned by the
> > attribute; they should be treated as opaque identifiers, rather than words with
> > any meaning.)
> 
> I am not satisfied with this response. You are basically saying "it doesn't
> matter".

It doesn't.

> That is no kind of resolution, so it DOES NOT WORK FOR ME.

Why not?

> If there is a difference in behavior between limited-quirks and no-quirks
> modes, then the corresponding values of compatMode MUST be distinct,

Why?

> regardless
> of whether the value is considered an opaque identifier or not. Otherwise,
> there is no way to implement 8.4 step 2 without introducing a hidden variable
> that is distinct from compatMode.

That's true. What's the problem?

> If you aren't willing to introduce a new value,

Well, no, that would introduce significant compatibility risk for very little
gain.

> then you need to provide a
> comment in the text indicating the behavior you mention above

The spec is unambiguous:

| The compatMode IDL attribute must return the literal string "CSS1Compat"
| unless the document has been set to quirks mode by the HTML parser, in
| which case it must instead return the literal string "BackCompat".

> and also pointing
> to alternative mechanisms, e.g.,. having the content evaluate
> document.docType.publicId directly.

Why would the content need to do that? (a) The content should be in standards
mode and (b) if it isn't, you can always stick a
  <script>var thisPageIsInLimitedQuirksMode = true;</script>
somewhere.

> If the specification intentionally requires
> a hidden variable different from compatMode, then that should be indicated
> somewhere as well in the spec.

It is:

| A Document is always set to one of three modes: no-quirks mode, the
| default; quirks mode, used typically for legacy documents; and
| limited-quirks mode, also known as "almost standards" mode.

> A reference also needs to be added from 3.1.3 to 8.2.5.4.

| The mode is only ever changed from the default by the HTML parser,
| based on the presence, absence, or value of the DOCTYPE string.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Sunday, 21 November 2010 09:55:35 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 21 November 2010 09:55:36 GMT