Vlastní výpis: Schéma položek, limity a příklady

Vlastní výpis je opakovatelná kolekce položek, které sdílejí malé schéma polí. Každá položka může mít název, stručné shrnutí, jednu nebo dvě hodnoty metadat a cílový odkaz. Tato struktura poskytuje čtenářům více kontextu než odrážkový seznam , aniž by každá položka fungovala jako samostatná produktová karta .

Příklad — podporované exportní formáty

• CSV — Tabulkové řádky pro analýzu v tabulkovém procesoru. Nejlepší pro ploché záznamy. Dostupnost: Všechny plány. Akce: Zobrazit nastavení CSV exportu.
• JSON — Vnořené záznamy pro aplikace a datové pipeliny. Nejlepší pro zachování vztahů mezi poli. Dostupnost: Pro a Enterprise. Akce: Přečíst JSON referenci.
• Google Sheets — Synchronizovaný list pro týmy, které pracují s daty bez kódu. Dostupnost: Pro a Enterprise. Akce: Připojit Google Sheets.

Vykreslený prvek by neměl být dekorativní verzí těchto odrážek. Měl by odhalit jednu kolekci obsahující tři položky a každá položka by měla zachovat stejná pole title, summary, bestFor, availability a url. Model polí – nikoli okraj, ikona nebo počet sloupců – je to, co činí výpis vlastním.

Proč na tomto prvku záleží

Běžný souvislý text skrývá opakování. Pokud je šest integrací popsáno v šesti odstavcích, čtenář musí zjistit, že každý odstavec obsahuje název systému, podporovanou akci, požadavek na účet a odkaz na nastavení. Vlastní výpis pojmenovává tyto opakující se části prostřednictvím jednoho schématu položek: definované sady polí používaných každou položkou. Čtenáři se naučí vzor po první položce a mohou pozdější položky předvídatelně skenovat.

Tato konzistence také zlepšuje znovupoužitelnost. Systém pro správu obsahu může validovat povinná pole, šablona může vykreslit každou položku bez značkování specifického pro stránku a downstream aplikace může transformovat stejný zdroj do kompaktního mobilního seznamu nebo prohledávatelného adresáře. Vyhledávače a AI systémy obdrží diskrétní hranice položek, namísto aby musely odvozovat, kde jedna entita končí a druhá začíná.

Prvek je důležitý, protože existuje běžná mezera mezi dvěma platnými strukturami. Odrážky fungují, když je každá položka jedním kompaktním tvrzením. Karty fungují, když každá položka potřebuje nezávislé obrázky, několik obchodních atributů, výraznou akci nebo dostatečnou vizuální váhu, aby obstála sama. Mnoho kolekcí nepotřebuje ani jeden extrém. Integrační seznam může vyžadovat název, dvouvěté shrnutí schopností, stav a odkaz. Zploštění do odrážek ztrácí pole; nafouknutí do karet plýtvá místem a působí propagačně.

Struktura není omluvou pro vytváření každé kolekce na míru. Jednorázový design vytváří nekonzistentní pole, řazení, přístupnost a responzivní chování. Proto se nejprve uplatňují pravidla pro psaní prvků : identifikujte opakovanou informační potřebu, zaregistrujte nejmenší schéma, které ji splňuje, a udržujte obsah přenositelný napříč renderery.

Kdy jej použít

Použijte vlastní výpis, když všechny položky odpovídají na stejnou otázku čtenáře, každá potřebuje dvě až pět viditelných polí a primárním úkolem je prohlížení nebo navigace, nikoli porovnávání každé hodnoty vedle sebe. Vhodné kolekce zahrnují integrace, oblasti služeb, podporované formáty, stahování zdrojů, typy partnerů, týmové odpovědnosti, náhledy adresářů a seskupené funkce.

Před výběrem proveďte čtyři testy:

1. Opakovatelnost: Může každá položka používat stejná povinná pole bez vymýšlení výjimek?
2. Nezávislost: Může čtenář pochopit jednu položku bez přečtení předchozí?
3. Skenování: Je vzor název-plus-shrnutí užitečnější než mřížka srovnatelných hodnot?
4. Akce: Potřebuje každá položka nejvýše jeden primární cíl?

Pokud jsou odpovědi ano, vlastní výpis je pravděpodobně vhodný. Použijte jiný prvek, když kolekce neprojde některým z těchto testů:

• Použijte odrážkový seznam, když položky potřebují pouze jednu paralelní větu a žádná samostatná metadata.
• Použijte srovnávací tabulku , když čtenáři musí skenovat stejná kritéria vertikálně nebo horizontálně napříč alternativami.
• Použijte produktovou kartu, když obrázek, cena, nabídka, hodnocení, dostupnost a nákupní akce činí každou položku významnou obchodní jednotkou.
• Použijte seznam kroků, když pozice vyjadřuje posloupnost spíše než redakční řazení.
• Použijte glosář nebo definiční vzor, když každá položka je v zásadě dvojice pojem–definice.
• Použijte nadpisy a souvislý text, když položky vyžadují různá pole nebo více než přibližně 100 slov vysvětlení každá.

Nevybírejte vlastní výpis pouze proto, že design volá po opakovaných rámečcích. Nejprve dokažte, že existuje stabilní model obsahu. Pokud má položka jedna cenu, položka dva životopis autora a položka tři velikost souboru ke stažení, nejde o jednu kolekci, i když je CSS dokáže zarovnat.

Kam jej umístit

Umístěte výpis poté, co stránka definuje kolekci a její pravidlo pro zařazení. „Podporované integrace" je označení; „Tyto integrace mohou odesílat auditované stránky do vlastního reportovacího pracovního prostoru" říká čtenářům, co členství znamená. Pokud výběr nebo testování vytvořilo sadu, vysvětlete tuto metodu před první položkou, aby výpis neimplikoval nepodloženou úplnost nebo pořadí.

Umístěte kolekci blízko rozhodovacího nebo navigačního úkolu, kterému slouží. Integrační stránka by měla představit připojení a jeho výsledek před výpisem podporovaných workflow. Adresář by měl vysvětlit rozsah a filtry před zobrazením záznamů. Průvodce seznamem by měl uvést svou metodu hodnocení před představením vybraných položek.

Nepřerušujte výpis souvislým textem, reklamami, výzvami k akci nebo nesouvisejícími snímky obrazovky. Hranice položek musí zůstat souvislé. Umístěte kvalifikace do definovaných metadat dotčené položky nebo vysvětlete podmínku platnou pro celou kolekci před nebo za celý seznam. Pokud je potřeba více než dvanáct položek, seskupte je pod smysluplné podnadpisy, přidejte filtrování nebo nasměrujte čtenáře na Adresářový index . Nevytvářejte nekonečný vizuální blok.

Anatomie

Kompletní vlastní výpis má tyto oblasti:

1. Název kolekce: pojmenovává sadu jazykem čtenáře, nikoli interním názvem komponenty.
2. Prohlášení o rozsahu: definuje, co je způsobilé k zařazení a zda je kolekce úplná, vybraná nebo ilustrativní.
3. Kontejner seznamu: vytváří jednu sémantickou kolekci a nese počet položek.
4. Název položky: jednoznačně identifikuje entitu, zdroj, schopnost nebo možnost.
5. Shrnutí položky: vysvětluje relevantní odlišnost nebo použití položky v jedné nebo dvou větách.
6. Skupina metadat: zobrazuje nula až tři označená fakta z registrovaného schématu.
7. Primární akce: odkazuje na jeden jasný cíl pomocí popisného textu kotvy.
8. Hranice položky: používá mezery, čáru nebo zdrženlivé povrchové úpravy bez odpojení položky od její kolekce.

Prohlášení o rozsahu zabraňuje běžnému selhání přesnosti. „Dostupné integrace" implikuje úplnost; „Běžné reportovací integrace" deklaruje výběr. Autor musí zvolit formulaci, kterou zdrojová data mohou podpořit.

Příklady designu

Renderer může měnit hustotu, ale musí zachovat pořadí polí, sémantickou strukturu seznamu a předvídatelnou posloupnost čtení.

Skládaný redakční výpis

Použijte výchozí skládaný design, když shrnutí nesou většinu hodnoty. Udržte název první, shrnutí druhé, metadata třetí a akci poslední. Stačí jemný oddělovač; každá položka nepotřebuje vyvýšenou kartu.

Kompaktní náhled adresáře

Použijte kompaktní variantu, když názvy a jedna hodnota metadat umožňují čtenářům vybrat cíl. Shrnutí může být kratší, ale označení musí zůstat viditelná. Nikdy nenahrazujte smysluplný stav nevysvětlenou barevnou tečkou.

Seskupený výpis

Použijte skupiny, když jedna stabilní klasifikace rozděluje kolekci osmi až dvaceti čtyř položek do sekcí. Nadpisy skupin musí popisovat skutečnou taxonomii, jako je typ exportu nebo oblast služeb. Neseskupujte pouze pro dosažení stejných sloupců.

Úzké viewport

Při úzkých šířkách zachovejte zdrojové pořadí a skládejte metadata pod shrnutím. Neschovávejte pole, která zůstávají relevantní, nezmenšujte text pro udržení sloupců a nepřesouvejte akce pryč od jejich položky.

Parametry

Níže uvedené schéma je záměrně omezené. Pole se stává součástí komponenty pouze tehdy, když je užitečné napříč kolekcí, nikoli proto, že jedna položka náhodou má pro něj data.

Tři položky jsou minimum, protože dvojice je obvykle přehlednější jako souvislý text, dvousloupcové srovnání nebo dvě výrazné karty. Dvanáct je běžné maximum, protože skenování dlouhého nefiltrovaného bloku se stává neefektivním. Strop seskupení na dvacet čtyři je ochranné omezení, nikoli cíl; větší nebo často se měnící sady potřebují adresář, vyhledávání, stránkování nebo datově řízenou aplikaci.

Zvolte ordered=true pouze tehdy, když viditelné pořadí vyjadřuje deklarované hodnocení. Redakční pohodlí, abecední řazení nebo pořadí ze zdrojových dat nevytváří hodnocení. Když je hodnocení skutečné, uveďte metodologii a zachovejte pozici jak ve viditelném výstupu, tak ve strukturovaných datech.

Syntaxe a příklady kódu

Přenositelná direktiva definuje autorský kontrakt. Adaptéry platforem mohou ukládat data odlišně, ale musí zachovat stejné názvy polí, pořadí položek, volitelnost a viditelný výstup.

Přenositelná Markdown direktiva

:::custom-listing{title="Exportní formáty" variant=stacked}
Toto jsou formáty dostupné pro odesílání dokončených auditních záznamů do jiného pracovního prostoru.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Tabulkové řádky pro analýzu v tabulkovém procesoru a import plochých souborů.

- Nejlepší pro: Analýzu v tabulkovém procesoru
- Dostupnost: Všechny plány
- Akce: Zobrazit nastavení CSV exportu
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Vnořené záznamy, které zachovávají vztahy pro aplikace a datové pipeliny.

- Nejlepší pro: Automatizované workflow
- Dostupnost: Pro a Enterprise
- Akce: Přečíst JSON referenci
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
Synchronizovaný list pro týmy, které pracují s daty bez kódu.

- Nejlepší pro: Sdílenou revizi
- Dostupnost: Pro a Enterprise
- Akce: Připojit Google Sheets
:::
:::

Příkladové URL adresy popisují pouze přenositelnou syntaxi; implementace je musí nahradit ověřenými cíli. Nezveřejňujte příkladovou cestu jako živý odkaz pouze proto, že se objevuje v bloku kódu.

Hugo adaptér

{{< custom-listing title="Exportní formáty" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="Zobrazit nastavení CSV exportu" >}}
  Tabulkové řádky pro analýzu v tabulkovém procesoru a import plochých souborů.

  **Nejlepší pro:** Analýzu v tabulkovém procesoru  
  **Dostupnost:** Všechny plány
  {{< /custom-listing-item >}}
{{< /custom-listing >}}

Tento zápis specifikuje budoucí nebo projektový adaptér; neopravňuje k vytvoření page-lokální shortcode. Všechny parametry jsou pojmenované. Dokud adaptér neexistuje, vykreslujte kolekci jako sémantické HTML s <ul> a <li> nebo jako nativní Markdown, spíše než abyste tiše zahazovali vztahy mezi poli.

WordPress blok

<!-- wp:amicited/custom-listing {"title":"Exportní formáty","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabulkové řádky pro analýzu v tabulkovém procesoru a import plochých souborů.</p>
    <dl><dt>Nejlepší pro</dt><dd>Analýzu v tabulkovém procesoru</dd><dt>Dostupnost</dt><dd>Všechny plány</dd></dl>
    <a href="/docs/exports/csv/">Zobrazit nastavení CSV exportu</a>
  </li>
</ul>
<!-- /wp:amicited/custom-listing -->

Nativní bloky jsou přijatelnou náhradou, když vytvářejí jeden seznam, jednu položku seznamu na záznam, skutečné nadpisy, definiční seznam pro označená metadata a popisné odkazy. Obecný blok Sloupce není spolehlivou náhradou, protože zdrojové pořadí a seskupení položek se často na mobilu rozpadá.

Příklady

Dobrý: konzistentní výpis zdrojů

Migrační zdroje

Tyto zdroje podporují týmy při přípravě, provádění a validaci migrace webu.

1. Pracovní list pro přesměrování — Zaznamenává každou starou URL, její schválený cíl, vlastníka a stav validace. Formát: Tabulkový procesor. Fáze: Plánování. Akce: Stáhnout pracovní list přesměrování.
2. Skript pro validaci při spuštění — Kontroluje stavové kódy, řetězce přesměrování, cíle kanonických URL a indexovatelnost pro migrovanou sadu URL. Formát: Skript. Fáze: Spuštění. Akce: Zkontrolovat nastavení validace.
3. Monitorovací pohled po spuštění — Sleduje chyby procházení a neočekávané změny návštěvnosti po nasazení. Formát: Dashboard. Fáze: Monitorování. Akce: Konfigurovat monitorovací pohled.

Toto funguje, protože každá položka používá stejných pět polí: název, shrnutí, formát, fáze a akce. Rozsah vysvětluje, proč zdroje patří k sobě. Číslování odráží deklarovanou migrační fázi, nikoli tvrzení, že první zdroj je „nejlepší". Každá akce identifikuje svůj cíl namísto opakování „Zjistit více".

Špatný: rámečky bez sdíleného modelu

Užitečné věci

• SEO checklist — Náš oblíbený průvodce. Nedávno aktualizováno. Zjistit více.
• Prémiový audit — 499 €, zahrnuje hovor a zprávu. Pět hvězdiček. Koupit nyní.
• Viktor — Technický vedoucí se sídlem v Bratislavě, k dispozici v úterý.
• API dokumentace — Autentizace, limity, chyby, příklady, SDK, changelog, stav, podpora a dvacet dalších témat.

Toto selhává ještě před začátkem vizuálního designu. Sada mísí zdroj, službu, osobu a oblast dokumentace. Pole se mění u každé položky, „nedávno" nemá datum, hodnocení postrádá zdroj a stupnici a hloubka položky sahá od fragmentu po osnovu sekce. Rozdělte obsah podle účelu, pak zvolte registrovaný prvek pro každou kolekci. Ohraničení kolem nekonzistentních dat nevytváří vlastní výpis.

Špatný: výpis, který by měl být tabulkou

Předpokládejme šest plánů, z nichž každý zobrazuje měsíční cenu, roční cenu, limit uživatelů, úložiště, dobu odezvy podpory a dostupnost SSO. Čtenáři potřebují porovnat stejných šest hodnot napříč všemi plány. Výpis by je donutil pamatovat si plán jedna při procházení plánu šest. Použijte srovnávací tabulku, protože úkolem je porovnávání napříč položkami. Pokud každý plán také potřebuje prohlášení o pozici a nákupní akci, umístěte je mimo tabulku nebo vedle ní pomocí registrované komponenty plánu stránky; nezdvojujte konfliktní hodnoty ve dvou zdrojích.

Značkování schématu a přístupnost

Vykreslete kolekci s nativní sémantikou seznamu. Použijte <ul>, když pořadí položek nemá význam, a <ol>, když stránka deklaruje skutečnou posloupnost nebo hodnocení. Každá položka patří do jednoho <li>. Uvnitř použijte skutečný nadpis na správné úrovni dokumentu, odstavec pro shrnutí a <dl>, <dt> a <dd> pro označená metadata. Čtečka obrazovky by měla narazit na název položky před jejím popisem, fakty a akcí.

Nedělejte celou položku příliš velkým odkazem, pokud obsahuje další ovládací prvek nebo několik textových oblastí. Dejte primárnímu odkazu popisný popisek, například „Zobrazit nastavení CSV exportu." Pokud je použit vzor nataženého odkazu, jeho indikátor fokusu musí zůstat viditelný a jeho přístupný název musí stále popisovat cíl. Ikony potřebují alternativní text pouze tehdy, když sdělují informace, které již nejsou přítomny v textu. Dekorativní ikony by měly být skryty před asistenčními technologiemi.

Vizuální pořadí a zdrojové pořadí se musí shodovat. Více sloupcové desktopové rozvržení se musí sbalit bez čtení položky jedna, položky tři, položky pět a poté položky dva. Popisky metadat nemohou zmizet jen proto, že se opakované hodnoty jeví vizuálně zarovnané; „Enterprise" samo o sobě neříká nevidomému čtenáři, zda popisuje dostupnost, cílovou skupinu nebo podporu.

Strukturovaná data ItemList jsou volitelná, nikoli výchozí stylingový háček. Použijte je, když je viditelná kolekce smysluplný konečný seznam a stránka těží z identifikace této kolekce. Mapujte každou viditelnou položku na itemListElement. Zahrňte position pouze pro skutečný uspořádaný seznam a ujistěte se, že názvy, URL a počty odpovídají vykreslenému obsahu. Neoznačujte navigační menu, libovolné upoutávky na funkce nebo částečnou sadu, jako by šlo o úplný hodnocený seznam. Když jsou položky identifikovatelné entity, jako jsou organizace nebo softwarové aplikace, použijte nejkonkrétnější způsobilý typ pouze tehdy, když stránka dodává a ověřuje požadovaná identifikační data.

Pravidla psaní

1. Vysvětlete členství před představením členů. Čtenáři potřebují vědět, zda je sada úplná, vybraná, sponzorovaná, hodnocená nebo ilustrativní, než začnou interpretovat vynechání nebo pořadí. Uveďte pravidlo pro zařazení ve větě o rozsahu.
2. Definujte jedno schéma položek před psaním položek. Konzistentní pole umožňují čtenářům naučit se jeden vzor skenování a umožňují validaci zachytit chybějící obsah. Zaregistrujte povinná a volitelná pole, než autoři naplní kolekci.
3. Udržujte povinná pole skutečně univerzální. Nominálně povinné pole, které autoři vyplní „N/A" v polovině položek, je špatné pole nebo důkaz, že kolekce obsahuje různé typy položek.
4. Omezte viditelná metadata na tři dvojice. Více polí posouvá úkol směrem k porovnávání a ztěžuje skenování každého řádku. Přesuňte sekundární fakta na cílovou stránku nebo použijte tabulku.
5. Pište shrnutí pro odlišnost, ne pro opakování. Název již položku pojmenovává. Použijte shrnutí k vysvětlení její relevantní schopnosti, cílové skupiny, omezení nebo role.
6. Používejte paralelní popisky a jednotky. Nestřídejte „Plán," „Dostupné na" a „Úroveň" pro stejný koncept. Normalizujte data, měny, jednotky a slovní zásobu stavů před vykreslením.
7. Dejte každé položce jednu primární akci. Konkurenční tlačítka mění referenční seznam v mřížku karet a zakrývají zamýšlený další krok. Umístěte sekundární cíle na stránku s podrobnostmi.
8. Deklarujte smysluplné pořadí. Abecední, chronologické, hodnocené, redakční a pořadí ze zdrojového systému vytvářejí různá očekávání. Pojmenujte pořadí, když by mohlo ovlivnit interpretaci.
9. Nastavte minimální a maximální počty. Použijte běžně tři až dvanáct položek, až dvacet čtyři pouze v užitečných skupinách. Změňte vzor, když kolekce spadá mimo tyto hranice.
10. Udržujte jeden zdroj pravdy. Pokud se cena, stav, dostupnost nebo jiné proměnlivé pole objevuje jinde, naplňte každou reprezentaci ze stejného vlastního zdroje a v případě potřeby uveďte datum ověření.

Typy příspěvků, které jej používají

• Průvodce seznamem používá vlastní výpis, když každá vybraná položka potřebuje stejné shrnutí, vhodnost, omezení a odkaz dále, ale ne hustou srovnávací matici.
• Stránka Nejlepší-X-pro-Y jej může použít pro doporučení specifická pro cílovou skupinu po vysvětlení metody hodnocení. Hodnocení musí být explicitní, nikoli implikované vizuálním pořadím.
• Stránka Alternativy-k-X může prezentovat možnosti náhrady s konzistentními poli „nejlepší pro," kompromis a odkaz na podrobnosti před užším srovnáním.
• Kategorická stránka používá kompaktní nebo seskupený výpis k náhledu zvládnutelné sady dceřiných produktů nebo služeb, když filtrování ještě není nutné.
• Adresářový index používá prvek pouze pro náhled nebo malý, stabilní adresář. Velké sady entit potřebují vyhledávání, filtry, stránkování a datově podložené adresářové rozhraní.
• Profil společnosti může vypsat ověřené obchodní jednotky, certifikace nebo lokality, když každá položka sdílí stejná pole.
• Profil dodavatele může vypsat podporované služby, regiony nebo modely spolupráce, aniž by se profil změnil v mřížku produktů.
• Integrační stránka může vypsat podporované workflow, datové objekty, triggery nebo cíle pomocí předvídatelného schématu schopností a požadavků.

Přítomnost kolekce nevyžaduje tento prvek. Použijte jej pouze tehdy, když vlastní model polí zlepšuje vyhledávání nebo navigaci. Krátká sada předpokladů stále patří do odrážek a matice schopností stále patří do tabulky.

QA kontrolní seznam

• Kolekce má název a větu o rozsahu, která definuje zařazení.
• Každá položka představuje stejný druh entity, zdroje, schopnosti nebo možnosti.
• Povinná a volitelná pole jsou zdokumentována před zadáváním obsahu.
• Každá položka má jedinečné stabilní ID, název a shrnutí o délce 12–60 slov.
• Žádná položka nevymýšlí pole, které chybí v registrovaném schématu.
• Kolekce obsahuje 3–12 položek nebo odůvodněné skupiny s maximálně 24 celkem.
• Položky mají nejvýše tři viditelné dvojice metadat a jednu primární akci.
• Popisky, jednotky, stavy, data a formulace akcí jsou konzistentní.
• Pořadí je deklarováno, když implikuje hodnocení, chronologii nebo prioritu.
• Místo toho byla zvolena tabulka, když je hlavním úkolem porovnávání napříč položkami.
• Výstup používá jeden sémantický <ul> nebo <ol> s jedním <li> na položku.
• Nadpisy následují hierarchii stránky a metadata používají sémantiku pojem–popis.
• Klávesnicový fokus je viditelný a odkazy popisují své cíle.
• Zdrojové pořadí odpovídá vizuálnímu pořadí na desktopu i mobilu.
• Značkování ItemList, pokud je přítomno, odpovídá viditelným položkám, pořadí, počtu, názvům a URL.
• Proměnlivé hodnoty pocházejí z vlastního zdroje a obsahují příslušné datum ověření.

FAQ

Níže uvedené otázky řeší hranice, které nejčastěji způsobují, že se vlastní výpis posouvá k odrážkám, kartám nebo tabulkám.

Co je to vlastní výpis?

Vlastní výpis je opakovatelná kolekce, jejíž položky sdílejí malé, pojmenované schéma polí, například název, shrnutí, metadata a odkaz. Nachází se mezi jednoduchým odrážkovým seznamem a vizuálně nezávislou mřížkou karet.

Kolik položek by měl vlastní výpis obsahovat?

Použijte tři až dvanáct položek jako běžný redakční rozsah. Dvě položky obvykle vyžadují souvislý text nebo komponentu vedle sebe. Více než dvanáct položek vyžaduje užitečné seskupení, filtrování, stránkování nebo adresářový vzor; seskupená varianta nesmí překročit dvacet čtyři položek.

Kdy by se měl vlastní výpis stát tabulkou?

Použijte tabulku, když čtenáři musí porovnávat většinu položek napříč stejnými třemi nebo více poli, zejména číselnými hodnotami, daty, stavy nebo možnostmi ano/ne. Výpis ponechte, když shrnutí a odkazy dále jsou důležitější než porovnávání napříč položkami.

Potřebuje vlastní výpis schéma ItemList?

Ne. Přidejte ItemList pouze tehdy, když je kolekce smysluplná a konečná, každá označená položka je viditelná a jakákoli pozice odráží deklarované pořadí. Běžné navigační, upoutávkové a související výpisy obvykle potřebují sémantické HTML spíše než speciální schéma.

Mohou mít položky různá pole?

Chybět mohou pouze volitelná pole definovaná sdíleným schématem. Nenechte autory vymýšlet pole pro jednotlivé položky. Pokud několik položek potřebuje odlišný informační model, rozdělte je do jiného výpisu nebo zvolte vhodnější prvek.