本文转载自图灵社区对Lea Verou专访，专访时间：2016年8月。

Lea Verou

W3C CSS工作组特邀专家，设计CSS语言的委员之一，此前曾在W3C担任开发者代言人。目前，她在麻省理工学院从事人机交互领域的研究。她还是一位博客作家，并经常在国际性的技术会议上担任讲师；她创建的多个开源项目广受开发者欢迎。

-图说-

来自CSS一姐的个人网站（），也多用于各种公众场合，例如本书的作者介绍部分。

-图说-

Lea的运动照，爱游泳。

-图说-

Lea自己设计的图标，常见各种公众场合，包括本书的封面。

访谈内容：英文版

非常荣幸能够邀请到畅销书《CSS 揭秘》的作者Lea Verou，进行一期图灵专访。请问Lea写这本书的初衷是什么？读者应该怎样阅读本书？

市面上有很多CSS的书，有全面讲解CSS各方面知识的，也有专注介绍某一方面的。但是，没有一本书教会读者怎样运用CSS创造性地思考、解决问题，也没有一本书可以跳过最开始的简介部分。

概括来讲，这似乎是学习新知识时的一个普遍问题：大多数图书只会提供陈腐、老掉牙的解决方案，却不会尝试向读者介绍如何获得自己的解决方法。说到CSS方面的书，作者们总是想当然地认为读者都是些“技术小白”，也就想当然地架构起内容。《CSS 揭秘》这本书呢，尊重语言和读者，没有简化内容。CSS高级开发人员以及真正理解CSS是如何工作却想进一步提高知识的人，会从本书中获益最多。

《CSS揭秘》封面的右下角有一个类似海盗标志的Logo，而这个标志同样也出现在你的个人网站上。这个标志的背后含义是什么？对我自己而言，你好像挺欣赏海盗元素的，透过批判性思维能从“丑陋”当中发现“美善”？

这是我个人的Logo，已经用了好多年了。它本身并没有什么特殊的含义，不用太认真对待。括号（{ }）表示代码，作为语法元素经常出现在CSS和JavaScript里。两把交叉刀代表海盗、编码界的海盗。在西方文化当中，海盗并不一定表示坏的意思，他们也可以表示某方面的“大牛”。这也是我想要传达的意思。

我们一般认为，男权社会中男性的地位要高于女性。作为女性，你又来自互联网技术不太发达的希腊。是什么原因让你成为一位世界范围内广泛知晓的开发人员？一个人的出身是否可以决定她/他的成就？

值得庆幸的是，网络的普及，让出身和人们所能达到的高度之间不存在必然联系。我见过有的人把自己封闭在某个网络的小角落里，只跟自己国家的人交流、工作，但这是他们的选择。只要把英语说好，没有人能限制他们成就的广度和深度。我希望任何想在国际舞台上做出一些事情的人要专注于提高自己的英语水平，而不仅仅是他们的HTML、CSS和JavaScript。不管你的技术知识有多好，如果不能很好地表达自己，没有人会知道。

讲一个我自己的有趣故事，开始创建个人博客之前，我曾用希腊语创建过一个博客，很遗憾完全地、彻底地失败了。在希腊，很少有人会对前沿的css技术感兴趣，这也就可以解释为什么希腊的开发人员挣得那么少，还常常被他们的客户刁难。我很庆幸自己没有放弃，开始创建用英语编写的国际博客，不然我的生活肯定是另一番样态。

希腊目前可能还存在一些针对女性的性别歧视，但并不明显，不然我可能会被影响到。实际上，有时候希腊在性别平等方面比其他西方国家更进步。我最近在个人博客上写了一篇博文（ ），文章里讲到在我的职业生涯里，我个人还没有真正经历过任何的性别歧视。所以，我喜欢做这一行：）

除了写书分享知识以外，你还分享了好多的开源项目。但是，据我所知，有些人是不愿意分享代码示例的。他们认可展示出来设计良好的作品，却不愿意分享设计蓝图。你怎么看待？

代码共享是一种回馈社会的行为。无论从事什么行业，我们都离不开开源项目的帮助。想象一下，如果每个人的逻辑都一模一样，我们的专业会千篇一律。使用了别人分享的成果却不愿意分享自己的代码，在我看来，有点“小自私”。的确，其他行业的文化可能有所不同，从业人员不愿意分享工作。

我很喜欢技术行业的开放分享文化，欣赏开发人员之间分享知识、互相帮助的活动。他们热衷于分享代码或者回答Stack Overflow技术问答网站上的问题。换做是我，我一样会这么做。另外，当我的工作可以帮助到别人、被他人使用时，我非常高兴。这就是为什么我选择这个领域的原因。

开源代码也意味着其他人可以参与进来，为项目做贡献，最终项目的质量也更高。比如说，我发布Bliss的时候，还没有测试，现在它有一整套testsuite帮助调试bug。还有许多项目，比如PrismJS是由社区共同维护的。我自己没有时间维护它们，如果不是开源，项目只会烂尾。

演讲时，现场展示代码编写过程应该算是开源的最高形式。难道你没有想过代码漏洞或者拖延会影响公共演讲吗？通常你怎么为会议演讲做准备？

现场展示代码编写之前，我会一遍一遍地演示代码，这一点非常重要。代码要尽可能短，尽量减少犯错的机会，而且一般情况下，观众也无法消化一张幻灯片上好多行的代码量。我见过有人曾用100行的代码启动IDE ，在开始演示代码编写之前，很多观众早已失去了兴趣。

尽管你竭尽可能避免犯错，现场展示代码编写总避免不了失误的发生。出发前，我还在飞机上调试漏洞，除非能立即修复，不然我只能暂且放下问题。没有人希望在现场展示时跟代码漏洞较劲。我个人经历中，只要演讲者能很快调试好代码，听众大都很理解。

下面我们来聊聊CSS。和CSS相比，JavaScript的新增特性从生成到广泛应用历时几天，而CSS的新增特性要经历长达几年的周期。所以，有人建议多增加一些CSS polyfill。你怎么看待这个问题？

这样做肯定会缩短新特性的周期。按照这种思路，PostCSS 运用CSSNext大大缩短了CSS新增特征的周期，但并不是所有的新特性都可以提前处理。对于更多的动态特性，比如自定义属性的新unit，目前polyfill就无法进行填充或转译，但大多数的JS API却可以很容易地被转译。Houdini API能够很好地解决这个难题，让我们像编写JS polyfill 一样轻松编写CSS polyfills。

Houdini 是W3C的一个新增工作组，他们的最终目标是让浏览器支持CSS特性。如果真能成功的话，这无疑是CSS发展史上最令人兴奋的时刻。你认为Houdini 的目标可行吗？

Houdini肯定会让CSS polyfill成为可能，这的确令人兴奋，我也很期待。不过我担心开发人员把Houdini 当作拐杖，不让浏览器实现某些功能。他们认为开发人员通过Houdini API总能编写出应对问题的库。我不希望CSS因为Houdini 的工作就停止进一步发展，我也不愿意看到CSS成为一个依赖大量库解决基本问题的“地狱”。

运用JavaScript代码编写HTML解决了很多问题，所以一些React.JS开发人员尝试把CSS和JavaScript两种语言结合起来，解决CSS存在的问题。你怎么看待JavaScript代码编写CSS的现象？

我认为，这主要是那些并不真正了解CSS，只想用JS代码解决一切问题的JavaScript开发人员的想法。“如果你只有一把锤子，看什么都是钉子。”这样做，只能让他们丧失掉大部分的潜在合作伙伴：有一半的HTML 和CSS 开发人员对JS不感冒。

不过，CSS工作组的成员也认识到CSS在范畴和封装方面的问题，正在积极讨论解决方案。

CSS已经从网页设计延伸到了出版行业，例如O’Reilly 已经开始尝试把CSS运用到出版流程。你认为CSS能胜任出版行业的要求么？基于出版行业的要求，W3C之后会对CSS做出相应的规范么？

CSS从一开始就是要设计成一门文档样式语言的，把CSS运用到出版行业也是必然的。实际上，CSS 之父 Bert Bos和Hakon Wium Lie，在11年前也就是2005年的时候，就运用CSS排版了《CSS：网页设计》这本书（）

当然， CSS要想和现有工具InDesign一样灵活，还需要很多工作要准备。在过去的几年里，我们已经取得了很大的进步。不过，网页比出版社的资源广，所以他们的声音更容易被CSS工作组了解到。出版行业是一个严肃的行业，我们会认真考虑添加的每一个新功能。