W3C home > Mailing lists > Public > www-style@w3.org > February 2015

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 26 Feb 2015 11:42:48 -0800
Message-ID: <CAAWBYDDNHwYwSF_vBzxcpTzmSGJak4d1r-7nfGH04n01uA-y5g@mail.gmail.com>
To: www-style list <www-style@w3.org>
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:

Emil said:
> Supporting two different margin percentage resolution
> models adds a lot of complexity with very little upside.
> It also introduces more confusion in that percentage
> margins are handled differently for flexbox/grid and all
> other elements.
>
> I'd argue that we shouldn't support this and have the
> spec changed to be consistent across elements.

Ojan said:
> I'm not longer a decision-maker here, but I'll add a bit
> more background data. Christian is closer to the
> implementation side of this than I am these days. I've
> been opposed to this change from the beginning and
> brought it up with the CSS working group many times.
>
> All the bugs Chrome or Firefox have received that I've
> seen have been around authors trying to get the legacy
> behavior on flexboxes and having it not work in Firefox.
> For better or worse, there are some standard aspect ratio
? hacks percentage padding/margin are used for that the
> specced behavior breaks. As best I can tell, there aren't
> other use-cases for percentage padding/margin anyways.

Christian said:
> Yeah, I'm not really happy about this part of the spec and
> would really rather not implement it. So basically I agree
> with Ojan and Emil here.
>
> Note that for margin this would be fairly straightforward to
> implement afaict, only padding is the problem. But I doubt
> we want those to be inconsistent with each other.

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?

~TJ
Received on Thursday, 26 February 2015 19:43:35 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:01 UTC