Подробнее о `детали`

Много болтовни вокруг старого <details> и <summary> элементы в последнее время! Я видел Леа Веру недавно написала в Твиттере наблюдение об элементе display поведение, и это как бы распалось на большее количество наблюдений и заметок об использовании от людей, включая возобновление обсуждения на ли <summary> должно быть разрешено содержать интерактивные элементы или нет.

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

Можем ли мы изменить отображение элементов, вложенных в <details> элемент?

В приложении, которое я создаю, я использую для панелей, но столкнулся с некоторой странностью размеров.
Флексбокс: https://t.co/noZvxAN35G
Сетка: https://t.co/pis0lPjvXk
Сначала я подумал, что это ошибка, но все три движка с этим согласились. В таблице стилей UA нет ничего для кажется, объясняет это.

— Леа Веру (@LeaVerou) 28 августа 2022

Супер странно! Если мы взломаем DevTools, таблица стилей пользовательского агента сообщит нам: <details> отображается как блочный элемент.

Обратите внимание на необходимое <summary> элемент и два дополнительных <div>он там. Мы можем переопределить display, правильно?

Чего мы можем ожидать, так это того, что <details> теперь имеет явную высоту 40vh и три строки, где третья строка занимает оставшееся пространство от первых двух. Так:

Ух, но третий ряд не... делает... этого.

Очевидно, мы имеем дело с контейнером сетки, который не может применять поведение сетки к своим элементам сетки. Но спецификация HTML говорит нам:

Ассоциация details элемент ожидается, что он будет отображаться как блок-бокс. Также ожидается, что элемент будет иметь внутреннюю теневое дерево с двумя слоты.

(Акцент мой)

И чуть позже:

Ассоциация details второй элемент слоты как ожидается, будет иметь свое style атрибут установлен на «display: block; content-visibility: hidden;" когда details элемент не имеет open атрибутов. Когда у него есть open атрибут, style ожидается, что атрибут будет удален из второго слоты.

(Выделено мной, еще раз)

Итак, в спецификации указан второй слот — два дополнительных <div>s из примера — становятся блочными элементами только тогда, когда <details> закрыто. Когда он открыт — <details open> — они должны соответствовать отображению сетки, которая переопределяет стиль пользовательского агента… верно?

Это дискуссия. я понимаю slots установлены на display: contents по умолчанию, но запихивание вложенных элементов в слоты и удаление возможности их стилизации кажется неуместным. Это проблема спецификации, заключающаяся в том, что содержимое представляет собой слоты, или проблема браузера, в которой мы не можем переопределить их display даже несмотря на то, что они находятся в дереве ящиков? Более умные люди могут просветить меня, но это похоже на неправильную реализацию.

Is <details> контейнер или интерактивный элемент?

Многие люди через <details> для переключения меню открытые и закрытые. Это практика популяризирован GitHub.

Кажется разумным. Спецификация, конечно, позволяет это:

Ассоциация details элемент представляет виджет раскрытия, из которого пользователь может получить дополнительную информацию или элементы управления.

(Акцент мой)

Хорошо, мы могли ожидать этого <details> является контейнером (он имеет безоговорочно role=group) и расширение <summary> это интерактивный элемент, который устанавливает контейнер open состояние. Имеет смысл, поскольку <summary> имеет неявное button роль в некоторых контекстах (но без соответствующей роли WAI-ARIA).

Но Мелани Самнер немного покопалась это не только противоречит этому, но и приводит к выводу, что использование <details> меню, наверное, не самое лучшее. Посмотрите, что произойдет, когда <details> отображается без <summary> элемент:

Он делает именно то, что предлагает спецификация, когда ему не хватает <summary> — оно делает свое:

Первый summary дочерний элемент элемента, если есть, представляет краткое изложение или легенда деталей. Если нет ребенка summary элемент, пользовательский агент должен предоставить собственную легенду (например, «Подробности»).

(Акцент мой)

Мелани прогнала это через валидатор HTML и — сюрприз! — это неверно:

Итак, <details> требует <summary>, И когда <summary> пропал, отсутствует, <details> создает свою собственную разметку, хотя и передается как недействительная разметка. Это все здорово и актуально, когда <summary> есть:

Все это приводит к новому вопросу: почему <summary> учитывая подразумеваемый button роль, когда <details> это то, что кажется интерактивным элементом? Возможно, это еще один случай неправильной реализации браузера? Опять же, спецификация классифицирует оба типа как интерактивные элементы. Вы можете видеть, насколько все это становится запутанным.

В любом случае, окончательный вывод Мелани о том, что нам следует избегать использования <details> для меню основано на том, как вспомогательные технологии читают и объявляют <details> которые содержат интерактивные элементы. Элемент объявлен, но никаких упоминаний об интерактивных элементах управления, кроме этого, нет, пока вы, эээ, не взаимодействовать <details>. Только после этого будет объявлено что-то вроде списка ссылок.

Кроме того, содержимое внутри свернутого <details> исключен из поиска на странице (за исключением браузеров Chromium, которые могут получить доступ к свернутому содержимому на момент написания), что еще больше затрудняет поиск.

Должен <summary> разрешить интерактивные элементы?

Именно этот вопрос поставлен в эта открытая тема. Идея состоит в том, что что-то вроде этого будет недействительным:

<details>
  <summary><a href="...">Link element</a></summary>
</details>

<!-- or -->

<details>
  <summary><input></summary>
</details>

Скотт О'Хара хорошо подводит итог почему это проблема:

Ссылка вообще не видна для JAWS при навигации с помощью виртуального курсора. При переходе к элементу сводки с помощью клавиши Tab JAWS объявляет «пример текста, кнопка» в качестве имени и роли элемента. Если снова нажать клавишу Tab, JAWS снова объявит «пример текста, кнопка», хотя фокус клавиатуры находится на ссылке.

[...]

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

Скотт открыл билеты, чтобы исправить это поведение в Chromium и WebKit. Спасибо, Скотт!

Тем не менее, это действительный HTML:

Скотт идет дальше в отдельное сообщение в блоге. Например, он объясняет, как бить role=button on <summary> может показаться разумным решением, обеспечивающим постоянное объявление вспомогательными технологиями. Это также разрешило бы дискуссию о том, является ли <summary> следует разрешить интерактивные элементы, потому что кнопки не могут содержать интерактивные элементы. Единственная проблема заключается в том, что Safari затем лечит <summary> как стандартная кнопка, которая теряет свою expanded и collapsed состояния. Итак, правильная роль объявлена, но ее состояние теперь нет. 🙃

Куда мы сейчас идем?

Вы боитесь использовать <details>/<summary> со всеми этими проблемами и несоответствиями? Да, да, но только для того, чтобы убедиться, что то, что в нем, обеспечивает пользователям правильный опыт и ожидания.

Я просто рад, что эти разговоры происходят и что они происходят открыто. Поэтому вы можете прокомментировать три предложенных Скоттом решения о том, как модель контента для <summary> определен, голосуйте за его заявки и сообщайте о своих собственных проблемах и вариантах использования, пока вы этим занимаетесь. Будем надеяться, что чем лучше мы понимаем, как используются элементы и чего от них ожидаем, тем лучше они будут реализованы.