[css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items

Section 6.4 allows implementation to resolve the percent values of margins and padding in one of two ways - their own axis or their inline axis. This is very unfortunate from the point of view of interoperability and I hope we can align on a single proposed behavior.

Section 4.2 of the [css-flexbox] has the same wording, probably for the same reason. Maybe if the issue gets resolved, it should be resolved in both places?

@SelenIT

@SelenIT Absolutely. Doing otherwise would be quite objectionable imho!

We've taken quite a bit of care to keep flexbox and grid aligned as much as we can and this is great. As far as this issue is concerned I'm not sure this is a hard requirement. In fact, this is one of the places where the two modules differ.

When we introduced grid it was our intention to provide two dimensional, symmetric layout behavior as much as possible. Since then the spec moved mostly in terms of syntax, thus, this behavior principle is something we still feel strong about.

Flexbox on the other hand is a single dimensional space distribution, thus keeping everything symmetric is not that necessary.

These were our hopes and intentions but reality is different. After releasing grid in all current browsers we are fragmented between webkit and blink supporting non-symmetric % resolution while gecko and edge have a symmetric resolution. At the end of the day this is pretty bad for interop and we already see some pages being broken due to this difference.

The following options should help us decide on a single, interoperable behavior.

Resolve flexbox % against inline axis (non-symmetric) and change grid to resolve all % in their own axis (symmetric)
Align with blink and webkit - both flexbox and grid to be asymmetric (resolve margins and padding % in their inline axis)
Align with gecko and edge - both flexbox and grid are symmetric (resolve all % in their own axis)

@tabatkins

In addition to the above options, I'd like to add, since the stated reasoning by @tabatkins /Google of keeping this asymmetric was to allow the percentage padding hack for aspect ratio to work. I would like to submit that we should actually solve this problem in CSS. The hack alone proves developer need of this and I think a V1 shouldn't need to be overly complicated. This may allow us to have the best of both worlds and keep grid or flex (based on the above resolution) symmetric while providing authors with an actual aspect ratio solution. I have a few ideas in this space and I know others probably do as well.

@gregwhitworth

I'd like it interoperable, I don't think (with my author hat on) that I have a very strong opinion as to whether it should or should not be symmetric, or whether we need to keep grid and flexbox the same. I could write this up as a blog post though with examples and see if i can get some author feedback if that would be helpful?

I would love to solve the padding hack issue though anyway, and agree with @gregwhitworth that there is clear developer need to do so.

@rachelandrew

@rachelandrew getting a blog post out is an awesome idea! Let's see what the rest of the community thinks and if they care enough about it.

@rachelandrew

There have been several discussions about this topic in the past, I'm linking the last one I found just for reference: https://lists.w3.org/Archives/Public/www-style/2015Feb/0521.html

Regarding this issue there are some use counters in Chrome to measure the usage of percentage vertical padding and margins in flexbox:

Percentage vertical padding: https://www.chromestatus.com/metrics/feature/timeline/popularity/955
Percentage vertical margin: https://www.chromestatus.com/metrics/feature/timeline/popularity/956

I guess one question is to know if people are using it for the aspect ratio trick, and if so if we're planning to remove that possibility without having a good alternative. Probably @rachelandrew's post could help to gather valuable feedback on that topic.

Adding @cbiesinger to the loop as he participated in previous discussions about this topic and is the flexbox maintainer on Chrome.

The issue was indeed discussed in the past (around 2015) and I even proposed a feature that would allow authors to chose which sizing applies to a given layout container such as grid, flexbox or block (see the NYC f2f minutes ). The jsbin I used seems to be alive as well and the property suggested was box-percent-sizing: symmetric | asymmetric; just so it is closer to box-sizing.

The aspect ratio argument was discussed at that time too with the obvious questions of "if we really need it, why isn't there a dedicated property for it?" etc.

@malix0

@malix0 the feedback here is more mixed than you're representing. And no one's particularly happy with this result.

There apparently is enough web content that depends on the blink/webkit behavior that the other engines have to match it. We still might be able to figure out some other way of supporting grid layouts with entirely independent axis measurements, but it can't be the default.

Agenda+ since we didn't actually resolve yet.

[css-grid-1][css-flexbox-1] Commit changes to require percent margin/…

@astearns

@astearns, may be this is necessary to not break things, but we developer need a logical way to do things and to me this don't looks really logical. But now it is. I hope so that something like %w and %h will be supported. I don't think this will be much difficult because Edge (@atanassov) and Firefox (@dholbert) developers just changed things in a day

Just in case, about the ratio problem...

In Sciter I've introduced width and height functions.

height: width(75%);
line-height: height(100%);
width: height(50%)

benefits are clear I think: no need for special units - the feature can be added without changing existing grammar definitions and parsers.

The Working Group just discussed [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items, and agreed to the following resolutions:

RESOLVED: Both flexbox and grid items top and bottom margin and padding percent resolves against the available inline direction.

The full IRC log of that discussion

<dael> Topic: [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items
<dael> github: https://github.com//issues/2085
<dael> Rossen_: This is back from last week. Spec one option to resolve padding and margins for grid and flex items.
<dael> Rossen_: We discussed last week. I pinged dholbert and Mats on the thread. dholbert responded from Gecko and acknowledged they will change their behavior and they linked to a bug
<dael> Rossen_: That means we can resolve unless there's additional feedback or objections.
<dael> Rossen_: Current prop: both flexbox and grid items top and bottom margin and padding % resolves against the available inline direction.
<dael> Rossen_: Any thoughts? Comments? Objections?
<dael> RESOLVED: Both flexbox and grid items top and bottom margin and padding percent resolves against the available inline direction.

Navigation Menu

Repository navigation

[css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items #2085

53 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items #2085

Description

Activity

SelenIT commented on Dec 6, 2017

fantasai commented on Dec 6, 2017

atanassov commented on Dec 6, 2017

gregwhitworth commented on Dec 6, 2017

rachelandrew commented on Dec 7, 2017

atanassov commented on Dec 7, 2017

mrego commented on Dec 7, 2017

atanassov commented on Dec 7, 2017

53 remaining items

astearns commented on Jan 26, 2018

fantasai commented on Jan 26, 2018

malix0 commented on Jan 28, 2018

c-smile commented on Jan 31, 2018

css-meeting-bot commented on Jan 31, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions