CSS魔法, 原名张鹏,国内知名CSS技术专家,百姓网前端架构师。拥有近十年的网站开发经验,在移动前端领域积累颇深,自称“披着工程师外衣的设计师”。他是CMUI、Action、GHX等开源项目的作者,曾为GitHub、Gulp、Stylus等网站和项目翻译过大量文档;其生动活泼、循序渐进的博客写作风格深受读者喜爱,在CSS Conf等技术会议上的演讲广受好评。

图灵访谈非常有幸能邀请到“魔法哥”,进行一期专访。我们都知道您是国内知名的 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 的基础知识之后,我惊讶地发现,原先那些看似神奇、背都背不下来的外星咒语,早已融入我的血液,成为信手拈来的本能。

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

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

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

更多精彩,加入图灵访谈微信!