Closed Bug 98977 Opened 23 years ago Closed 23 years ago

Layout problems freshmeat and linuxgames.com (unknown doctype)

Categories

(Core :: DOM: HTML Parser, defect, P1)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla0.9.7

People

(Reporter: wolruf, Assigned: dbaron)

References

(
URL
)

Details

Attachments

(5 files)

linuxgame strict?
(deleted), text/html
Details
freshmeat dtd
(deleted), text/html
Details
strict dtd
(deleted), text/html
Details
patch to fix http://www.linuxgames.com/
(deleted), patch
waterson
: superreview+
Details | Diff | Splinter Review
add 2 FPIs; switch to case-insensitive comparison
(deleted), patch
harishd
: review+
waterson
: superreview+
Details | Diff | Splinter Review
Using build 2001090906 on RH6.2 Linux, here are sites that do not work as usual: - http://freshmeat.net/ (the top table borders are thick, do not render as with previous Mozilla 2001090808 or IE6). - http://www.linuxgames.com/ the white table borders are going too far than they should (worked very well with Mozilla 2001090808). Might either be related to bug #97619 or bug involving doctype checkin.
The bug is caused by patch checkin in bug #55264.
Severity: major → normal
Summary: layout problems freshmeat and linuxgames.com → Layout problems freshmeat and linuxgames.com (unknown doctype)
Attached file linuxgame strict? (deleted) —
Attached file freshmeat dtd (deleted) —
Attached file strict dtd (deleted) —
Reassigning to David thanks to Bernd's comments.
Assignee: attinasi → dbaron
As Bernd wrote on bug 97619: freshmeat doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 TRansitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> linux games doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD W3 HTML//EN"> I'm reluctant to change the freshmeat one since that was an intentional decision -- the only reason it wasn't triggering strict mode before was because "loose.dtd" didn't appear within 25 characters of "www.w3.org" -- see bug 61901 -- although I would also have to add a rule for the typo in the FPI. The linuxgames one is easy to fix, though.
Component: Layout → Parser
r=hixie
http://www.dnmi.no now have new white stripes between images (left side). <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 FINAL//EN">
Comment on attachment 48795 [details] [diff] [review] patch to fix http://www.linuxgames.com/ sr=waterson
Attachment #48795 - Flags: superreview+
*** Bug 99223 has been marked as a duplicate of this bug. ***
Date: Mon, 10 Sep 2001 23:04:26 -0500 From: Jason Johnston <jason@screaminweb.com> To: dbaron@fas.harvard.edu Newsgroups: netscape.public.mozilla.layout, netscape.public.mozilla.seamonkey Subject: Re: DOCTYPE handling changes (choosing between quirks and strict modes) I noticed that the DOCTYPE changes have caused Microsoft Outlook Web Access to no longer be subject to quirks. It uses the following DOCTYPE: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 3.2//EN"> with color values specified in the body tag: <body TEXT=000000 BGCOLOR=FFFFFF LINK=000000 ALINK=000000 VLINK=000000> Before this weekend, the absence of the "#" in the color values was ignored and links were black. Now, links are the default link color (blue) because strict mode ignores these invalid color values. Deleting the DOCTYPE completely causes the quirks behavior to return. The public identifier "-//IETF//DTD HTML 3.2//EN" needs to be added to the current list to emulate past behavior. Thanks --J
I'll make a patch tomorrow that fixes linuxgames, fixes the above issue, and changes the case-sensitivity of our tests (even though FPIs are technically case-sensitive, people do make case-sensitivity errors and if we're doing the tests for going into quirks, I think it's safe, since we'll be going into quirks for the incorrect DOCTYPEs). However, I think the correct solution for freshmeat is Evangelism, unless we want to revisit some decisions made a long time ago (but very slightly botched in code) that I think we should stick with.
*** Bug 99484 has been marked as a duplicate of this bug. ***
*** Bug 99432 has been marked as a duplicate of this bug. ***
Comment on attachment 49147 [details] [diff] [review] add 2 FPIs; switch to case-insensitive comparison r=harishd
Attachment #49147 - Flags: review+
Comment on attachment 49147 [details] [diff] [review] add 2 FPIs; switch to case-insensitive comparison sr=waterson
Attachment #49147 - Flags: superreview+
Checked in attachment 49147 [details] [diff] [review] at 2001-09-13 21:19 PDT. Still need to address freshmeat issue (probably through evangelism).
*** Bug 99424 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P1
Target Milestone: --- → mozilla0.9.5
*** Bug 100029 has been marked as a duplicate of this bug. ***
*** Bug 101092 has been marked as a duplicate of this bug. ***
Are the layout problems at ThinkGeek related to this bug? Or, should I file a new bug on that? Example: http://www.thinkgeek.com/stuff/apparel/coder-hacker.shtml (page is way too wide)
*** Bug 102412 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.5 → mozilla0.9.6
How about setting a transitional flag in the parser for selected doctypes (such as HTML 4.01 Transitional and XHTML 1.0 Transitional) and then making the code that implements the line box generation / vertical sizing of table cells check for the transitional flag so that bug 22274 would no longer be an issue for transitional docs? Pros * Would solve the number one layout issue with HTML 4.01 Transitional and XHTML 1.0 transitional without making those doctypes all quirky. * The code for avoiding bug 22274 already exists for the quirks mode. * Would reduce the number of evang bugs. * Would help with the influx of dups of bug 22274 * Doesn't really harm anyone, because authors aren't relying on the gap in table cells to appear. (Making the doctypes all quirky would hurt.) * Would match the behavior of Mac IE 5 standards mode, (AFAIK) Windows IE 6 standard mode and Opera 5. Cons * Bug 22274 would still apply to Strict doctypes.
Here is an interesting article about CSS2, and IE5 & broken box model hack, and IE6 Css2 vs CSS1 that get bad code correct..maybe it will help to figure out this one, or other bugs too. :) http://www.glish.com/css/hacks.asp
BTW: this guys home page has a ton of stuff on CSS1 & CSS2... http://www.glish.com/css/home.asp
Please don't post unrelated comments to the bug. We know what the problem is.
ok, Sorry David, Apologies. Being new to this and all I guess people like to be on task. Just trying to be helpful, maybe sometimes in the wrong way, and it backfires, again sorry. -Dennis
*** Bug 104909 has been marked as a duplicate of this bug. ***
http://freshmeat.net seem to have modified their page. Thick borders gone. http://www.redhat.com are ALL thick borders.
As freshmeat.net modified their doctype, should we close this bug report and open a new one for redhat.com in Tech Evangelism ?
I think redhat is already in bugzilla for this.. but you know what.. it renders fine in 0.9.5 milestone and is bad in 2001101803.. with thick borders. I'd say its one of several mozilla bugs for layout regressions that have been seen on trunk since 0.9.4 landed..
Target Milestone: mozilla0.9.6 → mozilla0.9.7
can't see the problem with latest nightly build 2001112508.
looks fine to me in recent Linux CVS. Resolving WFM.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: