Slashdot Mirror
Seeking a Browser Compatibility Reference?
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."
Lycos' webmonkey has a basic chart.
This might be helpful...
http://www.anybrowser.org/campaign/
How are you going to keep them down on the farm once they've seen Karl Hungus?
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!
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 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. 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.
NCDesign has a good list for NN/IE at http://www.ncdesign.org/html/list.htm which will tell you, by tag and by attribute, which versions of those browsers have the support within them.
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.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?
Programming can be fun again. Film at 11.
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.
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.
I write in my journal
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.
--
Overcaffeinated. Angry geeks.
We've solved the problem by writing everything to HTML4.01 and using CSS for the layout.
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.
455fe10422ca29c4933f95052b792ab2
MacEdition has a good writer who tirelessly flogs web standards. She has several guides to cross-browser CSS support at the bottom of the page.
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.
I write in my journal
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).
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...
Slashdot is jumping the shark. I'm just driving the boat.
O'Reilly's Dynamic HTML: The Definitive Reference does an excellent job of describing which browsers support various functions and each HTML tag.
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).
--
Overcaffeinated. Angry geeks.
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.
--
Overcaffeinated. Angry geeks.
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.
11*43+456^2
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?).
- I don't need to go outside, my CRT tan'll do me just fine.
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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!
I write in my journal
...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...
Power Corrupts,Absolute Power Corrupts Absolutely, leaving one person(group)in charge is absolutely corrupt.
While I still believe that HTML is a minor issue these days, the hobgoblins and headaches are with CSS.
:(
CSS Property Support
CSS Selector Support
It doesn't cover how well each feature is supported though.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
"And the meaning of words; when they cease to function; when will it start worrying you?"
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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.
- I don't need to go outside, my CRT tan'll do me just fine.
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 don't need to go outside, my CRT tan'll do me just fine.
there's SelfHTML, 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.
This
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.
--
Overcaffeinated. Angry geeks.
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.
--Giving to trolls for the benefit of us all
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.
I write in my journal
You, like so many other Slashdotters, seem to have forgotten that the purpose of the computer is to work for the user. Not the other way around.
I write in my journal