vw相比rem，在實際開發中究竟有多大區別？

01-09

大概一年前用rem做了一些移動端的開發，比起原來的媒體查詢加px響應式的響應式，當然是更適合移動端，但是計算本身有些麻煩，感覺並沒有像很多人推薦的那麼戳中痛點。
後來發現了vw，感覺其實能更好的滿足要求，完全不需要關注媒體查詢了，不過在微信上偶爾還會有兼容性問題，但是基本能夠滿足日常需求。可是不知道為什麼似乎周圍根本沒人用，是因為本身還存在兼容性問題？還是因為其他性能考慮？糾結了好幾個月，一直沒找到答案，求指點

同様我也認為基於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/Public/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/Public/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/Public/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/Public/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必將會流行。

新版x5更新後，安卓版微信的vw vh vmin vmax 已經沒有兼容性問題了。

如果不考慮系統自帶瀏覽器的兼容性問題，用起來當然是極好的。

最麻煩的就是兼容問題啊 x5

一個用長寬來表示字體大小，一個用字體大小來表示長寬。沒差啊。就看兼容性了。

現在在項目中已經開始使用了

vw/vh 最喜歡的css單位

rem 在封裝組件時會和html字體耦合

使用vm/vh就完全的解耦了

calc也基本可以使用了

vw換算也很麻煩吧？

1年半前曾用vw和vh配合著media query生寫了一個響應式的登陸頁面，體驗就是大體效果很好，但是如果還原精度很高的設計圖，可能還是差一些。舉例，比如二吊子設計師要求寬高比為1：1.6，你就很難給他們弄出來。不如px來的直接，雖然在各個解析度的屏幕下，看起來大小不一致，但是總體來說寬高比例上沒有失真。

使用vw對於不支持這個特性的瀏覽器並沒有完善的fallback方案。

vw calc可能會有問題至於為什麼少有人用因為大牛meitui

使用lib-flexible，屏幕寬度就是10rem，用起來跟vm是一個意思的。

要說有啥區別的話，就是rem兼容性完爆vm。

vw相對寬度，rem相對html，好似沒對比喔。vw兼容性差