Closed Bug 42388 Opened 24 years ago Closed 24 years ago

Collection Bug - new dtd strict mode causes pages to misrender

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: doronr, Assigned: harishd)

References

(
URL
)

Details

(Keywords: top100, Whiteboard: [nsbeta2+])

Attachments

(1 file)

A trivial patch.
664 bytes, patch
Details | Diff | Splinter Review
this is a collection bug for tables being misrendered due to rickg's dtd strict mode.
*** Bug 42385 has been marked as a duplicate of this bug. ***
*** Bug 42350 has been marked as a duplicate of this bug. ***
*** Bug 42410 has been marked as a duplicate of this bug. ***
*** Bug 42370 has been marked as a duplicate of this bug. ***
Marking one of my bugs as a duplicate. This is only a guess, but I added there that this might have something to do with bug #42204.
bug #42388 is a related RFE here. I've checked #42204 and it doesn't seem to be the problem, so forget that. assigning to rickg.
Assignee: asa → rickg
sorry, i meant #42286. holding off on actually marking it RFE for now, as jag thinks it's the proper fix (i.e, don't coddle bad HTML.) I'll let you guys make that decision...
Component: Browser-General → Parser
Assuming this is all the same bug we are seeing here are sample urls that are now not working http://www.mozillazine.org/ http://users.ipa.net/~asj/
The "problem" is that pages which specify an html 4 DTD have their HTML code parsed more strictly and any incorrect HTML code encountered then, most often missing closing tags, result in the page not rendering like it should. One could argue that this is really an invalid bug, since the pages, by specifying the HTML 4 DTD, promise they are going to provide HTML code which adheres to the specified DTD, but then break that promise. One can also argue that Mozilla should deal with these pages more gracefully than just rendering the page incorrectly. Instead, upon the first piece of bad code encountered it should fall back upon the parsing mechanism used to parse documents which don't specify an HTML 4 DTD and indicate somewhere that the page contains errors, as indicated in bug 42286.
Whoops, forgot to add myself to CC after mid-air collision.
dupe of bug 42154 ?
Bernd, bug 42154 refers to just a tables issue. My sucky page http://users.ipa.net/~asj/ does not have any tables but is screwed up. I do however think both bugs may be related to the same thing, but not just a tables issue.
this is a collection bug for all bugs due to the new strict dtd mode, tables or not. this will be marked depends on the bugs that have the concrete problems. Moving this to nobody@mozilla.org to keep rickg's spamm minimal.
Assignee: rickg → nobody
Summary: new dtd strict mode causes tables to misrender → Collection Bug - new dtd strict mode causes tables to misrender
*** Bug 42513 has been marked as a duplicate of this bug. ***
Some additional test cases that show bad table rendering: http://freshmeat.net http://opensource.lineo.com Hope these help.
As far as I can tell, there are at least three issues: bug 42370 - missing non-optional closing tags (broken html) breaks following tags bug 42312 - missing optional closing tags (<p> without </p> for example) breaks following tags bug 42526 - <th> in tables not rendered
Depends on: 42312, 42370, 42526
Hardware: PC → All
Summary: Collection Bug - new dtd strict mode causes tables to misrender → Collection Bug - new dtd strict mode causes pages to misrender
*** Bug 42414 has been marked as a duplicate of this bug. ***
*** Bug 42487 has been marked as a duplicate of this bug. ***
*** Bug 42603 has been marked as a duplicate of this bug. ***
*** Bug 42712 has been marked as a duplicate of this bug. ***
*** Bug 42657 has been marked as a duplicate of this bug. ***
*** Bug 42754 has been marked as a duplicate of this bug. ***
RickG checked in code that should fix many of the strict DTD's bugs. These should all be retested in today's builds. We need to figure out: * which of these bugs are bugs in the strict DTD * which are bugs in the pages
Working on that for Windows 95 and Linux
All test cases listed on this bug look good on Linux wth build 2000061608.
In addition, all bugs which are marked as dupes of this one are resolved by the fix. Linux build 2000061608.
Even pages with screwy html are worrking good again. Win32 Party time!!
*** Bug 44498 has been marked as a duplicate of this bug. ***
*** Bug 44483 has been marked as a duplicate of this bug. ***
*** Bug 44510 has been marked as a duplicate of this bug. ***
*** Bug 44511 has been marked as a duplicate of this bug. ***
also bug 44395 tables being misrendered (missing tag).
*** Bug 44757 has been marked as a duplicate of this bug. ***
*** Bug 44520 has been marked as a duplicate of this bug. ***
*** Bug 45113 has been marked as a duplicate of this bug. ***
Nominating for nsbeta2 attention due to the large number of duplicates.
Keywords: nsbeta2
adding mostfreq keyword
Keywords: mostfreq
If you're going to nominate this for beta2, somebody needs to figure out which of the pages are/were bugs in the strict DTD itself, and which are its intended effects. The dupes of this bug are two different sets of things and they need to be sorted out.
Some of these now behave better: helixcode and slashdot are now OK. www.dagbladet.no may be bug 43570, which surfaced at the same time but appear to be a separate bug (?)
Here's a couple more examples of sites that work fine with MOZ_DISABLE_STRICT=1, but are somewhat scrambled with strict dtd. Tables collapsing into a single column: http://www.kodak.com/ http://www.sgi.com/ Style sheet not being applied?: http://news.bbc.co.uk/hi/english/uk/newsid_828000/828847.stm (representative example)
actually, this bug was created to pick dupes, and then file the actual bugs to the devs. This was fixed, but now seems to have regressed. Do you think that 42312 should be reopened?
My $0.02: Earlier problems seen with http://www.mozillazine.org, http://freshmeat.net and http://opensource.lineo.com have dissapeared. However, http://www.everything2.com still exhibits table rendering problems. HTH
On a build from this morning, I'm still seeing the sidebar collapsing beneath the comments in the articles, for example: http://www.mozillazine.org/talkback.html?article=1495 The problem disappears if strict dtds are disabled.
Putting on [nsbeta2-] radar. Not critical to beta2.
Assignee: nobody → harishd
Whiteboard: [nsbeta2-]
Ok something strange is going on here and I think it is related to strict dtd mode, but not sure. I am gong to look more and ask around, but if someone else figures it out let me know or file a bug. Mozillazine http://www.mozillazine.org does not look correct in current builds of Mozilla. I have seen this bug for about a week and a half now (regression). If i save the main page to a local drive the page still loads incorrectly. If i take out <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40-971218/loose.dtd"> then read load. The page starts to load correctly and looks good then regresses to the exact same issue. I was supprised that it loads correctly then reverts back to the bad format only if I take out the DTD. If pages like Mozillazine are not rendered correctly this really should be nsbeta2.
The following two sites from the top100 list (http://komodo.mozilla.org/buster/pagelist.html) also show the collapsing table problem, and are cured by disabling strict dtds: top100/url.55 : http://www.benews.com/ top100/url.135 : http://www.richinstyle.com/
Keywords: top100
richinstyle.com isn't top100. It's just on the list because someone felt like adding it, I guess...
Another thing to test: Can you find invalid markup that, if corrected, fixes the problem. If not, then it could be a bug in the strict DTD (probably easily fixed) rather than the DTD itself. One can run the pages through http://validator.w3.org/ to see.
Last I heard, all of the pages below are fed through the strict parser because they either specify a Strict FPI, or a Transitional FPI with a URI. For example, if I take the URI out of the doctype on mozillazine's page, they render fine again: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> I've just looked at http://www.mozillazine.org/ and http://www.mozillazine.org/talkback.html?article=1495, and fixing the code (no, not by removing the doctype ;-) ) fixed the layout. Anyone wanna tackle the others? Btw, those pages with a Strict FPI are out of luck. They claim to adhere strictly to a standard, yet do not. Would their respective reporters mind e-mailing the webmasters and letting them know to either change the doctype to Transitional with no URI, or fix the code? ---List of URLs and their doctypes---------------------------- http://www.kodak.com/ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd"> http://www.sgi.com/ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> http://news.bbc.co.uk/hi/english/uk/newsid_828000/828847.stm <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> http://www.everything2.com/ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> http://www.mozillazine.org/talkback.html?article=1495 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40-971218/loose.dtd"> http://www.mozillazine.org/ <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40-971218/loose.dtd"> http://www.benews.com/ <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd"> http://www.richinstyle.com/ <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0//EN" "http://www.w3.org/TR/REC-html40/strict.dtd">
*** Bug 45236 has been marked as a duplicate of this bug. ***
*** Bug 45450 has been marked as a duplicate of this bug. ***
Why don't you guys make a dtd anal mode in the preferences? Let the user decide on how the browser should react. When enabled, then the warnings on the html quality will show. I dunno, like in the percentage stats bar for example, or even another pop up window. Because, people do not want to see all these "warning, poor quality webpage" errors. They just want a browser to do what its suppose to do, browse. That way when people download the n6pr2, they won't be thrown off guard by the program. Lets face it, if an everyday person decided to download the beta and finds it doesn't work the way it should, then one or both will happen! 1) The user will complain to netscape about the poor quality and very buggish style program 2) The user will be so thrown off guard that (s)he'll delete the program and probably never come back to it again, even if it is final release. We want to draw attention the great high standards mozilla has, not detour them because we want to be anal on how a page is going to display (messed up) because the page has 3 errors on. The internet isn't burger king, you can't have it your way. The point is that you have to be mindful of what people want if you want people to use your products. People have expectations, and if you don't live up to them, chances are they aren't coming back to see you again. I must say that we get this problem solitified soon, or we lose a lot of respect. Not only do I find the use of strict dtd mode enabled for a normal user annoying, its just plain stupid too! I'm sorry I posted this here, but I'm not to sure where else I'm going to get the attention of the coders. But please, email me any flames, comments, etc. (except for spam... I get enough of that **** already!) :)
Jason Chambers: i filed an RFE in bug 44525: "[RFE] User option to force quirks mode for specified sites" You may want to add a comment, or even vote for it.
Can someone take a look at http://www.lokigames.com/. The page is drawn twice in the browser. I assume this a dtd mode problem because setting MOZ_DISABLE_STRICT=1 seems to fix the problem.
*** Bug 45354 has been marked as a duplicate of this bug. ***
*** Bug 45781 has been marked as a duplicate of this bug. ***
Most of these pages are using (now obsolete) HTML 4.0 rather than HTML 4.01. What about triggering quirks if HTML 4.0 (not HTML 4.01) doctypes found?
More stuff to go on that I hope will help: Head over to: http://oss.lineo.com/cgi-bin/cvsweb/. What you should see is a table with a header and alternating blue and white rows (this is now it renders in Netscape 4.73). Mozilla (Build ID: 2000071920 - PC - Linux) is rendering all the folder icons on a single row; it does not appear to be parsing the <th> tag in the source correctly, nor is it coloring the table rows. If I set the environment variable MOZ_DISABLE_STRICT=1 the table looks just fine. Caveat: I have not looked at the HTML source closely enough to determine whether this is an HTML bug or a Mozilla/strict-DTD bug. Hopefully this will give someone smarter than me something to go on.
*** Bug 45977 has been marked as a duplicate of this bug. ***
*** Bug 46025 has been marked as a duplicate of this bug. ***
First of all, as a user it really p*sses me off that a whole bunch of pages are not rendered correctly. This may be ok because the pages contain 2 or 3 HTML errors, but I want a browser that copes with it - there are much more incorrect than correct HTML pages out there. I sincerely hope this bug is gone till nsbeta2. Do NOT release an end-user beta that screws up that many pages. Having said that, might this be a platform specific issue? Take a look at Bug 46025, I can't get http://www.buffymedia.de/index2.php to render correctly with Mozilla, MOZ_DISABLE_STRICT=1 doesn't help under Linux. However, under Windows the page is rendered correctly, and I didn't change anything, just started the freshly unpacked binary!
http://oss.lineo.com/cgi-bin/cvsweb/ uses an old version of cvsweb, updating to a newer version should fix that page... kinda :-) harishd/rickg, http://oss.lineo.com/cgi-bin/cvsweb/ uses a doctype with a lowercase "public" while 'tidy' says it should be "PUBLIC". Can that be used like "transitional" with lowercase t to qualify it as an invalid doctype and therefore not use strict parsing? Stephan Jaensch, I hope you're pissed off enough to also write an e-mail to those webmasters, telling them to either fix their HTML code (http://validator.w3.org), or to adjust their doctype to something more appropriate like <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
Peter, probably I was not clear enough: certainly the pages are broken and should be fixed. Nevertheless Mozilla should do what it can to render the page as close to the expected/intended as possible. Well yes, I also wrote an eMail to one of the webmasters. :-) Response: They will not fix Mozilla rendering until the rendering engine is "stable". His point: a few weeks ago Mozilla rendered the pages perfectly, it seems that it does as well nowadays with Mozilla under Windows, but not under Linux. They already have to keep two versions for NS/IE and don't want to create a third when Mozilla rendering behaviour could change every day (as it did recently with strict DTD checking). I see his point. What do you say?
Stephan, can you reply to that webmaster and tell him that replacing: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> with this (i.e. removing the loose.dtd): <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> should fix "support" for Mozilla? After that change it looks just fine under Moz on linux and Windows 95. I've tried MOZ_DISABLE_STRICT=1 on Windows and Linux and it renders the original page the same (though incorrectly) on both. It looks like it's rendering it in standards mode (the thick borders at the top and the bottom of those blocks: their minimum height needs to be the font's line height).
If a page requests strict mode then it has to follow the spec. strictly. In other words Mozilla will not try to correct things in strict mode. If webmasters don't want to change their markup, but would want their pages to be rendered as in Nav. or IE then they ought to change their DOCTYPE.
Status: NEW → ASSIGNED
As I've said before, there's no reason to say that for HTML 4.0 strict and not HTML 4.0 transitional, HTML 3.2, or HTML 2.0. The only reason to do what we're doing is that HTML 4.0 DOCTYPEs are not yet prevalent on the web, whereas the others are, and our goal is to encourage documents created in the future to be stricter. Considering that we haven't released yet, and the number of dups on this bug, I think we may need to back off to HTML 4.01.
To respond to Peter Annema's comment at 05:18 today: I think having the word "public" in lowercase is legal. I think only the FPI (Formal Public Identifier) and System Identifier (the URL) are case sensitive, since they are 'minimum literal's.
Hmmm, all I have to go by is 'HTML tidy' and its source, which clearly indicate that SYSTEM and PUBLIC should be uppercase. I haven't found any specs yet defining one way or the other.
ISO 8879:1986 (SGML), section 13.4.5: # NAMECASE specifies whether upper-case substitution is to be performed for # entity references and entity names ("ENTITY") and/or for all other # names, name tokens, number tokens, and delimiter strings ("GENERAL"). ISO 8879:1986 (SGML), section 13.4.7 lists DOCTYPE, SYSTEM and PUBLIC as names. HTML 4.01, section 20.1: # FUNCTION # RE 13 # RS 10 # SPACE 32 # TAB SEPCHAR 9 # [...] # NAMECASE GENERAL YES # ENTITY NO # [...] # FORMAL YES Since SYSTEM and PUBLIC are names, and names are case insensitive per HTML, section 20.1, SYSTEM and PUBLIC are case insensitive.
*** Bug 46128 has been marked as a duplicate of this bug. ***
small note - if you find issues with the dtd, file newbugs. This is just to collect dupes. IF you want, open a bug about having the same quirk level as 4.x.
Here's something you guys might want to read..... I was doing a little experiment today. What I did was in nav 4.73, took a miss rendered page then File -> Edit Page then saved the page to my hd, edit it and made it HTML 4.01 instead of HTML 4.0... You guys might want to check out these results. Woot.net before: Rant layout was squished all the way to the right Woot.net after: Rant layout rendered normally, but colours in the links box is changed Distributed.net before: Project statistics and info not being paragraphed out, it was all a big huge paragraph of its own. Links on the left side were widely spaced on the vertical. Distributed.net after: Rendered properly but resizing of text never happened, and the banner at the top needs to be resized. Like I said many times before, I don't know jack **** (even the person) about HTML or about webstandards etc. For all I know you guys know that this is happening. But it seems to me that mozilla just decided to stop supporting HTML 4.0 altogether! Anyone care to do the same for the rest of these pages? Comments anyone?
Did you try the pages on your hard drive before you changed them? How did you change them?
I'm look at the two page sources right now... it seems the one I have didn't add "http://www.w3.org/TR/REC-html40/loose.dtd"> to what it says on the internet. (that'll solved most of it right there) I guess netscape was fixing all the errors when it saved :/
I have a general question concerning this whole issue: Are there any pages that are actually rendered better with strict syntax checking? Strict mode might be good to find HTML errors, but for the end user I see only disadvantages (broken pages). IMHO it should be disabled by default, not activated by DTDs in the document which the end-user can't change (to view the page correctly).
I doubt the strict DTD would improve any pages, although strict layout mode certainly could. See: http://www.people.fas.harvard.edu/~dbaron/mozilla/modes However, **if** the strict DTD manages to enforce on the Web higher standards for web content (pun intended), it could result in less bloated software, faster performance of web pages, and easier creation of web browsers.
*** Bug 46155 has been marked as a duplicate of this bug. ***
I am clearing the nsbeta2- to trigger a reevaluation by the PDT. The status of (most of) the bugs marked as duplicates is as follows (I did thisk quickly, so I might have made a few mistakes): FIXED (these are not listed below): bug 42385, bug 42350, bug 42410, bug 42526, bug 42414, bug 42487, bug 42603, bug 42712, bug 42754 Caused by HTML 4.0 Strict DTD: bug 44520, http://www.kodak.com/ Casued by HTML 4.0 Transitional DTD: bug 42370, bug 42513, bug 44498, bug 44483, bug 44510, bug 44511, bug 44757, bug 45113, http://www.sgi.com/ , http://www.benews.com/ , bug 45450, bug 45354, bug 45977, bug 46025, bug 46128, bug 46155 We have received 15 separate bug reports on this issue that still exist, yet there has not yet been a mozilla.org milestone release with the Transitional and Strict DTDs enabled. If we simultaneously release a mozilla.org milestone and a Netscape beta (one which will presumably be used a good bit more than the first beta) with these enabled, the number of bugs received will overwhelm the QA volunteers who have been triaging these bugs. We will be unable to triage incoming layout bugs and be unable to separate out good bug reports from problems caused by the Transitional and Strict DTDs. At the very least, we *must* back off the transitional DTD to HTML 4.01 (and maybe also the same for the strict DTD). PDT: This is a simple change to the code that decides which DTD to use. It will allow the people helping with triaging bugs to work on unknown bugs rather than repeatedly analyse a bug we created intentionally and already fully understand.
Whiteboard: [nsbeta2-]
*** Bug 42818 has been marked as a duplicate of this bug. ***
*** Bug 46255 has been marked as a duplicate of this bug. ***
*** Bug 46232 has been marked as a duplicate of this bug. ***
Putting on [NEED INFO] radar. PDT needs to know impact to user and risk of fix to make a call on this bug. If we change to the the other DTD, what are the side effects going to be? Are those same pages (or new pages) going to be rendered incorrectly? David Baron, can you get back to us on that?
Whiteboard: [NEED INFO]
David's Comment:At the very least, we *must* back off the transitional DTD to HTML 4.01. My comment: May be. Because transitional DTD might be thought of as a compatibilty DTD. Note: My fix ( matter of enabling a flag ), for beta2, would be to disable transitional DTD, however, for beta3 I can make HTML 4.01 Transitional to trigger the transitional DTD. David's Comment: And maybe also the same (*must* back off ) for the strict DTD. My comment: Definitely not. There should be no misconception in using strict DOCTYPE.
For PDT: --------- Good: Disabling transitional DTD, for beta2, should not cause any side effects ( AFAIK). Documents, that use transitionl DTD, but don't follow the transitional spec., would be rendered in compatiblity mode ( like Nav4.x and IE ). That is, there is a good chance ( ~99% ) that documents would get laid out "correctly". Bad: My disabling transitional DTD users will not be able to see the use of transitional DOCTYPE ( in beta2 ).
Attached patch A trivial patch. — — Splinter Review
For PDT: Impact to user: Many pages have large sections of missing content or content that is displayed with no markup. This has been noticed by "ordinary" users who have downloaded nightly builds: we already have 18 bugs filed on it. These pages include at least one top100 site, as well as many other major company homepages. Risk of fix: Fix is to partially (i.e., for some of the pages where it changed, but not all) revert behavior to what it was in M16, before Rick checked in the Strict DTD. It causes code to be used for these pages that is already used for 99% of the pages on the web, rather than different code. It is very low risk.
Whiteboard: [NEED INFO] → [NEEDed INFO]
harishd, if it is an option at all, how much effort would it take to do non-strict parsing on Transitional, but also do non-NavQuirks rendering?
"Bad: My disabling transitional DTD users will not be able to see the use of transitional DOCTYPE ( in beta2 )." I think that is the lesser of the evils.
*** Bug 46326 has been marked as a duplicate of this bug. ***
This is too risky to take right now for PR2. Putting on [nsbeta2-] radar.
Whiteboard: [NEEDed INFO] → [nsbeta2-]
You mean you won't change the rendering behaviour back to what it was in M16 for beta 2? This will give you a LOT of negative press and a LOT of frustrated users that will rightfully claim that Mozilla is not only slower and not as full-featured as IE, but it also renders pages worse. And they are right because Mozilla has left the path of rendering the pages as good as possible, instead it trashes whole pages because of one or two wrong-used tags. The spec may allow this but the user won't. You have been warned.
Clearing [nsbeta2-] to trigger re-evaluation by PDT team. I have spoken with David Baron and Harish and all three of us agree that: 1) this fix is low-risk 2) if we do not check in this fix for nsbeta2: a) Bugzilla may be deluged by DUPs of this issue (we've already gotten 18 DUPs with this issue only in the dailies, not any milestone or N6 PR1) b) the usefulness of the nsbeta2 for uncovering unknown *real* compatibility issues for which no fix is known yet may be dangerously reduced because such real issues will be hidden by this common (and easily fixable) non-issue that we intend to fix I strongly encourage the PDT team to mark this nsbeta2+ and please call me if you are considering minusing it again. Thanks!
Whiteboard: [nsbeta2-]
I would add 2c, the risk that volunteer testers and bugzilla jockeys will get fed up with internal Netscape bickering and just leave. It's a real pain to look at 1/3rd of the bugs on bugzilla every day and decide that they are probably caused by strict parsing.
*** Bug 46250 has been marked as a duplicate of this bug. ***
*** Bug 46642 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [nsbeta2+]
All on the cc: list for this bug: as soon as the fix is checked in, would you please lend a hand by downloading the next daily build and pounding on the various URLs below to help make sure that (1) we've fixed the problem, and (2) we haven't introduced new problems? Although this is believed to be extremely low risk as we're just kicking into a compatibility mode we use elsewhere, as time is very short before nsbeta2, we'd really appreciate your help in verifying just to be sure that we've introduced no new regressions. Thanks!
Note: I would be diabling Transition DTD. Strict DTD, however, will remain strict. ( refer to my earlier comments ).
*** Bug 46038 has been marked as a duplicate of this bug. ***
Disabled Transitional DTD. Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
The layout is fine for bug 44510 (distributed.net webpage, which I reported.) But I have noticed 1 error on it. The headers for different sections (bolded text) is not being increased in size as in n4.73 And the box on www.woot.net (top left) is much bigger in length (smaller in hight) as in n4.73 Should I report more layout bugs (if I notice any,) here or create a new bug for each case?
Jason, from your comment it sounds like a residual style problem in compatibiltiy DTD. Please open a separate bug. Thanx.
Adding cc to myself. Also, it seems on the 2000072808 Morning Build that the Strict DTD's are the problem, now.
I have checked the 31 dups of this bug and everything seems to be OK as far as Transitional DOCTYPEs are concerned. I found 4 sites that still has problems that were unrelated to DOCTYPE. I haven't checked the ones with Strict DOCTYPE. OK bug 42350 http://freshmeat.net/ OK bug 42385 http://www.apple.com/quicktime/download/ OK bug 42410 http://www.lug.psu.edu/main.php3 OK bug 42414 http://www.flanker2.com/index7.html OK bug 42487 http://www.w3.org/Style/CSS/Test/current/sec11.htm ERR bug 42513 http://www.everything2.com/ A (DOCTYPE unrelated) problem, filed new bug 46946 OK bug 42603 http://www.videogames.com ?? bug 42657 http://junruh.mcom.com/tests.html URL is behind Netscape firewall OK bug 42712 http://www.freshmeat.net OK bug 42754 http://aim.aol.com/openim/ OK bug 42818 http://www.versiontracker.com/ ERR bug 44483 http://news.bbc.co.uk/ Same problem as http://www.everything2.com, see bug 46946 OK bug 44498 http://www.ireland.com/ OK bug 44510 http://www.distributed.net Minor font problem, as Jason Chambers noted (did you open new?) OK bug 44511 http://www.webopedia.com/ , http://mailandnews.com/ ERR bug 44520 http://www.reactor.ru/ Page looks awful due to Strict DTD. Remove DTD -> OK. OK bug 45113 http://stats.distributed.net/rc5-64/psummary.php3?id=275863 OK bug 45236 http://www.mozillazine.org OK bug 45354 http://freeshell.org/~baptize2 OK bug 45450 http://tally.distributed.net/rc5-64/psummary.php3?id=196242 ERR bug 45781 but same as bug 44483 ?? bug 45977 http://www.fenk.wageningen-ur.nl/~oever/portaloo.html Page is now 404 ERR bug 46025 http://www.arcor.net/index.shtml A (DOCTYPE unrelated) minor problem, filed new bug 46950. OK bug 46128 http://www.irc-scripts.com/ OK bug 46155 http://www.berlin-consortium.org/news.html OK bug 46232 http://www.sun.com/developers/openoffice/ OK bug 46250 http://www.sferi.com/jack.html OK bug 46255 http://www.los-angeles2019.de/blade/books.html OK bug 46326 http://www.sun.com/software/whitepapers/wp-unicode OK bug 46642 http://www.logos-m.ru/~deo/bug10.html Other URLs mentioned: OK http://www.sgi.com OK http://www.benews.com OK http://opensource.lineo.com
Wewps, soory, was busy for the last couple of days! I'll open new now!
Hrmf, looks like I don't need to file it after all, its working in build 2000072808! What build were you using when you were checking the dups? (Downloading 20000730 right now, but noticed that ftp.mozilla.org is growing increasingly slower by the week. I'm going 3.0kb/s on a cable modem over here for some reason. Any mirrors around that updates daily?)
I checked the dups using build 2000-07-28-08 on Windows 98 SE. Using build 2000-07-30-08, I still see that font problem at http://www.distributed.net - the text "Optimal Golomb Rulers!" has about half the font-size compared with NC4.74 and IE5.00
Let's mark this Verified, and write a new bug for remaining problems. ok?
I agree with leger on this. This bug is only for tracking, please open new bugs for any open issues. thanks!
Status: RESOLVED → VERIFIED
*** Bug 42818 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: