Spec-tabellen: Opmaak, regels en voorbeelden

Een spec-tabel zet feiten over één onderwerp om in expliciete label-waardeparen. Een lezer kan de bedrijfstemperatuur vinden zonder een productbeschrijving opnieuw te lezen, en een machine kan de relatie tussen ‘Bedrijfstemperatuur’ en ‘−10 tot 45 °C’ behouden zonder te raden welk getal bij welke bewering hoort.

De productnaam en waarden hierboven zijn illustratief. De structuur is het productiemodel: één onderwerp, één precies label per rij, één waarde met bijbehorende eenheid en een expliciete status waar een feitelijke waarde niet kan worden gegeven.

Waarom dit element ertoe doet

Specificatieproza dwingt lezers tot vermijdbare reconstructie. Bedenk: “Het apparaat weegt 6,4 kilogram, levert continu 500 watt, meet 280 bij 190 bij 210 millimeter en kan werken van min 10 tot 45 graden Celsius.” De zin is grammaticaal correct, maar een koper die alleen afmetingen zoekt, moet elke clausule ontleden. Later terugkeren om het vermogen te controleren betekent opnieuw ontleden. Een tabel plaatst de labels in een voorspelbare rand en de waarden in een tweede kolom, waardoor het geheugenwerk vermindert en scannen betrouwbaar wordt.

De structuur is minstens zo belangrijk voor machines. Machine-extraheerbaarheid is het vermogen van een crawler, zoeksysteem, assistent of stroomafwaarts publicatietool om de betekenis en relaties in content te behouden. Native <table>, <th scope="row"> en <td>-opmaak stelt dat de rijkop de aangrenzende waarde kwalificeert. Het produceert een betrouwbaar paar: “Gebruikbare capaciteit — 512 Wh.” Dezelfde twee tekenreeksen, ingebed in promotionele zinnen, vereisen inferentie op taalniveau, en een opgemaakte verzameling niet-gerelateerde <div>-elementen kan visuele uitlijning tonen zonder een gegevensrelatie bloot te leggen.

Doorzoekbaar betekent niet dat elke website een database wordt. Het betekent dat elk feit een stabiel label, een discrete waarde en voorspelbare opmaak heeft, zodat een lezer of systeem naar één eigenschap kan vragen zonder de hele alinea te extraheren. Vergelijkbaar betekent dat afzonderlijk gepubliceerde producten dezelfde canonieke labels en eenheden kunnen gebruiken, zodat waarden later kunnen worden uitgelijnd zonder eerst ‘ongeveer een halve kilowatt’, ‘500 watt’ en ‘0,5 kW’ te normaliseren. Een spec-tabel maakt die latere vergelijking mogelijk; het is zelf geen vergelijking tenzij het meerdere onderwerpen naast elkaar presenteert.

Wanneer gebruiken

Gebruik een spec-tabel wanneer de pagina één entiteit beschrijft en lezers ten minste drie discrete, geverifieerde feiten nodig hebben. Typische onderwerpen zijn een product, softwareplan, API, bestandsformaat, faciliteit, voertuig, organisatie, dienstenpakket of technische standaard. Geschikte feiten hebben afgebakende antwoorden: afmetingen, ondersteunde besturingssystemen, connectortype, responseformaat, garantieperiode, rechtsvorm, dekkingsgebied, versie of een opgegeven limiet.

Gebruik proza rond de tabel om consequenties uit te leggen. ‘Maximaal laadvermogen: 18 kg’ hoort in de tabel; waarom die limiet een bepaalde installatie uitsluit, hoort in proza. De tabel moet antwoorden ‘wat is de waarde?’ terwijl de omringende uitleg antwoordt ‘waarom is het belangrijk?’

Bijna-goede gevallen komen vaak voor:

• Wanneer twee of meer producten op gedeelde criteria moeten worden beoordeeld, gebruik dan een vergelijkingstabel . Een spec-tabel heeft één onderwerp; het toevoegen van meerdere waardekolommen verandert het doel.
• Wanneer de inhoud een reeks gebeurtenissen is, gebruik dan een tijdlijn. Datums in een tabel met twee kolommen maken relaties niet automatisch chronologisch.
• Wanneer elke rij meerdere zinnen uitleg nodig heeft, gebruik dan koppen en proza. Dichte alinea’s in cellen belemmeren scannen en worden onleesbaar op kleine schermen.
• Wanneer de lijst slechts twee eenvoudige feiten bevat, gebruik dan een zin of definitielijst, tenzij het berichttype een geregistreerde spec-tabel vereist. Een tabel moet meerwaarde bieden voor het ophalen, niet een klein feit versieren.
• Wanneer waarden continu veranderen, koppel het element dan aan een eigen gegevensbron en toon een ophaaltijd. Een handmatig gekopieerde ’live’ waarde wordt misleidend zodra deze afwijkt.
• Wanneer het document veldnamen, typen en validatiebeperkingen beschrijft, gebruik dan de gegroepeerde variant hieronder; pers niet het hele gegevensmodel in één proza-zware cel ‘Details’.

De schrijfregels voor elementen hebben voorrang: kies het element op basis van het doel van de passage, niet op basis van de kop of het uiterlijk. Als een blok tot taak heeft specificaties te tonen, blijft het een spec-tabel, zelfs als het thema dezelfde woorden als kaarten zou kunnen weergeven.

Waar plaatsen

Plaats de eerste spec-tabel nadat het onderwerp is geïdentificeerd en voordat de pagina de lezer vraagt te interpreteren, configureren, vergelijken of kopen. Op een productpagina betekent dat normaal gesproken na de beknopte productbeschrijving en het belangrijkste voordeel, maar vóór gedetailleerde functie-uitleg. Zet in documentatie een tabel met vereisten of protocol direct vóór de procedure die ervan afhankelijk is. Lezers moeten weten wat de waarden beschrijven voordat ze deze zien, maar mogen niet door een lang verhaal moeten navigeren om ze te vinden.

Als de pagina meerdere categorieën heeft, plaats dan elke tabel onder een beschrijvende H2 of H3, zoals ‘Fysieke specificaties’ of ‘Compatibiliteit’. Houd de categorietitel buiten de tabel; het bijschrift noemt vervolgens het precieze onderwerp en bereik. Behoud dezelfde labelvolgorde op verwante pagina’s, zodat een lezer het patroon niet opnieuw hoeft te leren.

Plaats geen spec-tabel direct naast een andere dichte tabel, een schermvullende screenshot of een geanimeerde carrousel. Twee concurrerende rasters creëren een onduidelijk leespad en zijn vooral onhandig op tabletbreedtes. Plaats geen call-to-action tussen een bijschrift en de rijen, voetnoten in een niet-gerelateerd onderdeel, of een promotionele bewering in de waardekolom. Houd het bijschrift, de tabel, statuslegenda, verificatiedatum en bronvermelding als één samenhangende eenheid. Laat het volgen door uitleg voordat u een ander gegevenszwaar element introduceert.

Anatomie

Het gelabelde voorbeeld moet deze onderdelen identificeren:

1. Sectiekop: benoemt de categorie wanneer een pagina meer dan één tabel heeft, zoals fysieke of elektrische specificaties.
2. Bijschrift: identificeert het onderwerp en de exacte reikwijdte van de tabel. Het moet betekenisvol zijn buiten de omringende paragraaf.
3. Rijkop: gebruikt de canonieke, ondubbelzinnige naam van één eigenschap.
4. Waarde: bevat één feit in plaats van commentaar of een verkoopclaim.
5. Eenheid: verschijnt bij elke numerieke waarde tenzij de waarde werkelijk eenheidloos is.
6. Statuswaarde: spelt ‘Onbekend’ of ‘Niet van toepassing’ uit in plaats van een lege cel achter te laten.
7. Verificatiedatum: vermeldt wanneer veranderlijke feiten voor het laatst zijn gecontroleerd.
8. Bronvermelding: identificeert het primaire systeem, document, test of eigenaar waaruit de waarden afkomstig zijn.

Onbekend betekent dat de eigenschap van toepassing is, maar dat er op het moment van verificatie geen betrouwbare waarde beschikbaar was. Niet van toepassing betekent dat het uitgangspunt van de eigenschap niet van toepassing is op dit onderwerp. Niet beschikbaar is weer anders: het betekent dat een mogelijkheid of optie ontbreekt. Nul is een gemeten of opgegeven waarde. Een lege cel communiceert geen van deze betekenissen en is daarom niet toegestaan.

Ontwerpvoorbeelden

Elke ontwerpvariant behoudt native tabelopmaak, rijkoppen, zichtbare labels, tekstwaarden en een bijschrift. Stijl kan dichtheid en groepering veranderen, maar het mag de feiten niet in een afbeelding veranderen of kleur de enige drager van betekenis maken.

Standaard twee kolommen: de standaard voor één onderwerp en drie tot twaalf feiten. Labels bezetten de eerste kolom en waarden de tweede. Gebruik het voor product-, bedrijfs-, plan- en servicefeiten.

Gegroepeerd: twee of meer korte tabellen verdelen een grotere specificatieset per lezerstaak. Elke groep krijgt een kop en elke tabel behoudt zijn eigen bijschrift. Gebruik geen samengevoegde scheidingsrijen als visuele koppen, omdat ze navigatie en extractie bemoeilijken.

Veldreferentie: een documentatievariant voor eigenschappen waarvan de betekenis consistente secundaire velden vereist zoals type, vereiste en beperking. De eerste kolom gebruikt rij-kopsemantiek, terwijl elke secundaire dimensie een kolomkop heeft.

Compact mobiel: labels en waarden lopen op natuurlijke wijze terug zonder de lettergrootte te verkleinen. Een eenvoudige tabel met twee kolommen moet binnen de container hervloeien. Een bredere veldreferentie-variant mag scrollen binnen een gelabelde, met toetsenbord focusbare regio; het mag niet de hele pagina horizontaal laten scrollen.

Parameters

Het volgende contract definieert het draagbare element. ‘Bron’ in de laatste kolom geeft aan waar de renderer de parameter verkrijgt, niet waar het feitelijke feit is onderzocht.

Gebruik verified wanneer prijs, compatibiliteit, beschikbaarheid, versieondersteuning, capaciteit of een andere waarde kan veranderen. Een publicatiedatum is geen vervanging: die geeft aan wanneer de pagina is gepubliceerd, niet wanneer de specificatie is gecontroleerd.

Syntax en codevoorbeelden

Alle implementaties gebruiken hetzelfde bijschrift, geordende rijen, statusbetekenissen, verificatiewaarde en bron. Het draagbare directive is de canonieke auteurvorm.

Draagbare Markdown-directive

:::spec-table{caption="Northstar Field 500 — core specifications" verified="2026-08-27"}
| Specificatie | Waarde |
|---|---|
| Gebruikbare capaciteit | 512 Wh |
| Continu AC-uitgang | 500 W |
| Afmetingen (B × H × D) | 280 × 190 × 210 mm |
| Waterbestendigheid | Onbekend |
| Brandstoftype | Niet van toepassing |

Status: Onbekend = relevant maar niet geverifieerd; Niet van toepassing = kan niet van toepassing zijn.

Bron: goedgekeurd gegevensblad product, revisie 4.
:::

Hugo shortcode

De Hugo-adapter moet alleen benoemde parameters accepteren en de pijptabel-body weergeven als semantische tabelrijen. De notatie hieronder definieert de beoogde toewijzing; het impliceert niet dat er een nieuwe lokale shortcode moet worden gemaakt binnen een artikeltaak.

{{< spec-table caption="Northstar Field 500 — core specifications" verified="2026-08-27" >}}
| Specificatie | Waarde |
|---|---|
| Gebruikbare capaciteit | 512 Wh |
| Continu AC-uitgang | 500 W |
| Afmetingen (B × H × D) | 280 × 190 × 210 mm |
| Waterbestendigheid | Onbekend |
| Brandstoftype | Niet van toepassing |

Status: Onbekend = relevant maar niet geverifieerd; Niet van toepassing = kan niet van toepassing zijn.

Bron: goedgekeurd gegevensblad product, revisie 4.
{{< /spec-table >}}

De renderer moet <table>, <caption>, <tbody>, <th scope="row"> en <td> uitvoeren. Een field-reference-variant heeft ook <thead> met scope="col"-koppen nodig. Het moet mintekens, vermenigvuldigingstekens, eenheidsspatiëring en statustekst exact behouden.

WordPress-blok

<!-- wp:amicited/spec-table {"caption":"Northstar Field 500 — core specifications","verified":"2026-08-27","variant":"standard"} -->
<table>
  <tbody>
    <tr><th scope="row">Gebruikbare capaciteit</th><td>512 Wh</td></tr>
    <tr><th scope="row">Continu AC-uitgang</th><td>500 W</td></tr>
    <tr><th scope="row">Afmetingen (B × H × D)</th><td>280 × 190 × 210 mm</td></tr>
    <tr><th scope="row">Waterbestendigheid</th><td>Onbekend</td></tr>
    <tr><th scope="row">Brandstoftype</th><td>Niet van toepassing</td></tr>
  </tbody>
</table>
<p class="spec-table__status">Onbekend = relevant maar niet geverifieerd; Niet van toepassing = kan niet van toepassing zijn.</p>
<p class="spec-table__source">Bron: goedgekeurd gegevensblad product, revisie 4.</p>
<!-- /wp:amicited/spec-table -->

Een WordPress-implementatie kan bewerkbare blokken gebruiken in plaats van letterlijke HTML, maar de opgeslagen attributen en server-gerenderde uitvoer moeten hetzelfde contract behouden. Auteurs mogen geen screenshot of een generiek kolommenblok als vervanging gebruiken.

Voorbeelden

Goed: volledige, genormaliseerde productfeiten

Geverifieerd: 27 augustus 2026. Bron: illustratief goedgekeurd installatieblad, revisie 2.

Dit werkt omdat het bijschrift één onderwerp en één context identificeert. Elk label noemt een toetsbare eigenschap, bereiken behouden hun eenheden, afmetingen mengen geen systemen en maximaal vermogen wordt onderscheiden van typisch vermogen. ‘Niet van toepassing’ is gerechtvaardigd omdat een bedrade sensor geen te vervangen batterij heeft; het verbergt geen onbekende batterijspecificatie. De tabel kan worden gescand door een persoon, worden genavigeerd via rijkoppen of worden omgezet in discrete eigenschap-waardeparen.

Slecht: dubbelzinnige pseudo-gegevens

De slechte tabel oogt georganiseerd maar levert geen betrouwbare gegevens. ‘Vermogen’ kan voedingsspanning of verbruik betekenen, terwijl ‘Laag’ niet meetbaar is. Kabellengte mist een eenheid. De temperatuurrij noemt Celsius of Fahrenheit niet en lijkt een bereik te mengen met een graadsymbool. ‘Robuust’ is promotionele taal in plaats van een beschermingsgraad. De lege batterijcel zegt niet of het feit onbekend, niet relevant, nul of per ongeluk weggelaten is. De compatibiliteitsclaim bundelt een ongedefinieerde populatie en installatieoordeel in één cel.

Herstel het door brede labels te splitsen in canonieke eigenschappen, waarden te verkrijgen uit een benoemde primaire bron, een eenheid toe te voegen aan elke meting en lege plekken te vervangen door de juiste status. Als de bron de beschermingsgraad niet vermeldt, schrijf dan ‘Onbekend’; converteer marketingtaal niet naar een verzonnen technische waarde.

Schema-opmaak en toegankelijkheid

Er is geen algemeen Schema.org-type voor een specificatietabel. De tabel blijft waardevolle semantische HTML, zelfs als het geen JSON-LD produceert. Wanneer de omvattende pagina een in aanmerking komende entiteit vertegenwoordigt, wijs dan alleen exacte, geverifieerde feiten toe aan ondersteunde eigenschappen: bijvoorbeeld de sku, weight, width, height, depth, material of additionalProperty van een product waar van toepassing. Organisatiefeiten kunnen worden toegewezen aan eigenschappen zoals rechtsvorm of adres. De zichtbare tabel en gestructureerde gegevens moeten overeenkomen, dezelfde eenheden gebruiken en uit dezelfde bron komen. Verzin geen beoordelingen, aanbiedingen, identificatoren of schema-eigenschappen omdat er een rij bestaat.

Toegankelijkheid begint met echte opmaak. Geef de tabel een beschrijvend <caption>. Gebruik <th scope="row"> voor elk specificatielabel; field-reference-varianten hebben ook <th scope="col"> in een <thead> nodig. Houd de leesvolgorde logisch in de bron, niet alleen op het scherm. Gebruik geen lege cellen, samengevoegde cellen, alleen-pictogramstatussen, alleen-kleurgroepering of tooltips als enige locatie van een waarde. Afkortingen zoals AC, DC en IP moeten worden uitgeschreven in nabijgelegen proza wanneer de beoogde lezer ze mogelijk niet kent.

Een eenvoudige tabel met twee kolommen moet waar praktisch mogelijk teruglopen in plaats van scrollen. Wanneer een bredere tabel horizontaal scrollen vereist, plaats deze dan in een regio met een toegankelijk label en tabindex="0", behoud een zichtbare toetsenbordfocusindicator en vergrendel nooit de eerste kolom op een manier die waarden bedekt bij hoge zoom. Test bij 200% zoom, met toetsenbordnavigatie en met uitgeschakelde stijlen; de label-waarderelatie moet alle drie overleven.

Schrijfregels

De regels beschermen het ophalen en vergelijken, dus precisie gaat vóór beknoptheid:

• Gebruik 3–12 rijen per tabel. Splits langere sets per lezerstaak — fysiek, elektrisch, compatibiliteit, commercieel — in plaats van een ongedifferentieerde muur van feiten te creëren.
• Houd labels waar mogelijk op 1–6 woorden. Gebruik een kwalificatie zoals ‘maximaal’, ’typisch’, ‘geïnstalleerd’ of ‘per gebruiker’ wanneer dit de betekenis verandert.
• Houd een normale waarde op één regel en maximaal 12 woorden. Verplaats interpretatie, uitzonderingen en aanbevelingen naar aangrenzend proza of een direct gerelateerde notitie.
• Gebruik één meetsysteem per tabel, tenzij het publiek beide nodig heeft. Wanneer beide vereist zijn, presenteer dan de primaire waarde eerst en de omrekening tussen haakjes voor elke toepasselijke rij.
• Zet een eenheid naast elke numerieke meting: 512 Wh, 3 m en 45 °C. Vertrouw nooit op een kop om een eenheid aan slechts enkele rijen te leveren.
• Normaliseer gelijkwaardige eigenschappen over verwante pagina’s. Kies één label en één eenheid — zoals ‘Gewicht’ in kilogram — en wissel niet af met ‘Massa’, ponden of vage zinnen zonder gedocumenteerde reden.
• Gebruik exacte statuswoorden: Onbekend, Niet van toepassing of Niet beschikbaar. Definieer ze eenmalig wanneer meer dan één status voorkomt. Gebruik nooit een streepje, lege cel, TBC, vraagteken of kleur om status te impliceren.
• Gebruik een feitelijke, neutrale toon. Waarden mogen gunstig zijn, maar woorden zoals ‘geweldig’, ‘ultrasnel’, ‘beste in zijn klasse’ en ‘royal’ zijn conclusies, geen specificaties.
• Plaats nooit calls-to-action, getuigenissen, alinea’s verkooptekst, onverklaarde scores, niet-ondersteunde vergelijkingen of decoratieve afbeeldingen in een waardecel.
• Vermeld de bron en een exacte verificatiedatum voor veranderlijke of extern beweerde waarden. Als eigendom onduidelijk is, is de tabel niet klaar voor publicatie.

Berichttypen die het gebruiken

Het postTypes frontmatter-veld bepaalt de goedgekeurde toepassingen hieronder. Opname betekent dat het berichttype het element kan vereisen of er baat bij kan hebben; het betekent niet dat elke pagina drie feiten moet verzinnen om aan een lay-out te voldoen.

QA-checklist

• De tabel beschrijft één duidelijk geïdentificeerd onderwerp; meerdere opties zijn niet vermomd als een spec-tabel.
• Het bijschrift noemt zowel het onderwerp als de reikwijdte van de tabel.
• Elke eigenschap gebruikt een precies, canoniek label en elke cel bevat één waarde.
• Numerieke waarden bevatten consistente eenheden, kwalificaties, bereiken en dimensies.
• Geen cel is leeg; Onbekend, Niet van toepassing en Niet beschikbaar worden alleen gebruikt met hun gedefinieerde betekenissen.
• Beweringen komen overeen met een benoemde primaire bron en veranderlijke feiten tonen een exacte verificatiedatum.
• De gepubliceerde uitvoer gebruikt native <table>, <caption>, rijkoppen en gegevenscellen in plaats van een afbeelding of visueel raster.
• Field-reference-varianten bevatten kolomkoppen en behouden alle koprelaties.
• De tabel werkt op smalle breedtes, bij 200% zoom, met toetsenbordnavigatie en met uitgeschakelde stijlen.
• Kleur, pictogrammen, afkortingen en tooltips zijn nooit de enige manier om een waarde te begrijpen.
• Zichtbare feiten en eventuele in aanmerking komende Schema.org-eigenschappen komen exact overeen.
• Promotionele claims, interpretatie, calls-to-action en lange proza staan buiten de tabel.
• Het element volgt de voorrangsregel van het playbook en het geselecteerde berichttype bevat het element in zijn contentcontract.