Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
The Internet

Seeking a Browser Compatibility Reference? 85

Posted by Cliff from the dealing-with-the-minutae dept.
Fr05t asks: "Gone are the days of being able to use the W3C specs for DHTML and Javascript as a solid reference for every browser. To make things worse I've been finding more and more I'm required to build richer web content that runs on all browsers. I've found many books that have a chapter on Browser Compatibility, but is there such a thing as a complete guide to the incompatibilities between IE, Netscape, and Opera? I'd even settle for a site dedicated to the documentation of the browser SNAFU."
This discussion has been archived. No new comments can be posted.

Seeking a Browser Compatibility Reference? More

Seeking a Browser Compatibility Reference?

Comments Filter:

  • webmonkey (Score:4, Informative)

    by capoccia ( 312092 ) on Friday January 03, 2003 @04:51PM (#5009104) Journal
    Lycos' webmonkey has a basic chart [lycos.com].
    • According to this table, DHTML is supported by IE 4.0 and up. That's actually pretty useless. What is their metric? That you can add an element programmatically?

      DHTML is the fusion of DOM, scripting, and CSS. But it doesn't cover how complete the DOM support is (eg. does it support mutation events?), how powerful the scripting support is (eg. are regexes supported in their version of ECMAScript?), or how standards compliant the CSS is (eg. is the box model and float handled correctly?).

  • Any Browser (Score:2, Insightful)

    by jpsst34 ( 582349 )
    This might be helpful...

    http://www.anybrowser.org/campaign/ [anybrowser.org]

  • Teach a man to fish . . . (Score:3, Informative)

    by Mordant ( 138460 ) on Friday January 03, 2003 @04:54PM (#5009129)
    Instead, why not look for tutorials on generating content which can be read by most everything?

    See http://www.webstandards.org/learn/ for a good start!

  • My advice... (Score:2, Insightful)

    by MattCohn.com ( 555899 )
    Put as many widgets as you want in there, as long as it works in all browsers. There are lots of things that Opera and Netscape will slip up on, and things that IE also dives rendering. One thing that everyone has been (rightfully) bitching to MS about is PNG support. Come over here [entropymine.com] with a bunch of diffrent browsers and compaire results. Another thing I found to not work in IE is the top logo on this page [extremeboredom.net]. The first example you might want to stay away from because it'll make your site ugly if it fails, but the second one is fine. For people still looking, in Opera the top logo is fixed when scrolling like it should be, and in IE it moves. This kind of thing adds to the coolness of the site, but if you can't see it it's really no big problem.

  • HTML compat. by tag and attribute (Score:3, Informative)

    by sachmet ( 10423 ) on Friday January 03, 2003 @04:56PM (#5009150)
    NCDesign has a good list for NN/IE at http://www.ncdesign.org/html/list.htm [ncdesign.org] which will tell you, by tag and by attribute, which versions of those browsers have the support within them.
    • Aside from the fact that I was chagrined to find that my copy of Mozilla supports the marquee tag (formerly an IE-only tag), it's all fairly predictable; HTML isn't really a problem.

      The issues with browser compatibility are found in support for the DOM and (even more so) CSS. They have all supported table tags for years and the incompatibilities there are minor. What I really want are browsers that render the box model correctly, don't freak out when you use floats, and have sane implementations of "left," "right," margins, and padding.
    • While I still believe that HTML is a minor issue these days, the hobgoblins and headaches are with CSS.

      CSS Property Support [ncdesign.org]
      CSS Selector Support [ncdesign.org]

      It doesn't cover how well each feature is supported though. :(
  • That said, a Google Search [google.com] will generally do pretty well for you.
    • The browser market share is something like 99.9999% Internet Explorer
      Mozilla/Netscape 7 supports everything

      That's not true. Mozilla (perversely, in my opinion) does not support document.all. It's possible to use a different method to perform the same function, but it's unnecessarily verbose.
      • IE 6 (perversely, in my opinion) is moving away from document.all towards the W3C standard document.getElementByID. It's possible to use document.all to perform the same function, but it's unnecessary.
      • And using document.all is unnecessarily wrong. This was a proprietary extension introduced by Microsoft. It does not comply with the standard way of referencing elements used in the Document Object Model (DOM) and should not be used except when programming backwards compatible code for Internet Explorer 4 (I think 5+ supports the correct DOM references). This is bad practice, and I think it's a good think that the mozilla developers decided to leave it out, or else it would promote breaking the correct hierarchical structure.
        --
        • Two things. First, there's nothing wrong with proprietary extensions to an API. Gasp! Yeah, you heard me. There's nothing wrong with proprietary extensions to an API. If it works, implement it.

          Second, it's been quite a while since I did any web programming-- that company ceased to exist about 6 months ago-- but I do not believe IE 5 or 6 supports getElementById. My memory could be flawed on that point, but I seem to recall that a good deal of code had to be stuck inside conditionals with document.all for IE and document.getElementById for Mozilla.
          • but I do not believe IE 5 or 6 supports getElementById.

            Well, you're wrong. Programming DHTML for IE versions greater than 5 is a joy, because it does follow W3 DOM standards fairly well, as does Mozilla.

            DHTML support only goes straight into the crapper once you have to support IE 4 or NS 4. Those two programs are fucking hideous to program for, since their object model is almost entirely incompatible, with each other and anything created since then. Part of that incompatibility was "document.all", which you should really give up using...
          • Actually you only need to do the conditional once. Do to the dynamic nature of javascript all you need to do to have mozilla support document.all is define a function called all() that has a simple translation to the mozilla (dom) method and do a test for document.all == null. If its null assign document.all to your all() function. It works for just about everything. Sometimes you need to do a little extra work in your new function because it doesn't translate easily but I think its worth it not to have to litter your code with if(useragent.indexOf("blah")){ all over the place.
          • there's nothing wrong with proprietary extensions to an API

            In this particular case, I think there is, since the extension (which at the moment it was implemented may have been necessary due to lack of a standard) is overriden by a more consistent and well documented standards compliant extension (document.getElementById). Then, that extension should be dropped. As another poster pointed out, IE 5+ does implement the correct (DOM) way to do this. Microsoft itself seems to be moving away from document.all and favoring the DOM way (as evidenced by code samples in later tutorials from their site, IIRC).
            --
            • As another poster pointed out, IE 5+ does implement the correct (DOM) way to do this.

              Okay, I stand corrected.

              Then, that extension should be dropped.

              Why? Is the whole world going the way of Java, where every dot release deprecates whole swaths of the API? If both methods work, implement them both!
              • If both methods work, implement them both

                It's a simple matter of the rule of least effort. One method works for IE4 to 6, no Mozilla/Netscape. The other method works for IE5+/Mozilla/Netscape6+. The latter is more compatible and in the end will make you have less headaches when you have to update the code. The extra verbosity doesn't seem to be so expensive at this point, I think.

                --

                • It's a simple matter of the rule of least effort. One method works for IE4 to 6, no Mozilla/Netscape. The other method works for IE5+/Mozilla/Netscape6+.

                  But the first method is already used in hundreds of thousands of lines of JavaScript code. (In my late, lamented company's vault alone.) Seems to me that "less effort" would be implementing the fucking thing in the browser.

                  This is just one example of the Mozillans' choices to stick to principles or standards rather than go the extra step for IE compatibility. It's obvious from their attitude that they generally couldn't care less whether anybody uses IE or not... so virtually everybody, even all this time after the release of "1.0," still uses IE.
      • Newer versions of Mozilla (and Netscape 7 I think as well) added support for document.all for script compatibility. That said, it's better to use the standard DOM methods as IE 5+ support most of them just fine.

        The same story with the "innerHTML" property.
        • Newer versions of Mozilla (and Netscape 7 I think as well) added support for document.all for script compatibility.
          Oh no they didn't.
          Mozilla supports Marquee, and .innerhtml, but that's about it for MS-specific stuff.
          • Sorry about that...I was remembering discussion about this incorrectly. I stand corrected.
            • But it does kind of prove the point. They could have added support for document.all, just like they did for innerHTML, but they didn't, for reasons that I can only describe (as I did before) as perverse.

              Oh, well. You get what you pay for, I guess. ;-)
              • Perverse my ass. They added innerHTML because it was far easier (and in some cases faster) than the DOM equivalent. document.all adds nothing except IE dependance.

                As for needing document.all, you can add it yourself to point to the resources you need. Mozilla's JavaScript object model is quite flexible.

                Personally, I haven't missed document.all. I could see where you might need it for maintenance of existing scripts, but I would categorize it as perverse.

                Now, IE 6's behavior in fixing the box model broken in IE 5.x but not allowing the CSS2 selectors so all of the existing CSS pages break: that's perverse.

                Then again, not as perverse as iCabs support for CSS2 selectors but complete brainfuck with regard to CSS rendering implementation.

                There's plenty of perversion in web browsers. Why pick on Mozilla's ommision of document.all?
                • document.all adds nothing except IE dependance.

                  I think the words you're groping for here are "compatibility" and "convenience."

                  As for needing document.all, you can add it yourself to point to the resources you need.

                  Since it's trivial to implement it with JavaScript, and it's a feature of 95% (maybe more) of the browsers out there, why not implement it in the engine itself? Arguing that it's an easy thing to add yourself doesn't make a very compelling argument against implementing it in the browser, in my opinion.

                  There's plenty of perversion in web browsers. Why pick on Mozilla's ommision of document.all?

                  Because Mozilla is the tall poppy. The Mozillans hop on pop about their rigid and total standards compatibility, while for no good reason breaking compatibility with the vast, vast, majority of browsers and of JavaScript out there. Makes no sense.
                  • I think the words you're groping for here are "compatibility" and "convenience."

                    No. The word I was "groping" for was dependence. document.all is not a good API. The only reason to implement it is for compatibility with IE.

                    A lot of pages write to that API. And there's the rub. Having two APIs that do the same thing (the W3C standard way and the Internet Explorer way) confuse new developers as to the correct solution and perpetuate a suboptimal solution. IE 5+ supports that W3C standard API. IE 4 has a smaller marketshare than Mozilla/Netscape at this point.

                    Mandating that people reimplement all IE APIs reinforces dependence. It implies ownership of the web by Microsoft. I have no problem with it being the most used browser, but I refuse to cede ownership of what I consider a public resource.

                    Having a standard means that you aren't dependent on one vendor or solution. Having a standard means that if someone comes up with something better, you can use it. If you use the Apache web server and decide to switch to IIS or iPlanet or Zeus you can. Why? Because any browser can talk to any of them. Why? Because they all implement the HTTP standard.

                    As a user, if Mozilla doesn't serve your purposes, you can use IE. No one is stopping you. As a page author, there is little excuse. Sticking with standards is an assertion that the message is more important than the messenger.
                    Since it's trivial to implement it with JavaScript, and it's a feature of 95% (maybe more) of the browsers out there, why not implement it in the engine itself? Arguing that it's an easy thing to add yourself doesn't make a very compelling argument against implementing it in the browser, in my opinion.

                    You misunderstand. I think that implementing document.all in its entirety is non-trivial. What I was suggesting was that you code in the functionality that you are using currently -- most likely less than the full object hierarchy for document.all. Personally, as I don't use and don't care about document.all, I'm quite pleased that Mozilla developers are concentrating on other items. Remember that Mozilla is Open Source. Features find their way in because someone wants to scratch a personal itch. Perhaps you could get AOL/Netscape to push for the feature, but as they haven't cared thus far, it doesn't seem people are clamouring to pay them for the feature.
                    Because Mozilla is the tall poppy. The Mozillans hop on pop about their rigid and total standards compatibility, while for no good reason breaking compatibility with the vast, vast, majority of browsers and of JavaScript out there. Makes no sense.

                    A clean API that is used by everyone -- including Microsoft -- makes perfect sense. Just as Microsoft has dropped full support for DOS and Windows 3.x programs, it's time to drop document.all. Backward compatibility is a noble goal but not at the expense of progress. Taking the time to implement it is sinking time into a feature that is already obsolete.

                    The Mozilla project's stated goal is standards compliance -- not IE compatibility. If it doesn't serve your needs, don't use it. If you're bitching about it as a scapegoat for your own non-standard scripting, shame on you. If you're bitching about it because a bank site requires document.all, gently remind them that you're giving them your money.
                    • document.all is not a good API.

                      Why?

                      Mandating that people reimplement all IE APIs reinforces dependence. It implies ownership of the web by Microsoft.

                      Pfft. Re-implementing IE's API's gives users convenient options. Forcing users to change their code to support a browser that nobody uses anyway is a recipe for permanent marginality.

                      As a user, if Mozilla doesn't serve your purposes, you can use IE. No one is stopping you. As a page author, there is little excuse.

                      Huh? The only mandate on developers is to use what works. If document.all works 95+% of the time, then it's very, very hard to argue that they were wrong to use it.

                      You misunderstand. I think that implementing document.all in its entirety is non-trivial.

                      I understood exactly what you're saying. Why would implementing document.all be non-trivial? The code to perform that function is already there; all one would have to do is add a new entry point for it.

                      A clean API that is used by everyone -- including Microsoft -- makes perfect sense.

                      No, it doesn't. This is a popular misconception. A "clean API" is of no value whatsoever. What makes perfect sense is software that does what users need, want, and expect it to do. Breaking compatibility with the de facto standard in favor of a de jure standard that is at best irrelevant makes no sense at all, from any perspective.

                      The Mozilla project's stated goal is standards compliance -- not IE compatibility. If it doesn't serve your needs, don't use it.

                      Don't worry. I don't. Neither does virtually anybody else. Given this attitude on the part of the developers, it's easy to see why.
                    • A quote from a person on mozillazine:
                      All those kludges are awful. Microsoft revealed that they have absolutely no taste for API design. Binding the event object to the global window object was a stupid decision, it's like using global variables. And making an "all" array of everything is silly too. The document.layers API is awful too, each layer is a whole document! Maintaining these kind of kludges for ever is what make the software we use more bloated. It's also something which makes software development more difficult (you can be assigned to a project coded for these). If you knew the Microsoft Windows API you would know why the APIs are important and they should not be allowed to rotten.


                      It's a bad API. So was NS4's layer API. The W3C DOM is a better API. It is clear, concise, well-documented, and supported by more browsers in use today than document.all(!!!).

                      Neither does virtually anybody else. Given this attitude on the part of the developers, it's easy to see why.


                      More people use Mozilla, Netscape 6+, and the other Gecko-based browsers now than IE4- and Netscape 4 combined. The recent IE browser version support the DOM API in its entirety. If you code to the DOM spec instead of document.all, you will get more browsers than by using document.all. The "du jour" solution has greater penetration than your de facto solution. Why code for 95% when you could have 99%?

                      By all means, go to Microsoft's own tech documentation site [microsoft.com], select "APIs & References" from the search dropdown, and enter in document.all. Go ahead. I dare you. The ONLY documents you will get back relate to the DOM API. Even Microsoft is trying to dump document.all. Go look up the .NET documentation. Try to find document.all instead of a DOM example. You won't find it. Who do you think was one of the biggest contributors to the DOM spec? That's right: Microsoft.

                      Fix your scripts now or fix them later. I don't care. But you've backed the wrong horse.

                      If your goal is eyeballs, standards make more sense. If your goal is simply to avoid fixing your scripts, at least be honest about it. Don't pretend that you are doing for the users' benefit.
                    • More people use Mozilla, Netscape 6+, and the other Gecko-based browsers now than IE4- and Netscape 4 combined.

                      Ohhh-kay. So? More people use OmniWeb than Spry Mosaic, Lynx, and Emacs/W3 combined. But they're all utterly irrelevant compared to IE's market dominance.
                    • Thanks for not reading the sentence after that... *sigh*

                      If your goal is the greatest number of eyeballs with your scripting web site, using the DOM will reach more eyeballs than document.all. That's orthogonal to IE's market dominance.

                      98% is greater than 95%. So code to the 98%.

                      document.all = 95%
                      DOM = 98%

                      And in the future, that DOM percentage will approach 100% in every reasonable case (whether Mozilla becomes more popular or not) because of full support in IE -- that market-dominating browser you love so much. document.all could either gain in share (if IE dominance extends itself) or it could drop in share (if alternate browsers get a foothold, AOL moves forward with their Gecko-based client to Windows, and Microsoft doesn't deprecate the document.all API).

                      The DOM simply makes sense. document.all is potentially a limiting factor.
                    • If your goal is the greatest number of eyeballs with your scripting web site, using the DOM will reach more eyeballs than document.all.

                      Yeah, and if your goal is to make more work for your programmers for benefits that can only be expressed mathematically, then by all means let's leave document.all unimplemented.

                      The important point here is that only a fool would accept more work for a trivial increase in potential user base. The only consequence of omitting document.all is to continue to make Mozilla an unattractive alternative to IE for users. Par for the course.

  • To make things worse I've been finding more and more I'm required to build richer web content that runs on all browsers.

    With IE and it's 95% market share (Mozilla's numbers), I've found people care less every day about cross-browser compatability. It was a real problem when the market was 50/50, but that's been a while.

  • Browser conformance (Score:4, Informative)

    by __past__ ( 542467 ) on Friday January 03, 2003 @05:07PM (#5009274)
    "Gone are the days"? WTF? Browsers have never been closer to spec conformance than today. (Well, possibly except WorldWideWeb.app, being written by TBL together with the first HTML spec).

    Sure, it is still amazing that there is no Browser fully conforming to HTML 4 or CSS 2, both being W3C recs for years, but to what kind of "standard" would Netscape 4 possibly conform?

  • I know that it seems impossible to design a website *without* purposefully working around browser inadequacies, but that's almost what we have to do.

    As far as I'm aware, "browser compatibility tables" are artefacts of the past -- there's simply too many weird versions out there (and that's only considering Netscape 4!) to have a hope of covering it all. Besides, if we code around every single problem, we encourage users to stick with their current browsers for ever and ever, generally enshrining the errors for future posterity.

    I have found that if you follow "generally accepted good coding practises", most modern browsers can take it. If they can't, the breakdown is not horrible -- not like the hacks of the 1990s that completely fly apart on Mozilla today.

    If you perpetually correct for all of today's faults, you hold the web back. If you code for compliance with an eye out for any serious showstopping errors, you help the evolution continue... and that's something we really need.
    • Netscape 4 is a pile of crap. Just use the following in your pages.

      <link rel="stylesheet" type="text/css" href="thecssdeclarations.css" media="all"/>

      Netscape 4 (and other obsolete browsers) still get the content, but you are free to move on and use modern layout techniques for better browsers.

      The use of @import in your CSS file is another good method to prevent bad browsers from doing stupid things.

      Don't want the page to look like it was made in 1995? Upgrade your browser. Don't care if the page looks like it was made in 1995? Keep using Netscape 4.

      Simple.
  • Good luck trying to get ANY consistency if you really want to separate info and content!
    I have written sites with CSS [w3.org] for layout instead of Tables as the W3C [w3.org] recommends [w3.org]. It does not render consistently in ANYTHING. IE6SP1 displays it differently from IE6, IE5 (SP1,2), IE4 and Opera's CSS support is lacking. I've checked the page in Phoenix and it renders fairly well.

    For more information, I've saw a good tutorial on CSS stuff at Glish.com [glish.com]
    • separate info and content! oops, that would be style and content.

    • I have written sites with CSS [w3.org] for layout instead of Tables

      Also known as the Ulcer Generating Procedure if you try to exactly position image slices and whatnot. Using CSS for positioning requires the designer to seriously rethink layouts, and accept a bit of cross-browser slop. That's what makes it interesting (he says as he tears out what remains of his hair).

    • I hear you. I still use table based layouts, since the table behaviour has been pretty much standardized (there are a few quirks, but not as many as css). It will be a while before CSS based layouts render consistently. Especially those involving complex arrangements of boxes w/without borders, you know, the kind that are most easily obtained by using tables with 1px wide columns with black backgrounds. Currently, I use CSS mostly to define background colors, text properties and some divs. Not ready yet to use them for layout exclusively.
      --

  • CodeBitch (Score:4, Informative)

    by qengho ( 54305 ) on Friday January 03, 2003 @05:37PM (#5009538)
    MacEdition has a good writer who tirelessly flogs web standards [macedition.com]. She has several guides to cross-browser CSS support at the bottom of the page.
    • Thanks! And the MacEdition Guide to CSS2 support in Mac-only browsers [macedition.com] has been updated for Safari.

      • the MacEdition Guide to CSS2 support in Mac-only browsers [macedition.com] has been updated for Safari.

        I look forward to your thoughts on it. It's a good start, and they're doing more than giving lip service to standards, but the CSS support is flaky (won't even load the W3C's test pages, let alone render them, but I think that's another issue since it's complaining about a missing plugin for "text/html". Heh).

        • Yes, it's the text/html object issue. If you change each URL to testNNN.html instead of secNNN.html, where N are numbers or lower-case letters, you will get the page in full-window mode.

          OmniWeb has the same problem, BTW, has had for years. The Guide has been updated with new information several times in the past few days as I have time, so keep checking back and do send in new info.

  • O'Reilly's Dynamic HTML: The Definitive Reference (Score:4, Informative)

    by abh ( 22332 ) <ahockley@gmail.com> on Friday January 03, 2003 @05:54PM (#5009691) Homepage
    O'Reilly's Dynamic HTML: The Definitive Reference does an excellent job of describing which browsers support various functions and each HTML tag.
  • Try this [westciv.com.au]

    It's a bit out of date (no details for N7/Opera6/7), but a very detailed breakdown of CSS support in other browsers.

  • IMHO, the browser vendors should be at the very least *documenting* their level of standards compliance. It's bad enough that none of them are actually complying fully with the standards, but docs would go a long way. I would want something of this kind of form:

    BrowserX, V4.3:
    Complies mostly to XHTML 1.0 Strict / Frameset *
    Does not comply to XHTML 1.1
    Complies mostly to CSS2 **
    Complies to DOM Level 1
    Does not comply to DOM Level 2 ....
    * - Exceptions: Does not correctly implement img element alt property.
    ** - Exceptions: Does not render hover link colors correctly. Ignores paragraph font sizes.

    If every browser vendor would publish a definite conformance guide like that with their releases and patches, the web would be a better place.
    • If every browser vendor would publish a definite conformance guide like that with their releases and patches, the web would be a better place.
      Yes, it would. Opera do [opera.com]. mozilla.org do [mozilla.org]. If you dig hard enough in MSDN, even Microsoft do [microsoft.com]. You've just got to go looking for it all. And whether all those documents are 100% accurate is another question entirely...

      • Opera's page linked in your comment is exactly what I was talking about. Every browser needs to have that data documented in a roughly similar fashion. Preferably like in the Help documentation for the browser somewhere. Getting a browser and not knowing what standards it conforms to and how is like getting a car with no idea what type of fuel runs in it well or where the gas cap is.
  • ...but more and more my company has been asking m3 for things that only work IE...becuase thats what everyone else in the company is doing...so I gave up I code for IE and IE only now...
    Really what we need to is (I know I'll get killed for saying it) for all broswers to impliment DOM, CSS and javascript the way MS does...their browser dominates the market...so they should be the standard as sad as it is....
    Ideally MS would structly follow the w3c RFC's but they don't...so what are ya gonna do...

    • Re:I used to try (Score:3, Insightful)

      by ceejayoz ( 567949 )
      I code for IE and IE only now...

      Why not code valid XHTML? It renders perfectly in IE, as well as any other modern browser.

      Really what we need to is (I know I'll get killed for saying it) for all broswers to impliment DOM, CSS and javascript the way MS does.

      No, we need idiot web designers to code valid XHTML. I do it, it's easy - in fact, it's entirely automated - I send everything through Tidy [sourceforge.net] and it does all the work for me.
      • Everything I write is xhtml 1.0 compliant...thats easy....
        However not all broswers impliment DOM the same way which causes problems...and not all browsers support javascript the smae way either...then there are things I am asked to do that only IE does...such as automatic logins to web sites by readin NT security tokens....
      • My companies intranet (that i write) is valid xhtml1.0 transitional. Renders fine in IE5.5 and IE6 with minimal differences. In Phoenix (havent tried mozilla) its totally screwed. I asked in the phoenix forums about this and guess what they said:

        The code may be syntactically correct, but it could be logically incorrect

        Now is it me or does that sound like "Our browser doesnt support that unless its done in some wierd and wonderful way"?
    • IE 6 supports W3C standards quite well. Mozilla does it better, but IE 6 is close enough to get most things done. IE 5.0-5.5 aren't that bad in CSS either. They have their issues but they are a damn sight better than Netscape 4.
      • I write my pages with valid XHTML and CSS2. The pages will render perfectly in Mozilla and with slight tweaks, Konqueror and Opera. IE4.5 and IE5 will generally render quite well; however, IE6 is (almost?) IMPOSSIBLE to get to work.. the browser is just plain broken. It still doesn't properly render my pages.

        Microsoft actually had better CSS support in IE5.x than it does in 6.

  • Balance Money & Time (Score:3, Interesting)

    by gilgongo ( 57446 ) on Friday January 03, 2003 @07:27PM (#5010559) Homepage Journal
    Take the following facts:

    1. MSIE 5 commands about 40% of the market.
    2. MSIE 6 commands about 30% and rising.
    3. Netscape 4 has about 5%.
    4. Netscape 6 has about 5% and rising.
    5. All of these browsers render things differently.

    Next, take the following fact:

    The more work you spend making your code compatible, the more time/money you burn.

    Then consider this:

    Why do you want to spend this money/time on making your site compatible? How much time/money are you will to spend?

    In practice, I use the following rough formula:

    Code for the Majority Browser, then the next one in market share, then the next one until you reach the "10% Horizon" or until you think you're spent enough money/time (whichever is sooner).

    The lower the market share of the browser, the less point there is making your code compatible with that browser.

    • I disagree (Score:3, Informative)

      by ttfkam ( 37064 )
      First off, the browser stats vary dramatically by site. The stats I've been seeing lately have IE 6 ahead of 5.x (probably due to sales of computers with XP, Windows Update, and the gentle nudging toward v6 because of its standards support).

      If you code a page for the quirks of IE 5.x and tweak from there, you are coding for the past. It's quite clear that browsers are moving toward W3C standards support, not away from it. If you code toward the standards and tweak from there, you are much more likely to build a site that will stand the test of time and not break in newer browsers.

      As for availablity, if you code for valid XHTML, CSS, and WAI (accessibility) guidelines, older clients tend to degrade gracefully. Using "tricks" like specifying media="all" in stylesheet link tags or using @import makes it easy to code to modern browsers but make the content available to older browsers (like Netscape 4).

      XHTML+CSS with no tables and proper stylesheet declarations can make for beautiful sites that are both accessible to those with disabilities and browsers all the way back to Netscape 1.x.

      It requires that you give up on making Netscape 4 and IE 4 pretty though. But it sounds like you've done that already.
      • > First off, the browser stats vary dramatically by site.

        Exactly. That's why my formula says code for "the majority browser" - you need to first establish what that is/might be (could be IE6 could be JAWS ...)

        > If you code toward the standards and tweak from there,

        Again, I agree. But apply my formula: if that "tweaking" takes you to the 10% horizon, or takes up too much time, you should stop.

        My point is not whether code can look good or what will degrade gracefully. I have no doubt at all that you may well be able to make a beautiful site for all browsers in a reasonable time. Not all site designs are the same, however, so just go by the formula.

  • there's SelfHTML [teamone.de], an excellent HTML reference. It explains everything you want to know, together with examples and what versions of Netscape and Internet Explorer support the feature/tag/whatever in question. It covers HTML, DHTML, JavaScript and CSS 1/2. If there were also an english version avaible it could easily be the best HTML reference avaible, it certainly is for german speaking web-developers :-)
  • Honestly, I dont care what web browser is on top in ratings. I use mozilla, and thus I will code for mozilla. I have the luxary of not coding HTML for business, but for pleasure, and the people who view my sites are most likely going to be like minded and will have a high chance of using mozilla as well.

    Then to those of you who have to code for business:
    Screw Internet Exploder, Screw Nutscrape, Screw Mozilla. Code strictly to the standards. Any thing else is going to bite you in the arse 10 years down the line. Most browsers show some ability at following the standards. Also, standards change a lot less then what a browser renders. You code for MSIE 6 and then M$ decides to switch formats on you? Youre screwed. At least W3C doesnt change the standards too often. And if you need some fancy gizmo thats nonstandard but only one browser supports, then most likely you need to rethink your site design. Tastefully done, Tables and static images will please more people then a hyper-active flash super animation.
  • One of my favorites, though it hasn't been updated to include Mozilla yet, is here [blooberry.com]. Index dot HTML and Index dot CSS.

Slashdot Top Deals

If a thing's worth having, it's worth cheating for. -- W.C. Fields

Close