Elenchi Personalizzati: Schema degli Elementi, Limiti ed Esempi

Un elenco personalizzato è una raccolta ripetibile di elementi che condividono un piccolo schema di campi. Ogni elemento può avere un titolo, un riepilogo conciso, uno o due valori di metadati e un collegamento di destinazione. Questa struttura offre ai lettori più contesto rispetto a un elenco puntato senza far sì che ogni elemento si comporti come una scheda prodotto autonoma.

Esempio — formati di esportazione supportati

• CSV — Righe tabellari per l’analisi in fogli di calcolo. Ideale per record piatti. Disponibilità: Tutti i piani. Azione: Visualizza la configurazione dell’esportazione CSV.
• JSON — Record annidati per applicazioni e pipeline di dati. Ideale per preservare le relazioni tra campi. Disponibilità: Pro e Enterprise. Azione: Leggi il riferimento JSON.
• Google Sheets — Un foglio di lavoro sincronizzato per team che esaminano i dati senza codice. Disponibilità: Pro e Enterprise. Azione: Collega Google Sheets.

L’elemento renderizzato non dovrebbe essere una versione decorativa di quegli elenchi puntati. Dovrebbe esporre una raccolta contenente tre elementi, e ogni elemento dovrebbe preservare gli stessi campi title, summary, bestFor, availability e url. Il modello di campi — non il bordo, l’icona o il numero di colonne — è ciò che rende l’elenco personalizzato.

Perché questo elemento è importante

Il testo discorsivo ordinario nasconde le ripetizioni. Se sei integrazioni sono descritte in sei paragrafi, un lettore deve scoprire che ogni paragrafo contiene un nome di sistema, un’azione supportata, un requisito di account e un link di configurazione. Un elenco personalizzato nomina quelle parti ricorrenti attraverso uno schema di elementi: un insieme definito di campi utilizzato da ogni elemento. I lettori imparano lo schema dopo la prima voce e possono scorrere le voci successive in modo prevedibile.

Questa coerenza migliora anche il riutilizzo. Un sistema di gestione dei contenuti può validare i campi obbligatori, un template può renderizzare ogni elemento senza markup specifico per la pagina, e un’applicazione downstream può trasformare la stessa fonte in un elenco mobile compatto o in una directory ricercabile. I motori di ricerca e i sistemi di IA ricevono confini discreti per gli elementi invece di dover dedurre dove un’entità finisce e un’altra inizia.

L’elemento è importante perché esiste un divario comune tra due strutture valide. Gli elenchi puntati funzionano quando ogni elemento è una dichiarazione compatta. Le schede funzionano quando ogni elemento necessita di immagini indipendenti, diversi attributi commerciali, un’azione prominente o un peso visivo sufficiente per stare da solo. Molte raccolte non necessitano di nessuno dei due estremi. Un elenco di integrazioni può richiedere un nome, un riepilogo delle capacità in due frasi, uno stato e un collegamento. Appiattirlo in elenchi puntati perde i campi; gonfiarlo in schede spreca spazio e fa sembrare una raccolta di riferimento promozionale.

La struttura non è una scusa per rendere ogni raccolta personalizzata. Un design una tantum produce campi incoerenti, ordinamento, accessibilità e comportamento reattivo. Le regole di scrittura degli elementi si applicano quindi per prime: identifica l’esigenza informativa ripetuta, registra lo schema più piccolo che la soddisfa e mantieni il contenuto portabile tra diversi renderer.

Quando usarlo

Usa un elenco personalizzato quando tutti gli elementi rispondono alla stessa domanda del lettore, ciascuno necessita da due a cinque campi visibili e il compito principale è ispezionare o navigare piuttosto che confrontare ogni valore affiancato. Le raccolte adatte includono integrazioni, aree di servizio, formati supportati, download di risorse, tipi di partner, responsabilità di team, anteprime di directory e funzionalità raggruppate.

Esegui quattro test prima di sceglierlo:

1. Ripetibilità: Ogni elemento può usare gli stessi campi obbligatori senza inventare eccezioni?
2. Indipendenza: Un lettore può comprendere un elemento senza aver letto l’elemento precedente?
3. Scansionabilità: Il pattern titolo-più-riepilogo è più utile di una griglia di valori confrontabili?
4. Azione: Ogni elemento necessita di non più di una destinazione principale?

Se le risposte sono sì, un elenco personalizzato è probabilmente appropriato. Usa un altro elemento quando la raccolta fallisce uno di questi test:

• Usa un elenco puntato quando gli elementi necessitano solo di una frase parallela e nessun metadato separato.
• Usa una tabella comparativa quando i lettori devono scansionare gli stessi criteri verticalmente o orizzontalmente tra le alternative.
• Usa una scheda prodotto quando immagine, prezzo, offerta, valutazione, disponibilità e azione di acquisto rendono ogni elemento un’unità commerciale sostanziale.
• Usa un elenco di passaggi quando la posizione esprime una sequenza piuttosto che un ordinamento editoriale.
• Usa un glossario o un pattern di definizione quando ogni voce è fondamentalmente una coppia termine-definizione.
• Usa titoli e testo discorsivo quando gli elementi richiedono campi diversi o più di circa 100 parole di spiegazione ciascuno.

Non selezionare un elenco personalizzato semplicemente perché il design richiede box ripetuti. Prima dimostra che esiste un modello di contenuto stabile. Se l’elemento uno ha un prezzo e l’elemento due ha una biografia dell’autore mentre l’elemento tre ha una dimensione di download, non sono un’unica raccolta anche se il CSS può allinearli.

Dove posizionarlo

Posiziona l’elenco dopo che la pagina definisce la raccolta e la sua regola di inclusione. “Integrazioni supportate” è un’etichetta; “Queste integrazioni possono inviare pagine verificate a un workspace di reporting di proprietà” dice ai lettori cosa significa l’appartenenza. Quando la selezione o il test ha creato l’insieme, spiega quel metodo prima del primo elemento in modo che l’elenco non implichi completezza o classifica non supportata.

Colloca la raccolta vicino al compito decisionale o di navigazione che serve. Una pagina di integrazione dovrebbe introdurre la connessione e il suo risultato prima di elencare i flussi di lavoro supportati. Una directory dovrebbe spiegare ambito e filtri prima di mostrare le voci. Una listicle dovrebbe dichiarare il suo metodo di valutazione prima di presentare gli elementi selezionati.

Non interrompere un elenco con testo discorsivo, pubblicità, inviti all’azione o screenshot non correlati. I confini degli elementi devono rimanere consecutivi. Posiziona le qualifiche all’interno dei metadati definiti dell’elemento interessato o spiega una condizione valida per l’intera raccolta prima o dopo l’intero elenco. Se sono necessari più di dodici elementi, raggruppali sotto sottotitoli significativi, aggiungi filtraggio o indirizza i lettori a un Indice directory . Non creare un’unica pila visiva infinita.

Anatomia

Un elenco personalizzato completo ha queste regioni:

1. Titolo della raccolta: nomina l’insieme nel linguaggio del lettore, non nel nome interno del componente.
2. Dichiarazione di ambito: definisce cosa è qualificato per l’inclusione e se la raccolta è completa, selezionata o illustrativa.
3. Contenitore elenco: stabilisce una raccolta semantica e possiede il conteggio degli elementi.
4. Titolo elemento: identifica in modo univoco l’entità, la risorsa, la capacità o l’opzione.
5. Riepilogo elemento: spiega la differenza o l’uso rilevante dell’elemento in una o due frasi.
6. Gruppo metadati: espone da zero a tre fatti etichettati dallo schema registrato.
7. Azione principale: collega a una destinazione chiara utilizzando testo anchor descrittivo.
8. Confine elemento: utilizza spaziatura, una riga o un trattamento di superficie contenuto senza disconnettere l’elemento dalla sua raccolta.

La dichiarazione di ambito previene un comune fallimento di accuratezza. “Integrazioni disponibili” implica completezza; “Integrazioni di reporting comuni” dichiara una selezione. L’autore deve scegliere la dicitura che la fonte dati può supportare.

Esempi di design

Il renderer può variare la densità, ma deve preservare l’ordine dei campi, la struttura semantica dell’elenco e una sequenza di lettura prevedibile.

Elenco editoriale impilato

Usa il design impilato predefinito quando i riepiloghi portano la maggior parte del valore. Mantieni il titolo per primo, il riepilogo secondo, i metadati terzi e l’azione per ultima. Un sottile divisore è sufficiente; ogni elemento non necessita di una scheda rialzata.

Anteprima directory compatta

Usa una variante compatta quando titoli e un valore di metadato permettono ai lettori di scegliere una destinazione. Il riepilogo può essere più breve, ma le etichette devono rimanere visibili. Non sostituire mai uno stato significativo con un punto colorato non spiegato.

Elenco raggruppato

Usa i gruppi quando una classificazione stabile riduce una raccolta da otto a ventiquattro elementi in sezioni. Le intestazioni di gruppo devono descrivere una tassonomia genuina come tipo di esportazione o regione di servizio. Non raggruppare semplicemente per ottenere colonne uguali.

Viewport stretto

A larghezze ridotte, preserva l’ordine sorgente e impila i metadati sotto il riepilogo. Non nascondere campi che rimangono rilevanti, ridurre il testo per mantenere le colonne o spostare le azioni lontano dal loro elemento.

Parametri

Lo schema seguente è intenzionalmente limitato. Un campo diventa parte del componente solo quando è utile nell’intera raccolta, non perché un elemento ha casualmente dati per esso.

Tre elementi sono il minimo perché una coppia è di solito più chiara come testo discorsivo, un confronto a due colonne o due schede sostanziali. Dodici è il massimo normale perché scorrere una lunga pila non filtrata diventa inefficiente. Il tetto raggruppato di ventiquattro è un guardrail, non un obiettivo; insiemi più grandi o in frequente cambiamento necessitano di una directory, ricerca, paginazione o un’applicazione data-driven.

Scegli ordered=true solo quando l’ordine visibile esprime una classifica dichiarata. La convenienza editoriale, l’ordinamento alfabetico o l’ordine della fonte dati non creano una classifica. Quando la classifica è reale, indica la metodologia e mantieni la posizione sia nell’output visibile che in qualsiasi dato strutturato.

Sintassi ed esempi di codice

La direttiva portabile definisce il contratto di authoring. Gli adattatori di piattaforma possono memorizzare i dati diversamente, ma devono preservare gli stessi nomi di campo, ordine degli elementi, opzionalità e output visibile.

Direttiva Markdown portabile

:::custom-listing{title="Formati di esportazione" variant=stacked}
Questi sono i formati disponibili per inviare record di audit completati a un altro workspace.

:::item{id=csv title="CSV" url="/docs/exports/csv/"}
Righe tabellari per l'analisi in fogli di calcolo e l'importazione di file piatti.

- Ideale per: Analisi in fogli di calcolo
- Disponibilità: Tutti i piani
- Azione: Visualizza configurazione esportazione CSV
:::

:::item{id=json title="JSON" url="/docs/exports/json/"}
Record annidati che preservano le relazioni per applicazioni e pipeline di dati.

- Ideale per: Flussi di lavoro automatizzati
- Disponibilità: Pro e Enterprise
- Azione: Leggi il riferimento JSON
:::

:::item{id=sheets title="Google Sheets" url="/docs/exports/google-sheets/"}
Un foglio di lavoro sincronizzato per team che esaminano i dati senza codice.

- Ideale per: Revisione condivisa
- Disponibilità: Pro e Enterprise
- Azione: Collega Google Sheets
:::
:::

Gli URL di esempio descrivono solo la sintassi portabile; un’implementazione deve sostituirli con destinazioni verificate. Non pubblicare un percorso di esempio come collegamento funzionante solo perché appare in un blocco di codice.

Adattatore Hugo

{{< custom-listing title="Export formats" variant="stacked" >}}
  {{< custom-listing-item id="csv" title="CSV" url="/docs/exports/csv/" action-label="View CSV export setup" >}}
  Tabular rows for spreadsheet analysis and flat-file ingestion.

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

Questa notazione specifica un adattatore futuro o a livello di progetto; non autorizza la creazione di uno shortcode locale alla pagina. Tutti i parametri sono nominati. Fino a quando non esiste un adattatore, renderizza la raccolta come HTML semantico con <ul> e <li> o come Markdown nativo piuttosto che eliminare silenziosamente le relazioni tra campi.

Blocco WordPress

<!-- wp:amicited/custom-listing {"title":"Export formats","variant":"stacked"} -->
<ul class="custom-listing">
  <li data-item-id="csv">
    <h3>CSV</h3>
    <p>Tabular rows for spreadsheet analysis and flat-file ingestion.</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 -->

I blocchi nativi sono un fallback accettabile quando producono un unico elenco, un elemento elenco per voce, intestazioni reali, un elenco di definizioni per metadati etichettati e collegamenti descrittivi. Un blocco generico Columns non è un sostituto affidabile perché l’ordine sorgente e il raggruppamento degli elementi spesso si rompono su mobile.

Esempi

Buono: un elenco di risorse coerente

Risorse per la migrazione

Queste risorse supportano i team nella preparazione, esecuzione e validazione di una migrazione del sito.

1. Foglio di lavoro mappatura redirect — Registra ogni vecchio URL, la sua destinazione approvata, il proprietario e lo stato di validazione. Formato: Foglio di calcolo. Fase: Pianificazione. Azione: Scarica il foglio di lavoro redirect.
2. Script di validazione giorno del lancio — Controlla codici di risposta, catene di redirect, target canonical e indicizzabilità per l’insieme di URL migrati. Formato: Script. Fase: Lancio. Azione: Rivedi la configurazione di validazione.
3. Vista monitoraggio post-lancio — Tiene traccia di errori di crawling e cambiamenti imprevisti del traffico dopo la distribuzione. Formato: Dashboard. Fase: Monitoraggio. Azione: Configura la vista di monitoraggio.

Funziona perché ogni elemento usa gli stessi cinque campi: titolo, riepilogo, formato, fase e azione. L’ambito spiega perché le risorse appartengono insieme. La numerazione riflette la fase di migrazione dichiarata, non un’affermazione che la prima risorsa sia “la migliore”. Ogni azione identifica la sua destinazione invece di ripetere “Scopri di più”.

Cattivo: box senza un modello condiviso

Cose utili

• Checklist SEO — La nostra guida preferita. Aggiornata di recente. Scopri di più.
• Audit premium — €499, include una chiamata e un report. Cinque stelle. Acquista ora.
• Viktor — Responsabile tecnico con sede a Bratislava, disponibile il martedì.
• Documentazione API — Autenticazione, limiti, errori, esempi, SDK, changelog, stato, supporto e altri venti argomenti.

Fallisce prima ancora che inizi la progettazione visiva. L’insieme mescola una risorsa, un servizio, una persona e un’area di documentazione. I campi cambiano su ogni elemento, “di recente” non ha una data, la valutazione manca di fonte e scala, e la profondità degli elementi va da un frammento a uno schema di sezione. Suddividi il contenuto per scopo, poi scegli l’elemento registrato per ogni raccolta. Un bordo attorno a dati incoerenti non crea un elenco personalizzato.

Cattivo: un elenco che dovrebbe essere una tabella

Supponiamo che sei piani mostrino ciascuno prezzo mensile, prezzo annuale, limite utenti, storage, tempo di risposta del supporto e disponibilità SSO. I lettori devono confrontare gli stessi sei valori attraverso ogni piano. Un elenco li costringerebbe a ricordare il piano uno mentre scorrono fino al piano sei. Usa una tabella comparativa perché il compito è la valutazione incrociata degli elementi. Se ogni piano necessita anche di una dichiarazione di posizionamento e di un’azione di acquisto, posizionali all’esterno o accanto alla tabella usando il componente piano registrato della pagina; non duplicare valori contrastanti in due fonti.

Markup schema e accessibilità

Renderizza la raccolta con semantica nativa di elenco. Usa <ul> quando l’ordine degli elementi non ha significato e <ol> quando la pagina dichiara una sequenza o classifica genuina. Ogni voce appartiene a un unico <li>. Al suo interno, usa un’intestazione reale al livello corretto del documento, un paragrafo per il riepilogo e <dl>, <dt> e <dd> per i metadati etichettati. Uno screen reader dovrebbe incontrare il titolo dell’elemento prima della sua descrizione, dei fatti e dell’azione.

Non rendere l’intero elemento un collegamento sovradimensionato quando contiene un altro controllo o diverse aree di testo. Dai al collegamento principale un’etichetta descrittiva come “Visualizza configurazione esportazione CSV”. Se viene utilizzato un pattern stretched-link, il suo indicatore di focus deve rimanere visibile e il suo nome accessibile deve ancora descrivere la destinazione. Le icone necessitano di testo alternativo solo quando comunicano informazioni non già presenti nel testo. Le icone decorative dovrebbero essere nascoste alla tecnologia assistiva.

L’ordine visivo e l’ordine sorgente devono corrispondere. Un layout desktop a più colonne deve collassare senza leggere elemento uno, elemento tre, elemento cinque, poi elemento due. Le etichette dei metadati non possono scomparire solo perché i valori ripetuti appaiono visivamente allineati; “Enterprise” da solo non dice a un lettore non vedente se descrive disponibilità, pubblico o supporto.

I dati strutturati ItemList sono opzionali, non un gancio di stile predefinito. Usali quando la raccolta visibile è un elenco finito significativo e la pagina trae beneficio dall’identificazione di quella raccolta. Mappa ogni voce visibile a itemListElement. Includi position solo per un vero elenco ordinato, e assicurati che nomi, URL e conteggi corrispondano al contenuto renderizzato. Non marcare menu di navigazione, teaser di funzionalità arbitrari o un insieme parziale come se fossero un elenco completo classificato. Quando le voci sono entità identificabili come organizzazioni o applicazioni software, usa il tipo ammissibile più specifico solo quando la pagina fornisce e verifica i dati di identità richiesti.

Regole di scrittura

1. Spiega l’appartenenza prima di presentare i membri. I lettori devono sapere se l’insieme è completo, selezionato, sponsorizzato, classificato o illustrativo prima di interpretare omissioni o ordine. Dichiara la regola di inclusione nella frase di ambito.
2. Definisci uno schema di elementi prima di redigere gli elementi. Campi coerenti permettono ai lettori di imparare un pattern di scansione e permettono alla validazione di individuare contenuti mancanti. Registra i campi obbligatori e opzionali prima che gli autori popolino la raccolta.
3. Mantieni i campi obbligatori veramente universali. Un campo nominalmente obbligatorio che gli autori riempiono con “N/D” nella metà delle voci è il campo sbagliato o la prova che la raccolta contiene diversi tipi di elementi.
4. Limita i metadati visibili a tre coppie. Più campi spostano il compito verso il confronto e rendono ogni riga difficile da scansionare. Sposta i fatti secondari nella pagina di destinazione o usa una tabella.
5. Scrivi riepiloghi per la differenza, non per la ripetizione. Il titolo già nomina l’elemento. Usa il riepilogo per spiegare la sua capacità rilevante, il pubblico, la limitazione o il ruolo.
6. Usa etichette e unità parallele. Non alternare “Piano”, “Disponibile su” e “Livello” per lo stesso concetto. Normalizza date, valute, unità e vocabolario degli stati prima di renderizzare.
7. Dai a ogni elemento un’azione principale. Pulsanti concorrenti trasformano un elenco di riferimento in una griglia di schede e oscurano il passo successivo previsto. Metti le destinazioni secondarie nella pagina di dettaglio.
8. Dichiara l’ordine significativo. Ordini alfabetici, cronologici, classificati, editoriali e del sistema sorgente creano aspettative diverse. Nomina l’ordine quando potrebbe influenzare l’interpretazione.
9. Imposta conteggi minimi e massimi. Usa normalmente da tre a dodici elementi, fino a ventiquattro solo in gruppi utili. Cambia pattern quando la raccolta cade al di fuori di questi limiti.
10. Mantieni un’unica fonte di verità. Se prezzo, stato, disponibilità o un altro campo volatile appare altrove, popola ogni rappresentazione dalla stessa fonte di proprietà e mostra una data di verifica dove necessario.

Tipi di post che lo utilizzano

• Una Guida Listicle usa un elenco personalizzato quando ogni voce selezionata necessita dello stesso riepilogo, idoneità, limitazione e collegamento successivo ma non di una matrice di confronto densa.
• Una Pagina Best-X-for-Y può usarlo per raccomandazioni specifiche per pubblico dopo aver spiegato il metodo di valutazione. La classifica deve essere esplicita piuttosto che implicita dall’ordine visivo.
• Una Pagina Alternatives-to-X può presentare opzioni di sostituzione con campi coerenti di “ideale per”, compromesso e collegamento dettagli prima di un confronto più mirato.
• Una Pagina categoria usa un elenco compatto o raggruppato per anteprimere un insieme gestibile di prodotti o servizi figli quando il filtraggio non è ancora necessario.
• Un indice directory usa l’elemento solo per un’anteprima o una directory piccola e stabile. Insiemi di grandi entità necessitano di ricerca, filtri, paginazione e un’interfaccia directory basata sui dati.
• Un Profilo aziendale può elencare unità aziendali verificate, certificazioni o sedi quando ogni voce condivide gli stessi campi.
• Un Profilo fornitore può elencare servizi supportati, regioni o modelli di engagement senza trasformare il profilo in una griglia di prodotti.
• Una Pagina di integrazione può elencare flussi di lavoro supportati, oggetti dati, trigger o destinazioni utilizzando uno schema prevedibile di capacità e requisiti.

La presenza di una raccolta non richiede questo elemento. Usalo solo quando il modello di campi personalizzato migliora il recupero o la navigazione. Un breve insieme di prerequisiti appartiene ancora agli elenchi puntati, e una matrice di capacità appartiene ancora a una tabella.

Checklist QA

• La raccolta ha un titolo e una frase di ambito che definisce l’inclusione.
• Ogni elemento rappresenta lo stesso tipo di entità, risorsa, capacità o opzione.
• I campi obbligatori e opzionali sono documentati prima dell’inserimento del contenuto.
• Ogni elemento ha un ID stabile univoco, titolo e riepilogo di 12–60 parole.
• Nessun elemento inventa un campo assente dallo schema registrato.
• La raccolta contiene 3–12 elementi, o gruppi giustificati con non più di 24 totali.
• Gli elementi hanno non più di tre coppie di metadati visibili e un’azione principale.
• Etichette, unità, stati, date e formulazione delle azioni sono coerenti.
• L’ordine è dichiarato quando implica classifica, cronologia o priorità.
• Una tabella è stata scelta invece quando il confronto incrociato è il compito principale.
• L’output usa un unico <ul> o <ol> semantico con un <li> per elemento.
• Le intestazioni seguono la gerarchia della pagina e i metadati usano semantica termine–descrizione.
• Il focus da tastiera è visibile e i collegamenti descrivono le loro destinazioni.
• L’ordine sorgente corrisponde all’ordine visivo a larghezze desktop e mobile.
• Il markup ItemList, se presente, corrisponde agli elementi visibili, all’ordine, al conteggio, ai nomi e agli URL.
• I valori volatili provengono da una fonte di proprietà e includono una data di verifica appropriata.

FAQ

Le domande seguenti risolvono i confini che più spesso causano la deriva di un elenco personalizzato verso elenchi puntati, schede o tabelle.

Cos’è un elenco personalizzato?

Un elenco personalizzato è una raccolta ripetibile i cui elementi condividono un piccolo schema di campi con nome, come titolo, riepilogo, metadati e collegamento. Si colloca tra un semplice elenco puntato e una griglia di schede visivamente indipendente.

Quanti elementi dovrebbe contenere un elenco personalizzato?

Usa da tre a dodici elementi come intervallo editoriale normale. Due elementi di solito necessitano di testo discorsivo o un componente affiancato. Più di dodici necessitano di raggruppamento utile, filtraggio, paginazione o un pattern directory; la variante raggruppata non deve superare i ventiquattro elementi.

Quando un elenco personalizzato dovrebbe diventare una tabella?

Usa una tabella quando i lettori devono confrontare la maggior parte degli elementi attraverso gli stessi tre o più campi, specialmente valori numerici, date, stati o capacità sì/no. Mantieni un elenco quando riepiloghi e collegamenti successivi sono più importanti del confronto incrociato tra elementi.

Un elenco personalizzato necessita dello schema ItemList?

No. Aggiungi ItemList solo quando la raccolta è significativa e finita, ogni elemento marcato è visibile e qualsiasi posizione riflette un ordine dichiarato. La navigazione ordinaria, i teaser e gli elenchi di contenuti correlati di solito necessitano di HTML semantico anziché uno schema speciale.

Gli elementi possono avere campi diversi?

Solo i campi opzionali definiti dallo schema condiviso possono essere assenti. Non permettere agli autori di inventare campi per ogni elemento. Se diversi elementi necessitano di un modello informativo differente, suddividili in un altro elenco o scegli un elemento più adatto.