The fifth in a popular series of DOM scripting primers. This example demonstrates retrieving element style sizes without computed styles.
This is useful for figuring the starting point for a size animation, drag resize operation or anything that must modify the size of the element relative to its current size. This is important as computed styles are sometimes unavailable or unusable (particularly in Internet Explorer).
The very simple example script is inline and should need little explanation (though at least some will follow in the near future). The pivotal function is getElementSizeStyles.
o = getElementSizeStyles(el);
The function returns an object with height and width properties containing numbers that indicate the dimensions in pixels.
These are the only styles declared for the example images:
#secondone {
border: solid 10px #000033
}
#thirdone {
height: 214px;
width: 317px;
box-sizing: border-box;
-moz-box-sizing: border-box;
-o-box-sizing: border-box;
-webkit-box-sizing: border-box
}
Note that none of the test elements has inline styles, and other than the third, they have no dimensions specified anywhere (except for the standard height and width attributes). Pixel units are used to make the results easily verifiable, but any units can be used with this technique. As demonstrated, any box model may be used as well, whether it is supported or not. The reported dimensions may surprise you (particularly in IE quirks mode), but rest assured they are exactly what the browser expects (i.e. setting the dimensions to match the results will not affect the layout).
For those who do not care to wade through the style declarations, the expected results are:
Despite the fact that IE8 in Compatibility View (for example) does not parse the box-sizing rules and therefore renders the third image slightly differently than the latest quasi-standards-based browsers, as expected, the computed dimensions remain the same. However, it did strike the author as odd that the middle example (which has no declared height or width styles) came up with the same numbers in IE quirks mode as that mode uses the border-box model. Correct answers are always expected with this technique, but they are not always expected to be identical answers in all browsers (though it is convenient for testing when they are). Apparently the unexpected but welcome result is unique to images with height/width attributes. Blissfully, there is no reason to know or care about the myriad rendering inconsistencies. What matters for most scripts when it comes to dimensions is that GIGO (and its inverse of garbage out, garbage in) holds true, because otherwise cross-browser animations, drag resizes and similar operations can have an initial twitch.
For an example at the opposite (inept) end of the spectrum, see the first example on the jQuery test page. What can a script possibly do with such results? The truth hurts, but somebody has to say it. The rest of the "major" libraries are no better as the abstractions nearest to the DOM level are too confused to ever be effective. That's what happens when software is built per today's observations with guesswork to fill in the cracks. Suffice to say, such construction crumbles over time, which is why in an era where browsers are closer than ever, pages are still falling apart, requiring constant "upgrades" (huge wastes of time and money) to stay "current". That's the inescapable truth of the matter.
