Definizione corretta per "dati tabulari" in HTML

Question

Ho un argomento pedante che richiede una soluzione.

Come bevitore koolaid quando si tratta di HTML, mi occupo di markup semantico. Di conseguenza, ovviamente odio vedere tabelle a cui non appartengono. La regola generale per le tabelle è che dovresti usarle solo per "dati tabulari", ma ho notato che si tratta di una frase veramente mal definita. Volevo fare i seguenti dati una tabella, ma altri al mio ufficio d'accordo che una tabella sarebbe semanticamente corretto in questo caso (in contrapposizione ad un dl o ul, ecc):

------------------ 
| SomeEmployee | 
|----------------| 
| Field | val | 
| Field | val | 
| Field | val | 
| Field | val | 
------------------ 

Chiedendo in giro l'ufficio (e interwebs), ho avuto alcuni dei seguenti risposte su ciò che rende i dati "tabellare":

• "Tutto ciò che si dovrebbe mettere in un foglio di calcolo" (che ho visto intere prototipi di design realizzati in fogli di calcolo, quindi questo mi sembra un po 'carente)
• I dati che si associano bene a un database tabella (ad es. riga e colonna, in particolare)
• "Testo, testo preformattato, immagini, collegamenti, moduli, campi modulo, altre tabelle, ecc." (grazie W3C, che è davvero utile)

E così via e così via. Nessuna di queste sembra essere una definizione canonica, e non forniscono grandi linee di divisione per prendere decisioni. Quindi, ti chiedo, miei compatrioti intelligenti: come dovremmo definire i dati tabulari.

Se possibile, si prega di citare le fonti per le risposte per evitare una serie di risposte "ben penso".

Grazie!

Joe

Answer 1

Wikipedia ha alcune regole i piedi per terra, nelle sue linee guida interne di scrittura di articoli. Sono lontani da una definizione esauriente, ma funzionano bene nell'impiego IMO nel mondo reale.

• When tables are appropriate
• When tables may not be appropriate

Tutta la definizione è la pena di leggere, ma un paragrafo mi colpisce come particolarmente piacevole:

Prima di formattare una lista in forma di tabella, considerare se l'informazione sarà trasmessa più chiaramente in virtù di avere righe e colonne. Se è così, allora un tavolo è probabilmente una buona scelta. Se non ci sono evidenti vantaggi nell'avere righe e colonne, probabilmente una tabella non è la scelta migliore.

Answer 2

Il problema con il tuo esempio è che si trova in due colonne.

In questo limite, la distinzione tra se utilizzare un tag TABLE o un tag DL si attenua un po '. L'unico modo per distinguere sarebbe che nel dl, il tag DT dovrebbe essere un'etichetta e il dd dovrebbe contenere "dati". Se i "dati" che hai inserito nel tag DT NON sono un'etichetta (alias Metadata) nel tag DD, allora dovresti usare una tabella. Nel tuo esempio, questa è una sorta di dizionario, utilizzerei sicuramente un tag dl.Vorrei utilizzare una tabella in cui i dati in ciascuna delle due colonne rappresentano gli attributi INDEPENDENT di una cosa. Ma come dico, la distinzione sfoca.

Nella "tabella", la colonna Campo mi sembra più simile ai metadati. Quindi la regola sarebbe: usa sempre il tag più semanticamente specifico. In questo caso, un DL.

Quello che non farei MAI è utilizzare un tag ul o ol per questo. Molto semplicemente, sono per liste di colonne singole. Inoltre, non vi è alcun obbligo per ogni riga della lista di essere dati, cioè attributi che rappresentano una determinata cosa. Il contenuto dei tag UL o OL non contiene metadati associati: i tag UL e OL non forniscono alcun markup per i metadati, diversamente dai tag DL e TABLE.

Passando alla l'aspetto più generico della tua domanda, si applica quanto segue:

Come con il vero amore, si sa dati tabulari quando lo vedi.

E come per qualsiasi cosa tu sappia quando la vedi, la definizione precisa riempirebbe un volume di filosofie indigeribile. Per cominciare, dovresti definire cosa intendi per dati prima ancora di porre la domanda.

Con questi caveat in mente, e solo per l'esercizio mentale, qui andiamo:

A.- TABULAR dati devono essere dati strutturati: I dati devono essere o gerarchico o relazionale. Con questo intendo che dovrebbe essere POSSIBILE gettare i dati nell'una o nell'altra struttura (o in entrambi).

Questo permette le seguenti regole da derivati, che praticamente bloccano giù ciò che può andare in una tabella di dati, rispondendo in tal modo la tua domanda e conformi ai requisiti del W3C per l'uso del tag:

1. Atomicità : Ogni ROW di dati deve rappresentare una singola UNIT della stessa cosa. Vale a dire, i dati in ciascuna cella della tabella DEVONO essere un attributo di ciò che rappresenta ogni ROW di dati. Questo ti dice velocemente perché alcune cose dovrebbero andare nei tag UL: sono LISTE NON STRUTTURATE, cioè ogni riga può riferirsi a cose molto diverse, al contrario di DATI STRUTTURATI, dove ogni riga rappresenta SEMPRE una diversa istanza di una classe di cose.

2. CELL: Dovrebbe essere possibile mettere ogni attributo della cosa in un tag (ovvero una cella). Il contenuto di ogni cella deve essere dati; non sono ammessi elementi di layout. Nota che questo esclude elementi accessori come le intestazioni di colonna, che non dovrebbero usare tag e dovrebbero usare il tag funzionalmente più appropriato.

3. DEFINIZIONE DI RIGA O "FORMATO" DEI DATI: i dati in ogni riga() devono essere mappati su un "formato" predefinito. Per formato, intendo una lista di attributi che descrivono una determinata cosa. In quanto segue, i termini attributo e colonna sono usati in modo intercambiabile.

4. ORDINE COLONNA: questo formato deve essere ordinato rigorosamente. Vale a dire, l'ordine delle colonne non deve cambiare da una riga all'altra.

5. INDIPENDENZA DI RIGA: i dati in ogni riga non devono dipendere dai dati in altre righe. Né dovrebbe dipendere dall'esistenza di altre righe. I dati in ogni riga dipendono solo dal 'formato'.

6. INTEGRITÀ RIGA: i dati di ogni riga devono essere conformi ai vincoli definiti dal formato.

7. DATI CORRELATI: è necessario estendere le regole precedenti per tenere conto dei dati correlati e gerarchici. Questo è facilmente possibile estendendo il formato per consentire un tipo di colonna che è esso stesso una tabella.

8. Nelle regole precedenti, da nessuna parte si afferma che le "colonne" devono essere organizzate orizzontalmente. Ciò consente alle righe di avere più "struttura" e comunque rispettare le regole 0 - 6. Ad esempio, una tabella secondaria di dati "figlio" può apparire SOTTO i dati corrispondenti al suo record "genitore". O no. O un grande campo Memo potrebbe visualizzare le altre celle. Solo perché si tratta di dati tabulari non significa che non possa avere layout.

9. DATI IMMAGINE: un'immagine del prodotto in un catalogo è dati. Tuttavia, nel caso delle immagini, il vincolo di colonna è che l'immagine DEVE riguardare le altre "colonne" del "formato". Ad esempio, questo elimina una GIF trasparente che giustifica l'altezza e la larghezza fisica di una riga. Come ha alcuna relazione intrinseca agli altri dati nella fila, non sta adempiendo norme 0 - 7.

B.- dati di tabella NON INCLUDE dati non strutturati. Questo è più di un corollario, ma affronta i "mali" del tag:

1. Tutto ciò che è il layout, ad esempio, relativi alla sistemazione dei contenuti e la pagina, in contrasto con il contenuto stesso, non è dati tabulari .

È possibile che questo non fa altro che utilizzare stronzate per lucidare la seguente regola che lei stesso ha affermato nella sua domanda:

Tutto ciò che va in un foglio di calcolo o di una tabella di database, ignorando usi di fogli di calcolo che fanno non si riferiscono ai dati.

Ciò che non è una cazzata è l'affermazione ovvia, ma potenzialmente vaga, che i dati tabulari non sono altro che dati strutturati. Per struttura, intendo che deve costituire una raccolta "fortemente tipizzata".

Ancora una volta, noto che questa definizione esclude il testo per intestazioni di colonne, didascalie, piè di pagina. In altre parole, i dati tabulari sono ciò che va con il tag tbody. Tutto il resto del tag table è metadati a cui fa riferimento, ma non fa parte, i dati tabulari.

Le regole precedenti definiscono i dati come qualcosa che soddisfa un vincolo di colonna.

Quindi immagino che ora sia necessaria una definizione di un vincolo di colonna. Ma poi di nuovo, ne sai uno quando ne vedi uno ...