- From: <bugzilla@jessica.w3.org>
- Date: Sun, 21 Nov 2010 14:43:15 +0000
- To: public-html-bugzilla@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 UTC