Aangepaste Lijsten: Itemschema, Limieten en Voorbeelden

Een aangepaste lijst is een herhaalbare verzameling items die een klein veldschema delen. Elk item kan een titel, een beknopte samenvatting, een of twee metadatawaarden en een bestemmingslink hebben. Die structuur geeft lezers meer context dan een opsommingstekenlijst zonder elk item te laten gedragen als een zelfstandige productkaart .

Voorbeeld — ondersteunde exportformaten

• CSV — Tabellarische rijen voor spreadsheetanalyse. Het best voor platte records. Beschikbaarheid: Alle abonnementen. Actie: Bekijk CSV-exportinstellingen.
• JSON — Geneste records voor toepassingen en datapijplijnen. Het best voor het behouden van veldrelaties. Beschikbaarheid: Pro en Enterprise. Actie: Lees de JSON-referentie.
• Google Sheets — Een gesynchroniseerd werkblad voor teams die data beoordelen zonder code. Beschikbaarheid: Pro en Enterprise. Actie: Verbind Google Sheets.

Het weergegeven element mag geen decoratieve versie van die opsommingstekens zijn. Het moet één verzameling met drie items tonen, en elk item moet dezelfde velden title, summary, bestFor, availability en url behouden. Het veldmodel — niet de rand, het pictogram of het aantal kolommen — maakt de lijst aangepast.

Waarom dit element ertoe doet

Gewoon proza verbergt herhaling. Als zes integraties in zes alinea’s worden beschreven, moet een lezer ontdekken dat elke alinea een systeemnaam, ondersteunde actie, accountvereiste en instellink bevat. Een aangepaste lijst benoemt die terugkerende onderdelen via één itemschema: een gedefinieerde set velden die door elk item wordt gebruikt. Lezers leren het patroon na het eerste item en kunnen latere items voorspelbaar scannen.

Die consistentie verbetert ook herbruikbaarheid. Een contentmanagementsysteem kan vereiste velden valideren, een sjabloon kan elk item weergeven zonder paginaspecifieke opmaak, en een stroomafwaartse toepassing kan dezelfde bron omzetten in een compacte mobiele lijst of een doorzoekbare directory. Zoekmachines en AI-systemen ontvangen discrete itemgrenzen in plaats van te moeten afleiden waar de ene entiteit eindigt en de andere begint.

Het element is belangrijk omdat er een veelvoorkomende kloof is tussen twee geldige structuren. Opsommingstekens werken wanneer elk item één compacte verklaring is. Kaarten werken wanneer elk item onafhankelijke afbeeldingen, meerdere commerciële kenmerken, een prominente actie of voldoende visueel gewicht nodig heeft om zelfstandig te staan. Veel verzamelingen hebben geen van beide extremen nodig. Een integratielijst vereist mogelijk een naam, een samenvatting van twee zinnen over de mogelijkheden, een status en een link. Dat platmaken in opsommingstekens verliest de velden; het opblazen tot kaarten verspilt ruimte en laat een referentieverzameling aanvoelen als promotie.

Structuur is geen excuus om elke verzameling maatwerk te maken. Een eenmalig ontwerp leidt tot inconsistente velden, ordening, toegankelijkheid en responsief gedrag. De element-schrijfregels gelden daarom eerst: identificeer de terugkerende informatiebehoefte, registreer het kleinste schema dat hieraan voldoet en houd de inhoud draagbaar tussen verschillende renderers.

Wanneer gebruiken

Gebruik een aangepaste lijst wanneer alle items dezelfde lezersvraag beantwoorden, elk twee tot vijf zichtbare velden nodig heeft en de primaire taak is om te inspecteren of navigeren in plaats van elke waarde naast elkaar te vergelijken. Geschikte verzamelingen zijn onder andere integraties, servicegebieden, ondersteunde formaten, downloadbare bronnen, partnertypes, teamverantwoordelijkheden, directoryvoorbeelden en gegroepeerde functies.

Voer vier tests uit voordat u ervoor kiest:

1. Herhaalbaarheid: Kan elk item dezelfde vereiste velden gebruiken zonder uitzonderingen te verzinnen?
2. Onafhankelijkheid: Kan een lezer één item begrijpen zonder het vorige item te lezen?
3. Scanbaarheid: Is het patroon van titel-plus-samenvatting nuttiger dan een raster van vergelijkbare waarden?
4. Actie: Heeft elk item niet meer dan één primaire bestemming nodig?

Als de antwoorden ja zijn, is een aangepaste lijst waarschijnlijk geschikt. Gebruik een ander element wanneer de verzameling een van die tests niet doorstaat:

• Gebruik een opsommingstekenlijst wanneer items slechts één parallelle zin nodig hebben en geen aparte metadata.
• Gebruik een vergelijkingstabel wanneer lezers dezelfde criteria verticaal of horizontaal over alternatieven moeten kunnen scannen.
• Gebruik een productkaart wanneer afbeelding, prijs, aanbieding, beoordeling, beschikbaarheid en aankoopactie van elk item een substantiële commerciële eenheid maken.
• Gebruik een stappenlijst wanneer positie de volgorde uitdrukt in plaats van redactionele ordening.
• Gebruik een woordenlijst of definitiesjabloon wanneer elk item fundamenteel een term-definitiepaar is.
• Gebruik koppen en proza wanneer items verschillende velden of meer dan ongeveer 100 woorden uitleg per stuk nodig hebben.

Selecteer geen aangepaste lijst alleen omdat het ontwerp om herhaalde blokken vraagt. Bewijs eerst dat er een stabiel contentmodel bestaat. Als item één een prijs heeft, item twee een auteursbiografie en item drie een downloadgrootte, dan zijn het geen verzameling, zelfs niet als CSS ze kan uitlijnen.

Waar plaatsen

Plaats de lijst nadat de pagina de verzameling en de inclusieregel heeft gedefinieerd. “Ondersteunde integraties” is een label; “Deze integraties kunnen gecontroleerde pagina’s naar een eigen rapportagewerkruimte sturen” vertelt lezers wat lidmaatschap betekent. Wanneer selectie of testen de set hebben gecreëerd, leg die methode dan uit vóór het eerste item, zodat de lijst geen ongefundeerde volledigheid of rangschikking impliceert.

Zet de verzameling dicht bij de beslissings- of navigatietaak die ze dient. Een integratiepagina moet de verbinding en het resultaat introduceren voordat ondersteunde workflows worden opgesomd. Een directory moet de reikwijdte en filters uitleggen voordat items worden getoond. Een lijstgids moet de evaluatiemethode vermelden voordat geselecteerde items worden gepresenteerd.

Onderbreek een lijst niet met proza, advertenties, calls-to-action of niet-gerelateerde screenshots. Itemgrenzen moeten opeenvolgend blijven. Plaats kwalificaties binnen de gedefinieerde metadata van het betreffende item of leg een verzamelingsbrede conditie uit vóór of na de hele lijst. Als meer dan twaalf items nodig zijn, groepeer ze dan onder betekenisvolle subkoppen, voeg filters toe of stuur lezers naar een Directory-index . Creëer geen eindeloze visuele stapel.

Anatomie

Een volledige aangepaste lijst heeft deze onderdelen:

1. Verzamelingstitel: benoemt de set in de taal van de lezer, niet de interne naam van de component.
2. Reikwijdtestatement: definieert wat in aanmerking komt voor opname en of de verzameling compleet, geselecteerd of illustratief is.
3. Lijstcontainer: vestigt één semantische verzameling en bezit het itemaantal.
4. Itemtitel: identificeert uniek de entiteit, bron, mogelijkheid of optie.
5. Itemsamenvatting: legt het relevante verschil of gebruik van het item uit in een of twee zinnen.
6. Metadatagroep: toont nul tot drie gelabelde feiten uit het geregistreerde schema.
7. Primaire actie: linkt naar één duidelijke bestemming met beschrijvende ankertekst.
8. Itemgrens: gebruikt witruimte, een lijn of een terughoudende oppervlaktebehandeling zonder het item los te koppelen van de verzameling.

Het reikwijdtestatement voorkomt een veelvoorkomende nauwkeurigheidsfout. “Beschikbare integraties” impliceert volledigheid; “Veelgebruikte rapportage-integraties” verklaart een selectie. De auteur moet de bewoording kiezen die de brongegevens kunnen ondersteunen.

Ontwerpvoorbeelden

De renderer mag de dichtheid variëren, maar moet veldvolgorde, semantische lijststructuur en een voorspelbare leesvolgorde behouden.

Gestapelde redactionele lijst

Gebruik het standaard gestapelde ontwerp wanneer samenvattingen de meeste waarde dragen. Houd de titel eerst, samenvatting tweede, metadata derde en actie als laatste. Een subtiele scheidingslijn is voldoende; elk item heeft geen verhoogde kaart nodig.

Compact directoryvoorbeeld

Gebruik een compacte variant wanneer titels en één metadatawaarde lezers een bestemming laten kiezen. De samenvatting mag korter zijn, maar labels moeten zichtbaar blijven. Vervang nooit een betekenisvolle status door een onverklaarde gekleurde stip.

Gegroepeerde lijst

Gebruik groepen wanneer één stabiele classificatie een verzameling van acht tot vierentwintig items verdeelt in secties. Groepskoppen moeten een echte taxonomie beschrijven, zoals exporttype of serviceregio. Groepeer niet alleen om gelijke kolommen te krijgen.

Smal beeldvenster

Bij smalle breedtes behoudt u de bronvolgorde en stapelt u metadata onder de samenvatting. Verberg geen velden die relevant blijven, krimp geen tekst om kolommen te behouden en verplaats geen acties weg van hun item.

Parameters

Het onderstaande schema is bewust beperkt. Een veld wordt alleen onderdeel van de component wanneer het nuttig is voor de hele verzameling, niet omdat één item er toevallig gegevens voor heeft.

Drie items zijn het minimum omdat een paar meestal duidelijker is als proza, een tweekolomsvergelijking of twee substantiële kaarten. Twaalf is het normale maximum omdat het scannen van een lange ongefilterde stapel inefficiënt wordt. Het gegroepeerde maximum van vierentwintig is een vangrail, geen doel; grotere of vaak veranderende sets hebben een directory, zoekfunctie, paginering of een datagestuurde toepassing nodig.

Kies ordered=true alleen wanneer de zichtbare volgorde een verklaarde rangschikking uitdrukt. Redactioneel gemak, alfabetische sortering of databronvolgorde creëert geen rangorde. Wanneer rangschikking echt is, vermeld dan de methodologie en behoud de positie in zowel de zichtbare uitvoer als eventuele gestructureerde data.

Syntax en codevoorbeelden

De draagbare richtlijn definieert het auteurscontract. Platformadapters mogen de gegevens anders opslaan, maar moeten dezelfde veldnamen, itemvolgorde, optionaliteit en zichtbare uitvoer behouden.

Draagbare Markdown-richtlijn

:::custom-listing{title="Export formats" variant=stacked}
Dit zijn de formaten die beschikbaar zijn voor het versturen van voltooide auditrecords naar een andere werkruimte.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Tabellarische rijen voor spreadsheetanalyse en bestandsimport.

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

:::item{id=json title="JSON" url="/docs/exports/json/"}
Geneste records die relaties behouden voor toepassingen en datapijplijnen.

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

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
Een gesynchroniseerd werkblad voor teams die data beoordelen zonder code.

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

De voorbeeld-URL’s beschrijven alleen de draagbare syntax; een implementatie moet ze vervangen door geverifieerde bestemmingen. Publiceer geen voorbeeldpad als een live link alleen omdat het in een codeblok verschijnt.

Hugo-adapter

{{< custom-listing title="Export formats" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="View CSV export setup" >}}
  Tabellarische rijen voor spreadsheetanalyse en bestandsimport.

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

Deze notatie specificeert een toekomstige of projectniveau-adapter; het autoriseert niet het maken van een paginalokale shortcode. Alle parameters zijn benoemd. Totdat een adapter bestaat, geeft u de verzameling weer als semantische HTML met <ul> en <li> of als native Markdown, in plaats van de veldrelaties stilzwijgend te negeren.

WordPress-blok

<!-- wp:amicited/custom-listing {"title":"Export formats","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabellarische rijen voor spreadsheetanalyse en bestandsimport.</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 -->

Native blokken zijn een acceptabele reserve wanneer ze één lijst, één lijstitem per item, echte koppen, een definitielijst voor gelabelde metadata en beschrijvende links produceren. Een generiek Kolommen-blok is geen betrouwbaar alternatief omdat bronvolgorde en itemgroepering vaak breken op mobiel.

Voorbeelden

Goed: een consistente bronnenlijst

Migratiebronnen

Deze bronnen ondersteunen teams bij het voorbereiden, uitvoeren en valideren van een websitemigratie.

1. Omleidingswerkblad — Registreert elke oude URL, de goedgekeurde bestemming, eigenaar en validatiestatus. Formaat: Spreadsheet. Fase: Planning. Actie: Download het omleidingswerkblad.
2. Validatiescript voor lanceringsdag — Controleert responscodes, redirectketens, canonieke doelen en indexeerbaarheid voor de gemigreerde URL-set. Formaat: Script. Fase: Lancering. Actie: Bekijk de validatie-instellingen.
3. Monitoringsweergave na lancering — Volgt crawlfouten en onverwachte verkeerswijzigingen na implementatie. Formaat: Dashboard. Fase: Monitoren. Actie: Configureer de monitoringsweergave.

Dit werkt omdat elk item dezelfde vijf velden gebruikt: titel, samenvatting, formaat, fase en actie. De reikwijdte legt uit waarom de bronnen bij elkaar horen. De nummering weerspiegelt de aangegeven migratiefase, niet een bewering dat de eerste bron de “beste” is. Elke actie identificeert zijn bestemming in plaats van “Meer informatie” te herhalen.

Slecht: blokken zonder gedeeld model

Handige dingen

• SEO-checklist — Onze favoriete gids. Recent bijgewerkt. Meer informatie.
• Premium-audit — €499, inclusief gesprek en rapport. Vijf sterren. Nu kopen.
• Viktor — Technisch leider in Bratislava, beschikbaar op dinsdagen.
• API-documentatie — Authenticatie, limieten, fouten, voorbeelden, SDK’s, changelog, status, ondersteuning en twintig andere onderwerpen.

Dit faalt nog voordat het visuele ontwerp begint. De set mengt een bron, dienst, persoon en documentatiegebied. Velden veranderen per item, “recent” heeft geen datum, de beoordeling mist een bron en schaal, en de diepte van items varieert van een fragment tot een sectieoverzicht. Splits de inhoud op doel, kies dan het geregistreerde element voor elke verzameling. Een rand rond inconsistente data creëert geen aangepaste lijst.

Slecht: een lijst die een tabel zou moeten zijn

Stel dat zes abonnementen elk de maandprijs, jaarprijs, gebruikerslimiet, opslag, ondersteuningsrespons en SSO-beschikbaarheid tonen. Lezers moeten dezelfde zes waarden over elk abonnement vergelijken. Een lijst zou hen dwingen abonnement één te onthouden terwijl ze door abonnement zes scrollen. Gebruik een vergelijkingstabel omdat de taak evaluatie tussen items is. Als elk abonnement ook een positioneringsverklaring en aankoopactie nodig heeft, plaats die dan buiten of naast de tabel met de geregistreerde abonnementscomponent van de pagina; dupliceer geen conflicterende waarden in twee bronnen.

Schema-opmaak en toegankelijkheid

Geef de verzameling weer met native lijstsemantiek. Gebruik <ul> wanneer itemvolgorde geen betekenis heeft en <ol> wanneer de pagina een echte volgorde of rangschikking verklaart. Elk item hoort in één <li>. Gebruik daarbinnen een echte kop op het juiste documentniveau, een alinea voor de samenvatting en <dl>, <dt> en <dd> voor gelabelde metadata. Een schermlezer moet de itemtitel tegenkomen vóór de beschrijving, feiten en actie.

Maak niet het hele item tot een oversized link wanneer het een ander besturingselement of meerdere tekstgebieden bevat. Geef de primaire link een beschrijvend label zoals “Bekijk CSV-exportinstellingen.” Als een stretched-link-patroon wordt gebruikt, moet de focusindicator zichtbaar blijven en moet de toegankelijke naam nog steeds de bestemming beschrijven. Pictogrammen hebben alleen alternatieve tekst nodig wanneer ze informatie communiceren die niet al in tekst aanwezig is. Decoratieve pictogrammen moeten verborgen zijn voor ondersteunende technologie.

Visuele volgorde en bronvolgorde moeten overeenkomen. Een meerkoloms desktoplay-out moet instorten zonder item één, item drie, item vijf, dan item twee te lezen. Metadatalabels mogen niet verdwijnen alleen omdat herhaalde waarden visueel uitgelijnd lijken; “Enterprise” alleen vertelt een niet-visuele lezer niet of het beschikbaarheid, doelgroep of ondersteuning beschrijft.

ItemList gestructureerde data is optioneel, geen standaard stylinghook. Gebruik het wanneer de zichtbare verzameling een betekenisvolle eindige lijst is en de pagina baat heeft bij het identificeren van die verzameling. Wijs elk zichtbaar item toe aan itemListElement. Neem position alleen op voor een echte geordende lijst, en zorg dat namen, URL’s en aantallen overeenkomen met de weergegeven inhoud. Markeer geen navigatiemenu’s, willekeurige functieteasers of een gedeeltelijke set alsof het een complete gerangschikte lijst is. Wanneer items identificeerbare entiteiten zijn zoals organisaties of softwaretoepassingen, gebruik dan het meest specifieke geschikte type alleen wanneer de pagina de vereiste identiteitsgegevens levert en verifieert.

Schrijfregels

1. Leg lidmaatschap uit voordat je items presenteert. Lezers moeten weten of de set compleet, geselecteerd, gesponsord, gerangschikt of illustratief is voordat ze weglating of volgorde interpreteren. Vermeld de inclusieregel in de reikwijdtezin.
2. Definieer één itemschema voordat je items opstelt. Consistente velden laten lezers één scanpatroon leren en laten validatie ontbrekende inhoud opvangen. Registreer vereiste en optionele velden voordat auteurs de verzameling vullen.
3. Houd vereiste velden echt universeel. Een nominaal vereist veld dat auteurs in de helft van de items met “N.v.t.” vullen, is het verkeerde veld of bewijs dat de verzameling verschillende itemtypes bevat.
4. Beperk zichtbare metadata tot drie paren. Meer velden verschuiven de taak naar vergelijking en maken elke rij moeilijk scannend. Verplaats secundaire feiten naar de bestemmingspagina of gebruik een tabel.
5. Schrijf samenvattingen voor verschil, niet voor herhaling. De titel benoemt het item al. Gebruik de samenvatting om de relevante mogelijkheid, doelgroep, beperking of rol uit te leggen.
6. Gebruik parallelle labels en eenheden. Wissel niet af tussen “Abonnement,” “Beschikbaar op,” en “Niveau” voor hetzelfde concept. Normaliseer datums, valuta’s, eenheden en statuswoorden voordat je weergeeft.
7. Geef elk item één primaire actie. Concurrerende knoppen maken van een referentielijst een kaartenraster en verdoezelen de beoogde volgende stap. Plaats secundaire bestemmingen op de detailpagina.
8. Verklaar betekenisvolle volgorde. Alfabetische, chronologische, gerangschikte, redactionele en bronsysteemvolgordes creëren verschillende verwachtingen. Noem de volgorde wanneer deze de interpretatie kan beïnvloeden.
9. Stel minimum- en maximumaantallen in. Gebruik drie tot twaalf items normaal, met maximaal vierentwintig alleen in nuttige groepen. Wissel van patroon wanneer de verzameling buiten die grenzen valt.
10. Onderhoud één bron van waarheid. Als prijs, status, beschikbaarheid of een ander vluchtig veld elders voorkomt, vul dan elke representatie uit dezelfde eigen bron en vermeld waar nodig een verificatiedatum.

Posttypes die het gebruiken

• Een Lijstgids gebruikt een aangepaste lijst wanneer elk geselecteerd item dezelfde samenvatting, geschiktheid, beperking en vervolg-link nodig heeft, maar geen dichte vergelijkingsmatrix.
• Een Beste-X-voor-Y-pagina kan het gebruiken voor doelgroepspecifieke aanbevelingen na het uitleggen van de evaluatiemethode. Rangschikking moet expliciet zijn in plaats van geïmpliceerd door visuele volgorde.
• Een Alternatieven-voor-X-pagina kan vervangingsopties presenteren met consistente “het best voor”, afwegingen en detail-linkvelden voordat een smallere vergelijking volgt.
• Een Categoriepagina gebruikt een compacte of gegroepeerde lijst om een beheersbare set onderliggende producten of diensten te voorvertonen wanneer filtering nog niet nodig is.
• Een directory-index gebruikt het element alleen voor een voorvertoning of een kleine, stabiele directory. Grote entiteitssets hebben zoeken, filters, paginering en een datagestuurde directory-interface nodig.
• Een Bedrijfsprofiel kan geverifieerde bedrijfseenheden, certificeringen of locaties vermelden wanneer elk item dezelfde velden deelt.
• Een Leveranciersprofiel kan ondersteunde diensten, regio’s of betrokkenheidsmodellen vermelden zonder het profiel in een productraster te veranderen.
• Een Integratiepagina kan ondersteunde workflows, data-objecten, triggers of bestemmingen vermelden met een voorspelbaar mogelijkheid-en-vereiste-schema.

De aanwezigheid van een verzameling vereist niet dit element. Gebruik het alleen wanneer het aangepaste veldmodel het ophalen of navigeren verbetert. Een korte set vereisten hoort nog steeds in opsommingstekens en een matrix van mogelijkheden hoort nog steeds in een tabel.

QA-checklist

• De verzameling heeft een titel en een reikwijdtezin die inclusie definieert.
• Elk item vertegenwoordigt hetzelfde type entiteit, bron, mogelijkheid of optie.
• Vereiste en optionele velden zijn gedocumenteerd vóór het invoeren van inhoud.
• Elk item heeft een unieke stabiele ID, titel en samenvatting van 12–60 woorden.
• Geen enkel item verzint een veld dat ontbreekt in het geregistreerde schema.
• De verzameling bevat 3–12 items, of gerechtvaardigde groepen met maximaal 24 totaal.
• Items hebben niet meer dan drie zichtbare metadata-paren en één primaire actie.
• Labels, eenheden, statussen, datums en actiebewoording zijn consistent.
• Volgorde is verklaard wanneer deze rangschikking, chronologie of prioriteit impliceert.
• Er is een tabel gekozen in plaats daarvan wanneer vergelijking tussen items de hoofdtaak is.
• De uitvoer gebruikt één semantische <ul> of <ol> met één <li> per item.
• Koppen volgen de paginahiërarchie en metadata gebruikt term-beschrijving-semantiek.
• Toetsenbordfocus is zichtbaar en links beschrijven hun bestemmingen.
• Bronvolgorde komt overeen met visuele volgorde op desktop- en mobiele breedtes.
• ItemList-opmaak, indien aanwezig, komt overeen met de zichtbare items, volgorde, aantal, namen en URL’s.
• Vluchtige waarden komen uit een eigen bron en bevatten een passende verificatiedatum.

FAQ

De onderstaande vragen lossen de grenzen op die er het vaakst voor zorgen dat een aangepaste lijst afdrijft naar opsommingstekens, kaarten of tabellen.

Wat is een aangepaste lijst?

Een aangepaste lijst is een herhaalbare verzameling waarvan de items een klein, benoemd veldschema delen, zoals titel, samenvatting, metadata en link. Het zit tussen een eenvoudige opsommingstekenlijst en een visueel onafhankelijk kaartenraster in.

Hoeveel items moet een aangepaste lijst bevatten?

Gebruik drie tot twaalf items als normale redactionele bandbreedte. Twee items hebben meestal proza of een naast-elkaar-component nodig. Meer dan twaalf items hebben nuttige groepering, filtering, paginering of een directorypatroon nodig; de gegroepeerde variant mag niet meer dan vierentwintig items bevatten.

Wanneer moet een aangepaste lijst een tabel worden?

Gebruik een tabel wanneer lezers de meeste items moeten vergelijken op dezelfde drie of meer velden, met name numerieke waarden, datums, statussen of ja/nee-mogelijkheden. Houd een lijst aan wanneer samenvattingen en vervolglinks belangrijker zijn dan vergelijking tussen items.

Heeft een aangepaste lijst ItemList-schema nodig?

Nee. Voeg ItemList alleen toe wanneer de verzameling betekenisvol en eindig is, elk gemarkeerd item zichtbaar is en elke positie een verklaarde volgorde weerspiegelt. Gewone navigatie-, teaser- en gerelateerde-inhoudslijsten hebben meestal semantische HTML nodig in plaats van speciaal schema.

Kunnen items verschillende velden hebben?

Alleen optionele velden die zijn gedefinieerd door het gedeelde schema mogen ontbreken. Laat auteurs niet per item velden verzinnen. Als meerdere items een ander informatiemodel nodig hebben, splits ze dan in een andere lijst of kies een geschikter element.