Specifikační tabulky: Formát, pravidla a příklady

Specifikační tabulka převádí fakta o jednom subjektu na explicitní dvojice popisek–hodnota. Čtenář najde provozní teplotu, aniž by znovu četl popis produktu, a stroj dokáže zachovat vztah mezi „Provozní teplota“ a „−10 až 45 °C“, aniž by musel hádat, které číslo patří ke kterému tvrzení.

Název produktu a výše uvedené hodnoty jsou ilustrativní. Struktura je produkční model: jeden subjekt, jeden přesný popisek na řádek, jedna hodnota s jednotkou a explicitní stav tam, kde nelze uvést věcnou hodnotu.

Proč na tomto prvku záleží

Specifikační próza nutí čtenáře k vykonávání vyhnutelné rekonstrukce. Představte si: „Jednotka váží 6,4 kilogramu, dodává nepřetržitě 500 wattů, měří 280 na 190 na 210 milimetrů a může pracovat od minus 10 do 45 stupňů Celsia.“ Věta je gramaticky správná, ale kupující, který hledá pouze rozměry, musí parsovat každou větu. Když se později vrací pro kontrolu výstupu, musí parsovat znovu. Tabulka přesouvá popisky do předvídatelného okraje a hodnoty do druhého sloupce, čímž snižuje paměťovou zátěž a umožňuje spolehlivé skenování.

Struktura je stejně důležitá i pro stroje. Strojová extrahovatelnost je schopnost crawleru, vyhledávacího systému, asistenta nebo navazujícího publikačního nástroje zachovat význam a vztahy v obsahu. Nativní značení <table>, <th scope="row"> a <td> udává, že řádková hlavička kvalifikuje sousední hodnotu. Vytváří spolehlivou dvojici: „Využitelná kapacita — 512 Wh.“ Stejné dva řetězce vložené mezi propagační věty vyžadují inferenci na úrovni jazyka a stylizovaná kolekce nesouvisejících prvků <div> může odhalit vizuální zarovnání, aniž by odhalila datový vztah.

Dotazovatelnost neznamená, že se každý web stane databází. Znamená to, že každý fakt má stabilní popisek, diskrétní hodnotu a předvídatelné značení, takže čtenář nebo systém může požádat o jednu vlastnost, aniž by extrahoval celý odstavec. Srovnatelnost znamená, že samostatně publikované produkty mohou používat stejné kanonické popisky a jednotky, což umožňuje pozdější porovnání hodnot bez předchozí normalizace „asi půl kilowattu“, „500 wattů“ a „0,5 kW“. Specifikační tabulka umožňuje toto pozdější srovnání; není sama o sobě srovnáním, pokud neprezentuje více subjektů vedle sebe.

Kdy jej použít

Použijte specifikační tabulku, když stránka popisuje jednu entitu a čtenáři potřebují nejméně tři diskrétní, ověřená fakta. Typickými subjekty jsou produkt, softwarový plán, API, formát souboru, zařízení, vozidlo, organizace, balíček služeb nebo technická norma. Vhodná fakta mají ohraničené odpovědi: rozměry, podporované operační systémy, typ konektoru, formát odpovědi, záruční doba, právní název, oblast pokrytí, verze nebo stanovený limit.

Použijte prózu kolem tabulky k vysvětlení důsledků. „Maximální užitečné zatížení: 18 kg“ patří do tabulky; proč tento limit vylučuje konkrétní instalaci, patří do prózy. Tabulka by měla odpovědět na otázku „jaká je hodnota?“, zatímco okolní vysvětlení odpovídá na otázku „proč na tom záleží?“

Běžné případy blízké chybě:

• Pokud musí být dva nebo více produktů posuzovány podle sdílených kritérií, použijte místo toho srovnávací tabulku . Specifikační tabulka má jeden subjekt; přidání několika sloupců hodnot mění její účel.
• Pokud je obsahem sekvence událostí, použijte časovou osu. Data ve dvousloupcové tabulce automaticky neznamenají chronologické vztahy.
• Pokud každý řádek vyžaduje několik vět interpretace, použijte nadpisy a prózu. Husté odstavce uvnitř buněk znemožňují skenování a jsou obtížné na úzkých obrazovkách.
• Pokud seznam obsahuje pouze dvě jednoduchá fakta, použijte větu nebo definiční seznam, pokud typ příspěvku nevyžaduje registrovanou specifikační tabulku. Tabulka by měla vytvářet vyhledávací hodnotu, ne zdobit malý fakt.
• Pokud se hodnoty průběžně aktualizují, připojte prvek k vlastnímu zdroji dat a zobrazte čas získání. Ručně zkopírovaná „živá“ hodnota se stává zavádějící, jakmile se změní.
• Pokud dokument popisuje názvy polí, typy a validační omezení, použijte níže uvedenou seskupenou variantu; nestlačujte celý datový model do jedné buňky „Podrobnosti“ plné prózy.

Pravidla pro psaní prvků mají přednost: vybírejte prvek podle účelu pasáže, ne podle jejího nadpisu nebo vzhledu. Pokud je úkolem bloku zobrazit specifikace, zůstává specifikační tabulkou, i když by téma mohlo stejná slova vykreslit jako karty.

Kam jej umístit

Umístěte první specifikační tabulku poté, co byl subjekt identifikován, a dříve, než stránka požádá čtenáře o interpretaci, konfiguraci, srovnání nebo nákup. Na stránce produktu to obvykle znamená za stručným popisem produktu a klíčovým přínosem, ale před podrobným vysvětlením funkcí. V dokumentaci umístěte tabulku předpokladů nebo protokolu bezprostředně před postup, který na ni spoléhá. Čtenáři potřebují vědět, co hodnoty popisují, než je uvidí, ale neměli by kvůli jejich získání procházet dlouhé vyprávění.

Pokud má stránka několik kategorií, umístěte každou tabulku pod popisný H2 nebo H3, například „Fyzické specifikace“ nebo „Kompatibilita“. Ponechte název kategorie mimo tabulku; titulek (caption) pak pojmenovává přesný subjekt a rozsah. Zachovejte stejné pořadí popisků na souvisejících stránkách, aby se čtenář nemusel znovu učit vzor.

Neumisťujte specifikační tabulku přímo vedle jiné husté tabulky, celošířkového snímku obrazovky nebo animovaného karuselu. Dvě konkurující si mřížky vytvářejí nejasnou cestu čtení a jsou obzvláště nevhodné při šířce tabletu. Nevkládejte výzvu k akci mezi titulek a jeho řádky, neumisťujte poznámky pod čarou do nesouvisející komponenty a neuvádějte propagační tvrzení ve sloupci hodnot. Udržujte titulek, tabulku, legendu stavů, datum ověření a poznámku ke zdroji jako jeden ohraničený celek. Následujte vysvětlením, než představíte další prvek s hustými daty.

Anatomie

Označený snímek musí identifikovat tyto části:

1. Nadpis sekce: pojmenovává kategorii, pokud má stránka více než jednu tabulku, např. fyzické nebo elektrické specifikace.
2. Titulek: identifikuje subjekt a přesný rozsah tabulky. Musí dávat smysl i mimo okolní odstavec.
3. Řádková hlavička: používá kanonický, jednoznačný název jedné vlastnosti.
4. Hodnota: obsahuje jeden fakt, nikoli komentář nebo prodejní tvrzení.
5. Jednotka: uvádí se u každé číselné hodnoty, pokud hodnota skutečně nemá jednotku.
6. Stavová hodnota: vypisuje „Neznámý“ nebo „Neuplatňuje se“ místo ponechání prázdné buňky.
7. Datum ověření: uvádí, kdy byly proměnlivé údaje naposledy zkontrolovány.
8. Poznámka ke zdroji: identifikuje primární systém, dokument, test nebo vlastníka, ze kterého hodnoty pocházejí.

Neznámý znamená, že se vlastnost uplatňuje, ale v době ověřování nebyla k dispozici žádná důvěryhodná hodnota. Neuplatňuje se znamená, že předpoklad vlastnosti se na tento subjekt nevztahuje. Není k dispozici je opět něco jiného: znamená, že schopnost nebo možnost chybí. Nula je naměřená nebo deklarovaná hodnota. Prázdná buňka nesděluje žádný z těchto významů, a proto není povolena.

Příklady designu

Každá designová varianta zachovává nativní značení tabulky, řádkové hlavičky, viditelné popisky, textové hodnoty a titulek. Stylování může měnit hustotu a seskupení, ale nemůže přeměnit fakta na obrázek nebo nechat barvu nést význam samostatně.

Standardní dvousloupcová: výchozí pro jeden subjekt a tři až dvanáct faktů. Popisky zabírají první sloupec a hodnoty druhý. Použijte ji pro fakta o produktu, společnosti, plánu a službě.

Seskupená: dvě nebo více krátkých tabulek rozděluje větší sadu specifikací podle úkolu čtenáře. Každá skupina obdrží nadpis a každá tabulka si zachovává vlastní titulek. Nepoužívejte sloučené oddělovací řádky jako vizuální nadpisy, protože komplikují navigaci a extrakci.

Referenční tabulka polí: dokumentační varianta pro vlastnosti, jejichž význam vyžaduje konzistentní sekundární pole, jako je typ, požadavek a omezení. První sloupec používá sémantiku řádkové hlavičky, zatímco každá sekundární dimenze má hlavičku sloupce.

Kompaktní mobilní verze: popisky a hodnoty se přirozeně obtékají bez zmenšení velikosti písma. Jednoduchá dvousloupcová tabulka by se měla přetékat v rámci svého kontejneru. Širší varianta referenční tabulky polí může posouvat uvnitř popsané oblasti zaměřitelné klávesnicí; nesmí způsobit horizontální posouvání celé stránky.

Parametry

Následující kontrakt definuje přenosný prvek. „Zdroj“ v posledním sloupci uvádí, odkud renderer získává parametr, nikoli kde byl věcný údaj zjištěn.

Použijte verified vždy, když se cena, kompatibilita, dostupnost, podpora verzí, kapacita nebo jiná hodnota může změnit. Datum publikace není náhradou: říká, kdy byla stránka zveřejněna, nikoli kdy byla specifikace zkontrolována.

Syntaxe a příklady kódu

Všechny implementace mapují na stejný titulek, seřazené řádky, významy stavů, hodnotu ověření a zdroj. Přenosná direktiva je kanonická autorská forma.

Přenosná direktiva Markdown

:::spec-table{caption="Northstar Field 500 — základní specifikace" verified="2026-08-27"}
| Specifikace | Hodnota |
|---|---|---|
| Využitelná kapacita | 512 Wh |
| Trvalý AC výstup | 500 W |
| Rozměry (Š × V × H) | 280 × 190 × 210 mm |
| Odolnost vůči vodě | Neznámý |
| Typ paliva | Neuplatňuje se |

Stav: Neznámý = relevantní, ale neověřeno; Neuplatňuje se = nelze použít.

Zdroj: schválený produktový list, revize 4.
:::

Hugo shortcode

Adaptér pro Hugo by měl přijímat pouze pojmenované parametry a vykreslovat tělo pipe-table jako sémantické řádky tabulky. Níže uvedený zápis definuje zamýšlené mapování; neznamená, že by v rámci úkolu článku měl být vytvořen nový lokální shortcode.

{{< spec-table caption="Northstar Field 500 — základní specifikace" verified="2026-08-27" >}}
| Specifikace | Hodnota |
|---|---|---|
| Využitelná kapacita | 512 Wh |
| Trvalý AC výstup | 500 W |
| Rozměry (Š × V × H) | 280 × 190 × 210 mm |
| Odolnost vůči vodě | Neznámý |
| Typ paliva | Neuplatňuje se |

Stav: Neznámý = relevantní, ale neověřeno; Neuplatňuje se = nelze použít.

Zdroj: schválený produktový list, revize 4.
{{< /spec-table >}}

Renderer musí vygenerovat <table>, <caption>, <tbody>, <th scope="row"> a <td>. Varianta field-reference také potřebuje <thead> s hlavičkami scope="col". Musí přesně zachovat znaménka minus, násobení, mezery u jednotek a text stavů.

WordPress blok

<!-- wp:amicited/spec-table {"caption":"Northstar Field 500 — základní specifikace","verified":"2026-08-27","variant":"standard"} -->
<table>
  <tbody>
    <tr><th scope="row">Využitelná kapacita</th><td>512 Wh</td></tr>
    <tr><th scope="row">Trvalý AC výstup</th><td>500 W</td></tr>
    <tr><th scope="row">Rozměry (Š × V × H)</th><td>280 × 190 × 210 mm</td></tr>
    <tr><th scope="row">Odolnost vůči vodě</th><td>Neznámý</td></tr>
    <tr><th scope="row">Typ paliva</th><td>Neuplatňuje se</td></tr>
  </tbody>
</table>
<p class="spec-table__status">Neznámý = relevantní, ale neověřeno; Neuplatňuje se = nelze použít.</p>
<p class="spec-table__source">Zdroj: schválený produktový list, revize 4.</p>
<!-- /wp:amicited/spec-table -->

WordPress implementace může používat editovatelné blokové ovládání místo doslovného HTML, ale uložené atributy a serverem vykreslený výstup musí zachovat stejný kontrakt. Autoři nesmí nahrazovat snímek obrazovky nebo obecný blok sloupců.

Příklady

Dobrý: úplná, normalizovaná fakta o produktu

Ověřeno: 27. srpna 2026. Zdroj: ilustrativní schválený instalační list, revize 2.

Funguje to, protože titulek identifikuje jeden subjekt a jeden kontext. Každý popisek pojmenovává testovatelnou vlastnost, rozsahy mají své jednotky, rozměry nemíchají systémy a maximální výkon je odlišen od typického výkonu. „Neuplatňuje se“ je odůvodněno, protože drátový senzor nemá baterii k výměně; neskrývá neznámou specifikaci baterie. Tabulku může skenovat člověk, procházet podle řádkových hlaviček nebo převést na diskrétní dvojice vlastnost–hodnota.

Špatný: nejednoznačná pseudodata

Špatná tabulka vypadá uspořádaně, ale neposkytuje spolehlivá data. „Výkon“ může znamenat napájecí napětí nebo spotřebu, zatímco „Nízký“ není měřitelný. Délka kabelu postrádá jednotku. Řádek teploty neuvádí Celsia ani Fahrenheita a zdá se, že míchá rozsah se symbolem stupně. „Odolný“ je propagační jazyk, nikoli stupeň krytí. Prázdná buňka baterie neříká, zda je fakt neznámý, irelevantní, nulový nebo omylem vynechaný. Tvrzení o kompatibilitě do jedné buňky vměstnává nedefinovanou populaci a instalační úsudek.

Opravte ji rozdělením širokých popisků na kanonické vlastnosti, získáním hodnot z pojmenovaného primárního zdroje, přidáním jednotky ke každému měření a nahrazením prázdných míst správným stavem. Pokud zdroj neuvádí stupeň krytí, napište „Neznámý“; nepřevádějte marketingový jazyk na vymyšlenou technickou hodnotu.

Značení Schema a přístupnost

Neexistuje obecný typ Schema.org pro specifikační tabulku. Tabulka zůstává cenným sémantickým HTML, i když negeneruje JSON-LD. Pokud obklopující stránka představuje způsobilou entitu, mapujte pouze přesná, ověřená fakta na podporované vlastnosti: například sku, weight, width, height, depth, material nebo additionalProperty produktu, pokud je to vhodné. Fakta o organizaci mohou být mapována na vlastnosti jako právní název nebo adresa. Viditelná tabulka a strukturovaná data se musí shodovat, používat stejné jednotky a pocházet ze stejného zdroje. Nevymýšlejte hodnocení, nabídky, identifikátory ani vlastnosti schema jen proto, že existuje řádek.

Přístupnost začíná skutečným značením. Dejte tabulce popisný <caption>. Použijte <th scope="row"> pro každý specifikační popisek; varianty field-reference také potřebují <th scope="col"> v <thead>. Udržujte pořadí čtení logické ve zdrojovém kódu, nejen na obrazovce. Nepoužívejte prázdné buňky, sloučené buňky, stavy pouze pomocí ikon, seskupení pouze pomocí barev nebo tooltipy jako jediné umístění hodnoty. Zkratky jako AC, DC a IP by měly být rozepsány v okolní próze, pokud je zamýšlené publikum nemusí znát.

Základní dvousloupcová tabulka by se měla pokud možno obtékat, nikoli posouvat. Pokud širší tabulka vyžaduje horizontální posouvání, uzavřete ji do oblasti s přístupným popiskem a tabindex="0", zachovejte viditelný indikátor fokusu klávesnice a nikdy neblokujte první sloupec způsobem, který by zakrýval hodnoty při vysokém přiblížení. Testujte při 200% přiblížení, s navigací klávesnicí a s vypnutými styly; vztah popisek–hodnota musí přežít všechny tři situace.

Pravidla psaní

Pravidla chrání vyhledávání a srovnání, proto přesnost převažuje nad kompaktností:

• Používejte 3–12 řádků na tabulku. Rozdělte delší sady podle úkolu čtenáře – fyzické, elektrické, kompatibilita, obchodní – namísto vytváření nerozlišené zdi faktů.
• Udržujte popisky ideálně na 1–6 slovech. Použijte kvalifikátor jako „maximální“, „typický“, „instalovaný“ nebo „na uživatele“, pokud mění význam.
• Udržujte běžnou hodnotu na jednom řádku a maximálně 12 slovech. Přesuňte interpretaci, výjimky a doporučení do sousední prózy nebo přímo související poznámky.
• Používejte jeden systém měření na tabulku, pokud publikum skutečně nepotřebuje oba. Pokud jsou vyžadovány oba, uveďte primární hodnotu jako první a převod v závorce u každého příslušného řádku.
• Uveďte jednotku vedle každého číselného měření: 512 Wh, 3 m a 45 °C. Nikdy nespoléhejte na to, že nadpis dodá jednotku pouze některým řádkům.
• Normalizujte ekvivalentní vlastnosti napříč souvisejícími stránkami. Vyberte jeden popisek a jednu jednotku – například „Hmotnost“ v kilogramech – a nestřídejte se s „Váha“, librami nebo vágními frázemi bez zdokumentovaného důvodu.
• Používejte přesná stavová slova: Neznámý, Neuplatňuje se nebo Není k dispozici. Definujte je jednou, pokud se objeví více než jeden stav. Nikdy nepoužívejte pomlčku, prázdnou buňku, TBC, otazník nebo barvu k vyjádření stavu.
• Používejte věcný, neutrální tón. Hodnoty mohou být příznivé, ale slova jako „úžasný“, „ultrarychlý“, „nejlepší ve třídě“ a „štědrý“ jsou závěry, nikoli specifikace.
• Nikdy nevkládejte výzvy k akci, reference, odstavce prodejního textu, nevysvětlená skóre, nepodložená srovnání nebo dekorativní obrázky do buňky s hodnotou.
• Uveďte zdroj a přesné datum ověření u proměnlivých nebo externě tvrzených hodnot. Pokud vlastnictví není jasné, tabulka není připravena k publikování.

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

Pole postTypes v front matter definuje schválená použití níže. Uvedení znamená, že typ příspěvku může prvek vyžadovat nebo z něj mít prospěch; neznamená, že každá stránka musí vyrobit tři fakta, aby vyhověla rozvržení.

Kontrolní seznam QA

• Tabulka popisuje jeden jasně identifikovaný subjekt; více možností není maskováno jako specifikační tabulka.
• Titulek uvádí jak subjekt, tak rozsah tabulky.
• Každá vlastnost používá přesný, kanonický popisek a každá buňka obsahuje jednu hodnotu.
• Číselné hodnoty obsahují konzistentní jednotky, kvalifikátory, rozsahy a rozměry.
• Žádná buňka není prázdná; Neznámý, Neuplatňuje se a Není k dispozici jsou použity pouze se svými definovanými významy.
• Tvrzení odpovídají pojmenovanému primárnímu zdroji a proměnlivá fakta uvádějí přesné datum ověření.
• Publikovaný výstup používá nativní <table>, <caption>, řádkové hlavičky a datové buňky namísto obrázku nebo vizuální mřížky.
• Varianty field-reference zahrnují hlavičky sloupců a zachovávají všechny vztahy hlaviček.
• Tabulka funguje při úzkých šířkách, 200% přiblížení, s navigací klávesnicí a s vypnutými styly.
• Barva, ikony, zkratky a tooltipy nejsou nikdy jediným způsobem, jak porozumět hodnotě.
• Viditelná fakta a případné způsobilé vlastnosti Schema.org se přesně shodují.
• Propagační tvrzení, interpretace, výzvy k akci a dlouhá próza jsou umístěny mimo tabulku.
• Prvek se řídí pravidlem precedence playbooku a vybraný typ příspěvku zahrnuje prvek ve svém obsahovém kontraktu.