Lista definicji HTML - Jak poprawnie używać znaczników dl, dt i dd?

Najważniejsze zasady, które warto znać od razu

• to kontener dla par terminów i opisów, a nie zamiennik dla każdej listy.
• oznacza termin lub nazwę, a
  opis, definicję albo wartość.
• Jednemu terminowi może odpowiadać kilka opisów, a kilka terminów może wskazywać na jeden opis.
• Najlepsze zastosowania to glosariusze, metadane, skróty, profile produktów i dane techniczne.
• Do samego wcięcia tekstu lepiej użyć CSS niż nadużywać struktury semantycznej.
• Jeśli treść zaczyna przypominać kroki, porównanie albo siatkę danych, zwykle lepsze będzie
  ,
  albo .

  Czym jest lista definicji i kiedy naprawdę się przydaje

  W specyfikacji częściej mówi się dziś o description list niż o liście definicji, bo nie zawsze chodzi o klasyczne słownikowe definicje. Ja traktuję ten element jako semantyczny sposób zapisu par: „coś” i „jego opis”, „etykieta” i „wartość”, „termin” i „objaśnienie”. To ważne, bo HTML ma opisywać strukturę treści, a nie tylko jej wygląd.

  W praktyce ten układ sprawdza się tam, gdzie użytkownik ma szybko skojarzyć nazwę z konkretną informacją. Glosariusz pojęć technicznych, karta produktu, dane autora, lista parametrów API, a nawet krótkie zestawienie słów skrótów - wszędzie tam taki układ jest naturalny. Nie używam go do zwykłego wypunktowania, bo wtedy semantyka zaczyna kłócić się z treścią.

  Najprostszy test brzmi tak: czy czytelnik ma prawo zapytać „co to jest?” albo „jaka jest wartość tego pola?” Jeśli tak, lista opisowa zwykle będzie lepszym wyborem niż zwykła lista punktowana. Jeśli nie, lepiej nie kombinować i sięgnąć po prostszy element. Następny krok to poprawne złożenie samej struktury.

  Jak poprawnie zbudować strukturę z dl, dt i dd

  W tej strukturze wszystko opiera się na trzech elementach.

  otwiera całą listę,
  oznacza termin, a
  opisuje ten termin. Najbardziej praktyczna zasada, jakiej się trzymam, jest prosta: najpierw nazwa, potem wyjaśnienie. To wystarcza w większości przypadków i dobrze czyta się zarówno w kodzie, jak i na stronie.

  Element	Rola	Na co uważać
  dl	Kontener całej listy opisowej	Nie służy do robienia wcięć ani dekoracyjnych bloków
  dt	Termin, nazwa, etykieta	Może wystąpić kilka razy przed jednym opisem
  dd	Opis, definicja, wartość	Może wystąpić kilka razy po jednym terminie

  Najprostszy przykład wygląda tak:

  
    
  HTML
    
  Język znaczników służący do opisu struktury dokumentu.
  
    
  CSS
    
  Język stylów odpowiedzialny za wygląd interfejsu.
  

  Ten sam układ można rozbudować na dwa sposoby. Jeśli jedna nazwa ma kilka wariantów, umieszczam kilka

  przed jednym
  . Jeśli jedno hasło wymaga kilku objaśnień, dopisuję kilka
  pod jednym terminem. To przydatne przy skrótach, aliasach, nazwach alternatywnych i rozbudowanych opisach. Właśnie dlatego ten element jest bardziej elastyczny, niż wielu początkujących zakłada.

  HTML pozwala też owinąć pojedynczą parę w

  , jeśli chcesz stylować całe grupy osobno albo nadać wspólne atrybuty. W dokumentacji to bywa wygodne, szczególnie gdy jedna lista ma kilka sekcji o podobnej budowie. Zostawiasz semantykę w spokoju, a wygląd rozwiązujesz później w CSS. To podejście zwykle oszczędza najwięcej problemów.

  Gdy ta struktura jest już jasna, sensownie jest zobaczyć, gdzie naprawdę daje najlepszy efekt.

  

  Praktyczne układy, w których ta lista wygląda najlepiej

  Ja najczęściej sięgam po listę opisową w czterech sytuacjach. Pierwsza to glosariusz, czyli zestaw pojęć z krótkimi definicjami. Druga to metadane, na przykład nazwa, wersja, autor, data, licencja. Trzecia to skrót i pełna nazwa, kiedy kilka etykiet prowadzi do jednego opisu. Czwarta to dane techniczne, jeśli użytkownik ma szybko odczytać właściwość i jej wartość.

  • Glosariusz w dokumentacji - dobre rozwiązanie, gdy czytelnik uczy się nowych terminów i potrzebuje szybkich objaśnień.
  • Karta produktu - sprawdza się przy nazwie, modelu, materiale, kompatybilności albo wersji.
  • Profil lub metadane wpisu - przydaje się dla autora, daty publikacji, kategorii czy statusu.
  • Skróty i alternatywne nazwy - kilka terminów może wskazywać na jedną definicję, co oszczędza powtórzeń.
  • Parametry techniczne - dobry wybór dla takich pól jak rozmiar, waga, ilość rdzeni, długość czy numer wersji.

  W dokumentacji technicznej taki układ bywa czytelniejszy niż tabela, jeśli dane nie tworzą porównania wielu kolumn, tylko prostą relację „etykieta - wartość”. Gdy jednak zaczynasz zestawiać obok siebie kilka wartości dla wielu rekordów, to już inna historia. Wtedy lepiej od razu myśleć o tabeli, bo semantyka będzie bliższa temu, co faktycznie pokazujesz.

  Właśnie tu widać największą różnicę między dobrą semantyką a zwykłym „żeby ładnie wyglądało”. Kolejna sekcja pokazuje, gdzie łatwo popełnić błąd i jak go uniknąć.

  Najczęstsze błędy i kiedy lepiej wybrać inną strukturę

  Najczęstszy błąd, jaki widzę, to używanie

  tylko dlatego, że ktoś chce przesunąć tekst w prawo. To słaby pomysł, bo HTML nie powinien udawać CSS. Drugi błąd to pakowanie do listy opisowej treści, które są po prostu elementami równorzędnymi, bez relacji „termin - opis”. Trzeci problem pojawia się wtedy, gdy ktoś próbuje na siłę zrobić z niej format do długich instrukcji albo wieloelementowych porównań.

  Sytuacja	Lepszy wybór	Dlaczego
  Kroki do wykonania	ol	Kolejność ma znaczenie i użytkownik powinien ją widzieć
  Luźne elementy bez hierarchii	ul	Lista punktowana jest prostsza i bardziej naturalna
  Termin i objaśnienie	dl	Semantyka dokładnie odpowiada relacji między danymi
  Porównanie wielu kolumn	table	W tabeli lepiej widać układ wierszy, kolumn i zależności

  Jeśli zaczynasz myśleć o tabeli, a nie o definicji, to zwykle znak, że dl przestaje być najlepszym rozwiązaniem. Podobnie z FAQ: gdy odpowiedzi są krótkie i mocno związane z pojedynczym hasłem, lista opisowa jeszcze ma sens. Gdy pytania i odpowiedzi rozrastają się w pełne akapity, lepiej użyć nagłówków albo komponentu details i summary.

  Najkrótsza zasada brzmi więc tak: najpierw semantyka, potem wygląd. To właśnie ona decyduje, czy kod będzie łatwy w utrzymaniu po kilku miesiącach, czy stanie się przypadkowym zlepkiem znaczników. Z tej zasady wynika jeszcze jeden ważny temat, czyli dostępność i stylowanie.

  Dostępność i stylowanie bez psucia znaczenia

  Dokumentacja MDN zwraca uwagę, że czytniki ekranu mogą różnie prezentować listy opisowe, więc nie ma jednego „magicznego” sposobu na ich ogłaszanie. Dla mnie to sygnał prosty: nie kombinować z semantyką, jeśli HTML już robi robotę. Zwykle nie dokładam przypadkowych ról ARIA, bo łatwo wtedy pogorszyć, a nie poprawić odbiór treści.

  Jeśli chodzi o wygląd, CSS załatwia niemal wszystko. To właśnie tam ustawiam wcięcia, odstępy, grubość terminu i ewentualny separator między nazwą a opisem. Bardzo często wystarcza taki zestaw:

  dl {
    margin: 0;
  }
  
  dt {
    font-weight: 700;
  }
  
  dd {
    margin: 0 0 1rem 0;
  }
  
  dt::after {
    content: ": ";
  }

  W bardziej rozbudowanych kartach można też wykorzystać układ siatki albo flexbox, ale semantyka pozostaje ta sama. Gdy potrzebuję stylować każdą parę osobno, owijam dt i dd w div. To wygodne przy komponentach, które mają własne marginesy, ikony albo tło. Z kolei historyczny atrybut compact omijam, bo dzisiejszy CSS daje większą kontrolę i nie opiera się na starych podpowiedziach przeglądarki.

  Jeżeli układ ma być też naprawdę użyteczny dla osób korzystających z technologii wspomagających, trzymam się jeszcze jednej reguły: nie zmieniam kolejności treści tylko po to, by uzyskać efekt wizualny. Najpierw ma być logiczny odczyt, dopiero później wygląd. To proste podejście zwykle daje najlepszy rezultat zarówno na ekranie, jak i w kodzie.

  Co z tej struktury zabieram do codziennego kodu

  Moja praktyczna zasada jest bardzo krótka: jeśli treść da się opisać jako „nazwa + znaczenie”, lista opisowa jest dobrym wyborem. Jeśli zaczyna przypominać instrukcję krok po kroku, zwykłą listę elementów albo zestaw porównawczy, wybieram inne znaczniki. Taka decyzja zajmuje chwilę, ale później oszczędza poprawki w semantyce, stylach i dostępności.

  Dobrze zrobiona lista definicyjna nie rzuca się w oczy. I właśnie o to chodzi. Ma porządkować treść tak, żeby czytelnik od razu widział relację między terminem a objaśnieniem, a nie zastanawiał się, dlaczego coś wygląda jak lista, choć wcale nią nie jest.