Bug Tracker

Opened 7 years ago

Closed 7 years ago

#12883 closed bug (notabug)

.width(), outerWidth(), innerWidth all incorrect in Safari with inline-block divs

Reported by: kthrose@… Owned by: kthrose@…
Priority: undecided Milestone: None
Component: unfiled Version: 1.8.2
Keywords: Cc:
Blocked by: Blocking:

Description

I have a situation where I have a UL containing a couple of lis, and I am dynamically adding these lis to the DOM via jquery. When I call a .width() on these lis directly after they are appended to the DOM, directly follwing the append, I get back an inaccurate width.

http://jsfiddle.net/5jYj2/

The container element is always falling short by some arbitrary miscalculation in the width. At first I thought it was margin/padding, but the results I'd find were usually about 130px off in total width from the actual width if you were to check $(elem).width() in the console vs what it says when that function is being called.

If you change the style to inline, it seems to work fine. In Chrome, inline-block calculates properly.

I hope that fiddle makes sense. If you're not seeing the problem I can try to construct a more detailed fiddle, feel free to email me. I might try to look into this bug if I can get that kind of time.

Change History (5)

comment:1 Changed 7 years ago by m_gol

Which Safari? Works the same as in Chrome for me in Safari 6.0.2.

comment:2 Changed 7 years ago by mikesherov

Owner: set to kthrose@…
Status: newpending

Thanks for contributing! I also can not reproduce this issue. Please provide a more coherent jsfiddle and which browser specifically you're seeing the issue in. Thanks!

comment:3 Changed 7 years ago by kthrose@…

Status: pendingnew

Hey everyone - thanks for taking a look at this. I just looked over that Fiddle again in the following browsers and I am seeing the problem still:

Google Chrome 23.0.1271.101 Safari Version 5.1.7 (6534.57.2 Firefox 16.0.2

Also, I'm on a Macbook Pro circa 2010 if that makes any difference.

The problem is that I am depending on the calculated width() of each LI element in order to dynamically size the box around it to fit all elements in a line without breaking the line. I know there are better ways to do this, but this example shows that the calculations of the LI elements in incorrect. If the measurements were correct, the box would size to a long enough width that all elements could seat on one row.

comment:4 Changed 7 years ago by kthrose@…

In that specific example, if you implicity add 10 (the padding value), you can see the elements bounce up. But outerWidth() is supposed to account for padding:

http://api.jquery.com/outerWidth/ Get the current computed width for the first element in the set of matched elements, including padding and border.

So that function is not doing what it's supposed to do as per the docs.

Now if you go this Fiddle where I am using width() instead: http://jsfiddle.net/5jYj2/1/

You will see that width(), which is supposed to get the computed width - even though I'm implicitly adding the padding value from the CSS up top, it *still* won't size properly.

comment:5 Changed 7 years ago by mikesherov

Resolution: notabug
Status: newclosed

Everything works ask expected. Your demo is being effected by this: http://stackoverflow.com/questions/5256533/a-space-between-inline-block-list-items

Note: See TracTickets for help on using tickets.