HTML-lister er kedelige. Det gør de ikke do meget, så vi tænker ikke rigtig over dem på trods af hvor meget brugt de er. Og vi er stadig i stand til at gøre de samme ting, som vi altid har gjort for at tilpasse dem, som at fjerne markører, vende rækkefølge og lave tilpassede tællere.

Der er dog et par "nyere" ting - inklusive farer - at vide, når du bruger lister. Farerne er for det meste mindre, men langt mere almindelige, end du måske tror. Vi kommer til dem, plus nogle nye ting, vi kan gøre med lister, og endda nye måder at gribe gamle løsninger an på.

For at præcisere, er disse HTML-elementer, vi taler om:

• Bestilte lister <ol>
• Uordnede lister <ul>
• Beskrivelseslister <dl>
• Interaktive lister <menu>

Ordnede lister, uordnede lister og interaktive lister indeholder listeelementer (<li>), som vises i henhold til hvilken slags liste vi har at gøre med. En bestilt liste (<ol>) viser tal ved siden af ​​listeelementer. Uordnede lister (<ul>) og menuelementer (<menu>) viser punkttegn ved siden af ​​listeelementer. Vi kalder disse "listemarkører" og de kan endda styles ved hjælp af :: markør pseudo-element. Beskrivelseslister bruger beskrivelsesbegreber (<dt>) og beskrivelsesdetaljer (<dd>) i stedet for <li> og har ikke listemarkører. Det er meningen, at de skal bruges til at vise metadata og ordlister, men jeg kan ikke sige, at jeg nogensinde har set dem i naturen.

Lad os starte med de nemme ting - hvordan man korrekt (i hvert fald efter min mening) nulstiller listestile. Derefter tager vi et kig på et par tilgængelighedsproblemer, før vi kaster lys over det undvigende <menu> element, som du måske bliver overrasket over at lære... er faktisk også en type liste!

Nulstilling af listestile

Browsere anvender automatisk deres egne User Agent-stile for at hjælpe med den visuelle struktur af lister lige ud af boksen. Det kan være fantastisk! Men hvis vi vil starte med en blank tavle fri for stylingudtalelser, så skal vi nulstille disse stilarter først.

For eksempel kan vi ret nemt fjerne markørerne ved siden af ​​listeelementer. Intet nyt her:

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

Men moderne CSS har nye måder at hjælpe os med at målrette mod specifikke listeforekomster. Lad os sige, at vi vil rydde markører fra alle lister, undtagen hvis disse lister vises i langt indhold, som en artikel. Hvis vi kombinerer kræfterne fra nyere CSS pseudo-klasse funktioner :where() , :not(), kan vi isolere disse forekomster og tillade markørerne i disse tilfælde:

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

Hvorfor bruge :where() i stedet for :is()? Specificiteten af :where() er altid nul, hvorimod :is() tager specificiteten af ​​det mest specifikke element i sin liste over vælgere. Så bruger :where() er en mindre kraftfuld måde at tilsidesætte ting på og kan let tilsidesættes i sig selv.

UA-stile anvender også polstring for at placere et listeelements indhold fra dets markør. Igen, det er en ret god pris lige ud af kassen i nogle tilfælde, men hvis vi allerede fjerner listemarkørerne, som vi gjorde ovenfor, så kan vi lige så godt udslette den polstring også. Dette er en anden sag for :where():

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

OK, det vil forhindre, at listeelementer uden markør ser ud til at svæve i rummet. Men vi smed på en måde barnet ud med badevandet og fjernede polstringen i alle tilfælde, også dem vi tidligere isolerede i en <article>. Så nu hænger de lister med markører lidt ud for kanten af ​​indholdsboksen.

Bemærk, at UA-stile gælder en ekstra 40px til <menu> element.

Så det, vi vil gøre, er at forhindre listemarkørerne i at "hænge" uden for containeren. Det kan vi ordne med list-style-position ejendom:

Eller ej... måske kommer det ned til stilistiske præferencer?

Nyere tilgængelighedsproblemer med lister

Desværre er der et par tilgængelighedsproblemer, når det kommer til lister - selv i disse mere moderne tider. En bekymring er et resultat af at ansøge list-style: none; som vi gjorde, da vi nulstillede UA-stile.

Kort sagt, Safari ikke læse ordnede og uordnede lister stylet med list-style: none som faktiske lister, som når du navigerer i indhold med en skærmlæser. Med andre ord, fjernelse af markører fjerner også listens semantiske betydning. Det rettelse til denne rettelse det at anvende en ARIA list rolle på listen og en listitem rolle til listeelementerne så skærmlæsere vil opfange dem:

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

Mærkeligt, Safari anser dette for at være en funktion snarere end en fejl. Grundlæggende vil brugere rapportere, at skærmlæsere annoncerede for mange lister (fordi udviklere har en tendens til at overbruge dem), så nu er det kun dem med role="list" annonceres af skærmlæsere, hvilket faktisk ikke er så mærkeligt alligevel. Scott O'Hara har en detaljeret oversigt hvordan det hele gik.

Et andet tilgængelighedsproblem er ikke noget, vi selv har skabt (hurra!). Så ved du hvordan du skal tilføj en aria-label til <section> elementer uden overskrifter? Nå, det giver nogle gange mening at gøre det samme med en liste, der ikke indeholder et overskriftselement, der hjælper med at beskrive listen.

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

Du absolut ikke skal bruge begge metoder. Brug af en overskrift eller en ARIA-etiket er blot tilføjet kontekst, ikke et krav - sørg for at teste dine websteder med skærmlæsere og gør det, der giver den bedste brugeroplevelse til situationen.

I noget relaterede nyheder skrev Eric Bailey et fremragende stykke om hvorfor og hvordan han overvejer aria-label at være en kodelugt.

Vente, <menu> er en liste også?

OK, så du undrer dig sandsynligvis over alt det <menu> elementer, som jeg har glidet ind i kodeeksemplerne. Det er faktisk super simpelt; menuer er uordnede lister, bortset fra at de er beregnet til interaktive elementer. De er endda udsat for tilgængelighedstræet som uordnede lister.

I de tidlige dage af det semantiske web troede jeg fejlagtigt, at menuer var ligesom <nav>s før de troede, at de var til kontekstmenuer (eller "værktøjslinjer" som specifikationen siger), fordi det er, hvad tidlige versioner af HTML-specifikationen sagde. (MDN har et interessant indlæg på alle de forældede ting relateret til <menu> hvis du overhovedet er interesseret.)

I dag er dette imidlertid den semantiske måde at bruge menuer på:

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

Personligt synes jeg, der er nogle gode use-cases til <menu>. Det sidste eksempel viser en liste over sociale delingsknapper pakket ind i et mærke <menu> element, hvor det bemærkelsesværdige aspekt er, at "Del artikel"-etiketten bidrager med en betydelig mængde kontekst, der hjælper med at beskrive, hvad knapperne gør.

Er menuer absolut nødvendige? Nej. Er de HTML vartegn? Absolut ikke. Men de er der, hvis du nyder færre <div>s og du føler, at komponenten kunne bruge en aria-label for yderligere sammenhæng.

Ellers andet?

Ja, der er også det førnævnte <dl> (beskrivelsesliste) element, dog MDN ser ikke ud til at betragte dem som lister på samme måde - det er en liste over grupper, der indeholder termer - og jeg kan ikke sige, at jeg virkelig har set dem i brug. Ifølge MDN skal de bruges til metadata, ordlister og andre typer nøgleværdi-par. Jeg ville bare undgå dem med den begrundelse, at alle skærmlæsere annoncerer dem forskelligt.

Men lad os ikke afslutte tingene med en negativ tone. Her er en liste over super fede ting, du kan lave med lister:

• Coinsmart. Europas bedste Bitcoin og Crypto Exchange.Klik her
• Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. Adgang her.
• Kilde: https://css-tricks.com/newer-things-to-know-about-good-ol-html-lists/