Platon Data Intelligence.
Vertikal sökning & Ai.

Nyare saker att veta om bra HTML-listor

Datum:

HTML-listor är tråkiga. Det gör de inte do mycket, så vi tänker inte riktigt på dem trots hur mycket de är använda. Och vi kan fortfarande göra samma saker som vi alltid har gjort för att anpassa dem, som att ta bort markörer, vända ordning och göra anpassade räknare.

Det finns dock några "nyare" saker - inklusive faror - att veta när du använder listor. Farorna är för det mesta små, men mycket vanligare än du kanske tror. Vi kommer till dem, plus några nya saker vi kan göra med listor, och till och med nya sätt att närma sig gamla lösningar.

För att förtydliga är dessa HTML-element vi pratar om:

  • Beställda listor <ol>
  • Oordnade listor <ul>
  • Beskrivning listor <dl>
  • Interaktiva listor <menu>

Ordnade listor, oordnade listor och interaktiva listor innehåller listobjekt (<li>) som visas enligt vilken typ av lista vi har att göra med. En beställd lista (<ol>) visar siffror bredvid listobjekt. Oordnade listor (<ul>) och menyelement (<menu>) visar punktpunkter bredvid listobjekt. Vi kallar dessa "listmarkörer" och de kan till och med stylas med ::markör pseudo-element. Beskrivningslistor använder beskrivningstermer (<dt>) och beskrivningsdetaljer (<dd>) istället för <li> och har inga listmarkörer. De är tänkta att användas för att visa metadata och ordlistor, men jag kan inte säga att jag någonsin har sett dem i det vilda.

Låt oss börja med de enkla sakerna - hur man korrekt (åtminstone enligt min mening) återställer liststilar. Efter det ska vi ta en titt på ett par tillgänglighetsproblem innan vi lyser upp det svårfångade <menu> element, som du kanske blir förvånad över att lära dig... är faktiskt också en typ av lista!

Återställ liststilar

Webbläsare använder automatiskt sina egna User Agent-stilar för att hjälpa till med den visuella strukturen för listor direkt från lådan. Det kan vara jättebra! Men om vi vill börja med ett tomt blad utan stylingåsikter, måste vi återställa dessa stilar först.

Vi kan till exempel ta bort markörerna bredvid listobjekt ganska enkelt. Inget nytt här:

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

Men modern CSS har nya sätt att hjälpa oss inrikta oss på specifika listinstanser. Låt oss säga att vi vill ta bort markörer från alla listor, utom om dessa listor visas i långformigt innehåll, som en artikel. Om vi ​​kombinerar krafterna hos nyare CSS-pseudoklassfunktioner :where() och :not(), kan vi isolera dessa instanser och tillåta markörerna i dessa fall:

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

Varför användning :where() istället för :is()? Specificiteten av :where() är alltid noll, medan :is() tar specificiteten för det mest specifika elementet i sin lista över väljare. Så, använder :where() är ett mindre kraftfullt sätt att åsidosätta saker och kan enkelt åsidosättas själv.

UA-stilar tillämpar också utfyllnad för att placera ett listobjekts innehåll från dess markör. Återigen, det är ett ganska bra pris direkt ur lådan i vissa fall, men om vi redan tar bort listmarkörerna som vi gjorde ovan, kan vi lika gärna utplåna den stoppningen också. Detta är ett annat fall för :where():

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

OK, det kommer att förhindra att listobjekt utan markör ser ut att sväva i rymden. Men vi slängde liksom ut barnet med badvattnet och tog bort stoppningen i alla fall, inklusive de som vi tidigare isolerat i en <article>. Så nu hänger de där listorna med markörer på kanten av innehållsrutan.

Lägg märke till att UA-stilar tillkommer 40px till <menu> elementet.

Så vad vi vill göra är att förhindra att listmarkörerna "hänger" utanför behållaren. Vi kan fixa det med list-style-position fast egendom:

Eller inte... det kanske beror på stilistiska preferenser?

Nyare tillgänglighetsproblem med listor

Tyvärr finns det ett par tillgänglighetsproblem när det gäller listor - även i dessa mer moderna tider. En oro är ett resultat av att ansöka list-style: none; som vi gjorde när vi återställde UA-stilar.

I ett nötskal, Safari inte läs ordnade och oordnade listor stylade med list-style: none som faktiska listor, som när du navigerar innehåll med en skärmläsare. Med andra ord, borttagning av markörerna tar också bort listans semantiska betydelse. De fix för denna fix det att tillämpa en ARIA list roll på listan och en listitem roll till listobjekten så att skärmläsare hämtar 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>

Underligt, Safari anser att detta är en funktion snarare än en bugg. I grund och botten skulle användare rapportera att skärmläsare annonserade för många listor (eftersom utvecklare tenderar att överanvända dem), så nu är det bara de med role="list" meddelas av skärmläsare, vilket faktiskt inte är så konstigt trots allt. Scott O'Hara har en detaljerad genomgång hur det gick till.

Ett andra tillgänglighetsproblem är inte något vi själva skapat (hurra!). Så, du vet hur du ska lägga till en aria-label till <section> element utan rubriker? Tja, ibland är det vettigt att göra detsamma med en lista som inte innehåller ett rubrikelement som hjälper till att beskriva listan.

<!-- 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 inte måste använda båda metoderna. Att använda en rubrik eller en ARIA-etikett är bara ett extra sammanhang, inte ett krav – se till att testa dina webbplatser med skärmläsare och gör det som ger den bästa användarupplevelsen för situationen.

I något relaterade nyheter skrev Eric Bailey upp ett utmärkt stycke om varför och hur han tänker aria-label vara en kodlukt.

Vänta, <menu> är en lista också?

OK, så du undrar förmodligen över allt <menu> element som jag har glidit in i kodexemplen. Det är faktiskt superenkelt; menyer är oordnade listor förutom att de är avsedda för interaktiva objekt. De utsätts till och med för tillgänglighetsträdet som oordnade listor.

I början av den semantiska webben trodde jag felaktigt att menyer var som <nav>innan de trodde att de var för snabbmenyer (eller "verktygsfält" som specen säger) eftersom det är vad tidiga versioner av HTML-specifikationen sa. (MDN har en intressant artikel på alla utfasade saker relaterade till <menu> om du alls är intresserad.)

Idag är dock detta det semantiska sättet att använda menyer:

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

Personligen tror jag att det finns några bra användningsfall för <menu>. Det sista exemplet visar en lista över sociala delningsknappar insvepta i en etikett <menu> element, den anmärkningsvärda aspekten är att etiketten "Dela artikel" bidrar med en betydande mängd sammanhang som hjälper till att beskriva vad knapparna gör.

Är menyer absolut nödvändiga? Nej. Är de HTML-landmärken? Definitivt inte. Men de finns där om du gillar färre <div>s och du känner att komponenten skulle kunna använda en aria-label för ytterligare sammanhang.

Något annat?

Ja, det finns också det ovannämnda <dl> (beskrivningslista) element, dock, MDN verkar inte betrakta dem som listor på samma sätt — det är en lista över grupper som innehåller termer — och jag kan inte säga att jag verkligen har sett dem användas. Enligt MDN är de tänkta att användas för metadata, ordlistor och andra typer av nyckel-värdepar. Jag skulle bara undvika dem med motiveringen att alla skärmläsare tillkännager dem olika.

Men låt oss inte avsluta saker på en negativ ton. Här är en lista med supercoola saker du kan göra med listor:

plats_img

Senaste intelligens

plats_img