Детальніше на `деталі`

Багато балачок навколо старого <details> та <summary> елементи останнім часом! я бачив Леа Веру нещодавно написала у Твіттері спостереження про елемент display поведінки, і це начебто розділилося на додаткові спостереження та примітки щодо використання від людей, включаючи a пожвавила дискусію на те <summary> містити інтерактивні елементи чи ні.

Потрібно з’єднати багато точок, і я зроблю все можливе, щоб зробити саме це.

Чи можемо ми змінити відображення елементів, вкладених у <details> елемент?

У програмі, яку я створюю, я використовую для панелей, але зіткнувся з деякими дивними розмірами.
flexbox: https://t.co/noZvxAN35G
Сітка: https://t.co/pis0lPjvXk
Спочатку я подумав, що це помилка, але всі три двигуни погодилися. Нічого в таблиці стилів UA для здається, це пояснює.

— Леа Веру (@LeaVerou) Серпень 28, 2022

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

Зверніть увагу на необхідне <summary> елемент і два додаткових <div>s там. Ми можемо перевизначити display, чи не так?

Те, що ми можемо очікувати, це те <details> тепер має явну висоту 40vh і три рядки, де третій рядок займає простір, що залишився від перших двох. Подобається це:

Ох, але третій ряд не робить... цього.

Мабуть, ми маємо справу з контейнером сітки, який не може застосувати поведінку сітки до своїх елементів сітки. Але специфікація HTML говорить нам:

Команда details елемент є очікується відображення як a коробка блоку. Також очікується, що елемент матиме внутрішній елемент тіньове дерево з двома ігрові автомати.

(Наголос мій)

А трохи пізніше:

Команда 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> наданий imlcit 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 мають із моделлю вмісту для підсумку… але це лише розширить цей коментар за межі необхідного. tldr; модель підсумкового вмісту створює дуже непослідовний, а іноді просто несправний досвід для людей, які використовують AT.

Скотт відкрив квитки, щоб виправити цю поведінку Хром та WebKit. Дякую, Скотт!

Тим не менш, це дійсний HTML:

Скотт йде далі в a окремий допис в блозі. Наприклад, він пояснює, як ляпас role=button on <summary> може здатися розумним виправленням, щоб переконатися, що допоміжні технології постійно повідомляють про це. Це також вирішило б дискусію щодо того, чи потрібно <summary> повинні дозволяти інтерактивні елементи, оскільки кнопки не можуть містити інтерактивні елементи. Єдина проблема в тому, що Safari потім лікує <summary> як стандартна кнопка, яка втрачає свою expanded та collapsed держави. Отже, правильна роль оголошена, але тепер її стан ні. 🙃

Куди ми йдемо зараз?

Ви боїтеся використовувати <details>/<summary> з усіма цими проблемами та невідповідностями? Я точно так, але лише для того, щоб переконатися, що те, що міститься, забезпечує правильний досвід і очікування для користувачів.

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