Tabelle Specifiche: Formato, Regole ed Esempi

Una tabella specifiche trasforma i dati su un soggetto in coppie esplicite etichetta–valore. Un lettore può trovare la temperatura operativa senza rileggere una descrizione del prodotto, e una macchina può conservare la relazione tra “Temperatura operativa” e “−10 a 45 °C” senza dover indovinare quale numero appartiene a quale affermazione.

Il nome del prodotto e i valori sopra sono illustrativi. La struttura è il modello di produzione: un soggetto, un’etichetta precisa per riga, un valore con la sua unità e uno stato esplicito quando non è possibile fornire un valore fattuale.

Perché questo elemento è importante

Il testo descrittivo delle specifiche costringe i lettori a una ricostruzione evitabile. Considera: “L’unità pesa 6,4 chilogrammi, eroga 500 watt in continuo, misura 280 per 190 per 210 millimetri e può operare da −10 a 45 gradi Celsius.” La frase è grammaticalmente corretta, ma un acquirente che cerca solo le dimensioni deve analizzare ogni proposizione. Tornare in seguito per controllare la potenza significa analizzarla di nuovo. Una tabella sposta le etichette in un bordo prevedibile e i valori in una seconda colonna, riducendo il carico di memoria e rendendo la scansione affidabile.

La struttura è altrettanto importante per le macchine. L’estraibilità automatica è la capacità di un crawler, sistema di ricerca, assistente o strumento di pubblicazione a valle di preservare il significato e le relazioni nei contenuti. Il markup nativo <table>, <th scope="row"> e <td> stabilisce che l’intestazione di riga qualifica il valore adiacente. Produce una coppia affidabile: “Capacità utilizzabile — 512 Wh.” Le stesse due stringhe inserite tra frasi promozionali richiedono un’inferenza a livello linguistico, e una raccolta stilizzata di elementi <div> non correlati può esporre un allineamento visivo senza esporre una relazione dati.

“Consultabile” non significa che ogni sito web diventi un database. Significa che ogni dato ha un’etichetta stabile, un valore discreto e un markup prevedibile, così un lettore o un sistema può chiedere una proprietà senza estrarre l’intero paragrafo. “Confrontabile” significa che prodotti pubblicati separatamente possono usare le stesse etichette e unità canoniche, permettendo di allineare i valori in seguito senza prima normalizzare “circa mezzo kilowatt”, “500 watt” e “0,5 kW.” Una tabella specifiche abilita quel confronto successivo; non è di per sé una comparativa a meno che non presenti più soggetti affiancati.

Quando usarlo

Usa una tabella specifiche quando la pagina descrive un’entità e i lettori hanno bisogno di almeno tre dati discreti e verificati. I soggetti tipici includono un prodotto, un piano software, un’API, un formato file, un impianto, un veicolo, un’organizzazione, un pacchetto di servizi o uno standard tecnico. I dati adatti hanno risposte circoscritte: dimensioni, sistemi operativi supportati, tipo di connettore, formato di risposta, periodo di garanzia, ragione sociale, area di copertura, versione o un limite dichiarato.

Usa il testo intorno alla tabella per spiegare le conseguenze. “Carico massimo: 18 kg” appartiene alla tabella; perché quel limite esclude una particolare installazione appartiene al testo. La tabella dovrebbe rispondere a “qual è il valore?”, mentre la spiegazione circostante risponde a “perché è importante?”

I casi limite sono comuni:

• Quando due o più prodotti devono essere giudicati in base a criteri condivisi, usa invece una tabella comparativa . Una tabella specifiche ha un solo soggetto; aggiungere più colonne di valori ne cambia lo scopo.
• Quando il contenuto è una sequenza di eventi, usa una linea temporale. Le date in una tabella a due colonne non rendono automaticamente le relazioni cronologiche.
• Quando ogni riga necessita di diverse frasi di interpretazione, usa titoli e testo. Paragrafi densi all’interno delle celle ostacolano la scansione e diventano difficili su schermi stretti.
• Quando l’elenco contiene solo due dati semplici, usa una frase o un elenco di definizioni a meno che il tipo di post non richieda una tabella specifiche registrata. Una tabella dovrebbe creare valore di recupero, non decorare un piccolo dato.
• Quando i valori si aggiornano continuamente, collega l’elemento a una fonte dati proprietaria e mostra un orario di recupero. Un valore “in tempo reale” copiato manualmente diventa fuorviante non appena cambia.
• Quando il documento descrive nomi di campi, tipi e vincoli di validazione, usa la variante raggruppata qui sotto; non comprimere l’intero modello dati in un’unica cella “Dettagli” piena di testo.

Le regole di scrittura degli elementi hanno la precedenza: scegli l’elemento in base allo scopo del passaggio, non al suo titolo o aspetto. Se il compito di un blocco è esporre specifiche, rimane una tabella specifiche anche quando il tema potrebbe rendere le stesse parole come card.

Dove posizionarlo

Posiziona la prima tabella specifiche dopo che il soggetto è stato identificato e prima che la pagina chieda al lettore di interpretare, configurare, confrontare o acquistare. In una pagina prodotto, ciò significa solitamente dopo la descrizione concisa del prodotto e il beneficio chiave, ma prima delle spiegazioni dettagliate delle funzionalità. Nella documentazione, posiziona una tabella dei prerequisiti o del protocollo immediatamente prima della procedura che si basa su di essa. I lettori devono sapere cosa descrivono i valori prima di vederli, ma non dovrebbero dover attraversare una lunga narrazione per recuperarli.

Se la pagina ha diverse categorie, posiziona ogni tabella sotto un H2 o H3 descrittivo come “Specifiche fisiche” o “Compatibilità.” Mantieni il titolo della categoria fuori dalla tabella; la didascalia nomina poi il soggetto e l’ambito precisi. Preserva lo stesso ordine delle etichette tra pagine simili, così un lettore non deve reimparare lo schema.

Non posizionare una tabella specifiche direttamente accanto a un’altra tabella densa, uno screenshot a larghezza intera o un carosello animato. Due grigie in competizione creano un percorso di lettura poco chiaro e sono particolarmente scomode a larghezze da tablet. Non inserire un invito all’azione tra una didascalia e le sue righe, non mettere note a piè di pagina in un componente non correlato e non inserire affermazioni promozionali nella colonna dei valori. Mantieni didascalia, tabella, legenda dello stato, data di verifica e nota sulla fonte come un’unica unità delimitata. Segui con una spiegazione prima di introdurre un altro elemento ricco di dati.

Anatomia

La cattura annotata deve identificare queste parti:

1. Titolo di sezione: nomina la categoria quando una pagina ha più di una tabella, ad esempio specifiche fisiche o elettriche.
2. Didascalia: identifica il soggetto e l’ambito esatto della tabella. Deve avere senso anche al di fuori del paragrafo circostante.
3. Intestazione di riga: usa il nome canonico e univoco di una proprietà.
4. Valore: contiene un dato, non un commento o un’affermazione di vendita.
5. Unità: appare con ogni valore numerico a meno che il valore sia genuinamente senza unità.
6. Valore di stato: scrive per esteso “Sconosciuto” o “Non applicabile” invece di lasciare una cella vuota.
7. Data di verifica: indica quando i dati volatili sono stati controllati l’ultima volta.
8. Nota sulla fonte: identifica il sistema primario, documento, test o proprietario da cui provengono i valori.

Sconosciuto significa che la proprietà si applica ma nessun valore attendibile era disponibile al momento della verifica. Non applicabile significa che il presupposto della proprietà non si applica a questo soggetto. Non disponibile è ancora diverso: significa che una capacità o opzione è assente. Zero è un valore misurato o dichiarato. Una cella vuota non comunica nessuno di questi significati e pertanto non è consentita.

Esempi di design

Ogni variante di design mantiene il markup tabellare nativo, le intestazioni di riga, le etichette visibili, i valori testuali e una didascalia. Lo stile può cambiare densità e raggruppamento, ma non può trasformare i dati in un’immagine o far sì che il colore veicoli significato da solo.

Standard a due colonne: l’impostazione predefinita per un soggetto e da tre a dodici dati. Le etichette occupano la prima colonna e i valori la seconda. Usala per dati di prodotto, azienda, piano e servizio.

Raggruppato: due o più tabelle brevi dividono un insieme più ampio di specifiche per attività del lettore. Ogni gruppo riceve un titolo e ogni tabella mantiene la propria didascalia. Non usare righe di separazione unite come titoli visivi perché complicano la navigazione e l’estrazione.

Riferimento campi: una variante per documentazione di proprietà il cui significato richiede campi secondari coerenti come tipo, requisito e vincolo. La prima colonna usa la semantica di intestazione di riga, mentre ogni dimensione secondaria ha un’intestazione di colonna.

Mobile compatto: etichette e valori vanno a capo naturalmente senza ridurre la dimensione del carattere. Una semplice tabella a due colonne dovrebbe rientrare nel suo contenitore. Una variante più ampia di riferimento campi può scorrere all’interno di una regione etichettata e focusabile da tastiera; non deve far scorrere orizzontalmente l’intera pagina.

Parametri

Il seguente contratto definisce l’elemento portabile. “Fonte” nell’ultima colonna indica da dove il renderer ottiene il parametro, non dove è stata ricercata l’affermazione fattuale.

Usa verified ogni volta che prezzo, compatibilità, disponibilità, supporto versione, capacità o un altro valore può cambiare. Una data di pubblicazione non è un sostituto: indica quando la pagina è stata pubblicata, non quando la specifica è stata verificata.

Sintassi ed esempi di codice

Tutte le implementazioni mappano alla stessa didascalia, righe ordinate, significati di stato, valore di verifica e fonte. La direttiva portabile è la forma autoriale canonica.

Direttiva portabile Markdown

:::spec-table{caption="Northstar Field 500 — specifiche principali" verified="2026-08-27"}
| Specifica | Valore |
|---|---|
| Capacità utilizzabile | 512 Wh |
| Uscita CA continua | 500 W |
| Dimensioni (L × A × P) | 280 × 190 × 210 mm |
| Grado di resistenza all'acqua | Sconosciuto |
| Tipo di carburante | Non applicabile |

Stato: Sconosciuto = pertinente ma non verificato; Non applicabile = non può applicarsi.

Fonte: scheda tecnica prodotto approvata, revisione 4.
:::

Hugo shortcode

L’adattatore Hugo dovrebbe accettare solo parametri nominati e renderizzare il corpo della tabella a barre come righe di tabella semantiche. La notazione qui sotto definisce la mappatura prevista; non implica che debba essere creato un nuovo shortcode locale all’interno di un’attività di articolo.

{{< spec-table caption="Northstar Field 500 — specifiche principali" verified="2026-08-27" >}}
| Specifica | Valore |
|---|---|
| Capacità utilizzabile | 512 Wh |
| Uscita CA continua | 500 W |
| Dimensioni (L × A × P) | 280 × 190 × 210 mm |
| Grado di resistenza all'acqua | Sconosciuto |
| Tipo di carburante | Non applicabile |

Stato: Sconosciuto = pertinente ma non verificato; Non applicabile = non può applicarsi.

Fonte: scheda tecnica prodotto approvata, revisione 4.
{{< /spec-table >}}

Il renderer deve produrre <table>, <caption>, <tbody>, <th scope="row"> e <td>. Una variante field-reference necessita anche di <thead> con intestazioni scope="col". Deve preservare esattamente i segni meno, i simboli di moltiplicazione, la spaziatura delle unità e il testo di stato.

Blocco WordPress

<!-- wp:amicited/spec-table {"caption":"Northstar Field 500 — specifiche principali","verified":"2026-08-27","variant":"standard"} -->
<table>
  <tbody>
    <tr><th scope="row">Capacità utilizzabile</th><td>512 Wh</td></tr>
    <tr><th scope="row">Uscita CA continua</th><td>500 W</td></tr>
    <tr><th scope="row">Dimensioni (L × A × P)</th><td>280 × 190 × 210 mm</td></tr>
    <tr><th scope="row">Grado di resistenza all'acqua</th><td>Sconosciuto</td></tr>
    <tr><th scope="row">Tipo di carburante</th><td>Non applicabile</td></tr>
  </tbody>
</table>
<p class="spec-table__status">Sconosciuto = pertinente ma non verificato; Non applicabile = non può applicarsi.</p>
<p class="spec-table__source">Fonte: scheda tecnica prodotto approvata, revisione 4.</p>
<!-- /wp:amicited/spec-table -->

Un’implementazione WordPress può utilizzare controlli a blocchi modificabili invece di HTML letterale, ma i suoi attributi salvati e l’output renderizzato lato server devono preservare lo stesso contratto. Gli autori non devono sostituire con uno screenshot o un blocco colonne generico.

Esempi

Buono: dati prodotto completi e normalizzati

Verificato: 27 agosto 2026. Fonte: scheda di installazione illustrativa approvata, revisione 2.

Funziona perché la didascalia identifica un soggetto e un contesto. Ogni etichetta nomina una proprietà verificabile, gli intervalli mantengono le loro unità, le dimensioni non mescolano sistemi e la potenza massima è distinta dalla potenza tipica. “Non applicabile” è giustificato perché un sensore cablato non ha batteria da sostituire; non nasconde una specifica sconosciuta della batteria. La tabella può essere scansionata da una persona, navigata per intestazione di riga o trasformata in coppie proprietà–valore discrete.

Cattivo: pseudo-dati ambigui

La tabella cattiva sembra organizzata ma non fornisce dati affidabili. “Alimentazione” potrebbe significare tensione di alimentazione o consumo, mentre “Bassa” non è misurabile. Alla lunghezza del cavo manca l’unità di misura. La riga della temperatura non specifica Celsius o Fahrenheit e sembra mescolare un intervallo con un simbolo di grado. “Robusto” è linguaggio promozionale piuttosto che un grado di protezione IP. La cella vuota della batteria non dice se il dato è sconosciuto, irrilevante, zero o accidentalmente omesso. L’affermazione sulla compatibilità raggruppa in un’unica cella una popolazione indefinita e un giudizio di installazione.

Riparala suddividendo le etichette ampie in proprietà canoniche, ottenendo i valori da una fonte primaria nominata, aggiungendo un’unità a ogni misurazione e sostituendo gli spazi vuoti con lo stato corretto. Se la fonte non indica il grado di protezione IP, scrivi “Sconosciuto”; non convertire il linguaggio di marketing in un valore tecnico inventato.

Markup Schema e accessibilità

Non esiste un tipo Schema.org generale per una tabella specifiche. La tabella rimane un HTML semantico di valore anche quando non produce JSON-LD. Quando la pagina che la contiene rappresenta un’entità idonea, mappa solo dati esatti e verificati alle proprietà supportate: ad esempio, sku, weight, width, height, depth, material o additionalProperty di un prodotto, dove appropriato. I dati dell’organizzazione possono essere mappati a proprietà come ragione sociale o indirizzo. La tabella visibile e i dati strutturati devono concordare, usare le stesse unità e provenire dalla stessa fonte. Non inventare valutazioni, offerte, identificatori o proprietà schema solo perché esiste una riga.

L’accessibilità inizia con il markup reale. Dai alla tabella un <caption> descrittivo. Usa <th scope="row"> per ogni etichetta di specifica; le varianti field-reference necessitano anche di <th scope="col"> in un <thead>. Mantieni l’ordine di lettura logico nel codice sorgente, non solo sullo schermo. Non usare celle vuote, celle unite, icone come unico indicatore di stato, raggruppamenti basati solo sul colore o suggerimenti come unica posizione di un valore. Abbreviazioni come CA, CC e IP dovrebbero essere espanse nel testo vicino quando il pubblico previsto potrebbe non conoscerle.

Una tabella base a due colonne dovrebbe andare a capo anziché scorrere quando possibile. Quando una tabella più larga richiede lo scorrimento orizzontale, racchiudila in una regione con un’etichetta accessibile e tabindex="0", preserva un indicatore visibile del focus da tastiera e non bloccare mai la prima colonna in modo da coprire i valori a zoom elevato. Testa al 200% di zoom, con navigazione da tastiera e con gli stili disabilitati; la relazione etichetta–valore deve sopravvivere a tutti e tre i test.

Regole di scrittura

Le regole proteggono il recupero e il confronto, quindi la precisione viene prima della compattezza:

• Usa 3–12 righe per tabella. Suddividi insiemi più lunghi per attività del lettore — fisiche, elettriche, compatibilità, commerciali — invece di creare un muro indifferenziato di dati.
• Mantieni le etichette possibilmente tra 1 e 6 parole. Usa un qualificatore come “massimo”, “tipico”, “installato” o “per utente” quando cambia il significato.
• Mantieni un valore normale in una riga e non più di 12 parole. Sposta interpretazione, eccezioni e raccomandazioni nel testo adiacente o in una nota direttamente associata.
• Usa un sistema di misurazione per tabella a meno che il pubblico non necessiti genuinamente di entrambi. Quando sono richiesti entrambi, presenta il valore primario per primo e la conversione tra parentesi per ogni riga applicabile.
• Metti un’unità accanto a ogni misurazione numerica: 512 Wh, 3 m e 45 °C. Non affidarti mai a un’intestazione per fornire un’unità solo ad alcune righe.
• Normalizza le proprietà equivalenti tra pagine simili. Scegli un’etichetta e un’unità — ad esempio “Peso” in chilogrammi — e non alternare con “Massa”, libbre o frasi vaghe senza una ragione documentata.
• Usa parole di stato esatte: Sconosciuto, Non applicabile o Non disponibile. Definiscile una volta quando appare più di uno stato. Non usare mai un trattino, una cella vuota, TBC, un punto interrogativo o un colore per indicare lo stato.
• Usa un tono fattuale e neutro. I valori possono essere favorevoli, ma parole come “straordinario”, “ultraveloce”, “migliore della categoria” e “generoso” sono conclusioni, non specifiche.
• Non inserire mai inviti all’azione, testimonianze, paragrafi di testo promozionale, punteggi inspiegati, confronti non supportati o immagini decorative all’interno di una cella di valore.
• Indica la fonte e una data di verifica esatta per valori volatili o dichiarati esternamente. Se la proprietà non è chiara, la tabella non è pronta per la pubblicazione.

Tipi di post che lo utilizzano

Il campo frontmatter postTypes guida gli usi approvati qui sotto. L’inclusione significa che il tipo di post può richiedere o beneficiare dell’elemento; non significa che ogni pagina debba produrre tre dati per soddisfare un layout.

Checklist QA

• La tabella descrive un soggetto chiaramente identificato; più opzioni non sono state mascherate come tabella specifiche.
• La didascalia nomina sia il soggetto che l’ambito della tabella.
• Ogni proprietà usa un’etichetta precisa e canonica e ogni cella contiene un valore.
• I valori numerici includono unità, qualificatori, intervalli e dimensioni coerenti.
• Nessuna cella è vuota; Sconosciuto, Non applicabile e Non disponibile sono usati solo con i loro significati definiti.
• Le affermazioni corrispondono a una fonte primaria nominata e i dati volatili mostrano una data di verifica esatta.
• L’output pubblicato usa elementi nativi <table>, <caption>, intestazioni di riga e celle di dati anziché un’immagine o una griglia visiva.
• Le varianti field-reference includono intestazioni di colonna e preservano tutte le relazioni di intestazione.
• La tabella funziona a larghezze ridotte, zoom al 200%, con navigazione da tastiera e con stili disabilitati.
• Colore, icone, abbreviazioni e suggerimenti non sono mai l’unico modo per comprendere un valore.
• I dati visibili e qualsiasi proprietà Schema.org idonea concordano esattamente.
• Affermazioni promozionali, interpretazione, inviti all’azione e testi lunghi stanno al di fuori della tabella.
• L’elemento segue la regola di precedenza del playbook e il tipo di post selezionato include l’elemento nel suo contratto di contenuto.