Seeking a Browser Compatibility Reference? 85
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."
Re:Simple (Score:2, Informative)
It renders very nicely in IE. It looks almost exactly the same in Mozilla, Netscape, Opera, Amaya, dillo. It probably looks good for things like WebTV too. And it's perfectly useable in links or lynx.
I know you're going to say "But it looks like shit". Fuck you. the web is about content. You think Slashdot got to be popular because it's loaded with flash animations and background midi music?!!
It looks OK, it's got 'content' that people obviously want to read, and it works with practically any browser.
Re:Simple (Score:2)
Slashdot has design. Design can be content. Usability is assisted by good design, not bad design (although you seem to group all design similarly).
You have not solved the problem, as you claim, as they are talking about DHTML, not HTML.
webmonkey (Score:4, Informative)
"basic" is right (Score:2)
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)
http://www.anybrowser.org/campaign/ [anybrowser.org]
Re:Any Browser (Score:2)
Re:Any Browser (Score:1)
Teach a man to fish . . . (Score:3, Informative)
See http://www.webstandards.org/learn/ for a good start!
Re:Teach a man to fish . . . (Score:1)
My advice... (Score:2, Insightful)
HTML compat. by tag and attribute (Score:3, Informative)
HTML isn't really a compatibility problem anymore (Score:2)
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.
Thanks for the site link (Score:2)
CSS Property Support [ncdesign.org]
CSS Selector Support [ncdesign.org]
It doesn't cover how well each feature is supported though.
A few rules of thumb (Score:1)
Re:A few rules of thumb (Score:2)
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.
Re:A few rules of thumb (Score:2, Funny)
Re:A few rules of thumb (Score:3, Interesting)
--
Re:A few rules of thumb (Score:2)
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.
Re:A few rules of thumb (Score:2)
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...
Re:A few rules of thumb (Score:1)
Re:A few rules of thumb (Score:2)
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).
--
Re:A few rules of thumb (Score:2)
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!
Re:A few rules of thumb (Score:2)
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.
--
Re:A few rules of thumb (Score:2)
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.
Re:A few rules of thumb (Score:2)
Incorrect (Score:2)
The same story with the "innerHTML" property.
Re:Incorrect (Score:1)
Mozilla supports Marquee, and
Re:Incorrect (Score:2)
Re:Incorrect (Score:2)
Oh, well. You get what you pay for, I guess.
Re:Incorrect (Score:2)
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?
Re:Incorrect (Score:2)
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.
Re:Incorrect (Score:2)
That one sentence sums up why nobody gives a damn about Mozilla.
Re:Incorrect (Score:2)
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.
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.
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.
Re:Incorrect (Score:2)
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.
Re:Incorrect (Score:2)
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(!!!).
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
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.
Re:Incorrect (Score:2)
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.
Re:Incorrect (Score:2)
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.
Re:Incorrect (Score:2)
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.
More and more??? (Score:2)
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.Re:More and more??? (Score:3, Insightful)
Browser conformance (Score:4, Informative)
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?
Code for the content, not the browser (Score:2, Insightful)
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.
Re:Code for the content, not the browser (Score:2)
<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.
Conformity DNE, not even in IE (Score:1)
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]
Re:Conformity DNE, not even in IE (Score:1)
Re:Conformity DNE, not even in IE (Score:2)
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).
Re:Conformity DNE, not even in IE (Score:2)
--
CodeBitch (Score:4, Informative)
Re:CodeBitch (Score:1)
Re:CodeBitch (Score:2)
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).
Re:CodeBitch (Score:1)
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)
Peter-Paul Koch's site (Score:1)
CSS Guide (Score:1)
It's a bit out of date (no details for N7/Opera6/7), but a very detailed breakdown of CSS support in other browsers.
vendors' responsibility (Score:2)
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.
Re:vendors' responsibility (Score:1)
Re:vendors' responsibility (Score:2)
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.
I used to try (Score:2)
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)
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.
Re:I used to try (Score:2)
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....
Re:I used to try (Score:2)
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"?
Actually... (Score:2)
Re:Actually... (Score:2)
Microsoft actually had better CSS support in IE5.x than it does in 6.
Balance Money & Time (Score:3, Interesting)
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)
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.
Re:I disagree (Score:2)
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.
For all german speaking web-developers (Score:2)
Screw the browser war. (Score:2)
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 (Score:1)