Perché le persone creano tavoli con div?

Nello sviluppo web moderno mi imbatto in questo modello sempre più spesso. Sembra così:

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

E nei CSS c'è qualcosa di simile:

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{* (I nomi delle classi sono solo illustrativi; nella vita reale si tratta di nomi di classi normali che riflettono ciò di cui tratta l'elemento)}

Di recente ho anche provato a farlo da solo perché ... sai, lo stanno facendo tutti.

Ma ancora non capisco. Perché stiamo facendo questo? Se hai bisogno di un tavolo, fai semplicemente uno scoppio <table>e finisci . Sì, anche se è per il layout. Ecco a cosa servono le tabelle: disporre le cose in modo tabulare.

La migliore spiegazione che ho è che ormai tutti hanno sentito il mantra di "non usare le tabelle per il layout", quindi lo seguono ciecamente. Ma hanno ancora bisogno di una tabella per il layout (perché nient'altro ha le capacità di espansione di una tabella), quindi creano un <div>(perché non è una tabella!) E quindi aggiungono CSS che la rende comunque una tabella.

Per tutto il mondo questo mi sembra come mettere ostacoli arbitrari inutili sulla tua strada e poi fare un lavoro extra per aggirarli.

L'argomento originale per allontanarsi dalle tabelle per il layout era che in seguito è difficile modificare un layout tabulare. Ma modificare un layout a "tabella falsa" è altrettanto difficile e per gli stessi motivi. In effetti, in pratica la modifica di un layout è sempre difficile e non è quasi mai sufficiente cambiare il CSS, se si desidera fare qualcosa di più serio di piccole modifiche. Si avrà bisogno di capire e cambiare la struttura HTML per gravi modifiche di progettazione. E le tabelle non rendono il lavoro più difficile o più facile dei div.

In realtà, l'unico modo di vedere che le tabelle potrebbero fare un layout difficile da modificare, è se si ab loro usato e creato un pasticcio empio. Puoi farlo anche con i div.

Quindi ... nel tentativo di trasformare questo da un rant in una domanda coerente: cosa mi sto perdendo? Quali sono i vantaggi effettivi dell'utilizzo di una "tabella delle faux" rispetto a una vera?

Informazioni sul collegamento duplicato: questo non è un suggerimento per utilizzare un altro tag o qualcosa del genere. Questa è una domanda sull'utilizzo di un <table>vs display:table.

Questo è un modello comune per creare tabelle reattive. I dati tabulari sono difficili da visualizzare sui dispositivi mobili poiché la pagina verrà ingrandita per leggere il testo, il che significa che le tabelle vanno fuori dal lato della pagina e l'utente deve scorrere avanti e indietro per leggere la tabella, oppure la pagina verrà ingrandita , in genere significa che la tabella è troppo piccola per poter essere letta.

Le tabelle reattive cambiano il layout su schermi più piccoli - a volte alcune colonne sono nascoste o le colonne sono mescolate, ad esempio il nome e l'indirizzo e-mail potrebbero essere separati su schermi di grandi dimensioni, ma collassare in una cella su schermi di piccole dimensioni in modo che le informazioni siano leggibili senza scorrere.

<div>s vengono utilizzati per creare le tabelle anziché i <table>tag per un paio di motivi. Se <table>vengono utilizzati i tag, è necessario sovrascrivere gli stili e il layout predefiniti del browser prima di aggiungere il proprio codice, quindi in questo caso i <div>tag salvano molti CSS CSS. Inoltre, le versioni precedenti di IE non consentono di sovrascrivere gli stili di tabella predefiniti, quindi l'utilizzo di <div>s facilita anche lo sviluppo tra browser.

C'è una buona panoramica delle tabelle reattive sui trucchi CSS .

Modifica: dovrei sottolineare che non sto sostenendo questo modello - cade nella trappola della divite e non è semantico - ma è per questo che troverai tabelle fatte da divs.

La domanda è se i dati sono semanticamente una tabella (ovvero un insieme di dati o unità di informazioni organizzati logicamente in due dimensioni) o si utilizza semplicemente la griglia per il layout visivo, ad esempio perché si desidera espandere una barra laterale o qualcosa del genere.

Se le tue informazioni sono semanticamente una tabella, usi un <table>-tag. Se vuoi solo una griglia per scopi di layout, usi alcuni altri elementi html appropriati e li usi display:tablenel foglio di stile.

Quando i dati sono semanticamente una tabella? Quando i dati sono organizzati logicamente lungo due assi. Se ha senso con le intestazioni per le righe o le colonne, potresti avere una tabella semantica. Un esempio di qualcosa che non è semanticamente una tabella sta presentando un testo in colonne come in un giornale. Questa non è una tabella semanticamente, dal momento che la leggeresti in modo lineare e non verrebbe perso alcun significato se la presentazione fosse rimossa.

OK, perché non usarlo <table>per tutto piuttosto che solo per qualcosa che è semanticamente una tabella? Visivamente è ovviamente lo stesso (poiché l'elemento della tabella ha solo display:elementnel foglio di stile predefinito).

La differenza è che le informazioni semantiche possono aiutare agenti utente alternativi. Ad esempio, uno screen reader potrebbe consentire di navigare in due dimensioni nella tabella e leggere le intestazioni di una cella per entrambi gli assi se si dimentica dove ci si trova. Questo sarebbe solo fonte di confusione se la tabella non fosse semanticamente una tabella ma solo per il layout visivo.

La discussione <table>contro display:tableè solo un caso del principio più generale dell'uso del markup semantico. Vedi per esempio: perché dovremmo preoccuparsi di eseguire il markup in modo corretto e semantico? o Perché al markup semantico viene dato più peso ai motori di ricerca?

In alcuni casi potresti essere effettivamente obbligato per legge a utilizzare il markup semantico per motivi di accessibilità e in ogni caso non vi è motivo di rendere intenzionalmente la tua pagina meno accessibile.

Anche se non ti interessano gli utenti disabili, avere una presentazione separata dai contenuti ti dà dei vantaggi. Ad esempio, il layout a tre colonne potrebbe essere presentato in colonne singole su un dispositivo mobile utilizzando un foglio di stile alternativo.

In realtà, direi che l'uso di nomi di classe come "table" nel tuo esempio dimostra come le persone in realtà non capiscono cosa stanno facendo quando provano per il markup semantico. Ottengono voti per aver provato a mostrare che il contenuto non è un dato tabulare , ma perdono voti per nomi di classi sbagliati.

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

Tutto ciò che questo sviluppatore ha fatto è replicare il <table>markup originale con i nomi delle classi CSS. Ciò significa che non appena questo layout non è una tabella, i nomi delle classi sono in contrasto.

Ciò che questo sviluppatore avrebbe dovuto fare è considerare quali informazioni sono presenti nella tabella: è una galleria di miniature? Bene allora:

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

Ora posso creare alcuni CSS adattivi:

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

Perché div e non tabelle

Una tabella contiene dati tabulari : la presentazione di una tabella è indissolubilmente legata alla struttura di una tabella. I dati tabulari dovranno sempre essere in forma tabellare, indipendentemente da dove si inserisce quel contenuto o su quale schermo / dispositivo si desidera vengano visualizzati.

Una galleria di miniature (o molte altre cose, come un modulo di registrazione, un menu e altro) non sono dati tabulari. Può essere presentato come una tabella in alcuni layout di progettazione, ma in altri casi, come schermi di telefoni stretti, lo si desidera utilizzando layout di blocco più tradizionali. O forse vuoi visualizzare le anteprime in una barra laterale anziché nell'area del contenuto principale.

La tua scelta ora è quella di generare markup diversi per il contenuto wide screen (tabelle) e la barra laterale o il contenuto dello schermo stretto (div) - il che significa che gli script lato server dovranno essere consapevoli di dove sta andando il contenuto se lo stai costruendo a livello di codice - oppure hai l'output del tuo script lato server lo stesso markup (perché non dovrebbe interessarti dove lo stai inserendo) e utilizzare regole CSS diverse per le diverse situazioni.

Quindi, puoi scegliere di emettere sempre tabelle e quindi sovrascrivere le regole di visualizzazione della tabella naturale con il blocco (che dovrebbe davvero macinare alcuni ingranaggi nella testa di qualsiasi sviluppatore), o andare con div ben etichettati che consentano approcci più flessibili allo stile.

E le migliori pratiche da diversi anni sono state quelle di evitare le tabelle quando non è necessario presentare dati tabulari.

Ai vecchi tempi, il motore di rendering della tabella " appariva " più lento quando si utilizzavano le percentuali per le larghezze delle colonne. Il motore doveva essenzialmente scaricare l'intero set di dati prima di iniziare a capire quanto tutto fosse grande per disegnarlo sullo schermo.

Il motore DIV era diverso. Quando il browser incontra un DIV, va avanti e lo posiziona e inizia a riempire il contenuto in linea. Ovviamente, i div potrebbero saltare al termine del caricamento dei dati. Ecco perché sono comparso tra virgolette. L'intervallo di tempo per il completamento di entrambi era lo stesso, tuttavia le tabelle non erano state disegnate fino alla fine, il che significava che l'utente non era sicuro se stesse caricando o meno per un secondo o due.

Ciò peggiorò man mano che i tavoli venivano annidati.

Esistevano quindi (ed esistono ancora) modi per rendere più veloce il rendering FAR FAR delle tabelle. Fondamentalmente dandogli un suggerimento che le dimensioni delle colonne non cambiano, quindi il browser inizia a visualizzare immediatamente i dati tabulari. In definitiva, ciò significa che le tabelle possono effettivamente essere visualizzate nella posizione corretta più velocemente dei div, dando loro l'aspetto di essere migliori.

Ma questa non è tutta la storia. Il resto è che la maggior parte degli sviluppatori semplicemente non si preoccupano di imparare il loro mestiere abbastanza bene da saperlo. Invece saltano su vari vagoni e vanno con qualsiasi codice da cui possono copiare / incollare. Ancora oggi trovo che pochissimi sviluppatori web conoscono la differenza da un doctype all'altro - e questa è la ragione numero uno per cui vari siti hanno ogni sorta di soluzioni alternative per coprire vari browser.

Quindi, +1 a te per aver posto la domanda.

Se riesco a ottenere un po 'di "meta" qui, questo mi fa venire in mente due problemi:

Uno: qualcuno propone una regola per qualche buona ragione, e le persone mancano completamente il punto seguendo la lettera tecnica della regola mentre ignorano lo spirito. Trovano un modo per realizzare tutte le cose cattive che la regola stava cercando di prevenire, pur seguendo tecnicamente la regola come formulata.

Due: qualcuno vede un problema e propone una regola per prevenirlo. Altri vedono il valore di questa regola. Quindi insistono sulla cieca devozione a questa regola senza riguardo al problema originale che avrebbe dovuto risolvere e / o indipendentemente dagli altri problemi che crea. Ho avuto molte conversazioni in cui qualcuno dice "Devi fare X perché questa è la regola", e poi chiedo "Ma perché dovremmo fare X?", E mi guardano con sconcerto ed esasperazione e dicono "Ma Te l'ho appena detto! Perché è la regola! " Rispondo, "Ma sembra causare più problemi di quanti ne risolva. Penso che faremmo meglio a fare Y." E poi la persona dice: "No, guarda, ti faccio vedere. Vedi, è proprio qui in questo libro. X è la regola."

In questo caso, abbiamo un problema: il tag table fa due cose: uno, controlla il layout di un documento. Due, trasmette l'idea che i dati racchiusi siano costituiti da righe e colonne di numeri o altri dati.

Tante persone hanno proposto la soluzione: non usare i tag di tabella per controllare il layout di cose che non sono "tabelle" logicamente. Usa CSS.

Ma c'è un problema con questa soluzione. Il tag table e i suoi tag secondari svolgono molte funzioni di layout molto utili che non sono facili da ottenere utilizzando i CSS e, quando possono essere raggiunti, il codice necessario per farlo è spesso ingombrante, difficile da leggere e difficile da mantenere. Perché dovremmo fare le cose in modo goffo e difficile quando c'è un modo semplice e pulito?

Personalmente, penso che sarebbe stato meglio dichiarare semplicemente "Il fatto che qualcosa sia all'interno di un tag di tabella non significa necessariamente che rappresenti righe e colonne di numeri". Questo non sarebbe stato un pronunciamento oltraggioso. Non ho mai sentito qualcuno dire che il tag "p" può essere usato solo per cose che sono in realtà paragrafi di frasi inglesi grammaticalmente corrette, costruite logicamente. Non ho mai sentito qualcuno dire che è sbagliato usare un tag "ul" per un elenco che, in effetti, arriva in un ordine logico, solo perché volevi proiettili e non numeri di sequenza. Eccetera.

Ci sono già tonnellate di grandi risposte qui. Ma volevo aggiungere che gli tableelementi hanno limiti di rendering che non esistono per gli divelementi. Prova a creare una tabella che esegua lo scorrimento virtuale (come: SlickGrid , DataTables e altri) e rimarrai profondamente deluso. Semplicemente non funziona. La maggior parte delle griglie Javascript (tutte?) Moderne usano divs perché il CSS consente un rendering molto più flessibile.

Ci sono anche altre limitazioni. La mia regola generale è che se vedrò l'intera tabella su una singola schermata, e non voglio alcun / molto rendering personalizzato per esso uso un tableelemento, altrimenti vado con div perché posso controllare molto i risultati , molto più facilmente.

HTML e CSS hanno sviluppato un certo grado di flessibilità, il che significa che anche elementi concettualmente di "blocco" come <div>(la forma più antica e generale di contenuto di blocchi di HTML) non devono essere visualizzati come blocchi:

div { display: inline; }

Come notate, <div>può essere riproposto per emulare <table>e i suoi compagni di viaggio. In realtà, la maggior parte dei tag può. Date le loro ruoli speciali, dubito che si potrebbe utilmente rimappare tag macro come <html>, <head>, <body>, e <script>, ma i tag "comuni", come <div>, <p>, <b>, <em>, <span>, e <pre>? In palio. Rendi i blocchi dei tag in linea, i blocchi in linea, i tag preformattati scorrono, quelli fissi fluttuano. Impazzisci, se vuoi!

È possibile . Potresti voler girare un filo su come dovremmo usare tutti "markup semantico" blah blah blah , o credere ai pitonisti che "Dovrebbe esserci un modo - e preferibilmente solo uno - ovvio per farlo." Eppure Tim Toady è un ragazzo intelligente e curioso. Con una mano libera, li esplorerà tutti. Ciò include l'utilizzo della flessibilità disponibile per effettuare sostituzioni. Alcuni sono saggi, altri saranno dimostrati diversamente. Ma prova, errore ed esperienza sono l'unico modo per scoprirlo. Quindi sono presenti le condizioni sufficienti per la sostituzione.

Non credo che sia troppo esagerato dire che è necessaria anche la sostituzione. Come minimo, è estremamente conveniente . Per molto tempo, HTML non ha avuto <menu>, <section>o <aside>elementi. Tuttavia, le pagine Web e le app ovunque hanno menu, sezioni e barre laterali. Come? Perché gli elementi della lista HTML ( <ul>, <ol>, e <li>) erano facilmente riproposto e alcuni usi ri-classificati come contenitori di menu e parti. <div>potrebbe sostituire <article>, <section>, <aside>, <figure>, e <summary>. HTML5 ha recuperato e ha aggiunto elementi su misura per alcuni casi d'uso precedentemente non indirizzati. È un ottimo aggiornamento e correzione per adattarsi all'uso comune e reale.

Anche così, rimangono molti modi di dire comuni che non hanno tag su misura o modelli semantici . Cose come pagine, note a piè di pagina, virgolette, flussi di commenti, avatar associati, "mi piace", sottotitoli e sottotitoli che io e molti altri usiamo ogni giorno. Che cosa dobbiamo fare? Cosa possiamo Riutilizza elementi "vicini ma inesatti" con classi e ID per sostenere e supportare il nostro lavoro per i prossimi cinque o dieci o comunque molti anni prima che HTML6 o HTML7 raggiungano. "Sì, è una X, in teoria, HTML / CSS, ma la codificheremo e lavoreremo con essa come Y" è incredibilmente conveniente. Indispensabile, davvero. Rende i contenuti Web flessibili e non fragili.

Andando ancora oltre, il "markup semantico" ha limiti irriducibili . Questo è vero per qualsiasi tipo di struttura rigorosa che puoi immaginare per i contenuti.

I formati standard non possono comprendere l'intera ricchezza di necessità, desiderio e varietà umana. Saranno sempre "dietro la curva" di ciò che la gente sta facendo ora . Come stanno innovando. Diamine, HTML5 è ancora dietro la curva su note a piè di pagina, sottotitoli e altre innovazioni di stampa del 17 ° secolo. Manca di funzionalità essenziali per molti operatori dell'informazione e creatori di contenuti. Quindi improvvisiamo.

Ancora più immutabile è che le informazioni non rispettano un insieme di regole. Certo, inizia come un tavolo. Ma forse vuoi solo il riassunto: dì il titolo di ogni riga, come un elenco. Forse occupa troppo spazio e ti piacerebbe come un elenco in linea salvaspazio. Forse hai dischi di cui vuoi solo il titolo, quindi se fai clic, vedrai i dettagli sottostanti. Oppure si desidera raggruppare e classificare gli elementi in un elenco o una tabella complessi. Oh, ora vuoi che venga trasposto e classificato in un modo diverso. O i valori tracciati come un grafico a barre. Queste sono attività quotidiane eseguite in app, fogli di calcolo e visualizzazione dei dati. Sono parte integrante del nostro panorama informativo e di ciò che vogliamo e dobbiamo fare sul web. Gli umani riorganizzano costantemente la forma e la presentazione dei nostri dati. Non è solo una cosa, o un formato / layout, o un concetto. È fungibile, con la semantica che dipende dalla circostanza e dalle scelte che gli utenti fanno in modo interattivo. Sì, contrassegna il testo come "sottolineato" (<em>), ma questa è solo una convenzione. Ho lavorato su documenti con almeno una mezza dozzina di diversi tipi di "enfasi". Abbiamo bisogno di essere in grado di personalizzare e rimappare che per differenti usi, diverse interpretazioni. Un tipo di enfasi HTML? Stranamente riduzionista. Limitare. Fragile. Lo stesso vale per <table>, <p>ecc

È bello avere tag / elementi che aiutano a organizzare l'intera comunità pensando a "cosa va dove". Ciò aiuta a stabilire convenzioni e modi di dire e ci rende collettivamente più efficienti. Ma la capacità di rimappare le cose, di ridisegnare e riutilizzare quelle strutture? Questo è parte integrante dell'inclusività del Web e del suo successo.

I casi d'uso contano. C'è una grande differenza tra layout / presentazione in una pagina di contenuto e in un'applicazione. Nei contenuti, la semantica è molto importante per la consapevolezza SEO e l'usabilità. In questi casi, l'uso delle tabelle per presentare i dati tabulari è in genere la cosa giusta da fare. Come altri hanno notato, i motori di ricerca ti penalizzeranno e potresti persino infrangere le leggi sull'usabilità se ti è richiesto dalla legge di conformarti alle linee guida dell'usabilità.

In un'applicazione Web, gli sviluppatori possono scegliere di creare viste completamente separate per scopi SEO e di usabilità. Il responsive design ha portato le persone a creare visualizzazioni in grado di gestire layout desktop e mobili e le div sono migliori delle tabelle in questi casi d'uso.

Prendi i siti di e-commerce, ad esempio. La visualizzazione di un elenco di prodotti in un risultato di ricerca o di ricerca mostra, in generale, un elenco di prodotti in formato tabulare, ma è possibile che tali viste vengano generate utilizzando div (che offrono opzioni di layout e stile più generiche e flessibili) anziché tabelle. Amazon ed eBay sono buoni esempi di questo approccio. Ispeziona un risultato di ricerca su entrambi i siti e vedrai una serie di div profondamente nidificati.