Could you add a test case for this ?

Seems fixed

case:

alert($("#result").css("line-height")); return normal

$("#result").css("line-height",1.5);

alert($("#result").css("line-height")); return 1.5

under Chrome,Internet explorer

sorry tested again

--- to fix that problem need to fix ATTR function in core.js

with that

*** old line ***

if ( typeof name === "string" )

if ( value === undefined ) {

return this[0] && jQuery[ type || "attr" ]( this[0], name );

**** change for ***

if ( typeof name === "string" )

if ( value === undefined ) {

var camelCase = name.replace(/\\-(\\w)/g, function(all, letter){

return letter.toUpperCase();

});

return this[0] && jQuery[ type || "attr" ]( this[0], camelCase );

}

Still a problem with IE8 in 1.4.2 so I'll leave it open.

This ticket has been marked as missing a test case. In an effort to reduce the number of outstanding tickets in the bug tracker, it will be closed automatically in 30 days. In order to prevent this from happening, please provide a working test case. If a test case has already been provided and our records are wrong, please respond to the ticket so that it can be fixed. Thank you!

Automatically closed due to 14 days of inactivity.

I've verified that this issue exists still in jQuery 1.5.2, and have updated the test-case:

http://jsfiddle.net/qqyqM/

Particularly worrisome is the fact that on IE (I tested IE8 specifically), a line-height of 1.5 is converted by jQuery into "1px".

Can this bug be re-opened?

@ian - unfortunately that's what IE actually computes for line height when you do not supply a unit. jQuery cannot control this. Use "em".

Replying to [comment:9 timmywil]:

@ian - unfortunately that's what IE actually computes for line height when you do not supply a unit. jQuery cannot control this. Use "em".

Actually that's not the case; IE's .currentStyle has the correct value even in that case. I've updated the testcase to show this:

http://jsfiddle.net/qqyqM/4/

That's not what I get: http://jsfiddle.net/timmywil/qqyqM/7/

Replying to [comment:11 timmywil]:

That's not what I get: http://jsfiddle.net/timmywil/qqyqM/7/

With that testcase, I get this console output:

css:  1
currentStyle:  1
css:  1px
currentStyle:  1.5

This is with IE 8.0.7600.16385 running on Windows 7.

What result are you getting? What version of IE?

That's what I get, but that's what I was saying. IE8 does not return the correct value with currentStyle. Adding em fixes the issue tho.

I see, because you want it to return the correct value in pixels. I agree that would be great, but short of that, I feel it should at least return the actual value, rather than mangling it. The current state of the code means that this:

$(foo).css("line-height", $(foo).css("line-height"));

... is an unsafe operation, because it'll convert 1.5 to 1px, rather than just passing it straight through. It seems to me that we should strive for that sort of round-trip to always be safe.

I agree that adding em is an easy enough work-around, except that:

• People who haven't read this bug thread won't necessarily know to do it.
• Sometimes you don't have control over the CSS. For instance, I ran across this issue because I'm working on a bookmarklet that needs to operate on arbitrary web pages. Both slashdot and google search results have line-height values that fit this pattern (1.x with no em).

I wouldn't say it's a high-priority bug, but I do believe it's a valid bug.

My argument is that conversion from em to px is the browser's job. Unfortunately, IE doesn't understand that the user means means em when no unit is provided and simply passes through the set value. jQuery cannot guarantee that the operator intends em either. Most often, browsers do make that assumption, but there's also cm, mm, in, pt, pc, or ex, which is a mixture of absolute unit and relative unit designators. And if we were to assume em, the potential fix would be either to set em for the user ourselves before getting the computed value (which could be unpredictable and slow down .css) or compute to px ourselves (which would be expensive and probably not always be accurate, especially given transforms and zoom). So I'm not sure there's a workable solution to the problem.

Sounds like we agree that it's not worth it/possible to properly convert to pixels.

I do believe it's worth it to return the actual currentStyle value rather than mangling it. This already works for integer values (with 1 being returned as 1), so it just needs to be fixed for non-integer values (so 1.5 is returned as 1.5 rather than 1px).

I don't have permissions on this bug database to re-open... is that something you can do, Tim?

Thank you.

I think we might accept a patch, but I don't foresee this being something we're going to tackle.

Replying to [comment:17 timmywil]:

I think we might accept a patch, but I don't foresee this being something we're going to tackle.

Fair enough; thank you.