Re: [css-flexbox] percentage paddings, again

On Thu, Apr 17, 2014 at 6:55 PM, Ojan Vafai <ojan@chromium.org> wrote:
> On Thu, Apr 17, 2014 at 8:50 AM, Greg Whitworth <gwhit@microsoft.com> wrote:
>> > I made this codepen to outline the case:
>> > http://codepen.io/radium-v/pen/ropFz
>> > The example works as I'd expect in Chrome 34, IE11, and Safari 7 - but
>> > it unfortunately breaks in Firefox 28 (Daniel suggests the opposite though,
>> > that FF
>> > exhibits the correct behavior while the other browsers fail to match the
>> > spec).
>> > It seems to me that the paragraph from the spec is intended for
>> > single-line flex containers. It doesn't take into account how multi-line
>> > containers
>> > should behave, especially their dimensions aren't explicitly defined.
>> > There's some more detail regarding this section of the spec found here
>> > http://lists.w3.org/Archives/Public/www-style/2013Mar/0688.html
>> > I'm in favor of changing things here - it shouldn't be assumed that a
>> > flex container is more likely to be given an explicit height, since it's not
>> > assumed in most other cases.
>>
>> Those are all valid points, but we would prefer Grid and Flex being
>> consistent with one another and resolving these values in the same manner.
>> Because of that, we are in favor of IE and Chrome updating their
>> implementations to match Gecko and the spec. I do think you bring up an
>> interesting use case and would love to see us address it since authors will
>> undoubtedly hit it.
>
>
> I agree that grid and flex should be consistent, but disagree with your
> conclusion.
>
>>
>> I do like Tabs idea of a property because then there is no confusion to
>> the author as to what they are selecting to resolve against. I also think
>> that resolving padding-top against the width is similarly confusing to
>> authors and we shouldn’t repeat that (I understand why they chose that for
>> flows) but for a long time I always assumed that it _WAS_ resolved against
>> the height.
>
> Yes it's confusing and weird. If I were designing the platform from scratch,
> I would just disallow percentage height/padding entirely. But, making
> flexbox/grid be different than every other display type just adds to the
> confusion.
>
> If there were significant use-cases that we couldn't meet with percentage
> paddings resolving against the width, then it might be worth reconsidering,
> but I have yet to see compelling use-cases and have seen bugs from web
> developers where they want the resolve-against-width behavior. In the time
> we've been shipping flexbox, we've never once gotten a bug filed where
> someone wanted to have percentage paddings resolve against height.

The CSSWG ultimately decided to stick with the current wording, where
percentage padding is relative to the axis its in rather than always
relative to the width.  There were several reasons:

1. The fact that percentage vertical padding is relative to the width
in existing display modes is bizarre.  It seems to be because existing
display modes are all document-focused, where the only relevant input
dimension is width; height is virtually always just an output
variable.  Flexbox and Grid are both application-focused, and both
dimensions are relevant as inputs when using them.

2. Flexbox in particular is direction-agnostic; its layout algorithm
acts identically regardless of whether it's laid out vertically or
horizontally.  it would be an odd quirk if percentage padding was the
*one* aspect of its layout algorithm that varied based on direction -
a main-axis percentage might be relative to the main-axis container
size *or* the cross-axis container size, depending on orientation.

3. Flexbox and Grid are intentionally in sync as strongly as we could
make them; a one-column/row Grid should be almost identical to a
low-powered Flexbox.  Grid has been long established as having
percentage vertical padding relative to the vertical size, and users
of Microsoft's early implementation also depend on this.  Since we
can't (and don't want to) change this for Grid, we don't want to
change it for Flexbox either.

We recognize that there are some drawbacks, notably the inconsistency
with existing document-focused display modes, and the loss of the
ability to employ the common "aspect-ratio" hack involving vertical
padding.  We believe that the first is not too relevant, as most
authors don't use percentage padding in the first place, and those
that try (including me!) often already assume it's resolved against
the height. We also have a consistent principle in place that will
ensure further app-focused display modes act the same way.  The second
is unfortunate, but we plan to address aspect ratios directly in the
future, and so consider the loss of this hack for now to be not
significant enough to sway our opinion.

~TJ

Received on Tuesday, 6 May 2014 18:34:10 UTC