A new round of compatibility testing; input requested

After too many months of not doing any testing at all, I’m gearing up towards a major round of compatibility testing. Today, I’d like to ask you if you know DOM Core tests that I need to run.

I’m currently updating my mobile browser test line-up, and I installed new virtual IEs courtesy of modern.ie (highly recommended, by the way).

Change of methodology

More importantly, I am working on a new DOM test suite (draft version; both the suite and the URL will change) that allows me to perform many more tests because I partially automated the testing itself.

For me, that’s a major departure from my old methodology. In the past I never wanted to do any sort of automated tests, because the test suite itself would have to use some of the methods and properties that were being tested.

It’s impossible to show test results in a browser without using such basics as getElementById, parentNode, and appendChild. If the purpose of the tests is to establish the reliability of these methods and properties, however, one is not allowed to use them in the test framework. Makes sense, right? So: no test framework. Manual work.

A little while ago I decided to forego methodological purity in favour of ease of testing. All browsers support basic DOM methods and properties, and the prospect of hand-performing dozens of tests on about 25 mobile browsers didn’t appeal to me at all. (Incidentally, these are also the reasons why the core DOM tables haven’t been updated for so long. It’s a lot of work, and is unlikely to give surprising results, so I didn’t bother.)

Look mom! I found a browser bug!

Anyway, I’m glad I bothered re-doing these tests, because I found a minor browser incompatibility in the very core of the DOM Core. These are the moments I live for.

Take this HTML:

<p id="test" testAttribute="ppk">Test paragrapgh</p>

and this JavaScript:

function () {
	return document.getElementById('test').getAttributeNode('testAttribute').nodeName;
}

What does the function return? I assumed testAttribute, but only IE and Presto-based Opera 12 agree with me. The other browsers return testattribute, without the camelCase, instead.

Who’s right? I don’t know. But let’s be honest, one does not need the nodeName of an attribute node all that often. Did you ever? I didn’t.

The real surprise is that there are still incompatibilities to be found in the core of DOM Core, an area that has been well-studied ever since I set up my first DOM compatibility table back in 2000.

Input requested

This brings me to today’s request: do you know of any good tests to perform on the DOM Core methods and properties? Any peculiarities or oddities that require a long, good look? Now would be an excellent time to suggest them, since I’m creating the test suite right now and will start testing desktop and mobile browsers shortly.

The other parts of the DOM will get the same treatment later, so please restrict yourself to Core now.

Thanks!

This is the blog of Peter-Paul Koch, mobile platform strategist, consultant, and trainer. You can also follow him on Twitter.
Atom RSS

I’m speaking at the following conferences:

(Data from Lanyrd)

Categories:

Monthlies:

Comments

Comments are still open.

Post a comment

All comments on QuirksBlog are moderated. I will review your comment and publish it when I feel it’s appropriate to the post it was made on. I tend to publish comments in batches once or twice per day.

* required fields

Yes