ios 网格格子边距_我们应该如何解决网格和弹性项目的边距百分比和填充？-优快云博客

ios 网格格子边距

The CSS Working Group would like your opinion. There is a longstanding issue in both the CSS Grid Layout and Flexbox specifications.

CSS工作组希望您的意见。 CSS网格布局和Flexbox规范都存在一个长期存在的问题。

From the CSS Grid specification:

根据CSS Grid规范：

Percentage margins and paddings on grid items can be resolved against either:

网格项的边距和填充百分比可以根据以下任一方法进行解析：

their own axis (left/right percentages resolve against width, top/bottom resolve against height), or,
the inline axis (left/right/top/bottom percentages all resolve against width)

自己的轴（左/右百分比针对宽度，顶部/底部百分比针对高度），或者，
内联轴（左/右/上/下百分比均针对宽度进行解析）

A User Agent must choose one of these two behaviors.

用户代理必须选择以下两种行为之一。

Note: This variance sucks, but it accurately captures the current state of the world (no consensus among implementations, and no consensus within the CSSWG). It is the CSSWG’s intention that browsers will converge on one of the behaviors, at which time the spec will be amended to require that.

注意：这种差异很糟糕，但是可以准确地捕获当前的状态（实现之间没有共识，CSSWG内部也没有共识）。 CSSWG的意图是使浏览器集中在一种行为上，这时将对规范进行修改以要求这样做。

Authors should avoid using percentages in paddings or margins on grid items entirely, as they will get different behavior in different browsers.

作者应避免在网格项目的填充或边距中完全使用百分比，因为它们在不同的浏览器中会出现不同的行为。

The flexbox specification has the same wording.

flexbox规范具有相同的措辞。

这里有什么问题？ (What is the problem here?)

A percentage has to be resolved against something. If you give a grid item a margin-right of 10%, you would probably expect that 10% to be calculated as 10% of the width of the grid area. What happens however if you give the item a margin-bottom of 50%? Do you expect it to resolve to 50% of the total height of the grid area or do you expect it to calculate 50% from the width? The spec allows for both, and browser implementations are split.

必须针对某个问题解决一个百分比。如果为网格项目提供10％的右边距，则可能希望将10％计算为网格区域宽度的10％。但是，如果将商品的底边距设为50％，会发生什么情况？您希望它解析为网格区域总高度的50％，还是希望它从宽度计算出50％？规范同时允许两者，并且浏览器实现是分开的。

You can see the problem in this very simple CodePen. We have three column tracks which are each 120 pixels in width. The margin-right applied to each track resolves to 12 pixels, 10% of 120. In Chrome and Safari the margin-bottom resolves to 60 pixels. 50% of the width of 120 pixels is 60 pixels.

您可以在这个非常简单的CodePen中看到问题。我们有三个列轨道，每个列轨道的宽度均为120像素。应用于每个轨道的页边距右分辨率为12像素，占120％的像素。在Chrome和Safari中，页底距分辨率为60像素。 120像素的宽度的50％是60像素。

In Firefox and Edge the margin-bottom uses the height of the grid area and so in this case resolves to 150 pixels as I have put a height on the grid and items are stretching. If you remove the height on the grid container you will see how Firefox now completely collapses the container as there is now no height to resolve against. Chrome will keep the container at 60 pixels - that being the margin.

在Firefox和Edge中，底边使用网格区域的高度，因此在这种情况下，由于我在网格上放置了高度并且项目正在拉伸，因此解析为150像素。如果删除网格容器上的高度，您将看到Firefox现在如何完全折叠容器，因为现在没有要解决的高度。 Chrome会将容器的像素保持在60像素（即余量）。

See the Pen Margin and padding interop issue: Grid by rachelandrew (@rachelandrew) on CodePen.

请参阅Pen Margin和padding互操作问题： rachelandrew（ @rachelandrew ）在CodePen上的网格。

We see the same variance in Flexbox, however in Flexbox we resolve against the flex container as the containing block. However you can see in the below example how Chrome uses 10% of 500 pixels for the margin-right, and 50% of 500 pixels for margin-bottom. Firefox uses 10% of 500 pixels for margin-right and 50% of 300 pixels for margin-bottom.

我们在Flexbox中看到了相同的差异，但是在Flexbox中，我们将flex容器解析为包含块。但是，您可以在下面的示例中看到Chrome如何将500％像素的10％用于右边距，而500％像素的50％用于底部距。 Firefox将500像素的10％用于右边距，将300像素的50％用于底部距。

See the Pen Margin and Padding interop issue: flexbox by rachelandrew (@rachelandrew) on CodePen.

请参阅笔边距和填充互操作问题： rachelandrew（ @rachelandrew ）在CodePen上创建的flexbox 。

The fact that percentages resolve from the width is essentially a throwback to the old days of layout on the web where we didn’t have great control over the height of things. The width was the measurement we could control and so became the dominant measurement.

百分比从宽度上解析的事实实质上是对网络布局的旧时代的回溯，在网络上我们无法很好地控制事物的高度。宽度是我们可以控制的度量，因此成为主要度量。

“纵横比骇客” (The ‘aspect ratio hack’)

One reason to follow the Chrome behaviour here is that it allows the percentage-based padding “aspect ratio hack” to work on flex and grid items. There is an excellent write-up of the interoperability issue on Bram.us - Vertical margins/paddings and Flexbox, a quirky combination, the issue is also detailed on Flexbugs and Gridbugs.

遵循Chrome行为的原因之一是，它允许基于百分比的填充“长宽比hack”适用于flex和grid项。关于Bram.us的互操作性问题，有很好的文章- 垂直边距/填充和Flexbox，这是一个古怪的组合，该问题在Flexbugs和Gridbugs中也有详细介绍。

However, perhaps a better solution is to properly solve the aspect ratio issue, while also deciding on one solution for margins and padding in general.

但是，也许更好的解决方案是正确解决长宽比问题，同时通常还决定一种解决方案来解决边距和填充问题。

我们希望您的反馈！ (We want your feedback!)

The CSS Working Group would love to know your thoughts on this issue. As you can see above this is not an issue when using horizontal percentage margins and padding, this continues to work as it always has done. The issue is with vertical margins and padding. Would you prefer the Chrome behaviour, of the Firefox one? Other than the aspect ratio padding hack, are you using vertical margins and padding for any other reason?

CSS工作组很想知道您对这个问题的想法。正如您在上面看到的那样，当使用水平百分比边距和填充时，这不是问题，它像往常一样继续起作用。问题在于垂直边距和填充。您会喜欢Firefox的Chrome行为吗？除了长宽比填充技巧外，您是否出于其他原因使用垂直边距和填充？

You can comment directly on the GitHub issue with thoughts and use cases. It would be great to get this particular interoperability problem solved.

您可以使用思想和用例直接在GitHub问题上发表评论。解决这个特定的互操作性问题将是很棒的。

Also posted to the CSS WG Blog.

还发布到CSS WG Blog 。