Resizable causes unexpected size changing with specific font size. [IE8]

Hi akatsuki,

Thanks for taking the time to contribute to the jQuery UI project. I'm believe that I see the problem you're referring to, but having an

alsoResize

element within a

resizable

seems like a very strange thing to be doing.

Is there a reason you need this approach? I can add

height: 100%

to the inner div, and remove the {{{alsoResize}}] and this works fine in IE8.

Hi tj.vantoll,

Thanks for taking your time.

Well, let me show you another demo. It's what I want to do.

I'm using jQuery UI Dialog and the option value "resizable: true".

http://jsfiddle.net/5H4wj/2/embedded/result/

Dialog's resizable option seems to be using Resizable's "alsoResize" option.

So I tested the 1st demo, found the same behavior on it, and created this ticket.

If there are some workarounds for Dialog's behavior, it'll also be acceptable one for me.

Can you confirm that the problem is not present when a pixel based

padding

is used: http://jsfiddle.net/tj_vantoll/TXeVL/? I have a feeling this is caused by some subpixel rounding in IE < 9.

Yes, a pixel based padding makes it expected.

Thanks a lot for telling me about the subpixel rounding.

We finally decided to use 3px padding without using default .2em padding of theme.

To make our decision more reliable, I investigate the cause of behavior.

There are two causes.

For example in the last fiddle,

3.1px padding makes it unexpected.

If the fractional part of padding and border (whether it's computed or not) is lower than 5,

the computed height or width is rounded down by IE8 and it makes the element 1px smaller.

On the other hand, IE7 ignores fractional part of padding, so it looks stable.

0.5em padding that is computed to 15px in total should makes it expected.

But there is another one.

jQuery.css() computes 0.5em padding to 8px in IE < 9.

IE8 computes 0.5em padding to 7.5px when it computes offsetWidh, offsetHeight.

The difference makes resizable element 1px smaller.

On the other hand, IE7 always computes fractional em padding to integer, so it looks stable.

... I hope my English represents my thought.

Hi akatsuki,

Apologies for the late response. It sounds like the problem is that core's

outerHeight

and

outerWidth

are returning different values in IE8 than other browsers because of the

offsetHeight

and

offsetWidth

. Is that correct?

If so might you be able to create a test case that just shows this.

Thanks for your help.

Hi,

Thanks for your response.

Here are test cases of my last response.

first one: http://jsfiddle.net/akatsuki/NVpaB/

Setting width or height property of IE8 DOM always rounds down the sub-pixels(but offsetWidth/Height are rounded).

If the element style is "width:100px;padding:1.2px;", jQuery width() returns 99.6px(offsetWidth is 102, total padding is 2.4) and Resizable sets the value to width property.

Then the width will be 99px that is 1px smaller than actual one.

second one: http://jsfiddle.net/akatsuki/wMLNp/

jQuery css() returns em padding values differently in IE8 than other browsers.

"curCss" function in jQuery core always returns computed padding as rounded integer in IE.

But IE8 supports fractional paddings, and computes offsetWidth/Height without rounding them.

It makes the result of with() or height() unexpedted too(not outerWidth/Height).

I can't find them bug or by design for this library.

If there are any unclear point in my description, I'll try to describe it.

Thanks for the detailed reply. Since the difference is occurring in css/width/height this is really a core problem and not a UI one.

I'll create a core ticket for this. Thanks again.

Core ticket: http://bugs.jquery.com/ticket/14039