Bug Tracker

Opened 6 years ago

Closed 6 years ago

Last modified 5 years ago

#14078 closed bug (duplicate)

.height() returns non-pixel value

Reported by: anonymous Owned by:
Priority: low Milestone: None
Component: css Version: 2.0.2
Keywords: Cc:
Blocked by: Blocking:

Description

I have a collection of divs that have a percentage height and whose parent div is hidden (display: none). When I use .height() on one of the child divs, it returns the percentage value with the percent stripped. My understanding is that .height() is always supposed to return a pixel value, in which case this would be a bug.

Change History (4)

comment:1 Changed 6 years ago by timmywil

Component: unfiledcss
Priority: undecidedlow
Status: newopen

This is true. I believe it's either that or return 0 though. We fall back to uncomputed styles in that situation and .height simply returns the parsed number regardless of unit. It's not a common situation, but the purpose is to provide some useful number in as many situations as possible. Admittedly, cases where the units are not pixels could probably use more consideration.

comment:2 Changed 6 years ago by dmethvin

Resolution: duplicate
Status: openclosed

Duplicate of #7928.
This sounds like a dup of #7928 to me but it's hard to tell for sure without a test case. I'll close it though.

Realize that the performance implication of a fix is pretty horrific anyway, we'd need to walk up the DOM tree making everything visible, measure the div causing a browser reflow, and then set everything back causing another reflow. Even then we wouldn't know for sure whether the situation where the child was showing matched any real display situation, for example the child might be width:auto and the parent is always resized explicitly when it's not display:none.

comment:3 Changed 5 years ago by jasonkarns

This ought to be reopened. This applies to both height and width (the bug details ought to be updated)

In addition to reporting the percent values as pixels when a parent element is display:none, jQuery also reports the dimensions incorrectly when the element is not currently attached to the DOM.

An implementation should be fairly straightforward: jQuery already has the a visibility filter (the :visible/:hidden selector) that tests for whether the element affects page layout (has dimensions && not a descendant of display:none && is attached to the DOM). Simply returning 0 for the height/width of any :hidden element would be proper behavior.

The behavior of the visibility filter and the dimensions of an element are already tightly correlated. A visible element has non-zero height/width and a hidden element has zero height/width *by definition*. As long as height() and width() return their percent values even while :hidden, we have a glaring violation of what these two concepts mean with respect to one another.

I've created a test case to demonstrate the issue: http://jsfiddle.net/jasonkarns/DEanZ/4/

comment:4 Changed 5 years ago by dmethvin

A visible element has non-zero height/width and a hidden element has zero height/width *by definition*.

The current behavior of .width() is to make heroic attempts to answer the question, "What would the width of this element be if it wasn't hidden by a direct display:none on it?" And it's done that since about jQuery 1.4 or so. Which means that any attempt to redefine this and always return 0 is going to break a lot of code written over the years. See #7618 and #9945.

It seems like any code that asks for the height/width of a parent-hidden element is asking the wrong question and wouldn't like the answer of 0 anyway. There are many better ways to determine this that don't force layout, such as .is(descendant-of-parent-known-to-be-currently-hidden)

Note: See TracTickets for help on using tickets.