我们希望您就一个建议的解决方案提供反馈意见，该解决方案可解决布局方法按照与文档来源无关的顺序排列项目的问题。
CSS 工作组正在努力解决这样的情况：布局方法可以按照与来源无关的顺序来排列项目，从而不影响文档的阅读顺序和焦点顺序。本文介绍了具体问题和建议的解决方案，我们非常期待收到您的反馈。
问题
HTML 文档的阅读顺序遵循源顺序。这意味着屏幕阅读器将按照来源中的布局来阅读文档，而使用键盘在文档周围移动的用户也会遵循源代码顺序。通常这是合理的，合理的文档来源顺序对于阅读模式内容、屏幕阅读器以及任何 CSS 受限的设备至关重要。但 CSS，尤其是 Flexbox 和网格，可以创建这样的布局，让布局定义与底层源不同的视觉阅读顺序。
例如，对 Flex 项使用 order 属性会更改布局顺序，但不会更改源代码中的布局顺序。
使用网格布局时，所选的布局方法可以混乱标签页顺序，例如在使用 grid-auto-flow: dense 时，这会创建项的随机布局顺序。
开发者还可以将项目放置在网格上，使其按照与源代码中指示的顺序不同的顺序来断开连接。
建议的解决方案
CSS 工作组正在提出解决此问题的方法，并希望开发者和无障碍社区就此方法提供反馈。
遵循具有 reading-order: auto 的随机布局
在创建随机布局顺序的情况下（例如，在网格布局中使用密集打包时），您可能希望浏览器遵循布局，而不是源顺序。为此，Flex 或网格项需要具有值为 auto 的 reading-order 属性。
以下 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 遵循非随机布局
在某些网格和弹性布局中，布局顺序易于理解。例如，在使用 order 属性对项目进行重新排序的 Flex 布局中，有一个明显的布局顺序由 order 属性决定。在其他布局中，理想的布局顺序并不明确，可能不止一种选择。因此，在采用非随机布局时，您需要向容器添加 grid-order-items 属性，并通过关键字值说明布局顺序的意图。
以下示例显示了使用 row-reverse 的 Flex 布局。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 提供反馈和审核。