px em和rem實戰經驗

2021-08-21 09:06:44 字數 1743 閱讀 7312

在自適應布局或者移動端網頁開發時,我們經常會用到em和rem兩個長度單位。接下來我們討論一下這兩個單位和px之間的區別,以及他們的使用場景等。

px,畫素(計算機螢幕上的乙個點)。(引自w3school-css單位)

畫素(pixels),相對長度單位,它是相對於顯示器螢幕解析度而言的,它相容性好而且精確,但是這種方法當使用者在縮放瀏覽器或者需要相容不同移動裝置時,我們的頁面布局可能會被打破。

em為了解決上述問題而進化產生,也是相對長度單位,根據使用它的元素的大小決定(有人誤以為是根據父元素,那是因為使用它的元素繼承了父類的屬性,根據w3c標準可知 ,它們是基於當前物件元素的字型大小),它可以自動適應使用者所使用的字型。

em,相對長度單位。相對於當前物件內文字的字型尺寸。

如當前對行內文字的字型尺寸未被人為設定,則相對於瀏覽器的預設字型尺寸。(引自em-css3參考手冊)

假設任意瀏覽器的預設字型大小都是16px。所有未經調整的瀏覽器中都是1em=16px。為了方便換算,我們通常在css中設定body的屬性font-size:62.5%,這就使1em值變為10px,這樣我們就可以把設計稿的px值除以10,然後換上em作為單位來進行px和em的換算,十分簡單,例如16px可以改寫為1.6em。

由於em值不是固定的,1em在不同元素下的值會因為該元素或者該元素父元素的大小不同而不同,因此在我們多次使用時,就會帶來開發的難度。這時候rem(root em)應運而生了。rem是相對於根(html)元素,這就意味著,我們只需要根據自己的需要給根元素確定乙個參考值,然後通過它既可以做到只修改根元素就成比例地調整所有字型大小,又可以避免字型大小逐層復合的連鎖反應。最大的優點是提供一致尺寸,便於計算。

rem,相對長度單位。相對於根元素(即html元素)font-size計算值的倍數。(引自rem-css3參考手冊)

em 和 rem 單位之間的區別是瀏覽器根據誰來轉化成px值,em是基於當前物件內文字的字型尺寸決定,rem是基於html元素的字型大小來決定,而根(html)元素的字型大小如果沒有顯式地設定固定值去覆蓋,那麼它首先來自瀏覽器設定,因此瀏覽器的字型大小設定可以影響每個使用rem單元以及每個通過em單位繼承的值。為了還原設計稿和實現合理的布局所以需要根元素重寫。瀏覽器縮放動態修改根元素大小可以參考以下**段。

var userem = window.userem = object.create("

return

this;

},set: function

(newconfig) }}

this.resize();

return

this;

}}, ,

config: ,

writable: false,

configurable: false,

enumerable: true

}});

addeventlistener("resize", function

() .bind(userem));

userem.set();

script>

同時,也有人認為這種做法在一定程度上剝奪了使用者對瀏覽器字型設定的權利,他們的觀點是rem的好處是給了我們的乙個途經去獲取使用者的偏好來影響**中每一處使用rem的元素大小,無論使用者如何設定自己的瀏覽器,我們的布局都能調整到合適大小。這個就暫不做討論吧,日後有機會再講。

px,em和rem的區別

三者都是相對長度單位 一 px 畫素 畫素是相對於螢幕顯示器解析度而言的。畫素特點 字型大小被定死,不會因為縮放改變二 em em是相對於當前物件的文字尺寸,如果沒有設定,則相對於瀏覽器的預設字型尺寸 特點 1 em的值不是固定的 2 em的可以繼承父級元素的字型大小 注意 所有瀏覽器的預設字型大小...

MongoDB實戰經驗分享

nosql並不是no sql,而是指not only sql。nosql的出現是為了彌補sql資料庫因為事務等機制帶來的對海量資料 高併發請求的處理的效能上的欠缺。nosql不是為了替代sql而出現的,它是一種替補方案,而不是解決方案的首選。絕大多數的nosql產品都是基於大記憶體和高效能隨機讀寫的...

Spark專案實戰經驗

auto.offset.reset 啟動時讀取的偏移量。如果是需要歷史資料那麼設定成earliest 如果不需要消費歷史資料那麼設定成latest 1 如果自動提交偏移量 spark streaming消費到資料之後立馬提交,那麼就會有乙個問題 提交偏移量成功 處理失敗了,那麼spark strea...