我们希望您就一项针对布局方法按与文档来源无关的顺序排列项的问题提出的解决方案提供反馈。
CSS 工作组正在努力解决以下情况：布局方法可以按与来源断开连接的顺序排列项，因此与文档的阅读顺序和焦点顺序断开连接。本文将介绍该问题和建议的解决方案，欢迎您提供反馈。
问题
HTML 文档的阅读顺序遵循源代码顺序。这意味着，屏幕阅读器会按照文档在来源中的布局来读取文档，而使用键盘在文档中按 Tab 键浏览的人也会遵循该来源顺序。通常情况下，这种做法是合理的，而且合理的文档来源顺序对于阅读模式下的内容呈现、屏幕阅读器以及任何 CSS 受限的设备都至关重要。不过，CSS（尤其是 flexbox 和网格）可以创建布局，其中布局定义的视觉阅读顺序与底层来源不同。
例如，对 flex 项使用 order 属性会更改布局顺序，但不会更改来源中的顺序。
使用网格布局时，所选的布局方法可能会打乱标签页顺序，例如使用 grid-auto-flow: dense 时，该方法会创建随机的商品布局顺序。
开发者还可以通过以与来源中规定的顺序不同的顺序将商品放置在网格中来导致此断开连接。
建议的解决方案
CSS 工作组正在为此问题提出解决方案，并希望开发者和无障碍社区就此方法提供反馈。
使用 reading-order: auto 遵循随机布局
在创建随机布局顺序的情况下（例如在网格布局中使用密集打包时），您可能希望浏览器遵循布局顺序，而不是源代码顺序。若要实现此效果，弹性或网格项需要具有 reading-order 属性，且值为 auto。
以下 CSS 会导致阅读顺序遵循因 grid-auto-flow: dense 而紧密排列的项的放置位置。
.cards {
display: grid;
grid-auto-flow: dense;
}
.cards li {
grid-column: auto / span 2;
reading-order: auto;
}
使用 reading-order-items 遵循非随机布局
在某些网格布局和 flex 布局中，布局顺序很容易理解。例如，在采用 order 属性对项进行重新排序的 flex 布局中，order 属性会明确指定布局顺序。在其他布局中，理想的布局顺序不太明确，可能有多个选择。因此，在采用非随机布局时，您需要向容器添加 grid-order-items 属性，并使用关键字值说明您对布局顺序的意图。
以下示例展示了使用 row-reverse 的弹性布局。Flex 内容具有 reading-order: auto，而 Flex 容器具有 reading-order-items: flex flow，这表示我们还希望阅读顺序遵循 flex-flow 方向，而不是遵循视觉顺序（我们可以使用 flex visual 来表示视觉顺序）。
.cards {
display: flex;
flex-flow: row-reverse;
reading-order-items: flex flow;
}
.cards li {
reading-order: auto;
}
在下一个示例中，我们使用 grid-template-areas 创建了一个网格布局，并将项放置在与源顺序不同的布局顺序中。reading-order-items 属性用于指示我们应遵循布局顺序，先遍历每一行，然后再前进到下一行。（grid column 表示相反方向）。
.wrapper {
display: grid;
grid-template-columns: repeat(6, minmax(0, 1fr));
grid-template-areas:
"a a b b b b"
"c c d d e e"
"f f g g h h";
reading-order-items: grid rows;
}
.a {
grid-area: a;
reading-order: auto;
}
这是否意味着来源顺序无关紧要？
否，来源顺序仍然很重要。此功能仅应在阅读顺序可能与来源不同的特定情况下使用。例如，当使用可能会导致此断开的布局方法（例如密集网格打包）时，或者当在某个断点处采用不同的布局顺序更有意义时。
使用这些属性时，请按以下顺序创建源文档：如果网页在没有 CSS 的情况下呈现，则该顺序应有意义。仅在需要这些属性的位置和断点处添加它们。
创作工具是否应应用这些属性？
允许用户通过拖放元素来创建网格布局的创作工具仍应鼓励用户创建合理的源文档。因此，在大多数情况下，根据布局顺序重新排序来源会比使用这些属性作为处理断开连接的懒惰方式更合适。
请就此提案分享您的反馈
我们非常希望就此功能收集反馈。特别是，如果您有认为此方法无法解决的用例，或者对该方法存在无障碍功能方面的疑虑，请告知 CSS 工作组。
有一个正在进行的讨论串，其中包含许多用例和有关该方法的想法。您可以在该帖子中添加任何评论，并指出此提案可能存在的问题。请注意，当前提案与我发起此主题讨论的初始提案有很大不同。感兴趣的人可能会喜欢我们今天所取得的成就背后的所有对话，因为这很好地展示了 CSS 工作组如何处理提案，使其最终成为可以在浏览器中实现的内容。
缩略图图片由 Patrick Tomasso 提供。感谢 Chris Harrelson、Tab Atkins 和 Ian Kilpatrick 提供反馈和审核。