/ / - Need to remove DTD to get quirks mode



13 years ago
4 years ago


(Reporter: moz-bugzilla2, Unassigned)





(1 attachment)



13 years ago
I'm going to attach a dump of the page in question. This page does have some
validation issues but the bigger concern is that this page works fine in Firefox
1.0.6 but does not display correctly in 1.5 Beta 1 (or in a more recent 20050911
build from the branch). As such this would seem to be a regression issue. If
this site is negatively affected, I would imagine other sites would be so too
which would not be good for perception of the release.

Comment 1

13 years ago
Created attachment 195736 [details]
Problematic page (displays fine in FF 1.0.6)


13 years ago
Flags: blocking1.8b5?
That page you attached is in standards mode. It has 44  nowrap="nowrap"
attributes. When I remove those, the page shows up fine in current trunk build.
This behavior changed with bug 277232.
So I think this is tech evangelism.
Depends on: 277232

Comment 3

13 years ago
You seem correct. I'll change the bug over and send over an email to discover
with the suggested solution. Thanks.
Component: General → English US
Flags: blocking1.8b5?
Product: Firefox → Tech Evangelism
Summary: page not rendering correctly → Need to remove nowrap's -
Version: 1.5 Branch → unspecified

Comment 4

13 years ago
The problem is with the 'account center' pages at,
(which is a credit card company) not, which is a magazine.

Comment 5

13 years ago
The page I sent seems to be fixed with the removal of nowrap, but some other
pages (such as the cashback main page) seem to need a little additional help to
be displayed correctly. I just show discover an email on this and would suggest
others do the same. The site is still functional but looks horrible and could
give a bad perception of this isn't corrected by Discover prior to 1.5 release.
Assignee: nobody → english-us
Keywords: regression
QA Contact: general → english-us
Summary: Need to remove nowrap's - → Need to remove nowrap's - /


13 years ago
Summary: Need to remove nowrap's - / → Need to remove nowrap's - /
Whiteboard: →

Comment 6

13 years ago
Both pages looks fine for me with trunk builds, because I see them all in quirks
mode. Have they changed their code?

Now the web pages have
<!doctype html public  "-//W3C//DTD HTML 4.0 Transitional//EN"

The attached page has
<!doctype html public  "-//W3C//DTD HTML 4.01 Transitional//EN"

Severity: major → normal
Summary: Need to remove nowrap's - / → / / - Need to remove nowrap's

Comment 7

13 years ago
The has 4.0 and the account access page and other
account pages use 4.01. It's the pages once logged in that don't work correctly
in the beta (and other branch builds). The logged in account pages are host of while the login page is which works alright.

Comment 8

13 years ago
Apparently Discover doesn't even support Firefox 1.0 and didn't seem motivated
to fix their site:

Thank you for your recent inquiry regarding the Firefox 1.5 Beta 1 browser. We
apologize for any inconvenience you may have experienced.

Unfortunately at the time our website is not designed to support the Firefox
browser. If you are experiencing difficulty with viewing the Discover Card's
website with Firefox you may need to contact the developers of Firefox to report
the issue.

You may view Discover Card's website by using the following browsers: Internet
Explorer, Netscape, and Aol browsers. The minimum browser requirements are
Internet Explorer 4.0 or higher, Netscape 4.1 to 4.79, and AOL 5.0 or higher.

If you do not have these browsers, you may want to upgrade your browser at the
appropriate website (Microsoft, AOL or Netscape).


Discover Card Web Support 
*** Bug 314532 has been marked as a duplicate of this bug. ***

Comment 10

13 years ago
*** Bug 315500 has been marked as a duplicate of this bug. ***

Comment 11

13 years ago
*** Bug 315753 has been marked as a duplicate of this bug. ***

Comment 12

13 years ago
(In reply to comment #8)
> Apparently Discover doesn't even support Firefox 1.0 and didn't seem motivated
> to fix their site:

Hey Steve, I logged in (using 1.5 final) and duplicate the problem... but I don't see where the fsck hides their "contact us". Where do I send it?

Comment 13

13 years ago
(In reply to comment #8)
> Apparently Discover doesn't even support Firefox 1.0 and didn't seem motivated
> to fix their site:

Hey Steve, I logged in (using 1.5 final) and duplicate the problem... but I don't see where the fsck hides their "contact us". Where do I send it?

Comment 14

13 years ago
**** BIG NEWS ****
(In reply to comment #5)
> The page I sent seems to be fixed with the removal of nowrap, but some other
> pages (such as the cashback main page) seem to need a little additional
> help to be displayed correctly.

Per Steve's comment, I focused on the "cashback bonus" page. (I have some cashback to use, and will try to use the same trick on one of the most horribly broken "cashback partner" pages next.)

The page looks A+++ if I simply delete the DOCTYPE specification (first line). 

The resulting code starts with:

includes all failed attributes (such as "nowrap") and even the bad elements (AFAIK, there ain't no such thing as a <covansys> in wc3.)

Page looks good with just this change, using the Firefox-saved "dashboard_files" external files with absolutely zero modifications.

I guess that without a DOCTYPE, we fall into "quirks" mode, with compatibility at the level of HTML 3x (more or less). But that's just a wild guess, I don't know anything about Gecko Code, I'm only playing with the contents.

I'll next report results of proceeding to the "Blockbuster" cashback page, which (as sent by Discovercard) is so broken that you can't confirm a rental card amount to be mailed. (We had to switch to Opera.)

BTW: Opera/Windoze and Konqueror/Linux both work OK, our problem seems unique to us, on the 1.8 toolkit (current seamonkey nightly fails just like FF).

Comment 15

13 years ago
(In reply to comment #6)
> Now the web pages have
> <!doctype html public  "-//W3C//DTD HTML 4.0 Transitional//EN"
> "">
> The attached page has
> <!doctype html public  "-//W3C//DTD HTML 4.01 Transitional//EN"
> "">
> see

YOU'VE GOT IT! According to our doco (your reference), 4.0 Transitional *with a system identifier* (i.e., "") is QUIRKS MODE. But 4.01 *with the same identifier* has been changed to invoke ALMOST-STANDARDS MODE.

Maybe we didn't do it exactly as we say until recently (I mean, perhaps FF 1.06 displayed as quirks in both cases).

My key test was: leave the "4.01 Transitional//EN"> present, but remove the separate DTD identifier. According to our doco, this combination should behave like 4.0 (it is listed just above the test reference for 4.0 with and without, both of which should do Quirks.

Looks good! So, discovercard could keep the following first line:

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

*if* they terminate the doctype (">") WITHOUT including a reference to the official loose DTD at .

The combination of DTD identifier present *and* 4.01 moves us from from "Quirks Mode" to "Almost Standards" mode. Discovercard can (a) remove the entire DOCTYPE; (b) remove just the system-specific DTD URL identifier; or (c) downgrade the claimed level from 4.01 to 4.0.

Easiest and shortest for them, I think, would be to leave the DOCTYPE, ditch the system-specific DTD URL.   

Comment 16

13 years ago
Rick: Customer Service -> Secure Account Center online message form I think was what I used

Comment 17

13 years ago

    Here's the results of several pages within the noted problem area, "Cashback Bonus":

    (a) page 'browsePartnerItem.php' with selected partner BLOCKBUSTER: perfect appearance after changing DOCTYPE to exclude system-specific DTD URL (or removing DOCTYPE entirely, which always got the same result as ripping the WC3 loose.dtd URL).

    (b)page 'addPartnerCartItem.php' with page title 'View Your Order'. Not perfect, but pretty good. There's a tiny bit of blank (white) right margin missing in the upper portion (The table with 'cashback bonus' in red at the top, a RED menu on the left, and generated content on the right). Below this, the table containing "site map", "terms of use" and below, there's about 80 pixels of missing margin on the right side. Konqueror looks perfect, that's what I'm using for comparison (I'm running on Linux).

    (c) page 'verifyOrder.php', same problems as (b). The main table is missing the same tiny margin at the right edge (about 15 pixels?) and the table with the "bottom" stuff is again missing a larger amount, also on the right, but it's a slightly smaller amount than missing on (b) (about 60 pixels this time?). Again, Konq looks perfect.

    (d) page 'logoff.php', same problem as (b), but much less. The main table looks perfect (including the right margin) and the "bottom" table is only missing a TINY bit of margin on the right--- maybe 3 pixels wide.

    IMHO this should be good enough to quiet down the screaming, and discovercard should do it. Still, I am disappointed to see that even forcing quirks mode doesn't get us exactly right.

    Our small issues with table width on the right side are the same under both modes of repair (just the system-specific DTD removal, OR ripping out the entire DOCTYPE.) I had kinda hoped that when I pulled the reference to "4.01", we might have invoked some even more proprietary/primitive fucntionality.
    So, the remaining issue (margins on the right side don't line up) are present in our current 'quirks'. Maybe the other browsers aren't handling the nested tables properly-- arbitrarily widening the bottom table when the middle is bigger, even though the bottom table specifies a fixed width of only 750. The "nowrap" appears only within TDs, and IMHO shoudn't have anything to do with creating an entirely new column (or stretching the last existing column with extra empty space) to increase the table width when the columns inside DO NOT get widened by "no wrap". Discover Implementation Defect, I think. They should match up the table size of the parent by using width="100%" on the table at the bottom.

Comment 18

13 years ago
OK, the remaining question is:

Should I try to "handle" this with Discovercard, or should a more skilled (i.e. GENTLE) evangelist provide our resolution?

I think our suggestion, after reminding Discovercard that we've already got over 10% market share, is to solve the problems via two easy changes in discoverscard's website code:

Step 1, Mandatory and extremely easy:
Remove the explicit DTD URL "" from DOCTYPE on all of your web pages. Why? Because you are absolutely NOT compliant with this DTD, and including the specific DTD reference causes us to treat you as genuine 4.01 Transitional. That's a BAD THING. 

You're really NOT 4.01 Transitional, but by removing the DTD you can leave in the 4.01 DOCTYPE: this combination (4.01 Transitional, but WITHOUT a specific DTD URL) is a kind of "signal" for us to treat you as extremely non-compliant. You need that. You've got lots of proprietary attributes such as nowrap="nowrap" and secure="yes". Even if we ignore them as best we can, attempting to treat you as GENUINE 4.01 Transitional causes terrible problems, because your layout (partly CSS, partly HTML) causes many elements to be infinite width.

It's probably much easier for you to send us the signal that your code is "extremely non-compliant" (one line change, the top line of every PHP/HTML page you send) than it would be for you to actually fix your layout.

Step 2, Optional, and more involved: Even *with* invocation of our quirks mode, your pages show some problems on the right-hand margin. This occurs mostly in the bottom table, which is hard-coded 750 pixels wide.... but really ought to be 100% of the width of the table above (bordered with the red menu on the left, a single red line containing a title on top). You could easily make this entire table into a child element of a single <tr><td colspan="3"....> of the preceeding table. There are other ways to accomplish this, but this would be valid wc3 HTML and it would work as you intend.

Comment 19

13 years ago
We should revise the Bug Summary: They should remove the explicit DTD reference from their DOCTYPE. "Need to remove nowrap's" isn't the best/easiest way for discovercard to handle this problem, Their generated code has zillions of nowrap attributes, in lots of different places (44 on one page, xx on another, yy on another...).

But the DOCTYPE line is identical on every page I looked at. The explicit DTD occurs only in the first line of every page they create, this is the only line they need to change.

Steve, would you modify this Summary? Only a Reporter or Assignee or 'bugzilla bigshot' can change the Summary.

Comment 20

13 years ago
Thanks everyone for the analysis. Please contact them politely, point them to the appropriate comment and ask them to update their pages by removing the DOCTYPE. That seems to be the simplest edit in my opinion. No need for "professional" evangelists, you guys can do it!
Summary: / / - Need to remove nowrap's → / / - Need to remove DTD to get quirks mode

Comment 21

13 years ago
I ran a page through the wc3 verifier.... nowrap is a defined attribute, not proprietary. But the 4.01 spec warns you that it is deprecated, and (hint! hint!)  explicitly says

<b>Note. </b>if used carelessly, this attribute may result in excessively wide cells.

That's exactly what happens. Other UAs appear to constrain the size of these TDs so that they fit into the fixed size parent table (or, maybe the fixed size grandparent "wrapper" table). But that's definitely wrong, we're definitely right. A chunk of "nowrap" content is like a wide image, you don't cut off half of it so that it fits into a table--- you expand the table. 

Comment 22

13 years ago
Since I'm a Discover card member, I'll try to be nice and handle it with them, probably tomorrow.

Comment 23

13 years ago
*** Bug 320474 has been marked as a duplicate of this bug. ***

Comment 24

13 years ago
I advised Discover of their problem and my suggested workaround (strip off the explicit DTD URL) on Dec 9. In Discover's return message (also Dec. 9) I was advised that my message was forwarded "to the appropriate parties".

Today I pinged them (replied to the reply), thank you for forwarding my message, no one has contacted me yet. The site is still bad, but during the week before Christmas, they might have a lot of other work stacked up...

And, if I were in charge, the website code would be FROZEN during this period. But I really am hoping for a phone call or email, so that I may review any areas of Fear/Uncertainty which they may have about this change.  

Comment 25

13 years ago
Their reply to my "ping" message sounds promising

me (yesterday): Hi xxxxxxx,

I have not yet been contacted by the 'escalation' parties involved (a full week). I would love to speak in person, or via email, to discuss any questions which your people might have about your website defect and my recommended ( EASY!! ) workaround.

Thanks in advance, Rick

today's reply: Thank you for your reply. I apologize for the misunderstanding. The information you have provided was forwarded to the appropriate department to assist in identifying the problem with Firefox. We are working on a resolution and hope to have it corrected shortly.

Ignoring flamebait "the problem with Firefox", this seems very good. And I will DEFINITELY ignore the flamebait.

Comment 26

13 years ago
Site '' now looks good, although they chose a really hard way to fix it:

They left in the DTD. They also left in a lots of 'nowrap' attributes. What they changed was:

(1) the 'nowrap' attributes are now properly coded (just the 'nowrap' attribute, not the incorrect nowrap="nowrap" attribute/value encoding they had before). This doesn't have any effect on the way we display the pages.

(2) "nowrap" appears only in table cells where it has no effect at all (e.g., the cell content is just a single &nbsp; and the cell "width" is set to a much larger value), *or* the table cell content has now been broken up by explicit <br> elements (shortening the content enough to prevent 'nowrap' from ever expanding the width of the table cell). These changes are what makes discovercard work...

They've still got lots of 'nowrap', but their table content isn't wide enough for the attribute to have any effect.

The URL '' links directly to the '' home page.
'' is a different page and the site contains quite a few pages, they all look fine now. (Many links from '' also go to; they all look good too.)

Comment 27

13 years ago
Are there any outstanding pages that are still broken? I did a look through the discovercard site and all looked good.

Comment 28

13 years ago
It's kinda weird that the only 'Resolution' code which is even remotely close to "Not a problem, THEY fixed it" seems to be: WORKSFORME

It WFM *now*, but the problem has been quite reproducible before their repair. 'WFM' sounds like a 'it isn't reproducible, and we don't know exactly why' closure code to me... and (hint) in a previous life, I was Test & Integration at Companies you have heard of.

So: either create a new resolution code for "resolved by changes in non-Mozilla Source, Product, or Configuration", or call it WFM.

Comment 29

13 years ago
Steve, I logged in and looked at just about everything. They're all fixed. 

Comment 30

13 years ago
Great! I'm going to close out though if anyone sees something that Rick and I missed, please chirp up.

Rick: As for the WFM, my perspective in this situation is that FIXED is appropriate more appropriate. As this bug is a Tech Evangelism, it would seem to imply lobbying to get the item fixed by other sites. This was successful and is now FIXED. I can understand where you're coming from though and that makes a lot of sense too.
Last Resolved: 13 years ago
Resolution: --- → FIXED


13 years ago
OS: Windows XP → All
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.