图灵访谈 CSS魔法：学海无涯，而吾生有涯

本文由 “图灵访谈” 微信公众号约稿并首发，由 @CSS魔法 撰稿。

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

大家好，很荣幸接受图灵的专访。我叫 “CSS魔法”，熟悉我的朋友都叫我 “魔法哥”。

这个问题问得好，瞬间把我的思绪拉回八年之前——那时我刚开始系统地学习前端知识。当时为了找一份前端工作，我把市面上所有的 CSS 书籍全部买来，全部啃光，迅速且系统地掌握了 CSS 的基础知识。

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

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

说到 Eric Meyer，他还是《CSS 权威指南》的作者，也是我的偶像。从偶像那里得来一个名字，很荣幸；而且这其中也有图灵的功劳，也是缘份。

请简单介绍一下您在百姓网的工作内容吧！

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

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

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

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

• 编写工具库和 UI 框架，并提供文档，提升业务开发效率。
• 优化开发流程，提升业务工程师的开发体验。
• 制定各类开发规范，并通过工具来确保规范的执行。
• 调研新技术、新工具，并适时应用推广。
• 组织定期的技术交流会和不定期的技术分享……

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

此外，大家可能还想了解在编写 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 的基础知识之后，我惊讶地发现，原先那些看似神奇、背都背不下来的外星咒语，早已融入我的血液，成为信手拈来的本能。

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

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

谢谢肯定。很高兴今天跟大家聊了这么多，我们下次再见！

（长按或扫描二维码，即可关注 “CSS魔法” 公众号。）