有关于CSS的一些新东西

上个月 2018年TPAC会议 刚结束没多久，@Rachel Andrew在Smashing Magazine上面就发表了一篇文章《 The CSS Working Group At TPAC: What’s New In CSS? 》介绍了CSS中将会有的一些新东西，同时我们国内@安佳 大大也发了一篇有关于参加该 会议的总结 。就在这个月，@Rachel Andrew在瑞典.马尔默举办的2018年 Øredev 开发者大会 上分享了一个话题就是有关于 CSS的一些新东西 ，同时她还分享了另一个话题《 2019年布局有哪些 工具 包 》。我阅读了@Rachel Andrew在该会议上分享的两个话题，但今天主要想根据@Rachel Andrew分享的第一个话题做一些总结： CSS有哪些新东西 。希望对大家有所帮助。

先上@Rachel Andrew分享的PPT：

如何获取CSS的新特性

很多同学估计都有类似的问题，怎么才能第一时间获取到有关于CSS相关的新特性呢？有关于这个问题，并不是一个很复杂的问题，不过@Rachel Andrew还是围绕这个方面做了一些阐述。

CSS工作组 只是W3C工作组中的一个小组。CSS工作组一直坚持透明原则，它内部所有的交流都是公开的，并邀请公众来关注和参与讨论：

• 绝大多数的讨论都发生在工作组的邮件列表中： www-style 。这个邮件列表是公开布档的，欢迎任何人的参与
• 每周都会召开一次电话会议，时长一小时。该会议并不向非工作组成员开放，但会议会被记录在 W3C的IRC服务器 上的 #css 频道。这些会议也会整理出来发布到邮件列表中
• 还有每个季度会有一次面对面会议，也会记录下来。在获得工作组主席的许可之后，这类会议也通常会对观察员开放（就是旁听）

所有这些都是W3C进程的一部分，任何决定都是通过这样的方式来产生的。此外，那些真正负责把这些决定写成规范的人员叫作规范编辑。规范编辑可能是W3C的工作人员、浏览器开发者、相关专业的特邀专家，也可能是会员公司的职员，他们全职从事此项工作，为了共同利益去推进标准。

另外，在Github上专门有一个仓库 csswg-drafts 对CSS的一些提案提供了一些讨论的场地，大家对感兴趣的话题可以参与讨论，也可以从中获取到第一手相关资料。

正如 @小倩今年在CSS Conf大会上分享 的时候也提到过，W3C还是需要大家一起参与的，如果你感兴趣的话，可以按照下面这样的方式来参与：

• 如果你对某个特性有疑问，可以在 GitHub Issues中参与讨论
• 如果你有独道的想法，可以通过 WICG提出你的想法
• 如果你只想知道怎么用，简单一点的就 查阅MDN相关的文档
• 我想大家较为关心的是某个特性能不能用，针对这个可以在 web-platform-tests 上获得答案

如何理解规范的形成

任何一个规范的形成都是一个漫长的过程，到目前为止， W3C 对Web标准制定的 Web标准和草案 接近 1161 个，包括 WD 、 CR 、 PR 、 PER 、 REC 、 ret 和 Note 这 7 种：

• WD （Working Draft 工作草案） ：不稳定也不完整。目的是创建当前规范的一个快照，也能征求 W3C 和公众的意见
• CR （Candidate Recommendation 候选推荐标准） ：所有的已知 issues 都被解决了，向 implementor 征集实现；AC 正式审查，可能有三种结果：成为标准、返回工作组继续完善、废弃(此阶段的很有可能成为标准，且如有改动，则需给出改动原因)
• PR （Proposed Recommendation 提案推荐标准） ：从 CR 到 PR 需要全面的 test suite 和实现报告，以证明每个特性都在至少2款浏览器里实现了，意味着其质量足以成为REC。此时，W3C 成员再最后一次 review 下规范(一般不会有实质性的改动；若有，则只能再发布一个新的WD或CR)
• PER （Proposed Edited Recommendation 已修订的提案推荐标准）
• REC （Recommendation 推荐标准，通常称之为 standard，即事实标准） ：此时，就不会有太多变动了，当然依然可以收勘误。它可能成为:Edited Recommendation 编辑推荐标准。微小改动，然后生成推荐的 Revised Edition；Amended Recommendation 修订推荐标准。不增加新功能的实质性更改；SPSD Superseded Recommendation 被取代的推荐标准（缺少足够的市场相关性）
• ret （Retired 退役的)
• Note （Group Note 工作组说明） ：不打算成为标准的文档。已经停止使用了。通常记录规范以外的信息，eg.规范的用例及其最佳实践、解释规范被弃用的原因

对于CSS的每项规范大致都会经历以下几个过程：

• 编辑草案(ED) ：这是一项规范的初始阶段，可能非常粗糙。对这个阶段没有什么要求，也不保证它会被工作组批准。但它也是各个修订版本的必经阶段，每次变更都是先从一个 ED 中产 生的，然后才会发布出来
• 首个公开工作草案(FPWD) ：一项规范的首个公开发布版本，它应该准备就绪，以接受工作组的公开反馈
• 工作草案(WD) ：在第一个 WD 之后，还会有更多的 WD 出来。 这些 WD 会吸收来自工作组和更广阔的社区的反馈，一版接着一版小幅改进。浏览器的早期实现通常是从这个阶段开始的，厂商基本不太可能对更早阶段的草案提供实验性的支持
• 候选推荐规范(CR) ：这可以认为是一个相对稳定的版本。此时比较适合实现和测试。一项规范只有具备一套完整的测试套件和两个独立的实现之后，才有可能继续推进到下一阶段
• 提名推荐规范(PR) ：这是 W3C 会员公司对这项规范表达反对意见的最后机会。实际上他们很少在这个阶段提出异议，因此每个 PR 推进到下一阶段(也是最后一个阶段)只是时间问题
• 正式推荐规范(REC) ：一项 W3C 技术规范的最终阶段

用W3C上的一张图来简要的向大家展示一下一个CSS属性诞生的历程：

版本之争

随着前端社区开始有介绍 CSS Selectors Level 4相关的文章 开始，很多人把这个称之为 CSS4选择器 ，也在说CSS3还未成为规范，CSS4就要来了，真心学不动了。为此@Rachel Andrew特别花了一点时间阐述了：

CSS发展至今，将不会有CSS版本之称，只会有模块的Level一说

有关于这个话题，早在2016年@Rachel Andrew特意写了一篇文章《 Why there is no CSS4 - explaining CSS Levels 》做出相关的解释。

想想，这就是我与大神之间的差距！

针对这个问题，我在前几天写的一篇博文《揭开CSS的面纱》中也提到过：

由于CSS 的各个模块在近些年里以不同的速度在推进，我们已经越来越难以把这些规范以CSS3、CSS4这样的方式来划分了，而且这样也难以被大众理解和接受。

所以，大家以后不要再把CSS按CSS3或者CSS4来称谓了，我们应该改变以前的习惯，按功能模块发布的版本号来称呼他们。这样才不会给别人造成误解或困惑！

CSS 的一些新东西

开篇有点过长，咱们还是开始进入到真正的主题吧。@Rachel Andrew给我们分享了CSS的一些新东西：

• CSS Grid Layout & Subgrid
• CSS Box Alignment
• Gap
• Intrinsic Sizing Keywords
• Scroll Snap
• Scrollbars
• Shapes
• Conic Gradients
• Aspect Ratio Units
• Exclusions
• CSS Houdini
• Meet Feature Queries

接下来简单的聊一下，如果要深入的聊，估计都足够写本书来聊了。

CSS Grid Layout & Subgrid

CSS Grid Layout到目前为止已经有 Level 1 和 Level 2 两个版本。而Subgrid是属于CSS Grid Layout Level 2中的一部分。CSS Grid Layout中的很多特性都得到了很多主流浏览器的支持，而且@Rachel Andrew预计在2019年将会成为主流布局方式之一。话又说回来，CSS Grid Layout能这么成熟和得到浏览器的支持，离不开@Rachel Andrew的功劳，因为她一直在推进该特性的向前发展。

CSS Grid Layout对于开发者而言是一件好事，他将改变Web布局的模式，因为在CSS Grid Layout之前的布局模式都是一维布局，只有Grid是二维布局。Grid很强大，但其涉及到相关概念也特别的多，如果要彻底的了解或掌握她，还是需要花不少的时间去学习。当然最好是能多写一些案例。有关于这方面的介绍，这里就不做过多的详细介绍，感兴趣的话可以阅读站上有关于 CSS Grid Layout相关的文章 。

最近我自己也在拿 Flexbox和Grid做一个对比 ，希望通过这种对比的方式能更好的向大家介绍清楚Flexbox和Grid布局的差异性，能让大家更好的掌握Web布局的技巧。

CSS Box Alignment

CSS Box Alignment目前是 Level 3 ，主要用于控制各种布局方法中项目是如何对齐的。由于不同布局方法在对齐方面有不同的约束，因此Box Alignment的一些行为依赖于布局方法。该规范定义了三种对齐方式：

• 位置对齐 ： start 、 end 、 center 、 self-start 、 self-end 、 flex-start 、 flex-end 、 left 和 rgiht
• 基线对齐 ： baseline 、 first baseline 和 last baseline
• 分布式对齐 ： stretch 、 space-between 、 space-around 和 space-evenly

而我们接触最多的应该是Flexbox布局中控制Flex项目对齐方式用到的属性，比如：

.flex {
    display: flex;
    align-items: center;
    justify-content: center;
}

而在Grid布局中也可以用这样的方式来实现对齐：

.grid {
    display: grid;
    align-items: start;
    justify-content: space-between;
}

也就是说，以后不管是在Flexbox布局还是Grid布局中，控制元素对齐的方式都将会通过该规范中的一些特性来完成。而该规范中提到的特性不仅仅是上面提到的那部分。 更详细的可以阅读相关规范 。

要彻底理解CSS Box Alignment规范中提到的特性，还需要对CSS的一些基础特性要有彻底的了解，不然只能理解其表面上的特性。

有关于这方面相关的特性介绍，给大家推荐 @Chen Hui Jing 在 2018年的Btconf Berlin上分享的视频 ：

对应的PPT可以点击这里阅读 。

如果还想更深入的了解有关于CSS Box Alignment的话，下面这几篇文章或许对你有所帮助：

• CSS Box Alignment
• Box Alignment Cheatsheet
• 网格布局中的盒模型对齐
• 对齐flexbox容器中的flex元素
• Demystifying CSS alignment

Gap

在Web布局中总是避免不了控制区域间的间距，比如早前的Grid Framework就是通过 margin 或 padding 来控制。而在 CSS Multi-column Layout Module Level 1 中使用属性 column-gap 来控制列与列之间的间距：

但在Flexbox布局中，如果想要控制Flex项目之间的间距时，大部分还是通过 margin 之类来完成，当然在容器有可用空间时，还会使用其对齐系统来控制间距。而CSS Grid 布局有点类似于多列布局一样，有专门的属性( grid-gap 、 grid-column-gap 和 grid-row-gap )来控制网格轨道的大小：

但不久之后，不管是我们熟悉的Flexbox布局还是不太熟悉的网格布局，甚至是多列布局中，控制Flex项目（网格轨道、列）间距，可以统一使用 gap 、 row-gap 或 column-gap ，其中 gap 是 column-gap 和 row-gap 两属性的简写属性。

.grid {
    display: grid;
    grid-template-columns: repeat(3, 1fr);
    column-gap: 20px;
    row-gap: 20px;
}

.flex {
    display: flex;
    flex-wrap: wrap;
    column-gap: 20px;
    row-gap: 20px;
}

Intrinsic Sizing Keywords

Intrinsic Sizing Keywords指的是 CSS Intrinsic & Extrinsic Sizing Module Level 3 中指定盒子大小的属性。在CSS中指定一个盒子（即元素）大小都知道可以用 width/height 、 min-width/height 、 max-width/height 等属性。而这些属性可接受的值常常是 auto 、 none 、 inherit 、 initial 、 unset 或者带 <length> 单位的数值。事实上，除了这些属性值之外，我们还可以使用其他的一些关键词来设置盒子的大小。

• min-content
• max-content
• fit-content

Scroll Snap

CSS Scroll Snap Module Level 1 是什么？我习惯性把其称为 CSS滚动捕捉 。那什么又是滚动捕捉呢？比如说这样的一个效果：“将一个元素锁定在滚动视窗之中”。以前实现这样的一个效果，就算是使用原生的JavaScript来实现，也不是一件轻易的事情。该模块的出现就能较轻易的实现：

通过在 x 以及 y 轴上定义“捕捉点”（Snap Points）来控制滚动容器的滚动行为。当用户在水平或垂直方向滚动时，利用捕捉点，滚动容器会捕捉到内容区域的某一点。

Scroll Snap Points主要提供了以下几个属性：

• scroll-snap-type ：定义在滚动容器中的一个snap点如何被严格的执行
• scroll-snap-type-x ：定义在滚动容器中水平轴上snap点如何被严格的执行
• scroll-snap-type-y ：定义在滚动容器中垂直轴上snap点如何被严格的执行
• scroll-snap-coordinate ：结合元素的最近的祖先元素滚动容器的 scroll-snap-destination 定义的轴，定义了元素中 x 和 y 坐标偏移的位置。如果元素已经变型，snap坐标也以相同的方式进行变型，为了使元素的snap点向元素一样被显示。
• scroll-snap-destination ：定义滚动容器的可视化viewport 中元素snap点的 x 和 y 坐标位置
• scroll-snap-points-x ：定义滚动容器中内容的snap点的水平位置
• scroll-snap-points-y ：定义滚动容器中内容的snap点的垂直位置
• scroll-snap-align ：元素相对于其父元素滚动容器的对齐方式。它具有两个值， x 和 y 。如果你只使用其中的一个，另外一个值默认相同
• scroll-snap-padding ：与视觉窗口的滚动容器有关。工作原理也相近与正常的内边距，值设置一致。此属性具有动画效果，所以如果你想要对齐snap点进行滚动，这将是一个很好的而选择

有关于这方在更详细的介绍建议阅读下面这些文章：

• Well-Controlled Scrolling with CSS Scroll Snap
• 提前思考CSS Scroll Snap Points
• CSS Scroll Snap Points简介
• CSS Scroll Snap Points规范
• Well-Controlled Scrolling with CSS Scroll Snap
• CSS Scroll Snap: What Is It? Do We Need It?
• Intuitive Scrolling Interfaces with CSS Scroll Snap Points
• Swipe Views with CSS Snap Points: Building a More Efficient Mobile Web Navigation
• Get up to speed with scroll snap points

Scrollbars

CSS Scrollbars Module Level 1 给开发者提供了自定义容器滚动条的个性化样式。在Webkit内核提供了 -webkit-scrollbar （由七个伪元素）属性，可以轻易的帮助我们实现自定义（个性化）滚动条UI风格。

• ::-webkit-scrollbar ：整个滚动条
• ::-webkit-scrollbar-button ：滚动条上的按钮（下下箭头）
• ::-webkit-scrollbar-thumb ：滚动条上的滚动滑块
• ::-webkit-scrollbar-track ：滚动条轨道
• ::-webkit-scrollbar-track-piece ：滚动条没有滑块的轨道部分
• ::-webkit-scrollbar-corner ：当同时有垂直和水平滚动条时交汇的部分
• ::-webkit-resizer ：某些元素的交汇部分的部分样式（类似 textarea 的可拖动按钮）

基于七个伪元素，在Webkit内核下可以实现类似下面这样个性化的滚动条UI风格：

而 CSS Scrollbars Module Level 1 模块提供了新的CSS属性 scrollbar-color 和 scrollbar-width 可以来设置滚动条颜色和宽度：

Shapes

Shapes最早的身影是在 CSS Exclusions and Shapes Module Level 3 出现的，后来才独立出来成为一个模块 CSS Shapes Module Level 1 。该模块提供的特性可以让开发者打破以前那种规规矩矩的页面布局。可以轻易的实现类似下图这样的Web布局效果：

有关于Shapes具体的使用可以参阅下面相关文章：

• CSS Shapes
• Take A New Look At CSS Shapes
• CSS Shapes 中文教程

Conic Gradients

Conic Gradients最早是由 @Lea Verou 提出的，而且还为其写了一个 Polyfill 。是一个绘制圆锥渐变效果的一个属性。

上面只是其最简单的一些效果，他能做的事情更多，比如Codepen上收集到的有关于 conic-gradient 的效果就很强大：

值得庆幸的是， conic-gradient 属性也被纳入到了 CSS Image Values and Replaced Content Module Level 4 体系，不久的将来就可以像 lineaar-gradient 、 radial-gradient 、 repeating-linear-gradient 和 repeating-radial-gradient 一样的使用。另外除了 conic-gradient 之外还有 repeating-conic-gradient 属性，这样一来，渐变的特性就更强大了。

有关于 conic-gradient 更多的介绍可以阅读下面的这些文章：

• conic-gradient
• Introduction to Conic Gradients in CSS
• How to Create CSS Conic Gradients for Pie Charts and More
• 神奇的 conic-gradient 圆锥渐变
• 3种纯CSS实现中间镂空的12色彩虹渐变圆环方法

Aspect Ratio Units

在Web布局中，有的时候会对某个区域特别是图片要根据宽高比进行处理。 宽高比 在影视制作中又被称之为 长宽比 ，指的是一个视频的宽度除以它的高度所得到的比例，通常表示为 x:y 或 x × y ，其中的冒号和叉号表示中文的“比”之意。目前，在电影工业中最常被使用的是anamorphic比例（即 2.39:1 ）。传统的 4:3 仍然被使用于现今的许多电视画面上，而它成功的后继规格 16:9 则被用于高清晰度电视或数字电视上。常见的比例：

以往实现这样的效果都是依赖于其他的手段来实现，比如说把容器 height 设置为 0 ，然后将 padding-top 或 padding-bottom 设置为宽高比例的百分值。也可以通过 padding 和 calc() 、 padding 和CSS自定义属性等来实现。有关于这方面的介绍可以阅读下面这几篇文章：

• CSS实现长宽比的几种方案
• 容器长宽比
• Web中如何实现纵横比
• Flexible Images

为了让广大开发者能更好的处理这样的效果，CSS在 CSS Intrinsic & Extrinsic Sizing Module Level 4 模块中提供了一个长宽比的单位： aspect-ratio 。只不过这个属性还没有成为规范。不过大家对这个属性有何看法的话，可以通过www-style@w3.org与CSSWG联系。

Exclusions

Exclusions不好怎么翻译，以免造成错误的翻译，还是直接称之为Exclusions吧。那么Exclusions指的是什么呢？我还是用一张图来给大家做解释吧。

CSS Exclusions 就是致力于解决文本围绕图片（当然也可以是其他的元素）方式。它看上去类似于CSS Shapes，但又和CSS Shapes有很大的区别，它不需要依赖浮动，也不管是否设置了 position 的值为 absolute 、 relative 或者 fixed 。允许内容围绕一个内联元素。如上图所示。

CSS Exclusions 模块引入了两个新属性和值：

• wrap-flow ：设置Exclusion区域以及内容围绕的方式
• wrap-margin ：设置Exclusion区与周边围绕区域的间距

是不是很有意思，有关于其更深入的介绍建议花点时间阅读下面的文章：

• CSS Exclusions:让布局变得更有意思
• The future of CSS layouts 【 译文 】
• CSS Exclusions and Grid Layout
• CSS exclusions with Queen Bey

CSS Houdini

CSS Houdini 是由一群来自 Mozilla, Apple, Opera, Microsoft, HP, Intel, IBM, Adobe 与 Google 的工程师所组成的工作小组，志在建立一系列的 API，让开发者能够介入浏览器的 CSS engine 操作，带给开发者更多的解決方案，用来解决 CSS 长久以来的问题：

• Cross-Browser issue
• CSS Polyfill 的制作困难

简单的来说，CSS Houdini是通过JavaScript来扩展CSS。另外，有兴趣的读者可以直接从这里 CSS Houdini Drafts 看详细內容。

从@安佳分享的文章中可以获知，今年的 TPAC会议上 ，CSS Houdini有两处改动：

• CSS Layout 的 API 做了调整，比较重大的改动有：API 是基于 async 函数，而不是 generators 了( 详见 Run a Work Queue );之前返回 dictionary ，现在是返回带有 dictionary 的 FragmentResult 构造函数;传给 layout 的 Edges 对象现在也会包含滚动条的 padding
• CSS Animation Worklet 升级为 FPWD

写这篇文章的时候，CSS Houdini具体的进展如下：

有关于更多的介绍或资讯可以参考下面的链接：

• Is Houdini ready yet? 实时关注浏览器的支持情况、及标准的推进情况
• Houdini Samples 通过实例，非常直观的感受 Houdini 的功能
• CSS Houdini
• CSS Houdini Experiments
• Houdini: Demystifying CSS
• Houdini: Maybe The Most Exciting Development In CSS You’ve Never Heard Of
• Playing with Houdini CSS, Part One — Introduction and PaintAPI
• Playing with Houdini CSS, Part Two — Typed OM
• CSS Houdini 教程

向大家特别推荐一个视频，@Sam Richard 分享的 《 Magic tricks with Houdini 》：

Meet Feature Queries

这里提到的是CSS的查询功能，满足条件的查询功能。在 CSS条件查询规范 （ CSS3 Conditional Rules Specification ）提供了 @supports 、 @media 和 @viewport 相关属性。而其中 @supports 作用就是用来 查询浏览器是否支持CSS的特性 。比如：

@supports 使用起来很简单，这里就不做过多阐述，有关于这方面更多的介绍可以阅读下面的文章：

• CSS3条件判断： @supports
• 说说CSS中的 @supports

其他

@Rachel Andrew在Smashing Magazine上面就发表了一篇文章《 The CSS Working Group At TPAC: What’s New In CSS? 》中还提到了其他的一些特性在上文中没有提到的，比如说伪类 :where() 和逻辑属性之类的。有关于逻辑属性和值的了解，我也是初次接触不多，前段时间整理了一篇相关的文章，感兴趣的同学可以阅读《 理解CSS的逻辑属性和值 》一文。

总结

上面是我自己对PPT的一些理解以及做出的相关整理。大部分涉及到的只是CSS的部分。对于前端开发者要获取的不仅仅是CSS的一些新特性，如果你还可更轻易的获取一些相关信息，可以通过 Web API Links 来进行了解。

如果你有其他的一些想法或经验，欢迎在下面的评论中与我们一起分享。