内容简介:There are a few serious issues with theThe rem unit is clever, in principle. The reason people use it is because we’re used to counting with the decimal system. If we do something like this —Unfortunately rems are not supported on certain (older) browsers.
Why I dislike the rem unit
There are a few serious issues with the rem
unit. The main reason why I dislike the rem
unit is because pixels don’t belong on the web. Yes, that sounds weird, but let me explain. If you define font-sizes with pixels people who use certain browsers can’t increase their font-size. This conflicts with the idea that the user should be able to override styles with their own preferences. I think that idea is one of the things that makes the web such a wonderful place. That’s why I dislike pixels. But what does that have to do with the rem
?
The rem unit needs a fallback
The rem unit is clever, in principle. The reason people use it is because we’re used to counting with the decimal system. If we do something like this — html { font-size: 62.5%; }
— which sets the font-size to 10px in most browsers, it’s easier to define font-sizes set in Photoshop. If a heading is 22px, we can now easily define it like this — h1 { font-size: 2.2rem; }
. Nice and simple. There are a few problems though. The first one is pixels
.
Unfortunately rems are not supported on certain (older) browsers. For these browsers it needs a fallback. People use pixels as a fallback. The heading now looks like this — h1 { font-size: 22px; font-size: 2.2rem; }
. Older browsers will ignore the second font-size rule, and newer browsers will override the first one. This means that people with older browsers will not be able to resize the font-size to their preferences. This is a problem for everybody who’s older than forty. If you’re not forty already, you will be one day, probably.
So instead of using pixels as a fallback, you should be using em
as a fallback. But if you use em
as a fallback you don’t need rem
, because ems are just as flexible as rems. And if you think about it, they’re actually much more flexible than rems.
The rem unit is not flexible enough.
Flexible units are great for responsive design. A common pattern in responsive sites is that the font-size is smaller on a smaller screen. We can do this by simply reducing the font-size on the html-element. Now all font-sizes will be smaller, but the ratio between the font-sizes remains the same. This works with rems and with ems.
html { font-size: 62.5%; } h1 { font-size: 2.2(r)em; } @media (max-width: 20em) { html { font-size: 56.25%; /* this will result in a smaller h1 */ } }
But what if we decide something else. We might want the text in an aside to be smaller than the body copy on bigger screens. A quite common pattern too. With ems this is very easy.
@media (min-width: 20em) { aside { font-size: 90%; } }
With the rem unit we have a problem though. Since all font-sizes are relative to the root element, the font-size: 90%;
rule is completely ignored. We now have to recalculate
and override every font-declaration in the aside to get the same result. Spaghetti is wonderful as lunch or dinner, but not as code.
The rem unit is buggy
So by using the rem unit we disable the flexible nature of the web for some users, and we write code that’s not as flexible as it should be. If this is still not enough reason to ignore this unit, here’s another reason. It’s buggy . I assume this bug will be fixed soon but right now this unit seems a bit too fragile to use in production.
Yes but inheritance is hard!
Another reason why some people prefer rem
over em
is because inheritance is hard
. I always tell these people they’re doing it wrong. This sounds a bit harsh, so let me explain. What is this inheritance problem? Imagine a website where we want the font-size of paragraphs and list items to be 12 pixels. Here’s one way to do this:
html { font-size: 62.5%; } p, li { font-size: 1.2em; }
The inheritance problem occurs when we nest a p
in a li
. The p
will now be 1.2 × 1.2 = 14.4 pixels. This is too big. To make sure that a p
in a li
is 12 pixels too we now have to write extra, increasingly complex code:
html { font-size: 62.5%; } p, li { font-size: 1.2em; } li p, li li { font-size: 1em; }
This problem gets bigger if we define font-sizes on elements that usually contain more child-elements, like on a div
, or on sectioning elements.
I think this problem is caused by the fact that we want to calculate font-sizes with our decimal system. Once we let go of that burden we see that it’s actually pretty simple and sensible to prevent this inheritance issue. Instead of setting the size of the root element to something that’s easy to do maths with , we set it to the actual size of the body copy . That’s the size of the text you’re reading right now. This way we don’t have to declare font-sizes for every element. This solves the inheritance issue. And it results in much cleaner code. This next block of code does exactly the same as the complex example above
html { font-size: 0.75em; }
So using ems forces you to think about structuring your CSS. This is a good thing. It results in less code, and more robust CSS. And the result is much more flexible.
Round numbers are not flexible enough for proportions
If we look at each heading as a separate element with a single font-size it makes sense to use pixels, or rems. But if you look at each heading as one step in a scale , as one part in a system , suddenly pixels are not flexible enough. But even if our designer just picked some random sizes that look — or feel — good together, turning them into ems makes sense. They too will turn forty, so they too will want to increase the font-size one day. Even a scale of randomly picked sizes that look good together will still feel right when the base font-size is increased.
Superflexible
Now if we decided that the font-size should be larger for bigger screens, a simple html { font-size: 1.1em; }
would do. The ratio hasn’t changed, but all fonts are bigger. And if we decide that all typography within an aside should be smaller, a simple aside { font-size: .618em; }
would do. Same ratio, different font-size. Simple. Do we know how big each heading is, exactly, in pixels? No we don’t. But does that matter? No, not at all. We might not know how big each heading is exactly, we do know that everything is in proportion.
But why?
I wrote this article because this morning I told someone he’s doing it wrong
, which is pretty harsh. I can now apologise and send him a link to this article. Again, he’ll read he’s doing it wrong, bit this time with an explanation. Sometimes 140 characters are not enough to explain something. Next time, instead of just telling someone off on Twitter, I’ll have a link with an explanation to accompany it.
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。
Python编程初学者指南
[美]Michael Dawson / 王金兰 / 人民邮电出版社 / 2014-10-1
Python是一种解释型、面向对象、动态数据类型的高级程序设计语言。Python可以用于很多的领域,从科学计算到游戏开发。 《Python编程初学者指南》尝试以轻松有趣的方式来帮助初学者掌握Python语言和编程技能。《Python编程初学者指南》共12章,每一章都会用一个完整的游戏来演示其中的关键知识点,并通过编写好玩的小软件这种方式来学习编程,引发读者的兴趣,降低学习的难度。每章最后都会......一起来看看 《Python编程初学者指南》 这本书的介绍吧!