Listy niestandardowe: Schemat elementów, ograniczenia i przykłady

Lista niestandardowa to powtarzalna kolekcja elementów, które dzielą mały schemat pól. Każdy element może mieć tytuł, zwięzłe podsumowanie, jedną lub dwie wartości metadanych oraz link docelowy. Taka struktura daje czytelnikom więcej kontekstu niż lista wypunktowana , nie czyniąc przy tym każdego elementu samodzielną kartą produktu .

Przykład — obsługiwane formaty eksportu

• CSV — Wiersze tabelaryczne do analizy w arkuszach kalkulacyjnych. Najlepsze dla płaskich rekordów. Dostępność: Wszystkie plany. Akcja: Zobacz konfigurację eksportu CSV.
• JSON — Zagnieżdżone rekordy dla aplikacji i potoków danych. Najlepsze do zachowywania relacji między polami. Dostępność: Pro i Enterprise. Akcja: Przeczytaj dokumentację JSON.
• Google Sheets — Zsynchronizowany arkusz dla zespołów, które przeglądają dane bez kodowania. Dostępność: Pro i Enterprise. Akcja: Połącz Google Sheets.

Wyrenderowany element nie powinien być dekoracyjną wersją tych wypunktowań. Powinien udostępniać jedną kolekcję zawierającą trzy elementy, a każdy element powinien zachowywać te same pola title, summary, bestFor, availability i url. To model pól — a nie obramowanie, ikona czy liczba kolumn — czyni listę niestandardową.

Dlaczego ten element jest ważny

Zwykły tekst ukrywa powtórzenia. Jeśli sześć integracji opisano w sześciu akapitach, czytelnik musi odkryć, że każdy akapit zawiera nazwę systemu, obsługiwaną akcję, wymagane konto i link konfiguracyjny. Lista niestandardowa nazywa te powtarzające się części za pomocą jednego schematu elementów: zdefiniowanego zestawu pól używanych przez każdy element. Czytelnicy poznają wzorzec po pierwszym wpisie i mogą przewidywalnie skanować kolejne wpisy.

Ta spójność poprawia również możliwość ponownego wykorzystania. System zarządzania treścią może walidować wymagane pola, szablon może renderować każdy element bez znaczników specyficznych dla strony, a aplikacja downstream może przekształcić to samo źródło w kompaktową listę mobilną lub przeszukiwalny katalog. Wyszukiwarki i systemy AI otrzymują wyraźne granice elementów, zamiast musieć wnioskować, gdzie kończy się jedna encja, a zaczyna druga.

Ten element jest ważny, ponieważ istnieje powszechna luka między dwiema poprawnymi strukturami. Wypunktowania działają, gdy każdy element jest jednym zwięzłym stwierdzeniem. Karty działają, gdy każdy element potrzebuje niezależnej grafiki, kilku atrybutów handlowych, widocznej akcji lub wystarczającej wagi wizualnej, aby stać samodzielnie. Wiele kolekcji nie wymaga żadnej ze skrajności. Lista integracji może wymagać nazwy, dwuzdaniowego podsumowania możliwości, statusu i linku. Spłaszczenie tego do wypunktowań gubi pola; rozdmuchanie do kart marnuje miejsce i sprawia, że kolekcja referencyjna wydaje się promocyjna.

Struktura nie jest wymówką, aby każda kolekcja była szyta na miarę. Jednorazowy projekt generuje niespójne pola, kolejność, dostępność i zachowanie responsywne. W związku z tym w pierwszej kolejności stosują się zasady pisania elementów : zidentyfikuj powtarzającą się potrzebę informacyjną, zarejestruj najmniejszy schemat, który ją spełnia, i utrzymuj treść przenośną między rendererami.

Kiedy go używać

Używaj listy niestandardowej, gdy wszystkie elementy odpowiadają na to samo pytanie czytelnika, każdy potrzebuje od dwóch do pięciu widocznych pól, a głównym zadaniem jest przeglądanie lub nawigacja, a nie porównywanie każdej wartości obok siebie. Odpowiednie kolekcje obejmują integracje, obszary usług, obsługiwane formaty, zasoby do pobrania, typy partnerów, obowiązki zespołowe, podglądy katalogów i zgrupowane funkcje.

Przed wyborem wykonaj cztery testy:

1. Powtarzalność: Czy każdy element może używać tych samych wymaganych pól bez tworzenia wyjątków?
2. Niezależność: Czy czytelnik może zrozumieć jeden element bez czytania poprzedniego?
3. Skanowalność: Czy wzór tytuł-plus-podsumowanie jest bardziej użyteczny niż siatka porównywalnych wartości?
4. Akcja: Czy każdy element potrzebuje nie więcej niż jednego głównego miejsca docelowego?

Jeśli odpowiedzi są twierdzące, lista niestandardowa jest prawdopodobnie odpowiednia. Użyj innego elementu, gdy kolekcja nie spełnia jednego z tych testów:

• Użyj listy wypunktowanej, gdy elementy potrzebują tylko jednego równoległego zdania i żadnych oddzielnych metadanych.
• Użyj tabeli porównawczej , gdy czytelnicy muszą skanować te same kryteria w pionie lub poziomie w poprzek alternatyw.
• Użyj karty produktu, gdy obraz, cena, oferta, ocena, dostępność i akcja zakupu czynią każdy element znaczącą jednostką handlową.
• Użyj listy kroków, gdy pozycja wyraża sekwencję, a nie kolejność redakcyjną.
• Użyj glosariusza lub wzorca definicji, gdy każdy wpis jest zasadniczo parą termin–definicja.
• Użyj nagłówków i tekstu, gdy elementy wymagają różnych pól lub więcej niż około 100 słów wyjaśnienia każdy.

Nie wybieraj listy niestandardowej tylko dlatego, że projekt wymaga powtarzających się ramek. Najpierw udowodnij, że istnieje stabilny model treści. Jeśli element pierwszy ma cenę, element drugi ma biografię autora, a element trzeci ma rozmiar pliku do pobrania, nie stanowią one jednej kolekcji, nawet jeśli CSS może je wyrównać.

Gdzie ją umieścić

Umieść listę po tym, jak strona zdefiniuje kolekcję i regułę jej doboru. „Obsługiwane integracje” to etykieta; „Te integracje mogą wysyłać audytowane strony do własnego obszaru roboczego raportowania” mówi czytelnikom, co oznacza członkostwo. Jeśli selekcja lub testy stworzyły zestaw, wyjaśnij tę metodę przed pierwszym elementem, aby lista nie sugerowała niepotwierdzonej kompletności ani rankingu.

Umieść kolekcję blisko zadania decyzyjnego lub nawigacyjnego, któremu służy. Strona integracji powinna przedstawić połączenie i jego rezultat przed wypisaniem obsługiwanych przepływów pracy. Katalog powinien wyjaśnić zakres i filtry przed pokazaniem wpisów. Poradnik w formie listy powinien określić metodę oceny przed przedstawieniem wybranych elementów.

Nie przerywaj listy tekstem, reklamami, wezwaniami do działania ani niezwiązanymi zrzutami ekranu. Granice elementów muszą pozostać kolejne. Umieść zastrzeżenia w zdefiniowanych metadanych odpowiedniego elementu lub wyjaśnij warunek dotyczący całej kolekcji przed lub po całej liście. Jeśli konieczne jest więcej niż dwanaście elementów, zgrupuj je pod znaczącymi podnagłówkami, dodaj filtrowanie lub skieruj czytelników do indeksu katalogowego . Nie twórz niekończącego się wizualnego stosu.

Anatomia

Kompletna lista niestandardowa składa się z następujących obszarów:

1. Tytuł kolekcji: nazywa zbiór w języku czytelnika, a nie wewnętrzną nazwą komponentu.
2. Stwierdzenie zakresu: określa, co kwalifikuje się do włączenia i czy kolekcja jest kompletna, wybrana czy ilustracyjna.
3. Kontener listy: ustanawia jedną semantyczną kolekcję i odpowiada za liczbę elementów.
4. Tytuł elementu: jednoznacznie identyfikuje encję, zasób, funkcję lub opcję.
5. Podsumowanie elementu: wyjaśnia istotną różnicę lub zastosowanie elementu w jednym lub dwóch zdaniach.
6. Grupa metadanych: udostępnia od zera do trzech oznaczonych faktów z zarejestrowanego schematu.
7. Główna akcja: linkuje do jednego jasnego miejsca docelowego za pomocą opisowego tekstu zakotwiczenia.
8. Granica elementu: używa odstępu, linii lub stonowanej powierzchni bez odłączania elementu od jego kolekcji.

Stwierdzenie zakresu zapobiega typowemu błędowi dokładności. „Dostępne integracje” sugeruje kompletność; „Typowe integracje raportowania” deklaruje wybór. Autor musi wybrać sformułowanie, które źródło danych może poprzeć.

Przykłady projektowe

Renderer może zmieniać gęstość, ale musi zachować kolejność pól, semantyczną strukturę listy i przewidywalną sekwencję czytania.

Ułożona lista redakcyjna

Używaj domyślnego ułożonego projektu, gdy podsumowania niosą większość wartości. Zachowaj tytuł jako pierwszy, podsumowanie jako drugie, metadane jako trzecie, a akcję jako ostatnią. Subtelny separator wystarczy; każdy element nie potrzebuje uniesionej karty.

Kompaktowy podgląd katalogowy

Używaj kompaktowego wariantu, gdy tytuły i jedna wartość metadanych pozwalają czytelnikom wybrać miejsce docelowe. Podsumowanie może być krótsze, ale etykiety muszą pozostać widoczne. Nigdy nie zastępuj znaczącego statusu niewyjaśnioną kolorową kropką.

Lista zgrupowana

Używaj grup, gdy jedna stabilna klasyfikacja dzieli kolekcję od ośmiu do dwudziestu czterech elementów na sekcje. Nagłówki grup muszą opisywać rzeczywistą taksonomię, taką jak typ eksportu lub region usługi. Nie grupuj tylko po to, aby uzyskać równe kolumny.

Wąski widok

Przy wąskich szerokościach zachowaj kolejność źródłową i umieść metadane pod podsumowaniem. Nie ukrywaj pól, które pozostają istotne, nie zmniejszaj tekstu, aby utrzymać kolumny, ani nie przenoś akcji z dala od ich elementu.

Parametry

Poniższy schemat jest celowo ograniczony. Pole staje się częścią komponentu tylko wtedy, gdy jest użyteczne w całej kolekcji, a nie dlatego, że jeden element akurat ma dla niego dane.

Trzy elementy to minimum, ponieważ para jest zwykle czytelniejsza jako tekst ciągły, porównanie dwukolumnowe lub dwie pełne karty. Dwanaście to normalne maksimum, ponieważ skanowanie długiego, niefiltrowanego stosu staje się nieefektywne. Limit dwudziestu czterech dla wariantu zgrupowanego to bariera ochronna, a nie cel; większe lub często zmieniające się zbiory wymagają katalogu, wyszukiwarki, stronnicowania lub aplikacji opartej na danych.

Wybierz ordered=true tylko wtedy, gdy widoczna kolejność wyraża zadeklarowany ranking. Wygoda redakcyjna, sortowanie alfabetyczne lub kolejność źródła danych nie tworzą rankingu. Gdy ranking jest faktyczny, podaj metodologię i zachowaj pozycję zarówno w widocznym wyniku, jak i w danych strukturalnych.

Składnia i przykłady kodu

Przenośna dyrektywa określa umowę autorską. Adaptery platform mogą przechowywać dane inaczej, ale muszą zachować te same nazwy pól, kolejność elementów, opcjonalność i widoczny wynik.

Przenośna dyrektywa Markdown

:::custom-listing{title="Export formats" variant=stacked}
These are the formats available for sending completed audit records to another workspace.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Tabular rows for spreadsheet analysis and flat-file ingestion.

- Best for: Spreadsheet analysis
- Availability: All plans
- Action: View CSV export setup
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Nested records that preserve relationships for applications and data pipelines.

- Best for: Automated workflows
- Availability: Pro and Enterprise
- Action: Read the JSON reference
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
A synchronized worksheet for teams that review data without code.

- Best for: Shared review
- Availability: Pro and Enterprise
- Action: Connect Google Sheets
:::
:::

Przykładowe adresy URL opisują wyłącznie przenośną składnię; implementacja musi zastąpić je zweryfikowanymi miejscami docelowymi. Nie publikuj przykładowej ścieżki jako działającego linku tylko dlatego, że pojawia się w bloku kodu.

Adapter Hugo

{{< custom-listing title="Export formats" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="View CSV export setup" >}}
  Tabular rows for spreadsheet analysis and flat-file ingestion.

  **Best for:** Spreadsheet analysis  
  **Availability:** All plans
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Ten zapis określa przyszły adapter lub adapter na poziomie projektu; nie upoważnia do tworzenia lokalnego shortcode’a na stronie. Wszystkie parametry są nazwane. Dopóki adapter nie istnieje, renderuj kolekcję jako semantyczny HTML z <ul> i <li> lub jako natywny Markdown, zamiast po cichu tracić relacje między polami.

Blok WordPress

<!-- wp:amicited/custom-listing {"title":"Export formats","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabular rows for spreadsheet analysis and flat-file ingestion.</p>
    <dl><dt>Best for</dt><dd>Spreadsheet analysis</dd><dt>Availability</dt><dd>All plans</dd></dl>
    <a href="/docs/exports/csv/">View CSV export setup</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Natywne bloki są akceptowalnym rozwiązaniem zastępczym, gdy tworzą jedną listę, jeden element <li> na wpis, prawdziwe nagłówki, listę definicji dla oznaczonych metadanych i opisowe linki. Ogólny blok Columns nie jest niezawodnym zamiennikiem, ponieważ kolejność źródłowa i grupowanie elementów często łamią się na urządzeniach mobilnych.

Przykłady

Dobrze: spójna lista zasobów

Zasoby migracyjne

Te zasoby wspierają zespoły przygotowujące, wykonujące i walidujące migrację strony.

1. Arkusz mapowania przekierowań — Rejestruje każdy stary URL, jego zatwierdzone miejsce docelowe, właściciela i status walidacji. Format: Arkusz kalkulacyjny. Etap: Planowanie. Akcja: Pobierz arkusz przekierowań.
2. Skrypt walidacji dnia uruchomienia — Sprawdza kody odpowiedzi, łańcuchy przekierowań, cele kanoniczne i indeksowalność dla migrowanego zestawu URL-i. Format: Skrypt. Etap: Uruchomienie. Akcja: Przejrzyj konfigurację walidacji.
3. Widok monitorowania po uruchomieniu — Śledzi błędy indeksowania i nieoczekiwane zmiany ruchu po wdrożeniu. Format: Pulpit nawigacyjny. Etap: Monitorowanie. Akcja: Skonfiguruj widok monitorowania.

To działa, ponieważ każdy element używa tych samych pięciu pól: tytuł, podsumowanie, format, etap i akcja. Zakres wyjaśnia, dlaczego zasoby należą do siebie. Numeracja odzwierciedla zadeklarowany etap migracji, a nie twierdzenie, że pierwszy zasób jest „najlepszy”. Każda akcja identyfikuje swoje miejsce docelowe zamiast powtarzać „Dowiedz się więcej”.

Źle: ramki bez wspólnego modelu

Pomocne rzeczy

• Lista kontrolna SEO — Nasz ulubiony przewodnik. Ostatnio aktualizowany. Dowiedz się więcej.
• Audyt premium — 499 €, zawiera rozmowę i raport. Pięć gwiazdek. Kup teraz.
• Viktor — Lider techniczny z Bratysławy, dostępny we wtorki.
• Dokumentacja API — Uwierzytelnianie, limity, błędy, przykłady, SDK, dziennik zmian, status, wsparcie i dwadzieścia innych tematów.

To zawodzi, zanim zacznie się projektowanie wizualne. Zbiór miesza zasób, usługę, osobę i obszar dokumentacji. Pola zmieniają się przy każdym elemencie, „ostatnio” nie ma daty, ocena nie ma źródła ani skali, a głębokość elementów waha się od fragmentu do konspektu sekcji. Podziel treść według celu, a następnie wybierz zarejestrowany element dla każdej kolekcji. Obramowanie wokół niespójnych danych nie tworzy listy niestandardowej.

Źle: lista, która powinna być tabelą

Załóżmy, że sześć planów pokazuje miesięczną cenę, roczną cenę, limit użytkowników, przestrzeń dyskową, czas odpowiedzi wsparcia i dostępność SSO. Czytelnicy muszą porównać te same sześć wartości w każdym planie. Lista zmusiłaby ich do zapamiętania planu pierwszego podczas przewijania do planu szóstego. Użyj tabeli porównawczej, ponieważ zadaniem jest ocena między elementami. Jeśli każdy plan potrzebuje również stwierdzenia pozycjonowania i akcji zakupu, umieść je poza tabelą lub obok niej, używając zarejestrowanego komponentu planu na stronie; nie powielaj sprzecznych wartości w dwóch źródłach.

Znaczniki schematu i dostępność

Renderuj kolekcję z natywną semantyką listy. Używaj <ul>, gdy kolejność elementów nie ma znaczenia, oraz <ol>, gdy strona deklaruje faktyczną sekwencję lub ranking. Każdy wpis należy do jednego <li>. Wewnątrz niego użyj prawdziwego nagłówka na odpowiednim poziomie dokumentu, akapitu dla podsumowania oraz <dl>, <dt> i <dd> dla oznaczonych metadanych. Czytnik ekranu powinien napotkać tytuł elementu przed jego opisem, faktami i akcją.

Nie czyń całego elementu przesadnie dużym linkiem, gdy zawiera on inną kontrolkę lub kilka obszarów tekstowych. Nadaj głównemu linkowi opisową etykietę, taką jak „Zobacz konfigurację eksportu CSV”. Jeśli używany jest wzór stretched-link, jego wskaźnik fokusu musi pozostać widoczny, a jego dostępna nazwa musi nadal opisywać miejsce docelowe. Ikony potrzebują tekstu alternatywnego tylko wtedy, gdy przekazują informacje, których nie ma w tekście. Ozdobne ikony należy ukryć przed technologią asystującą.

Kolejność wizualna i kolejność źródłowa muszą być zgodne. Wielokolumnowy układ na desktopie musi zwinąć się bez czytania elementu pierwszego, trzeciego, piątego, a potem drugiego. Etykiety metadanych nie mogą znikać tylko dlatego, że powtarzające się wartości wyglądają na wizualnie wyrównane; „Enterprise” samo w sobie nie mówi czytelnikowi niewidzącemu, czy opisuje dostępność, odbiorców czy wsparcie.

Strukturalne dane ItemList są opcjonalne, a nie domyślnym hakiem stylizacyjnym. Używaj ich, gdy widoczna kolekcja jest znaczącą, skończoną listą, a strona zyskuje na identyfikacji tej kolekcji. Mapuj każdy widoczny wpis na itemListElement. Dołącz position tylko dla rzeczywistej uporządkowanej listy i upewnij się, że nazwy, URL-e i liczby są zgodne z wyrenderowaną treścią. Nie oznaczaj menu nawigacyjnych, przypadkowych zwiastunów funkcji ani niepełnych zestawów tak, jakby były kompletną rankingową listą. Gdy wpisy są identyfikowalnymi encjami, takimi jak organizacje lub aplikacje, używaj najbardziej konkretnego kwalifikującego się typu tylko wtedy, gdy strona dostarcza i weryfikuje wymagane dane identyfikacyjne.

Zasady pisania

1. Wyjaśnij członkostwo przed przedstawieniem członków. Czytelnicy muszą wiedzieć, czy zbiór jest kompletny, wybrany, sponsorowany, rankingowy czy ilustracyjny, zanim zinterpretują pominięcie lub kolejność. Określ regułę doboru w zdaniu zakresu.
2. Zdefiniuj jeden schemat elementów przed tworzeniem elementów. Spójne pola pozwalają czytelnikom nauczyć się jednego wzorca skanowania, a walidacji wychwycić brakującą treść. Zarejestruj wymagane i opcjonalne pola, zanim autorzy wypełnią kolekcję.
3. Utrzymuj wymagane pola naprawdę uniwersalne. Pozornie wymagane pole, które autorzy w połowie wpisów wypełniają „N/D”, jest niewłaściwym polem lub dowodem, że kolekcja zawiera różne typy elementów.
4. Ogranicz widoczne metadane do trzech par. Więcej pól przesuwa zadanie w kierunku porównywania i utrudnia skanowanie każdego wiersza. Przenieś drugorzędne fakty na stronę docelową lub użyj tabeli.
5. Pisz podsumowania dla różnicy, a nie powtórzenia. Tytuł już nazywa element. Użyj podsumowania, aby wyjaśnić jego istotną funkcję, odbiorców, ograniczenie lub rolę.
6. Używaj równoległych etykiet i jednostek. Nie stosuj naprzemiennie „Plan”, „Dostępny w” i „Poziom” dla tego samego pojęcia. Znormalizuj daty, waluty, jednostki i słownictwo statusów przed renderowaniem.
7. Daj każdemu elementowi jedną główną akcję. Konkurujące przyciski zamieniają listę referencyjną w siatkę kart i zaciemniają zamierzony następny krok. Umieść drugorzędne miejsca docelowe na stronie szczegółów.
8. Deklaruj znaczącą kolejność. Kolejność alfabetyczna, chronologiczna, rankingowa, redakcyjna i wynikająca z systemu źródłowego tworzą różne oczekiwania. Nazwij kolejność, gdy może wpływać na interpretację.
9. Ustaw minimalną i maksymalną liczbę. Używaj normalnie od trzech do dwunastu elementów, z maksymalnie dwudziestoma czterema tylko w użytecznych grupach. Zmień wzorzec, gdy kolekcja wykracza poza te granice.
10. Utrzymuj jedno źródło prawdy. Jeśli cena, status, dostępność lub inne zmienne pole pojawia się gdzie indziej, wypełniaj każdą reprezentację z tego samego własnego źródła i podaj datę weryfikacji tam, gdzie to konieczne.

Typy wpisów, które go używają

• Poradnik w formie listy używa listy niestandardowej, gdy każdy wybrany wpis potrzebuje tego samego podsumowania, dopasowania, ograniczenia i linku dalej, ale nie gęstej macierzy porównawczej.
• Strona Najlepsze-X-dla-Y może jej użyć do rekomendacji dla konkretnych odbiorców po wyjaśnieniu metody oceny. Ranking musi być jawny, a nie sugerowany przez układ wizualny.
• Strona Alternatywy-dla-X może przedstawić opcje zastępcze z spójnymi polami „najlepsze dla”, kompromisami i linkiem do szczegółów przed węższym porównaniem.
• Strona kategorii używa kompaktowej lub zgrupowanej listy, aby zaprezentować możliwy do opanowania zestaw produktów lub usług podrzędnych, gdy filtrowanie nie jest jeszcze konieczne.
• Indeks katalogowy używa tego elementu tylko do podglądu lub małego, stabilnego katalogu. Duże zbiory encji wymagają wyszukiwarki, filtrów, stronnicowania i interfejsu katalogowego opartego na danych.
• Profil firmy może wymienić zweryfikowane jednostki biznesowe, certyfikaty lub lokalizacje, gdy każdy wpis dzieli te same pola.
• Profil dostawcy może wymienić obsługiwane usługi, regiony lub modele współpracy bez przekształcania profilu w siatkę produktów.
• Strona integracji może wymienić obsługiwane przepływy pracy, obiekty danych, wyzwalacze lub miejsca docelowe za pomocą przewidywalnego schematu funkcji i wymagań.

Obecność kolekcji nie wymaga tego elementu. Używaj go tylko wtedy, gdy niestandardowy model pól poprawia wyszukiwanie lub nawigację. Krótki zestaw wymagań wstępnych nadal należy do wypunktowań, a macierz funkcji nadal należy do tabeli.

Lista kontrolna QA

• Kolekcja ma tytuł i zdanie zakresu określające regułę doboru.
• Każdy element reprezentuje ten sam rodzaj encji, zasobu, funkcji lub opcji.
• Wymagane i opcjonalne pola są udokumentowane przed wprowadzeniem treści.
• Każdy element ma unikalny stabilny identyfikator, tytuł i 12–60-słowne podsumowanie.
• Żaden element nie tworzy pola, którego nie ma w zarejestrowanym schemacie.
• Kolekcja zawiera 3–12 elementów lub uzasadnione grupy liczące nie więcej niż 24 elementy łącznie.
• Elementy mają nie więcej niż trzy widoczne pary metadanych i jedną główną akcję.
• Etykiety, jednostki, statusy, daty i sformułowania akcji są spójne.
• Kolejność jest zadeklarowana, gdy implikuje ranking, chronologię lub priorytet.
• Zamiast tego wybrano tabelę, gdy głównym zadaniem jest porównanie między elementami.
• Wynik używa jednego semantycznego <ul> lub <ol> z jednym <li> na element.
• Nagłówki są zgodne z hierarchią strony, a metadane używają semantyki terminu i opisu.
• Fokus klawiatury jest widoczny, a linki opisują swoje miejsca docelowe.
• Kolejność źródłowa jest zgodna z kolejnością wizualną na desktopie i urządzeniach mobilnych.
• Znacznik ItemList, jeśli występuje, jest zgodny z widocznymi elementami, kolejnością, liczbą, nazwami i URL-ami.
• Zmienne wartości pochodzą z własnego źródła i zawierają odpowiednią datę weryfikacji.

FAQ

Poniższe pytania rozwiązują granice, które najczęściej powodują, że lista niestandardowa dryfuje w kierunku wypunktowań, kart lub tabel.

Czym jest lista niestandardowa?

Lista niestandardowa to powtarzalna kolekcja, której elementy dzielą mały, nazwany schemat pól, taki jak tytuł, podsumowanie, metadane i link. Znajduje się pomiędzy prostą listą wypunktowaną a wizualnie niezależną siatką kart.

Ile elementów powinna zawierać lista niestandardowa?

Używaj od trzech do dwunastu elementów jako normalnego zakresu redakcyjnego. Dwa elementy zwykle wymagają tekstu ciągłego lub komponentu obok siebie. Więcej niż dwanaście wymaga użytecznego grupowania, filtrowania, stronnicowania lub wzorca katalogowego; wariant zgrupowany nie może przekraczać dwudziestu czterech elementów.

Kiedy lista niestandardowa powinna stać się tabelą?

Używaj tabeli, gdy czytelnicy muszą porównać większość elementów według tych samych trzech lub więcej pól, zwłaszcza wartości liczbowych, dat, statusów lub możliwości typu tak/nie. Zachowaj listę, gdy podsumowania i linki dalej są ważniejsze niż porównanie między elementami.

Czy lista niestandardowa wymaga schematu ItemList?

Nie. Dodawaj ItemList tylko wtedy, gdy kolekcja jest znacząca i skończona, każdy oznaczony element jest widoczny, a jakakolwiek pozycja odzwierciedla zadeklarowaną kolejność. Zwykłe listy nawigacyjne, zwiastunowe i powiązanych treści zwykle wymagają semantycznego HTML, a nie specjalnego schematu.

Czy elementy mogą mieć różne pola?

Tylko opcjonalne pola zdefiniowane przez wspólny schemat mogą być pominięte. Nie pozwalaj autorom wymyślać pól dla poszczególnych elementów. Jeśli kilka elementów potrzebuje innego modelu informacji, podziel je na inną listę lub wybierz bardziej odpowiedni element.