Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#13777 closed defect (wontfix)

"position:absolute" inside ScrollableView can screw up scroll calculation

Reported by: Ming Zhe Huang Owned by: ykami
Priority: high Milestone: tbd
Component: DojoX Mobile Version: 1.7.0b1
Keywords: Cc: Atsushi Ono
Blocked By: Blocking:

Description

Please see the video. Test case is also attached.
This test case derives from a much more complex scenario in which "position:absolute" is used for layout. However, if "position:absolute" is used, you cannot scroll to the bottom of the view.

Attachments (2)

testAbsoluteScrollableView.html (1.6 KB) - added by Ming Zhe Huang 8 years ago.
Test Case
testAbsoluteScrollableView.swf (72.5 KB) - added by Ming Zhe Huang 8 years ago.
video

Download all attachments as: .zip

Change History (6)

Changed 8 years ago by Ming Zhe Huang

Test Case

Changed 8 years ago by Ming Zhe Huang

video

comment:1 Changed 8 years ago by ykami

Cc: Atsushi Ono added

comment:2 Changed 8 years ago by Atsushi Ono

It is the standard HTML behaviour that the size of absolute positioned child block is ignored to compute the size of parent container. In this case the computed height of ScrollableView's containerNode is 0px, so you cannot scroll to the bottom of the list. This works as expected.

To avoid this, please try the followings:

  • Reconsider whether position:relative can be used instead
  • Set the height of ScrollableView's containerNode explicitly as below
dijit.byId("parentScrollableViewId").containerNode.style.height = "500px";

comment:3 Changed 8 years ago by ykami

Resolution: wontfix
Status: newclosed

Archer, it is obvious from the CSS spec that a container element does not expand if its children are all absolute. In addition to onoat's suggestions, another possible idea I think is to have a place holder relative div element with an explicit height specified. That way you don't have to care about the ScrollableView's internal containerNode.

comment:4 Changed 8 years ago by Ming Zhe Huang

Thanks. I totally agree that this bug is invalid.

A suggestion. This bug may remind us that we need more layout strategy or layout containers, then people are less likely to take care of details of layout by themselves, which sometimes is cumbersome or rigid.
Actually in my scenario the problem can be solved if we have a expanding box which eats remaining space not occupied by siblings, something like CSS3 flex box tries to provide.

Note: See TracTickets for help on using tickets.