HTML-lister er kjedelige. Det gjør de ikke do mye, så vi tenker egentlig ikke på dem til tross for hvor mye brukt de er. Og vi er fortsatt i stand til å gjøre de samme tingene som vi alltid har gjort for å tilpasse dem, som å fjerne markører, reversere rekkefølge og lage tilpassede tellere.
Det er imidlertid noen "nyere" ting - inkludert farer - å vite når du bruker lister. Farene er for det meste små, men mye mer vanlig enn du kanskje tror. Vi kommer til disse, pluss noen nye ting vi kan gjøre med lister, og til og med nye måter å nærme oss gamle løsninger på.
For å avklare, dette er HTML-elementene vi snakker om:
- Bestilte lister
- Uordnede lister
- Beskrivelseslister
- Interaktive lister
Ordnede lister, uordnede lister og interaktive lister inneholder listeelementer (
) som vises i henhold til hva slags liste vi har å gjøre med. En bestilt liste (
) viser tall ved siden av listeelementer. Uordnede lister (
) og menyelementer (
) viser punkt ved siden av listeelementer. Vi kaller disse "listemarkører" og de kan til og med styles bruker ::markør pseudo-element. Beskrivelseslister bruker beskrivelsesord (
) og beskrivelsesdetaljer (
) i stedet for
og har ikke listemarkører. De skal brukes til å vise metadata og ordlister, men jeg kan ikke si at jeg noen gang har sett dem i naturen.
La oss starte med de enkle tingene - hvordan du tilbakestiller listestiler på riktig måte (i det minste etter min mening). Etter det tar vi en titt på et par tilgjengelighetsproblemer før vi kaster lys på det unnvikende
element, som du kanskje blir overrasket over å lære... er faktisk også en type liste!
Tilbakestiller listestiler
Nettlesere bruker automatisk sine egne User Agent-stiler for å hjelpe med den visuelle strukturen til lister rett ut av boksen. Det kan være flott! Men hvis vi vil starte med et blankt ark uten styling meninger, må vi tilbakestille disse stilene først.
For eksempel kan vi fjerne markørene ved siden av listeelementer ganske enkelt. Ikke noe nytt her:
/* Zap all list markers! */
ol, ul, menu {
list-style: none;
}Men moderne CSS har nye måter å hjelpe oss med å målrette spesifikke listeforekomster. La oss si at vi ønsker å fjerne markører fra alle lister, bortsett fra hvis disse listene vises i langt innhold, som en artikkel. Hvis vi kombinerer kreftene til nyere CSS pseudo-klasse funksjoner :where() og :not(), kan vi isolere disse forekomstene og tillate markørene i disse tilfellene:
/* 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 bruke :where() istedenfor :is()? Spesifisiteten til :where() er alltid null, mens :is() tar spesifisiteten til det mest spesifikke elementet i listen over velgere. Så bruker :where() er en mindre kraftig måte å overstyre ting og kan lett overstyres selv.
UA-stiler bruker også utfylling for å plassere et listeelements innhold fra markøren. Igjen, det er en ganske fin pris rett ut av esken i noen tilfeller, men hvis vi allerede fjerner listemarkørene som vi gjorde ovenfor, kan vi like gjerne slette den polstringen også. Dette er en annen sak for :where():
:where(ol, ul, menu) {
padding-left: 0; /* or padding-inline-start */
}OK, det kommer til å forhindre at listeelementer uten markør ser ut til å flyte i rommet. Men vi kastet liksom ut babyen med badevannet og fjernet polstringen i alle tilfeller, inkludert de vi tidligere isolerte i en
. Så nå henger de listene med markører på kanten av innholdsboksen.
Legg merke til at UA-stiler gjelder en ekstra 40px til
element.
Så det vi ønsker å gjøre er å forhindre at listemarkørene "henger" utenfor beholderen. Vi kan fikse det med list-style-position eiendom:
Eller ikke ... kanskje det kommer ned til stilistiske preferanser?
Nyere tilgjengelighetsproblemer med lister
Dessverre er det et par tilgjengelighetsproblemer når det gjelder lister - selv i disse mer moderne tider. En bekymring er et resultat av å søke list-style: none; som vi gjorde da vi tilbakestilte UA-stiler.
I et nøtteskall, Safari ikke les ordnede og uordnede lister stylet med list-style: none som faktiske lister, som når du navigerer i innhold med en skjermleser. Med andre ord, fjerning av markørene fjerner også listens semantiske betydning. De fiks for denne løsningen det å bruke en ARIA list rolle på listen og en listitem rolle til listeelementene så skjermlesere vil fange dem opp:
- ...
- ...
- ...
- ...
- ...
- ...
Merkelig, Safari anser dette som en funksjon heller enn en feil. I utgangspunktet vil brukere rapportere at skjermlesere annonserte for mange lister (fordi utviklere har en tendens til å overbruke dem), så nå er det bare de med role="list" annonseres av skjermlesere, noe som faktisk ikke er så rart likevel. Scott O'Hara har en detaljert oversikt av hvordan det hele gikk ned.
Et annet tilgjengelighetsproblem er ikke noe vi har laget (hurra!). Så du vet hvordan du skal legge til en aria-label til
elementer uten overskrifter? Vel, noen ganger er det fornuftig å gjøre det samme med en liste som ikke inneholder et overskriftselement som hjelper til med å beskrive listen.
Grocery list
Du absolutt ikke må bruke begge metodene. Å bruke en overskrift eller en ARIA-etikett er bare lagt til kontekst, ikke et krav – sørg for å teste nettsidene dine med skjermlesere og gjør det som gir den beste brukeropplevelsen for situasjonen.
I noe relaterte nyheter skrev Eric Bailey et utmerket stykke om hvorfor og hvordan han vurderer aria-label å være en kodelukt.
Vente,
er en liste også?
OK, så du lurer sannsynligvis på alt
elementer som jeg har gled inn i kodeeksemplene. Det er faktisk superenkelt; menyene er uordnede lister bortsett fra at de er ment for interaktive elementer. De blir til og med utsatt for tilgjengelighetstreet som uordnede lister.
I de første dagene av det semantiske nettet trodde jeg feilaktig at menyer var som
s før de trodde at de var for kontekstmenyer (eller "verktøylinjer" som spesifikasjonen sier) fordi det var det tidlige versjoner av HTML-spesifikasjonen sa. (MDN har en interessant artikkel på alle de avviklede tingene relatert til
hvis du i det hele tatt er interessert.)
I dag er imidlertid dette den semantiske måten å bruke menyer på:
Personlig synes jeg det er noen gode bruksområder for
. Det siste eksemplet viser en liste over sosiale delingsknapper pakket inn i en etikett
element, det bemerkelsesverdige aspektet er at "Del artikkel"-etiketten bidrar med en betydelig mengde kontekst som hjelper til med å beskrive hva knappene gjør.
Er menyer helt nødvendig? Nei. Er de HTML landemerker? Definitivt ikke. Men de er der hvis du liker færre
s og du føler at komponenten kan bruke en aria-label for ekstra kontekst.
Alt annet?
Ja, det er også det nevnte
(beskrivelsesliste) element, men MDN ser ikke ut til å vurdere disse listene på samme måte - det er en liste over grupper som inneholder termer - og jeg kan ikke si at jeg virkelig har sett dem i bruk. Ifølge MDN skal de brukes til metadata, ordlister og andre typer nøkkelverdi-par. Jeg ville bare unngå dem med den begrunnelse at alle skjermlesere kunngjør dem annerledes.
Men la oss ikke avslutte ting på en negativ tone. Her er en liste over superkule ting du kan gjøre med lister:
