HTML-списки нудні. Вони цього не роблять do багато, тому ми насправді не думаємо про них, незважаючи на те, наскільки широко вони використовуються. І ми все ще можемо робити те саме, що й завжди робили, щоб налаштувати їх, наприклад, видаляти маркери, змінювати порядок і створювати власні лічильники.
Однак є кілька «новіших» речей, включаючи небезпеки, про які слід знати під час використання списків. Небезпеки здебільшого незначні, але набагато більш поширені, ніж ви думаєте. Ми дійдемо до них, а також до деяких нових речей, які ми можемо робити зі списками, і навіть до нових способів підходу до старих рішень.
Щоб уточнити, ми говоримо про ось елементи HTML:
- Упорядковані списки
- Не упорядковані списки
- Списки опису
- Інтерактивні списки
Упорядковані списки, невпорядковані списки та інтерактивні списки містять елементи списку (
), які відображаються відповідно до типу списку, з яким ми маємо справу. Впорядкований список (
) відображає числа поруч із елементами списку. Невпорядковані списки (
) і елементи меню (
) відображає маркери поруч із елементами списку. Ми називаємо це «маркерами списків» і їх навіть можна стилізувати використання ::маркер псевдоелемент. У списках опису використовуються терміни опису (
) і деталі опису (
) замість
і не мають маркерів списку. Вони повинні використовуватися для відображення метаданих і глосаріїв, але я не можу сказати, що коли-небудь бачив їх у дикій природі.
Давайте почнемо з легкого — як правильно (принаймні на мою думку) скинути стилі списку. Після цього ми розглянемо кілька проблем із доступністю, перш ніж пролити світло на невловиме
елемент, який ви, можливо, здивуєтеся… насправді також є типом списку!
Скидання стилів списку
Браузери автоматично застосовують власні стилі агентів користувача, щоб допомогти з візуальною структурою списків прямо з коробки. Це може бути чудово! Але якщо ми хочемо почати з чистого аркуша без думок про стилі, то спочатку нам потрібно скинути ці стилі.
Наприклад, ми можемо досить легко видалити маркери поруч із елементами списку. Тут нічого нового:
/* Zap all list markers! */
ol, ul, menu {
list-style: none;
}Але сучасний CSS має нові способи, які допомагають нам націлюватися на певні екземпляри списку. Скажімо, ми хочемо очистити маркери з усіх списків, за винятком тих, які містяться в них довгостроковий вміст, наприклад стаття. Якщо ми об’єднаємо можливості новіших функцій псевдокласу CSS :where() та :not(), ми можемо виділити ці випадки та дозволити маркери в цих випадках:
/* Where there are lists that are not articles where there are lists... */
:where(ol, ul, menu):not(article :where(ol, ul, menu)) {
list-style: none;
}Навіщо використовувати :where() замість :is()? Специфіка :where() завжди дорівнює нулю, тоді як :is() приймає специфіку найбільш конкретного елемента у своєму списку селекторів. Отже, використовуючи :where() є менш сильним способом перевизначення речей, і його можна легко перевизначити.
Стилі UA також застосовують відступи, щоб розділити вміст елемента списку від його маркера. Знову ж таки, у деяких випадках це досить гарна можливість, але якщо ми вже видаляємо маркери списків, як ми робили вище, ми також можемо стерти це відступ. Це інший випадок для :where():
:where(ol, ul, menu) {
padding-left: 0; /* or padding-inline-start */
}Гаразд, це запобігатиме тому, що елементи списку без маркерів плаватимуть у просторі. Але ми ніби викинули дитину разом із водою для купання та зняли підкладку в усіх випадках, включаючи ті, які ми раніше ізолювали в
. Отже, тепер ці списки з маркерами ніби звисають з краю вікна вмісту.
Зауважте, що стилі UA застосовують додаткові 40px до
елемент.
Отже, що ми хочемо зробити, це запобігти «зависанню» маркерів списку за межами контейнера. Ми можемо це виправити за допомогою list-style-position майно:
Чи ні… можливо, це зводиться до стилістичних переваг?
Нові проблеми доступності зі списками
На жаль, є кілька проблем із доступністю списків — навіть у наш сучасний час. Одне занепокоєння - це результат застосування list-style: none; як ми робили під час скидання стилів UA.
Одним словом, Safari НЕ читати впорядковані та невпорядковані списки зі стилем list-style: none як фактичні списки, наприклад під час навігації вмістом за допомогою програми зчитування з екрана. Іншими словами, видалення маркерів також позбавляє семантичного значення списку. The виправлення для цього виправлення це застосувати ARIA list роль у списку та a listitem роль елементів списку тож програми зчитування з екрана підберуть їх:
- ...
- ...
- ...
- ...
- ...
- ...
Дивно, Safari вважає це функцією а не помилка. В основному користувачі повідомляли, що програми зчитування екрана оголошували забагато списків (оскільки розробники, як правило, зловживали ними), тож тепер доступні лише ті з role="list" оголошуються програмами зчитування з екрана, що насправді не так уже й дивно. Скотт О'Хара має детальний виклад про те, як усе пішло.
Друга проблема доступності не є нашою власною ініціативою (ура!). Отже, ви знаєте як ти повинен додати aria-label до
елементи без заголовків? Ну, іноді має сенс зробити те саме зі списком, який не містить елемента заголовка, який допомагає описати список.
Grocery list
Ви абсолютно НЕ потрібно використовувати будь-який метод. Використання заголовка чи мітки ARIA – це лише доданий контекст, а не вимога. Обов’язково протестуйте свої веб-сайти за допомогою програм зчитування з екрана та робіть те, що пропонує найкращу взаємодію з користувачем у цій ситуації.
У дещо схожих новинах Ерік Бейлі написав чудовий твір про чому і як він вважає aria-label бути кодовим запахом.
Зачекайте,
це також список?
Гаразд, тож, напевно, вам цікаво все
елементи, які я вставив у приклади коду. Насправді все дуже просто; меню є невпорядкованими списками, за винятком того, що вони призначені для інтерактивних елементів. Вони навіть відображаються в дереві доступності як невпорядковані списки.
На початку семантичної мережі я помилково вважав, що меню — це як
s перш ніж повірити, що вони призначені для контекстних меню (або «панелей інструментів», як специфікація каже), тому що це було сказано в ранніх версіях специфікації HTML. (MDN має цікавий опис на всі застарілі матеріали, пов’язані з
якщо тобі взагалі цікаво)
Однак сьогодні це семантичний спосіб використання меню:
Особисто я вважаю, що є кілька хороших варіантів використання
. В останньому прикладі показано список кнопок соціального обміну, загорнутих у мітку
Примітним аспектом є те, що мітка «Поділитися статтею» надає значну кількість контексту, який допомагає описати, що роблять кнопки.
Чи меню є абсолютно необхідним? Ні, вони Орієнтири HTML? Точно ні. Але їх там, якщо вам подобається менше
s і ви відчуваєте, що компонент може використовувати an aria-label для додаткового контексту.
Ще щось?
Так, є також вищезгадане
(список опису) елемент, однак, MDN, здається, не розглядає їх списки таким же чином — це список груп, що містять терміни — і я не можу сказати, що я справді бачив їх використання. Згідно з MDN, вони повинні використовуватися для метаданих, глосаріїв та інших типів пар ключ-значення. Я б просто уникав їх на тій підставі, що всі програми зчитування з екрана оголошують їх по-різному.
Але не будемо закінчувати все на негативній ноті. Ось список суперкрутих речей, які можна робити зі списками:
