This is a great analysis Dave - and spot on. Most of .curCSS() originated back from stuff on QuirksMode.org - which is to say that it's acceptable, but not perfect. If I were to give you a SVN account, would you be willing to make some of these changes (e.g. remove the need for elem.style, swap the order of getComputedStyle/currentStyle).
I'm debating what to do about the borderWidth issue, though - since jQuery does access that property too, in $.css(). I hate having special cases for properties, but perhaps it would be 'ok' to have a built in check to see if borderPositionStyle is 'none' before going any further. Contact me off-list if you'd like to help me with this. --John On 9/9/06, Dave Methvin <[EMAIL PROTECTED]> wrote: > As John says, the situation with getting border dimensions on elements is a > mess (like margin and padding) and there are limits to the amount of > lipstick jQuery can put on this pig. Here are the results of my experiments > with jQuery().css() on IE6, IE7RC1, FF1.5, and Opera 9.1. > > 1) The shortcut properties such as border or borderWidth are no good for > getting exact dimensions, so ignore them. Instead, get each side's > information individually with borderLeftWidth etc. > > 2) IE6 and Opera yield nonsense for borderLeftWidth when there is no border. > Opera may do this for compatibility, it supports both currentStyle which has > an IE-like bad value (3) and getComputedStyle which has the correct one (0). > jQuery prefers currentStyle over getComputedStyle so it ends up with the bad > value. In any case, always check borderLeftStyle for "none" before trusting > the value of borderLeftWidth. > > 3) If you have a -->css rule<-- that applies to an element and sets a "thin" > or a "1em" border, Firefox helpfully converts all the border dimensions to > pixels; IE6 and Opera do not. (Opera would return converted values too if > .css() prioritized getComputedStyle over currentStyle.) So, always use > pixels if you set an explicit border width in a css rule. > > 4) If you have a -->style property<-- on an element like > style="border-left-width: thin" that exact string will be returned in both > all browsers. That's because jQuery().css() stops looking when it finds a > string in elem.style.borderLeftWidth. In FF and Opera the getCurrentStyle > value has the pixel-converted value but jQuery doesn't use it. IE doesn't > ever convert it, just like case 3. Again, pixels are a must if you set > explicit widths. > > jQuery could change some things here--although it might introduce other > bugs--but IE will still insist on returning the exact strings it has, > including border width names like thin/medium/thick and non-pixel > measurements like 0.2em. It's a shame this doesn't change at all in IE7. > I've never found an easy way to convert non-pixel units to pixels, so most > likely the only useful workaround is to always use pixels. For the cases > where IE returns thin/medium/thick you could probably map the names to > appropriate pixel widths, but that special case is probably best handled in > your own code. > > I wasn't quite sure on the history behind .curCSS and why it uses properties > in the order .style[prop], currentStyle[prop], getComputedStyle(prop). I saw > that setAuto uses the force flag, which does skip over .style[prop] in some > cases. > > > > _______________________________________________ > jQuery mailing list > [email protected] > http://jquery.com/discuss/ > -- John Resig http://ejohn.org/ [EMAIL PROTECTED] _______________________________________________ jQuery mailing list [email protected] http://jquery.com/discuss/
