Perché non utilizzare le tabelle per il layout in HTML? [chiuso]

Sembra essere l' opinione generale che le tabelle non dovrebbero essere utilizzate per il layout in HTML.

Perché?

Non ho mai (o raramente onestamente) visto argomenti validi per questo. Le solite risposte sono:

• È bene separare il contenuto dal layout
  Ma questo è un argomento fallace; Cliche Pensando . Immagino sia vero che l'uso dell'elemento table per il layout abbia poco a che fare con i dati tabulari. E allora? Al mio capo importa? I miei utenti si preoccupano?
  
  Forse io o i miei colleghi sviluppatori che devono mantenere la cura di una pagina Web ... Un tavolo è meno gestibile? Penso che usare una tabella sia più facile che usare div e CSS.
  
  A proposito ... perché usare un div o un intervallo non è una buona separazione dei contenuti dal layout e da una tabella? Ottenere un buon layout con solo div spesso richiede molti div nidificati.

• Leggibilità del codice
  Penso che sia il contrario. Molte persone capiscono HTML, pochi capiscono CSS.

• È meglio che SEO non usi le tabelle
  Perché? Qualcuno può mostrare qualche prova che lo sia? O una dichiarazione di Google secondo cui le tabelle sono scoraggiate dal punto di vista SEO?

• Le tabelle sono più lente.
  È necessario inserire un elemento tbody aggiuntivo. Queste sono le noccioline per i moderni browser web. Mostrami alcuni parametri di riferimento in cui l'uso di una tabella rallenta significativamente una pagina.

• Una revisione del layout è più semplice senza tabelle, vedi css Zen Garden .
  La maggior parte dei siti Web che richiedono un aggiornamento richiedono anche nuovi contenuti (HTML). Gli scenari in cui una nuova versione di un sito Web richiede solo un nuovo file CSS non sono molto probabili. Zen Garden è un bel sito web, ma un po 'teorico. Per non parlare del suo uso improprio di CSS.

Sono davvero interessato a buoni argomenti per usare divs + CSS invece di tabelle.

Esaminerò i tuoi argomenti uno dopo l'altro e proverò a mostrare gli errori in essi contenuti.

È bene separare il contenuto dal layout Ma questo è un argomento fallace; Cliché Thinking.

Non è affatto fallace perché l'HTML è stato progettato intenzionalmente. L'uso improprio di un elemento potrebbe non essere del tutto fuori discussione (dopo tutto, nuovi idiomi si sono sviluppati anche in altre lingue), ma le possibili implicazioni negative devono essere controbilanciate. Inoltre, anche se non ci fossero argomenti contro l'abuso <table>dell'elemento oggi, potrebbe esserci domani a causa del modo in cui i fornitori di browser applicano un trattamento speciale all'elemento. Dopotutto, sanno che "gli <table>elementi sono solo per i dati tabulari" e potrebbero usare questo fatto per migliorare il motore di rendering, nel processo cambiando sottilmente il modo in cui si <table>comportano, e quindi rompendo i casi in cui era stato precedentemente utilizzato in modo improprio.

E allora? Al mio capo importa? I miei utenti si preoccupano?

Dipende. Il tuo capo ha i capelli a punta? Quindi potrebbe non interessarsene. Se è competente, allora se ne occuperà, perché lo faranno gli utenti .

Forse io o i miei colleghi sviluppatori che devono mantenere una cura della pagina Web ... Un tavolo è meno gestibile? Penso che usare una tabella sia più facile che usare divs e css.

La maggior parte degli sviluppatori web professionali sembra opporsi a te^{[ citazione necessaria ]} . Che le tabelle siano in effetti meno gestibili dovrebbe essere ovvio. L'uso delle tabelle per il layout significa che cambiare il layout aziendale significa in effetti cambiare ogni singola pagina. Questo può essere molto costoso. D'altra parte, l'uso giudizioso di HTML semanticamente significativo combinato con CSS potrebbe limitare tali modifiche al CSS e alle immagini utilizzate.

A proposito ... perché usare un div o un intervallo non è una buona separazione dei contenuti dal layout e da una tabella? Ottenere un buon layout con solo div spesso richiede molti div nidificati.

I <div>s profondamente nidificati sono un anti-pattern proprio come i layout di tabella. I bravi web designer non ne hanno bisogno molti. D'altra parte, anche tali div annidati in profondità non hanno molti problemi dei layout delle tabelle. In effetti, possono persino contribuire a una struttura semantica dividendo logicamente il contenuto in parti.

Leggibilità del codice Penso che sia il contrario. Molte persone capiscono html, poco capiscono css. È più semplice

"La maggior parte delle persone" non importa. I professionisti contano. Per i professionisti, i layout delle tabelle creano molti più problemi rispetto a HTML + CSS. È come dire che non dovrei usare GVim o Emacs perché il Blocco note è più semplice per la maggior parte delle persone. O che non dovrei usare LaTeX perché MS Word è più semplice per la maggior parte delle persone.

È meglio che SEO non usi le tabelle

Non so se questo è vero e non lo userei come argomento, ma sarebbe logico. I motori di ricerca cercano dati pertinenti . Sebbene i dati tabulari possano ovviamente essere pertinenti, raramente è ciò che gli utenti cercano. Gli utenti cercano i termini utilizzati nel titolo della pagina o in posizioni altrettanto importanti. Sarebbe pertanto logico escludere il contenuto tabulare dal filtraggio e quindi ridurre di molto il tempo di elaborazione (e i costi!).

Le tabelle sono più lente. È necessario inserire un elemento tbody aggiuntivo. Queste sono noccioline per i moderni browser web.

L'elemento aggiuntivo non ha nulla a che fare con le tabelle più lente. D'altra parte, l'algoritmo di layout per le tabelle è molto più difficile, il browser deve spesso attendere il caricamento dell'intero tavolo prima che possa iniziare a impaginare il contenuto. Inoltre, la memorizzazione nella cache del layout non funzionerà (i CSS possono essere facilmente memorizzati nella cache). Tutto questo è stato menzionato prima.

Mostrami alcuni parametri di riferimento in cui l'uso di una tabella rallenta significativamente una pagina.

Sfortunatamente, non ho dati di riferimento. Sarei interessato a me stesso perché è giusto che questa argomentazione manchi di un certo rigore scientifico.

La maggior parte dei siti Web che richiedono un aggiornamento richiedono anche nuovi contenuti (html). Gli scenari in cui una nuova versione di un sito Web richiede solo un nuovo file CSS non sono molto probabili.

Affatto. Ho lavorato su diversi casi in cui la modifica del design è stata semplificata da una separazione tra contenuto e design. Spesso è ancora necessario cambiare del codice HTML, ma le modifiche saranno sempre molto più limitate. Inoltre, a volte le modifiche al design devono essere apportate in modo dinamico. Prendi in considerazione i motori di template come quello utilizzato dal sistema di blog di WordPress. I layout delle tabelle ucciderebbero letteralmente questo sistema. Ho lavorato su un caso simile per un software commerciale. Essere in grado di cambiare il design senza cambiare il codice HTML era uno dei requisiti aziendali.

Un'altra cosa. Il layout della tabella rende molto più difficile l'analisi automatizzata dei siti Web (screen scraping). Questo potrebbe sembrare banale perché, dopo tutto, chi lo fa? Sono stato sorpreso me stesso. Lo scraping dello schermo può essere di grande aiuto se il servizio in questione non offre un'alternativa al servizio Web per accedere ai suoi dati. Sto lavorando in bioinformatica dove questa è una triste realtà. Le moderne tecniche web e i servizi Web non hanno raggiunto la maggior parte degli sviluppatori e spesso lo scraping dello schermo è l'unico modo per automatizzare il processo di acquisizione dei dati. Non sorprende che molti biologi svolgano ancora tali compiti manualmente. Per migliaia di set di dati.

Ecco la risposta del mio programmatore da un thread simliar

Semantica 101

Per prima cosa dai un'occhiata a questo codice e pensa a cosa non va qui ...

class car {
    int wheels = 4;
    string engine;
}

car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

Il problema, ovviamente, è che una bici non è un'auto. La classe di auto è una classe inappropriata per l'istanza di bici. Il codice è privo di errori, ma è semanticamente errato. Riflette male sul programmatore.

Semantica 102

Ora applica questo al markup del documento. Se il documento deve presentare dati tabulari, il tag appropriato sarebbe <table>. Se si posiziona la navigazione in una tabella, tuttavia, si sta abusando dello scopo previsto <table>dell'elemento. Nel secondo caso, non stai presentando dati tabulari: stai (mis) usando l' <table>elemento per raggiungere un obiettivo di presentazione.

Conclusione

I visitatori noteranno? No. Al tuo capo importa? Può essere. A volte tagliamo gli angoli come programmatori? Sicuro. Ma dovremmo? No. A chi giova se usi il markup semantico? Tu e la tua reputazione professionale. Ora vai e fai la cosa giusta.

Risposta ovvia: vedi CSS Zen Garden . Se mi dici che puoi facilmente fare lo stesso con un layout basato su tabella (ricorda: l'HTML non sta cambiando) allora usa sicuramente le tabelle per il layout.

Altre due cose importanti sono l'accessibilità e il SEO.

Entrambi si preoccupano per quale ordine vengono presentate le informazioni. Non è possibile presentare facilmente la navigazione nella parte superiore della pagina se il layout basato su tabella lo inserisce nella terza cella della seconda riga della seconda tabella nidificata nella pagina.

Quindi le tue risposte sono manutenibilità, accessibilità e SEO.

Non essere pigro. Fai le cose nel modo giusto e corretto anche se sono un po 'più difficili da imparare.

Vedi questa domanda duplicata.

Un elemento che stai dimenticando è l'accessibilità. I layout basati su tabelle non si traducono altrettanto bene se, ad esempio, è necessario utilizzare uno screen reader. E se lavori per il governo, potrebbe essere necessario supportare browser accessibili come gli screen reader .

Penso anche che tu abbia sottovalutato l'impatto di alcune delle cose che hai menzionato nella domanda. Ad esempio, se sei sia il designer che il programmatore, potresti non apprezzare appieno quanto separa la presentazione dal contenuto. Ma una volta entrati in un negozio in cui si trovano due ruoli distinti, i vantaggi iniziano a diventare più chiari.

Se sai cosa stai facendo e disponi di buoni strumenti, i CSS hanno davvero vantaggi significativi rispetto alle tabelle per il layout. E mentre ogni elemento da solo potrebbe non giustificare l'abbandono delle tabelle, nel complesso vale la pena.

Sfortunatamente, CSS Zen Garden non può più essere utilizzato come esempio di un buon design HTML / CSS. Praticamente tutti i loro progetti recenti utilizzano la grafica per l'intestazione della sezione. Questi file grafici sono specificati nel CSS.

Quindi, un sito web il cui scopo è mostrare il vantaggio di mantenere il design al di fuori del contenuto, ora commette regolarmente il SIN INSPEAKABLE di mettere il contenuto in design. (Se l'intestazione della sezione nel file HTML dovesse cambiare, l'intestazione della sezione visualizzata non cambierebbe).

Il che dimostra solo che anche coloro che sostengono la rigida religione DIV e CSS, non possono seguire le proprie regole. Puoi usarlo come linea guida nel modo in cui li segui da vicino.

Questo non è assolutamente l'argomento definitivo, ma con CSS puoi prendere lo stesso markup e cambiare il layout a seconda del mezzo, il che è un bel vantaggio. Per una pagina di stampa puoi sopprimere tranquillamente la navigazione senza dover creare una pagina adatta alla stampante, ad esempio.

Una tabella per il layout non sarebbe così male. Ma non puoi ottenere il layout di cui hai bisogno con un solo tavolo per la maggior parte del tempo. Molto presto hai 2 o tre tabelle nidificate. Questo diventa molto ingombrante.

• È MOLTO più difficile da leggere. Non è un'opinione. Ci sono solo altri tag nidificati senza segni identificativi su di essi.

• Separare i contenuti dalla presentazione è una buona cosa perché ti consente di concentrarti su ciò che stai facendo. La miscelazione dei due porta a pagine gonfie che sono difficili da leggere.

• CSS for styles consente al tuo browser di memorizzare nella cache i file e le richieste successive sono molto più veloci. Questo è ENORME.

• Le tabelle ti bloccano in un design. Certo, non tutti hanno bisogno della flessibilità di CSS Zen Garden, ma non ho mai lavorato su un sito in cui non avevo bisogno di cambiare un po 'il design qua e là. È molto più facile con i CSS.

• I tavoli sono difficili da modellare. Non hai molta flessibilità con loro (cioè devi ancora aggiungere attributi HTML per controllare completamente gli stili di una tabella)

Non uso tabelle per dati non tabulari da 4 anni. Non ho guardato indietro.

Vorrei davvero suggerire di leggere CSS Mastery di Andy Budd. È fantastico.

Immagine su ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg

È bene separare il contenuto dal layout
Ma questo è un argomento fallace; Cliche Pensando

È un argomento fallace perché le tabelle HTML sono layout! Il contenuto è i dati nella tabella, la presentazione è la tabella stessa. Questo è il motivo per cui a volte separare CSS da HTML può essere molto difficile. Non stai separando il contenuto dalla presentazione, stai separando la presentazione dalla presentazione! Un mucchio di div nidificati non è diverso da un tavolo: è solo un diverso set di tag.

L'altro problema con la separazione dell'HTML dal CSS è che hanno bisogno di una conoscenza intima l'uno dell'altro - non puoi davvero separarli completamente. Il layout dei tag nell'HTML è strettamente associato al file CSS, qualunque cosa tu faccia.

Penso che le tabelle contro i div dipendano dalle esigenze della tua applicazione.

Nell'applicazione che sviluppiamo al lavoro, avevamo bisogno di un layout di pagina in cui i pezzi si adattassero dinamicamente al loro contenuto. Ho trascorso giorni cercando di far funzionare questo cross-browser con CSS e DIV ed è stato un vero incubo. Siamo passati ai tavoli e tutto ha funzionato .

Tuttavia, abbiamo un pubblico molto chiuso per il nostro prodotto (vendiamo un componente hardware con un'interfaccia Web) e i problemi di accessibilità non ci preoccupano. Non so perché gli screen reader non siano in grado di gestire bene i tavoli, ma immagino che sia così che devono essere gli sviluppatori.

CSS / DIV - sono solo lavori per i ragazzi del design, no? Le centinaia di ore che ho trascorso nel debug di problemi DIV / CSS, cercando in Internet per far funzionare una parte del markup con un browser oscuro, mi fa impazzire. Fai un piccolo cambiamento e l'intero layout va terribilmente storto - dove su questo c'è la logica. Trascorrere ore spostando qualcosa di 3 pixel in questo modo, quindi qualcos'altro di 2 pixel l'altro per farli allineare tutti. Questo mi sembra semplicemente sbagliato in qualche modo. Solo perché sei un purista e qualcosa non è "la cosa giusta da fare" non significa che dovresti usarla all'ennesima potenza e in ogni circostanza, specialmente se ti rende la vita 1000 volte più facile.

Quindi alla fine ho deciso, puramente per motivi commerciali, anche se mi tengo al minimo, se prevedo 20 ore di lavoro per ottenere un DIV posizionato correttamente, rimarrò su un tavolo. È sbagliato, sconvolge i puristi, ma nella maggior parte dei casi costa meno tempo ed è più economico da gestire. Posso quindi concentrarmi su come far funzionare l'applicazione come desidera il cliente, piuttosto che soddisfare i puristi. Dopotutto pagano le bollette e la mia argomentazione a un manager che impone l'uso di CSS / DIV - vorrei solo sottolineare che anche i clienti pagano il suo stipendio!

L'unico motivo per cui si verificano tutti questi argomenti CSS / DIV è a causa della mancanza dei CSS in primo luogo e perché i browser non sono compatibili tra loro e se lo fossero, metà dei web designer nel mondo sarebbe senza lavoro .

Quando progetti un modulo di Windows non provi a spostare i controlli dopo averli disposti, quindi penso che sia strano per me il motivo per cui vorresti farlo con un modulo web. Semplicemente non riesco a capire questa logica. Ottieni il layout giusto per iniziare e qual è il problema. Penso che sia perché ai progettisti piace flirtare con la creatività, mentre gli sviluppatori di applicazioni sono più interessati a far funzionare effettivamente l'applicazione, creare oggetti di business, implementare le regole di business, capire come i bit di dati dei clienti si relazionano tra loro, garantendo che la cosa soddisfi i clienti requisiti - sai - come le cose del mondo reale.

Non fraintendetemi, entrambi gli argomenti sono validi, ma per favore non criticare gli sviluppatori per aver scelto un approccio più semplice e logico alla progettazione dei moduli. Spesso abbiamo cose più importanti di cui preoccuparci rispetto alla semantica corretta dell'uso di una tabella su un div.

Caso in questione - in base a questa discussione ho convertito alcuni tds e trs esistenti in div. 45 minuti a scherzare cercando di mettere tutto in fila uno accanto all'altro e ho rinunciato. TD tornerà dopo 10 secondi - funziona - subito - su tutti i browser, niente altro da fare. Per favore, cerca di farmi capire - quale possibile giustificazione hai per volermi fare in un altro modo!

Il layout dovrebbe essere semplice. Il fatto che ci siano articoli scritti su come ottenere un layout dinamico a tre colonne con intestazione e piè di pagina nei CSS dimostra che si tratta di un sistema di layout scadente. Ovviamente puoi farlo funzionare, ma ci sono letteralmente centinaia di articoli online su come farlo. Non ci sono praticamente articoli simili per un layout simile con tabelle perché è palesemente ovvio. Indipendentemente da ciò che dici contro le tabelle e in favore dei CSS, questo fatto annulla tutto: un layout di base a tre colonne nel CSS è spesso chiamato "Il Santo Graal".

Se ciò non ti fa dire "WTF", allora devi davvero eliminare il kool-aid.

Adoro i CSS. Offre incredibili opzioni di stile e alcuni fantastici strumenti di posizionamento, ma come motore di layout è carente. È necessario un qualche tipo di sistema di posizionamento dinamico della griglia. Un modo semplice per allineare le scatole su più assi senza conoscerne prima le dimensioni. Non me ne frega niente se lo chiami <table> o <gridlayout> o altro, ma questa è una funzionalità di layout di base che manca ai CSS.

Il problema più grande è che non ammettendo che mancano funzionalità, gli zeloti CSS hanno trattenuto i CSS da tutto ciò che potrebbe essere. Sarei perfettamente felice di smettere di usare le tabelle se CSS fornisse un posizionamento della griglia multiasse decente come praticamente qualsiasi altro motore di layout al mondo. (Ti rendi conto che questo problema è già stato risolto molte volte in molte lingue da tutti tranne il W3C, giusto? E nessun altro ha negato che tale funzionalità fosse utile.)

Sospiro. Abbastanza sfiato. Vai avanti e riponi la testa nella sabbia.

In base alla conformità 508 (per i lettori di schermo per l'istruzione visiva), le tabelle dovrebbero essere utilizzate solo per contenere i dati e non per il layout in quanto causano il panico dei lettori di schermo. O almeno così mi è stato detto.

Se assegni nomi a ciascuno dei div, puoi scansionarli tutti insieme anche tramite CSS. Sono solo un po 'più di dolore per sedersi nel modo in cui ne hai bisogno.

Ecco una sezione di HTML da un recente progetto:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <div id="header">
        <h1><!-- Page title --></h1>
        <ol id="navigation">
            <!-- Navigation items -->
        </ol>
        <div class="clearfix"></div>
    </div>
    <div id="sidebar">
        <!-- Sidebar content -->
    </div>
    <!-- Page content -->
    <p id="footer"><!-- Footer content --></p>
</body>
</html>

Ed ecco lo stesso codice di un layout basato su tabella.

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
    <title>{DYNAMIC(TITLE)}</title>
    <meta http-equiv="content-type" content="text/html;charset=utf-8" />
    <meta http-equiv="Content-Style-Type" content="text/css" />
    <link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
    <table cellspacing="0">
        <tr>
            <td><!-- Page Title --></td>
            <td>
                <table>
                    <tr>
                        <td>Navitem</td>
                        <td>Navitem</td>
                    </tr>
                </table>
            </td>
        </tr>
    </table>

    <table>
        <tr>
            <td><!-- Page content --></td>
            <td><!-- Sidebar content --></td>
        </tr>
        <tr>
            <td colspan="2">Footer</td>
        </tr>
    </table>
</body>
</html>

L'unica pulizia che vedo in quel layout basato su tabella è il fatto che sono troppo zelante con il mio rientro. Sono sicuro che la sezione del contenuto avrebbe altre due tabelle incorporate.

Un'altra cosa a cui pensare: dimensioni dei file . Ho scoperto che i layout basati su tabella hanno in genere il doppio delle loro controparti CSS. Sulla nostra banda larga ad alta velocità che non è un grosso problema, ma è su quelli con modem dial-up.

Vorrei aggiungere che i layout basati su div sono più facili da mantenere, evolvere e refactor. Solo alcune modifiche al CSS per riordinare gli elementi e il gioco è fatto. Dalla mia esperienza, riprogettare un layout che utilizza le tabelle è un incubo (più se ci sono tabelle nidificate).

Il tuo codice ha anche un significato da un punto di vista semantico .

Nessun argomento a favore dei DIV mi è favorevole.

Direi: se la scarpa si adatta, indossala.

Vale la pena notare che è difficile, se non impossibile, trovare un buon metodo DIV + CSS per il rendering dei contenuti in due o tre colonne, che è coerente su tutti i browser e sembra ancora come volevo.

Questo suggerisce un po 'di equilibrio verso i tavoli nella maggior parte dei miei layout, e nonostante ciò mi sento in colpa per usarli (non so perché, la gente dice solo che è male, quindi provo ad ascoltarli), alla fine, la visione pragmatica è che è solo più facile e veloce per me usare TABELLE. Non mi pagano a ore, quindi i tavoli sono più economici per me.

I layout CSS sono generalmente molto migliori per l'accessibilità, a condizione che il contenuto abbia un ordine naturale e abbia senso senza un foglio di stile. E non sono solo gli screen reader ad avere problemi con i layout basati su tabelle: rendono anche molto più difficile per i browser mobili visualizzare correttamente una pagina.

Inoltre, con un layout basato su div puoi facilmente fare cose interessanti con un foglio di stile di stampa come escludere intestazioni, piè di pagina e navigazione dalle pagine stampate - penso che sarebbe impossibile, o almeno molto più difficile, farlo con un layout basato su tabella.

Se dubiti che la separazione dei contenuti dal layout sia più semplice con i div che con le tabelle, dai un'occhiata al codice HTML basato su div su CSS Zen Garden , vedi come cambiare i fogli di stile può cambiare drasticamente il layout e pensare se puoi ottenere la stessa varietà di layout se l'HTML fosse basato su tabella ... Se stai eseguendo un layout basato su tabella, è improbabile che tu stia usando CSS per controllare tutta la spaziatura e il riempimento nelle celle (se lo fossi, tu quasi certamente troveremo più facile usare div galleggianti ecc. in primo luogo). Senza usare CSS per controllare tutto ciò, e dato che le tabelle specificano l'ordine delle cose da sinistra a destra e dall'alto verso il basso delle cose nell'HTML, le tabelle tendono a significare che il layout diventa molto fisso nell'HTML.

Realisticamente penso che sia molto difficile cambiare completamente il layout di un design basato su div e CSS senza cambiare un po 'i div. Tuttavia, con un layout basato su div e CSS è molto più facile modificare cose come la spaziatura tra i vari blocchi e le loro dimensioni relative.

Il fatto che si tratti di una domanda fortemente dibattuta è una testimonianza del fallimento del W3C nell'anticipare la diversità dei progetti di layout che si tenterebbero. Usare divs + css per un layout semanticamente amichevole è un ottimo concetto, ma i dettagli dell'implementazione sono così imperfetti da limitare la libertà creativa.

Ho tentato di passare da uno dei siti della nostra azienda da tavoli a div, ed è stato un tale mal di testa che ho completamente eliminato le ore di lavoro che ci avevo riversato e sono tornato ai tavoli. Cercare di lottare con i miei div per ottenere il controllo dell'allineamento verticale mi ha maledetto con importanti problemi psicologici che non scuoterò mai finché questo dibattito si scatenerà.

Il fatto che le persone debbano spesso trovare soluzioni complesse e brutte per raggiungere semplici obiettivi di progettazione (come l'allineamento verticale) suggerisce fortemente che le regole non sono abbastanza flessibili. Se le specifiche SONO sufficienti, perché i siti di alto profilo (come SO) trovano necessario piegare le regole usando tabelle e altre soluzioni alternative?

Immagino sia vero che l'uso dell'elemento table per il layout abbia poco a che fare con i dati tabulari. E allora? Al mio capo importa? I miei utenti si preoccupano?

Google e altri sistemi automatizzati fanno cura, e sono altrettanto importanti in molte situazioni. Il codice semantico è più semplice per un sistema non intelligente da analizzare ed elaborare.

Avendo dovuto lavorare con un sito Web che comprendeva 6 livelli di tabelle nidificate generate da alcune applicazioni e aver generato HTML non valido, era in effetti un lavoro di 3 ore per rettificarlo rompendo per una piccola modifica.

Questo è ovviamente il caso limite, ma il design basato su tabella non è realizzabile. Se si utilizza CSS, si separa lo stile in modo che durante la correzione dell'HTML si abbia meno di cui preoccuparsi di rompere.

Inoltre, prova questo con JavaScript. Sposta una singola cella di tabella da una posizione a un'altra in un'altra tabella. Piuttosto complicato esibirsi dove div / span funzionerebbe semplicemente copia-incolla-saggio.

"Mi interessa il mio capo"

Se fossi il tuo capo. Ti importerebbe. ;) Se apprezzi la tua vita.

Flessibilità del layout
Immagina di creare una pagina con un gran numero di miniature.
DIV :
se metti ogni miniatura in un DIV, fluttuando a sinistra, forse 10 di loro si adattano su una riga. Rendi la finestra più stretta e BAM: sono 6 di fila o 2 o comunque adatti.
TABELLA:
Devi dire esplicitamente quante celle ci sono in una riga. Se la finestra è troppo stretta, l'utente deve scorrere in orizzontale.

Manutenibilità
Stessa situazione di cui sopra. Ora vuoi aggiungere tre miniature alla terza riga.
DIV:
aggiungili. Il layout si adatterà automaticamente.
TABELLA: incolla le nuove celle nella terza riga. Oops! Ora ci sono troppi articoli lì. Tagliare alcuni da quella fila e metterli sulla quarta fila. Ora ci sono troppi articoli lì. Tagliarne alcuni da quella riga ... (ecc.)
( Naturalmente, se stai generando le righe e le celle con script sul lato server, questo probabilmente non sarà un problema. )

Penso che quella barca abbia navigato. Se osservi la direzione presa dall'industria noterai che CSS e Open Standard sono i vincitori di quella discussione. Che a sua volta significa per la maggior parte del lavoro html, ad eccezione dei moduli, i progettisti useranno div anziché tabelle. Faccio fatica perché non sono un guru CSS, ma è così.

Inoltre, non dimenticare che le tabelle non vengono visualizzate correttamente sui browser mobili. Certo, l'iPhone ha un browser kick-ass ma tutti non hanno un iPhone. Il rendering delle tabelle può essere una nocciolina per i browser moderni, ma è un mucchio di angurie per i browser mobili.

Ho scoperto personalmente che molte persone usano troppi <div>tag, ma con moderazione può essere estremamente pulito e di facile lettura. Lei dice che le persone hanno difficoltà a leggere CSS rispetto alle tabelle; in termini di "codice" forse vero; ma in termini di lettura dei contenuti (view> source) è molto più facile capire la struttura con i fogli di stile che con le tabelle.

Sembra che tu sia abituato ai tavoli e basta. Mettere il layout in una tabella ti limita solo per quel layout. Con CSS puoi spostare i bit, dare un'occhiata a http://csszengarden.com/ E no, il layout non richiede normalmente molti div nidificati.

Senza tabelle per il layout e la semantica corretta, HTML è molto più pulito, quindi più facile da leggere. Perché qualcuno che non capisce i CSS dovrebbe provare a leggerlo? E se qualcuno si considera sviluppatore web, allora la buona conoscenza dei CSS è un must.

I vantaggi SEO derivano dalla possibilità di avere contenuti più importanti nella parte superiore della pagina e di avere un migliore rapporto contenuto / markup.

http://www.hotdesign.com/seybold/

• Conformità 508: la capacità di uno screen reader di dare un senso al tuo markup.
• In attesa di rendering: le tabelle non vengono visualizzate nel browser fino a quando non arriva alla fine </table>dell'elemento.

L'idea generale del markup semantico è la separazione del markup e della presentazione, che include il layout.

I Div non stanno sostituendo le tabelle, hanno il loro uso nel separare il contenuto in blocchi di contenuto correlato (,). Quando non hai le competenze e fai affidamento sulle tabelle, spesso dovrai separare il contenuto in celle per ottenere il layout desiderato, ma non dovrai toccare il markup per ottenere la presentazione quando usi il markup semantico. Questo è molto importante quando viene generato il markup anziché pagine statiche.

Gli sviluppatori devono smettere di fornire un markup che implichi un layout in modo che quelli di noi che hanno le competenze per presentare i contenuti possano andare avanti con il nostro lavoro e gli sviluppatori non devono tornare al loro codice per apportare modifiche quando è necessario cambiare la presentazione.

Non si tratta in realtà se "i div sono migliori delle tabelle per il layout". Qualcuno che capisce i CSS può duplicare qualsiasi progetto usando 'tabelle di layout' in modo abbastanza semplice. La vera vittoria sta usando gli elementi HTML per quello per cui sono lì. La ragione per cui non dovresti usare le tabelle per i dati non tabulari è la stessa ragione per cui non memorizzi numeri interi come stringhe di caratteri: la tecnologia funziona molto più facilmente quando la usi per lo scopo per il quale è stata progettata. Se fosse mai stato necessario utilizzare le tabelle per il layout (a causa delle carenze del browser nei primi anni '90), certamente non lo è ora.

Gli strumenti che utilizzano layout di tabella possono diventare straordinariamente pesanti a causa della quantità di codice richiesta per creare il layout. Il portale Netweaver di SAP utilizza per impostazione predefinita TABELLA per impaginare le loro pagine.

Il portale di produzione SAP al mio attuale concerto ha una home page il cui HTML pesa oltre 60 KB e arriva a sette tabelle di profondità, tre volte all'interno della pagina. Aggiungi in Javascript, l'uso improprio di 16 iframe con problemi di tabella simili all'interno di essi, CSS eccessivamente pesanti ecc. E la pagina pesa oltre 5 MB.

Vale la pena dedicare del tempo per ridurre il peso della pagina in modo da poter utilizzare la larghezza di banda per svolgere attività coinvolgenti con gli utenti.

Vale la pena capire CSS e div in modo che la colonna del contenuto centrale venga caricata e visualizzata prima della barra laterale in un layout di pagina. Ma se stai lottando per usare div galleggianti per allineare verticalmente un logo con del testo di sponsorizzazione, usa la tabella e vai avanti con la vita. La religione del giardino zen non dà molto da fare.

L'idea di separare il contenuto dalla presentazione è di partizionare l'applicazione in modo che diversi tipi di lavoro influiscano su diversi blocchi di codice. In realtà si tratta di gestione delle modifiche. Ma gli standard di codifica possono esaminare lo stato attuale del codice solo in modo superficiale.

Il registro delle modifiche per un'applicazione che dipende dagli standard di codifica per "separare il contenuto dalla presentazione" mostrerà un modello di modifiche parallele tra silos verticali. Se una modifica al "contenuto" è sempre accompagnata da una modifica alla "presentazione", quanto ha successo il partizionamento?

Se vuoi veramente partizionare il tuo codice in modo produttivo, usa Subversion ed esamina i log delle modifiche. Quindi utilizzare le tecniche di codifica più semplici - div, tabelle, JavaScript, include, funzioni, oggetti, continuazioni, qualunque cosa - per strutturare l'applicazione in modo che le modifiche si adattino in modo semplice e comodo.

Perché è DIFFICILE mantenere un sito che utilizza tabelle e impiega molto più tempo a programmare. Se hai paura dei div galleggianti, segui un corso. Non sono difficili da capire e sono circa 100 volte più efficienti e un milione di volte meno un dolore nel culo (a meno che tu non li capisca - ma ehi, benvenuto nel mondo dei computer).

Chiunque stia pensando di fare il proprio layout con un tavolo meglio non aspettarsi che lo mantenga. È il modo più arretrato per rendere un sito Web. Grazie a dio abbiamo un'alternativa molto migliore ora. Non ci tornerò MAI più.

È spaventoso che alcune persone potrebbero non essere consapevoli del tempo e dei benefici energetici derivanti dalla creazione di un sito utilizzando strumenti moderni.

Le tabelle non sono generalmente più facili o più gestibili rispetto ai CSS. Tuttavia, ci sono alcuni problemi di layout specifici in cui le tabelle sono davvero la soluzione più semplice e flessibile.

Il CSS è chiaramente preferibile nei casi in cui il markup della presentazione e il CSS supportano lo stesso tipo di design, nessuno nella loro mente corretta sosterrebbe che font-tags sono meglio di specificare la tipografia in CSS, dal momento che CSS ti dà lo stesso potere di font-tags, ma in un modo molto più pulito.

Il problema con le tabelle, tuttavia, è fondamentalmente che il modello di layout di tabella in CSS non è supportato in Microsoft Internet Explorer. Tabelle e CSS sono quindi non equivale al potere. La parte mancante è il comportamento a griglia delle tabelle, in cui i bordi delle celle si allineano sia verticalmente che orizzontalmente, mentre le celle si espandono ancora per contenere il loro contenuto. Questo comportamento non è facile da ottenere nel CSS puro senza codificare alcune dimensioni, il che rende il design rigido e fragile (fintanto che dobbiamo supportare Internet Explorer - in altri browser questo è facilmente raggiungibile utilizzando display:table-cell).

Quindi non è davvero una questione se le tabelle o CSS sono preferibili, ma si tratta di riconoscere i casi specifici in cui l'uso delle tabelle può rendere il layout più flessibile.

Il motivo più importante per non utilizzare le tabelle è l'accessibilità. Le Linee guida per l'accessibilità dei contenuti Web http://www.w3.org/TR/WCAG10/ consigliano di utilizzare le tabelle per il layout. Se sei preoccupato per l'accessibilità (e in alcuni casi potresti essere legalmente obbligato a farlo), dovresti usare i CSS anche se le tabelle sono più semplici. Nota che puoi sempre creare lo stesso layout con CSS come con le tabelle, potrebbe richiedere solo più lavoro.

Sono stato sorpreso di vedere alcuni problemi non già coperti, quindi ecco i miei 2 centesimi, oltre a tutti i punti molto validi fatti in precedenza:

.1. CSS e SEO:

a) I CSS avevano un impatto molto significativo sul SEO consentendo di posizionare i contenuti nella pagina dove vuoi. Alcuni anni fa, i motori di ricerca davano un'importanza significativa ai fattori "on-page". Qualcosa nella parte superiore della pagina è stato ritenuto più pertinente per la pagina rispetto a qualcosa che si trova nella parte inferiore. "Inizio della pagina" per un ragno significava "all'inizio del codice". Utilizzando CSS, è possibile organizzare il contenuto ricco di parole chiave all'inizio del codice e posizionarlo comunque ovunque nella pagina. Ciò è ancora in qualche modo rilevante, ma i fattori sulla pagina sono sempre meno importanti per il posizionamento della pagina.

b) Quando il layout viene spostato su CSS, la pagina HTML è più leggera e quindi carica più velocemente per uno spider dei motori di ricerca. (i ragni non si preoccupano di scaricare file CSS esterni). Il caricamento rapido delle pagine è una considerazione importante per il posizionamento di numerosi motori di ricerca, incluso Google

c) Il lavoro SEO richiede spesso test e modifiche, il che è molto più conveniente con un layout basato su CSS

.2. Contenuto generato:

Una tabella è notevolmente più semplice da generare a livello di programmazione rispetto al layout CSS equivalente.

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

Generare una tabella è semplice e sicuro. È autonomo e si integra bene in qualsiasi modello. Fare lo stesso con i CSS è considerevolmente più difficile e potrebbe non essere affatto utile: è difficile modificare il foglio di stile CSS sul volo e aggiungere lo stile in linea non è diverso dall'uso di una tabella (il contenuto non è separato dal layout).

Inoltre, quando viene generata una tabella, il contenuto (in variabili) è già separato dal layout (in codice), facilitando la modifica.

Questo è uno dei motivi per cui alcuni siti Web molto ben progettati (SO per esempio) usano ancora layout di tabella.

Naturalmente, se i risultati devono essere attuati tramite JavaScript, i div valgono il problema.

.3. Test rapido di conversione

Quando si capisce cosa funziona per un pubblico specifico, è utile essere in grado di modificare il layout in vari modi per capire cosa ottiene i risultati migliori. Un layout basato su CSS semplifica notevolmente le cose

.4. Soluzioni diverse per problemi diversi

Le tabelle di layout vengono generalmente ignorate perché "tutti conoscono div e CSS" sono la strada da percorrere.

Tuttavia, resta il fatto che le tabelle sono più veloci da creare, più facili da comprendere e più robuste rispetto alla maggior parte dei layout CSS. (Sì, CSS può essere altrettanto affidabile, ma una rapida occhiata in rete su diversi browser e risoluzioni dello schermo mostra che non è spesso il caso)

Ci sono molti aspetti negativi sui tavoli, tra cui manutenzione, mancanza di flessibilità ... ma non gettiamo il bambino con l'acqua della vasca. Ci sono molti usi professionali per una soluzione che sia veloce e affidabile.

Qualche tempo fa, ho dovuto riscrivere un layout CSS semplice e pulito utilizzando le tabelle perché una parte significativa degli utenti avrebbe utilizzato una versione precedente di IE con un supporto davvero scarso per i CSS

Io, per esempio, sono stufo della reazione istintiva "Oh no! Tabelle per il layout!"

Per quanto riguarda la folla "non era destinata a tale scopo e quindi non dovresti usarla in questo modo", non è forse quell'ipocrisia? Cosa ne pensi di tutti i trucchi CSS che devi usare per far funzionare la cosa maledetta nella maggior parte dei browser? Erano pensati per quello scopo?