也来谈谈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