Slashdot Mirror
ADC Rates Web Browsers For Javascript Compatibility
blamanj writes "The Apple Developer's site has an article about Javascript compatibility. They rate the 6 Mac browsers for feature-completeness in the Javascript arena. For those who don't read articles, Mozilla wins by a nose."
Seriously, is this meaningful in any way whatsoever?
I'm not using a mac, but in mozillazine.org someone said the Mozilla team corrected the scrollbars bug in the latest builds.
In my pc seems to work, too.
I'm from Argentina: Tango, Asado, Mate, Gaucho, Maradona, YPF
I'll bet the reason Safari couldn't handle that XML -- which Mozilla 1.3b didn't run on my debian system until I copied it locally and fixed the XML problems -- was that it wasn't really XML. The MIME type is "text/plain" and it didn't have a proper XML declaration.
* And remember, it's spelled N-e-t-s-c-a-p-e, but it's pronounced "Mozilla."
Anyway, I kind of like the Bork edition for windows... it adds quite a bit of entertainment value to the msn site. For example:
Running IE6 on w2k, it fares quite well.
s ts/import.html
The only test it seems to have some issue with is the W3CDOM test where it creates form fields on the fly.
It creates the fields, but the radio buttons don't seem to accept a click. This may have to do with the fact that the radio buttons don't have a name attribute. I've noticed before that IE (at least mine) doesn't like unnamed radio buttons (as that's how it knows how to group them).
Otherwise, the other tests worked quite well.
--
Using Mozilla/Phoenix on win - the 'Import XML' test fails on my system.
From the Phoenix JS console:
Error: xmlDoc.getElementsByTagName("apple")[0] has no properties
Source File: http://developer.apple.com/internet/javascript/te
Line: 31
If it doesn't work in Safari, then you try the first one on your list, which is ... let's see ... Safari. I don't think that is an optimal strategy.
This article isn't bad, but it only scratches the surface of a lot of more insidious problems with all the browsers "tested".
For instance, no real differentiation is made between DOM 0, DOM 1, and DOM 2 style events and their setters. There's not even a whisper about mutation events. The section on "display" properties totally misses the related (and more useful) problems of using attribute getters and setters in the various browsers. Ever tried setting a div to have overflow="scroll" on Safari?
One last nit: does anyone else find it uber-annoying that ADC's articles don't have authorship attribution?
Dojo: defanging browsers so you don't have to
Um, it's because Opera 6.x has no DOM support to speak of. V7 is showing real promise on the platforms it's available on, but the Opera 6 series is notoriously bad at anything that isn't straight-up HTML w/ CSS.
Dojo: defanging browsers so you don't have to
I'm basing this on my experience writing a contact form that thwarts spam. It has (optional) client side verification of the fields based on regular expressions. (The same regular expressions are then used again on the server, the client side stuff just makes it fail fast.) When a web browser thinks it supports JavaScript, but doesn't do it well enough this runs into problems. I keep finding browsers that like the regular expressions I use.
If you are using an uncommon browser, I would appretiate the testing. Please go to my contact page and fill out a valid email address but no subject or message. If your browser works correctly, you should not get an error about the email address. Then send me the results. (If you do have problems, disable JavaScript first.)
navigator.appName checking isn't portable, and it can be quite verbose (requires a check per browser per feature), whereas object detection (which is what they're doing here) allows you to detect whether or not a specific feature is supported without knowing what browsers support it.
Browser specific hacks are what got us into the document.all vs. document.layers mess in the 4.0 days anyway.
As for browser-specific-code WRT to the XML loading thing, there's little (if any) support for DOM 3 Load And Save (as there's no public spec yet), so executing conditional, browser specific code to get this functionality is necessaray. Mozilla has implemented the XMLHTTP object that first appeared in IE, and so it's kind of the defacto standard (similar to innerHTML, which would also go away with DOM 3 Load And Save), however creating these objects is different on the various platforms, and is again not standard.
Dojo: defanging browsers so you don't have to
If you consider that the web is used for a lot more than academic papers in the year 2003, you'll be quite suprised to find that JavaScript w/ DOM bindings can be quite useful in helping to make web _application_ interfaces suck less. HTML makes an....um...interesting presentation layer for lots of stuff, application data included, but when you want to do something with that data, HTML's cracks start to show.
http://netWindows.org/docs/round_trips.html
Dojo: defanging browsers so you don't have to
Konqueror just got better Javascript debugging. It's in CVS now and it's slated to be part of 3.2. I wonder if Apple will pick this up sooner?