最牛逼的 HTML 和 CSS 代码的背后

前些天，kejunz 在微博上发了两条微博：

现在国内都一堆只会写JS的前端工程师真是奇葩啊

我认为史上写的最牛逼的html是<div class="mod"><div class="hd"></div><div class="bd"></div></div>可以想想它好在哪

这两个话题都挺有意思的。

第一个是吐槽目前很多前端太重JS，而忽视了HTML和CSS的重要性。这个话题，今年我在WebReBuild上海站时也提到过，甚至比较极端的说，**在前端开发领域，最难的其实是HTML，其次是CSS，最后才是JS。**当然这句话是不正确的，然而我们真需要老说那么正确的话吗？正确的话很多时候还不如不正确的话那么对人有用。比对错更重要的是对场景、环境的理解、把控。克军在感慨“奇葩”时，离不开的是当下的前端环境。对错是二元论，二元论就和红色电影里的好人坏人一样，与真实世界有较大的偏差。好的文学作品当如《红楼梦》一样，或者莫言的《蛙》，里面的人物，即便夸张，也无对错的评价。貌似跑题了，最近写什么都很容易跑题，奇怪……

克军的第二条微博，在我看到时真有一种触动。“最牛逼”只是修饰语，表示强调，就如我说“最难”的是HTML一样。看到这种微博时，别急着去反驳有更牛逼的HTML，或去思考JS比HTML难呀。若抱着这种反驳、挑刺的心态去读微博，或者倾听他人谈话，大部分情况下你不会有什么收获。

为什么克军会说最牛逼的HTML是<div class="mod"><div class="hd"></div><div class="bd"></div></div>？克军究竟想表达什么？照着这条路子去想，就挺有意思了。

凡是真心当过切图仔的（非贬义，我认为切图仔对前端来说是个褒义词，很形象，就和美国的西部牛仔一样），或多或少都写过：

<div class="box">
 ...
</div>

上面的代码是典型的一个页面区域，或者说页面的模块。纵观当前互联网上的页面，几乎充满着各种页面模块。一个典型的页面模块，包括头部和主体，比如：

<div class="box">
  <div class="hd"></div>
  <div class="bd"></div>
</div>

至于里面的 class 名，最外层有叫 box 的，也有叫 mod 的，不用太纠结，都差不多。里面的 hd 和 bd，则千差万别，比如 header、content、container、main 等等都有。克军是受了 YUI 的影响，用 hd 和 bd 也蛮清晰的，这些都不纠结。对一个团队来说，关键是要统一，要达成一致理解。

上面还无法说明为何这就牛逼了，我的理解是，要知道上面的代码为什么牛逼，你得亲历并想清楚过以下事情：

1. 为何只有 hd 和 bd？ft 呢？
2. 为何用 div 而不是 section / header 等？
3. 为何 hd 里的标签没做约定？
4. 这段代码，是为了满足什么需求？
5. 对于复杂需求，这个代码如何变化？
6. 简单和复杂之间如何权衡？（很多程序员倾向于把事情搞复杂）
7. 为何不是 mod / mod-hd / mod-bd ？
8. 在什么场景下这段代码不适用？（比如组合命名和长命名之争）
9. 这东西跟性能没关系。
10. 这东西跟可维护性关系很大。
11. 究竟什么是结构与样式的分离？
12. 衡量一个好的HTML代码的标准是什么？
13. 结构化设计是什么？
14. 部分如何构建出整体？砖瓦是怎么变成大厦的？
15. 关注度分离是个啥东西？
16. 什么是抽象？抽象的价值究竟是啥？
17. 什么是创新？什么是超越？

一定会有人说我扯远了。不过我想，如果你遇到过并认真思考过以上问题，你在见到克军这条微博时就不会惊讶了。这段代码的确是最牛逼的HTML代码。如果你不同意，请参考我前面关于对错的观点。

看到克军这条微博后的一天，我就在思索最牛逼的HTML代码有了，那么最牛逼的CSS代码是什么呢？仔细搜寻了一番记忆，于是有了这条微博：

贴一个我见过的写得最好的 CSS 代码：.content { width: 980px; margin-left: auto; margin-right: auto; } 可以想想好在哪。

算是抖个包袱，早上发完之后，就秋游去了。玩了一天，看看回复，还是挺有意思的，有少数几个回复已经说出了我想说的。其实大部分在上面说最牛逼的HTML时已经说了，但还得说明下：

1. 这跟性能没关。怎么老有人喜欢“性能思维”呢？在前端代码里，大部分性能问题都是扯淡。
2. 这跟 980px 没关。栅格年代已经远去了，960 不是 magic number.

这段代码的作用，是个前端都能看懂：让块元素水平居中。一般大家都会写成：

.content {
  width: 980px;
  margin: 0 auto;
}

上面的代码能正常工作，大部分情况下也不会有问题，但上面的代码存在**思维的懒惰**。写成:

.content {
  width: 980px;
  margin-left: auto;
  margin-right auto;
}

看起来代码变多了，变啰嗦了。但如果你真经过思考，就会明白：

1. margin: 0 auto 中的 0 绝大部分情况下是冗余的，页面上早就有 reset.css 或 normalize.css 重置过
2. margin: 0 auto 不纯粹，你要的是“水平居中”，却顺便把 top / bottom 给重置了
3. 不纯粹会导致顺序和优先级的依赖，比如有另一处要给 margin-top/bottom 赋值时，就必须要提高优先级

进一步的东西是，我一直觉得CSS里，有一个重要的原则：

最小影响原则

你在写某段CSS代码时，首先要非常清楚地知道这段CSS代码的功能，其次要尽量严格保障这段CSS代码只实现了你想要实现的功能。

这就如医生动手术，好好做好本分就行，千万别留下一个小镊子在病人身体里。

与HTML代码一样，对CSS代码来说，很重要的两个衡量标准也是稳定和灵活。这里不多说了。

熟悉设计模式的，应该会感知到，最小影响原则和单一职责原则（SRP）本质上是一样的。SRP 作为设计模式的重要原则之一，其重要性不用我在此啰嗦了。

最后想说下下面这段代码：

<div class="mod"><div class="tr"><div class="tl><div class="tc"></div></div></div><div class="mr"><div class="ml"><div class="mc"></div></div></div> <div class="br"><div class="bl><div class="bc"></div></div></div>

好像还有人做过九宫格布局……

以及最近在 KISSY 开发群里的一段文字：

我发现DataLazyload有两个问题：
1.判断节点是否已经在视图之中的时间简单的判断Dom.offset,没有考虑到节点或者上级节点被隐藏的现象
2.如果页面上脚本自动显示、隐藏或更改一些层的大小，引起某些层从视图外移动到视图类，DataLazyload既没有自己判断这种情况，也没有提供接口来重新执行loadItems

很多DPL了做着做着，很多类库组件开发着开发着，都很容易被诱惑着去“满足所有需求”，去“解决所有bug”……

如何权衡简单与复杂？如何在复杂中依旧能保持简单？没bug的组件是好组件吗？究竟什么是好组件？

然后，没有然后了……