HTML <div>: più veloce del table. Perché?

[fcaldera]

Originariamente inviato da k.b
Ma valutate il lavoro nel suo complesso o vi basta vedere un tag <table> per cassare tutto senza ulteriore ispezione?

valutiamo il lavoro nel suo complesso, e difficilmente chi sviluppa a tabelle ne usa una sola e basta.
Dopo 100 righe già si perdono di vista gli annidamenti.
Lo stesso parere negativo è riservato anche a chi <divifica> qualsiasi cosa. C'è gente che utilizza i div esattamente come se stesse usando una tabella (che è anche peggio) e non usa la marcatura corretta.

Originariamente inviato da k.b
Perche' ripeto, usare UNA tabella per lo scheletro di un layout (o per una sua parte) non e' sinonimo di "lavoro fatto male e impossibile da mantenere".?

io non so a che tipi di layout tu faccia riferimento: se c'è una sola tabella significa che il resto è tableless. quindi si sarebbe potuto evitare anche quell'unica tabella.

Quindi, serve davvero o semplicemente è un problema di non sapere come fare ad evitare quella tabella?

chi è che, sapendo fare dei buoni layout senza tabelle, poi si serve di una tabella magari solo per centrare il contenuto?

[fcaldera]

Originariamente inviato da k.b
Mi interesserebbe leggerla, ad ora non ho trovato una soluzione pienamente soddisfacente. Ovviamente parlo di label accanto all'input box, uno sotto l'altro non vale

soluzione tableless

<fieldset>
<label>...</label>
<input... />
</fieldset>

label e input flottati a sinistra e clearing sul fieldset

soluzione a tabelle

<table>
<tr>
<td>
<label>....</label>
</td>
<td>
<input ... />
</td>
</tr>
</table>

[k.b]

Originariamente inviato da fcaldera
soluzione tableless

<fieldset>
<label>...</label>
<input... />
</fieldset>

label e input flottati a sinistra e clearing sul fieldset

soluzione a tabelle

<table>
<tr>
<td>
<label>....</label>
</td>
<td>
<input ... />
</td>
</tr>
</table>

Ok, ma come garantisci che gli input siano tutti allineati indipendentemente dalla lunghezza delle label?

[ricman]

Originariamente inviato da k.b
Ma valutate il lavoro nel suo complesso o vi basta vedere un tag <table> per cassare tutto senza ulteriore ispezione? Perche' ripeto, usare UNA tabella per lo scheletro di un layout (o per una sua parte) non e' sinonimo di "lavoro fatto male e impossibile da mantenere". Non posso credere che se vedete un paio di table/tr/td non sapete piu' che pesci prendere per fare una modifica, dai. E mi vuoi dire che non hai mai visto layout table-less orribili e impossibili da mantenere salvo riscrittura?

Ma tu parli sempre di eccezioni... (che cmq io non userei.. sono a favore dei div).

Capisco che al tuo ristorante un piatto di pasta, con un po' di impegno, posso anche mangiarlo col coltello... non ci sono leggi che te lo impediscono. Ma la forchetta cosa cavolo ci sta a fare allora?!?
Usiamo ogni cosa per il suo scopo!!
Oltretutto il disabile di turno potrebbe non riuscire a mangiare da te...

Io facevo siti con le tabella quando iniziai anni fa... poi le cose vanno avanti, si sistemamo, vengono definite delle linee guida migliori... perchè non seguirle? Perchè continuare a cercare quegli unici due layout un po' più difficili da realizzare senza tabelle (se ci sono).

E Si... Se io (ma siamo in molti a quanto pare) vedo un sito con le tabelle (usate alla ca###) lo giudico fatto da qualcuno poco esperto o poco aggiornato, o che usa vecchi sistemi, o che usa "programmini" che gli fanno il layout tracciando linee a dx e sx ... Insomma non mi fa certo una bella impressione... Fossi una ditta che cerca personale ci guarderei a queste cose!!

[Myaku]

Originariamente inviato da k.b
Ok, ma come garantisci che gli input siano tutti allineati indipendentemente dalla lunghezza delle label?

cercando di non andare troppo ot ... gli definisci la larghezza (alle label)

[k.b]

Originariamente inviato da Myaku
cercando di non andare troppo ot ... gli definisci la larghezza (alle label)

Gia', ma cosi' non e' piu' "indipendente dalla lunghezza delle label". In pratica devi individuare la label piu' lunga e dare la width fissa di conseguenza, il che e' contrario al principio di separazione tra contenuto e presentazione. Se un giorno aggiungi una label piu' lunga, devi cambiare anche il foglio di stile, cosa che non dovrebbe mai succedere.

[k.b]

Originariamente inviato da ricman
E Si... Se io (ma siamo in molti a quanto pare) vedo un sito con le tabelle (usate alla ca###) lo giudico fatto da qualcuno poco esperto o poco aggiornato, o che usa vecchi sistemi, o che usa "programmini" che gli fanno il layout tracciando linee a dx e sx ... Insomma non mi fa certo una bella impressione... Fossi una ditta che cerca personale ci guarderei a queste cose!!

Ma su questo siamo d'accordo, dico solo che una singola tabella non e' sinonimo di layout fatto da schifo. Chiaro che se - come sempre mi par di capire - si paragonano siti fatti con frontpage e mille tabelle annidate a layout fatti coi div pulitissimi e validati strict, allora grazie che i primi li scarti

Le tabelle sono solo uno strumento. Se ne puo' fare a meno? Si, certo che si puo'. Le alternative alle tabelle sono altrettanto semplici e cross browser? No, non lo sono. E' peggio usare UNA tabella per i casi particolari, o tutti gli hack necessari per far digerire lo stesso layout table-less a tutti i browser compreso quel cesso di IE6? Dipende dai punti di vista, specialmente del cliente che paga.

Ho visto diverse volte layout table-less con fix JAVASCRIPT per sistemare il layout. Mi sembra un'aberrazione ben peggiore di usare una tabella.

[Myaku]

Originariamente inviato da k.b
il che e' contrario al principio di separazione tra contenuto e presentazione.

tale principio è: contenuto -> html // presentazione -> css (situazione ideale, esterno), ergo è rispettato.
non lo è invece usare le tabelle in maniera impropria, poichè: form con tabella -> vincolare la presentazione all'html. se un domani non vuoi più le label affiancate agli input (presentazione), quel domani dovrai modificare l'html.

devi cambiare anche il foglio di stile, cosa che non dovrebbe mai succedere.

e dove sta scritto?

[fcaldera]

Originariamente inviato da k.b In pratica devi individuare la label piu' lunga e dare la width fissa di conseguenza,

1) Assegnare una larghezza alla label non implica che la label non possa essere più lunga, ma semplicemente che andrà a capo... cosa peraltro più che ragionevole mi pare.

2) dalla tua osservazione sembrerebbe, implicitamente, che facendolo a tabelle non assegneresti una larghezza fissa ai td che contengono le label: quindi tu lasceresti libera la tua tabella di spaziarsi a caso ? :master:

Originariamente inviato da k.b
il che e' contrario al principio di separazione tra contenuto e presentazione.

principio che con questo esempio non c'entra nulla.
Il principio che citi parla di tutt'altro e riguarda il fatto di usare tag semanticamente corretti e stili non incorporati nel documento

[k.b]

Originariamente inviato da Myaku
tale principio è: contenuto -> html // presentazione -> css (situazione ideale, esterno), ergo è rispettato.

Non e' rispettato perche' per scrivere la definizione nel foglio di stile devi prima sapere cosa conterra' la label (ed e' un contenuto potenzialmente dinamico).

Se usi una tabella per cambiare il layout devi toccare l'HTML.
Se usi la fixed width per cambiare il contenuto devi toccare il foglio di stile.
Stesso problema, da due punti di vista differenti.