很久沒有寫關於排版的文章，恰巧最近同事間討論到關於畫面資料流（ Content Flow ）的問題，所以把這個老話題在拿出來嘴一下，順便填充一下部落格的內容。
但，太久沒有寫文章實在是過於生疏。
WD-40
這個比較跟本文無關，只是為了 WD 的埂而已。
RWD
全名叫做 Responsive web design，從被提出來，距今大概已經 10 年過去了。但是對於這件事情的話題性還是不少，諸多網頁（網站）設計都會提到這個東西。然後就像是戰南北一樣，這件事情也時常拿來跟 AWD 做比較。關於這些事情我們後面再來聊。
關於響應式的設計，我們最主要的目的在於：
- 針對不同裝置，只需要維護一份資料就可以了。
- 在不同裝置，有比較相近的畫面操作邏輯與畫面編排。
- 在不同裝置（不同螢幕解析度）下，保有一定的使用者友善介面。
- 對於 SEO 來說，不同裝置保有同一個版本的畫面，可保持對 SEO 策略的一致性。
- 可以同時面對不同裝置，而不需要網站重新導向。
然後針對上述 5 點，我們繼續思考關於反面的事情：
- 維護的那「一份」資料，多數情況下會很大一包。
- 為了追求操作邏輯統一性，必須額外付出製作成本。
- 這個世界上有千千萬萬種解析度的手機、平板與電腦螢幕，最近有 8K。
- Google 一邊告訴你說手機與桌機要有相同結構，一邊告訴你說我有 AMP Page 好蚌蚌。
- 因為不同裝置都在同一份的關係，結果每個人手上都好大一包。
好，講到這邊先別急著放棄，後面會讓人放棄的事情還多著呢（欸。
AWD
全名叫做 Adaptive web design，這裡不是四輪傳動全時四驅的那個。這個字很常拿來跟 RWD 擺在一起。翻成中文呢，有的人叫做自適式，有的人叫自適應，我是覺得怎麼叫都很饒口，所以還是說英文就好了，中文要表達起來真的有點容易搞混。至於說為何會有 AWD 的出現，主要是因為 Mobile first 這件事情，所以衍生出了行動裝置優先的網頁設計。
說個豆知識，AWD 的年紀比 RWD 要老的多。大概是行動裝置剛剛起步的時候（大概是黑梅機時代），為了給這些小型裝置能有簡易的網頁可以瀏覽，所以經由伺服器端來產出一個給行動裝置瀏覽的畫面，就是現在俗稱的「手機版」跟「桌機版」的差別。但，後來不被廣泛使用的原因，也是因為整體設計模式並不如 RWD 那樣來的流暢，所以這兩者的界線就變得很曖昧。
自適應式的設計，最主要的方向在於：
- 針對不同裝置，由伺服器端判斷
user-agent來給出不同的資料。 - 在不同的裝置尺寸下，設計師可以設計專用的操作邏輯與畫面。
- 對於每種裝置都能做到最佳化（設計、介面、資料流）。
- Mobile first 所以強化（應用）在行動裝置支援的功能（ feature ）。
- 不同裝置不同檔案，可以完全分離而不受影響。
然後針對上述 5 點，要打臉的地方也是啪啪啪：
- 打開 Sketch 起手式就會有三個 Page，分別叫 手機版 、 平板 跟 電腦版。
- 通常叫平板的，都是去依親手機版，或者投靠電腦版，然後變成 奇怪的形狀。
- 有幾個裝置就要維護幾種 Content flow, UI/UX 跟資料流邏輯。
- 有一種行動裝置瀏覽器，叫做 InAppBrowser 或俗稱 IAB。
- 你有多少版本，就要對應有多少 SEO 的策略（別忘了你有好多網站）。
簡單的舉幾個點，讓大家知道一下，其實各有各的難處。RWD 與 AWD 對我來說，從來就不是什麼二選一的事情。如果你真的需要針對特別的裝置來製作，那麼選 AWD 就沒毛病，如果不是，那麼選 AWD 還是 RWD 根本就不那麼重要。最主要的，還是依據內容來決定，擷一段 Wiki 的總結，
There is certainly more than one way to skin the cat of dynamic web development.
如果真的要區分，那麼我會這麼說：
- RWD 就是 one-size-fits-to-all
- AWD 就是 one-size-stretches-to-all
至於是 誰 去 fits 或 stretches 誰 其實就不是那麼重要。
響應式什麼？適應什麼？
這邊比較工程一點，不過我想先撇除 viewport 的部分，單純的以「螢幕解析度」這件事情來講，應該會比較容易理解。所謂的 響應 或者有的地方會說 自適應 的網頁設計，單就字面上來看，就是在各種螢幕解析度下，都能保有畫面的操作邏輯、頁面結構與相似的使用者體驗（指 RWD 來說）。
所以，在這個所謂響應的著墨點，在於：
- 流體佈局（ Fluid Layout ）。
- 有限制的元件尺寸（文字、區塊、圖片）。
- 內容資料流的斷點設計（ Breakpoints ）。
- 結構化的區塊（避免內容破碎）。
要列出來的東西很多，主要就以以上四個方向來說明，理論上應該比較容易理解。
流體佈局的部分，這件事情在當年 Bootstrap 推出之後，貌似大家對於 排版 這件事情好像就沒有那麼排斥（真的嗎？），然後對於眾多工程師來說，也提供了不少的救贖。雖然在當初那個年代，大家都還是 float 來 float 去的，但是大抵上還是解決了不少問題。
所以，當我們查看當年 Bootstrap 的 col-sm-4 的設定時，你可以看到 CSS 當中是這樣寫的 width: 33.33%，這樣的設定基本上就符合流體佈局的設計。之所以使用百分比，實際上是為了要在 大容器 當中，保有對於寬度的彈性設置。基於 12 個欄位的預設值，當我們寫了 3 個 col-sm-4 時，就相當於填滿了整個容器。
而，當容器的尺寸發生了變化，依據每一種 Media Query 的設定（設計），無論我們的容器在什麼階段被換成了哪一種尺寸，在容器當中的區塊依舊會保持 3 個子區塊的排列方式。亦即，你的 大容器 即便永遠都是 100% 的寬度，那麼在任何尺寸的可顯示裝置上，都會維持 3 個子區塊的排列。
接著，我們的子區塊 width: 33.33% 相較於容器來說，並不能稱得上是 有限制的 元件尺寸，舉例來說，我們有一張圖片，他的最佳尺寸是 300px，那麼，我們在 1080px 寬的螢幕下，你的子區塊會得到 360px 的寬度，你的圖片若使用了 100% 寬，那麼他就會被拉伸到 360px 的寬度。
圖片被拉伸本身並不是問題，問題在於 圖片 這樣的元素，應該要擁有一個 最大靜態尺寸，以避免在不同的流體佈局當中，尺寸的改變而造成內容資料流的變化。所以說，我們可以將圖片設計為 max-width: 300px; 用以避免他超過 300px 而發生不可預期的事情。換句話說，我們可以透過這種方式，將變化的變因侷限在 300px 以下的變化。
當然，上述的 有限制 的元件尺寸，並非一定是圖片，內容資料的區塊、影片、表單欄位甚至按鈕，都可以依照這樣的方式來實作。為什麼會需要這樣的元件？當我們在流體佈局當中使用相對單位時，你會因為寬度的改變，進而影響到元件高度跟著改變，諸如等比的圖片、影片，文字內容區塊等。所以，當這些區塊在製作或是設計時，必須考慮到因為 寬度 的變化，對於資料流所造成的影響。
資料流的影響，就是在內容為王（ Content is king ）的結構當中，需要納入考量的部分。舉個簡單的例子，在新聞網站，或是報紙（這年頭應該很少人看報紙了），多數以 欄 為單位來切分內容，重要的標題也有機會採用跨欄的方式來達到醒目的效果。另外一個例子，在 Microsoft Word 編輯文件中，有個功能叫做「文繞圖」，在既定的格線系統當中，我們確實可以很巧妙的安排這些內容，讓他變得易於呈現，且容易閱讀。
但，在面對這麼多裝置的網路環境當中，並沒有一個很固定的格線系統，即便有，在 使用者產生 的內容裡面，你很難侷限（或強迫）使用者能按照規則來走。以「文繞圖」為例子，當文字的長度恰巧高於圖片高度的一個行高，那麼，那一段文字就會被折向圖片的 底部，雖然我們確實可以稱之為「文繞圖」，不過，對於閱讀者而言，這樣個 斷點 就不算是友善（或容易閱讀）的結果。
那麼，應該考慮什麼方式來製作需要的 斷點 呢？
- 將你的圖片比例縮小。
- 結構化你的文字區塊。
將你的圖片縮小是一種方式，但這樣所產生的效益並不高。由於你無法確切掌控文字內容的長度，所以這邊的斷點製作，會比較傾向於將文字包裝成 結構化的區塊。無論是 Bootstrap 或諸如此類的工具，最起先的用意即是提供 格線系統 ，用以統一（或標準化）你可以操作的格線，讓網頁排版在某種程度上有高度共通性。所以，當我們在規劃排版這件事情的時候，所需要決定的斷點（ Breakpoints ）就是一個讓人比較難捉摸的地方。例如，瀑布流（他沒有斷點，或者說，每個區塊都是一個斷點）。
Content is king
內容為王的意思就是，內容為王。我們關注的地方有：
- 資料流（ Content flow ）
- 斷點（ Breakpoints ）
這兩件事情跟 RWD 還是 AWD 一點關係也沒有 ，請記好這件事情，這裡跟內容有關，跟你要怎麼去實現 響應 還是 自適應 的事情沒有關係。資料流因為斷點的設計而產生走向，這些走向最終會被我們封裝成區塊，這些區塊才會跟 RWD/AWD 產生關連。我們回文到前兩段，AWD 可以 直接決定內容呈現方式 然後輸出到裝置，RWD 則可以依據裝置來 動態調整資料流與斷點 ，所以現在可以知道是 誰 跟 誰 了吧。
因為我不是設計師，所以我沒辦法給出什麼資料流的設計建議，或是斷點的設計方向。但，依照 區塊 的結構化，我們可以用來編排我們的版型、用來決定是否採用哪一些格線系統。對於資料流的呈現，我們必須依賴網格系統來當作排版的標準（如果全部用 position: absolute 來做，我也是覺得很神）。我們包裝成區塊之後，設計師決定了資料流的順序、樣貌以及操作邏輯，所以，對於前端工程師來說，依循這樣的規則來做絕對不會錯。
網格系統最經典的應該就是 Microsoft Excel（是嗎？），當中的欄與列的呈現方式，其實跟前端工程師切版有 87 分像。諸如時下最潮的 Grid Layout ，或者是 flexbox（目前 Bootstrap4 就是採用 flexbox）。然後，我們又再次回到 10 年前，甚至 20 年前在用 Table 切版的年代。
有沒有聽過「跨欄置中」？
為什麼會提到這件事情，因為在網格系統中，我們將文字簡化為 區塊 的用意，在於簡化（這不是廢話），我是說，利用巢狀結構來降低畫面複雜度。這個是我們在規劃區塊時，需要留意的事情。我在前文所提到的 內容破碎 所指的，即是一種過度區塊化，或是過度扁平導致資訊破碎。舉個例子來說，
請給我一張名片
我先給你我的名字這個區塊
然後這一片是我的職稱
接著這個長方形方塊是我的電話
最後這個方塊是我公司名稱跟 Logo
重點是 請給我一張名片 ，所謂的 一張 就是區塊，裡面的名字、職稱、電話、公司名稱與 Logo 就屬於巢狀結構，他們是 一定且必要 存在於一張名片當中所需要的元素，這種時候若沒有 一張 這個動作來包裝，那麼這些資訊就會流於破碎。
至於在不同尺寸下，我的名片可能 長得不一樣 這件事，就屬於設計師的範疇，對於前端工程師而言，就是把區塊重新排列組合，請記得，就是 排列組合 這件事情而已。在這邊不需要糾結在 RWD 還是 AWD 還是 WD-40 這些事情，因為根本就不干他們的事情。因為不管你是前端重新排列組合，還是後端排列組合後輸出，最終都只是 重新排列組合 而已。
重點在於，你是否如實呈現了設計師的資料流、斷點與介面邏輯。
小結
我還是想說一下，好看的介面設計不代表好的使用者體驗，難看也不一定代表肯定不好。這種事情不是一個硬幣正反兩面的事，讓資料與介面邏輯說話，剩下的就只是輔助而已。
套一句 Amos 說的，能收到款的管你什麼 WD 都切給你。
好 WD-40 不來一罐嗎？
