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 14:43:15 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1PKB8N-0005fA-Ut@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11360

Glenn Adams <glenn@skynav.com> changed:

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

--- Comment #6 from Glenn Adams <glenn@skynav.com> 2010-11-21 14:43:15 UTC ---

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.

-- 
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 14:43:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 21 November 2010 14:43:17 GMT