TPAC 的 CSS 工作组：CSS 有什么新变化？

上周，我参加了 W3C TPAC 以及那里的 CSS 工作组会议。 对规范进行了各种更改，并且进行了我认为网页设计师和开发人员感兴趣的讨论。 在本文中，我将稍微解释一下 TPAC 发生的事情，并展示我们在 TPAC 特别针对 CSS 讨论的内容的一些示例和演示。

什么是 TPAC？

TPAC 是 W3C 的技术全体会议/咨询委员会会议周。 作为 W3C 一部分的所有不同工作组有机会聚集在一个屋檐下。 该活动每年在世界不同的地方举行，今年在法国里昂举行。 在 TPAC，CSS 工作组等工作组有自己的会议，就像我们在一年中的其他时间一样。 但是，因为我们都在一个大楼里，这意味着其他群体的人可以更容易地作为观察者来，并且可以讨论跨工作组的利益。

TPAC 的与会者通常是一个或多个工作组的成员，致力于 W3C 技术。 他们要么是成员组织的代表，要么是特邀专家。 与 W3C 工作组的任何其他会议一样，在 TPAC 举行的所有讨论的记录都将公开提供，通常作为 IRC 在会议期间记录的日志。

CSS 工作组

CSS 工作组在 TPAC 和一年中至少两次其他场合会面； 这是我们每周电话的补充。 在我们所有的会议上，对规范提出的各种问题进行了讨论，并做出了决定。 由于能够与整个团队一起讨论这些问题，或者只是能够绕过白板或在屏幕上查看演示，因此有些问题保留为面对面讨论。

在任何会议（无论是面对面会议还是电话会议）中讨论某个问题时，相关的 GitHub 问题都会随讨论记录更新。 这意味着如果您有想要跟踪的问题，您可以为它加注星标并查看它何时更新。 完整的 IRC 会议记录也会发布到 www 风格的邮件列表中。

以下是我们讨论过的一些我认为您最感兴趣的内容。

CSS 滚动条

CSS 滚动条规范旨在提供一种标准的方式来设置滚动条的大小和颜色。 如果你有 Firefox Nightly，你可以测试一下。 要查看下面的示例，请使用 Firefox Nightly 并通过访问 Firefox Nightly 中的https://about:config启用标志layout.css.scrollbar-width.enabled和layout.css.scrollbar-color.enabled 。

该规范为我们提供了两个新属性： scrollbar-width和scrollbar-color 。 scrollbar-width属性可以采用auto 、 thin 、 none或length值（例如1em ）。 看起来好像可以从规范中删除length值。 可以想象，Web 开发人员可能会通过调整宽度来制作非常不可用的滚动条，因此最好让浏览器确定有意义的确切宽度，而不是显示细或粗滚动条。 Firefox 没有实现长度选项。

如果你使用auto作为值，那么浏览器将使用默认的滚动条： thin会给你一个细滚动条，而none将显示不可见的滚动条（但元素仍然是可滚动的）。

在支持 CSS 滚动条的浏览器中，您可以在演示中看到这一点：

scrollbar-color属性处理——正如你所期望的——滚动条颜色。 滚动条有两个部分，您可能希望独立着色：

• 拇指
  滚动时上下移动的滑块。
• 追踪
  滚动条背景。

scrollbar-color属性的值是auto 、 dark 、 light和<color> <color> 。

使用auto作为关键字值将为您提供该浏览器的默认滚动条颜色， dark将提供深色滚动条，无论是在该平台的暗模式还是自定义暗模式下， light平台的亮模式或自定义亮模式.

要设置自己的颜色，请添加两种颜色作为值，并用空格分隔。 第一种颜色用于拇指，第二种颜色用于轨道。 您应该注意颜色之间有足够的对比度，否则滚动条可能对某些人来说难以使用。

在支持 CSS 滚动条的浏览器中，您可以在演示中看到：

请参阅 CodePen 上 Rachel Andrew (@rachelandrew) 的 Pen CSS 滚动条：滚动条颜色。

纵横比单位

一段时间以来，我们一直在使用 CSS 中的 padding hack 来实现长宽比框，然而，随着网格布局和更好的内容调整方式的出现，在 CSS 中实现长宽比的真正方法已成为更紧迫的需求.

GitHub 上提出了两个与此要求相关的问题：

• 需要的纵横比单位
• 纵横比。

现在在 CSS Sizing 的 Level 4 中有一个规范草案，会议的决定是这需要在 GitHub 上进一步讨论，然后才能做出任何决定。 因此，如果您对此感兴趣，或者有其他用例，CSS 工作组会对您对这些问题的评论感兴趣。

:where()函数伪类

去年，CSSWG 决定添加一个伪类，其行为类似于:matches()但具有零特异性，从而使其易于覆盖，而无需人为地夸大后续元素的特异性来覆盖默认样式表中的某些内容。

:matches()伪类对您来说可能是新的，因为它是一个 4 级选择器，但是，它允许您指定一组选择器来应用一些 CSS。 例如，您可以编写：

 .foo a:hover, pa:hover { color: green; }

或使用:matches()

 :matches(.foo, p) a:hover { color: green; }

如果你曾经有一大堆选择器只是为了设置相同的规则，你会看到这将是多么有用。 以下 CodePen 使用前缀名称webkit-any和-moz-any来演示matches()功能。 您还可以在 MDN 上阅读有关 match() 的更多信息。

我们经常做这种选择器的堆叠，因此:matches()最有用的地方是在某种初始的默认样式表中。 但是，我们在覆盖这些默认值时需要小心，任何覆盖都是以确保它比默认值更具体的方式完成的。 正是出于这个原因，提出了零特异性版本。

会议讨论的问题是关于这个伪类的命名，你可以在这里看到最终的解决方案，如果你想知道为什么排除了各种名称，请查看完整的线程。 在 CSS 中命名非常困难——因为我们都将不得不永远忍受它！ 经过大量辩论，该小组投票决定将此选择器称为:where() 。

自那次会议以来，在我写这篇文章的过程中，有人提出了将matches()重命名为is()的建议。 如果您有任何强烈的感受，请查看问题并发表评论！

边距和填充的逻辑简写

关于命名事物，我过去曾在 Smashing Magazine 上写过有关逻辑属性和值的文章，请参阅“了解逻辑属性和值”。 这些属性和值提供流相关映射。 这意味着，如果您使用的不是水平从上到下的书写模式（例如英语），则边距和填充、宽度和高度等内容将遵循文本方向，并且与物理屏幕尺寸无关。

例如，对于实物保证金，我们有：

• margin-top
• margin-right
• margin-bottom
• margin-left

这些（假设为水平-tb）的逻辑映射是：

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

我们可以有两个值简写。 例如，要将margin-block-start和margin-block-end都设置为简写，我们可以使用margin-block: 20px 1em 。 第一个值表示块维度中的起始边，第二个值表示块维度中的结束边。

然而，当我们谈到四值速记margin时，我们遇到了一个问题。 该属性名称用于物理边距——我们如何表示逻辑四值版本？ 已经提出了各种建议，包括文件顶部的开关：

 @mode "logical";

或者，使用一个看起来有点像媒体查询的块：

 @mode (flow-mode: relative) { }

然后是关键字修饰符的各种建议，使用一些标点符号，或者创建一个全新的属性名称：

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

您可以阅读该问题以查看正在考虑的各种事项。 讨论的问题是，虽然逻辑版本很可能最终成为默认版本，但有时您会希望事情与屏幕几何形状相关； 我们需要能够在一个样式表中同时拥有这两个选项。 在 CSS 顶部设置@mode可能会造成混淆； 如果有人要复制和粘贴一大块样式表，它将失败。

我的偏好是具有某种关键字值。 这样，如果您查看规则，您可以准确地看到正在使用的模式，即使它看起来有点不雅。 这是预处理器可以为您处理的事情； 如果您确实希望所有属性和值都使用逻辑版本。

我们没有设法解决这个问题，所以如果您确实对其中哪些可能是最好的有想法，或者可以看到我们没有描述的问题，请在 GitHub 上评论这个问题。

网络平台测试讨论

在 CSS 工作组会议和非会议风格的技术全体会议期间，我参与了讨论如何让更多人参与编写 CSS 规范测试。 Web 平台测试项目旨在为所有 Web 平台提供测试。 这些测试然后帮助浏览器供应商检查他们的浏览器是否符合规范。 在 CSS 工作组中，目标是对已达到候选推荐 (CR) 状态的规范的任何规范性更改都应伴随测试。 这是有道理的，因为一旦规范在 CR 中，我们就会要求浏览器实现该规范并提供反馈。 他们需要知道规范中是否有任何更改，以便他们可以更新他们的代码。

问题是我们编写规范的人很少，所以规范编写者必须编写所有测试会减慢 CSS 的进度。 我们希望看到其他人编写测试，因为这是为 Web 平台做出贡献并深入了解规范如何工作的一种方式。 因此，我们开会思考如何鼓励人们参与这项工作。 我过去曾写过关于这个主题的文章； 如果您对为平台编写测试的想法感兴趣，请查看我关于“测试 Web 平台”的 24 种方式文章。

继续工作！

TPAC 已大大增加了我的个人待办事项清单。 然而，我已经能够获得关于规范编辑、测试写作的技巧，并制定了一个计划，以使多列布局规范（我是其中的共同编辑）恢复到 CR 状态。 作为一个不喜欢会议的人，我来看看这些面对面会议对于网络平台的价值，让我们这些为它做出贡献的人有机会分享我们个人正在开发的知识。 我觉得重要的是，然后将这些知识并在团队之外分享，以帮助更多的人参与开发和使用该平台。

如果您对 CSS 工作组的运作方式以及新的 CSS 是如何发明并最终在浏览器中产生兴趣感兴趣，请查看我在 2017 CSSConf.eu 的演示文稿“CSS 来自哪里？” 以及来自 fantasai 在她的帖子“W3C CSS 工作组的内部视图”中的信息。