这个博客已经过去了很久……

不过,你可以通过以下方式找到我

现在的位置: 首页 > 谈前端 > HTML > 正文
最牛逼的 HTML 和 CSS 代码的背后
2013年08月26日 HTML ⁄ 共 2751字 等你评论

前些天,kejunz 在微博上发了两条微博:

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

我认为史上写的最牛逼的html是

  1. <div class="mod"><div class="hd"></div><div class="bd"></div></div>  

可以想想它好在哪

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

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

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

为什么克军会说最牛逼的HTML是

  1. <div class="mod"><div class="hd"></div><div class="bd"></div></div>  

?克军究竟想表达什么?照着这条路子去想,就挺有意思了。

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

<div>
 ...
</div>

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

<div>
  <div></div>
  <div></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 作为设计模式的重要原则之一,其重要性不用我在此啰嗦了。

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

  1. <div class="mod"><div class="hd"></div><div class="bd"></div></div>  

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

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

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

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

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

然后,没有然后了……

友荐云推荐
×