css和sass
At Edenspiekermann, we rely heavily on code reviews to make sure the work we commit is good enough™. One thing I regularly come across is the fuzziness around numbers, especially the ones that have a decimal point. Hence, here is a short article to shed light on this matter.
在Edenspiekermann ，我们严重依赖代码审查来确保我们所做的工作足够好。 我经常碰到的一件事是数字的模糊性，尤其是那些有小数点的数字。 因此，这里有一篇简短的文章可以阐明这一问题。
最初设定 (Initial Setup)
To make the whole explanation clearer before even getting started, we are going to work on a small piece of code that happens to be very relevant to our case.
为了在开始之前就使整个解释更清楚，我们将编写一小段与我们的案例非常相关的代码。
.list-item {
float: left;
width: 33%;
}有什么问题？ (What’s the Problem?)
Maybe you are wondering what the problem is with this code snippet. In appearance, not much. It is a three-column grid layout. Quite the usual you could say.
也许您想知道此代码段是什么问题。 外观上不多。 它是一个三列网格布局。 您可以说的很平常。
Although, 33% + 33% + 33% equals 99%, not 100%. While it might not make any difference in most cases, when working on straight alignments — 1% can make a big difference. 1% of a 1400px large container is 14px. That’s a pretty big distance.
虽然33％+ 33％+ 33％等于99％，而不是100％。 尽管在大多数情况下可能没有什么区别，但是在进行直线对齐时-1％可能会产生很大的不同。 1400px大容器的1％为14px 。 那是一个很大的距离。
Why don’t we just move the decimal dot (or rather add it) to make it more precise? We could probably reduce the gap to 1.4px, or even 0.14px which is not worth bothering anymore I suppose! Let’s start with that then.
我们为什么不只是移动小数点(或添加小数点)以使其更精确？ 我们可能会将间隙减小到1.4px ，甚至是0.14px ，我想这不再值得打扰了！ 让我们从那开始。
.list-item {
float: left;
width: 33.33%;
}That works better but it still ain’t perfect. This problem has been extensively discussed in this absolutely great article from John Albin Wilkins entitled “Responsive Design’s Dirty Little Secret”. If you haven’t read it, read it.
效果更好，但仍不完美。 约翰·阿尔宾·威尔金斯(John Albin Wilkins)的这篇绝对伟大的文章名为“响应式设计的肮脏小秘密”， 对此问题进行了广泛讨论。 如果您还没有阅读，请阅读。
浏览器无法处理吗？ (Can’t the Browser Handle This?)
At this point, you might be wondering why the browser cannot just make it work™. The thing is, the CSS specifications don’t specify (of the irony) anything to browser vendors about what to do in case of floating precision with percentage numbers. And when the CSS specifications omit a detail, you can be sure that every browser will do it its own way.
在这一点上，您可能想知道为什么浏览器无法使其正常运行。 关键是，CSS规范没有对浏览器供应商指定任何(具有讽刺意味的)关于在使用百分比数字进行浮动精度的情况下该怎么做的事情。 而且，当CSS规范省略细节时，您可以确保每个浏览器都会以自己的方式进行操作。
Take this example from the aforementioned article:
以上述文章为例：
[…] with a 6 column grid, each column is 100% ÷ 6 = 16.666667% wide. On a 1000 pixel wide viewport (which I’ve conveniently picked to make our math easier), that calculates to 166.66667 pixels per column. Since the spec gives no guidelines, browser vendors are free to make their own rules. If a browser were to round to the nearest pixel, in our example, we’d arrive at 167 pixels. But since 167 x 6 = 1002 pixels, we’d no longer have room for all 6 columns in our viewport. Alternatively, if a browser rounded down to 166 pixels per column, we’d be 4 pixels short of perfectly fitting all columns into our viewport. — John Albin Wilkins
[…]具有6列网格，每列的宽度为100％÷6 = 16.666667％。 在一个1000像素宽的视口(为了方便我们的数学运算，我很方便地选择了它)，每列的计算结果为166.66667像素。 由于该规范未提供指导，因此浏览器供应商可以自由制定自己的规则。 如果将浏览器四舍五入到最接近的像素，在我们的示例中，我们将得出167个像素。 但是，由于167 x 6 = 1002像素，我们在视口中不再为所有6列留出空间。 另外，如果浏览器将每列取整到166像素，那么我们会将所有列完美地适合我们的视口还需要4像素。 — 约翰·阿尔宾·威尔金斯
That’s exactly what happens. Old versions of Internet Explorer (mainly 6 and 7) round to the closest whole number, resulting in layout breakage. WebKit browsers round down, which prevents any catastrophic layout result but leaves us with extra space. Opera (at least in its old rendering engine) was doing some weird stuff that I won’t even bother to explain. But again, there is no rule about this behaviour in the spec, so who’s to blame? Not the browsers resorting in subpixel rendering, that’s for sure, because in the end that’s what gives the best results.
就是这样。 Internet Explorer的旧版本(主要是6和7)四舍五入到最接近的整数，从而导致布局损坏。 WebKit浏览器向下取整，这可以防止任何灾难性的布局结果，但为我们留出了更多空间。 Opera(至少在其旧的渲染引擎中)正在做一些奇怪的事情，我什至不愿解释。 但是同样，规范中没有关于这种行为的规则，那么应该归咎于谁呢？ 可以肯定的是，并不是浏览器采用亚像素渲染 ，因为最终可以提供最佳效果。
Anyway, it’s pretty much a mess, and we’ll come back to this in the conclusion of this article.
无论如何，这几乎是一团糟，我们将在本文的总结中再次讨论这一点。
那Sass呢？ (What About Sass?)
Sass supports mathematical operations. It is not new and is actually one of the first few things Sass was used for (to build math-based grid systems). What we could do is tell Sass that we want to divide our container’s width in 3 equal parts.
Sass支持数学运算。 它不是新事物，实际上是Sass用来(建立基于数学的网格系统)的头几件事。 我们可以做的就是告诉Sass，我们想将容器的宽度分成3个相等的部分。
.list-item {
float: left;
width: (100% / 3);
}We could also use the percentage(..) function for the same result:
我们也可以将percentage(..)函数用于相同的结果：
.list-item {
float: left;
width: percentage(1 / 3);
}Sass, in both Ruby and LibSass, has a precision option of 5. That’s actually a problem because it is pretty low; 10 would be better but that’s not the default (although configurable, but not in an easy way).
Ruby和LibSass中的Sass的精度选项均为5。 这实际上是一个问题，因为它的价格很低。 10会更好，但这不是默认值(尽管可以配置，但不是很容易)。
This code will yield the following CSS:
此代码将产生以下CSS：
.list-item {
float: left;
width: 33.33333%;
}That does not solve our browser problem, but that does make authoring stylesheets easier. Not only do we not have to handle the calculation and the precision ourselves, but we also make the code more convenient to read and update by actually displaying the calculation.
那不能解决我们的浏览器问题，但是确实可以使样式表的编写更加容易。 我们不仅不必自己处理计算和精度，而且还通过实际显示计算使代码更易于阅读和更新。
I’d say that is a good thing.
我会说这是一件好事。
两全其美的 (The Best of Both Worlds)
So far, we have learnt that it is good to let Sass handle the computation for us rather than hard coding the value. Now, the best approach would be to let the browser handle this in the best way it can. For this, there is the calc(..) CSS function.
到目前为止，我们了解到让Sass为我们处理计算而不是对值进行硬编码是一件好事。 现在，最好的方法是让浏览器以其可能的最佳方式进行处理。 为此，有calc(..) CSS函数。
.list-item {
float: left;
width: calc(100% / 3);
}This code snippet does not get compiled into anything. It hits the browser as authored. Then, it is up to the browser to make the best of it. I’ll be entirely honest with you and tell you I’m not sure whether browsers handle calc(..) values the same as regular ones. I suppose they perform the calculation, then do their rounding. Some browsers appear to bring subpixel rendering into the equation. If you have any insight on this, please share in the comments.
此代码段不会编译成任何东西。 它会按原样命中浏览器。 然后，由浏览器来充分利用它。 我会完全诚实的告诉您，我不确定浏览器是否处理calc(..)值与常规值相同。 我想他们执行计算，然后进行四舍五入。 一些浏览器似乎将亚像素渲染带入了方程式。 如果您对此有任何见解，请分享评论。
For browsers that do not support the calc(..) expression, mostly Internet Explorer 8 and Opera Mini, we can put a static value expressed as a Sass operation right before it. This way, we get the best of both worlds.
对于不支持calc(..)表达式 (主要是Internet Explorer 8和Opera Mini calc(..)浏览器，我们可以在其前面放置一个表示为Sass操作的静态值。 这样，我们可以兼得两全。
.list-item {
float: left;
width: (100% / 3);
width: calc(100% / 3);
}结论 (Conclusion)
Let’s have a little recap. For starters, percentage based layouts are hard to handle because of browser inconsistencies and a lack of specification in the matter of floating precision.
让我们来回顾一下。 对于初学者来说，由于浏览器不一致以及浮动精度方面缺乏规范，基于百分比的布局很难处理。
Then, hard-coding values resulting from a somehow complex calculation is usually not a good idea. We can let Sass compute an approximation (to 5 digits after the floating point).
然后，以某种方式进行复杂计算得出的硬编码值通常不是一个好主意。 我们可以让Sass计算一个近似值(到浮点数后5位)。
Even better, we can let the browser compute an approximation. In a perfect world, when the browser is in charge of both the math and the rendering, it should be able to make the best out of it. To head in that direction, we rely on the calc(..) function.
更好的是，我们可以让浏览器计算一个近似值。 在一个完美的世界中，当浏览器同时负责数学和渲染时，它应该能够充分利用数学。 要朝这个方向前进，我们依靠calc(..)函数。
That’s pretty much where it is at right now. Nothing new, but I thought a quick recap would help!
现在几乎就是这样。 没什么新鲜的，但是我认为快速回顾会有所帮助！
翻译自: https://www.sitepoint.com/a-tale-of-css-and-sass-precision/
css和sass
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
