Gli elenchi HTML sono noiosi. Non lo fanno do molto, quindi non ci pensiamo davvero nonostante quanto siano ampiamente utilizzati. E siamo ancora in grado di fare le stesse cose che abbiamo sempre fatto per personalizzarli, come rimuovere marcatori, invertire l'ordine e creare segnalini personalizzati.

Ci sono, tuttavia, alcune cose "nuove" - ​​inclusi i pericoli - da sapere quando si usano gli elenchi. I pericoli sono per lo più minori, ma molto più comuni di quanto si possa pensare. Arriveremo a quelli, oltre ad alcune nuove cose che possiamo fare con le liste e persino nuovi modi per affrontare le vecchie soluzioni.

Per chiarire, questi sono gli elementi HTML di cui stiamo parlando:

• Elenchi ordinati <ol>
• Elenchi non ordinati <ul>
• Elenchi di descrizione <dl>
• Liste interattive <menu>

Gli elenchi ordinati, gli elenchi non ordinati e gli elenchi interattivi contengono voci di elenco (<li>) che vengono visualizzati in base al tipo di elenco con cui abbiamo a che fare. Un elenco ordinato (<ol>) visualizza i numeri accanto alle voci dell'elenco. Elenchi non ordinati (<ul>) ed elementi di menu (<menu>) visualizza i punti elenco accanto agli elementi dell'elenco. Chiamiamo questi "indicatori di elenco" e possono anche essere abbinati usando il ::marcatore pseudo-elemento. Gli elenchi di descrizioni utilizzano termini descrittivi (<dt>) e i dettagli della descrizione (<dd>) invece di <li> e non hanno marcatori di elenco. Dovrebbero essere usati per visualizzare metadati e glossari, ma non posso dire di averli mai visti in natura.

Cominciamo con le cose facili: come reimpostare correttamente (almeno secondo me) gli stili di elenco. Successivamente, daremo un'occhiata a un paio di problemi di accessibilità prima di far luce sull'inafferrabile <menu> elemento, che potresti essere sorpreso di apprendere ... è in realtà anche un tipo di elenco!

Reimpostazione degli stili di elenco

I browser applicano automaticamente i propri stili User Agent per aiutare con la struttura visiva degli elenchi fin da subito. Può essere fantastico! Ma se vogliamo iniziare con una tabula rasa priva di opinioni stilistiche, dobbiamo prima reimpostare quegli stili.

Ad esempio, possiamo rimuovere abbastanza facilmente i marcatori accanto agli elementi dell'elenco. Niente di nuovo qui:

/* Zap all list markers! */
ol, ul, menu { list-style: none;
}

Ma i moderni CSS hanno nuovi modi per aiutarci a scegliere come target istanze di elenchi specifici. Supponiamo di voler cancellare i marcatori da tutti gli elenchi, tranne se tali elenchi compaiono in contenuto lungo, come un articolo. Se combiniamo i poteri delle nuove funzioni di pseudo-classe CSS :where() ed :not(), possiamo isolare quelle istanze e consentire i marcatori in quei casi:

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

Perché usare :where() invece di :is()? La specificità di :where() è sempre zero, mentre :is() prende la specificità dell'elemento più specifico nel suo elenco di selettori. Quindi, usando :where() è un modo meno energico di scavalcare le cose e può essere facilmente scavalcato esso stesso.

Gli stili UA applicano anche il riempimento per distanziare il contenuto di una voce di elenco dal suo marcatore. Ancora una volta, in alcuni casi è un'offerta piuttosto carina, pronta all'uso, ma se stiamo già rimuovendo i marcatori di elenco come abbiamo fatto sopra, allora potremmo anche cancellare quella spaziatura interna. Questo è un altro caso per :where():

:where(ol, ul, menu) { padding-left: 0; /* or padding-inline-start */
}

OK, questo impedirà agli elementi dell'elenco senza marcatore di apparire fluttuanti nello spazio. Ma in un certo senso abbiamo buttato via il bambino con l'acqua sporca e rimosso l'imbottitura in tutti i casi, compresi quelli precedentemente isolati in un <article>. Quindi, ora quegli elenchi con i marcatori pendono dal bordo della casella del contenuto.

Si noti che gli stili UA applicano un extra 40px Vai all’email <menu> elemento.

Quindi quello che vogliamo fare è evitare che i marcatori di elenco "appendano" fuori dal contenitore. Possiamo risolverlo con il list-style-position proprietà:

O no... forse dipende dalle preferenze stilistiche?

Problemi di accessibilità più recenti con gli elenchi

Sfortunatamente, ci sono un paio di problemi di accessibilità quando si tratta di elenchi, anche in questi tempi più moderni. Una preoccupazione è il risultato dell'applicazione list-style: none; come abbiamo fatto durante il ripristino degli stili UA.

In poche parole, Safari non leggere liste ordinate e non ordinate stilizzate con list-style: none come elenchi effettivi, come quando si naviga nei contenuti con uno screen reader. In altre parole, la rimozione dei marcatori rimuove anche il significato semantico dell'elenco. Il correzione per questa correzione per applicare un ARIA list ruolo nella lista e a listitem ruolo alle voci dell'elenco quindi gli screen reader li raccolgono:

<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>

Stranamente, Safari considera questa una caratteristica piuttosto che un bug. Fondamentalmente, gli utenti segnalavano che i lettori di schermo stavano annunciando troppi elenchi (perché gli sviluppatori tendono a usarli in modo eccessivo), quindi ora solo quelli con role="list" sono annunciati dagli screen reader, il che in realtà non è poi così strano. Scott O'Hara ha una carrellata dettagliata di come tutto è andato giù.

Un secondo problema di accessibilità non è di nostra creazione (evviva!). Quindi, sai come dovresti aggiungere un aria-label a <section> elementi senza titoli? Bene, a volte ha senso fare lo stesso con un elenco che non contiene un elemento di intestazione che aiuta a descrivere l'elenco.

<!-- 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>

Assolutamente non devono usare entrambi i metodi. L'utilizzo di un'intestazione o di un'etichetta ARIA è solo un contesto aggiunto, non un requisito: assicurati di testare i tuoi siti Web con lettori di schermo e fai ciò che offre la migliore esperienza utente per la situazione.

In notizie in qualche modo correlate, Eric Bailey ha scritto un pezzo eccellente su perché e come considera aria-label essere un odore di codice.

Aspettare, <menu> è anche una lista?

OK, quindi, probabilmente ti starai chiedendo di tutto il <menu> elementi che ho inserito negli esempi di codice. In realtà è semplicissimo; i menu sono elenchi non ordinati, tranne per il fatto che sono pensati per elementi interattivi. Sono persino esposti all'albero dell'accessibilità come elenchi non ordinati.

Agli albori del web semantico, credevo erroneamente che i menu fossero simili <nav>s prima di credere che fossero per i menu contestuali (o "barre degli strumenti" come la specifica dice) perché è quello che dicevano le prime versioni delle specifiche HTML. (MDN ha un articolo interessante su tutte le cose deprecate relative a <menu> se sei interessato.)

Oggi, tuttavia, questo è il modo semantico di usare i menu:

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

Personalmente, penso che ci siano alcuni buoni casi d'uso per <menu>. L'ultimo esempio mostra un elenco di pulsanti di condivisione social racchiusi in un file labeled <menu> elemento, l'aspetto notevole è che l'etichetta "Condividi articolo" contribuisce a una quantità significativa di contesto che aiuta a descrivere cosa fanno i pulsanti.

I menu sono assolutamente necessari? No. Lo sono Punti di riferimento HTML? Sicuramente no. Ma sono lì se ti diverti di meno <div>s e ritieni che il componente potrebbe utilizzare un aria-label per un contesto aggiuntivo.

Qualunque altra cosa?

Sì, c'è anche il suddetto <dl> (lista di descrizione) elemento, tuttavia, MDN non sembra considerarli liste allo stesso modo - è un elenco di gruppi contenenti termini - e non posso dire di averli davvero visti in uso. Secondo MDN, dovrebbero essere utilizzati per metadati, glossari e altri tipi di coppie chiave-valore. Li eviterei semplicemente perché tutti gli screen reader li annunciano in modo diverso.

Ma non concludiamo le cose con una nota negativa. Ecco un elenco di cose fantastiche che puoi fare con le liste:

• Coinsmart. Il miglior scambio di bitcoin e criptovalute d'Europa.Clicca qui
• Platoblockchain. Web3 Metaverse Intelligence. Conoscenza amplificata. Accedi qui.
• Fonte: https://css-tricks.com/newer-things-to-know-about-good-ol-html-lists/