JavaScript and DOM Compatibility
Posted by Maciej Stachowiak on Wednesday, September 28th, 2005 at 8:01 pmWith the increasing popularity of advanced JavaScript techniques on the web (variously called web 2.0, AJAX or DHTML), we’ve decided to make a big push for JavaScript and DOM compatibility. And hey, this stuff is useful for a lot of web 1.0 sites as well. (Can you tell I’m not a fan of these buzzwords?)
We’re testing against a number of test suites, including the JavaScript test suite from Mozilla and several DOM test suites from the W3C. We won’t obsolete quirksmode.org any time soon. And we are also working to support nonstandard “DOM Level 0″ features and Firefox and mozilla quirks. But we’re making a lot of progress on this standards stuff too.
Here’s a quick update on where we stand, with the latest cvs version of WebKit:
JavaScript
| Mozilla JavaScript tests | 1111 total | 1018 passed | 91.63% success |
DOM (in HTML pages)
| DOM Level 1 Core (html) | 238 total | 226 passed | 95.0% success |
| DOM Level 2 Core (html) | 11 total1 | 11 passed | 100% success |
| DOM Level 2 Events (html) | 26 total | 26 passed | 100% success |
| DOM Level 2 HTML (html) | 685 total | 680 passed | 99.3% success |
DOM (in XHTML pages)
Note, this section applies only to XHTML pages served with an XHTML mime type. This doesn’t apply to most XHTML pages on the web today. But we’d to be forward-looking and so we’re doing our best to make XHTML and XML work really well in the WebKit engine.
| DOM Level 1 Core | 238 total | 212 passed | 89.1% success |
| DOM Level 2 Core | 11 total1 | 7 passed | 63.8% success |
| DOM Level 2 Events (xhtml) | 26 total | 26 passed | 100% success |
| DOM Level 2 HTML (xhtml) | 687 total | 597 passed | 86.9% success |
| DOM Level 3 Core (xhtml)2 | 708 total | 78 passed | 11.0% success |
In closing, I’d like to add that even though we’re not yet passing all the DOM test suites, on many we are actually doing better than most other browsers, and we’re actively working to do even better.
1 – A lot of the DOM Level 2 Core tests are not available in HTML standalone versions yet – we’re working with the W3 Consorium’s QA working group on this.
2 – DOM Level 3 support is completely experimental – we haven’t really made a full-on attempt to work on it yet.
September 28th, 2005 at 9:54 pm
Plz support event.preventDefault() and event.stopPropagation() methods…!
September 28th, 2005 at 10:36 pm
Do you have a reproducible case of preventDefault or stopPropagation not working? They appear supported here. I tried this test case:
<a href=”http://www.google.com” onclick=”alert(’here’)”><span onclick=”event.stopPropagation()”>click here</span></a>
<a href=”http://www.google.com” onclick=”alert(’here’)”><span onclick=”event.preventDefault()”>click here</span></a>
They seem to stop propagation and prevent default respectively. (Although there seems to be a bug that stopping propagation also prevents the default action! Is that what you had in mind?)
September 28th, 2005 at 11:35 pm
So when can we expect to see these improvements rolled into the non-developer version of Safari? I am getting tired of having to launch Firefox for a few sites that use this stuff (writely.com for example).
September 29th, 2005 at 2:50 am
JavaScript and DOM compatibility
JavaScript, long being a second class citizen on Mac but thanks to the arrival of Mac OS X a lot has changed. It seems that the use of advanced JavaScript
September 29th, 2005 at 5:50 am
Where are the web pages for the various test suites?
Also, maciej, I think a more accurate preventDefault test would be:
click here
since the span tag doesn’t have a default click action.
September 29th, 2005 at 5:53 am
Er, didn’t realize HTML markup was allowed. That test (a good example) should read:
<a href=”http://www.google.com” onclick=”event.preventDefault()”>click here</a>
And, of course, the test should be made using a JS-assigned handler:
<a href=”http://www.google.com” id=”foo”>click here</a>
<script type=”text/javascript”>
document.getElementById( ‘foo’ ).addEventListener( ‘click’, function( evt ){ evt.preventDefault( ) }, false );
</script>
September 29th, 2005 at 9:15 am
OK, your DOM-assigned handler example doesn’t work on the last released version of Safari (default not prevented) but it does work on the latest cvs WebKit. I think it is actually a JS parsing problem though, as this workaround works:
function f(evt) { evt.preventDefault(); }
document.getElementById(’foo’).addEventListener(’click’, f, false);
I also fixed the problem I found with stopPropagation, just waiting for code review: 5180
And finally, I’m afraid we can’t make any commitments about when specific fixes will make it into releases. The best we can do is let you know after the fact.
September 29th, 2005 at 11:11 pm
Ah, that nasty bug 4788. I think that folks do get discouraged when they encounter something like the Gmail bug where…just…nothing…happens. And I hate to say it, but I think the test “people” use these days for browser excellence is not some oh-so-subtle rendering in CSS2, but do the fancy AJAX things of the world (and yeah, interactive SVG too) work?
In other words, do Gmail and Google Maps work as advertised? And of course, they wonder about that Google Earth, but that’s not in your court.
October 4th, 2005 at 1:12 am
Great! The ultimate test application is almost working (just kidding and sorry for Czech locale, English localization pack (external XML file) is pending, but if you know XMLSpy you get the idea
at http://www.whoa-framework.org/website/vas/1.0/?/editor/xml .
Still needs a little bit of tweaking for Safari, but god i’d love to replace Firefox with Safari for such particular applications (please note that the code is actually about three years old and almost intact, no sign of Ajax at that time:) and worked on Mozilla Gecko since its 0.8 version with IE since 6.0). Now Safari is coming very close.. More on http://www.whoa-framework.org/?/product/bender .
October 4th, 2005 at 9:54 am
Safari Browser Continues to Improve
In Safari browser news, they’ve recently announced a long list of fixes to the WebKit rendering engine and a renewed focus on JavaScript and DOM Compatibility.
Their list of improvements includes over 40 fixes. In the JS/DOM efforts, they rep…
October 5th, 2005 at 10:10 pm
Disarm IE: My Dev Wishlist for Other Browsers
October 14th, 2005 at 6:28 am
Coincidentally, I hit that preventDefault bug today. Immediately after, I ran into bug 3374. But 3374 is a lot easier to work around. In any case, now that I’m learning the DOM, I’m even more appreciative of your efforts. Thanks!
October 29th, 2005 at 3:15 am
I went to check how the latest nightly does on http://www.w3.org/DOM/Test/ but none of the linked Ecmascript test suites run under Safari – neither on the Nightly or the latest Tiger release version (2.0.1). Is there a way to make the tests run under Safari? I guess there is given you have proper reports of the results.
February 7th, 2006 at 5:03 am
wow, the implemented Javascript engine in Safari is not very fast.
check out the javascript performance test on
http://wd-testnet.world-direct.at/mozilla/dhtml/funo/jsTimeTest.htm
Power G5 4×2,5 Ghz 10.4.4
Safari 2.0.3 (417.8), Opera 9.00 (3216)
Time
Safari: 1657 ms
Opera: 883 ms !!!
so Opera twice the speed of Safari.