CSS 魔法：学海无涯，而吾生有涯

摘要：我们都知道您是国内知名的专家，是什么样的情结使得您愿意将魔法作为自己的别名大家好，很荣幸接受图灵的专访。在这一堆书里，有一套上下册教程叫作谈是由图灵引进的哦。从偶像那里得来一个名字，很荣幸而且这其中也有图灵的功劳，也是缘份。

非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/article/216538

图灵访谈非常有幸能邀请到“魔法哥”，进行一期专访。我们都知道您是国内知名的 CSS 专家，是什么样的 “CSS情结” 使得您愿意将 “CSS魔法” 作为自己的别名？

大家好，很荣幸接受图灵的专访。我叫 “CSS魔法”，熟悉我的朋友都叫我 “魔法哥”。 这个问题问得好，瞬间把我的思绪拉回八年之前——那时我刚开始系统地学习前端知识。当时为了找一份前端工作，我把市面上所有的 CSS 书籍全部买来，全部啃光，迅速且系统地掌握了 CSS 的基础知识。

在这一堆书里，有一套上下册教程叫作《Eric Meyer谈CSS》（是由图灵引进的哦）。我记得很清楚，书里有这么一段话：“在准备好语义化的结构之后，我们再给它施加一点儿 CSS 魔法……” 我当时感觉这句话正好契合 CSS 带给我的体验！

我很喜欢 CSS 这门技术，它优雅、神奇、充满魔力，短短几行代码就可以让我们的网页脱胎换骨、焕然一新。于是从那时起，我就开始使用 “CSS魔法” 这个网名了。以这个名字注册了微博，后来还创建了 “CSS魔法” 微信公众号，分享自己在前端领域的学习经验；在为图灵翻译《CSS揭秘》一书时，也很自然地以此为笔名了。

说到 Eric Meyer，他还是《CSS权威指南》的作者，也是我的偶像。从偶像那里得来一个名字，很荣幸；而且这其中也有图灵的功劳，也是缘份。 请简单介绍一下您在百姓网的工作内容吧！

我目前在百姓网担任手机站的前端架构师。比较尴尬的是，“前端架构师” 这个头衔经常遭遇质疑：“前端居然也需要架构？” 所以我也趁这个机会阐述一下，我理解中的前端架构到是什么。

其实不管是前端还是后端，任何一项严肃的、长期的、大规模的工程，都是需要有人来设计架构的。

百姓网的前端架构目标很明确：随着业务规模的扩张和团队的壮大，整个网站系统的复杂度也随之迅速上升；如何化繁为简、帮助业务工程师高效高质完成开发任务，这正是前端架构师的职责和挑战所在。

因此，简单概括一下，我在百姓网所做前端架构工作包括：

编写工具库和 UI 框架，并提供文档，提升业务开发效率

优化开发流程，提升业务工程师的开发体验

制定各类开发规范，并通过工具来确保规范的执行

调研新技术、新工具，并适时应用推广

组织定期的技术交流会和不定期的技术分享

……

看来“魔法哥”要全面把握开发流程，规划框架，制定规范。那平时还需要写代码吗？

其实，长年重构代码也都是份内事，偶尔还需要投身业务开发。毕竟架构层作为业务层的坚实后盾，松懈不得啊！

您觉得哪些 CSS 知识是必须掌握的？

对一个专业的 CSS 开发者来说，首先，CSS2 的核心知识必须完全掌握。以《CSS权威指南》（第三版）为例，除了 “声音样式” 之外，这本书的所有内容都是应该透彻理解的。即使记不住某些冷僻属性的名称与行为，也需要知道在哪里可以快速查阅。

接下来，关于 CSS3，很多同学都问过我这样一个问题：“魔法哥，现在浏览器都支持 CSS3 了，我跳过 CSS2 直接学 CSS3 可以吗？”

在回答这个问题之前，我们需要先搞清楚 “CSS3” 到底是什么。读过《CSS揭秘》这本书的同学应该都很清楚了，“CSS3” 是一个俗称，并不是 W3C 的官方术语。基本上它是CSS2 之后更新或新增的 CSS 规范模块的合称。

实际上，CSS3 相对于 CSS2 并不是类似软件版本更替那样的升级。CSS2 的全称是 “CSS Level 2”，后续的 CSS 规范并不是完全以替代品的形态出现的，某些 Level3 的 CSS 规范模块（或新增的规范模块）往往是基于 CSS2 来扩展的。

因此，对于 CSS 学习者来说，如果买了一本只讲 CSS3 新增内容的教程或参考书，那还需要搭配 CSS2 的书来看。事实上，由于篇幅所限，市面上绝大部分以 “CSS3” 为卖点的图书确实都不会重复讲解 CSS2 的内容。看到这里，相信上面的问题在大家心中已经得出答案了吧。

我自己的学习路径是这样的：通过《CSS权威指南》和《精通CSS》等 CSS2 时代的经典教程来打好 CSS2 的基础（因为 CSS2 已经完全稳定了）；对后续新技术和新规范的了解和掌握，通常求助于 MDN 等在线资源（因为变化相当快）。如果新入门的同学面对庞杂的 CSS 体系感觉无从下手，不妨参考这条路径。

有图灵社区网友提问：您在工作中常用的 CSS 实用技巧有哪些？

首先，我会毫不犹豫地推荐大家使用 CSS 预处理器。由于 CSS 并不是编程语言，并不具备抽象能力，当网站的规模发展到一定程度之后，原生 CSS 很难解决抽象与复用的问题。而预处理器则正好弥补了 CSS 在这方面的不足。

即使你不打算学习预处理器的特有语法，甚至还有些排斥，那也不妨尝试利用它的模块机制来拆分和组织代码。由于预处理器大多兼容 CSS 原生语法，因此你可以保持原来写代码的习惯，仅利用预处理器在模块化方面的功能。

对于多人合作的团队来说，通过模块来拆分代码尤为重要。虽然引入预处理器会要求你在工作流中加入构建环节，但我认为这个成本是完全值得的。

接下来，想跟大家分享的经验就是：做好 CSS 代码的 “分层”。我设计的 CSS 架构通常都会由 “Normalize + Reset → 通用基础样式 → UI 组件 → 页面通用的布局框架 → 单个页面的布局和样式” 这几个层级构成，越往左越靠近架构，越往右越靠近业务。

划好层级并把代码写到正确的层级去，可以带来很多好处：在团队分工上，可以把不同层级的代码交给不同的人来开发和维护，相当于关注点分离；从架构角度来看，也可以实现 “控制复杂度” 这一重要目的。

还有就是善用工具。比如通过 Lint 程序来保障代码规范的执行，通过构建工具来让重复劳动尽可能自动化，通过 Autoprefixer 这样的工具来加工或生成代码，等等。俗话说，磨刀不误砍柴工，多看多听多试，用开放的心态去了解和尝试新工具，往往会有不错的收获。

如果这位网友想问的是 “有哪些实用的 CSS 特性”，那我觉得至少要提一下 Flexbox。它是 CSS3 引入的更强大、更易用的布局方式，而且我们在移动端已经可以安全地使用 Flexbox 的基础特性了。其它的特性，比如高级选择符、渐变、动画等高级特性，也非常有价值，我在编写 UI 框架时都有实际应用。

此外，大家可能还想了解在编写 CSS 时需要掌握的原则和思路。这里我会推荐《CSS揭秘》这本书中的“CSS 编码技巧”一节。我一直想写篇文章来讲述自己多年积累的 CSS 经验，但一直苦于找不到合适的切入点，总怕挂一漏万。而当我读到这一节时终于释然——原来已经有人帮我做了这件事情！随后我也将它亲手翻译了出来，也算了却了一桩心事。

前端领域的技术更新非常快，常常是一门技术还没学明白，另一门技术又火了，你是如何取舍的呢？

确实，近些年前端领域的新技术、新工具、以及新的实践方式都层出不穷，稍不留神就会有落伍的感觉。而每个人精力都是有限的，面对这样的局面，难免会有一种疲于奔命的压迫感。

我自己的应对方式是抓住核心，放弃自己很难精通的、一时用不到的、或者对当下想做的事情价值不大的技术方向。比如一路以来，我放弃了富媒体方向的 Flash，放弃了图形与游戏方向的 Canvas 和 WebGL，放弃了单页应用方向的 MV*，放弃了语言方向的 FP ，等等。

当然这些 “放弃” 都是战略性的，而不是永久性的。毕竟精力有限，不可能面面俱到。不过，一旦某个方向变成自己必须攻克的战略要地，那我也必然会义无反顾跃入新坑。

除了在技术范畴内作取舍，我还会把一部分精力放在 “人” 身上——就是写代码的这群人。个人英雄的时代一去不复返了，单打独斗能力再强，也难成气候。因此，帮助身边的小伙伴快速成长，打造一支梯队完备、技能互补的前端开发团队，往往更具现实意义。有些时候，这也可以成为一种 “突破瓶颈” 的解决方案——每当团队里的小伙伴攻克了某项新技术时，我都可以宽慰自己：我不会，没关系，有小伙伴可以顶上！

有图灵社区网友提问：CSS 与它的小伙伴儿 JavaScript 的关系是怎样的？有什么共同点和差异？

哇噢，这个问题完全是面试题的既视感啊！好的，我来好好回答一下，重温被面试的感觉。

根据 Web 标准的 “分离” 原则，网页界面由三层构成：结构层、表现层、行为层。这三者在技术上分别由 HTML、CSS、JS 来实现。大家都知道有句话叫 “术业有专攻”，在网页上也是一样，不同的层应该由不同的技术来实现。

在近些年，CSS 的能力得到了不少提升，比如 :hover 伪类的增强以及 :checked、:target 等新伪类的出现，令原本只能由 JS 实现的交互功能也可以用 CSS 来实现了。这意味着，在某些场景下，这两者的功能有重叠的地方。

不过从原理上来说，CSS 只具备修改渲染树的能力，无法修改 DOM 结构（“渲染树” 是指 DOM 树在应用样式之后产生的、用于渲染网页界面的数据模型）。CSS 可以通过 display、visibility、opacity 等属性来控制元素的显隐，但无法把元素从 DOM 树上删除或移动，也无法创建新的 DOM 元素。这是 CSS 的能力边界。

虽然这两者的功能有一些重叠，但它们并不是互斥的。JS 和 CSS 是可以合作的，而且我们应该擅用这种合作关系，发挥各自所长。举例来说，CSS 的声明式特性比较简单易懂，在管理样式方面更加易于书写和维护。因此，在实现某些动态效果的时候，我们可以把不同状态的样式以类的形式写在 CSS 中，然后让 JS 通过切换元素的类来实现样式的变化。

有图灵社区网友提问：鉴于 CSS 擅长处理复杂布局和绚丽的视觉效果，眼下 Web 开发者可以跳过 JavaScript，走 “UI + 后端” 的路线么？

简单地说：不可能。

首先说一下 “UI” 这个概念。UI 并不是静态的布局和样式，不是设计师发给我们的 PSD 图像。UI 是用户界面，它的核心是交互，而交互需要由 JS 来实现。交互以及交互传达出的用户体验，才是眼下前端的核心价值。

接下来，我们回到实际的开发场景中来看待这个问题。如果是团队作战，那么团队中的个体当然可以有所侧重和取舍。在整个技术栈中，自己放下的某个环节只要有小伙伴可以顶上，那就没啥大问题。不过如果是打算通吃前后端的全栈工程师给自己做职业规划，那么 JS 是绕不开的。

其实在图灵社区里，我跟这位提问的网友已经有过交流。他回避 JS 的原因主要在于入门时被网上的低劣教程所误导，对 JS 留下了错误的第一印象，进而心生抵触。

这位网友的经历让我十分惋惜，同时也不由地深深感叹：我们在学习一门技术时，选择规范、系统的学习途径是多么重要啊！所以这里要再一次郑重推荐图灵的程序设计丛书，魔法哥信赖之选！

有图灵社区网友提问：您是否赞同将前人留下的技巧直接运用到自己的项目中？是否需要 “知其然、知其所以然” 的研究精神？

这要看你给自己的定位是什么。我认为技术工作者大致可以分为两类。第一类人单纯被技术本身所吸引——相信我们都有感触，技术本身就有一种迷人的美！而第二类人把技术作为手段，他们学习技术的最终目的是通过技术来推动一些事。这两种技术人都有各自合理的出发点，并没有孰对孰错之分。

那么，如果你是第一类人，那你对自己的规划和定位必然是某个领域的技术专家。所有有价值的技术都应该被你吃透，而且相信你自己也会有源源不断的强烈兴趣，去把这些技术掰开了、揉碎了研究到极致。

而如果你是第二类人，那么 “知其所以然” 就不是必须的了。尤其是在团队中，你可以把 “知其所以然” 的任务交给技术专家，把有限的精力投入到更适合自己的地方去。

回想自己一路以来的经历，能否给前端初学者分享一些学习经验？

我这些年写博客始终以初中级开发者作为主要受众，创建的“CSS魔法” 微信公众号也仍然关注前端初学者群体。因此可以聊的经验有很多，最重要的应该是——“系统学习、打好基础”，因为真正基础的东西是不会过时的。

我也曾模仿别人网站的代码，或是在网上收集别人发表的各种技巧，然后把找来的一句句代码拼凑在一起。虽然这种方法通常也可以生效，但我完全不知其所以然，那些代码片断对我来说无异于外星人的咒语。由于无人指导，无法系统地学习知识，当时的状态就像是在黑暗的迷宫中摸索一样。

当时在书店里能找到的相关书籍也无非是一些迎合国人 “短平快” 心理的快餐书，什么“现学现用”“代码速查 300 例” 之类。我是一个喜欢打破沙锅问到底的人，这些没头没尾的所谓技巧显然无法满足我的好奇心，失望而归。

几年之后，以图灵为代表的科技图书公司开始引进国外的经典教程和参考书。当《精通CSS》《JavaScript 高级程序设计》这些著作捧到我手上时，你可以想像我当时有多么欣喜若狂。

在疯狂求知的过程中，我发现，前些年我在网上费尽辛苦收集到的珍稀黑魔法，其实在书里都有着更加全面和系统的讲解。当我稳固地掌握了 HTML、CSS、JS 的基础知识之后，我惊讶地发现，原先那些看似神奇、背都背不下来的外星咒语，早已融入我的血液，成为信手拈来的本能。

现在的孩子们是幸福的，你们生活在一个信息通畅、资源富足的时代。因此不需要眼巴巴地乞求 “大神们” 施舍只言片语的秘技，只要多读几页书，你也可以成为别人眼中的大神！

十分感谢魔法哥花费宝贵的时间接受图灵的专访，深入浅出，鞭辟入里！

我也很高兴今天跟大家聊了这么多，我们下次再见!