与 Tab Atkins 的五问

Avatar of Chris Coyier
Chris Coyier

DigitalOcean 为您旅程的各个阶段提供云产品。立即开始使用 $200 的免费积分!

Tab Atkins (Twitter) 是 CSS 工作组的成员,也是 W3C 其他几个工作组的贡献者。他在 Google Chrome 团队为 Google 工作。浏览器和规范是我们行业的骨骼和血液,所以 Tab,嗯,是一个骨科医生,或者类似的东西。我在下面询问 Tab 关于所有这些事情,以及更多。

*Chris: 作为规范编写者,您在思考 CSS 的新想法时会考虑哪些事情?我知道您在编写列表规范时深入考虑了语言。对于速度或实现难度等事情呢?有没有对 CSS 语言来说是好的,但对浏览器来说很糟糕或不切实际的事情?

Tab: 在思考 CSS 的新想法时,我会考虑很多事情。首先也是最重要的是,这个新想法是否有助于作者。如果没有,就没有理由进一步追求这个想法。在 Google 雇佣我全职从事规范工作之前,我是一名全职 Web 开发人员,所以我还积压了很多事情,如果我在以前的工作中有了这些事情,就会很有帮助。

另一个非常重要的考虑因素是新想法将如何影响 CSS 作为一种语言。我尝试以与现有功能一致的方式设计新功能,并且预测与未来的新功能保持一致。有时这会产生新的想法,而不是仅仅过滤掉现有想法,通常以我可以暴露出来的新旋钮的形式,用于控制当前是魔法的东西。例如,列表 3 中的 marker-attachment 属性 部分来自于我对现有浏览器对标记行为的测试。事实证明,这种控制对于国际化也很有用,当列表项中包含混合方向时。

最后一个观点的衍生是国际化。CSS 2.1 做出了很多设计决策,这些决策基于对像英语这样的水平从左到右的语言的假设。很明显,它是由说英语或其他西欧语言的人编写的。有一些让希伯来语或阿拉伯语等 rtl 语言有所改善,但对于日语等垂直语言却没有。我们努力更加努力地让所有这些语言在我们较新的规范中尽可能自然地工作。例如,Flexbox 规范中 ‘flex-flow’ 的值会自动尊重书写模式和方向,但使用自然听起来的名字(“row” 和 “column”),这样作者就不必费心去思考它们。很多可以将其描述或值中使用 ‘left’ 或 ‘right’ 的属性,现在则改用 “start” 或 “end”,它们会根据元素的语言是 ltr 还是 rtl 自动翻转(我们将这些类型的值称为“逻辑方向”,而不是“物理方向”,比如 ‘left’)。

速度和可实现性很重要,但从来都不是首要考虑因素。我通常假设浏览器会想出如何做任何必要的事情,只有在它们反驳时才会缩小范围。过去,我多次对一些我认为肯定会遭到否决的事情的易用性或速度感到惊讶,也对一些我认为肯定会容易或受欢迎的事情的普遍批评感到惊讶。

最后,每个规范都有其自身的一系列问题,我需要担心。正如您提到的,在编写 Lists 规范时,我非常关注语言。这贯穿整个规范,从像预定义列表样式的大量清单这样的明显方面,到像前面提到的 ‘marker-attachment’ 属性这样的不太明显的事情,这个想法来自于我参加的一个为期两天的会议,主题是修复 HTML 和 CSS 中的国际化问题。在编写规范时,总有一大堆领域特定知识需要我吸收。

*Chris: 我知道您赞成“拥有自己的数据”这个理念。例如,不使用第三方服务来处理博客上的评论,因为这些数据将由第三方拥有,而不是您。您将这个理念贯彻到什么程度?这个理念来自哪里?

Tab: 我现在实际上没有处理我的博客上的任何评论,因为我还没有抽出时间编写对它的支持。^_^ 但是是的,我原则上拒绝将我的内容交给第三方服务。我从 Tantek Çelik 那儿了解到这个想法,他是一个全能的好人,很早就加入了 Twitter,因此能够获得 27 个单字母用户名之一(@t,有兴趣的可以看一下)。

如果你回顾历史,你会发现人们生活中的大量内容因第三方服务关闭而丢失。一个明显的例子是几年前的 Geocities 关闭。不过,还有很多不为人知的例子,比如失败的社交网络或博客平台,它们只是到了生命周期结束。如果你将你的内容托管在别人的服务器上,你就依赖于他们永远存在。当他们不可避免地关门大吉时,他们会带着你的数据一起离开。如果你拥有自己的数据,并将其托管在你自己的域名和服务器上,你就没有那么容易成为别人失败的商业计划的受害者。

不过,我并没有把这个理念贯彻到极致——有时我会屈服于便利性。我让 Twitter 托管我所有的推文,因为我认为它们是短暂的,如果 Twitter 明天关门大吉,我也不会错过我的旧推文。我让 Gmail 处理我的邮件,因为它实在是太棒了,而且我相信 Google 会存在一段时间。(此外,他们提供便捷的数据导出功能,所以当他们确实关门大吉时,我应该能够以我能够使用的格式获取我的数据。)Tantek 则走得更远。他运行着一个定制的博客平台,名为 Falcon,它托管了他几乎所有的内容,包括推文等,然后将其同步到 Twitter 等第三方。我希望最终能够增强我自己的博客平台来做这种事情,但我还没有抽出时间来集中精力做这件事。

即使像托管我自己的评论而不是让 Disqus 托管它们,也并没有把事情做得足够远。今年早些时候,Tantek 举办了第一届 IndieWebCamp,这是一个为期两天的开发营,专注于拥有自己的数据的概念。那里最有趣的讨论环节之一是关于发布/订阅系统的,以及我们如何利用它们来让评论者在我们的博客文章上拥有自己的评论。我们已经有了像 pingbacks 这样的糟糕版本,但如果你可以在 Twitter 或 Facebook 或你自己的博客上回复别人的博客文章,并让它显示在博客上呢?如果其他人可以继续回复你的评论,并将整个内容集中显示在帖子下面呢?我们拥有所有可以实现这一点的技术,而且一些非常聪明的人正在努力让它变得容易实现。

拥有自己数据的最后一个非常重要的方面是优先使用众所周知的基于文本的格式。去年,我放弃了 mySQL,转而使用为我的网站定制的基于 JSON 的数据存储。它不如 SQL 强大,效率也不如 SQL 高,但是你知道吗?我不需要那么强大的功能。 我不是在运行一个拥有数万次访问量的庞大企业网站。我确实需要的是能够轻松地备份我的数据,更重要的是,无论未来哪些技术已经流行或过时,都能恢复这些数据。即使 JSON 突然被大量拒绝,我们也永远能够解析 JSON,因为它太简单了。我用 Markdown 编写我的帖子,并将它们转换为 HTML,这也是因为这两种格式都很有名,而且即使在未来变得不受欢迎,也仍然很容易解析。在我力所能及的范围内,我的数据都没有存储在专有格式中,因为那样的话,我就会受制于拥有该格式的公司。在某些情况下,我必须屈服于效率,并使用二进制格式,例如存储图像或视频,但我会选择一个开放的、众所周知的格式,因为这样我更有可能在未来找到这些格式的解码器。

*Chris: 你直接为 Google 工作。从事 Web 标准的工作不是一件直接有利可图的事情。这是否是一种简单的宏大思考,比如:“Web 标准对 Web 来说是好的,对 Web 有利的事情对 Google 也有利。” 还是有更多的原因?

Tab: 不,你基本上说对了。请记住,我们的企业格言是“不作恶”,因此我们的赚钱行为都是秉持这种精神进行的。我们开发了 Chrome(并将其开源!),仅仅是为了开发一个更好的浏览器(好的),这对用户有利(更多的好!),最终对 Google 有利(赚钱)。

良好的 Web 标准让 Web 变得更好。如果原生应用更容易编写,或者更漂亮,或者提供了 Web 没有的功能,作者就会编写原生应用,而不是网页。在原生应用上卖广告比较困难,因此 Google 为我从事 Web 标准工作提供资金,帮助弥补这些不足,让 Web 成为编写应用的最佳场所。

请注意,我的实际工作独立于 Google 可能会为其其他项目特别想要的任何事情。例如,我们各种 Web 应用,比如 Gmail 或 Docs,只是 Web 上任何其他大型应用的新功能的使用案例。我做我认为对作者和 Web 最好的事情,这会让所有人的船都浮起来。

*Chris:Dart 首次发布时,人们将其与 JavaScript 进行了比较,普遍的观点是“JavaScript 已经赢了”。 我相信 Dart 团队没有忽视 JavaScript 拥有更多浏览器支持的事实。 你怎么看?

Tab: 我个人认为,现在试图取代 JavaScript 是荒谬的。 普遍的观点是正确的——除非出现重大失误或几年内完全停止功能更新,否则 JavaScript 已经赢了。

也就是说,我认为 Dart 最终将在许多方面非常有价值。 我们可以在无数个小细节上让网页对作者来说更友好,但每个细节本身价值不大,很容易被拒绝。 只有当你想象它们共同发挥作用时,你才能看到它们巨大的价值。 我和其他 Google 内部的 JS 开发者,比如 Alex Russell 和 Erik Arvidsson,与 Dart 团队密切合作,重新设计了 Dart 的 DOM API,使它们更小、更理智,并且与语言的其他部分更一致。 例如,当你获取元素子节点的列表时,它在 Dart 中是一个真正的 List(类似于 JS 的 Array),而不是缺少所有有用 List 函数的特殊 NodeList 类型。 API 的其他部分返回合适的 Maps 或 Sets,原因相同。 这意味着你不需要记住一组自定义命名、低效的 DOM 函数或属性——你可以直接重用你已经掌握的所有知识。 由于这种设计贯穿整个 DOM API,因此其益处更加清晰,我们可以利用它来帮助推广 JavaScript DOM API 的相同改进。

除此之外,Dart 也旨在用作服务器端语言,类似于在 Node 中运行 JS。 这样做没有任何问题——服务器端空间非常广阔,不像客户端语言那样受到兼容性和协调的限制。

*Chris: 在软件开发中,关注功能膨胀是明智的。 你不能永远添加新功能,而不让软件变得更糟。 它可能会变得更难学习、更难解释、更难让功能直观且易于发现,以及运行速度更慢(仅举几例)。 你是否担心 CSS 会出现这种情况?

Tab: 是的,一直都有。 我在 CSSWG 中以追求许多新功能和语法而闻名,但我始终意识到膨胀问题。 然而,这种担忧与其他担忧直接竞争,比如确保网页能够与原生应用程序相匹配,所以我一直都在权衡利弊。

与直觉相反,有时添加新功能会使事情简单,前提是设计得当。 以 CSS 布局为例。 我是一位老手,精通于按照自己的意愿弯曲 HTML 和 CSS,并让语义化标记与我收到的 Photoshop mockup 相匹配。 这些技能来之不易,我知道(从帮助许多其他开发者中得知),并非每个人都像我一样精通它。 你不应该为了制作一个有吸引力、响应式的网站而成为天才,但如今这基本上是必需的。 这就是为什么你会看到如此多的布局框架的原因。

我们在 CSS 中通过设计新的布局模型来解决这个问题。 块级布局和浮动是为文档设计的,而不是为应用程序设计的,这就是使用它们如此痛苦的原因。 Flexbox 和 Grid Layout 是两个协同尝试,旨在创建适合应用程序的布局模型。 我与微软密切合作(他们为 Flexbox 提供了我的共同编辑,并且是 Grid 的主要推动者),以保持规范同步,以便你在一个模型中学习的概念可以在另一个模型中重复使用。

我们尝试保持事情更简单的另一个方法是,将那些更适合其他语言的功能委托给其他语言。 我们可以在 CSS 中添加很多目前正在 JavaScript 中实现的功能。 我们已经接受了一些可以提供真正益处的功能,比如 Transitions 和 Animations,但仍然有很多功能 JS 更适合。 SVG 是另一个例子。 同样,当我们可以提供真正益处时,比如更简单、更紧凑的 linear-gradient() 和 radial-gradient() 函数,而不是 <linearGradient> 和 <radialGradient> 元素,我们将直接将功能复制到 CSS 中。 但如今,我们通常会直接使用 SVG,并为其定义一个简单的接口。 例如,Filters 规范具有一组预定义的滤镜函数,语法简单,但允许 SVG 使用现有的 SVG 滤镜元素来处理更复杂或更强大的滤镜,并且只提供了一种指向它们的途径。 另一个例子是 Image Values 中的 element() 函数,它可以直接指向 SVG 画笔源(如渐变或图案)并原生使用它。 这在现在有些用处,但随着 SVG2 添加网格渐变等功能,它将在未来变得更加强大。 我也是 SVG 工作组的成员,因此我对未来的发展方向以及如何调整 CSS 以更有效地利用它有很好的了解。

*Chris: 谢谢 Tab!