Why I dislike the rem unit (2013)

栏目: IT技术 · 发布时间: 4年前

内容简介: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.


以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Flash第一步

Flash第一步

陈冰 / 清华大学出版社 / 2006-3 / 45.00元

《Flash第1步:ActionScript编程篇》(珍藏版)为《Flash第一步》的ActionScript编程篇,包含后4部分内容。第3部分为ActionScript篇,你将学会像一个软件设计师那样来思考问题,并掌握在Flash中进行程序开发工作所必须具备的重要知识,还将学会运用Flash完整的编程体系来完成从简单到复杂的各种编程任务。另外,在开发一个Flash应用过程中会涉及的各种其他Web......一起来看看 《Flash第一步》 这本书的介绍吧!

JS 压缩/解压工具
JS 压缩/解压工具

在线压缩/解压 JS 代码

CSS 压缩/解压工具
CSS 压缩/解压工具

在线压缩/解压 CSS 代码

Base64 编码/解码
Base64 编码/解码

Base64 编码/解码