Add 'almost standards' mode to Page Info



17 years ago
8 years ago


(Reporter: malcolm-bmo, Unassigned)


(Depends on: 1 bug)

Firefox Tracking Flags

(Not tracked)




(2 attachments, 3 obsolete attachments)



17 years ago
With bug 153032, we now have an 'almost standards' rendering mode in addition 
to quirks and 'full standards' (the old standards mode).  This mode is 
triggered by transitional DOCTYPEs, for example.

Page info currently reports 'almost standards' mode as 'strict standards 
mode'.  See:

This new mode should be added to Page Info to allow page authors to determine 
which mode their page is being displayed under.

Expected results:
Page info for should show as 'almosts standards' mode.
Actual results:
Page info for shows as 'Standards compliance mode'.
Confirmed, but this is a mode completely internal to gecko that it does not
export to any external interfaces, so there is no way for page info to find out
whether we're in standards compliance mode or almost-standards mode.
Ever confirmed: true

Comment 2

17 years ago
Agreed.  Would it be acceptable to add a new attribute to nsIDOMNSHTMLDocument  
that can provide the information that page info needs, in the same way that 
compatMode does?
it should just use a different value for document.compatMode

once that's done it's extreamly simple on the page info side of things.
*** Bug 154461 has been marked as a duplicate of this bug. ***
fwiw, I wouldn't call it 'almost standards mode'. 'transition standards mode'
might work though.
I suggest avoiding the words "Transitional" or "Strict" when decsribing the
modes. Calling the standards mode "strict mode" has caused enough confusion already.

Comment 7

17 years ago
I got the impression that document.compatMode was intended to be compatible 
with the Microsoft implementation - see bug 105640 and

If so, I'm not sure it would be a good idea to break that compatibility by 
returning a different value in this case.  That's why I suggested adding a new 

Regarding naming - we now have three modes, which are described as follows:
eCompatibility_NavQuirks        Quirks mode
eCompatibility_AlmostStandards  ?
eCompatibility_FullStandards    Standards compliance mode

Perhaps 'Partial standards compliance mode'? Why not 'Almost standards 
compliance mode'?

Comment 8

17 years ago
Created attachment 89398 [details] [diff] [review]
Proposed patch

This demonstrates what I was suggesting - add a new property to
nsIDOMNSHTMLDocument and base the Page Info text off that.

Note that I've not attempted to build this at all.
That would work (probably even compile as well), but I don't see why we can't 
just add another value to the property we have.

Comment 10

17 years ago
People do seem to be interested in maintaining compatibility with MSIE's 
compatMode property.  See in particular jst's comment in bug 105640 comment 10.

For reference, the following MSDN article describes the property:

I think that we should either remain completely compatible with MSIE, and 
therefore add a new property for our purposes, or be completely incompatible 
and return completely different values for document.compatMode (ie, 
not 'CompatMode', 'CSS1Compat').  I don't think it's helpful to have a property 
that looks and works like MSIE's property, and that *occasionally* returns a 
completely unexpected value.
Mozilla's Standards mode is more about CSS2compat than about
CSS1compat--particularly if you consider the difference with Almost Standards. :-)

Comment 12

17 years ago
cc'ing jst to see if he has any comments to make about adding/changing 
properties on the DOM document object.
Is there any chance of this making it into 1.0.1?
I really don't think the "need" to show this info in the page info dialog is
nearly reason enough to add a new property to the DOM (or break compliance with IE).

I'd much rather see the logic that the parser uses duplicated in the page info
dialog if this is that important, polluting the DOM with this seems like a bad
idea to me.
Duplicating the parser's logic is not a good idea.  If we want this it would
make more sense to add something to nsIContentViewer, which is exposed within
the app but not to web pages using the DOM.
Sure, that's fine with me.

Comment 19

17 years ago
Nominating for Mozilla 1.1.  Now that 'almost standards' mode is getting some 
awareness, it's going to be more important for authors to verify what mode they 
are operating in.

(For example,

I've taken a look at the code, but I've not got enough experience to understand 
exactly what would need doing.  If someone can sketch an implementation, I'll 
attempt a patch.
Keywords: mozilla1.1


17 years ago
Attachment #89398 - Attachment is obsolete: true
I agree with Malcolm, correct info on which mode is used is much needed.
Saying "Standards compliance mode" when it's not is bad.
Also, don't be so sure that this is a permanent fix (and that almost-standards
will last forever).  CSS3 will almost definitely provide a solution that we can
use to solve this with rules in the UA stylesheet (that would even apply in full
standards mode), and we're likely to implement that at some point (and probably
as one of the higher-priority parts of CSS3).

Comment 22

16 years ago
How about calling them something like:

Standards compliance mode with CSS1 compatibility
Full standards compliance mode


Standards compliance mode (with transitional CSS1)
Standards compliance mode

Also, there should be a help page or something for that page info dialog, that
could point users (or rather, developers) to as the explaination
of that field.

There's no way currently to find out what mode I'm in, other than adding
something to your page to see how line-height behaves, is there?

Comment 23

15 years ago
re: <a href="">comment
19</a> or <a
href=">comment 22</a>:

I agree. We either need to:
a) accept this current patch as the solution until CSS3.
b) discuss what would be needed to implement additional text or a link
explaining this dialog further.

I knew enough about Mozilla to know that it wasn't rendering in
"standards-compliance" mode--it was running in "almost-standards compliance
mode", because I copied the doctype from the devedge article.

Other developers may get scared and remove the doctype, fearing that it will
break subpages.


Comment 24

15 years ago
The current patch is no good (see comment 15). At one time, I did start on an 
implementation based on comment 17, but (IIRC) I couldn't figure out how Page 
Info could obtain a reference to the correct nsIMarkupDocumentViewer.
Product: Browser → Seamonkey
Daniel, I hope you don't mind if I steal this bug...
I have patch according to comment 17.
Assignee: db48x → mats.palmgren
Keywords: mozilla1.1
Summary: Add 'almost standards' mode to Page Info → [FIX] Add 'almost standards' mode to Page Info
Created attachment 170681 [details] [diff] [review]
Patch rev. 1
Attachment #170681 - Flags: superreview?(dbaron)
Attachment #170681 - Flags: review?(
Created attachment 170682 [details]
Screenshot (patch rev. 1)
Comment on attachment 170681 [details] [diff] [review]
Patch rev. 1

>   /**
>+   * Layout mode: see layout/base/nsCompatibility.h for values.
>+   */
>+  readonly attribute PRInt32 compatibilityMode;
Perhaps you should move the values here?
You also forgot to rev the iid.

>+/* The #modetextlink style is based on the "Get New Themes" link in the pref panel */
>+#modetextlink {
>+  text-decoration: underline;
>+  color: blue;
>+  cursor: pointer;
>+#modetextlink:active {
>+  color: red;
The fact that these work depends on a bug in pageInfo.css not declaring a
default namespace. We really ought to share this style with the similar one in
prefpanels.css somehow.

>Index: browser/locales/en-US/chrome/browser/
I don't think this change belongs here ;-)

>+              <hbox><html:a id="modetextlink" style="display:block" href="&generalModeURL;" target="_blank"/></hbox>
html should be wrapped in a label or description element, not forced to fit
with display:block and hbox hacks.

>+    compatibilityMode =
>+      window.opener.gBrowser.docShell.contentViewer.QueryInterface(Components.interfaces.nsIMarkupDocumentViewer).compatibilityMode;
This won't work for View Frame Info.

>+      document.getElementById("modetextlink").innerHTML = theBundle.getString("generalStrictMode");
Use .textContent for text, not .innerHTML
Attachment #170681 - Flags: review?( → review-
Attachment #170681 - Flags: superreview?(dbaron)
Created attachment 170754 [details] [diff] [review]
Patch rev. 2

(In reply to comment #28)
> >Index: browser/locales/en-US/chrome/browser/
> I don't think this change belongs here ;-)

I don't get it. Why should this file not be updated?

> This won't work for View Frame Info.

I could not find a simple way to get from "document" to "nsIDocShell", so
I had to traverse the docShell tree looking for the one with the document.
Attachment #170681 - Attachment is obsolete: true
Attachment #170754 - Flags: review?(
Comment on attachment 170754 [details] [diff] [review]
Patch rev. 2

>Index: browser/locales/en-US/chrome/browser/
>Index: toolkit/content/xul.css
Please don't mix suite and firefox patches.

>+              <label><html:a id="modetextlink" href="&generalModeURL;" target="_blank"/></label>
I notice that all the textboxes gave been given zero margin. Please could you
give the label a class so you can style it in pageInfo.css to match.

>+    var iter = window.opener.gBrowser.docShell.getDocShellEnumerator(Components.interfaces.nsIDocShellTreeItem.typeContent,
>+                                                                     Components.interfaces.nsIDocShell.ENUMERATE_FORWARDS);
>+    while (iter.hasMoreElements()) {
>+      const docShell = iter.getNext().QueryInterface(Components.interfaces.nsIDocShell);
>+      const webNavigation = docShell.QueryInterface(Components.interfaces.nsIWebNavigation);
>+      if (webNavigation.document == theDocument) {
>+        compatibilityMode = docShell.contentViewer.QueryInterface(Components.interfaces.nsIMarkupDocumentViewer).compatibilityMode;
>+        break;
>+      }
>+    }
Boris Zbarsky knows a better way to get a doc shell.

>+html|a:link {
>+  text-decoration: underline;
>+  color: blue;
>+  cursor: pointer;
>+html|a:active {
>+  color: red;
Hmm... perhaps these should be :link and :link:active?
> I could not find a simple way to get from "document" to "nsIDocShell",


should work....
I'll add in my two cents. First, don't use window.opener, use theDocument.

Second, do patch both xpfe and browser at the same time - it's the only way to
keep them in sync. However, your patch doesn't include changes for browser's
pageInfo.js, pageInfo.xul, pageInfo.dtd, or skins.

Third, I don't really care for that to be a link. It's an interesting idea, but
I think the information is best put into the help file.
Attachment #170754 - Attachment is obsolete: true
Attachment #170754 - Flags: review?(neil)
QA Contact: pmac → nobody

Comment 34

10 years ago
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
I think we can actually confirm this bug now as it's still there.


9 years ago
Depends on: 561258
Assignee: matspal → nobody
Summary: [FIX] Add 'almost standards' mode to Page Info → Add 'almost standards' mode to Page Info
You need to log in before you can comment on or make changes to this bug.