w3ctech

既然写CSS很容易,那为什么大家还是把CSS写的那么烂呢?-Hacker Noon

在你开始阅读这篇文章之前,一定要做好心理准备。因为我写的 90% 都是在发牢骚,只有最后大概 10% 介绍 CSS 技巧之最佳实践。提前给你们打好预防针啦。

important does not fix your bad css

前端工程师在职业发展中可能会遇到以下困境:

  • 某个阶段,感觉(自己所做的)工作没有任何难度

  • 为团队创造的价值越来越低啦

  • 自己做的事情,大家都能做

同意的请举手。如果你确实是这样,(恭喜你)说明你是多数派。

而且说句实在话,CSS 确实很简单。另外我可以保证,就算是傻子也能写出下面的代码:


p {

color: red;

}

那么你还有什么好抱怨的?堆纯 CSS 代码,不需要任何技巧。而且只给单个元素添加全局样式,而不用考虑其他 CSS,当然是非常简单的。

那么CSS到底难在哪儿?

one does not simply mess with css

后端开发工程师:“虽然我已经完成新功能的开发,但是我弄乱了前端,不过你放心,我已经修好绝大部分,所以你前端只需要对细节进行微调,时间应该不会超过 30 分钟”

于是我打开HTML文件,(吃惊地)发现到处都是弃用的HTML标签,而且丝毫没有考虑过响应式设计。深呼吸,(暗示自己),他们写的CSS肯定会稍微好点。然而在我打开CSS文件之后,发现(同样)到处都是类似固定(fixed)定位、清除左浮动、右浮动以及!important的代码,于是我慢慢的把鼠标绕在脖子上。(别拦我,让我死)

(安慰自己),也许他们写出的代码不会一直这么糟糕,但是(在现实中)我几乎没见过后端工程师写出能用的前端代码的。也还好啦,写前端代码本来就不是后端工程师的职责所在。但是请后端工程师不要随便写一堆前端代码,然后指望前端工程师帮你擦屁股。

所以好的CSS长啥样?

you don't have to put all your sass files in the same folder

(项目的)组织结构。尤其是当你做过大型项目,就会发现项目的组织结构真的很重要。举个正面例子——Steven Bradley 写的利于维护代码的目录结构,这篇文章是为 SCSS 项目写的,不过也适用于普通的 CSS 项目。它重点强调如何将 CSS 文件模块化,形成便于维护的文件。

规范。这可能是我每天所遇到的最大问题。不幸的是,大部分工程师对CSS规范的理解一知半解,正是因为这样,才导致糟糕的 CSS 代码(如 !important)烂大街。那我们该如何避免呢?下面列出了很多值得参考的命名约定,它们旨在减少写死的(非常依赖文档结构的) CSS 选择器。假设你对此不感冒,我还是要劝你如无必要,避免使用超过 3 层的 CSS 类/元素选择器。

命名约定。恕我直言,对于任何一个大型的 CSS 项目来说,命名约定是标配。没有命名约定,CSS 就会变得既难维护又不可靠。命名约定可以让我们轻松地重用项目中的 CSS,如有必要,还能帮我们剔除项目中多余的 CSS。这里仅列举几种比较流行的命名约定,如:BEMOOCSSSMACSS以及我自己写的hiccup

测试。在这一点上,绝大多数其它工程师可能都没发现当后端工程师有多爽。 因为后端工程师的开发工作只需要让一个环境(网站所在的服务器)正常即可。你知道作为前端工程师最痛苦的事情是什么吗?5 个以上的浏览器以及上千种移动设备……好的前端测试工作其实是个苦差,且耗时很长。我见过很多项目延期,就因为没有把前端测试考虑进去,而通常前端测试花费的时间会超出常人预期。

所以如何扭转这种对CSS的天真看法?

i'm working on css over here!

在以后工作中,再也不能让后端工程师们抱有侥幸心理。作为前端工程师,我们不会随便把一堆无响应式的 CSS 代码丢给后端工程师,然后撒手不管。所以凭什么他们就能写无用的烂代码,然后在他们的 CSS 代码失效时让我们去打补丁?我不是说要让后端工程师好好写 CSS 代码,而是我们应该告诉后端工程师,如果觉得写 CSS 很难的话,就不要写。别让其他工程师觉得前端很简单,前端才不简单呢,我们前端工程师跟其他人一样努力地工作,别让他们看走眼。

w3ctech微信

扫码关注w3ctech微信公众号

共收到1条回复

  • 深有同感

    回复此楼