Closed Bug 44525 Opened 24 years ago Closed 24 years ago

[RFE] User option to force quirks mode for specified sites

Categories

(SeaMonkey :: Preferences, enhancement, P3)

Product:
SeaMonkey
Component:
Preferences
Platform:
x86
Linux
Type:
enhancement

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: spam, Assigned: matt)

References

Details

(Keywords: helpwanted)

Since bug 43274 now is marked fixed, and i still can't view around one third of my favourite sites with mozilla: It would be more than nice if i could add sites in preferences that "Always use quirks mode for these sites:" The wording should perhaps be more understandable - like "Display this site in old browsermode" or something. The enhancement would imply a collector of sorts, and url's listed in prefs.js or thereabouts. If i can't view my favourite sites - i simply can't use Mozilla - now or in the future - till the sites have coughed up new code. Since that is unlikely to happen "only" because of Mozilla, this enhancement is pretty urgent. IMHO: If MSIE on Windows can display a site Mozilla can't - forcing strict mode in Mozilla without any kind of "plan B" is plain suicide. The fact that MSIE on Mac also enforce strict mode for some sites, same way as Moz, doesn't account for much. Not as long as the IE for Win/NT is more sloppy and welcoming. It's just MS usual way of saying "install Windows instead", for once using "correctness" as an alibi. A further enhancement of a feature like this would of course be if Moz detects incorrect HTML on it's own, and suggest compatability mode for a site, so user can just click "OK" to add a site to quirks-list.
Great idea! When DTD nonconformance is detected, the browser should prompt the user to re-render the page using quirks mode. That could be less annoying if the dialog had a "remember this decision" box.
I personally don't want to see a window pop up everytime theres a 1 line error on the site that'll misrender. Personally I would see that being an excuse from people not to use netscape. I would say have an option in the advanced section the the preferences that allow people (probably coders, itt's, etc.) to enable DTD Strict Mode. I see that window popup of "Display this site in old browsermode" being excessive as "Are you sure you want to exit windows?" <click yes> "Are you positive?" <click yes> "No, I mean it, are you really sure, theres not turning back now!" <click yes> type thing, except its when your visiting websites. To me, thats more than an annoyance. Needless to say, something has to be done so people can disable the DTD strict mode. This suggestion from the reporter is very good, and I agree, something urgently needs to be done!
right, Jason.. could get annoying if uninvited. A while back someone suggested an "error-meter" on the bottom line of moz. That is a good idea, and could be used in this context: I vision a feature where a click on that error-meter would spawn an "Add this site to old browser-mode list?". Options on buttons could be "Add and reload" and "Cancel". (The 'add and reload' performing a super reload to overrule cache) If few errors while page load, it wouldn't be required to click error-meter at all. User will easily see if there are many many errors, mainly by how the page itself look. Secondly the "error-meter" would give a very rough indication of how bad things are. As for design, the "error-meter" could have that "cellular battery status" look - simply 4 "levels" or lines, where no lines would mean few or no errors, and 4 lines would roughly mean "more than 75% errors" or thereabouts. Some of the framework for all this is of course already onboard.. URL is known and stored somewhere, there is an engine to collect sites. A quick error detection/evaluation mechanism would probably be the tricky part.
It was bug 29404 i had in mind originally, but some sort of "error-meter" idea is discussed in several bugs, mainly bug 6211, which 29404 was marked a dup of later. 6211 is a request for a far more detailed and exact feature however, full xml, java and html validity check. Some wants a console for it, others would suffice with an icon of sorts.
Is this going to be on the beta2 radar? I believe this bug (DTD strict) should be addressed before being released. If not a fix, there shohuld be at least a warning on start-up that pages could be misrendered so the general user won't file 3000 bugs that it doesn't work.
What about using a menu for bug 6211, instead of a button: _____________________ | Show errors | |---------------------| |* Normal mode | +-|._Compatibility_mode_|------------------------------------------------+ | [X] [:::::::::::::] Document: Done (3.2 seconds) \+/ |V| ", [8] [/] | +------------------------------------------------------------------------+ Then whenever a page appears strangely, the user can glance at the icon; if it appears as a red cross (rather than as a green tick), they know that choosing `Compatibility mode' from the icon's menu might fix things. Whether the user had normal mode or compatibility mode set for a given page should be stored in the cache, but I don't think it should be a permanent setting.
As for caching, you could store the preference for quirk mode in the user's profile. On the next visit, if a DTD non-conformance problem is detected AND the history shows that the user chose quirks mode last time, Mozilla could automatically choose quirks mode on the user's behalf. If the page is cured of its DTD problems, Mozilla could take note of that and clear the quirks mode preference from persistent storage.
Ok, that would make it part of the data stored with the history, rather than with the cache. But we have a problem here. Mozilla can't tell what a `site' is (a site can be on more than one server, and a server like geocities.com can hold more than one site, yada yada yada). So how do we prevent the user from having to respecify the mode on every page they visit, on a malbehaving (but not necessarily misbehaving) site? We could take a lesson from the character encoding feature. When a server sends the incorrect character encoding, we can override it, and the encoding we specify is (I think) used for every page until we get to a page which has a different (and presumably correct) encoding specified (which usually means that we've left the misbehaving site). The equivalent to that would be to persist the rendering mode as long as any document we visited had exactly the same DOCTYPE as the previous page, and revert to Normal (strict) mode as soon as we visited a page with a different DOCTYPE (which would usually mean we'd left that site). But then we could easily cause problems if we went from one strict-doctype site site to another, where the second was properly authored. We'd end up rendering a properly-authored page in quirks mode, something which wouldn't be nearly as obvious as a page rendered in the incorrect encoding ... I'm running out of ideas here. CCing Ian.
Sounds like good ideas are flying, but I must say again... People hate nag screens. Especially reoccuring nag screens you can't disable. Can't we have a menu option of 3 choices? Because it's going to be at least 2 or 3 years after netscape ships out the final that people might probably care about fixing their errors. (Assuming Microsoft will ever follow suit by following web standards. (like hell.)) Menu setting are: A) Always use Quirk mode. B) Use strict mode until error found. C) Always use strict mode. Something more worded properly. To me its going to be very annoying that every 3rd new webpage I go to that mozilla will ask if I want to jump into quirk mode because theres an error on the webpage. Adding myself to the CC list because this will be interesting to see what the netscape boys are going to do! ;) I can't wait, I'm getting anxious already. *fidgets in his computer chair*
> I must say again... People hate nag screens. No, you needn't say it again, we've gone well beyond that idea now. > Because it's going to be at least 2 or 3 years after netscape ships out the > final that people might probably care about fixing their errors. (Assuming > Microsoft will ever follow suit by following web standards. (like hell.)) You've forgotten about the next version of AOL. Webmasters will start caring about fixing their errors pretty smartly, as soon as that is released. > Menu setting are: > A) Always use Quirk mode. No: because then turning on Quirks mode would be the first thing people did when they installed Mozilla (in order to get pages to look `right'), and the people who tried to write standards-compliant pages would gnash their teeth, and we might as well have not implemented the standards compliance at all. > B) Use strict mode until error found. No: if you've ever used iCab you'll know why that's not feasible. Only a tiny minority of pages have no errors in them, so the browser would end up in Quirks mode for most of the browsing session -- and we'd have the same problems as with (A) above. The rendering of many HTML errors would not be improved at all by switching to Quirks mode; and the parser can't be expected to know which errors on a given page fall into that category and which do not. > C) Always use strict mode. No: If that's a feasible option to offer the user, then this bug might as well be marked WONTFIX.
I think a "phaze 1" and "phaze 2" is an idea: 1: implementation of an error-meter and a dialogue (OR menu on it's icon) giving option to rerender page overruling the DTD, a "reload page in old brower-mode" 2: Dive the think-tank and puzzle out how and where to best implement a collector, (a separate "shadow bookmarks"?) - furthermore how big it should allowed to be, whether introduce new flags or not etc. -- The collector needn't even be a biggie in the beginning: This is a "band-aid" service for bad URL's. It could collect a "bottom 10" in the beginning, and refresh that list based on a "FIFO" principle, comparing to URL's in history. That approach will give users opportunity to at least see a page, and yet not stimulate faulty html. In addition, it makes it possible to implement the rough and basic part of a "panic-button" much quicker.
I think we should *not* have any user-controllable option for enabling quirks mode, partly because of all the problems listed above, and partly because if only a minority of sites are affected then forcing strict mode on those will encourage adoption of standards. If there is a site that triggers strict mode but was designed with the quirks in mind (even if the author did not realise they were quirks), then we need to add that DOCTYPE to the list of quirky doctypes. What is important is that enough sites render as in legacy browsers for Mozilla's adoption to be significant, and that future sites use standards. If a minority of small sites render per-the-standards and look ugly because of this, then tough, the authors should code to the standards. Now having said that -- R.K.Aa: You say "I still can't view around one third of my favourite sites with mozilla". What are these sites? Lets get *them* fixed rather than implement an override at this late stage. I would recommend a resolution of WONTFIX.
Ian Hickson: I think one has to balance ideals against reality here. Over the past 5 weeks around 30 dups have been annotated in bug 42388 (strict DTD collection bug). Some sites are major (kodak, sgi, apple, bbc and more). If you think a stricter browser can be educating - that's fine. You may be right - I hope you're right. But keep in mind there's noone more cynical than plain users. And users won't use a browser that can't display their sites. Recent surveys say MSIE has an 86% marketshare. Mozilla has a potential for altering that, for several reasons; it being a far better browser already than NC, and the verdict in the MS case. In other words: The timing is getting fairly good for a comeback of some significance. Sure wouldn't hurt. This RFE can be made a very light-weight, and yet make the browser more usable for "the masses". Mozilla won't choke on it, even if you consider it a camel. If you believe Moz is fit to be more than a developers "correctness" validator, isn't it also a point to encurage it to be widespread - and ASAP? Without waiting for code to catch up out there? There are features that obviously need more attention than this "bug" - but a "wontfix" seems to me plain silly.
A user option isn't going to do much good. If there's a problem with the default, then we need to consider changing the default, because most users won't know to change the option.
I agree with dbaron. There are far too many user options already, and the mass audience for this browser (AOL) is not going to understand conformance, quirks, and the history of HTML. I would really like to see mozilla use as much smarts as possible to automatically do the best thing for the user. Nevertheless, there should be an advanced option to enforce stric tmode for people who are checking their pages for conformance.
R.K.Aa: What David and Jeffrey said. However. Regarding the problems on kodak, sgi, and apple: Ouch! That's bad. Something there needs to be done. I'll bring this up in the newsgroups. David: Briefly, I would guess we need to either: evangelise the sites, make the strict DTD have slightly different error handling, or treat HTML4.0 as quirks and only 4.01 as strict. I would suggest the first (they need only use a 3.2 doctype, or transitional without a SysID, after all). I *still* think that an option to enable quirks mode is a B.A.D. idea.
What David says indicates he didn't read further than the summary. Jeffry utters a desire to force STRICT mode - the exact opposite of this bug. But whatever - good luck etc. I'll drop this RFE.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → INVALID
Resolved invalid? WTF? Its an RFE
There's an interesting point ... If Apple's site looks bad under Mozilla's strict mode, shouldn't it also look bad under MSIE 5/Mac's strict mode? If not, why not? [According to bug 43546, an RFE may never be INVALID. Reopening ...
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
... and resolving as WONTFIX.]
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
Hickson additional note, you asked: Here some "worst cases" of URL's i visit daily and now render bad or not at all: http://www.pcworld.no http://www.dagbladet.no (2nd biggest newspaper, oldest on web here) http://www.nrk.no (national broadcasting company) http://www.cybercity.no (my ISP)
I think the solution is to back off to 4.01, not to have a pref. All of the pages mentioned above are 4.0, not 4.01.
I agree with David. David, I assue you are escalating the DOCTYPE issue, yes?
Status: RESOLVED → VERIFIED
R.K.Aa: BTW, thanks for the additional pages. They are all HTML 4.0 Transitional, which is yet another reason to change our strict handling from 4.0 to 4.01.
www.moviefone.com (movie showtimes listings) is completely unusable as of 072400 on Linux (cvs build).
*** Bug 26575 has been marked as a duplicate of this bug. ***
*** Bug 84636 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.