Решение проблемы разметки CSS и отключения порядка исходного кода

Нам нужна ваша обратная связь по предлагаемому решению проблемы, связанной с методами компоновки, которые располагают элементы в порядке, не соответствующем исходному коду документа.

Rachel Andrew

Рабочая группа CSS работает над решением проблемы, когда метод компоновки может располагать элементы в порядке, не связанном с исходным кодом, а следовательно, и с порядком чтения и фокусировки документа. В этой статье объясняется проблема и предлагается решение, и мы будем рады вашим отзывам.

Проблема

Порядок чтения HTML-документа соответствует порядку в исходном коде. Это означает, что программа чтения с экрана будет читать документ так, как он представлен в исходном коде, и человек, использующий клавиатуру для перемещения по документу с помощью клавиши Tab, также будет следовать этому порядку. Обычно это логично, и разумный порядок в исходном коде документа имеет решающее значение для отображения контента в режиме чтения, для программ чтения с экрана и для любых устройств с ограниченными возможностями CSS. Однако CSS, и в частности flexbox и grid, могут создавать макеты, в которых порядок визуального чтения отличается от порядка в исходном коде.

Например, использование свойства order для элементов flex изменяет порядок в макете, но не порядок в исходном коде.

Щелкните по примеру и переключитесь между окнами с помощью клавиши Tab, чтобы увидеть, как порядок перехода по вкладкам отключается от порядка расположения элементов с помощью свойства `order`.

При использовании сетки (grid layout) выбранный метод компоновки может нарушить порядок перехода по вкладкам, например, при использовании grid-auto-flow: dense , который создает случайный порядок элементов в макете.

Щелкните по примеру и переключитесь между окнами с помощью клавиши Tab, чтобы увидеть, как порядок перехода по вкладкам нарушается из-за расположения элементов в сетке.

Разработчик также может вызвать это несоответствие, размещая элементы на сетке в порядке, отличном от того, который указан в исходном коде.

Щелкните по примеру и перемещайтесь по вкладкам, чтобы увидеть, как порядок перехода между вкладками отключается от порядка расположения элементов с помощью свойств размещения в сетке.

Примечание: Подробнее о проблеме можно узнать здесь:

• Flexbox и навигация с помощью клавиатуры несовместимы.
• Порядок отображения исходного кода HTML и порядок отображения CSS
• Видео: Сетка, перестановка контента и доступность.

Предложенное решение

Рабочая группа CSS предлагает решение этой проблемы и будет рада получить отзывы от разработчиков и сообщества специалистов по доступности относительно этого подхода.

Примечание: Обратите внимание, что названия свойств и значений, используемые в этом сообщении, могут измениться. В этом сообщении используются правила именования, которые, как мы надеемся, помогут в получении обратной связи.

Следование случайным макетам с reading-order: auto

В ситуациях, когда порядок элементов в макете задан случайным образом, например, при использовании плотной упаковки в сеточной компоновке, вам, вероятно, потребуется, чтобы браузер следовал заданному порядку, а не порядку в исходном коде. Для этого элементы flex-контейнера или сетки должны иметь свойство ` 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

В некоторых сеточных и гибких макетах порядок элементов легко понять. Например, в гибком макете, использующем свойство order для изменения порядка элементов, порядок элементов очевиден и определяется этим order . В других макетах идеальный порядок менее ясен, может быть несколько возможных вариантов. Поэтому при использовании нерандомизированных макетов необходимо добавить свойство grid-order-items к контейнеру, указав ключевые значения, объясняющие желаемый порядок элементов.

В следующем примере показана гибкая компоновка с использованием row-reverse . Элементы гибкой компоновки имеют reading-order: auto , а контейнер гибкой компоновки 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 является предпочтительным вариантом в случаях, подобных описанному в этом твите , поскольку это проще и быстрее, чем манипулирование DOM. Существует также сопутствующая проблема и предложение, выдвинутые против стандарта DOM, которые бы упростили этот тип изменения порядка.

Должны ли инструменты разработки применять эти свойства?

Инструменты для создания макетов, позволяющие пользователям создавать сеточную разметку путем перетаскивания элементов, должны по-прежнему побуждать пользователей создавать осмысленный исходный документ. Поэтому в большинстве случаев было бы целесообразнее переупорядочивать исходный текст в соответствии с порядком элементов макета, а не использовать эти свойства как ленивый способ решения проблемы несоответствия.

Пожалуйста, поделитесь своим мнением по этому предложению.

Мы очень заинтересованы в получении отзывов по этому вопросу. В частности, если у вас есть сценарий использования, который, по вашему мнению, этот подход не решит, или если у вас есть опасения по поводу доступности данного подхода, пожалуйста, сообщите об этом рабочей группе CSS.

There is an ongoing thread , which contains many use cases and thoughts on the approach. That thread is a great place to add any comments, and highlight potential issues with this proposal. Note that the current proposal is very different from my initial one that started the thread. Interested people might enjoy all the conversation that led to where we are today, as it's a good example of how proposals are worked though in the CSS Working Group to become something that can be implemented in browsers.

Изображение для превью предоставлено Патриком Томассо . Благодарим Криса Харрелсона, Таба Аткинса и Иэна Килпатрика за отзывы и рецензирование.