I'm writing a CSS book

JavaScript archives Compatibility CSS coaching Thidrekssaga QuirksBlog Donations Politics Mobile About COH

sitemapcontact

CSS OM, take 2

Just now I re-tested the CSS Object Model, both to accomodate IE8b1, FF3b4 and Safari 3.1, and because some of my earlier conclusions were wrong.

getBoundingClientRect()

In my previous post I dismissed getClientRects() and getBoundingClientRect() as incomprehensible, but now I understand I should test them with multi-line inline elements. When the methods are used on such elements, they (should) return one rectangle per line.

I rewrote the test page to show absolute elements at the rectangle coordinates, and now it's clear how getClientRects() is supposed to work, and that IE5.5-7 have significant bugs with this method: they report far too many rectangles. (IE8b1 does the right thing, BTW.)

Thanks to John Resig for taking the lead in dissecting a few browser oddities with these methods.

offset

I also retested the offset-related properties, and Travis Leithead of the IE team revealed the cause of Opera's weird negative values for offsetX/Y: Opera's reference point is the top/left of the content block (excluding padding and border), while Safari and Konqueror use the top/left of the element's border.

I summarily judged Opera's implementation Incorrect, because the Safari way seems to be the most logical one. I'm open to counter-arguments, though.

Update: The spec says that the correct reference point is the top/left of the padding-box, which makes sense. Page changed to reflect that.

Update 2: Went through the CSS Table, too. No surprises, except for one minor IE8b1 regression. However, I now count IE's support of its own rules[] array Incorrect for reasons mentioned in the table. This is an old bug.

Comments

Comments are closed.