Last Comment Bug 154359 - Add 'almost standards' mode to Page Info
: Add 'almost standards' mode to Page Info
Status: NEW
Product: SeaMonkey
Classification: Client Software
Component: Page Info (show other bugs)
: Trunk
: All All
-- normal with 5 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
: Nobody; OK to take it and work on it
: 154461 (view as bug list)
Depends on: 561258
  Show dependency treegraph
Reported: 2002-06-26 04:09 PDT by Malcolm Rowe
Modified: 2011-05-27 10:29 PDT (History)
16 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---

Proposed patch (4.60 KB, patch)
2002-06-27 06:17 PDT, Malcolm Rowe
no flags Details | Diff | Splinter Review
Patch rev. 1 (7.46 KB, patch)
2005-01-08 12:38 PST, Mats Palmgren (:mats)
neil: review-
Details | Diff | Splinter Review
Screenshot (patch rev. 1) (39.74 KB, image/png)
2005-01-08 12:42 PST, Mats Palmgren (:mats)
no flags Details
Testcase (769 bytes, text/html)
2005-01-09 11:27 PST, Mats Palmgren (:mats)
no flags Details
Patch rev. 2 (11.28 KB, patch)
2005-01-09 11:36 PST, Mats Palmgren (:mats)
no flags Details | Diff | Splinter Review

Description User image Malcolm Rowe 2002-06-26 04:09:54 PDT
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'.
Comment 1 User image Boris Zbarsky [:bz] (still a bit busy) 2002-06-26 04:15:37 PDT
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.
Comment 2 User image Malcolm Rowe 2002-06-26 05:18:15 PDT
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?
Comment 3 User image Daniel Brooks [:db48x] 2002-06-26 12:37:54 PDT
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.
Comment 4 User image Boris Zbarsky [:bz] (still a bit busy) 2002-06-26 14:36:14 PDT
*** Bug 154461 has been marked as a duplicate of this bug. ***
Comment 5 User image Daniel Brooks [:db48x] 2002-06-26 17:45:56 PDT
fwiw, I wouldn't call it 'almost standards mode'. 'transition standards mode'
might work though.
Comment 6 User image Henri Sivonen (:hsivonen) 2002-06-26 22:17:56 PDT
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 User image Malcolm Rowe 2002-06-27 03:24:12 PDT
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 User image Malcolm Rowe 2002-06-27 06:17:39 PDT
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.
Comment 9 User image Daniel Brooks [:db48x] 2002-06-27 13:44:19 PDT
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 User image Malcolm Rowe 2002-06-28 02:13:55 PDT
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.
Comment 11 User image Henri Sivonen (:hsivonen) 2002-06-28 13:12:49 PDT
Mozilla's Standards mode is more about CSS2compat than about
CSS1compat--particularly if you consider the difference with Almost Standards. :-)
Comment 12 User image Malcolm Rowe 2002-07-04 06:44:40 PDT
cc'ing jst to see if he has any comments to make about adding/changing 
properties on the DOM document object.
Comment 13 User image Henri Sivonen (:hsivonen) 2002-07-04 10:18:10 PDT
Is there any chance of this making it into 1.0.1?
Comment 14 User image Johnny Stenback (:jst, 2002-07-04 10:19:25 PDT
Comment 15 User image Johnny Stenback (:jst, 2002-07-04 11:12:13 PDT
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.
Comment 16 User image David Baron :dbaron: ⌚️UTC-8 2002-07-04 12:45:42 PDT
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.
Comment 17 User image David Baron :dbaron: ⌚️UTC-8 2002-07-04 12:46:35 PDT
actually, probably nsIMarkupDocumentViewer would be more appropriate.
Comment 18 User image Johnny Stenback (:jst, 2002-07-04 14:22:27 PDT
Sure, that's fine with me.
Comment 19 User image Malcolm Rowe 2002-07-10 02:38:45 PDT
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.
Comment 20 User image Mats Palmgren (:mats) 2002-08-28 15:45:14 PDT
I agree with Malcolm, correct info on which mode is used is much needed.
Saying "Standards compliance mode" when it's not is bad.
Comment 21 User image David Baron :dbaron: ⌚️UTC-8 2002-09-04 14:28:07 PDT
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 User image Jeremy M. Dolan 2003-01-01 11:59:00 PST
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 User image Sam Katz 2004-01-12 12:25:41 PST
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 User image Malcolm Rowe 2004-01-13 03:08:58 PST
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.
Comment 25 User image Mats Palmgren (:mats) 2005-01-08 12:35:55 PST
Daniel, I hope you don't mind if I steal this bug...
I have patch according to comment 17.
Comment 26 User image Mats Palmgren (:mats) 2005-01-08 12:38:17 PST
Created attachment 170681 [details] [diff] [review]
Patch rev. 1
Comment 27 User image Mats Palmgren (:mats) 2005-01-08 12:42:37 PST
Created attachment 170682 [details]
Screenshot (patch rev. 1)
Comment 28 User image 2005-01-08 13:51:38 PST
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
Comment 29 User image Mats Palmgren (:mats) 2005-01-09 11:27:04 PST
Created attachment 170751 [details]
Comment 30 User image Mats Palmgren (:mats) 2005-01-09 11:36:10 PST
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.
Comment 31 User image 2005-01-09 14:46:35 PST
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?
Comment 32 User image Boris Zbarsky [:bz] (still a bit busy) 2005-01-09 14:51:09 PST
> I could not find a simple way to get from "document" to "nsIDocShell",


should work....
Comment 33 User image Daniel Brooks [:db48x] 2005-01-09 18:55:22 PST
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.
Comment 34 User image Robert Kaiser 2009-06-14 15:17:26 PDT
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
Comment 35 User image Frank Wein [:mcsmurf] 2009-11-22 02:47:21 PST
I think we can actually confirm this bug now as it's still there.

Note You need to log in before you can comment on or make changes to this bug.