The Analysis of jquery CSS () method is a bug.

Bug description when the CSS font-size: 100% of the element class Percentage value, we will get an incorrect value.

What is this value? You may have guessed it. Yes, the clientwidth * Percentage of the parent container.

 

This is because of hisCodeAs follows:

If (ELEM. currentstyle ){//

R = ELEM. currentstyle [stylestring]; // obtain the final rendering value of the corresponding CSS attribute.

If (! /^ \ D + (PX )? $/I. Test (RET) &/^ \ D/. Test (RET )){
VaR left = style. Left, rsleft = ELEM. runtimestyle. Left;

ELEM. runtimestyle. Left = ELEM. currentstyle. Left;
Style. Left = RET | 0;
Ret = style. pixelleft + "PX ";

Style. Left = left;
ELEM. runtimestyle. Left = rsleft;
}

Return ret;

The code above indicates that if the obtained R content starts with a number and does not end with a PX, it will be converted, for example, 100% 20em 30pt ex in.

How to convert it? There is a conversion formula, such as N em = N * 16 PX, N Pt = math. floor (N * 3/4) Px and so on, but jquery's method is clever. because once the value is a percentage

So for padding Left top bottom right line-height margin and so on, all the % values are obtained by multiplication with the clientwidth of the parent element of the current element ....

For this reason, go to the W3C manual. now we only need to get the clientwidth multiplication of the parent element, but the disadvantage is that we need to switch for various possible units, and then apply a regular matching to retrieve units and apply different conversion formulas to different units. Very troublesome...

Then, jquery uses the above Code to temporarily put the style of the current element. left stores a variable and assigns the R value (whether em % Pt or whatever) to the style. left

The left position of the current element naturally changes. At this time, the pixel value corresponding to this value is automatically calculated through element. pixelleft. In this way, the correct PX value is obtained.

The results of defaultview are consistent and are automatically converted to PX. Then, the original style. Left value is overwritten to restore the style. Left position of the element.

 

Here, we need to mention the element. runtimestyle. Why does it temporarily overwrite it here? It may be out of insurance. For example, this value may be changed in other code because runtimestyle has a higher priority than style... So element. runtimestyle is overwritten to retrieve the correct value for pixelleft.

 

The bug shows that the % percentage of the font in IE is relative to the default font size, but here it is wrong to calculate the value with the clientwidth of the parent container.

So it should be judged as follows: (the following code cannot be run in the pseudo-code jquery, but the idea is usable)

VaR B = false;
If (/^ \ D +/. Test (r = node. currentstyle [stylestring = NS. String. camelize (stylestring)]) {
If (! (B =/^ Font/. Test (stylestring) | (B & R. Match (/\ D + $/) [0]! = '% ')){
VaR left = node. style. Left, rsleft = node. runtimestyle. Left;
Node. runtimestyle. Left = node. currentstyle. Left;
Node. style. Left = r | 0;
R = node. style. pixelleft;
Node. style. Left = left;
Node. runtimestyle. Left = rsleft;
Return parseint (R );
}
Else if (node! = Document. Body) return math. Floor (parseint (r) x (parseint (getcurrentstyle (document. Body, 'font-size') | 16)/100 );
Else return math. Floor (parseint (r) * 16/100 );

Then let's talk about other small bugs.

This bug is essentially irrelevant to jquery. Is the problem of IE itself, that is, the problem of currentstyle.

We all know that currentstyle.css float is used when stylestring is float.

But the problem is that when the current node in IE is absolute or relative fixed, it is clear that float will be ineffective, so other browsers will eventually return none, no matter whether you are left or right in float, it will return none because the final rendering of the browser is none, it is obvious that IE returns left or right here. then let's make a decision.

F (stylestring = 'float') return ns. String. isinlist (node. currentstyle. Position, ['absolute ', 'relative', 'fixed'])? 'None': node. currentstyle. stylefloat;

 

Of course, it is important to judge whether IE6 fixed is invalid, so rendering is effective. However, since IE6 fixed is invalid, it will generally use absolute CSS hack to simulate fixed for IE, so it doesn't matter if you do not judge whether to judge it.

 

There are functional questions. I don't understand why jquery doesn't convert the color values taken out by Non-ie defaultview, such as RGB (255,255,255), to # ffffff and then return the result. Isn't it more convenient for external use? It may be because his set method allows such parameters, but I still think the conversion is good.

If (R. indexof ('rgb (', 0)> = 0) {
var color = r;
r = '';
color. replace (/\ D {1, 3}/g, function (m) {
M = parseint (m ). tostring (16);
r + = m. length = 2? M: m = 0 + m;
});
return '#' + R;
}

 

For the time being, I think there is no need to fix or unify the differences in returned values of other situations, such as Left top equivalence, different browsers, and different locations... 1 is very troublesome. we can use element. offset to replace can be directly unified...