Темная тень DOM

Да, это именно то, что это значит.

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

Но не этот контент!

Конечно, спецификация не игнорирует это разделение. По сути, он предполагает различие между элементами, которые содержат текстовое содержимое или информационные атрибуты, и элементами, которые являются просто пустыми полями для создания визуальных частей, таких как большой палец ввода "range" Давайте назовем их элементами содержимого и вспомогательными элементами .

Так как часто виджеты имеют такое четкое различие между ними? Для примера ввода "range" Недавно я написал виджет слайдера для доступного видеоплеера, и его разметка выглядела так:

 <label for="slider-thumb">
  <button type="button" id="slider-thumb" 
    role="slider" aria-orientation="horizontal"
    aria-valuemin="0" aria-valuemax="120" 
    aria-valuenow="75" aria-valuetext="Time: 01:15">
    <span></span>
  </button>
</label>

Единственная часть этого слайдера, которую можно поместить в Shadow DOM, это <span><button> Сама <button>ARIA, которые предоставляют динамическую информацию для программ чтения с экрана и других технологий доступа.

Чтобы это работало с Shadow DOM, нам нужно переместить все атрибуты ARIA во внешний <label>tabindex Но это было бы менее доступно, потому что мы утратили бы нативную семантику (например, метка атрибута forменее полезно, потому что это означает, что виджет не может отправлять данные формы (поэтому нужен отдельный элемент управления формы, такой как скрытый ввод).

Но даже если бы это было хорошо — и даже если каждый создаваемый нами виджет имеет четкое и простое различие между содержимым и служебными элементами — контентная часть виджета все еще не инкапсулирована ; он по-прежнему уязвим к конфликтам имен и нежелательному наследованию CSS .

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

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

Brilliant! Целая группа пользователей уволена в одном простое предупреждение!

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

С этим требованием Shadow DOM предоставляет только половину решения ; и половина решения не является решением вообще.

В свет

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

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

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

Это можно выразить с помощью простого атрибута элемента:

 <div encapsulated="encapsulated">

HTML DOM будет интерпретировать это по-другому — это просто элемент с неотрисованным атрибутом, как и любой другой. Однако CSS DOM интерпретирует его как некий фрагмент документа, фактически говоря, что элемент и все, что внутри него, не наследуется от более высоких областей .

И мы уже можем делать наоборот — стили области видимости для поддерева — либо с помощью селекторов-потомков, либо, если вам действительно нужно, с помощью <style scoped><link><style>

Чтобы использовать этот инкапсулированный атрибут, мы могли бы по-прежнему использовать лучший способ управления и шаблонирования служебных элементов, но HTML — это неправильное место для этого. На самом деле, нам вообще не нужно определять пустые элементы — это функциональная необходимость только потому, что у нас нет другого способа определения презентационных поддеревьев — поэтому эту возможность следует добавить в CSS .

Другими словами, один элемент должен иметь возможность определять любое количество псевдоэлементов , а сами псевдоэлементы также определять псевдоэлементы. Что-то вроде этого:

 #mywidget::after
{
}
#mywidget::after + ::element
{
}
#mywidget::after > ::element
{
}
#mywidget::after > ::element + ::element
{
}

Который создал бы виртуальное поддерево как это:

 <div id="mywidget" encapsulated="encapsulated">
  Text content
  <after>
    <element></element>
    <element></element>
  </after>
  <element></element>
</div>

Определение этого материала в CSS подразумевает четкое и врожденное различие, которое не может не понять ни один разработчик — контент идет в HTML , презентация в CSS , просто так, как и должно быть.

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