Side navigation
#12883 closed bug (notabug)
Opened November 11, 2012 08:26PM UTC
Closed December 29, 2012 10:37PM UTC
.width(), outerWidth(), innerWidth all incorrect in Safari with inline-block divs
| Reported by: | kthrose@netpoetica.com | Owned by: | kthrose@netpoetica.com |
|---|---|---|---|
| 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.
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.
Attachments (0)
Change History (5)
Changed December 28, 2012 10:26PM UTC by comment:1
Changed December 29, 2012 04:36AM UTC by comment:2
| owner: | → kthrose@netpoetica.com |
|---|---|
| status: | new → pending |
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!
Changed December 29, 2012 05:28PM UTC by comment:3
| status: | pending → new |
|---|
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.
Changed December 29, 2012 05:33PM UTC by comment:4
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:
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.
Changed December 29, 2012 10:37PM UTC by comment:5
| resolution: | → notabug |
|---|---|
| status: | new → closed |
Everything works ask expected. Your demo is being effected by this: http://stackoverflow.com/questions/5256533/a-space-between-inline-block-list-items
Which Safari? Works the same as in Chrome for me in Safari 6.0.2.