Skip to main content

Bug Tracker

Side navigation

#2671 closed bug (patchwelcome)

Opened April 10, 2008 07:35AM UTC

Closed April 18, 2011 07:07PM UTC

Last modified April 19, 2011 06:39PM UTC

curCSS: computed style hack for IE

Reported by: linwong Owned by:
Priority: low Milestone:
Component: css Version: 1.5.2
Keywords: Cc:
Blocked by: Blocking:

I get a computed error for line-height because of this hack.

In my case, I had a line height of 1.6 (which is a valid value). Upon trying to calculate the pixels for this, it returns 1px, which is not correct.

I got the error using .css


returned 1px when my line-height was 1.6

Attachments (1)
Change History (19)

Changed May 15, 2008 03:04PM UTC by flesler comment:1

need: ReviewTest Case

Could you add a test case for this ?

Changed December 21, 2008 01:14AM UTC by sanaell comment:2

Seems fixed


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


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

under Chrome,Internet explorer

Changed December 21, 2008 01:16AM UTC by sanaell comment:3

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 );


Changed June 20, 2010 06:25PM UTC by dmethvin comment:4

component: corecss

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

Changed October 14, 2010 03:14AM UTC by snover comment:5

status: newpending

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!

Changed November 11, 2010 11:09PM UTC by trac-o-bot comment:6

status: pendingclosed

Automatically closed due to 14 days of inactivity.

Changed April 14, 2011 08:50PM UTC by comment:7

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

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?

Changed April 14, 2011 09:34PM UTC by timmywil comment:8

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

Changed April 14, 2011 10:26PM UTC by Ian Gilman <> comment:9

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:

Changed April 14, 2011 10:40PM UTC by timmywil comment:10

_comment0: That's not what I get:

That's not what I get:

Changed April 15, 2011 06:04PM UTC by Ian Gilman <> comment:11

Replying to [comment:11 timmywil]:

That's not what I get:

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?

Changed April 15, 2011 06:15PM UTC by timmywil comment:12

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.

Changed April 15, 2011 08:29PM UTC by Ian Gilman <> comment:13

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.

Changed April 15, 2011 10:36PM UTC by timmywil comment:14

priority: minorlow

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.

Changed April 18, 2011 05:33PM UTC by Ian Gilman <> comment:15

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.

Changed April 18, 2011 07:07PM UTC by timmywil comment:16

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

Changed April 18, 2011 07:07PM UTC by timmywil comment:17

status: closedreopened

Changed April 18, 2011 07:07PM UTC by timmywil comment:18

resolution: → patchwelcome
status: reopenedclosed

Changed April 19, 2011 06:39PM UTC by Ian Gilman <> comment:19

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.