New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
atanassov opened this Issue Dec 5, 2017 · 64 comments

Comments

@atanassov
Collaborator

atanassov commented Dec 5, 2017

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

This comment has been minimized.

Collaborator

SelenIT commented Dec 6, 2017

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

This comment has been minimized.

Contributor

fantasai commented Dec 6, 2017

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

@fantasai fantasai changed the title from [css-grid] Choose a single option for resolving padding and maring percent values of grid items to [css-flexbox][css-grid] Choose a single option for resolving padding and maring percent values of grid items Dec 6, 2017

@atanassov atanassov changed the title from [css-flexbox][css-grid] Choose a single option for resolving padding and maring percent values of grid items to [css-flexbox][css-grid] Choose a single option for resolving padding and maring percent values of grid/flex items Dec 6, 2017

@atanassov

This comment has been minimized.

Collaborator

atanassov commented Dec 6, 2017

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

This comment has been minimized.

Contributor

gregwhitworth commented Dec 6, 2017

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

This comment has been minimized.

Contributor

rachelandrew commented Dec 7, 2017

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

This comment has been minimized.

Collaborator

atanassov commented Dec 7, 2017

@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

This comment has been minimized.

Member

mrego commented Dec 7, 2017

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:

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

This comment has been minimized.

Collaborator

atanassov commented Dec 7, 2017

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

This comment has been minimized.

Member

tabatkins commented Dec 7, 2017

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

This comment has been minimized.

Collaborator

atanassov commented Dec 7, 2017

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

This comment has been minimized.

Member

tabatkins commented Dec 7, 2017

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

@atanassov

This comment has been minimized.

Collaborator

atanassov commented Dec 7, 2017

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

@astearns astearns changed the title from [css-flexbox][css-grid] Choose a single option for resolving padding and maring percent values of grid/flex items to [css-flexbox][css-grid] Choose a single option for resolving padding and margin percent values of grid/flex items Dec 12, 2017

@radium-v

This comment has been minimized.

radium-v commented Dec 13, 2017

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

This comment has been minimized.

Contributor

tantek commented Dec 13, 2017

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

This comment has been minimized.

Member

mrego commented Dec 13, 2017

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

This comment has been minimized.

Member

css-meeting-bot commented Dec 13, 2017

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

@astearns astearns removed the Agenda+ label Dec 19, 2017

@rachelandrew

This comment has been minimized.

Contributor

rachelandrew commented Dec 20, 2017

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

This comment has been minimized.

marcvangend commented Dec 20, 2017

(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

This comment has been minimized.

Dan503 commented Dec 20, 2017

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

This comment has been minimized.

dpawson commented Dec 20, 2017

• 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

This comment has been minimized.

samnabi commented Dec 20, 2017

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

@robsonvleite

This comment has been minimized.

robsonvleite commented Jan 15, 2018

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

This comment has been minimized.

Dan503 commented Jan 15, 2018

@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

This comment has been minimized.

Contributor

gregwhitworth commented Jan 17, 2018

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

This comment has been minimized.

Collaborator

SelenIT commented Jan 18, 2018

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

This comment has been minimized.

Member

css-meeting-bot commented Jan 24, 2018

The Working Group just discussed Issue #2085.

The full IRC log of that discussion <dael> Topic: Issue #2085
<astearns> https://github.com//issues/2085
<dael> github: https://github.com//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

This comment has been minimized.

Collaborator

atanassov commented Jan 24, 2018

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

This comment has been minimized.

Dan503 commented Jan 24, 2018

No discussion about %h and %w units?

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

@atanassov

This comment has been minimized.

Collaborator

atanassov commented Jan 24, 2018

@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

This comment has been minimized.

dpawson commented Jan 25, 2018

@Pauan

This comment has been minimized.

Pauan commented Jan 25, 2018

@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

This comment has been minimized.

dpawson commented Jan 25, 2018

@dholbert

This comment has been minimized.

Contributor

dholbert commented Jan 25, 2018

@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

This comment has been minimized.

malix0 commented Jan 26, 2018

@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

This comment has been minimized.

Member

astearns commented Jan 26, 2018

@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

This comment has been minimized.

Contributor

fantasai commented Jan 26, 2018

Agenda+ since we didn't actually resolve yet.

fantasai added a commit that referenced this issue Jan 27, 2018

[css-grid-1][css-flexbox-1] Commit changes to require percent margin/…
…padding resolution against inline-axis, per WG discussion. #2085

@fantasai fantasai removed the Needs Edits label Jan 27, 2018

@malix0

This comment has been minimized.

malix0 commented Jan 28, 2018

@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

This comment has been minimized.

c-smile commented Jan 31, 2018

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

This comment has been minimized.

Member

css-meeting-bot commented Jan 31, 2018

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment