Інформація про дані Платона.
Вертикальний пошук і штучний інтелект.

Нові речі, які варто знати про старі добрі списки HTML

Дата:

HTML-списки нудні. Вони цього не роблять do багато, тому ми насправді не думаємо про них, незважаючи на те, наскільки широко вони використовуються. І ми все ще можемо робити те саме, що й завжди робили, щоб налаштувати їх, наприклад, видаляти маркери, змінювати порядок і створювати власні лічильники.

Однак є кілька «новіших» речей, включаючи небезпеки, про які слід знати під час використання списків. Небезпеки здебільшого незначні, але набагато більш поширені, ніж ви думаєте. Ми дійдемо до них, а також до деяких нових речей, які ми можемо робити зі списками, і навіть до нових способів підходу до старих рішень.

Щоб уточнити, ми говоримо про ось елементи HTML:

  • Упорядковані списки <ol>
  • Не упорядковані списки <ul>
  • Списки опису <dl>
  • Інтерактивні списки <menu>

Упорядковані списки, невпорядковані списки та інтерактивні списки містять елементи списку (<li>), які відображаються відповідно до типу списку, з яким ми маємо справу. Впорядкований список (<ol>) відображає числа поруч із елементами списку. Невпорядковані списки (<ul>) і елементи меню (<menu>) відображає маркери поруч із елементами списку. Ми називаємо це «маркерами списків» і їх навіть можна стилізувати використання ::маркер псевдоелемент. У списках опису використовуються терміни опису (<dt>) і деталі опису (<dd>) замість <li> і не мають маркерів списку. Вони повинні використовуватися для відображення метаданих і глосаріїв, але я не можу сказати, що коли-небудь бачив їх у дикій природі.

Давайте почнемо з легкого — як правильно (принаймні на мою думку) скинути стилі списку. Після цього ми розглянемо кілька проблем із доступністю, перш ніж пролити світло на невловиме <menu> елемент, який ви, можливо, здивуєтеся… насправді також є типом списку!

Скидання стилів списку

Браузери автоматично застосовують власні стилі агентів користувача, щоб допомогти з візуальною структурою списків прямо з коробки. Це може бути чудово! Але якщо ми хочемо почати з чистого аркуша без думок про стилі, то спочатку нам потрібно скинути ці стилі.

Наприклад, ми можемо досить легко видалити маркери поруч із елементами списку. Тут нічого нового:

/* 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 */
}

Гаразд, це запобігатиме тому, що елементи списку без маркерів плаватимуть у просторі. Але ми ніби викинули дитину разом із водою для купання та зняли підкладку в усіх випадках, включаючи ті, які ми раніше ізолювали в <article>. Отже, тепер ці списки з маркерами ніби звисають з краю вікна вмісту.

Зауважте, що стилі UA застосовують додаткові 40px до <menu> елемент.

Отже, що ми хочемо зробити, це запобігти «зависанню» маркерів списку за межами контейнера. Ми можемо це виправити за допомогою list-style-position майно:

Чи ні… можливо, це зводиться до стилістичних переваг?

Нові проблеми доступності зі списками

На жаль, є кілька проблем із доступністю списків — навіть у наш сучасний час. Одне занепокоєння - це результат застосування list-style: none; як ми робили під час скидання стилів UA.

Одним словом, Safari НЕ читати впорядковані та невпорядковані списки зі стилем list-style: none як фактичні списки, наприклад під час навігації вмістом за допомогою програми зчитування з екрана. Іншими словами, видалення маркерів також позбавляє семантичного значення списку. The виправлення для цього виправлення це застосувати ARIA list роль у списку та a listitem роль елементів списку тож програми зчитування з екрана підберуть їх:

<ol style="list-style: none;" role="list"> <li role="listItem">...</li> <li role="listItem">...</li> <li role="listItem">...</li>
</ol> <ul style="list-style: none;" role="list"> <li role="listItem">...</li> <li role="listItem">...</li> <li role="listItem">...</li>
</ul>

Дивно, Safari вважає це функцією а не помилка. В основному користувачі повідомляли, що програми зчитування екрана оголошували забагато списків (оскільки розробники, як правило, зловживали ними), тож тепер доступні лише ті з role="list" оголошуються програмами зчитування з екрана, що насправді не так уже й дивно. Скотт О'Хара має детальний виклад про те, як усе пішло.

Друга проблема доступності не є нашою власною ініціативою (ура!). Отже, ви знаєте як ти повинен додати aria-label до <section> елементи без заголовків? Ну, іноді має сенс зробити те саме зі списком, який не містить елемента заголовка, який допомагає описати список.

<!-- This list is somewhat described by the heading -->
<section> <h2>Grocery list</h2> <ol role="list"> <!-- ... --> </ol>
</section> <!-- This list is described by the aria-label -->
<ol role="list" aria-label="Grocery list"> <!-- ... -->
</ol>

Ви абсолютно НЕ потрібно використовувати будь-який метод. Використання заголовка чи мітки ARIA – це лише доданий контекст, а не вимога. Обов’язково протестуйте свої веб-сайти за допомогою програм зчитування з екрана та робіть те, що пропонує найкращу взаємодію з користувачем у цій ситуації.

У дещо схожих новинах Ерік Бейлі написав чудовий твір про чому і як він вважає aria-label бути кодовим запахом.

Зачекайте, <menu> це також список?

Гаразд, тож, напевно, вам цікаво все <menu> елементи, які я вставив у приклади коду. Насправді все дуже просто; меню є невпорядкованими списками, за винятком того, що вони призначені для інтерактивних елементів. Вони навіть відображаються в дереві доступності як невпорядковані списки.

На початку семантичної мережі я помилково вважав, що меню — це як <nav>s перш ніж повірити, що вони призначені для контекстних меню (або «панелей інструментів», як специфікація каже), тому що це було сказано в ранніх версіях специфікації HTML. (MDN має цікавий опис на всі застарілі матеріали, пов’язані з <menu> якщо тобі взагалі цікаво)

Однак сьогодні це семантичний спосіб використання меню:

<menu aria-label="Share article"> <li><button>Email</button></li> <li><button>Twitter</button></li> <li><button>Facebook</button></li>
</menu>

Особисто я вважаю, що є кілька хороших варіантів використання <menu>. В останньому прикладі показано список кнопок соціального обміну, загорнутих у мітку <menu> Примітним аспектом є те, що мітка «Поділитися статтею» надає значну кількість контексту, який допомагає описати, що роблять кнопки.

Чи меню є абсолютно необхідним? Ні, вони Орієнтири HTML? Точно ні. Але їх там, якщо вам подобається менше <div>s і ви відчуваєте, що компонент може використовувати an aria-label для додаткового контексту.

Ще щось?

Так, є також вищезгадане <dl> (список опису) елемент, однак, MDN, здається, не розглядає їх списки таким же чином — це список груп, що містять терміни — і я не можу сказати, що я справді бачив їх використання. Згідно з MDN, вони повинні використовуватися для метаданих, глосаріїв та інших типів пар ключ-значення. Я б просто уникав їх на тій підставі, що всі програми зчитування з екрана оголошують їх по-різному.

Але не будемо закінчувати все на негативній ноті. Ось список суперкрутих речей, які можна робити зі списками:

spot_img

Остання розвідка

spot_img

Зв'яжіться з нами!

Привіт! Чим я можу вам допомогти?