W3C home > Mailing lists > Public > public-css-archive@w3.org > December 2017

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

From: marcvangend via GitHub <sysbot+gh@w3.org>
Date: Wed, 20 Dec 2017 11:24:46 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-353038114-1513769085-sysbot+gh@w3.org>
(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](https://codepen.io/rachelandrew/pen/xpVLza) 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`?

-- 
GitHub Notification of comment by marcvangend
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2085#issuecomment-353038114 using your GitHub account
Received on Wednesday, 20 December 2017 11:24:49 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:21 UTC