【譯】PX、EM仍是REM媒體查詢？

時間 2019-11-11

標籤仍是 rem 媒體查詢欄目 CSS 简体版

原文原文鏈接

原文連接：https://zellwk.com/blog/media-query-units/

你有沒有想過使用媒體查詢的時候到底該用px、em仍是rem做單位呢？我曾經也有一樣的疑問，並且我到如今也還沒弄明白。

當我一年多之前開始創建mappy-breakpoint庫的時候，我用的是rem。當我與Sam Richard聊過以後，我轉用了em，由於我發現兩者並沒有差別。

除了em和rem，另外一個經常使用於媒體查詢的單位是咱們的老朋友px。現在全部瀏覽器都已解決了px縮放問題，可能如今咱們也可使用px媒體查詢了。

這周我終於下定決心完全搞懂這個問題。

在咱們開始前，我假設你已經知道了em和rem是什麼，若是你不清楚，請閱讀這篇文章。html

#基礎實驗
我建立了三個div元素，分別用於測試px、em、和rem。我給每一個div指定了一個背景顏色，易於辨認。git

.pixel { background: red; }
.em { background: green; }
.rem { background: blue; }

接着，由於咱們是在比較媒體查詢單位，因此我分別在三個選擇器上各創建了一個min-width查詢。

我決定在查詢起做用時下降元素的不透明度，這樣我立刻就能看出區別。這是使用px的媒體查詢的CSS代碼：github

@media (min-width: 400px) {
    .pixel {
        opacity: 0.5;
    }
}

下一步是搞清楚怎樣使用em和rem單位。

在第一次實驗中，我想看看在理想環境中這三個單位是否有區別，也就是說，如下任何狀況都沒有發生：
1.<html>的font-size發生了改變
2.用戶放大了頁面
3.用戶修改了瀏覽器字體設置

既然如今全部條件都是理想的，我能夠假設16px == 1em == 1rem，這沒什麼問題，那麼400px就等於25em或者25rem。瀏覽器

@media (min-width: 400px) {
    .pixel {
        opacity: 0.5;
    }
}

// 400 / 16 = 25
@media (min-width: 25em) {
    .em {
        opacity: 0.5;
    }
}

// 400 / 16 = 25
@media (min-width: 25rem) {
    .rem {
        opacity: 0.5;
    }
}

若是三個媒體查詢的行爲是一致的，它們應該都會恰好在400px觸發。

事實也是如此（在我所測試過的瀏覽器上）。

基礎實驗sass

由於三個媒體查詢全都在同一個斷點觸發，在此階段px、em和rem媒體查詢並沒有區別。

創建了基礎實驗以後，下一步就是測試在條件非徹底理想時，即以上所提條件之一可能會發生，再一次提醒，這些狀況分別是：
1.<html>的font-size發生了改變
2.用戶放大了頁面
3.用戶修改了瀏覽器字體設置

咱們來一個一個地測試吧。app

#1.<html>的font-size發生了改變

第一種狀況很是廣泛。事實上，幾乎全部網頁都在他們的CSS文件中使用這種方法來改寫默認的font-size。

佈局

html { font-size: 200%; }

在個人測試中，我使用了200%的font-size，也就是說，我設置了1em和1rem都等於32px。若是em和rem受font-size改變的影響，它們應該只在800px的時候觸發。

結果是，在Chrome、Firefox和IE11上三個媒體查詢都是在400px觸發。

Chrome, Firefox, IE11上的結果

這是正確的行爲，em和rem不該該被HTML中font-size的改變所影響，由於它們是基於瀏覽器內部的font-size的。

不幸的是，在Safari上咱們觀察不到這種正確的行爲，它會在800px觸發rem媒體查詢:(

Safari上的結果

由於這種行爲只在Safari中發生，我很好奇手機端Safari是否也受影響，事實是，它們也受了影響。

因此，第一種狀況告訴咱們不該該在媒體查詢中使用rem，不過，咱們仍是在接下來的實驗中保留rem，看看會不會發生其餘事情。測試

#2.用戶放大了頁面

第二種狀況也很廣泛。若是你的網頁上的字體不夠大，用戶可能會使用瀏覽器的縮放功能來放大字體。

小知識：最初是由於老瀏覽器不能隨用戶縮放頁面更新px值，纔有了em。在這種狀況下，測試用戶縮放頁面狀況下使用不一樣單位的媒體查詢行爲的不一樣，能夠幫助咱們解答如今是否可使用px媒體查詢這個問題。

用戶放大頁面

此次實驗的結果是Chrome、Firefox和IE的行爲是一致的，使用px做單位的查詢與em和rem同樣在相同時間觸發。

Chrome, Firefox, IE11上的結果

但猜猜怎麼着......Safari並無這樣作:(

Safari上的結果

不幸的是，這表示使用px做單位的媒體查詢也是不可能的事了，由於Safari不能恰當地支持它們（除非你打算放棄Safari？）。

好吧，讓咱們繼續最後一個實驗，看看還有沒有意料以外的事情發生。字體

#3.用戶修改了瀏覽器字體設置
不少開發者認爲用戶不會修改他們瀏覽器的字體大小，由於這項設置藏得非非很是深。

好吧，若是全部用戶都這樣作，那真的是太棒了，這樣咱們就不用作這個實驗了！:)

不幸的是，沒有數據證實用戶不會修改他們瀏覽器的字體大小，因此爲咱們的網站增長靈活性依然是咱們做爲開發者的責任。

在這次實驗中我測試的4個瀏覽器上，我增大了默認字體大小，如下是設置方式（若是你想跟着修改的話）：
1.Chrome: 設置 -> 外觀 -> 字號
2.Firefox: 選項 -> 語言和外觀 -> 字體和顏色
3.Internet Explorer: 菜單欄 -> 查看 -> 文字大小

有一個瀏覽器我沒法找到如何設置字體大小，那就是Safari，因此我改用了一個代理方法。我改變了瀏覽器設置，使得最小字體大小大於16px，方法是preferences -> advanced -> acessibility。

此次測試是惟一一個在全部瀏覽器上表現一致的。網站

在第三種狀況下全部瀏覽器的結果

如你所見，使用px的查詢比使用em或rem的查詢都要早觸發。

這並非bug，這種實現是正確的，由於px是絕對單位，無論用戶怎樣設置他們的默認字體大小，斷點都應該保持爲400px。

而em和rem是基於瀏覽器的字體大小的，所以，當用戶修改了默認字體大小設置時，它們的媒體查詢也應該更新。

因此......pixel愛好者，很抱歉戳破了你的幻想泡泡，可是基於pixel的媒體查詢是毫不可能的。

（若是你不太理解最後一個實驗，這裏有更詳細的解釋。）

若是你寫了一個網站，網站的斷點是600px，這個600px斷點對16px（默認）的字體大小來講是很好的。

在這裏咱們把小於600px的視口叫作「小視口」，大於600px的叫作「中視口」。

咱們再進一步假設你只在600px改變佈局，小於600px時使用一欄佈局，大於600px時使用兩欄佈局。

如今把你的瀏覽器字體大小設置爲20px，而後在650px視口打開你的網站。

若是你的媒體查詢用的是em或rem，你的用戶會在650px視口看到一欄佈局，這個行爲在以上提到的前兩種狀況中也是一致的。

若是你的媒體查詢用的是px，你的用戶會在650px視口看到兩欄佈局，這個行爲在前兩種狀況中是不一致的（並且這種設計與窗口也不相符）。

#總結

從以上測試能夠看出，在4個瀏覽器中保持表現一致的惟一單位是em。除了在Safari上找到的bug外，em和rem並沒有任何區別。

這三個實驗中，px媒體查詢在其中兩個都表現很好（除了在Safari上）。不幸的是，在第三個實驗中，px媒體查詢的斷點一直是400px，若是你打算支持會修改瀏覽器字體大小設置的用戶，你就不可能使用px媒體查詢。

所以，我從這些實驗中得出的結論就是：使用em媒體查詢。

若是你用的庫沒有用em媒體查詢，把這篇文章給那個庫的開發者看看，好讓他們知道他們寫的代碼可能會有什麼後果。或者改用一個使用em媒體查詢的庫，如Mappy-breakpoints、Breakpoint-sass或sass-mq。

相關標籤/搜索

每日一句

每一个你不满意的现在，都有一个你没有努力的曾经。