1 Posted by Shawn Wilsher on 27 June 2005 | Permalink

I would say option C is your best option because it doesn't let the drawback of option A happen, and prevents the extra work required by you from option B.

I also don't like option A because I learned almost all of my javascript knowledge from your site through your articles and your code. To me, that drawback is a big deal, but to others it may not be.

2 Posted by Mark Woodman on 27 June 2005 | Permalink

I vote: [C] Perfectly browser agnostic is nice, but there comes a point when an old dog has to be put down. Goodnight, Netscape 4.

3 Posted by Johannes Axner on 27 June 2005 | Permalink

I say C (or B if you can take the hassle), look to the future and make the site forwards compatible and don't show novice scripters bad standards.

4 Posted by Robbert Broersma on 27 June 2005 | Permalink

C+. Rewrite the page, trash the old version, and keep track (globally, not obsessively) of changes you had to make. E.g.:

„Scrolling Layer: replaced onmouseover attribute with element.onmousover for the sake of unobtrusiveness. Discarded Netscape 4 support.”

Depending on your actual point of view you might accommodate such tracking page with something like: „This log might incorrectly be intepreted as a guide to willingly abandon support for browsers that can be supported. The contrary is true: this page is meant as a trail of breadcrumbs leading to more complete browser support.”

5 Posted by JD on 27 June 2005 | Permalink

Clearly option C.

It's high time that we abandon these old browsers. So no one is tempted to use your code and make script work in older browsers!

6 Posted by Robert Nyman on 27 June 2005 | Permalink

I'd say C as well. For the reason to promote standardized DOM scripting instead of keeping some things that were proprietary for Netscape 4.

When it comes to your custom attributes, is replacing them with classNames instead an option for you?

7 Posted by Valentin Agachi on 27 June 2005 | Permalink

I have to go on C as well.
There is no point on supporting Netscape 4 anymore.
Long live DOM and modern browsers!

8 Posted by eNeRGy on 27 June 2005 | Permalink

Option C.
I agree with above statements from the other user reactions.
But disagree with the B option, it will only distract beginners and lead them into the wrong (old) way.
If you wish a totally sepparated version with all the old code would be an option. But keep it away from the 'live' version of quirksmode.
Hope this helps.

9 Posted by Tino Zijdel on 28 June 2005 | Permalink

Option C.
You could consider making one extra page with some information on scripting for 'ancient' browsers.

My question to you: why XHTML Transitional and not for instance HTML 4.01 Transitional? I suspect you will not implement mime-type sniffing and just keep on sending pages as text/html. Also from your article I have a sence that you will not check on wellformedness either, let alone make sure that you follow the guidelines from appendix C ( http://www.w3.org/TR/xhtml1/#guidelines ), so XHTML doesn't seem like a logical choice to me...

10 Posted by Stuart Colville on 28 June 2005 | Permalink

Yep I'm for C too. Naturally the new script will degrade gracefully for Netscape 4, in which case the old version can be safely sent on it's way to the bit bucket.

11 Posted by Scott Severance on 28 June 2005 | Permalink

I prefer C, although B is acceptable. Netscape 4 isn't worth supporting, as it's no longer very common and is a real nuissance.

12 Posted by Aaron Barker on 28 June 2005 | Permalink

Option C.

Everyone has already said what I think. The tons of extra pain you would have to go through for a < 1% browser isn't worth it.

13 Posted by Tim Connor on 28 June 2005 | Permalink

Long time reader, etc, etc.

Option C

As to the #4 issue of not converting pages: I know you've weighed in against overloading css selectors for attaching javascript events, but it is one of the few relatively semantically acceptable solutions that validate, when you want vanilla XHTML. Perhaps solutions involving things like Dean Edward's cssQuery or http://www.ripcord.co.nz/behaviour/ are acceptable for attaching behavior for public sites, where for various reasons you don't want or need to roll a custom DTD?

Of course, I fall in the other camp on the breakdown of behavior versus presentation for simple scripting of navigation elements and the like, so maybe that skews my view. ;)

14 Posted by Tijs Teulings on 28 June 2005 | Permalink

+1 for option C. Succes PPK.

15 Posted by Jacob on 28 June 2005 | Permalink

C.

I'd say B gives the best result - people learning javascript will not get confused with "old" coding styles, and the compatible versions are still there should someone need them.

So, in order to save you a lot of work, I'd go with C if I were you. "QuirksMode.org is supposed to be perfectly browser agnostic" - yes, and don't get me wrong, this is a good thing, but NN4 really is ancient now and I think people can safely code using non-NN4 methods without causing problems.

16 Posted by Tom on 28 June 2005 | Permalink

C, NN4 needs to die.

Perhaps you could add a slight footnote?

"This used to be the way we did it, how silly were we?"

17 Posted by Winter Knight on 28 June 2005 | Permalink

C.

I'm sure that at some point during the climax of the browser wars, you knew this day would have to come eventually. As long as they keep making browsers and you refuse to ditch them, you will eventually be supporting so many that you will go insane.

Besides, as long as you keep treating NN4 as the retarded brother who needs special attention, you won't be truly browser agnostic.

18 Posted by Angus Turnbull on 28 June 2005 | Permalink

I'm in a similar-ish boat. Most of the older scripts on my site were designed in the NS4/IE5 days and operate under the "NS4 as a lowest common denominator" assumption. I've actively maintained them, so they work in Safari/Mozilla/Opera et. al., but I'm slowly taking Option (B).

That is, I'm writing and uploading separate newer scripts to cover each genre (menu, tooltip, remote content loading, etc), that are built around DOM standards without any legacy v4-browser code. The old ones I intend to keep available with links to use the newer ones as appropriate.

In your case though, due to the greater number of scripts, I'd follow the advice of the throngs above and shoot for (C).

19 Posted by Gérard Talbot on 28 June 2005 | Permalink

I vote for C.

And I think HTML 4.01 strict makes much more sense to me than XHTML 1.0 transitional.

NS 4 is a browser which was designed more than 9 years ago (development started around march 1996). NS 4 definitively needs to die. MSIE 4 also needs to be forgotten entirely.

20 Posted by Dante on 28 June 2005 | Permalink

C.

I was going to vote for B, but then, your site is too bloody large anyway. No one gives a damn about NN4 compatibility anyway.

21 Posted by Alan Cooper on 28 June 2005 | Permalink

I vote for a modified A,
then (chronologically) a partial B, and eventually a modified C.

As one who is just beginning to learn this stuff, I would certainly appreciate having all the old versions flagged as soon as possible with a generic warning (comment in the .js?)including the url of a (generic) tutorial on what's wrong with them. This is, I think, a higher priority than actually fixing them.

Then, as you get round to updating, keep some of the old ones, more for reference than for compatibility, so that users can see the pattern and fix up their own old pages in the same way. (Since I've actually been beginning for almost 10 years now, I do have a few of those to deal with, and it might even be useful for someone like me to have to implement the change on something that was actually well written according to the standards of its day.)

With regard to the compatibility issue, isn't it true that all scripts written in the 'modern' style break the ancient "if a script can work in a browser, it should work in that browser" rule?
If so, it seems that option B amounts to cluttering up space so that a diminishing fraction of the potential effects can still be implemented in a browser that noone uses. (On the other hand surely storage is cheap enough these days that they could be archived for historical reference purposes.)

cheers,
Alan

22 Posted by Thomas Goyne on 28 June 2005 | Permalink

C, with a few (perhaps two or three) older scripts archived, along with commentary about why how they do things is no longer considered good.

23 Posted by charlie on 28 June 2005 | Permalink

C, supporting too old browsers is the way to a really bad internet, no innovation. People don't know about the power of new browsers. So we must "force" them to move to new ones.
Before google did it with with Gmail, when i talked about that, it was the worst thing a web developper can do. Now google did it, it is no more the worst thing you can do...

If we must wait for big companies to move the web, why the open source? why web standards?

24 Posted by ghgh on 28 June 2005 | Permalink

B, for the sake of hystorical preservation only, and yeah... HTML 4, not useless (and trendy) XHTML, pease.. =(

25 Posted by Jeroen on 28 June 2005 | Permalink

C.

and put up a nice grave for Netscape 4. throw a party even ;-)

hell of a job. good luck

26 Posted by Philippe Antoine on 28 June 2005 | Permalink

C

The uneasy one.

27 Posted by Alex Kapranoff on 28 June 2005 | Permalink

Option B.

It is the most practical one. And the hassle of having two versions of (some, not all!) scripts seems not to be that big, really.

28 Posted by Volker Rakow on 28 June 2005 | Permalink

Option B.

I can´t really give any better insight as to the pros and cons than you. It's only my opinion.

29 Posted by Jo on 28 June 2005 | Permalink

Definitely C.

Netscape 4.x is a pain to code for: both CSS and javascript.

The new scripts should all degrade nicely in whatever non-DOM browser (if possible). So keeping that in mind all will work out well.

30 Posted by Gerv on 28 June 2005 | Permalink

How about option D? "Put a note at the top of the page stating that the code is obsolete". Much less work, and no danger of misleading novice coders.

But then, if you are happy to do the work that C involves, then that's great too :-)

31 Posted by daipratt on 28 June 2005 | Permalink

Option C

Sure you wouldn't like to reconsider that 60% fugure? Muhahaha

32 Posted by Masklinn on 28 June 2005 | Permalink

I'd vote for B, even though it'd be the tougher on you I think this kind of things should be kept, if only for history's sake.

33 Posted by ppk on 28 June 2005 | Permalink

Well, at the moment C seems to have the upper hand. Voting isn't closed yet; please continue to add yours.

Gerv: your option is interesting, except that I'd have to declare about two thirds of my JavaScript pages obsolete, and I feel that's really too much.

Custom attributes: I'm not going to take a decision right now. They'll stay for the moment.

Thomas: archiving just a few oldies might be a good idea. But which ones?

HTML vs. XHTML: Part of the reasons I'm going to switch slowly is to find out which problems XHTML will give. I'm going to treat a W3C validator message "Valid XHTML" as the touchstone for my pages; and the validator doesn't say anything about MIME types.

Alan: "isn't it true that all scripts written in the 'modern' style break the ancient "if a script can work in a browser, it should work in that browser" rule?"
No. Modern W3C DOM scripts work only in modern browsers, so this rule is satisfied.

34 Posted by Mark Chaimungkalanont on 28 June 2005 | Permalink

Definitely for C.

I've absorbed and learnt so much from quirksmode it's hard to imagine not having it here. It's the first place I send people who want to find out more about client side coding. I'd love to see the older pages brought up to speed to make it easier for people to use all resources with confidence. It's hard to eulogise ppk enough for the work he's put in to make this one of the invaluable and readable resources on the web. We really do appreciate the great amounts of thought and quality invested in this site!

35 Posted by T.Willmot on 28 June 2005 | Permalink

Deffinately C. you have to go with standards and who needs Netscape 4 compatibility anyway?

36 Posted by Nick Fitzsimons on 28 June 2005 | Permalink

C for me - support for Netscape 4 is as relevant as support for IE 3 or Netscape 2, neither of which, I assume, is high on your list of priorities :-)

On the other hand, I can see benefits in B, if only so that future generations of scripters will be able to see the horrors we had to deal with in the first few years. But you're the guy who has to pay for the hosting... maybe you could archive the defunct stuff as zipped downloads, rather than having it live on the site?

37 Posted by Will Rickards on 28 June 2005 | Permalink

[C]

Are your pages available in the way back machine? Is it possible to just link to the previous version using that facility?
Either way I don't think dropping Netscape 4 support is a bad thing. If you follow the separation of behaviour and structure, netscape 4 just doesn't get the behaviour like any other out of date browser. Maybe your experience in rewriting the scripts will remind you of all the quirks netscape 4 requires. You could create a new page or set of pages that document those issues and include it for readers that have to support netscape 4.

38 Posted by Will Rickards on 28 June 2005 | Permalink

Also another thing you might consider is letting some of your readers submit revised scripts to you? Make your job easier?

39 Posted by Tino Zijdel on 28 June 2005 | Permalink

"Part of the reasons I'm going to switch slowly is to find out which problems XHTML will give."

You're not likely to encounter any problems as long as you sent it with a text/html mimetype since browsers will interpret is as HTML instead of XHTML. For a browser the DTD doesn't matter much; only some browsers use the DTD to determine whether they should render in standards compliant mode or quirksmode.

"I'm going to treat a W3C validator message "Valid XHTML" as the touchstone for my pages; and the validator doesn't say anything about MIME types."

The validator has it's limitations. Obviously the validator for instance won't be able to check mimetype when you're using the file upload feature.
Also, as I said before, it is allowed to use text/html mimetype with XHTML 1.0 as long as you keep in mind the compatibility guidelines mentioned in appendix C of the recommendation. However, XHTML as text/html, since it is interpreted as HTML, doesn't have any advantages over HTML.

Maybe you should consider reading Anne's blog more often: http://annevankesteren.nl (I believe you met him last Saturday) ;)

40 Posted by Kevin Ireland on 28 June 2005 | Permalink

Modified B. Create an archive.quirksmode.org and copy all of the existing pages there. Don't worry about linking from the revised pages to the archived version.

I guess I'm a packrat at heart. Someone somewhere might have a reason to look through these. Unless the cost of the storage space is an issue, keep them - just in case. By giving just a single entry point into the archived content (rather than crossreferencing each page), the size of the main site remains effectively unchanged.

I like the idea of help from readers - there are a lot of us. Perhaps via a wiki?

41 Posted by Tanny O'Haley on 28 June 2005 | Permalink

Option C. I also think HTML 4.01 strict makes much more sense than XHTML 1.0 transitional. I liked Russ Weakley's take on xhtml vs html strict with includes a few good resources in the Ten questions for Russ Weakley article at http://webstandardsgroup.org/features/russ-weakley.cfm#xhtml

42 Posted by David on 28 June 2005 | Permalink

I'm with Gerv (comment #30). Put a note up saying that the code is obsolete, and that it is not meant to be an example of current best practices. Less work for you, and it'll prompt people who don't know what they are to find out what the current best practices are.

And, of course, it's possible that someone may need to make a Netscape 4-compatible script. Can't for the life of me think why, but given management these days...

43 Posted by John Hansen on 28 June 2005 | Permalink

[C] - Standards-based code takes less time to download, less time to code, and less time for a prospective student to figure out. Because of the influence of people like you, Zeldman, Cederholm, etc, web programmers are becoming much more knowledgable, and it will only do your readers a huge service if you lead by example.

I don't see the need to archive the current version of your site. Even if your scripts might not work with Netscape 4, using standards-based code will ensure the readability of this site in any browser by degrading gracefully.

44 Posted by Austin Matzko on 28 June 2005 | Permalink

B
How are novice scripters supposed to know what's now bad practice unless they see it labeled as such?
Besides, you never know when someone might need to deal with an old browser.

45 Posted by Alex Lein on 28 June 2005 | Permalink

B
While option C will probably win, I'd rather have a new script with a link to the old method in case (for some unholy reason) I need to code for NN4.
The reason for my opinion is that I develop and maintain B2B sites, and about 25% of all my IE traffic is from IE4. That's a sizable chunck to worry about.

46 Posted by Matt McCarthy on 29 June 2005 | Permalink

Why XHTML at all?

Are you planning to send as application/xhtml+xml to browsers that will accept it? If not, it's still getting treated as text/html. If yes, Firefox will not render your pages progressively (only supported for text/html today).

Are you planning to take advantage of its being XML, like using MathML in your documents?

You can achieve separation of content from presentation and behavior using HTML 4.01 just as well. Plus, you can still have standards-mode rendering and be spec-compliant.

I appreciate XHTML on sites that are useful as data sources for other programs (screen scraping), so I can parse XMLHTTP-requested copies of the document with DOM methods. Otherwise, meh.

47 Posted by Emrah BASKAYA on 29 June 2005 | Permalink

Option C

I am strictly AGAINST any Netscape 4 support esp. in leading sites like yours. Let those users upgrade, if there is left any.

Of the 70000 users that visited my humble site, there hasn't been a single NS4 users. I bet quirksmode, in the last 2 years, did not get more than 0.1% of NS4 users, and they need to be told they need to upgrade some time in the next century or so.

Also, about the custom properties. I don't know why it renders the pages invalid. Standards, while setting rules, should leave some room for flexibility. In a world where there is DOM+Javascript, I need to be able to give custom attributes to my tags, from earth to W3. Someone tell me why it should be bad thing to use custom attributes. Such pages should render as valid code, but with a seperate page of list of custom attributes in the page, so if we made a typo or sth, we could see it there. Another solution would be to reserve at least 2 or 3 custom attribute names that wouldn't render the pages invalid, in the XHTML specification. But some people choose to think they are living in another planet, unfortunately in some of the key places that decide the future of the web, they probably would like the web to look and behave the same.

Please keep on using custom attributes and endorse it. We need to have a bit of freedom. Getting a valid XHTML mark is a trivial issue, when you have conformed to the core of the specs, and when your site looks good on all major browsers.

48 Posted by Kristjan Kannike on 29 June 2005 | Permalink

I concur with Kevin Ireland for a modified B (a separate archive), in order to make the life of future researchers easier. (And give perspective on new vs. old ways: it is insightful to see how the things have changed.)

49 Posted by Raj on 29 June 2005 | Permalink

Well, I see most folks going for option C. Although I can understand most of the reasons behind choosing for that option, I would rather stick with option A. The risk of ppl picking up wrong habits could be miminized by adding annotations that this code is onle there for historical reasons to demonstrate how it should NOT be done in light of current developement options.
This way you would end up with nice collection of examples to demonstrate why the current alternatives are better.

50 Posted by JD on 29 June 2005 | Permalink

Raj,

it's well known that people don't read any notes. They simply copy/paste the example code. Ask MSDN site about it.

And I guess things are really easier for ppk here as everyone has voted for option C. :)

JD

51 Posted by Joost Diepenmaat on 29 June 2005 | Permalink

I'm all for option B. It'll hardly be more work than option C and why throw away all the hard found experience? By the way: surely having a big site is better than having a small one :-)

52 Posted by sam nothingness on 30 June 2005 | Permalink

option B Because It's not much work, People can see the old way and the new way and the 10 people left using NS4 can still use the site

53 Posted by Fuzztrek on 2 July 2005 | Permalink

C.

I pity anyone who needs to know how to do something in Netscape 4, and even more so for anyone who WANTS to know :(

54 Posted by Faruk Ates on 2 July 2005 | Permalink

Go for option C, is what I say.

"Drawback: even though Netscape 4 compatibility is possible, this site no longer provides it, and QuirksMode.org is supposed to be perfectly browser agnostic."

It isn't already, then, I presume? In that case, even more reason to go for C, as it's the one option that is most forward-compatible and at the same time provides the highest-quality content in the end.

55 Posted by Paul on 4 July 2005 | Permalink

Option C

I suspect the few people viewing a site like this with NN4 do that on purpose, just to see what happens.

Backwards compatibility is nice, but at some point one has to drop obsolete code and move on.

56 Posted by Martin on 5 July 2005 | Permalink

Modified option B.

Don't re-write but July 2005 and earlier versions keep the way they are - in Archives with a note saying the code is obsolute.

From August 2005, start from scratch using valid XHTML.

57 Posted by ppk on 11 July 2005 | Permalink

Result of the vote:

Option C: 37 votes (77 %)
Option B: 11 votes (23 %)

Accordingly, option C will be implemented.