Tabele de Specificații: Format, Reguli și Exemple

Un tabel de specificații transformă datele despre un singur subiect în perechi explicite etichetă–valoare. Un cititor poate găsi temperatura de funcționare fără să recitească o descriere a produsului, iar o mașină poate reține relația dintre „Temperatură de funcționare” și „−10 până la 45 °C” fără să ghicească ce număr aparține cărei afirmații.

Numele produsului și valorile de mai sus sunt ilustrative. Structura este modelul de producție: un singur subiect, o etichetă precisă pe rând, o valoare cu unitatea sa și o stare explicită acolo unde nu poate fi furnizată o valoare factuală.

De ce contează acest element

Proza descriptivă îi obligă pe cititori să facă o reconstrucție evitabilă. Gândiți-vă: „Unitata cântărește 6,4 kilograme, furnizează 500 de wați continuu, măsoară 280 pe 190 pe 210 milimetri și poate funcționa între minus 10 și 45 de grade Celsius.” Fraza este corectă gramatical, dar un cumpărător care caută doar dimensiunile trebuie să analizeze fiecare propoziție. Revenirea ulterioară pentru a verifica puterea de ieșire înseamnă reanalizarea textului. Un tabel mută etichetele într-o margine previzibilă și valorile într-o a doua coloană, reducând efortul de memorare și făcând scanarea fiabilă.

Structura contează la fel de mult pentru mașini. Extractibilitatea mecanică este capacitatea unui crawler, sistem de căutare, asistent sau instrument de publicare din aval de a păstra sensul și relațiile din conținut. Markupul nativ <table>, <th scope="row"> și <td> afirmă că antetul rândului califică valoarea adiacentă. Produce o pereche fiabilă: „Capacitate utilizabilă — 512 Wh.” Aceleași două șiruri încorporate printre fraze promoționale necesită inferență la nivel lingvistic, iar o colecție stilizată de elemente <div> fără legătură poate expune o aliniere vizuală fără a expune o relație de date.

Interogabilitatea nu înseamnă că fiecare site web devine o bază de date. Înseamnă că fiecare fapt are o etichetă stabilă, o valoare discretă și un markup previzibil, astfel încât un cititor sau un sistem poate solicita o proprietate fără a extrage întregul paragraf. Comparabilitatea înseamnă că produsele publicate separat pot folosi aceleași etichete canonice și unități de măsură, permițând alinierea valorilor ulterior, fără a normaliza mai întâi „aproximativ jumătate de kilowatt”, „500 de wați” și „0,5 kW”. Un tabel de specificații permite acea comparație ulterioară; nu este el însuși o comparație, decât dacă prezintă mai multe subiecte unul lângă altul.

Când să îl folosiți

Folosiți un tabel de specificații atunci când pagina descrie o singură entitate și cititorii au nevoie de cel puțin trei fapte discrete și verificate. Subiectele tipice includ un produs, un plan software, o interfață API, un format de fișier, o instalație, un vehicul, o organizație, un pachet de servicii sau un standard tehnic. Faptele potrivite au răspunsuri delimitate: dimensiuni, sisteme de operare suportate, tip de conector, format de răspuns, perioadă de garanție, denumire legală, arie de acoperire, versiune sau o limită declarată.

Folosiți proza în jurul tabelului pentru a explica consecințele. „Sarcină maximă: 18 kg” aparține tabelului; de ce acea limită exclude o anumită instalație aparține prozei. Tabelul ar trebui să răspundă la întrebarea „care este valoarea?”, iar explicația din jur să răspundă la „de ce contează?”

Cazurile apropiate de limită sunt frecvente:

• Atunci când două sau mai multe produse trebuie judecate după criterii comune, folosiți un tabel comparativ . Un tabel de specificații are un singur subiect; adăugarea mai multor coloane de valori îi schimbă scopul.
• Atunci când conținutul este o succesiune de evenimente, folosiți o cronologie. Datele într-un tabel cu două coloane nu fac automat relațiile cronologice.
• Atunci când fiecare rând are nevoie de mai multe fraze de interpretare, folosiți titluri și proză. Paragrafele dense în interiorul celulelor împiedică scanarea și devin dificile pe ecrane înguste.
• Atunci când lista conține doar două fapte simple, folosiți o frază sau o listă de definiții, cu excepția cazului în care tipul de postare necesită un tabel de specificații înregistrat. Un tabel ar trebui să creeze valoare de regăsire, nu să decoreze un fapt minor.
• Atunci când valorile se actualizează continuu, conectați elementul la o sursă de date deținută și afișați un moment al regăsirii. O valoare „în direct” copiată manual devine înșelătoare imediat ce se modifică.
• Atunci când documentul descrie nume de câmpuri, tipuri și constrângeri de validare, folosiți varianta grupata de mai jos; nu înghesuiți întregul model de date într-o singură celulă „Detalii” cu multă proză.

Regulile de redactare a elementelor au prioritate: alegeți elementul în funcție de scopul pasajului, nu de titlul sau aspectul său. Dacă un bloc are rolul de a expune specificații, rămâne un tabel de specificații chiar și atunci când tema ar putea reda aceleași cuvinte sub formă de carduri.

Unde să îl plasați

Plasați primul tabel de specificații după ce subiectul a fost identificat și înainte ca pagina să ceară cititorului să interpreteze, configureze, compare sau cumpere. Pe o pagină de produs, aceasta înseamnă de obicei după descrierea concisă a produsului și beneficiul cheie, dar înainte de explicațiile detaliate ale caracteristicilor. În documentație, puneți un tabel cu cerințe preliminare sau protocol imediat înainte de procedura care se bazează pe acesta. Cititorii trebuie să știe ce descriu valorile înainte de a le vedea, dar nu ar trebui să traverseze o narațiune lungă pentru a le regăsi.

Dacă pagina are mai multe categorii, plasați fiecare tabel sub un H2 sau H3 descriptiv, cum ar fi „Specificații fizice” sau „Compatibilitate”. Păstrați titlul categoriei în afara tabelului; apoi legenda denumește subiectul și sfera exactă. Păstrați aceeași ordine a etichetelor pe paginile înrudite, astfel încât un cititor să nu fie nevoit să reînvețe tiparul.

Nu plasați un tabel de specificații direct lângă un alt tabel dens, o captură de ecran pe toată lățimea sau un carusel animat. Două grile concurente creează un traseu de lectură neclar și sunt deosebit de incomode la lățimi de tabletă. Nu inserați un îndemn la acțiune între o legendă și rândurile sale, nu puneți note de subsol într-o componentă fără legătură și nu plasați o afirmație promoțională în coloana valorilor. Păstrați legenda, tabelul, legenda stărilor, data verificării și nota sursei ca o unitate delimitată. Urmați cu explicații înainte de a introduce un alt element bogat în date.

Anatomie

Captura etichetată trebuie să identifice următoarele părți:

1. Titlul secțiunii: denumește categoria atunci când pagina are mai mult de un tabel, de exemplu specificații fizice sau electrice.
2. Legenda: identifică subiectul și sfera exactă a tabelului. Trebuie să aibă sens și în afara paragrafului înconjurător.
3. Antetul rândului: folosește denumirea canonică, neambiguă a unei proprietăți.
4. Valoarea: conține un singur fapt, nu comentarii sau afirmații de vânzare.
5. Unitatea: apare lângă fiecare valoare numerică, cu excepția cazului în care valoarea este cu adevărat fără unitate.
6. Valoarea de stare: scrie explicit „Necunoscut” sau „Nu se aplică”, în loc să lase o celulă goală.
7. Data verificării: indică momentul când datele volatile au fost verificate ultima dată.
8. Nota sursei: identifică sistemul principal, documentul, testul sau deținătorul de la care provin valorile.

Necunoscut înseamnă că proprietatea se aplică, dar nici o valoare de încredere nu era disponibilă la momentul verificării. Nu se aplică înseamnă că premisa proprietății nu se aplică acestui subiect. Indisponibil este din nou diferit: înseamnă că o capacitate sau opțiune este absentă. Zero este o valoare măsurată sau declarată. O celulă goală nu comunică niciunul dintre aceste înțelesuri și, prin urmare, nu este permisă.

Exemple de design

Fiecare variantă de design păstrează markupul nativ de tabel, antetele rândurilor, etichetele vizibile, valorile text și o legendă. Stilizarea poate modifica densitatea și gruparea, dar nu poate transforma datele într-o imagine sau poate face ca doar culoarea să transmită sens.

Standard cu două coloane: varianta implicită pentru un singur subiect și între trei și doisprezece fapte. Etichetele ocupă prima coloană, iar valorile pe a doua. Folosiți-l pentru produse, companii, planuri și date despre servicii.

Grupate: două sau mai multe tabele scurte împart un set mai mare de specificații în funcție de sarcina cititorului. Fiecare grup primește un titlu și fiecare tabel își păstrează propria legendă. Nu folosiți rânduri de separare îmbinate ca titluri vizuale, deoarece complică navigarea și extracția.

Referință de câmpuri: o variantă de documentație pentru proprietăți al căror sens necesită câmpuri secundare consistente, cum ar fi tipul, cerința și constrângerea. Prima coloană folosește semantică de antet de rând, în timp ce fiecare dimensiune secundară are un antet de coloană.

Compact pentru mobil: etichetele și valorile se împart pe rânduri în mod natural, fără a reduce dimensiunea textului. Un tabel simplu cu două coloane ar trebui să se rearanjeze în interiorul containerului său. O variantă mai largă de referință de câmpuri poate derula în interiorul unei regiuni etichetate, care poate fi focusată cu tastatura; nu trebuie să facă întreaga pagină să deruleze orizontal.

Parametri

Contractul următor definește elementul portabil. „Sursa” din ultima coloană indică de unde obține motorul de randare parametrul, nu unde a fost cercetată afirmația factuală.

Folosiți verified de fiecare dată când prețul, compatibilitatea, disponibilitatea, suportul pentru versiuni, capacitatea sau o altă valoare se pot modifica. Data publicării nu este un substitut: aceasta indică momentul lansării paginii, nu cel al verificării specificației.

Sintaxă și exemple de cod

Toate implementările se mapează la aceeași legendă, rânduri ordonate, sensuri ale stărilor, valoare de verificare și sursă. Directiva portabilă este forma canonică autorată.

Directivă portabilă Markdown

:::spec-table{caption="Northstar Field 500 — specificații de bază" verified="2026-08-27"}
| Specificație | Valoare |
|---|---|
| Capacitate utilizabilă | 512 Wh |
| Ieșire AC continuă | 500 W |
| Dimensiuni (L × Î × A) | 280 × 190 × 210 mm |
| Grad de rezistență la apă | Necunoscut |
| Tip combustibil | Nu se aplică |

Stare: Necunoscut = relevant, dar neverificat; Nu se aplică = nu poate fi aplicat.

Sursa: fișă tehnică aprobată a produsului, revizia 4.
:::

Shortcode Hugo

Adaptorul Hugo ar trebui să accepte doar parametri denumiți și să redea corpul sub formă de tabel pipe ca rânduri de tabel semantice. Notația de mai jos definește maparea intenționată; nu implică faptul că ar trebui creat un nou shortcode local în cadrul unei sarcini de articol.

{{< spec-table caption="Northstar Field 500 — specificații de bază" verified="2026-08-27" >}}
| Specificație | Valoare |
|---|---|
| Capacitate utilizabilă | 512 Wh |
| Ieșire AC continuă | 500 W |
| Dimensiuni (L × Î × A) | 280 × 190 × 210 mm |
| Grad de rezistență la apă | Necunoscut |
| Tip combustibil | Nu se aplică |

Stare: Necunoscut = relevant, dar neverificat; Nu se aplică = nu poate fi aplicat.

Sursa: fișă tehnică aprobată a produsului, revizia 4.
{{< /spec-table >}}

Motorul de randare trebuie să producă <table>, <caption>, <tbody>, <th scope="row"> și <td>. O variantă field-reference are nevoie și de <thead> cu antete scope="col". Trebuie să păstreze exact semnele minus, semnele de înmulțire, spațierea unităților și textul stărilor.

Bloc WordPress

<!-- wp:amicited/spec-table {"caption":"Northstar Field 500 — specificații de bază","verified":"2026-08-27","variant":"standard"} -->
<table>
  <tbody>
    <tr><th scope="row">Capacitate utilizabilă</th><td>512 Wh</td></tr>
    <tr><th scope="row">Ieșire AC continuă</th><td>500 W</td></tr>
    <tr><th scope="row">Dimensiuni (L × Î × A)</th><td>280 × 190 × 210 mm</td></tr>
    <tr><th scope="row">Grad de rezistență la apă</th><td>Necunoscut</td></tr>
    <tr><th scope="row">Tip combustibil</th><td>Nu se aplică</td></tr>
  </tbody>
</table>
<p class="spec-table__status">Necunoscut = relevant, dar neverificat; Nu se aplică = nu poate fi aplicat.</p>
<p class="spec-table__source">Sursa: fișă tehnică aprobată a produsului, revizia 4.</p>
<!-- /wp:amicited/spec-table -->

O implementare WordPress poate folosi controale editabile de tip bloc în loc de HTML literal, dar atributele salvate și ieșirea redată pe server trebuie să păstreze același contract. Autorii nu trebuie să substituie o captură de ecran sau un bloc generic de coloane.

Exemple

Corect: fapte complete și normalizate despre produs

Verificat: 27 august 2026. Sursa: fișă de instalare ilustrativă aprobată, revizia 2.

Acest exemplu funcționează deoarece legenda identifică un singur subiect și un singur context. Fiecare etichetă denumește o proprietate testabilă, intervalele își păstrează unitățile, dimensiunile nu amestecă sistemele de măsură, iar puterea maximă este distinctă de puterea tipică. „Nu se aplică” este justificat deoarece un senzor cu fir nu are baterie de înlocuit; nu ascunde o specificație necunoscută a bateriei. Tabelul poate fi scanat de o persoană, navigat după antetul rândului sau transformat în perechi discrete proprietate–valoare.

Greșit: pseudo-date ambigue

Tabelul greșit pare organizat, dar nu oferă date de încredere. „Alimentare” ar putea însemna tensiunea de alimentare sau consumul, iar „Scăzut” nu este măsurabil. Lungimea cablului nu are unitate de măsură. Rândul temperaturii nu specifică dacă este vorba de grade Celsius sau Fahrenheit și pare să amestece un interval cu un simbol de grade. „Robust” este limbaj promoțional, nu un grad de protecție la pătrundere. Celula goală a bateriei nu spune dacă faptul este necunoscut, irelevant, zero sau omis accidental. Afirmația de compatibilitate înglobează o populație nedefinită și o judecată de instalare într-o singură celulă.

Reparați-l împărțind etichetele largi în proprietăți canonice, obținând valori dintr-o sursă primară numită, adăugând o unitate de măsură la fiecare măsurătoare și înlocuind spațiile goale cu starea corectă. Dacă sursa nu menționează gradul de protecție la pătrundere, scrieți „Necunoscut”; nu transformați limbajul de marketing într-o valoare tehnică inventată.

Markup Schema și accesibilitate

Nu există un tip Schema.org general pentru un tabel de specificații. Tabelul rămâne un HTML semantic valoros chiar și atunci când nu produce JSON-LD. Atunci când pagina care îl conține reprezintă o entitate eligibilă, mapați doar faptele exacte și verificate la proprietăți suportate: de exemplu, sku, weight, width, height, depth, material sau additionalProperty ale unui produs, acolo unde este cazul. Datele despre organizație se pot mapa la proprietăți precum denumirea legală sau adresa. Tabelul vizibil și datele structurate trebuie să coincidă, să folosească aceleași unități și să provină din aceeași sursă. Nu inventați evaluări, oferte, identificatori sau proprietăți de schemă doar pentru că există un rând.

Accesibilitatea începe cu markup real. Dați tabelului o <caption> descriptivă. Folosiți <th scope="row"> pentru fiecare etichetă de specificație; variantele field-reference au nevoie și de <th scope="col"> într-un <thead>. Păstrați ordinea de citire logică în sursă, nu doar pe ecran. Nu folosiți celule goale, celule îmbinate, stări doar din pictograme, grupări doar pe culoare sau tooltip-uri ca unică locație a unei valori. Abrevierile precum AC, DC și IP ar trebui explicate în proza din apropiere atunci când publicul vizat s-ar putea să nu le cunoască.

Un tabel de bază cu două coloane ar trebui să se împartă pe rânduri, mai degrabă decât să deruleze, ori de câte ori este practic. Atunci când un tabel mai larg necesită derulare orizontală, limitați-l la o regiune cu o etichetă accesibilă și tabindex="0", păstrați un indicator vizibil de focus pentru tastatură și nu blocați niciodată prima coloană într-un mod care să acopere valorile la zoom mare. Testați la 200% zoom, cu navigare prin tastatură și cu stilurile dezactivate; relația etichetă–valoare trebuie să supraviețuiască tuturor celor trei condiții.

Reguli de redactare

Regulile protejează regăsirea și compararea, astfel încât precizia are prioritate în fața compactității:

• Folosiți 3–12 rânduri per tabel. Împărțiți seturile mai lungi în funcție de sarcina cititorului — fizic, electric, compatibilitate, comercial — mai degrabă decât să creați un zid nediferențiat de fapte.
• Păstrați etichetele la 1–6 cuvinte acolo unde este posibil. Folosiți un calificativ precum „maxim”, „tipic”, „instalat” sau „per utilizator” atunci când acesta modifică sensul.
• Păstrați o valoare normală pe un rând și la maximum 12 cuvinte. Mutați interpretarea, excepțiile și recomandările în proza adiacentă sau într-o notă direct asociată.
• Folosiți un singur sistem de măsurare per tabel, cu excepția cazului în care publicul are nevoie în mod real de ambele. Când ambele sunt necesare, prezentați mai întâi valoarea principală și conversia între paranteze pentru fiecare rând aplicabil.
• Puneți o unitate de măsură lângă fiecare măsurătoare numerică: 512 Wh, 3 m și 45 °C. Nu vă bazați niciodată pe un titlu pentru a furniza o unitate doar pentru unele rânduri.
• Normalizați proprietățile echivalente pe paginile înrudite. Alegeți o singură etichetă și o singură unitate — de exemplu, „Greutate” în kilograme — și nu alternați cu „Masă”, livre sau fraze vagi fără un motiv documentat.
• Folosiți cuvinte exacte pentru stări: Necunoscut, Nu se aplică sau Indisponibil. Definiți-le o singură dată atunci când apare mai mult de o stare. Nu folosiți niciodată o linie, o celulă goală, TBC, semn de întrebare sau culoare pentru a sugera starea.
• Folosiți un ton factual și neutru. Valorile pot fi favorabile, dar cuvinte precum „uimitor”, „ultra-rapid”, „cel mai bun din clasă” și „generos” sunt concluzii, nu specificații.
• Nu puneți niciodată îndemnuri la acțiune, testimoniale, paragrafe de text de vânzare, scoruri neexplicate, comparații nesuportate sau imagini decorative în interiorul unei celule de valoare.
• Menționați sursa și o dată exactă de verificare pentru valorile volatile sau afirmate extern. Dacă proprietatea nu este clară, tabelul nu este gata de publicare.

Tipuri de postări care îl folosesc

Câmpul postTypes din frontmatter conduce utilizările aprobate de mai jos. Includerea înseamnă că tipul de postare poate necesita sau beneficia de element; nu înseamnă că fiecare pagină trebuie să inventeze trei fapte pentru a satisface un aspect.

Lista de verificare QA

• Tabelul descrie un singur subiect clar identificat; opțiunile multiple nu au fost deghizate ca tabel de specificații.
• Legenda denumește atât subiectul, cât și sfera tabelului.
• Fiecare proprietate folosește o etichetă precisă, canonică, iar fiecare celulă conține o singură valoare.
• Valorile numerice includ unități, calificative, intervale și dimensiuni consistente.
• Nicio celulă nu este goală; Necunoscut, Nu se aplică și Indisponibil sunt folosite doar cu sensurile lor definite.
• Afirmațiile corespund unei surse primare denumite, iar datele volatile au o dată exactă de verificare.
• Rezultatul publicat folosește <table>, <caption>, antete de rând și celule de date native, nu o imagine sau o grilă vizuală.
• Variantele field-reference includ antete de coloană și păstrează toate relațiile dintre antete.
• Tabelul funcționează la lățimi înguste, la 200% zoom, cu navigare prin tastatură și cu stilurile dezactivate.
• Culoarea, pictogramele, abrevierile și tooltip-urile nu sunt niciodată singurul mod de a înțelege o valoare.
• Datele vizibile și orice proprietăți Schema.org eligibile coincid exact.
• Afirmațiile promoționale, interpretările, îndemnurile la acțiune și proza lungă se află în afara tabelului.
• Elementul respectă regula de precedență a playbook-ului, iar tipul de postare selectat include elementul în contractul său de conținut.