New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 599471 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug



Sign in to add a comment

offsetHeight and offsetWidth inconsistent on children of flexbox with justfy-content other than flex-start

Reported by justin.m...@hotmail.com, Mar 31 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2695.1 Safari/537.36

Steps to reproduce the problem:
1. Create a div with display: flex and justify-content set to anything other than flex-start
2. Place some divs inside it all with same percent width (if flex-flow:row) or percent height (if column) without overflowing
3. Compare the offsetWidth (if rows) or offsetHeight (if columns) of the children elements

What is the expected behavior?
The offsetWidth (if rows) or offsetHeight (if columns) for all of the children elements should be the same due to them having the same percentage. Getting the width or height using getComputedStyle works this way.

What went wrong?
The offsetWidth or offsetHeight values are often not the same despite the equal percent width/height values. They do sometimes match under seemingly-random circumstances (see comments).

Did this work before? N/A 

Chrome version: 51.0.2695.1  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash 21.0 r0

Example/testing for height: http://codepen.io/justinm53/full/grxQNE/

- Only under some combinations of parent height and justify-content value do the heights in this example match.
- Only seems to happen with justify-content being changed from flex-start (default).
 
It should also be noted that this doesn't work in Chrome stable version 49.0.2623.87 and works as intended in Edge/IE/Firefox
Cc: le...@chromium.org
Components: -Blink Blink>Layout>Flexbox
Can you clarify what values you see? I see values that are similar except for rounding. Is that the issue you see too?

If yes: Due to the way we pixel-snap this is probably expected.

Comment 3 by le...@chromium.org, Mar 31 2016

Status: WontFix (was: Unconfirmed)
cbiesinger is correct -- the offsetHeight value attempts to give you the on-screen representation, which with a box with a height of 49.9px will vary between 50 and 49.

If you want the sub-pixel height, use getBoundingClientRect(). That returns your expected value for all boxes.
Alright, I understand now, apologies for the misunderstanding. I arrived at this issue because jQuery's $(el).height() uses offsetHeight, and I figured their common height function would be the "exact" height as oppose to the on-screen height. I'm not going to bother considering that an issue on their part, though.

Thanks for the quick responses, though. I'll definitely keep this little detail in mind in the future.

Comment 5 by le...@chromium.org, Mar 31 2016

No problem! Thanks for taking the time to file an easy-to-follow issue :)

Sign in to add a comment