Re: [css-flexbox][css-grid] Reverting vertical % padding/margin to match block

I agree that Grid and Flexbox should do the same thing here. I also agree
that we should not overly constrain new APIs by past decisions where a
change is a significant improvement. But, I don't think this case falls
under that principle because the specced behavior is not actually an
improvement in practice.

The reason I feel strongly about this case is that I have yet to hear
anyone argue that this change is better for any real use-cases. I've only
seen arguments that are principled (e.g. that it's just "wrong" for
percentage padding/margin heights to resolve against the width). I don't
see important use-cases for percentage margin/padding at all, so I don't
see the benefit in further complicating the platform for them.

When you combine that with the fact that we have bug reports showing that
web developers want and expect the non-specced behavior and that two major
browsers ship that behavior (and always have), I only see upsides to
changing the spec and downsides to keeping it the way it is.

It goes without question that we should strive to get all browser vendors
to agree and ship the same thing. It just so happens that this is hard to
implement efficiently in Blink, but that is *not* why we don't want to
implement it. It just makes us that much more reluctant to invest time
towards a decision we disagree with.

As stated above, I'm not a direct decision maker on Blink at the moment, so
these are just my own opinions, although I have the impression that the
current Blink folks working in this area agree with the sentiment I'm
expressing here.

On Sat, Feb 28, 2015 at 9:56 AM fantasai <fantasai.lists@inkedblade.net>
wrote:

> On 02/27/2015 11:37 PM, Tab Atkins Jr. wrote:
> > On Fri, Feb 27, 2015 at 7:14 PM, fantasai <fantasai.lists@inkedblade.net>
> wrote:
> >> On 02/26/2015 02:42 PM, Tab Atkins Jr. wrote:
> >>> Traditionally (for uninteresting reasons), vertical percentage padding
> >>> on elements was resolved relative to the *width* of the element, not
> >>> the height.  In other words, in ".foo { width: 100px; height: 200px;
> >>> padding-top: 50%; }", the value of padding-top is 50px, not 100px!
> >>>
> >>> This was a weird detail and quite different from how percentages work
> >>> pretty much everywhere else in the language, but some people came to
> >>> depend on it, such as to create elements with aspect ratios.
> >>>
> >>> Flexbox and Grid, being new layout modes, took the opportunity to fix
> >>> this, and defined that vertical percentage margins and padding are
> >>> relative to the height of the element, like you'd naively expect.
> >>>
> >>> Blink has never implemented this, and in talks with our implementors,
> >>> we don't plan to.  Some quotes: [...]
> >>>
> >>> So, while I understand and am totally sympathetic to the reasons we
> >>> defined the behavior the way we did, I also find the counter-arguments
> >>> reasonable.  Since we're fairly intent on willfully violating the spec
> >>> here, would it be okay to change the spec back to match the % behavior
> >>> that Block has?
> >>
> >> I don't have a strong opinion one way or another, and wouldn't mind
> >> changing the spec back if that helps authors with consistency or there's
> >> content depending on it or whatever. However, I'm strongly in favor of
> >> keeping Flexbox and Grid consistent. If we change, we change both of
> them.
> >
> > Strongly agree, and why I purposely talked about both Flexbox and Grid
> > here.  These two are clearly linked up and should act the same,
> > regardless of which way we settle.
>
> The initial reason for the change was that Grid, as drafted and implemented
> by Microsoft, was the other way around. If they refuse to change Grid, and
> Blink refuses to change Flexbox, then we have a problem.
>
> ~fantasai
>