也來談談wap端瀑布流佈局

Definition

瀑布流佈局，在視覺上表現爲良莠不齊的多欄佈局，隨着頁面滾動條向下滾動，新數據不斷被加載進來。

瀑布流對於圖片的展示，是高效而具備吸引力的，用戶一眼掃過的快速閱讀模式能夠在短期內得到更多的信息量,而瀑布流裏懶加載模式又避免了用戶鼠標點擊的翻頁操做。

瀑布流的主要特性即是錯落有致，於亂中見序，定寬而不定高的設計讓頁面區別於傳統的矩陣式圖片佈局模式，巧妙的利用視覺層級，視線的任意流動又緩解了視覺疲勞，同時給人以不拘一格的感受，切中年輕一族的個性化心理。

最先採用此佈局的網站是Pinterest，逐漸在國內流行開來。

目前主流的佈局方式是如下三種：

1. 傳統的多列浮動：如wap端天貓的搜索結果頁就是左右兩列浮動佈局
2. 經過絕對定位的方式：如Pinterest。
3. 使用css3實現。

本文重點討論的是第三種。

Origin

我組負責的搜索結果頁佈局是傳統的格子布局，經過 ul>li.float[width:50%]*2 簡單代碼就能夠知足效果了。

不過，PM在橫向比較其餘廠的設計後，堅定要求咱們上瀑布流。

老早就有這個需求了，在我入職前老早就有了。由於開發進度等各類緣由拖了下來，此次過完了818，又提了出來。前端不是什麼麻煩事，在和後端同窗溝通後，這事就定了下來。

限於移動端的硬件性能，絕對定位實現瀑布流的方式首先就否了。

另外左右兩列的佈局，不利於數據的渲染。

通常搜索結果頁有列表和大圖兩種模式切換。

切換的樣式佈局能夠經過css來控制（ps：具體的代碼就不貼了，能夠參考現有的搜索結果頁），

後臺的模板渲染也只是一套，前端異步加載新數據依然是一種數據就能夠了。

若是是左右兩列的佈局，就麻煩多了

• 首先列表佈局和大圖佈局各有一種樣式
• 後臺的渲染模板也要有兩套，列表的data-module不變，大圖模式須要將dm按奇偶數分開，而後各自再組成data-list去填充模板
• 前端加載下一頁獲取的數據能夠保持dm不變，不過須要經過js拆爲兩個奇偶list。
  這樣就背離了先後端分離的初衷，並且也加劇了browser的負擔。
  所以，依然須要後臺去實現數據分拆，接口變動。
• 這也就是瀑布流佈局一直拖着沒作的緣由。

因此若是前端能實現，不須要多少的工做量，不增長其餘童鞋的工做量，天然是皆大歡喜。

Fill the hole

1. 使用flex彈性佈局實現

ps：還不知道flex? 傳送門在這
使用flex-direction：column縱向排列的屬性 + flex-wrap:wrap超太高度換行的屬性來實現。

線上的能夠參考這個網址

DEMO的代碼在這

截圖以下：

• 看數字，很明顯是縱向排列，根本就是僞瀑布流佈局。
• 很坑的是，高度要定死，要不DOM是不會換行的。
• 另外加載新數據，高度須要從新計算，且總體的排列順序變掉了。依然是先佔滿左列的空間，再折行。

以下圖，高度不變，增長DOM，變成四列了。




高度改變，變成這樣了




so，這種實現方式對單頁且對排序不敏感的需求適用或者對橫向佈局適用。

2. 經過collumn屬性來實現

css3中增長了一個新的屬性：column 來實現等高的列的佈局效果。該屬性有column-width寬度，column-count數量等，而且能根據窗口自適應。

DEMO代碼傳送門

該屬性的效果幾乎與上面的截圖等同，新增數據的效果也同樣

所以，該屬性並不適合瀑布流的格子布局。

實際上，collumn比較適合文字內容的佈局，w3cScholl提供的就是文本佈局的栗子傳送門。

咱們來看看普通瀑布流佈局與css3實現的效果對比圖

不管是flex.collumn仍是collumn都是以縱向展開、向右推動的形式來佈局的，並非橫向平鋪佈局、向下推動的方式。其餘的實現方式還沒有找到，到這裏就走到了死衚衕了，因此還得使用最上面所說的左右兩列布局來實現

3. 依然使用flex

佈局的傳統解決方案，基於盒狀模型，依賴 display屬性 + position屬性 + float屬性。

而現代特性的Flex佈局，能夠簡便、完整、響應式地實現各類頁面佈局，那麼就用flex取代float來實現左右兩列的佈局。

具體的實現邏輯只能按照最上的分析了。
DEMO傳送門

end