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

[atanassov]

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.

[SelenIT]

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?

[fantasai]

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

[atanassov]

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.

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

[gregwhitworth]

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.

[rachelandrew]

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.

[atanassov]

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

[mrego]

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.

[atanassov]

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.

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

This isn't quite right. Our stated reason was that the aspect-ratio hack was the only significant case (that is, the only case that showed up in non-trivial numbers in our use-counters) for using % padding in the first place. Virtually nobody was using % padding for anything else at all.

Thus, there was no argument for making %s relative to each axis, besides a weak sense of theoretical purity ("what it should have been to start with"). And, since we can't change the behavior for block layout, that's directly clashing with the other theoretical-purity argument, that %s on padding should work the same in all display modes.

I agree that we should add an actual aspect-ratio feature; I have a (flawed) proposal for this in my blog from 2010. But that has no bearing on this issue; we'll still be stuck with the weird % behavior in block layout for compat reasons, and there's no strong argument for making other layout modes have different behavior than this.

[atanassov]

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

Looking at your use counters it's clear that introducing grid raised the numbers immediately... seems like another great opportunity missed to rid the web of wacky patterns.

As to this being "theoretical purity" - you can make that argument for block and table layout where heights are results of widths. Before introducing grid however, we worked hard to make sure % values actually work.

[tabatkins]

% heights have nothing to do with width, let's not get sidetracked.

[atanassov]

@tabatkins - the reference was to all % values. Heights do behave much better and agree that we shouldn't be pulling these in the discussion - wasn't my intention.

[radium-v]

Hi,

I wrote a blog post about this issue back in 2015: http://www.radiumvinteractive.com/flexbox-percentage-margins-and-paddings/

I think my original suggested idea to add a new property would definitely be overkill, but the interop situation is definitely still confusing for authors like me.

[tantek]

I think there's still a preference to keep this symmetrical for actual use-cases, like similar features in native-app UI frameworks. Either way I agree with finding an actual solution to the hack use-case that doesn't involve polluting/abusing this feature.

[mrego]

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

Looking at your use counters it's clear that introducing grid raised the numbers immediately... seems like another great opportunity missed to rid the web of wacky patterns.

The big jump on the usage is related to a change on how counters are measure in Chromium to get more realistic values, so not directly related to Grid. See the note:

Note: on 2017-10-26 the underlying metrics were switched over to a newer collection system which is more accurate. This is also the reason for the abrupt spike around 2017-10-26.

[css-meeting-bot]

The Working Group just discussed [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items.

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/w3c/csswg-drafts/issues/2085

<dael> Rossen_: I'll intro this, but I'm also going to timebox this. We've beaten this down in the past quite a bit. We've stated differences already openly. I think the current GH captures a lot of this.

<dael> Rossen_: I want to recapture the topic and i'm speaking as an edge impl on this.

<dael> Rossen_: Base of the problem is that we have a spec that defines 2 diff models of resolving % values for margin & padding top/bottom

<dael> Rossen_: They are spec for flexbox and grid to either resolve % against inline direction and that matches with block behavior.

<dael> Rossen_: Other proposed/defined behavior is keep everything symmertic and resolve top & bottom in the same axis as the height and width and those resolve in the respective block direction.

<dael> Rossen_: I expressed the differences between flex and grid from our PoV. In this case I am a proponent of keeping flexbox and grid as close as possible. I wouldn't push for that principle on this, but I wouldn't be opposed. Flex is mostly a single dimentional layout where we distribute empty space in block or inline direction.

<dael> Rossen_: In the veritical case that's a lot closer to block layout.

<dael> Rossen_: Grid has always been 2d layout and we have attempted to keep everything as symmetric as possible when we worked on this, even internally at MS. That was a key preinciple. Everything is resolvable and symmetric to the extent where things are computable.

<dael> Rossen_: This has been our behavior since the original grid. Later Gecko & FF caught up with grid and flexbox. At this point the blink and WK impl cought up with grid and the opposite for the inline direction % resolution was proposed/accepted b/c of those impl and the strong argument at the time was that people were trying to use % padding aspect ratio hack for grid items.

<dael> Rossen_: And here we are today.

<dael> Rossen_: Thanks to people from Igalia we have data that suggests current usage of those properties as % has incresed after we had a wider release of grid. That, looking a thte numbers, is at least 2-4x higher.

<dael> Rossen_: The reason I'm bringing this up is we're starting to see non-interop content. There are broken webpages due to this.

<rego> just a clarification, the jump in the metrics is unrelated to grid shipping, it was a change in the way to measure use counters in Chromium

<dael> Rossen_: I'll give you an example of this where content looks broken on seemingly normal wordpress sites.

<rego> > Note: on 2017-10-26 the underlying metrics were switched over to a newer collection system which is more accurate. This is also the reason for the abrupt spike around 2017-10-26.

<dael> Rossen_: I'd like L1 of grid and flexbox with jsut one behavior so that we're not introducing more breakage.

<dael> Rossen_: That's everything I want to say.

<dael> Rossen_: At this point the higher order importance is that we have interop o nthose basic layouts that will be adopted more and more.

<dael> Rossen_: I'd like to hear from Chrome folks if there are additional opinions or data.

<dael> TabAtkins: Nothign that hasn't been said a year ago when we first had to introduce the undefinedness of this. We cannot change behavior of blocks, it should have been symmetric. Only reasonable use of % is the aspect ratio hack. Even though it's weird, being consistant with block seems easier for authors.

<tantek> FWIW "consistent with block" on one hand, "consistent with positioned elements" is the other.

<dael> TabAtkins: Ulimately I don't care, I want consistancy. We're split in half. Once 3 browsers converge we can change the spec to that. I don't want to change until someone bites the bullet and changes behavior.

<Rossen_> http://www.gpkafunda.com

<rachelandrew> I'm having trouble with audio (on hotel wifi) but I noted in the issue my thoughts previously

<Rossen_> q?

<dael> Rossen_: URL that's an example where in FF or Edge you'll see breakage.

<dael> Rossen_: WOuld FF or Gecko be willing to change to match Chrome?

<dael> dbaron: I don't know off the top of my head.

<dael> dbaron: I'd need to look into history.

<dael> Rossen_: Our position is we want interop. We're more willing to change now that grid is impl everywhere (which is awesome).

<dael> Rossen_: Once thing I want to throw out is there was another poss. solution proposed a couple years ago by myself in NY to entertain the idea of a switch to resolve % in one way or the other based on the container itself.

<dael> Rossen_: It took me a couple of days to make a prototype and make it work. That's another potential way forward.

<dael> Rossen_: However I said I'd timebox. I don't want to force a decision on this call. I really want to see grid L1 and flexbox have a single defined behavior on that.

<tantek> q?

<dael> Rossen_: Also, I know rachelandrew is having audio issues, but she offered to write a blog post. It would be grea to hear what the community has to say.

<fantasai> +!

<fantasai> +1

<rachelandrew> I'll write up something in the next couple of days once I'm back in the UK

<dael> Rossen_: To close the topic, does anyone else want to say anything?

<tantek> q?

<dael> tantek: I want to call out what I thought is new is it appears there's consensus on developing an actual solution to the aspect ratio hack. I see more interest on developing that in this issue then I remember previous interest.

<dael> tantek: In the hope of making progress on something with consensus I'd like to see the folks with proposals for that use case to post them in a sep. issue

<dael> fantasai: TabAtkins and I are planning to spec it for sizing L4 once L3 goes to CR

<dael> tantek: That would be great to see. I just wanted to call that out. I don't know if there's other new information.

<dael> Rossen_: That's great. gregwhitworth has been working on that from our end too so you might want to loop him into that discussion.

<dael> tantek: +1 to gregwhitworth

<dael> Rossen_: Anything else? If not we can continue after rachelandrew blogpost.

[rachelandrew]

I wrote this up as a post on the CSS WG blog, also cross-posted to my blog. I'll tweet about it and see if we can get any author feedback.

[marcvangend]

(Posting my thoughts here as @rachelandrew asked on her blog.)

If I understand correctly, the question is how to resolve top/bottom margins and paddings. Left/right margins and paddings obviously resolve against width.

My first intuitive response was that it's most logical when margins and paddings resolve against their own axis. You could compare it to how other percentage values work: height: 50% obviously means "50% of the container height", not "50% of the container width".

However, thinking about this a bit longer, I cannot imagine why I would actually _need_ a margin-bottom that is a percentage of the element's height. Would a designer ever say "If the editor enters more text in this area, I want it to have a bigger bottom margin"? I don't think that is very likely.

On the other hand, I come across fluid-width designs on a daily basis. Rachel's code pen uses fixed-width grid columns, but they might as well be 25% wide. I think it is very likely that a designer wants the column margins to scale with the column width, while keeping the margin bottom identical to the margin right.

Conclusion: I would choose to resolve top/bottom margins and paddings against width, because I think it has more practical use.

PS. Has it been considered to leave the choice to the programmer? Eg. introduce syntax like margin-bottom: 20%w and margin-bottom: 20%h?

[Dan503]

Oooh margin-bottom: 20%w and margin-bottom: 20%h sounds like an awesome idea. It lets us have more fine tuned control over how we want the percentages calculated.

Making %w and %h actual generic unit types would also solve the aspect ratio issue. You could do something like height: 50%w to create a 2/1 ratio container :)

As for what % would equal in flex and grid, I'm not really sure :/

From a logical sense, I like the idea of basing it off the same axis. From a practical sense though, if I say padding: 10%; I would expect equal padding around all sides of the container :/

[dpawson]

• their own axis (left/right percentages resolve against width, top/bottom resolve against height),

It makes sense (user perspective) over the second option.

As per the spec, currently sucks rather a lot.

[samnabi]

%s on padding should work the same in all display modes.

This is the most important factor for me as a web developer. I vote for asymmetric, keep the behaviour of percentage heights in grid and flex to be the same as block mode.

[CyberAP]

Keep it simple for the CSS newcomers and use symmetric axis relativity. It's a pain to figure that out for the first time when it doesn't work as expected. Something like box-fit (object fit for block-level elements) could be implemented to deal with aspect ratio issue. For those who want flexibility I think %w and %h is a great idea. Not only for Flexbox and Grid, but for the CSS units overall. That behavior would still let you use container width to do an aspect ratio hack.

[marcvangend]

@CyberAP I agree that it's good to consider simplicity, especially for newcomers, but can you provide a use case where said newcomer (or anyone else) would actually need percentage margins relative to the element height? I'm not saying it doesn't exist, but I couldn't come up with one.

[dpawson]

Where I'm dealing with no absolute values, e.g. for varying sight issues,
hence sizes.
Margins are just one aspect of visual ability.

On 20 December 2017 at 17:07, marcvangend [e-mail] wrote:

@CyberAP https://github.com/cyberap I agree that it's good to consider
simplicity, especially for newcomers, but can you provide a use case where
said newcomer (or anyone else) would actually need percentage margins
relative to the element height? I'm not saying it doesn't exist, but I
couldn't come up with one.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-353123013,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASOJ5ZVNG8FDA1_WeV1U_kRN-KxaiBLks5tCT7JgaJpZM4Q28qg
.

--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

[jamesej]

If you have a layout which varies in height but not width (e.g. to accommodate more or less content on different pages) then proportional spacing being relative to width makes sense as the width will remain constant and predictable as the height varies, so the spacing will not vary with how much content the layout contains. Generally you want spacing around an element to be the same in px horizontally and vertically or it looks odd.

However, if you happened to want to have a layout which extended _vertically_ to contain more content, you would actually want an asymettrical proportionality based on _height_.

This suggests as a general solution the addition of a CSS context property e.g. spacing-base-dimension: { vertical | horizontal | independent } which could apply to which dimension is used as the basis for calculating proportional spacing on all children. The default would be horizontal.

[Dan503]

Ok I've made up my mind now.

% on it's own stays consistent with display: block.

%w and %h are then introduced as new general units that gives you control over what axis you want to base the percentage on.

[pmccloghrylaing]

I'm in agreement with @marcvangend.

It seems more useful to be able to define padding and margins that are percentages of the same value in both directions. Having vertical and horizontal padding in proportion with each other seems like something that would be used all the time, whether it's defining gutters with margins or creating "cards" with consistent padding.

I also _love_ the idea of being able define what a percentage is relative to by specifying something like %w %h, although I wonder if it might be a better idea to follow the pattern of viewport relative units, something like w, h, min, max?

[CyberAP]

I also love the idea of being able define what a percentage is relative to by specifying something like %w %h, although I wonder if it might be a better idea to follow the pattern of viewport relative units, something like w, h, min, max?

That would be a good candidate to use with minmax function: minmax( 10%min, 10%max ); or alternatively minmax( 10%w, 10%h );.

[dpawson]

On 20 December 2017 at 20:14, jamesej [e-mail] wrote:

If you have a layout which varies in height but not width (e.g. to
accommodate more or less content on different pages) then proportional
spacing being relative to width makes sense as the width will remain
constant and predictable as the height varies, so the spacing will not vary
with how much content the layout contains. Generally you want spacing
around an element to be the same in px horizontally and vertically or it
looks odd.

However, if you happened to want to have a layout which extended
vertically to contain more content, you would actually want an
asymettrical proportionality based on height. This suggests the
addition of a CSS context property e.g. layout-base: { vertical |
horizontal | independent } which could apply to how this works on all
children with a default of horizontal.

​I am unable to see any logic in that second para.
If I want to 'spread out' vertically, why would that imply I also want the
same spreading
on the horizontal axis?

regards Dave​

--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk

[yisibl]

1. Keep the status of Flexbox.
2. Carry out the aspect-ratio property.
3. Consider adding the %w and %h unit (this abbreviation is a little strange, better to bepw/ph), but I'm afraid it will increase the complexity of the CSS. In fact, we just want to have a function to quickly achieve the vertical and horizontal ratio.

[Dan503]

Carry out the aspect-ratio property.

What would be the point of having the aspect-ratio property if we have access to a %w property?

height: 50%w; would be the equivalent to writing aspect-ratio: 2 / 1;

[trubblebruin]

I've never encountered a use-case where the Firefox implementation would be more sensible or useful than the Chrome implementation. In a common use case like a card grid item's margin-top matching the grid's horizontal spacing, with the Chrome implementation I can use margin-top: 2%; whereas with the Firefox implementation I need to do something that feels hacky, like margin-top: calc( 92vw / 50 ); (this example presumes the card grid is 92vw wide, to get around the writers of the Flexbox spec saying that percentage margins are a bad thing but not stating why).

[jamesej]

However, if you happened to want to have a layout which extended
vertically to contain more content, you would actually want an
asymettrical proportionality based on height. This suggests the
addition of a CSS context property e.g. layout-base: { vertical |
horizontal | independent } which could apply to how this works on all
children with a default of horizontal.

​I am unable to see any logic in that second para.
If I want to 'spread out' vertically, why would that imply I also want the
same spreading
on the horizontal axis?

I meant the last sentence as a general solution rather than specifically in the vertically extending case. I've edited my comment to make this clearer.

[revoltpuppy]

I'm inclined to go with Chrome’s solution, because content typically expands in height and it's hard to imagine increasing vertical spacing just because a box is taller; especially on mobile devices. However, that’s assuming that websites will continue to be built in this manner. I wonder if mass adoption and use of an actual layout mechanism (CSS Grid) will open up new possibilities that require Firefox's implementation. I don't have any examples, it's just speculation (and Grid is awesome).

That said, I think %w and %h would be a graceful solution.

[NicolasJEngler]

Our stated reason was that the aspect-ratio hack was the only significant case (that is, the only case that showed up in non-trivial numbers in our use-counters) for using % padding in the first place. Virtually nobody was using % padding for anything else at all.

Thus, there was no argument for making %s relative to each axis, besides a weak sense of theoretical purity ("what it should have been to start with"). And, since we can't change the behavior for block layout, that's directly clashing with the other theoretical-purity argument, that %s on padding should work the same in all display modes.

I'll have to agree with @tabatkins here, there's been previous cases where the spec leans on an already established behavior or convention rather than theoretical purity, and a reduced example case could be the spelling of the nowrap value for the white-space property. Maintaining consistency and following Chrome's approach seems more logical to me, however I'd still like to see an expansion of @marcvangend's idea for %w or %h units, independently of their spelling (I'm up for using syntax similar to those of viewport-relative units), as it provides a more granular control.

[mjamesderocher]

While I'd love to be able to do the 'aspect ratio hack' in Firefox, it does sort of make sense to stick with the way the spec recommends. Perhaps we could get a real solution for aspect ratio.

[lunelson]

Being able to reference the width or height of an element as a unit, either in the form of 50%w or just 50w would solve the aspect-ratio use-case elegantly and offer much more to CSS generally than the creation of a dedicated aspect-ratio property; but I agree with @tabatkins that this has no bearing on the question at hand.

The legacy is that percentage-based margin or padding refers to the width of the of the containing (parent) element, and personally I've always felt this fit with the 'grain of the web' (so to speak): e.g. the fact that block elements expand to the width of their container but have no intrinsic height. I feel this behaviour (asymmetric) makes sense for block and flexbox both, and should be spec'd as such.

However, Grid is an explicitly two-dimensional layout system in which there are intrinsic/implicit heights (of parents, children, grand-children, etc), and I think a clear use-case for having percentage-based margin and padding behave symmetrically.

So my vote is for option 1, from @atanassov 's second comment: asymmetric for flex, symmetric for grid.

[karimsabbagh]

I think it makes more sense that % padding and margins should resolve to their own axis. If that was implemented in non-flex elements, that would have made it easier to center items vertically (margin-top: 50%; transform: translatey(-50%) ) which is very useful when you don't know the height of the element.
And in the case of flex and grid, I don't see why it should be otherwise.
My vote would go for option 3: Align with gecko and edge - both flexbox and grid are symmetric (resolve all % in their own axis)

[contreforme]

I would make the same comment on a dedicated aspect-ratio property than @lunelson but I would differ on the vote, because as soon as we try and define a height property to an element (whatever its kind) we should be able to consider it to have it intrisically; that would be clearer than to suppose it will be for some kinds of elements, and not for some other kinds…
Finally, I would personnaly vote for the asymmetric way as when I consider a grid of elements (being composed of img, div, p, li, object, …) I am inclined to consider margins (or padding) as a "gutter" between the grid’s elements that should stay consistent on both x and y axis. But whatever the solution it will be ok as it should be - at last - consistent in all situations.

[malix0]

My vote would go for option 3: Align with gecko and edge - both flexbox and grid are symmetric (resolve all % in their own axis). Or why not provide both options, default resolve respect their own axis, but give possibility to use the other axis, for example "50% of width" or "w50%"

[Thomazella]

I care more about consistency across browsers than any specific solution. I also think that resolving vertical % against width is more practical even if counterintuitive at first. The suggestion of new units, or a property, to let us define the behavior is pretty cool. And on the subject of aspect ratio, I think a property for it is best. Something readable and elegant, like "aspect-ratio: 4 3."

[tomhodgins]

And on the subject of aspect ratio, I think a property for it is best. Something readable and elegant, like "aspect-ratio: 4 3."

I've thought about this too! I like the idea of an aspect-ratio property, though I think the value ought to be expressed as a ratio! CSS is already aware of ratios: https://drafts.csswg.org/mediaqueries-4/#typedef-ratio

Maybe something like:

aspect-ratio: 4/3;

[wernerglinka]

I only ever use % bottom padding with the percentage padding hack. Cases can be made for either approach but the inconsistency is what must be addressed.

For historical and market share reasons, I’d opt for:
Align with blink and webkit - both flexbox and grid to be asymmetric (resolve margins and padding % in their inline axis)

And the introduction of %w and %h

[Trve]

I was a web developer for more than five years before I encountered the (in my eyes) "weird" behavior that percentage-padding on the vertical axis resolves to the width. but I have to admit I learned it as part of the aspect ratio hack.

so for me it is both, counter intuitive and practical.

but we have a solution for things that are practical but not achievable at all or only achievable by hacks: create a spec for a feature that covers the needs.
so I'm supporting the idea of introducing new units that allow to define which axis you want to resolve against.

about the "counter intuitive" part of my analysis: yes, this part may be controversial.
but my personal experience with many of my colleagues I had to teach our explain something about CSS, especially non-webdev people, is comments like "wtf, why?" and something like this. for me this is somewhat dangerous when you think about what this makes people think about web development and web design. If I experience weird things like this early on my way of doing something on a new platform I will always be a little scared or uncertain about it. and this matches my own opinion about this specific topic.
I'd prefer to be predictable and intuitive over something like "this weird behavior has a practical use" or better in this case "there is no [obvious] practical use for the intuitive behavior".

and yes, consistency across all user agents is very important. I started web development back in the days when IE6 was still a thing. inconsistency is the worst. but right after this comes intuitiveness to merks the platform open and as easy as possible for newcomers.

but I want to raise one question, even though it speaks against my personal opinion:
wouldn't a change that removes the aspect ratio hack break [parts of] the web?

[GrigorisParaskevakos]

From my little experience rem and em work better when we need relative sizing and are more predictable with mobile devices. https://www.codecademy.com/articles/css3-features. Flexbox can be tricky if we do not define the correct parent element width.

[Pauan]

@atanassov

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

For option 1, I assume you mean that for horizontal flexboxes the % will resolve based on the height, and for vertical flexboxes the % will resolve based on the width. I am okay with that. I am not okay with it always resolving based upon the width.

I am okay with option 2, for the sake of consistency with display: block and also backwards compatibility.

I am okay with option 3, I believe it is the most theoretically correct option (but not necessarily the most practical option).

Essentially, I don't care that much which option is chosen, however, I strongly think %w and %h should be added: that solves every problem simultaneously:

• Authors get consistent behavior across browsers

• Authors can easily specify aspect ratio using %w and %h (no need for a new aspect-ratio property)

• Authors gain more flexibility: they can use %w on both axes, %h on both axes, or a mixture of %w and %h

  That means authors can choose whether they prefer option 1, 2, or 3, rather than having a one-size-fits-all approach (which doesn't work)

I've wanted %w and %h for many years, it would be a very useful addition in general.

Of course adding %w and %h will require filing a new issue, but I think it is indirectly related to this issue, which is why I'm mentioning it here.

[robsonvleite]

I have to say that anyone who wrote such a specification probably never put a project in production. Time, if I need a spacing of 10%, I expect it to have the same behavior on all sides. If I want to differentiate I already have how to define this using the properties of the margin.

I do not know about you but in more than ten years acting as a developer I never had a case where I had to calculate a height axis when it comes to web.

Was not the flexbox flexible? where is my flexibility in maintaining my grid without worrying about different devices when I have to think of two axes for the same property? In which case setting the height of a box of content is a plausible solution?

Are the specifications designed for a real world? That was not it! But how about a simple solution?

When the box has a defined height use it, if not use the width, and let the web be as flexible as it should be.

[Dan503]

@RobsonVLeite

When the box has a defined height use it, if not use the width

What? No! Don't swap the functionality around based on if the height has been defined or not. That's super confusing, especially for new devs. You set a height on something and then suddenly your spacing goes all wonky and you would have no idea why.

[gregwhitworth]

I have to say that anyone who wrote such a specification probably never put a project in production.

@RobsonVLeite While we desire and appreciate feedback from the community on specification issues, please do so in a respectful and constructive manner. Your opinion on this matter did not need to contain the above statement to get your point across.

[SelenIT]

The ability to get width-relative vertical margins already exists: it's block formatting. If you really need this, you can always get it by using a block wrapper or ::before/::after pseudo-elements as block placeholders. I guess this is what developers already have to do for this because of this "variance" in the implementations.

The ability to get height-relative vertical margins didn't exist at all in CSS before flex/grid layout (except absolute positioning which is a very different case). This ability also looks very natural to flex/grid items where we have different options to align them vertically relatively to the row/line height, which is not the common case for block layout. If we drop this ability, we would lose it forever and would have to resort to absolute positioning when the need for it occurs.

Considering this and in order to keep things simple (as @CyberAP said), I'd prefer @atanassov's option 3 (symmetric resolution for both Grid and Flexbox by deafult). And the ability to explicitly specify width or height percentages (the exact syntax TBD) would be the extremely useful addition too, of course.

[css-meeting-bot]

The Working Group just discussed Issue #2085.

The full IRC log of that discussion

<dael> Topic: Issue #2085

<astearns> https://github.com/w3c/csswg-drafts/issues/2085

<dael> github: https://github.com/w3c/csswg-drafts/issues/2085

<dael> Rossen_: We discussed ~1 month ago. I raised it before we locked down flexbox and grid. I wanted one behvaior for resolving hte block level padding and margins. Current spec allows to resolve those from corrisponding inline or block axis.

<dael> Rossen_: In a little more css2.1 terms top and bottom margins resolve to either height or width. FF and Edge impl that we resolve from the same direction as the padding and margin. Webkit & Blink impl the similar behavior to block. They resolve from width. THat enables the hack to have the aspect ratio on elements other than replaced.

<Rossen_> https://www.bloomberg.com/pursuits/travel

<dael> Rossen_: We've gone by for a couple years. Now that grid picking up we're seeing pretty bad compat issues

<Rossen_> https://thepeachtruck.com/blogs/the-peach-truck-kitchen

<Rossen_> https://maps.google.com/localguides/event/summit

<dael> Rossen_: here's a couple. If you have FF or Edge you can compare.

<dael> Rossen_: A month ago we left that rachelandrew would write a blog. She did. Thank you.

<dael> Rossen_: We got back quite a bit of opinions. They are kind of split. To summerize about 1/2 the people want to be able to spec on value and expect that padding and margin is the same.

<astearns> lost rossen

<Rossen_> getting back

<fantasai> https://wiki.csswg.org/planning/berlin-2018

<dael> fantasai: While we wait. If you're planning to come to Berlin please put yourself on the wiki. If you're interested in air BnB let florian or I know.

<dael> Rossen_: I'm back.

<dael> Rossen_: Second part of the group advocated for keeping the behavior symetric

<dael> Rossen_: They basically wer emotivated beuase they don't want to learn the wacky way of resolving against something not the same.

<dael> Rossen_: We are where we are. I listed some of those bad compat issues.

<dael> Rossen_: One other point brought up is at this point there's quite a bit of usage in Chrome so this won't be easy for Chrome to back away unless they want the compat issues we have.

<dael> Rossen_: Given where we are and the community is split I think the better service to the web is align on something which is at least consistant. For that reason I'm going to go and impl this behavior in the next version to Edge, to align to Chrome and Webkit, provided we can resolve to go with that.

<tantek> I thought we were going to give more time for a proposal for the aspect ratio stuff first?

<tantek> so we could eliminate that as an excuse

<dael> Rossen_: Last time we chatted TabAtkins was, I believe, also fine with going down to one behavior as long as there's impl interest. I'm committing to changing Edge so the only thing wuld be for FF to catch up.

<dael> Rossen_: But we are not going to continue to put our users through this suboptimal experience.

<dael> Rossen_: So I'm sorry I couldn't hold up for the new comers to CSS. It is what it is. So for UX we'll align with Chrome and Webkit.

<dael> Rossen_: I want to put it back on the WG to resolve on one behavior and I mostly want to hear from FF since they'll be the only ones left with the different behavior.

<dael> dbaron: I'd want to hear Mats' comments. I haven't spoken to him on this for a bit.

<dael> tantek: I'd like to hear from dholbert as well before FF has an opinion.

<dael> Rossen_: I don't mind if we hold back, but at this point we're going to ship to be interop with webkit and blink behavior on our next version.

<dael> Rossen_: So this will put more pressure on your folks. But that doesn't mean you have to agree right now. Please chat.

<dael> fantasai: One pattern I saw in the comments is a lot from the group supporting assymetic is that it initially doesn't make sense, but it is more useful more of the time in the end.

<dael> fantasai: I found that convincing.

<tantek> basically this is about giving in to compat right?

<dael> Rossen_: I also found it convincing. But given that everyone can only use that it's hard to argue the opposite.

<dael> rachelandrew: From talking to people I htink what you see if existing web dev think it's sensible and new people will find it strange. But I can understand the compat issue.

<dael> tantek: Only the oldest behavior...those of us that have been around 15-20 years would say that. Anyone who used positioning or flexbox/grid would see it as weird and different.

<dael> rachelandrew: Yeah. I'm jsut telling you what I'm hearing.

<Rossen_> +1 to tantek - this is exactly why I was fighting for so long and hard on the issue

<dael> tantek: I want to go on record to say I'm a little disappointed because this is an ex where the WG essentially failed by evidence of we're in a compat issue. It's not the first time, but I wanted to call it out. Every time we resolve to do it some way because a number of browsers do something and then websites depend on it and then we hit a threashold where other browsers are compelled to change.

<dael> tantek: I fully sympathize. But this a compat forced change. I don't think this is good for the model.

<dael> astearns: I would agree.

<dael> astearns: Given that the discussion was evenly split and that we are going in the compat direction it seems this will end up with another switch like box sizing where people can opt into the more sane way.

<dael> astearns: We're nearly out oftime. Rossen_ do you want to put your intent in and tag dholbert and Mats?

<dael> Rossen_: I will. Iw anted the minutes into the issue before I do it. If we can resolve sooner rathr then later so we can make the spec changes that owuld be great.

<dael> tantek: I'd like to call this out as a meta issue for the F2F which is when we don't act on some ambig we spec due to compat. I feel this is the latest data point.

<dael> astearns: Can you put it on the F2F agenda?

<dael> tantek: Yep.

<dael> astearns: Thanks everyone for calling in.

[atanassov]

As I stated during the WG discussion, our intention in Edge is to implement the blink and webkit behavior, i.e. resolve padding/margin-top/bottom values against the available inline size (width). Our decision is driven solely due to the compatibility issues experienced by our users.

@dholbert @MatsPalmgren it would be good to hear from gecko on this issue since your implementation will be the only one that has the symmetric behavior.

[Dan503]

No discussion about %h and %w units?

There are quite a lot of people in favour of having units like that.

[atanassov]

@Dan503 this is a separate feature request that isn't specific to flex or grid item vertical padding, hence the lack of discussion. We're not opposed to it, simply have to fork and continue as a separate topic at [css-values] or [css-sizing].

[dpawson]

With full accessibility alternatives I hope.
I thought blink went out with html 1.2?
Dave

On 24 January 2018 at 19:21, Rossen Atanassov [e-mail]
wrote:

As I stated during the WG discussion, our intention in Edge is to
implement the blink and webkit behavior, i.e. resolve
padding/margin-top/bottom values against the available inline size (width).
Our decision is driven solely due to the compatibility issues experienced
by our users.

@dholbert https://github.com/dholbert @MatsPalmgren
https://github.com/matspalmgren it would be good to hear from gecko on
this issue since your implementation will be the only one that has the
symmetric behavior.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-360244244,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASOJ7OdgiB834QXJJlPkiXmy8lHJSLdks5tN4LGgaJpZM4Q28qg
.

--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

[Pauan]

@dpawson "Blink" is the name of the engine which is used by Chrome, Chromium, and Opera. It does not mean the HTML <blink> tag.

What @atanassov meant is that the Edge team is choosing to use Chrome's and Safari's behavior, which means Firefox is the only major browser with a different behavior.

[dpawson]

Thank you for the clarification Pauan.

Dave

On 25 January 2018 at 09:10, Pauan [e-mail] wrote:

@dpawson https://github.com/dpawson "Blink"
https://en.wikipedia.org/wiki/Blink_(web_engine) is the name of the
engine which is used by Chrome, Chromium, and Opera. It does not mean
the HTML tag.

What @atanassov https://github.com/atanassov meant is that the Edge
team is choosing to use Chrome's and Safari's behavior, which means Firefox
is the only major browser with a different behavior.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-360405398,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AASOJ6ijBTv5s4XfmDUGpcJuzXR3GKBoks5tOET7gaJpZM4Q28qg
.

--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.

[dholbert]

@dholbert @MatsPalmgren it would be good to hear from gecko on this issue since your implementation will be the only one that has the symmetric behavior.

We're going to change as well (away from the symmetric behavior, to the inline-axis behavior). (I'm speaking for Mats based on his thoughts at the end of https://bugzilla.mozilla.org/show_bug.cgi?id=958714#c41 , & given that Edge is now changing.)

I've posted patches in https://bugzilla.mozilla.org/show_bug.cgi?id=958714 to make the change in Firefox.

[malix0]

@atanassov @dholbert @MatsPalmgren I don't understand why you chose to go blink and webkit behavior if the almost whole part of us that commented here prefer that axis resolve against their own? So our opinion count nothing?

[astearns]

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

[fantasai]

Agenda+ since we didn't actually resolve yet.

[malix0]

@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

[c-smile]

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.

[css-meeting-bot]

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/w3c/csswg-drafts/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.