it-swarm.it

Perché non usare le tabelle per il layout in HTML?

Sembra essere il parere generale che le tabelle non dovrebbero essere usate per il layout in HTML.

Perché?

Non ho mai (o raramente onesto) visto buoni argomenti per questo. Le risposte abituali sono:

  • È buono per separare il contenuto dal layout
    Ma questa è una discussione fallace; Fai clic sul Pensiero . Immagino sia vero che usare l'elemento table per il layout ha poco a che fare con i dati tabulari. E allora? Il mio capo si preoccupa? I miei utenti si preoccupano?

    Forse io oi miei colleghi sviluppatori che devono mantenere una cura della pagina Web ... È un tavolo meno manutenibile? Penso che usare una tabella sia più facile che usare div e CSS.

    A proposito ... perché usare un div o una buona separazione del contenuto dal layout e non da una tabella? Ottenere un buon layout con solo div spesso richiede un sacco di div nidificate.

  • Leggibilità del codice
    Penso che sia il contrario. La maggior parte delle persone capisce l'HTML, pochi capiscono i CSS.

  • È meglio per SEO non usare le tabelle
    Perché? Qualcuno può mostrare qualche prova che sia? O una dichiarazione di Google che i tavoli sono scoraggiati da una prospettiva SEO?

  • Le tabelle sono più lente.
    È necessario inserire un elemento tbody extra. Questo è noccioline per i moderni browser web. Mostrami alcuni benchmark in cui l'uso di una tabella rallenta in modo significativo una pagina.

  • Una revisione del layout è più semplice senza tabelle, vedere css Zen Garden .
    La maggior parte dei siti Web che richiedono un aggiornamento necessitano anche di nuovi contenuti (HTML). Scenari in cui una nuova versione di un sito Web ha solo bisogno di un nuovo file CSS non è molto probabile. Zen Garden è un sito Web di Nizza, ma un po 'teorico. Per non parlare del suo uso improprio dei CSS.

Sono molto interessato ai buoni argomenti per usare divs + CSS invece delle tabelle.

665
Benno Richters

Ho intenzione di passare attraverso i tuoi argomenti uno dopo l'altro e cercare di mostrare gli errori in loro.

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

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

E allora? Il mio capo si preoccupa? I miei utenti si preoccupano?

Dipende. Il tuo capo è a punta di capelli? Quindi potrebbe non interessarsene. Se è competente, a lei interesserà, perché gli utenti faranno .

Forse io oi miei colleghi sviluppatori che devono mantenere una cura della pagina web ... È un tavolo meno manutenibile? Penso che usare una tabella sia più facile che usare div e css.

La maggior parte degli sviluppatori web professionisti sembra opporsi a te[ citazione necessaria ]. Quelle tabelle are in effetti meno mantenibili dovrebbero essere ovvie. Usare le tabelle per il layout significa che cambiare il layout aziendale significherà infatti 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 una buona separazione del contenuto dal layout e una tabella no? Ottenere un buon layout con solo div spesso richiede un sacco di div nidificate.

<div>s profondamente nidificati sono un anti-pattern proprio come i layout di tabella. I buoni web designer non hanno bisogno di molti di loro. D'altra parte, anche i div deep nidificati non hanno molti problemi di layout di tabella. In effetti, possono persino contribuire a una struttura semantica dividendo logicamente il contenuto in parti.

Leggibilità del codice Penso che sia il contrario. La maggior parte delle persone capisce l'html, poco capisce css. È più semplice.

"La maggior parte delle persone" non importa. I professionisti contano. Per i professionisti, i layout delle tabelle creano molti più problemi di HTML + CSS. Questo è come dire che non dovrei usare GVim o Emacs perché 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 per SEO non usare le tabelle

Non so se questo è vero e non lo userei come argomento, ma sarebbe logico. I motori di ricerca cercano rilevanti dati. Sebbene i dati tabulari possano ovviamente essere pertinenti, raramente viene cercato dagli utenti. Gli utenti cercano i termini utilizzati nel titolo della pagina o posizioni prominentemente simili. Sarebbe quindi logico escludere il contenuto tabellare dal filtraggio e quindi ridurre il tempo di elaborazione (ei costi!) Di un fattore importante.

Le tabelle sono più lente. È necessario inserire un elemento tbody extra. Questo è noccioline per i moderni browser web.

L'elemento extra non ha niente 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 che l'intera tabella venga caricata prima di poter iniziare a impaginare il contenuto. Inoltre, il caching del layout non funzionerà (i CSS possono essere facilmente memorizzati nella cache). Tutto questo è stato menzionato prima.

Mostrami alcuni benchmark in cui l'uso di una tabella rallenta in modo significativo una pagina.

Sfortunatamente, non ho alcun dato di riferimento. Sarei interessato a me stesso perché è giusto che questo argomento manchi di un certo rigore scientifico.

La maggior parte dei siti Web che necessitano di un aggiornamento necessitano anche di nuovi contenuti (html). Scenari in cui una nuova versione di un sito web ha solo bisogno di un nuovo file css non è molto probabile.

Affatto. Ho lavorato su diversi casi in cui la modifica del design è stata semplificata da una separazione di contenuti e design. Spesso è ancora necessario modificare qualche codice HTML, ma le modifiche saranno sempre molto più limitate. Inoltre, le modifiche al design devono essere apportate occasionalmente in modo dinamico. Considera motori di template come quello usato dal sistema di blogging di WordPress. I layout di tabella avrebbero letteralmente ucciso questo sistema. Ho lavorato su un caso simile per un software commerciale. Essere in grado di modificare il design senza modificare il codice HTML era uno dei requisiti aziendali.

Un'altra cosa. La disposizione delle tabelle rende molto più difficile l'analisi automatica dei siti Web (raschia schermo). Questo potrebbe sembrare banale perché, dopo tutto, chi lo fa? Sono rimasto sorpreso anch'io. Lo screen scraping può aiutare molto se il servizio in questione non offre un'alternativa WebService 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 screen scraping è l'unico modo per automatizzare il processo di acquisizione dei dati. Non c'è da stupirsi che molti biologi eseguano ancora tali compiti manualmente. Per migliaia di set di dati.

497
Konrad Rudolph

Ecco la mia risposta del programmatore da un thread simliar

Semantica 101

Per prima cosa dai un'occhiata a questo codice e pensa a cosa c'è che non va ...

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

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

Il problema, ovviamente, è che una bicicletta non è un'auto. La classe dell'auto è una classe inadeguata 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>. Tuttavia, se si posiziona la navigazione in una tabella, si sta abusando della finalità prevista dell'elemento <table>. Nel secondo caso, non stai presentando dati tabulari: stai utilizzando (erroneamente) l'elemento <table> per raggiungere un obiettivo di presentazione.

Conclusione

I visitatori se ne accorgeranno? No. Il tuo capo si preoccupa? Può essere. A volte tagliamo gli angoli come programmatori? Sicuro. Ma dovremmo? No. Chi beneficia se usi il markup semantico? Tu - e la tua reputazione professionale. Ora vai e fai la cosa giusta.

290
Carl Camera

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

Altre due cose importanti sono accessibilità e SEO.

Entrambi si preoccupano delle informazioni sugli ordini presentate. 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.

104
erlando

Vedi questa domanda duplicata.

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

Penso anche che sottovaluti 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 il modo in cui separa la presentazione dal contenuto. Ma una volta entrati in un negozio in cui sono due ruoli distinti, i vantaggi iniziano a diventare più chiari.

Se sai cosa stai facendo e hai buoni strumenti, i CSS hanno davvero dei vantaggi significativi rispetto alle tabelle per il layout. E mentre ogni elemento di per sé non può giustificare l'abbandono delle tabelle, nel complesso ne vale la pena.

91
Joel Coehoorn

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

Quindi, un sito Web il cui scopo è quello di mostrare il vantaggio di mantenere il design fuori dai contenuti, ora impegna regolarmente il PECCIA IMPLICABILE di mettere il contenuto nella progettazione. (Se l'intestazione della sezione nel file HTML dovesse cambiare, l'intestazione della sezione visualizzata non lo farebbe).

Il che dimostra che anche chi difende la rigida religione DIV e CSS, non può seguire le proprie regole. Puoi usarlo come linea guida nel modo in cui le segui da vicino.

54
James Curran

Questo non è l'argomento definitivo, in ogni caso, ma con i CSS puoi prendere lo stesso markup e cambiare il layout a seconda del medium, che è un bel vantaggio. Ad esempio, per una pagina di stampa è possibile sopprimere silenziosamente la navigazione senza dover creare una pagina stampabile.

48
expedient

Una tabella per il layout non sarebbe poi così male. Ma non è possibile ottenere il layout necessario con un solo tavolo la maggior parte del tempo. Molto presto hai 2 o 3 tabelle annidate. Questo diventa molto ingombrante.

  • È IS MOLTO più difficile da leggere. Questo non dipende dall'opinione. Ci sono solo più tag nidificati senza segni di identificazione su di essi.

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

  • Il CSS per gli stili consente al 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à del CSS Zen Garden, ma non ho mai lavorato su un sito in cui non avevo bisogno di cambiare il design un po 'qua e là. È molto più semplice con i CSS.

  • Le tabelle sono difficili da stile. Non hai molta flessibilità con loro (cioè hai ancora bisogno di aggiungere attributi HTML per controllare completamente gli stili di una tabella)

Non ho usato tabelle per dati non tabulari in probabilmente 4 anni. Non ho guardato indietro.

Mi piacerebbe davvero suggerire di leggere CSS Mastery di Andy Budd. È fantastico.

Immagine a 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

45
Ben Scheirman

È bene separare il contenuto dal layout
Ma questa è una discussione fallace; Cliche Pensando

È un argomento fallace perché le tabelle HTML sono layout! Il contenuto è data nella tabella, la presentazione è la tabella stessa. Questo è il motivo per cui separare CSS da HTML può essere molto difficile, a volte. Non stai separando il contenuto dalla presentazione, stai separando la presentazione dalla presentazione! Una pila di div nidificate non è diversa da una tabella: è solo una serie diversa di tag.

L'altro problema con la separazione dell'HTML dal CSS è che hanno bisogno di conoscenza intima l'uno dell'altro - non puoi davvero separarli completamente. Il layout dei tag nell'HTML è strettamente associato al file CSS, indipendentemente da ciò che fai.

Penso che le tabelle vs divs dipenda dalle esigenze della tua applicazione.

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

Tuttavia, abbiamo un pubblico molto chiuso per il nostro prodotto (vendiamo un pezzo di hardware con un'interfaccia web) e i problemi di accessibilità non ci interessano. Non so perché gli screen reader non siano in grado di gestire bene i tavoli, ma suppongo che se è così, gli sviluppatori devono gestirli.

36
17 of 26

CSS/DIV - sono solo posti di lavoro per i ragazzi del design, no? Le centinaia di ore che ho speso nel debugging dei problemi DIV/CSS, cercando in Internet una parte del markup che funziona con un browser oscuro, mi fa impazzire. Fai un piccolo cambiamento e l'intero layout è terribilmente sbagliato - dove su eath c'è la logica in questo. Trascorrere ore spostando qualcosa di 3 pixel in questo modo, poi qualcos'altro 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 farne uso all'ennesima potenza e in tutte le circostanze, specialmente se ti rende la vita 1000 volte più facile.

Quindi ho finalmente deciso, puramente per motivi commerciali, anche se continuo a usare al minimo, se prevedo 20 ore di lavoro per ottenere un DIV posizionato correttamente, rimarrò in un tavolo. È sbagliato, turba i puristi, ma nella maggior parte dei casi costa meno tempo ed è più economico da gestire. Posso quindi concentrarmi sull'ottenere che l'applicazione funzioni come vuole il cliente, piuttosto che compiacere i puristi. Dopo tutto pagano le bollette e la mia argomentazione a un dirigente che impone l'uso di CSS/DIV - vorrei semplicemente sottolineare che anche i clienti pagano il suo stipendio!

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

Quando progetti un modulo di Windows, non provi a spostare i controlli in giro dopo che li hai disposti, quindi penso che sia strano per me perché vorresti farlo con un modulo web. Semplicemente non riesco a capire questa logica. Prendi il layout giusto per iniziare e qual è il problema. Penso che sia perché i designer amano flirtare con la creatività, mentre gli sviluppatori di applicazioni sono più interessati a far funzionare effettivamente l'applicazione, creare oggetti business, implementare regole di business, capire come i bit dei dati dei clienti si relazionano tra loro, assicurando 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 criticate gli sviluppatori per aver scelto un approccio più semplice e più logico alla progettazione di moduli. Spesso abbiamo cose più importanti di cui preoccuparci rispetto alla semantica corretta di usare una tabella su un div.

Caso in questione - sulla base di questa discussione ho convertito alcuni tds e trs esistenti in div. 45 minuti che ci scherzavano cercando di mettere tutto in fila uno accanto all'altro e mi arresi. TD torna indietro di 10 secondi - funziona - subito - su tutti i browser, niente più da fare. Per favore, cerca di farmi capire - quale possibile giustificazione hai per volermi fare in altro modo!

23
Tim Black

Il layout dovrebbe essere facile. Il fatto che ci siano articoli scritti su come ottenere un layout dinamico a tre colonne con intestazione e piè di pagina in CSS mostra che si tratta di un sistema di layout scadente. Ovviamente puoi farlo funzionare, ma ci sono letteralmente centinaia di articoli su come farlo. Non ci sono praticamente articoli simili per un layout simile con le tabelle perché è palesemente ovvio. A prescindere da ciò che dici contro i tavoli ea favore dei CSS, questo fatto annulla tutto: un layout di base a tre colonne in CSS è spesso chiamato "The Holy Grail".

Se questo non ti fa dire "WTF", allora hai davvero bisogno di mettere giù il kool-aid ora.

Amo i CSS. Offre incredibili opzioni di stile e alcuni strumenti di posizionamento interessanti, ma come motore di layout è carente. Deve esserci un qualche tipo di sistema di posizionamento dinamico della griglia. Un modo semplice per allineare le scatole su più assi senza conoscere prima le loro dimensioni. Non me ne frega niente se lo chiami <table> o <gridlayout> o qualsiasi altra cosa, ma questa è una caratteristica di layout di base che manca ai CSS.

Il problema più grande è che non ammettendo ci sono funzionalità mancanti, gli zeloti di CSS hanno trattenuto i CSS da tutto ciò che poteva essere. Sarei perfettamente felice di smettere di usare le tabelle se il CSS fornisse un buon posizionamento della griglia multiasse come praticamente ogni 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 una simile funzione fosse utile.)

Sospiro. Basta sfogare. Vai avanti e rimetti la testa nella sabbia.

21
needlestack

In base alla conformità 508 (per i lettori di schermo per visivamente imparati), le tabelle dovrebbero essere utilizzate solo per contenere i dati e non per il layout in quanto provoca lo schermo dei lettori di schermo. O così mi è stato detto.

Se assegni nomi a ciascuna div, puoi incollarli tutti insieme usando anche i CSS. Sono solo un po 'più dolorosi di sedersi nel modo in cui ne hai bisogno.

19
Rob

Ecco una sezione di html di 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 sulla tabella è il fatto che sono troppo zelante con la mia indentazione. Sono sicuro che la sezione del contenuto avrebbe altre due tabelle incorporate.

Un'altra cosa a cui pensare: filesizes . Ho trovato che i layout basati su tabelle sono solitamente il doppio delle loro controparti CSS. Sulla nostra banda larga ad alta velocità non è un problema enorme, ma è su quelli con modem dial-up.

18
Ross

Vorrei aggiungere che i layout div-based sono più facili da mantenere, evolvere e refactoring. Solo alcuni cambiamenti nel CSS per riordinare gli elementi ed è fatto. Dalla mia esperienza, riprogettare un layout che usa le tabelle è un incubo (di più se ci sono tabelle annidate).

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

14
Guido

I layout CSS sono generalmente molto migliori per l'accessibilità, a condizione che il contenuto sia ordinato in modo naturale e abbia senso senza un foglio di stile. E non sono solo i lettori di schermo a lottare con i layout basati su tabelle: inoltre rendono molto più difficile per i browser mobili rendere una pagina correttamente.

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

Se dubiti che la separazione del contenuto dal layout sia più semplice con le div che con le tabelle, dai un'occhiata all'HT basato su div in CSS Zen Garden , vedi come cambiare i fogli di stile può cambiare drasticamente il layout e pensare se si potesse ottenere la stessa varietà di layout se l'HTML fosse basato su tabelle ... Se si sta facendo un layout basato su tabelle, è improbabile che si stia utilizzando il CSS per controllare tutta la spaziatura e il riempimento nelle celle (se In effetti, quasi sicuramente avresti trovato più facile usare i div flottanti ecc. in primo luogo). Senza usare il CSS per controllare tutto questo, e dato che le tabelle specificano l'ordine da sinistra a destra e dall'alto in basso nell'HTML, le tabelle tendono a significare che il tuo layout diventa molto fisso nell'HTML.

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

13
MB.

Il fatto che questa sia una domanda molto dibattuta è una testimonianza del fallimento del W3C nell'anticipare la diversità dei progetti di layout che sarebbero stati tentati. Usare divs + css per un layout semanticamente amichevole è un concetto grandioso, ma i dettagli di implementazione sono così imperfetti che limitano effettivamente la libertà creativa.

Ho tentato di cambiare uno dei siti della nostra azienda da tavoli a div, ed è stato un tale mal di testa che ho completamente cancellato le ore di lavoro che avevo versato e sono tornato ai tavoli. Cercare di lottare con i miei subacquei per ottenere il controllo dell'allineamento verticale mi ha maledetto con importanti problemi psicologici che non potrò mai scuotere finché infuria questo dibattito.

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

13
DLH

Non mi piacciono argomenti nei DIV.

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 proprio come volevo.

Questo dà un po 'di equilibrio ai tavoli nella maggior parte dei miei layout, e nonostante mi sento in colpa per usarli (perché, dunny, la gente dice solo che è male quindi provo ad ascoltarli), alla fine, la visione pragmatica è che è solo più facile e veloce per me usare TABLE. Non vengo pagato all'ora, quindi i tavoli sono più economici per me.

13
Radu094

Immagino sia vero che usare l'elemento table per il layout ha poco a che fare con i dati tabulari. E allora? Il mio capo si preoccupa? I miei utenti si preoccupano?

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

12
ceejayoz

Avendo dovuto lavorare con un sito Web che coinvolgeva 6 livelli di tabelle nidificate generati da alcune applicazioni, e avendo generato un codice HTML non valido, era in realtà un lavoro di 3 ore per rettificare l'interruzione per una piccola modifica.

Questo è ovviamente il caso Edge, ma il design basato su tabelle è irrinunciabile. Se usi css, separi lo stile in modo tale che quando si risolve l'HTML si abbia meno preoccupazioni da rompere.

Inoltre, prova questo con JavaScript. Sposta una singola cella di tabella da un posto a un altro posto in un'altra tabella. Piuttosto complicato da eseguire dove div/span dovrebbe funzionare solo in modalità copia-incolla.

"Il mio capo si preoccupa"

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

8
Kent Fredric

Flessibilità del layout
Immagina di creare una pagina con un numero elevato di miniature.
DIV :
Se metti ciascuna miniatura in un DIV, fluttua a sinistra, forse 10 di esse si adattano a una riga. Rendi la finestra più stretta, e BAM - è 6 su una riga, o 2, o comunque molti si adattano.
TAVOLO:
Devi dire esplicitamente quante celle ci sono in una fila. Se la finestra è troppo stretta, l'utente deve scorrere orizzontalmente.

Manutenibilità
Stessa situazione di cui sopra. Ora si desidera 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ì. Taglia un po 'da quella fila e mettili sulla quarta fila. Ora ci sono troppi articoli lì. Taglia un po 'da quella fila ... (ecc.)
(Ovviamente, se stai generando le righe e le celle con lo scripting lato server, probabilmente questo non sarà un problema.)

7
Nathan Long

Penso che quella barca abbia navigato. Se guardi alla direzione intrapresa dall'industria, noterai che i CSS e gli Open Standard sono i vincitori di quella discussione. Che a sua volta significa per la maggior parte del lavoro html, con l'eccezione delle forme, i progettisti useranno le div al posto delle tabelle. Ho delle difficoltà con questo perché non sono un guru dei CSS ma è così.

7
Thomas Wagner

Inoltre, non dimenticate che le tabelle non hanno un buon rendimento sui browser mobili. Certo, l'iPhone ha un browser kick-ass ma tutti non hanno un iPhone. Il rendering della tabella può essere un nocciolo per i browser moderni, ma è un mucchio di cocomeri per i browser mobili.

Personalmente ho scoperto che molte persone usano troppi tag <div>, ma con moderazione, può essere estremamente pulito e facile da leggere. Lei dice che la gente ha difficoltà a leggere i CSS rispetto alle tabelle; in termini di "codice" che forse è vero; ma in termini di lettura del contenuto (vista> sorgente) è molto più semplice capire la struttura con i fogli di stile che con le tabelle.

5
Swati

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

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

I vantaggi del SEO derivano dalla possibilità di avere contenuti più importanti più in alto nella pagina e di avere un migliore rapporto content-to-markup.

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

5
Rimantas

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

Le div non sostituiscono le tabelle, hanno il loro uso nella separazione del contenuto in blocchi di contenuto correlato (,). Quando non hai le competenze e ti affidi alle tabelle, dovrai spesso separare i contenuti nelle celle per ottenere il layout desiderato, ma non avrai bisogno di toccare il markup per ottenere la presentazione quando usi il markup semantico. Questo è molto importante quando viene generato il markup piuttosto che le pagine statiche.

Gli sviluppatori devono smettere di fornire il markup che implica il layout in modo che quelli di noi che hanno le capacità per presentare i contenuti possano andare avanti con i nostri lavori, e gli sviluppatori non devono tornare al loro codice per apportare modifiche quando le esigenze di presentazione cambiano.

5
Steve Perks
  • 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 finché non arriva alla fine dell'elemento </table>.
5
Rick Glos

Non si tratta di stabilire se "div è meglio delle tabelle per il layout". Qualcuno che capisce i CSS può duplicare qualsiasi progetto usando 'tabelle di layout' piuttosto semplice. La vera vittoria è usare elementi HTML per quello che sono lì per. La ragione per cui non usereste le tabelle per i dati non tablari è la stessa ragione per cui non memorizzate gli interi come stringhe di caratteri: la tecnologia funziona molto più facilmente quando la usate per lo scopo per cui è stata progettata. Se è mai stato necessario utilizzare le tabelle per il layout (a causa delle carenze del browser nei primi anni '90), certamente non lo è ora.

4
domgblackwell

Vale la pena di capire CSS e div così la colonna del contenuto centrale viene caricata e resa prima della barra laterale in un layout di pagina. Ma se stai lottando per usare i div flottanti per allineare verticalmente un logo con un testo di sponsorizzazione, usa la tabella e vai avanti con la vita. La religione del giardino zen non dà molto per scontato.

L'idea di separare il contenuto dalla presentazione è di partizionare l'applicazione in modo che i diversi tipi di lavoro influenzino diversi blocchi di codice. Questo è in realtà sulla gestione dei cambiamenti. Ma gli standard di codifica possono solo esaminare lo stato attuale del codice in maniera 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 i sili verticali. Se una modifica al "contenuto" è sempre accompagnata da una modifica a "presentazione", qual è il successo del partizionamento?

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

3
Patrick May

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

Il CSS è chiaramente preferibile nei casi in cui il markup di presentazione e il CSS supportano lo stesso tipo di design, nessuno sano di mente sosterrebbe che fontname __- tags sono migliori di specificare tipografia in CSS, dato che i CSS ti danno lo stesso potere di fontname __- 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 equivalenti al potere. La parte mancante è il comportamento simile alla griglia delle tabelle, dove 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 in puro CSS senza hardcoding di alcune dimensioni, il che rende il design rigido e fragile (purché sia ​​necessario supportare Internet Explorer - in altri browser questo si ottiene facilmente usando display:table-cell).

Quindi non si tratta in realtà di preferire tabelle o CSS, 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 not utilizzando le tabelle è l'accessibilità./Linee guida per l'accessibilità del contenuto del Web http://www.w3.org/TR/WCAG10/ consiglio di consultazione usando le tabelle per il layout. Se sei preoccupato per l'accessibilità (e in alcuni casi potresti essere legalmente obbligato a), dovresti usare CSS anche se le tabelle sono più semplici. Nota che puoi sempre creare lo stesso layout con i CSS come con le tabelle, potrebbe richiedere solo più lavoro.

3
JacquesB

Gli strumenti che utilizzano i 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 proprie pagine.

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

Dedicare il tempo necessario per ridurre il peso della pagina in modo da poter utilizzare la larghezza di banda per svolgere attività coinvolgenti con gli utenti è valsa la pena.

3
Mike Cornell

La manipolazione DOM è difficile in un layout basato su tabelle.

Con le immersioni semantiche:

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

Con le tabelle:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

Ora, scontato, il secondo esempio è un po 'stupido, e puoi sempre applicare ID o classi a una tabella oa un elemento td, ma questo sarebbe l'aggiunta del valore semantico, che è quello che i sostenitori della tabella si oppongono con veemenza.

3
Chris Fletcher

Sono stato sorpreso di vedere alcuni problemi non erano 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 hanno avuto un impatto molto significativo sulla SEO consentendo di posizionare il contenuto nella pagina dove vuoi. Alcuni anni fa, i motori di ricerca davano un'enfasi significativa ai fattori "in-page". Qualcosa nella parte superiore della pagina è stato ritenuto più pertinente alla pagina rispetto a qualcosa che si trova in basso. "Inizio pagina" per uno spider significa "all'inizio del codice". Usando i CSS, puoi organizzare il contenuto ricco di parole chiave all'inizio del codice e posizionarlo comunque ovunque desideri nella pagina. Questo è ancora piuttosto rilevante, ma i fattori di pagina sono sempre meno importanti per il posizionamento delle pagine.

b) Quando il layout viene spostato su CSS, la pagina HTML è più leggera e quindi carica più velocemente per uno spider di motori di ricerca. (gli spider non si preoccupano di scaricare file css esterni). Le pagine di caricamento rapido sono una considerazione importante per diversi motori di ricerca, tra cui 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ù facile 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 un tavolo è semplice e sicuro. È autonomo e si integra bene in qualsiasi modello. Fare lo stesso con i CSS è molto più difficile e potrebbe non essere di alcun beneficio: 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 (nelle variabili) è già separato dal layout (nel codice), rendendolo facile da modificare.

Questo è uno dei motivi per cui alcuni siti Web molto ben progettati (ad esempio SO) usano ancora i layout delle tabelle.

Naturalmente, se i risultati devono essere interpretati tramite JavaScript, i divs valgono la pena.

.3. Test di conversione rapida

Quando si capisce cosa funziona per un pubblico specifico, è utile essere in grado di cambiare il layout in vari modi per capire cosa ottiene i risultati migliori. Un layout basato su CSS rende le cose molto più semplici

.4. Diverse soluzioni per problemi diversi

Le tabelle di layout vengono solitamente ignorate perché "tutti sanno che div e CSS" sono la strada da percorrere.

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

Ci sono molti aspetti negativi delle tabelle, inclusa la manutenzione, la mancanza di flessibilità ... ma non buttiamo il bambino con l'acqua del bagno. 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 usando le tabelle perché una parte significativa degli utenti utilizzava una versione precedente di IE con un supporto davvero pessimo per i CSS

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

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

3
Sylverdrag

Perché è HELL mantenere un sito che utilizza le tabelle e impiega molto più tempo per il codice. Se hai paura delle immersioni fluttuanti, fai un corso su di loro. Non sono difficili da capire e sono circa 100 volte più efficienti e un milione di volte meno un rompicoglioni (a meno che non li capiate - ma hey, benvenuti nel mondo dei computer).

Chiunque stia considerando di fare il loro layout con un tavolo meglio non si aspetta che lo mantieni. È il modo più arretrato per rendere un sito web. Grazie a Dio abbiamo un'alternativa molto migliore ora. Non tornerò MAI più indietro.

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

3
Chuck Le Butt
  1. Prova a unire/dividere un colspan/rowspan profondo di 10/20 qualcosa. Più di una volta ho dovuto sopprimere il mio istinto di iniziare una lotta con qualcuno. [?!]
  2. Prova a cambiare l'ordine del codice sorgente senza modificare l'ordine visibile. [SEO, usabilità, ...]
  3. La pagina (molto semplice) che stiamo osservando è ~ 150K. Scommetto che può essere quasi dimezzato usando il CSS corretto. [SEO (Sì, SEO, leggi le ultime specifiche di Google ecc.), Perfo, ...]
  4. Prova a creare un modello iteratore che possa funzionare in qualsiasi larghezza.
  5. La discussione sull'argomento in questo mezzo basato su tabella di SO può causare una singolarità e distruggere tutti noi
2
Halil Özgür

Il problema della separazione rigorosa tra presentazione e contenuto mi sembra approssimativamente analogo alla separazione dei file di intestazione dai file di implementazione in C++. Ha senso, ma può anche essere un dolore. Testimonianza di Java e C # in cui le classi sono definite in un singolo file sorgente. Gli autori delle nuove lingue hanno notato qualcosa che stava causando mal di testa ai programmatori e se ne sono sbarazzati. Questo sembra essere il Gist di questa discussione. Un lato sta dicendo che i CSS sono troppo difficili, l'altro lato sta dicendo che uno deve diventare un master CSS.

Per problemi di layout semplici, perché non piegare la regola secondo cui la presentazione deve essere completamente separata? Che dire di un nuovo tag (o qualche estensione del tag div) che ci permette di controllare la presentazione direttamente in HTML? Dopotutto, non stiamo già facendo trapelare la presentazione in HTML? Guarda h1, h2 ... h6. Conosciamo tutti queste presentazioni di controllo.

La capacità di leggere codice (e HTML è codice) è molto importante. I guru tendono a trascurare l'importanza di rendere un ambiente di programmazione il più accessibile possibile alle masse. È molto miope pensare che solo i programmatori professionisti siano importanti.

2
user825628

Un grosso problema per me è che le tabelle, in particolare le tabelle nidificate, richiedono molto più tempo per il rendering rispetto a un'implementazione css propriamente detta. (Si può rendere css altrettanto lento).

Tutti i browser rendono il css più veloce perché ogni div è un elemento separato, quindi uno schermo può essere caricato mentre l'utente sta leggendo. (Per enormi set di dati, ecc.). Ho usato CSS invece di tabelle in quell'istanza che non si occupano nemmeno di layout.

Una tabella nidificata (tabelle all'interno di celle, ecc.) Non verrà visualizzata nella finestra del browser fino a quando non viene trovata l'ultima "/ tabella". Ancora peggio: una tabella mal definita non sarà nemmeno renderizzata! O quando lo fa, le cose si comportano male. (non colspanning correttamente con "TD" ecc.)

Io uso le tabelle per la maggior parte delle cose, ma quando si tratta di dati di grandi dimensioni e il desiderio di avere una schermata di rendering rapida per un utente finale, faccio del mio meglio per utilizzare ciò che i CSS hanno da offrire.

2
Tim Fischer

Ho dovuto fare siti in entrambi i modi, oltre a un terzo, il temuto layout "ibrido" con tabelle, div e stili: Vince/Divisioni CSS, facilmente.

Dovresti nidificare i divs tre in profondità per abbinare il peso del codice di una sola cella di tabella, subito dopo il pipistrello. Questo effetto si ridimensiona con le tabelle nidificate.

Preferirei anche fare un cambio di layout, rispetto a una modifica per ogni pagina del mio sito.

Ho il pieno controllo su ogni aspetto della presentazione con div/css. Le tabelle rovinano in modi orribili, specialmente in IE, un browser che non ho mai avuto l'opzione di non supportare.

Il mio tempo per la manutenzione o la riprogettazione di un sito web divs/css è una frazione di quello che sarebbe nelle tabelle.

Infine, posso innovare layout multipli commutabili con CSS e praticamente qualsiasi linguaggio di scripting. Questo sarebbe impossibile per me con le tabelle.

Buona fortuna con il tuo ROI mentre prendi questa decisione.

2
John Dunagan

Un esempio: vuoi centrare l'area del contenuto principale di una pagina, ma per poter contenere i float al suo interno, deve essere flottato. Non c'è "float: center" in CSS.

Questo non è l'unico modo per "contenere i galleggianti" all'interno di un elemento centrato. Quindi, non una buona discussione affatto!

In un certo senso, è una premessa sbagliata, la cosa "divs vs tables".

Divisione rapida e sporca di una pagina in tre colonne? Tabelle sono più facili, per essere onesti. Ma nessun professionista li usa più per il layout, perché bloccano il posizionamento degli elementi della pagina nella pagina.

La vera argomentazione è "posizionamento fatto da CSS (si spera in un file remoto)" rispetto al "posizionamento fatto da HTML nella pagina". Sicuramente tutti possono vedere i benefici del primo rispetto al secondo?

  1. Dimensione: se il layout della pagina è nell'HTML, nelle pagine, non può essere memorizzato nella cache e deve essere ripetuto su ogni pagina. Potrai risparmiare enormi quantità di larghezza di banda se il tuo layout è in un file CSS memorizzato nella cache, non nella pagina.
  2. Più sviluppatori possono lavorare sulla stessa pagina allo stesso tempo - Io lavoro sull'HTML, altri lavorano sul CSS. Nessun repository necessario, nessun problema con sovrascrittura, blocco dei file ecc.
  3. Apportare modifiche è più semplice - ci saranno problemi con il layout in diversi browser, ma devi solo correggere un file, il file CSS, per ordinarli.
  4. Accessibilità, come già detto molto prima. Le tabelle presuppongono che un layout bidimensionale funzioni per tutti. Questo non è il modo in cui alcuni utenti visualizzano i tuoi contenuti e non è il modo in cui Google visualizza i tuoi contenuti.

Considera questo:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

che rappresenta due file di una tabella con 6 celle. Qualcuno che può vedere il layout di tabella 2-D vedrà una didascalia sotto ogni immagine. Ma usando la sintesi vocale, o un PDA, e per uno spider dei motori di ricerca, è così

picture picture picture caption caption caption

e la relazione, che è evidente con il tavolo in atto, scompare.

I DIV e i CSS sono meglio per il compito di semplicemente disporre i rettangoli su una pagina HTML per ottenere un determinato progetto nel più breve tempo possibile? No, probabilmente non lo sono. Ma non mi occupo di mettere rapidamente rettangoli per ottenere un determinato progetto. Sto pensando ad un quadro molto più grande.

2
AmbroseChapel

La separazione tra contenuto e layout semplifica anche la creazione di layout di stampa o di skin (stili) diversi per il tuo sito, senza dover creare file html diversi. Alcuni browser (come Firefox) supportano anche la selezione di un foglio di stile dal menu di visualizzazione.

E penso che sia più facile mantenere un layout senza tablature. Non ti devi preoccupare di boxpans, colspans, ecc. Basta creare alcuni container-div e posizionare il contenuto dove è necessario. E detto questo lo ritengo anche più leggibile (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).

È solo un piccolo "trucco" che devi imparare (e una volta che hai imparato il trucco, penso che sia più semplice e più sensato).

2
Grad van Horck

Per rispondere all'argomento "le tabelle sono più lente", stai pensando al tempo di rendering, che è la metrica sbagliata. Molto spesso, gli sviluppatori scriveranno una tabella enorme per eseguire l'intero layout di una pagina, il che si aggiunge in modo significativo alle dimensioni della pagina da scaricare. Piaccia o no, c'è ancora un sacco di utenti dialup là fuori.

Vedi anche: uso eccessivo di ViewState

1
Greg Hurlman

Dalle esperienze passate, dovrei andare per DIV. Anche in OOP, l'obiettivo principale è ridurre l'accoppiamento tra gli oggetti, quindi questo concetto può essere applicato a DIV e tabelle. Le tabelle sono utilizzate per contenere i dati, non per sistemarli in una pagina. Un DIV è progettato specificamente per disporre gli elementi attorno a una pagina, pertanto il progetto deve utilizzare i DIV, le tabelle devono essere utilizzate per archiviare i dati.

Inoltre, la modifica di siti Web creati con tabelle è semplicemente difficile (secondo me)

1
Richard

il posizionamento di div e CSS consente un design più flessibile, che porta a modifiche e modelli più semplici delle tue pagine web.

Detto questo, se non ti interessa la flessibilità, usare un tavolo piuttosto che alcuni div che sono trasformati in un tavolo da CSS è sicuramente molto più facile e veloce da sconfiggere. Tendo ad usare i tavoli quando abbatto un disegno solo per farlo sembrare più veloce.

1
workmad3

Quando disegno il mio layout usando i CSS, generalmente conferisco a ogni sezione principale il proprio div di radice (livello del corpo), e utilizzo il posizionamento relativo/assoluto per farlo rientrare nella sua posizione corretta. Questo è un po 'più flessibile delle tabelle, poiché non sono limitato a un accordo che posso rappresentare utilizzando righe e colonne.

Inoltre, se decido di voler riordinare il layout (diciamo che voglio che la barra di navigazione sia sulla destra) posso semplicemente andare e modificare la posizione degli elementi in un unico posto (il file CSS) e l'HTML non funziona Devo cambiare. Se lo facessi con le tabelle, dovrei entrare e trovare le informazioni e fare un sacco di modding degli attributi e copiare e incollare per ottenere lo stesso effetto.

Infatti, usando i CSS, posso persino avere i miei utenti selezionare come vogliono che il loro layout funzioni. Fintanto che le dimensioni generali delle aree di contenuto non cambiano, sto perfettamente bene con l'utilizzo di un po 'di PHP scripting per generare il mio CSS in base alle preferenze dell'utente e permettendogli di riorganizzare il sito in i loro gusti Ancora una volta, possibile con le tabelle, ma molto più difficile da mantenere.

Infine, i CSS consentono un vantaggio MAGGIORE che le tabelle non forniranno mai: la capacità di riformattare il contenuto in base al dispositivo di visualizzazione. Il CSS mi consente di utilizzare un set di stili completamente diverso (compresa la posizione, la formattazione, ecc.) Per una stampante rispetto a quello che uso per il monitor. Questo può essere esteso anche ad altri media, un esempio eccellente è Opera Show, che consente di creare una pagina CSS ottimamente progettata (e molto standard) per essere vista come una presentazione.

Quindi, alla fine, la flessibilità e la gestione sono i veri vincitori. Generalmente, i CSS ti consentono di fare di più con il layout. Non c'è niente tecnicamente non standard su un layout basato su tabelle, ma perché vorresti limitarti?

1
Nicholas Flynt

In passato, gli screen reader e altri software per l'accessibilità hanno avuto difficoltà a gestire le tabelle in modo efficiente. In una certa misura, questo è stato gestito in lettori di schermo dal lettore passando da una modalità "tabella" a una modalità "layout" in base a ciò che vedeva all'interno del tavolo. Questo era spesso sbagliato, e quindi gli utenti dovevano cambiare manualmente la modalità durante la navigazione attraverso le tabelle. In ogni caso, le tabelle grandi, spesso molto nidificate erano, e in larga misura, sono ancora molto difficili da navigare attraverso uno screen reader.

Lo stesso è vero quando vengono utilizzati div o altri elementi a livello di blocco per ricreare tabelle e sono altamente annidati. Lo scopo di div è quello di essere usato come elemento di fomation e di layout e, come tale, è inteso per contenere informazioni simili e disporlo sullo schermo per gli utenti visivi. Quando uno screen reader incontra una pagina, ignora spesso qualsiasi informazione di layout, sia basata su CSS, sia basata su attributi html (questo non è vero per tutti i lettori di schermo, ma per quelli più popolari, come JAWS, Windows Eyes e Orca per Linux è).

A tal fine, i dati tabulari, vale a dire i dati che hanno senso logico essere ordinati in due o più dimensioni, con una sorta di intestazione, sono posizionati nelle tabelle migliori e utilizzano le div per gestire il layout del contenuto sulla pagina. (un altro modo per pensare a cosa sono i "dati tabulari" è cercare di disegnarlo in forma di grafico ... se non ci riesci, probabilmente non è meglio rappresentato in una tabella)

Infine, con un layout basato su tabella, al fine di ottenere un controllo a grana fine della posizione degli elementi sulla pagina, vengono spesso utilizzate tabelle molto nidificate. Questo ha due effetti: 1.) Maggiore dimensione del codice per ogni pagina - Poiché la navigazione e la struttura comune sono spesso eseguite con le tabelle, lo stesso codice viene inviato sulla rete per ogni richiesta, mentre un layout basato su div/css estrae il file css oltre una volta, e quindi usa meno divulatorie wordy. 2.) Le tabelle nidificate impiegano molto più tempo per il rendering del browser del client, portando a tempi di caricamento leggermente più lenti.

In entrambi i casi, l'aumento dell'ampiezza di banda dell'ultimo miglio, così come i personal computer molto più veloci attenuano questi fattori, ma in ogni caso sono ancora problemi esistenti per molti siti.

Con tutto ciò a mente, come altri hanno già detto, le tabelle sono più facili, perché sono più orientate alla griglia, consentendo meno riflessioni. Se il sito in questione non dovrebbe essere lungo, o non verrà mantenuto, potrebbe essere sensato fare ciò che è più semplice, perché potrebbe essere il più conveniente. Tuttavia, se la base di utenti prevista potrebbe includere una parte sostanziale di persone con handicap, o se il sito verrà mantenuto da altri per un lungo periodo, passare il tempo in anticipo per fare le cose in modo conciso e accessibile potrebbe avere un guadagno maggiore alla fine.

1
cdeszaq

Ancora non capisco come div/CSS rendano più semplice cambiare il design di una pagina quando si considera la quantità di test per garantire che le modifiche funzionino su tutti i browser, specialmente con tutti gli hack e così via. È un processo estremamente frustrante e noioso che spreca grandi quantità di tempo e denaro. Per fortuna la legislazione 508 si applica solo agli Stati Uniti (terra del libero - sì, sì) e quindi, dato che sono con sede nel Regno Unito, posso sviluppare siti web in qualsiasi stile scegliamo. Contrariamente alla credenza popolare (USA), la legislazione fatta a Washington non si applica al resto del mondo - grazie a Dio per questo. Deve essere stata una buona giornata nel mondo del web design il giorno in cui la legislazione è entrata in vigore. Penso di diventare sempre più cinico mentre invecchio da 25 anni nel settore IT, ma sono certo che questo tipo di legislazione è solo per proteggere i posti di lavoro. In realtà chiunque può mettere insieme una pagina web ragionevole con un paio di tavoli. Ci vuole molto più impegno e conoscenza per farlo con DIV/CSS. Secondo la mia esperienza, possono essere necessarie ore e ore per cercare soluzioni a problemi abbastanza semplici e leggere articoli incomprensibili nei forum pieni di zeloti idealisti che discutono sul modo "giusto" di fare le cose. Non puoi semplicemente immergere le dita dei piedi nell'acqua e fare in modo che le cose funzionino correttamente in ogni caso. Mi sembra anche che la mancanza di una guida definitiva all'utilizzo di DIVS/CSS "out of the box", che si applica a tutte le situazioni, che funziona sui browser e scritta usando un linguaggio "normale" senza parlare con geek, profuma anche di un po 'di protezionismo.
Sono uno sviluppatore di applicazioni e direi che ci vuole quasi il doppio del tempo per capire i problemi di layout e testare tutti i browser di quanto non faccia per creare l'applicazione di base, progettare e implementare oggetti business e creare il database back end. Il mio tempo = denaro, sia per me che per i miei clienti, quindi mi dispiace se non rigetto tutti gli argomenti di DIV/CSS pro in favore del taglio dei costi e della fornitura di un rapporto qualità-prezzo per i miei clienti. Forse è proprio il modo in cui le menti degli sviluppatori funzionano, ma mi sembra molto più facile cambiare una struttura di tabelle complessa piuttosto che modificare DIV/CSS. Per fortuna ora sembra che una soluzione a questi problemi sia ora disponibile - si chiama WPF.

1
Tim Black

Penso che a nessuno importi come un sito web sia stato progettato/implementato quando si comporta bene e funziona velocemente.

Io uso entrambi i tag "table" e "div"/"span" nel markup HTML.

Permettetemi di darvi alcuni argomenti per cui scelgo le div:

  1. per un tavolo devi scrivere almeno 3 tag (table, tr, td, thead, tbody), per un design Nice, a volte hai un sacco di tabelle annidate

  2. Mi piace avere componenti sulla pagina. Non so come spiegare esattamente, ma proverò. Supponiamo che tu abbia bisogno di un logo e questo deve essere inserito, solo una piccola parte, nel contenuto della pagina successiva. Usando le tabelle devi tagliare 2 immagini e metterle in 2 diversi TD. Usando i DIV puoi avere un semplice CSS per impostarlo come vuoi. Quale soluzione ti piace di più?

  3. quando più di 3 tabelle nidificate per fare qualcosa, sto pensando di riprogettarlo usando i DIV

MA sto ancora usando le tabelle per:

  1. dati tabulari

  2. contenuto che si sta espandendo

  3. soluzioni veloci (prototipi), perché il modello di box DIV è diverso su ogni browser, perché molti generatori usano tabelle, ecc

1
Dani

Usando ancora la tabella per i layout, ci manca l'innovazione sul lato div.

Molti hanno escogitato soluzioni che rendono più semplice la creazione di layout per le div. Il più popolare è l'architettura della griglia. Esistono generatori di layout dinamici basati su questa architettura. Controlla: 1) 960.gs e (http://grids.heroku.com/) 2) progetto e molti di recente.

Non ho visto molta innovazione in termini di architettura e strumenti con il layout delle tabelle.

Direi, a parte tutte le teorie, praticamente il layout con CSS e le div sono più veloci. Piuttosto l'innovazione in questa direzione ha reso più facile di qualsiasi altra cosa.

1
Pixelgrey

Le tabelle sono buone per l'HTML che stai lanciando insieme per qualcosa di semplice o temporaneo. Se stai costruendo un sito Web su larga scala, dovresti usare div e CSS, dal momento che sarà più facile mantenerlo nel tempo mentre il tuo sito web cambia.

1
Adam Rosenfield

1: Sì, i tuoi utenti si preoccupano. Se usano uno screen reader, andranno persi. Se utilizzo qualsiasi altro strumento che tenta di estrarre informazioni dalla pagina, l'individuazione di tabelle che non vengono utilizzate per rappresentare dati tabulari è fuorviante.

Un div o span è accettabile per separare il contenuto perché questo è precisamente il significato di quegli elementi . Quando io, un motore di ricerca, uno screen reader o qualsiasi altra cosa, incontriamo un elemento di tabella, ci aspettiamo che questo significhi "il seguente è un dato tabellare, rappresentato in una tabella". Quando incontriamo un div, ci aspettiamo "questo è un elemento usato per div ide il mio contenuto in parti o aree separate.

2: leggibilità: sbagliato. Se tutto il codice di presentazione è in css, posso leggere l'html e capirò il contenuto della pagina. O posso leggere il css e capire la presentazione. Se tutto è mescolato insieme in html, devo eliminare mentalmente tutti i bit relativi alla presentazione prima che possa persino vedere cosa è contenuto e cosa no. Inoltre, sarei impaurito di incontrare uno sviluppatore web che non capiva i CSS, quindi non credo che sia un problema.

3: le tabelle sono più lente: sì, lo sono. Il motivo è semplice: le tabelle devono essere analizzate completamente, compreso il loro contenuto prima che possano essere renderizzate. Un div può essere reso quando viene incontrato, anche before il suo contenuto è stato analizzato. Ciò significa che le div verranno visualizzate prima che la pagina abbia completato il caricamento.

E poi c'è il bonus, che i tavoli sono molto più fragili e non saranno sempre resi uguali in browser diversi, con caratteri e dimensioni di font diversi e tutti gli altri fattori che possono far variare il layout. Le tabelle sono un modo eccellente per garantire che il tuo sito sia disattivato di un pixel o due in alcuni browser, non si adatta bene quando l'utente modifica la dimensione del suo carattere o modifica le sue impostazioni in qualsiasi altro modo.

Ovviamente # 1 è il più grande. Molti strumenti e applicazioni dipendono dal significato semantico di una pagina web. Il solito esempio sono gli screen reader per gli utenti ipovedenti. Se sei uno sviluppatore web, scoprirai che molte grandi aziende che potrebbero altrimenti assumerti per lavorare su un sito, richiedono che il sito sia accessibile anche in questo caso. Il che significa che devi pensare al significato semantico del tuo html. Con il web semantico, o più pertinentemente, microformati, lettori RSS e altri strumenti, il contenuto della pagina non viene più visualizzato esclusivamente attraverso un browser.

1
jalf

Mi dispiace per il mio inglese, ma ecco un altro motivo:

Ho lavorato in alcune organizzazioni governative e il motivo numero uno per non usare TABLE è per le persone disabili. Usano le macchine per "tradurre" le pagine web.

Il problema è che questa "macchina di traduzione" non può leggere il sito web se è fatto da TABLE. Perché ? Perché TABLE sono per DATAS.

infatti, se usi TABLES, per ogni CELLS devi specificare alcune informazioni per permettere alle persone disabili di sapere dove si trovano nella TABLE. Immagina di avere un grande tavolo e devi zoomare per vedere solo 1 cella sullo schermo: devi sapere in quale linea/colonna sei.

Quindi, i DIV sono usati, e i disabili possono semplicemente leggere il testo, e non ottenere alcune strane informazioni sulle linee/colonne quando non devono esserci.

Preferisco TABLE anche per creare template semplici e veloci, ma ora sono abituato al CSS ... è potente, ma devi sapere cosa stai facendo ... :)

1
RVeur23

Flex ha un tag per sistemare le cose in colonne verticali. Non credo che abbiano avuto l'intero contenuto/contenuto in questione, a dire il vero, ma almeno hanno risolto il problema.

Come molte delle persone frustrate dalla CSS, ho anche guardato in lungo e in largo per una risposta facile, sono stato ingannato nel sentirmi euforico quando pensavo di averlo trovato, e poi ho fatto a pezzi le mie speranze quando ho aperto la pagina in Chrome. Non sono abbastanza abile da dire che non è possibile, ma non ho visto nessuno offrire codice di esempio per la revisione da parte dei colleghi che dimostra in modo inequivocabile che può essere fatto in modo affidabile.

Quindi, qualcuno dal lato CSS di quest'isola può raccomandare una mentalità/metodologia per la stesura di colonne verticali? Ho provato il posizionamento assoluto in seconda e terza riga, ma finisco per sovrapporre roba ovunque e float ha problemi simili se la pagina viene ridotta.

Se ci fosse una risposta a questo sarei estatico a - fai la cosa giusta - Dimmi solo qualcosa tipo "Ehi hai provato ** flow: vertical | horizontal" e I Sono completamente fuori di testa.

1
Shanimal

Google attribuisce priorità molto bassa al contenuto del testo contenuto in una tabella. Stavo dando alcuni consigli SEO ad un ente di beneficenza locale. Nell'esaminare il loro sito Web stava usando le tabelle per impaginare il sito. Osservando ogni pagina, indipendentemente dalle parole - o combinazioni di parole - dalle loro pagine che ho usato nella casella di ricerca di Google, le pagine non comparivano in nessuna delle pagine di ricerca principali. (Tuttavia, specificando il sito nella ricerca è stata restituita la pagina.) Una pagina è stata ben copiata dagli standard normali per produrre un buon risultato in una ricerca ma ancora non è stata visualizzata in nessuna delle prime pagine dei risultati di ricerca restituiti . (Nota che questo testo era all'interno di un tavolo.) Poi ho individuato una sezione di testo nelle pagine che erano in un div piuttosto che in un tavolo. Inseriamo alcune parole da quel div nel motore di ricerca. Risultato? È arrivato al n. 2 nel risultato della ricerca.

1
Simon Measures

Una volta ho appreso che una tabella si carica contemporaneamente, in altre parole quando una connessione è lenta, lo spazio in cui la tabella arriva rimane vuoto fino a quando non viene caricata l'intera tabella, mentre un div si carica dall'alto verso il basso alla velocità dei dati e indipendentemente se è già completo o no.

1
Davy

Utilizzare le tabelle quando è necessario assicurarsi che gli elementi debbano rimanere in una specifica relazione fisica nel layout. Per i dati, la tabella è generalmente l'elemento di layout migliore da utilizzare perché non vuoi che le tue colonne si avvolgano in modi imprevisti e confondano le associazioni.

Si potrebbe anche sostenere che gli elementi non-dati che devono rimanere in una relazione specifica dovrebbero anche essere visualizzati in una tabella.

I layout CSS flessibili sono ideali per i contenuti che sono adatti per dispositivi mobili e schermi di grandi dimensioni e per la stampa e altri tipi di display, ma a volte il contenuto deve essere visualizzato in un modo molto specifico e se ciò richiede che i lettori di schermo non possano accedervi facilmente, potrebbe benissimo essere giustificato.

1
Sal

Cerco di evitare il più possibile TABLE, ma quando progettiamo forme complesse che combinano più tipi di controllo e diverse posizioni di didascalia con controlli piuttosto rigidi sul raggruppamento, usare i DIV è inaffidabile o spesso quasi impossibile.

Ora, non sostengo che questi moduli non potrebbero essere riprogettati per meglio adattarsi a un layout basato su DIV, ma per alcuni di essi il nostro cliente è fermamente convinto a non modificare i layout esistenti dalla versione precedente (scritto in ASP classico) perché è parallelo a un modulo cartaceo con cui i loro utenti hanno familiarità.

Poiché la presentazione dei moduli è dinamica (dove la visualizzazione di alcune sezioni è basata sullo stato del caso o sui permessi dell'utente), utilizziamo insiemi di DIV impilati, ciascuno contenente una TABELLA di elementi di modulo raggruppati logicamente. Ogni colonna di TABLE è classificata in modo che possano essere controllate dai CSS. In questo modo possiamo disattivare diverse sezioni del modulo senza il problema di non essere tabella per avvolgere righe in DIV.

1
CMPalmer

Ho studiato il problema degli screen reader e dei tavoli alcuni anni fa e ho trovato informazioni che contraddicono ciò che la maggior parte degli sviluppatori crede:

http://www.webaim.org/techniques/tables/

"Probabilmente sentirai alcuni sostenitori dell'accessibilità dire che le tabelle di layout sono una cattiva idea e che invece dovrebbero essere usate le tecniche di layout CSS. C'è del vero in quello che dicono, ma, ad essere sinceri, usare le tabelle per il layout non è il peggiore cosa che potresti fare in termini di accessibilità: le persone con tutti i tipi di disabilità possono accedere facilmente alle tabelle, purché le tabelle siano progettate tenendo conto dell'accessibilità. "

1
Rimian

Credo che questo sia un problema connesso a un problema generale. Quando è nato HTML, nessuno poteva prevedere il suo uso diffuso. Un'altra tecnologia che è quasi crollata sotto il peso del proprio successo. Quando le pagine HTML sono state scritte in vi su un terminale di testo verde, TABELLA era tutto ciò che era necessario per presentare i dati ai visitatori della pagina, e per lo più erano dati che avevano un senso in una tabella.

Sappiamo tutti come si sono evolute le cose. TABELLA è passata di moda relativamente di recente, ma ci sono molti motivi per preferire i DIV e i layout basati su CSS (l'accessibilità non è l'ultima). Ovviamente non posso scrivere un CSS per salvarmi la vita :-) e penso che un esperto di design grafico dovrebbe essere sempre a portata di mano.

Detto questo ... ci sono molti dati che dovrebbero essere presentati in una tabella anche in un sito web moderno.

1
Manrico Corazzi

Se stai supportando l'angolo del tavolo su questo trova un sito con le tabelle e poi procurati uno screen reader, attiva lo screen reader e spegni il monitor.

Quindi provalo con un bel sito di layout div semanticamente corretto.

Vedrai la differenza.

Le tabelle non sono malvagie se i dati in esse contenuti non sono tabellare la pagina.

1
Allen Hardy

Secondo le mie conoscenze sulle tabelle, se troppe tabelle sono nidificate, c'è un grande sovraccarico per il browser nel rendering della pagina.

1 - Il browser è in attesa di eseguire il rendering della vista finale attendere che venga caricata l'intera tabella.

2 - L'algoritmo per rendere la tabella è costoso e non è in un unico passaggio. Il browser, come e quando, ottiene i contenuti, proverà a eseguire il calcolo della larghezza e dell'altezza del contenuto. Quindi, se hai tabelle annidate, per esempio, il browser ha ricevuto la prima riga e la prima cella ha una grande quantità di contenuto, larghezza e altezza non definite, calcolerà la larghezza e renderà la prima riga, Nella media mentre ottiene la seconda riga, la cella # 2 avrà un sacco di contenuti! Ora calcolerà la larghezza per le celle della seconda riga. E il primo? Calcolerà le larghezze in modo ricorsivo. Non va bene dal lato client. (Per collocare un esempio) Come programmatore, ottimizzerai cose come il tempo di recuperare dati, strutture dati ottimizzate e così via. Ottimizzi le cose da completare sul lato server, ad esempio in2 secondi, ma l'utente finale a ottenere la vista finale in 8 secondi. Cosa c'è di sbagliato qui? 1. La rete potrebbe essere lenta! Cosa succede se la rete va bene? Qual è la rete sta consegnando i contenuti nel prossimo 1 sec? Dove vengono consumati questi 5 secondi in più? Cosa ti preoccupa-- Il browser potrebbe impiegare molto tempo a stimare e rendere i tavoli!

Come ottimizzare le tabelle? Se stai usando le tabelle, suggerirei, definisci sempre la larghezza per le celle. Ciò non garantisce che il browser prenderà ciecamente solo questa larghezza, ma sarebbe di grande aiuto per il browser nel decidere le larghezze iniziali.

Ma, alla fine, div è un ottimo modo in cui i CSS possono essere messi in cache dal browser; mentre la tabella non viene memorizzata nella cache!

1
Biranchi Panda

Le tabelle utilizzate come layout puro pongono alcuni problemi di accessibilità (che ho sentito). Ma capisco quello che viene chiesto qui che in qualche modo stai paralizzando il web usando un tavolo per garantire il corretto allineamento di qualcosa sulla tua pagina.

Ho sentito persone che discutono prima che le etichette e gli input FORM siano, in effetti, dati e che dovrebbero essere consentiti nelle tabelle.

L'argomento secondo cui l'utilizzo di una tabella per assicurarsi che alcuni elementi siano allineati correttamente causa questo massiccio aumento del codice, tendono ad includere esempi di come un singolo DIV può soddisfare tutte le loro esigenze. Non sempre includono le 10 linee di CSS e gli hack speciali dei browser che hanno dovuto scrivere per IE5, IE5.5, IE6, IE7 ...

Penso che rimanga sull'uso dell'equilibrio nel tuo design. Le tabelle sono nella casella degli strumenti, basta ricordare a cosa servono ...

0
HB

Sicuramente l'OP era un po 'finita, gli argomenti sembrano così settimanali e facilmente contrastati.

Le pagine Web sono il dominio degli sviluppatori web, e se dicono che div e CSS sono meglio delle tabelle che sono abbastanza buone per me.

Se un layout viene realizzato da tabelle generate da un'app server, quindi un nuovo layout significa modifiche all'app, una ricostruzione e un aggiornamento rapido dell'applicazione, come indicato solo per le modifiche a un file css.

Inoltre, accessibilità. Le tabelle utilizzate per il layout rendono inaccessibile un sito Web, quindi non utilizzarle. È un gioco da ragazzi, per non parlare di illegale.

0
Ian

Risposta brevissima: progettare siti Web gestibili è difficile con le tabelle e semplice con il modo standard per farlo.

Un sito Web non è un tavolo, è una raccolta di componenti che interagiscono tra loro. Descriverlo come una tabella non ha senso.

0
Rich Bradshaw

In termini di manutenzione del sito e revisioni del design mantenendo i contenuti (che si verificano sempre, soprattutto nell'e-commerce):

Contenuto e design sono stati riuniti insieme tramite tabelle = aggiornamento di contenuti e design.

Contenuto separato dal design = aggiornamento del design e forse un piccolo contenuto.

Se avessi fatto a modo mio, avrei mantenuto il mio contenuto in PHP generando XML, convertito in markup in XSLT e progettato con CSS e Javascript per l'interazione. Per il lato Java delle cose, JSP a JSTL per generare il markup.

0
mltorrefranca

Usando DIV, puoi facilmente cambiare le cose. Ad esempio, potresti fare questo:

Menu | Content

Content | Menu

Menu
----
Content

È facile modificarlo in CSS, non in HTML. Puoi anche fornire diversi stili (destrimano, mancino, speciale per piccolo schermo).

In CSS, puoi anche nascondere il menu in un foglio di stile speciale utilizzato per la stampa.

Un altro aspetto positivo è che il tuo contenuto è sempre nello stesso ordine nel codice (prima il menu, il contenuto dopo) anche se visivamente è presentato diversamente.

0
ofaurax