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

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

From: Rossen Atanassov <Rossen.Atanassov@microsoft.com>
Date: Fri, 27 Feb 2015 00:01:24 +0000
To: Tab Atkins Jr. <jackalmage@gmail.com>, www-style list <www-style@w3.org>
Message-ID: <BY2PR03MB192A4F85A685C101764573A9B150@BY2PR03MB192.namprd03.prod.outlook.com>
> -----Original Message-----
> From: Tab Atkins Jr. [mailto:jackalmage@gmail.com]
> Sent: Thursday, February 26, 2015 11:43 AM
> 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.

Document flow is a continuous type of layout thus taking dependency on the fixed dimension (width in top-to-bottom writing scripts) is much more intuitive and easier to express. Resolving padding and margin percentages from the containing page or paragraph width was a decision made probably 20 years ago when the web was used predominantly for reading and it still makes sense today (for that particular type of layout).

> 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.

Almost... We all recognized that the web is evolving into an application platform hence the presentation requirements became closer to other presentation frameworks. Having symmetry between the different dimensions is something that every developer coming from Java, MFC, XUL, XAML etc. expects. Flex and grid are arguably the solutions we're trying to give application developers so that they don't have to do everything on their own using abs pos (where the symmetry exists for top and bottom).

> 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?

You know better than anyone that specs aren't here to force us into implementing something but rather provoke consistency between our implementations. It is your right to decline from the spec but I don't see that being a good enough reason for changing it, thus I would object this proposal.

Speaking from implementation experience, making both flex and grid percentage resolution work per spec never imposed any technical difficulties... algorithmic or performance. If anything, having this symmetry made the codebase more consistent. Also the feedback we have received from our tooling partners in VS and developers building applications using flex and gird has been nothing but positive. 

Received on Friday, 27 February 2015 00:01:54 UTC

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