王白2016-05-20 20:22:12

同様我也認為基於vw開發佈局比基於rem不知道要高明到哪裡去了。

1。 vw可以輕鬆搞定彈性佈局，流體佈局。而網上那些吹捧rem的文章，所用的響應式適配方案都是基於彈性佈局的。流體佈局？人家說了，流體佈局不好，見 web app變革之rem；

2。 vw邏輯非常清晰，“1vw ＝ 1/100th viewport width”，用viewport width的百分比來設定element width。rem是什麼？“The font size of the root element”，就是說你用它來佈局，就相當於用font size 來設定 width size，中間你要轉一道。

基於以上，我也發出了題主的疑問，為什麼rem這種單位會被用來佈局，而vw這種天生的佈局單位缺鮮有人關注？

所以今天深扒了一下關於這兩個單位在 W3C組織 的郵件組裡的討論，

rem這個單位，我能找到的最早討論是在2002年4月，一封比較各種樣式語言的郵件中：

http：//

lists。w3。org/Archives/P

ublic/www-style/2002Apr/0010。html

，

CSS3 would just need a unit relative to the Root element‘s EM —— say， ’rem‘

之後有理由相信，rem最晚在2003年8月，已經被討論組內人士所公認，並有可能已處在 w3c 工作組成員的筆記之中：

http：//

lists。w3。org/Archives/P

ublic/www-style/2003Aug/0044。html

According to my experience， when some authors look for exotic ways to

define size of some element， it really comes to trying to define size of

that element relative to viewport size。 Nowadays， one has to use

percentages and carefully compute size of every element from root to the

element one wants to set size for。 This is logical addition to ’rem‘

unit （root’s em）。

郵件的作者此時也提出了兩個單位：

vpw： viewport width

vph： viewport height

仔細一看，這不就是現在的vw 和 vh 麼。

其實，再早半年，也已經有人提出了與 vw 和 vh 接近的概念：

http：//

lists。w3。org/Archives/P

ublic/www-style/2003Feb/0110。html

The unit should be relative to the screen （or paper） width。

The unit should be referenced to the preferred screen resolution。

I suggest those units：

sw8 = （screen。width / 800 ） px；

sw12 = （screen。width / 1200 ） px；

sw16 = （screen。width / 1600 ） px；

sw24 = （screen。width / 2400 ） px；

2005年3月，從一封討論CSS運算表示式的郵件裡

http：//

lists。w3。org/Archives/P

ublic/www-style/2005Mar/0057。html

可以確定 vw 已基本被定下，同時被定下的還有vh 和 vm （也就是後來的vmin）：

the working group recently

decided to investigate the implications of allowing simple， linear

expressions as values。

Some common cases can be done without expressions， by means of a few new

units：

gd = the grid unit from CSS3 Text

rem = the font size of the root element

vw = the viewport width （or 1/100th of it）

vh = the viewport height （or 1/100th of it）

vm = min（vw， vh）

當然

There is not even a draft yet， though。

不過話音剛落，到了當年7月26日，working draft 釋出： CSS3 Values and Units

此次是第二次釋出CSS3 Values and Units草案，距離首次釋出已經過去整整4年，顯而易見： ren， vw， vh， vm 是同時進的草案。

之後，2012年3月8日，vm 更改為 vmin。2012年8月28日，釋出Candidate Recommendation（備選標準），增加 vmax。截止到現在，CSS3 Values and Units依然處於備選標準階段，並不是一個正式標準，CSS Values and Units Module Level 3。

但儼然它是一個事實標準，因為瀏覽器廠商從來不是等標準確定後才付之實施，否則就會落後於人。我猜也不乏瀏覽器廠家在事先實現了某個features，繼而正式遞交工作組要求成為標準的，當然大多數瀏覽器廠商本身就是標準制定組成員。所以，雖然同時進入標準，rem 和 vw 的命運還得看瀏覽器廠家們是否積極去實現。

我們來看看 rem 和 vw 在 Moliza 家的待遇：

2009-01-05：有使用者提交bug要求支援rem：472195 – support css3 root em （‘rem’ or ‘re’） units

2009-07-11：有使用者提交bug要求實現vw：503720 – Implement vw/vh/vmin/vmax （viewport sizes） from CSS 3 Values and Units

相差半年

2010-1-21： Firefox3。6釋出，支援rem：Firefox 3。6 for developers

2013-2-19： Firefox 19釋出，支援vw：Firefox 19 for developers

晚了三年

其它各家皆是如此，厚此而薄彼，就導致瞭如下的支援度差異：

rem：

vw：

回到原題，vw被支援的太晚是其並不流行的根本原因，而當時移動端web app/page的開發需求已經十分旺盛，彈性佈局是一種不錯的移動端介面相容展現方式，對於rem機遇就此而來，便成為一個實現彈性佈局效果的極佳方案。

其實看目前狀況，對vw最不利的是Android Browser，據我調查Android Browser 4。4以下的還佔全部Android Browser的 9% 左右， 這個量還是不容忽視的。

好在既然所有最新瀏覽器都已經支援，那麼隨著時間推移，相信未來vw必將會流行。

知乎使用者2018-08-15 15:07:14

謝邀！

vw和rem都是兩個優秀的CSS長度單位。至於其具體的原理這裡就不過多闡述，如果你對其基本原理從未了解過，那麼先建議你花點時間閱讀一下這幾篇文章：

CSS3的REM設定字型大小_rem， 長度單位 教程_w3cplus

CSS的長度單位_CSS， 長度單位 教程_w3cplus

Rem VS Px_CSS， em， rem， 長度單位 教程_w3cplus

七個你可能不瞭解的CSS單位_CSS， 長度單位， vh， vw， vmin， vmax 教程_w3cplus

視窗單位 vs 百分比單位_CSS， 長度單位 教程_w3cplus

何時使用 Em 與 Rem_CSS， 長度單位 教程_w3cplus

REM vs EM_rem， em， 長度單位 教程_w3cplus

媒體查詢——PX，EM or REM？

這幾篇文章把CSS中的單位都做了一定的科普，以及常用的幾個單位在什麼場景使用更為適合也做了一定的探究。

接下來的內容，先當作大家對vw和rem之類的單位原理有了一定的瞭解。所以就回到題主的提問中來！

手淘的flexible。js這個庫承載了一定歷史時期適配史命，這裡所說的適配是指移動端。Flexible。js很強大，解決了移動端多端的適配問題，但也造成了一個誤解。

很多同學以為rem就可以完成移動端的適配

這裡要再次宣告一下，有這種理解的同學是錯誤的。Flexible。js雖然在整個方案中採用了rem做為單位，但他的核心是透過JS對移動裝置做了一些判斷，特別是dpr方面的判斷，然後再給html根元素賦值一個font-size。 達到動態生成font-size的值，從而完成rem 的佈局效果。

那麼為什麼會這麼做，或者這麼做的原因是什麼？簡單點來說有以下幾點：

就當初的時間階段，rem是較為成熟和穩定的一種單位，可以相對於html的font-size來計算

最初的初發點為了解決1px的細節問題；所以對dpr做了一定的判斷，對viewport的值做了縮放處理，從而解決了一些細節上的問題，也達到了一種較好的適配

Flexible的設計其實就為後面轉換vw單位做了伏筆，這是設計者（ @winter ）強大之處，當初設計的時候就有vw的影子存在

拋開flexible，也有團隊透過媒體查詢來改為html的font-size達到類似的效果

這是使用rem來適配的一個歷史過程，就當時而言，瀏覽器對rem的支援度相對於vw而言較為全面。這也是為什麼很多團隊或個人不採用viewport單位的主要原因之一。隨著時間向前的推移以及前端技術的革新，最主要是各大瀏覽器廠商的給力，viewport單位在這兩年再次進入到公眾的視野，開始有人或者有團隊在探討論在實際專案中的使用。

就vw在實際專案中的運用以及落地，我自己在團隊差不多花了將近一年的時間在做相關的事情。首先寫測試Demo，在手淘這樣的環境下跑通測試，另外由於業務的需要，我們還不能放棄一些低端裝置的使用者，所以還需要考慮一些降級的適配方案。當然除了這些之外，還需要考慮開發者，怎麼才能讓開發者不增加任何的成本，就可以在專案中使用vw來做開發。這些滿足之後還是不夠，就我們團隊，或者類似的團隊，還需要考慮怎麼能快速的從以前flexible。js開發的專案過渡或者切換到vw佈局中來，而且這樣的一個過程是無縫的一個過程。

上面說了一下rem和 vw在移動端開發的一個前世與今生。但就開發體驗來說，我覺得沒有差異性，不管是使用rem還是vw來做開發，前端開發者都不會人肉的去計算。大家都會藉助工具，比如說PostCSS工具（px2rem，px2vw之類的），在編譯的過程將px轉換為rem或者vw。就這一點而言，他們的開發體驗都是一樣的。不同的是，rem和vw配置的開發工具不同，開發的腳手架略有不同而言。至於原理，前面已經闡述到了，而且開發的過程不需要去太多關注其原理，而要關注的是細節上的差異化。就目前為止，不管是使用rem還是vw，還是有一些細節要處理的。針對細節而言，不管使用什麼樣的方式，都避免不了。因為沒有哪一種方案可以達到百分百的完美。

有關於rem和vw相關的技術沉澱過程，可以閱讀一下拙作：

使用Flexible實現手淘H5頁面的終端適配_雙11前端技術連載， Layout， mobile 教程_w3cplus

再聊移動端頁面的適配_Layout， 佈局， mobile， CSS 教程_w3cplus

如何在Vue專案中使用vw實現移動端適配_vw， Layout， 佈局， Vue， mobile 教程_w3cplus

分享手淘過年專案中採用到的前端技術_mobile 教程_w3cplus

這裡探討vw在專案中的使用雖然是基於vue的環境下，但事實上，你可以拋開任何的JS框架，因為所涉及到的PostCSS外掛都提供了不同的環境。自己可以根據自己的環境做調整。

以上只是自己的拙見以及自己這一兩年有關於移動端適配的一些探索，如果有不對之處，還請各路大神拍正。

winter2018-08-15 15:57:35

我要解釋一下，彈性佈局這個概念是我最早提出來的，它是當時業界熱議的“響應式佈局”的一個降級版，我也是根據響應式佈局原本文章中“

A flexible foundation

”的概念提出的。

它實際上包含對視網膜屏和不同螢幕尺寸適配，以及文字的適配方案，而flexible。js提供的rem，則是彈性佈局的一種實現方式，它是特定環境下（大概在2013年），vw相容性普遍極差，post css也沒有很好發展的情況下的一種適用於當時環境方案。

今天來看，rem被當做移動端適配的不二之選，這是我始料未及的。即使在當時的環境，彈性佈局也不鼓勵用rem來做所有的長度單位（比如小尺寸文字的font-size）。

現在我們來開發移動端網頁，如果要做到彈性佈局，當然是推薦vw，如果仍然希望達到更高相容性，則應該使用post css把它處理成rem。

實際上，一個好的彈性佈局，應該能夠根據實際設計語義，綜合運用以下css/html特性：

Media Query

正常流排版（display：inline-block、display：block、display：inline）

最大最小寬高（min-width、max-width）

多欄（column-width等）

flexbox（display：flex）

相對單位（% em rem vw wh wmax vmin）

圖片集（srcset、imageset）

SVG

如果你們覺得我當年提出的就是個rem單位，是不是也太看不起我了？

匿名使用者2018-09-01 00:26:31

其實rem這個單位，有點奇怪。

rem本身旳語意，是根元素字型尺寸的倍數。然而以我所見，實際開發中，大家對rem的用法，其實和字型沒啥關係。大家往往是根據各種規則計算一個寬度，然後把根元素的字型尺寸設定成這個寬度。然後使用rem設定各種子元素的寬度。

也就是說，其實大家是在使用rem模擬vw。就像當年大家使用table做佈局一樣，屬於“野路子”的一種（當然，很高明）。

既然是這樣，現在瀏覽器普遍支援vw了，那就可以把rem都換掉了。

方應杭2020-11-17 17:52:59

2020年，不推薦用 rem，直接 vw 不香嗎？