9.2. About client- and offset- Properties

In Internet Explorer 4, Microsoft introduced a set of size and position properties for elements that render as part of the regular body content (i.e., not positioned via CSS). These properties had the potential to assist scripts in their tasks of determining locations and dimensions of body content so that positioned elements could be moved in relation to these fixed elements. The properties are:

I use an image here because its content is the same size regardless of browser, and will let us see how the various size properties report the element's overall or content size (i.e., we're not at the mercy of font rendering vaguaries). Including padding, border, and margin settings for this fixed element will illustrate that some of these style attributes can impact topographical information about the element in the document. Table 9-1 shows the values for relevant size and position properties for several browsers and compatibility modes.

[12]For inline text elements in IE/Mac, add a margin of offsetParent to offset property values to get the equivalent of client properties.

Table 9-1 reveals a great deal about how various browsers report the location and size of an inline element. Some of the precise numbers, such as the location coordinates, are not critical measures because each browser renders surrounding content slightly differently, and any scripts that rely on the position will read the live values in each case. But several very important details are worth noting for this particular element insertion:

• IE 6 in backward-compatible mode calculates the heights and widths the same as IE for Windows all the way back to Version 4. This is good for backward compatibility.

• In IE 6/Windows backward-compatible mode, the offset sizes include the border thicknesses on both sides of the content.

• In standards mode, IE 6/Windows calculates the offsetLeft and offsetTop properties in relation to the offsetParent element; the offsetParent element (the body element in this case) has its own offset values. The actual location must take into account the offsetParent's offset values.

• In standards mode, IE 6/Windows reports width and height properties influenced by the padding thickness. This is wrong, because these properties should reflect the height and width attributes of the element (even getAttribute( ) returns the incorrect values).

• IE 5/Mac has a completely different notion of what the clientLeft and clientTop properties should measure compared to any IE/Windows version (representing the sum of the offset measure of the element plus the margin of the offsetParent element).

• IE 6/Windows in standards mode, IE 5/Mac, and NN 6 report identical offsetWidth and offsetHeight values, all of which include the padding and border thicknesses, but not the margins.

To gain an appreciation for why these differences can be important to your DHTML scripting, consider what it takes to position a second img element that has no padding, border, or margin so that the top-left corner of the positioned image is precisely at the top-left corner of the static image content. Depending on the browser and compatibility mode, you must take into account a variety of measurement components of the fixed element to accumulate a value to assign to the movable element's style.left and style.top properties. Table 9-2 shows the pieces required for the style.left property for several browser classes. The corresponding top values would also be assigned to the movable element's style.top property.

This syntax also assumes that the style object has the style sheet properties handy because they were set as an attribute of the element. If the style sheet is defined elsewhere in the page, you'll have to go the extra step of reading the effective style applied to the element (see DOM-specific techniques for this in Chapter 5). One more factor to take into account is the offsetParent location. If the element whose location you're reading is nested within multiple positioning contexts, you should use a separate function to accumulate all offsetLeft values of offsetParent s out to the root element. On the plus side, you can use the same calculation for Netscape 6 because the offsetParent.offsetLeft property returns zero, so its addition won't affect the outcome, even for nested positioning contexts.

For IE 5/Mac, the clientLeft and clientTop properties are valid for only some elements, such as inline img and positioned elements. For other kinds of elements, you need to calculate the equivalent of the clientLeft and clientTop properties by including the margins of the body element, which have significant default values you must account for as follows:

positionedElem.style.left = fixedElem.offsetLeft +
  parseInt(fixedElem.offsetParent.currentStyle.marginLeft)  + "px";

Netscape 7 adds support for the IE clientHeight and clientWidth properties (not clientLeft or clientTop), but only for elements that display scrollbars due to content overflowing the viewable area. This includes the document.body element, when it is larger than the content region of the browser window. For nonscrolled elements, both property values are zero.

This digression serves as an advisory that the client and offset properties are both helpful and tricky. Almost any task is possible, but it may require much trial, error, and cross-browser testing to achieve the desired results with your combination of elements. Not every positioning task is quite so difficult (as in the flying objects example in Chapter 4). But don't be surprised if a complex element design and precision positioning task across the domains of fixed elements, positioned elements, and event coordinates takes hard work to accomplish.

---

9. Document Object Model Reference		9.3. Default Property Values

---

Copyright © 2003 O'Reilly & Associates. All rights reserved.