Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming Businesses The Internet Apple IT Technology

ADC Rates Web Browsers For Javascript Compatibility 42

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."
This discussion has been archived. No new comments can be posted.

ADC Rates Web Browsers For Javascript Compatibility

Comments Filter:
  • I have never seen a web site with information that couldn't be presented best in plain HTML.
    • by russcoon ( 34224 ) on Monday February 24, 2003 @03:59PM (#5373063) Homepage
      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
  • Apple: "We're Great" (Score:3, Interesting)

    by quandrum ( 652868 ) on Monday February 24, 2003 @01:11PM (#5371479)
    Seriously... even though Mozilla "won", it was only because it could do XML, which safari can't handle properly yet. Excluding that test.. Safari was the only browser that was perfect on all tests. I could certainly develop some tests [diveintomark.org] that safari would fail....

    Seriously, is this meaningful in any way whatsoever?

    • I wonder (Score:4, Informative)

      by KnightStalker ( 1929 ) <map_sort_map@yahoo.com> on Monday February 24, 2003 @01:15PM (#5371517) Homepage
      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.
    • by mr3038 ( 121693 )
      Excluding [XML test] Safari was the only browser that was perfect on all tests.

      I don't have a Mac to test on but at least my old Nightly Build of Mozilla 1.3b (ID:2003021806) does render also the DHTML test perfectly[1]. You're right that the XML test is broken (the server is misconfigured).

      [1] Or... it does display and remove the scrollbar as expected when the div goes over (under?) the right edge of viewport. However, it doesn't display the scrollbar when the div goes over the left border of the viewport, which I consider as a bug also. It's the bug ID:6976 in case you want to vote it. Don't post extra comments to that bug unless you have a fix.

    • Safari was the only browser that was perfect on all tests. I could certainly develop some tests [diveintomark.org] that safari would fail....

      diveintomark.org [diveintomark.org] details CSS and rendering issues. This was a JavaScript test.

      Seriously, is this meaningful in any way whatsoever?

      What would you rather Steve said? "Safari is insanlely great!"? Apple posted a reproducable test suite that outlined some of Safari's positives and negatives. As for Apple saying "We're Great", the conclusion reads "The new Safari 1.0 beta is a strong contender." Safari went toe-to-toe with Mozilla and came out alive. That is quite an accomplishment and Apple should be commended for it.
      • ... There's no telling how many tests where done, but whose results we won't get to see until they have fixed the bugs. Let's see some tests from an independant third party. I bet Safari won't get "Perfect except for that W3C draft thing which no browser except Mozilla support, test that seems like it was put in there just so Safari would fail it, and the test will look more neutral".

        Nothing more than propaganda, I say

        • Oh, yeah, and I'd like to see how well Safari fares with all those crappily implemented DHTML menus floating around the 'net. The problem with JavaScript isn't with respecting the W3C standards, it's with dealing with all that crappy code that doesn't follow the standard, but since it works in version X of browser Y, it's good enough for everybody

          As long as the big two browsers support broken JS, the smaller browsers will have to support it as well, lest they lose what little market share they already have

  • by TulioSerpio ( 125657 ) on Monday February 24, 2003 @01:13PM (#5371497) Homepage Journal
    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 wonder... (Score:2, Interesting)

    by FunkyMarcus ( 182120 )
    ...how IE for Windows would fare with these tests.

    Based on experience, I'm not holding my breath.

    Mark
    • Re:I wonder... (Score:5, Informative)

      by ip_vjl ( 410654 ) on Monday February 24, 2003 @02:01PM (#5371930) Homepage
      Running IE6 on w2k, it fares quite well.

      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/tes ts/import.html
      Line: 31

      • 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/tes ts/import.html
        Line: 31


        As someone said elsewere, it's a problem with the MIME setting of the server.
    • Re:I wonder... (Score:2, Informative)

      by mhesseltine ( 541806 )

      Wonder no more. IE6 on Win98 performed every test flawlessly. YMMV, IANAL, etc.

  • The article seems to be taking quite a number of shots at Opera. I wonder if this has anything to do with Opera's hissy fit over Safari?
  • by Numeric ( 22250 )
    I have a 366mhz iBook which has basically replaced my 1.4ghz AMD box (which I only play BF1942 on) and I refuse to use Mozilla because it will runs slower than a old hound on a humid day.

    If I need to go to a site and it doesn't work in Safari, here's my browser order...

    1. Safari
    2. Chimera
    3. IE
    4. Lynx
    5. Mozilla
    • by Anonymous Coward
      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.
  • The XML test... (Score:2, Insightful)

    by Anonymous Coward
    I thought the whole point of these tests was to measure the brwoser's standards compliance. Then they go and code their javaScript (for the XML test, at least) such that there is a specific implementation so that IE will work since IE doesn't support the method called for by the standard.

    What's the point of testing browser compliance if you're going to execute separate code for specific browsers? Why not just check the navigator.appName and then write browser specific javaScript code like we've had to do ever since IE entered the browser war?
    • Re:The XML test... (Score:4, Interesting)

      by russcoon ( 34224 ) on Monday February 24, 2003 @03:46PM (#5372948) Homepage
      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.
  • by russcoon ( 34224 ) on Monday February 24, 2003 @02:41PM (#5372326) Homepage
    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?
    • One last nit: does anyone else find it uber-annoying that ADC's articles don't have authorship attribution? - parent
      I tested these scripts in six browsers, all running on Mac OS 10.2.1 . . . - ADC

      YES, it would be okay if they didn't keep saying I did this or I did that. I wish they would at least put a name so we know who this mysterious person is that is reporting this to the world.

      -Adam

  • by DeadSea ( 69598 ) on Monday February 24, 2003 @03:26PM (#5372747) Homepage Journal
    I would be very interested to see how regular expressions (a core part of the JavaScript language) stack up in various browsers. Netscape has had good support for regexps since 4.0, IE since 5.0. Opera still seems to be lacking in these regards.

    I'm basing this on my experience writing a contact form that thwarts spam [ostermiller.org]. 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 [ostermiller.org] 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.)

  • Windows Browsers (Score:3, Informative)

    by Chris Canfield ( 548473 ) <slashdot@ch r i s c a n f i e l d.net> on Monday February 24, 2003 @04:11PM (#5373184) Homepage
    I just tested the sample scripts on Opera 7.0, Mozilla, and I.E. for Windows. I know this isn't a comprehensive list of Windows browsers, but it is what I have on hand.

    Opera and Mozilla both handled everything flawlessly except for the XML. Neither seemed too happy with the imported XML text, instead remaining blank. On the other hand, I.E. rendered all of the above with no problems.

    In any case, you shouldn't be importing your site's content as XML anyway, as another poster pointed out. If you have to, your site will be I.E. only for now. Unless they have a Mac.
  • Safari debugger (Score:4, Interesting)

    by mcgroarty ( 633843 ) <brian DOT mcgroarty AT gmail DOT com> on Monday February 24, 2003 @04:20PM (#5373281) Homepage
    The article comments on Safari not having much in the way of Javascript debugging.

    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?

    • I dunno...I'd like to see it but I'm not hopeful that anything like it will show up in Safari 1.0. The JS debugger in KDE HEAD is primordial. It barely allows me to set breakpoints with any regularity, and it's introspection and exception reporting need a lot of work before I'll use anything but Mozilla for real JS debugging work.

      That said, Konq 3.1 is an absolute joy from end users's perspective. Now if only the same could be said about support for those developing against it...

  • SSS is a Finish guy's clever way to encrypt
    a web page's contents, unlockable by p'word

    It's implemented in Javascript.

    We just had a disappointment, after a Client
    revealed that they use Mac's and their brow-
    ser (IE) wouldn't unlock the page.

    Actually, I'm surprised that Opera 6 was
    rated to low on this battery of tests...
    its Windows implementation runs SSS well

    Has anyone used SSS (successfully) on a
    Mac? If so, which browser did it work on?

    TIA

    PS SSS's scheme doesn't show the encrypted
    page - even after it's been decrypted &
    displayed in clear text; a cool system!
  • Aren't we grateful for Standard ECMA-262 [ecma-international.org] and isn't it wonderful that everyone follows it?

    Particularly gratifying, considering that this standard has only been out since 1999... so most vendors have only had half-a-dozen or so revision opportunities...

  • I tried to read the story, but someone added "window.close()" to the dang page.

The gent who wakes up and finds himself a success hasn't been asleep.

Working...