(In reply to comment #0)
> In Section 3.1.3, Document.compatMode is specified to evaluate to "CSS1Compat"
> or "BackCompat", which are said to correspond to "no-quirks mode" and "quirks
> mode", respectively. However, the semantics (meaning) of these two values/modes
> is nowhere defined in the specification. Therefore, there is no utility to this
> attribute and it should be removed; alternatively, the semantics of these two
> modes needs to be fully spelled out.
> 
> Further, the prose refers to a "limited-quirks mode", but does not define
> either a corresponding string value or a meaning of this mode.

Document.compatMode returns CSS1Compat in this mode, as the specification says.

The meaning of the modes is defined by references to them throughout HTML5 and other specifications (i.e., when behavior should differ depending on the mode).  (New differences based on mode are no longer being introduced; they're recognized as a mistake.  However, there are a number of existing ones that are interoperable enough to be required to render Web content.)

> Finally, it is stated that "The mode is only ever changed from the default by
> the HTML parser, based on the presence, absence, or value of the DOCTYPE
> string." However, there is no indication of how the presence, absence, or value
> of the DOCTYPE string corresponds to these three modes, nor when the HTML
> parser would mutate the value of compatMode. [It is also curious how DOCTYPE
> could be related to CSS1 compatibility.]

http://www.w3.org/TR/html5/tokenization.html#the-initial-insertion-mode defines this.

(In reply to comment #1)
> (In reply to comment #0)
> > In Section 3.1.3, Document.compatMode is specified to evaluate to "CSS1Compat"
> > or "BackCompat", which are said to correspond to "no-quirks mode" and "quirks
> > mode", respectively. However, the semantics (meaning) of these two values/modes
> > is nowhere defined in the specification. Therefore, there is no utility to this
> > attribute and it should be removed; alternatively, the semantics of these two
> > modes needs to be fully spelled out.
> > 
> > Further, the prose refers to a "limited-quirks mode", but does not define
> > either a corresponding string value or a meaning of this mode.
> 
> Document.compatMode returns CSS1Compat in this mode, as the specification says.
> 
> The meaning of the modes is defined by references to them throughout HTML5 and
> other specifications (i.e., when behavior should differ depending on the mode).
>  (New differences based on mode are no longer being introduced; they're
> recognized as a mistake.  However, there are a number of existing ones that are
> interoperable enough to be required to render Web content.)
> 
> > Finally, it is stated that "The mode is only ever changed from the default by
> > the HTML parser, based on the presence, absence, or value of the DOCTYPE
> > string." However, there is no indication of how the presence, absence, or value
> > of the DOCTYPE string corresponds to these three modes, nor when the HTML
> > parser would mutate the value of compatMode. [It is also curious how DOCTYPE
> > could be related to CSS1 compatibility.]
> 
> http://www.w3.org/TR/html5/tokenization.html#the-initial-insertion-mode defines
> this.

Hi David,

Ah, ok, I had missed that last part (8.2.5.4); however, there still seems some ambiguity in the definition of compatMode, since three modes are referenced by 3.1.3 and 8.2.5.4, but only two values of compatMode are specified:

Mode                                   Document.compatMode

non-quirks mode             CSS1Compat
quirks mode                      BackCompat
limited-quirks mode       CSS1Compat

The reason I write CSS1Compat for non-quirks mode, is because the prose of 3.1.3 says:

"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"."

That doesn't seem correct, as one cannot distinguish between non-quirks and limited-quirks modes.

Regards,
Glenn

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.)

(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". That is no kind of resolution, so it DOES NOT WORK FOR ME.

If there is a difference in behavior between limited-quirks and no-quirks modes, then the corresponding values of compatMode MUST be distinct, 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.

If you aren't willing to introduce a new value, then you need to provide a comment in the text indicating the behavior you mention above and also pointing to alternative mechanisms, e.g.,. having the content evaluate document.docType.publicId directly. If the specification intentionally requires a hidden variable different from compatMode, then that should be indicated somewhere as well in the spec.

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

Regards,
Glenn

(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.

I remain unsatisfied.

I am going to keep re-opening this, until I am either satisfied or it is escalated to an issue.

It is not going to take much to satisfy me, and as I pointed out an added comment/note on the need for a hidden variable and a pointer to 8.2.5.4 from 3.1.3 will be enough.

By the way, who are you? I like to know whom I am talking with and your email address leaves that opaque, and you do not sign your name.

Regards,
Glenn

(In reply to comment #5)
> (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.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The only value you can see from .compatMode is "CSS1Compat". If you ever find your document is in "quirks" mode or "limited quirks" mode, that means your document is in some way non-conforming (e.g. you forgot your DOCTYPE). The .compatMode feature is only specified for compatibility with legacy content; there is, as far as I can tell, no use case for this feature in practice. I highly recommend pretending that the .compatMode feature doesn't exist.

I have therefore not made a change to the specification. I considered adding a note, but I couldn't work out what a note would say that would be helpful. As Ms2ger points out in earlier comments, the spec already seems to include all the information you requested.

mass-moved component to LC1