W3C home > Mailing lists > Public > www-style@w3.org > March 2013

Re: [css3-flexbox] alignment and overflow:scroll

From: Tony Chang <tony@chromium.org>
Date: Tue, 12 Mar 2013 10:13:29 -0700
Message-ID: <CAL-=4P2WvZXE-5-iY+NoxUYyc3UiNdfPjNSi7sZURSfx9Q26-Q@mail.gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style@w3.org" <www-style@w3.org>
On Tue, Mar 12, 2013 at 8:27 AM, Tab Atkins Jr. <jackalmage@gmail.com>wrote:

> On Mon, Mar 11, 2013 at 3:56 PM, Tony Chang <tony@chromium.org> wrote:
> > I'm confused about the order in which we apply alignment and overflow on
> the
> > flexbox.  Here's an example with stretching:
> >
> > <div style="display: flexbox; overflow: scroll; height: 100px;">
> >   <img intrinsic-height=200px>
> > </div>
> >
> > Should the image resize to a height 100px with no scrollbar on the
> flexbox
> > or should the image stay at 200px and the flexbox get a scrollbar?
> Following the algorithm, we determine in step 2 that the available
> vertical space is 100px.  In step 3, we use the last bullet point, and
> lay the element out normally, as if it were in block flow, to
> determine its size.  Replaced elements do not naturally shrink to fit
> into the space, so its hypothetical height is 200px.
> Then, down in step 14, we deal with align-self.  This specifies that
> the element must be adjusted to the cross-size of the flexbox, so its
> height gets shrunk to 100px.  No scrollbar is generated.

OK, sounds reasonable to me.

> In general, scrollbars will only be generated if a min-height is
> involved (which prevents 'stretch' from shrinking it to the height of
> the flexbox), or alignments other than 'stretch' are used.
> > Here's a similar example:
> > <div style="display: flexbox; overflow: scroll; height: 100px;">
> >   <img intrinsic-height=200px style="item-align: flex-end">
> > </div>
> You meant "align-self: flex-end", right?  I'll proceed as if that was the
> case.

Yes, that's right, sorry.

> > Where is the cross-end?  Is it the bottom of the flexbox (100px), causing
> > the flexbox to overflow out the top, or should the scrollable area
> extend to
> > 200px tall?
> Here, we do the same things we did previously, except when we come to
> step 14.  Now, because the alignment is 'flex-end', it doesn't have
> its height adjusted, and just aligns its cross-end edge with that of
> the flexbox. So, yes, it then overflows out the top.  However, because
> scrolling containers don't show their overflow, and you can't scroll
> past the top of an element, the overflowing part is simply clipped and
> is completely inaccessible.  (If we ever allowed scrollable areas to
> scroll into negative positions, you could get to it.)

Just to be clear, you're saying that there would be no scrollbar and we
would clip the top 100px of the image.  Likewise, if the flex item had
align-self: center, we would clip the top 50px of the image.  This seems
reasonable to me too.

> > Should absolutely positioned flex items also increase the size of the
> > scrollable area and change the position of cross-end?  This is further
> > confused in the wrap-reverse case where the cross-start is the bottom of
> the
> > flexbox (we need to resolve absolute position to determine the scrollable
> > area size, but absolutely positioned items will move during wrap-reverse
> > after we've computed the scrollable area size).
> This brings up an interesting question - if the flexbox is scrollable,
> should we take that into account when determining the available space,
> making those dimensions infinite?  If we did, then English text in a
> row flexbox would trigger orthogonal flow stuff, unless we figured out
> some way to reword the the third bullet point in step 3 to avoid this.
> I'm inclined to say "no", and leave the available space calculations
> alone (except that scrollbars subtract from them, which does need to
> be edited in).  That keeps things simple and predictable, and avoids
> any issues like what you've brought up.

This is fine with me as well and makes implementation much simpler.  Thanks
for the clarifications.
Received on Tuesday, 12 March 2013 17:13:57 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:09 UTC