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

[k.b]

Originariamente inviato da fcaldera
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:

Ma perche' ogni volta che si nomina una tabella si deve dare una connotazione negativa al discorso? Che significa "a caso"? Sarebbe libera di adattarsi al suo contenitore non "a caso". Ma sarebbe solo un limite massimo, mentre la larghezza esatta si adatterebbe dinamicamente.

Chiaro che con una larghezza fissa al massimo la label va a capo, ma perche' una limitazione del genere (magari a me non piace che una cosa vada a capo) la ritenete accettabile e una tabella no? Cioe' piuttosto meglio una pagina meno bella da vedere che un markup "impuro"?

[fcaldera]

Originariamente inviato da Myaku
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.

oltretutto la modifica potenzialmente non è in un solo punto
ma in tutte le pagine che contengono contenuti affiancati a tabelle

se invece nei miei "enne" form table-less controllati dai soli css decido di mettere gli input sotto le label o magari scambiarle di posto (input a sinistra e label a destra) posso farlo cambiando le regole di stile un solo punto (inverto i float)

quale dei due metodi vìola maggiormente (anzi: vìola e basta) quel principio di separazione tra presentazione e contenuti?

Originariamente inviato da k.b
Che significa "a caso"?

a caso significa "senza una regola specifica"
comunque tu lo definisca la sostanza resta sempre la stessa.

[fcaldera]

Originariamente inviato da k.b
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).

- a parte che come ti ho scritto prima la larghezza della label così specificata non sarebbe vincolante in assoluto (la label andrebbe a capo)...

- a parte che esistono altri metodi che non richiederebbero nemmeno di definire una larghezza alle label (ma che a te non interesseranno immagino)...

invece se lo fai a tabelle non devi sapere se le label vanno a destra o gli input a sinistra vero?
o la label sopra e l'input sotto?

che succede se fai 10 form e poi ti dicono di cambiare l'allineamento?
quante modifiche devi fare?

in questo caso non lo devi sapere prima vero?

[k.b]

Originariamente inviato da fcaldera
invece se lo fai a tabelle non devi sapere se le label vanno a destra o gli input a sinistra vero?
o la label sopra e l'input sotto?

che succede se fai 10 form e poi ti dicono di cambiare l'allineamento?

in questo caso non lo devi sapere prima vero?

Certo che si! Infatti anche le tabelle infrangono quel principio. Pero' almeno si adattano dinamicamente.

Cosa succede se faccio 10 form e poi devo cambiare l'allineamento? Succede che cambiero' 10 form, che nel frattempo funzionano.

Cosa succede se hai 10 form con label non note a priori perche' magari estratte da un db in cui le inseriscono dei redattori? Succede che devi cambiare le dichiarazioni dei fogli di stile per i form, e nel frattempo l'impaginazione e' piu' brutta perche' alcune label vanno a capo.

Io non sto dicendo "tabelle buone, table-less schifo", riconosco ed uso quotidianamente gli enormi vantaggi che i layout "liberi" dalle costrizioni delle tabelle garantiscono, pero' in certi casi l'approccio "purista" non e' la panacea di tutti i mali come molti vogliono far credere. In tutti i casi ci sono vantaggi e svantaggi. Di sicuro in genere le tabelle creano molti piu' problemi di quelli che risolvono, pero' in alcuni casi particolari l'alternativa non e' poi cosi' migliore.

[fcaldera]

Originariamente inviato da k.b
Le alternative alle tabelle sono altrettanto semplici e cross browser? No, non lo sono

me l'ero persa questa...

lo sono sì se uno si prende la briga di studiarle.
troppo facile fare gli sviluppatori frontend e poi ricorrere alle tabelle, visto che altri metodi una spanna più efficienti richiedono un po' di impegno per essere messi in pratica.

come se uno dicesse di essere un dentista perché sa curare le carie. estraendo direttamente il dente.

[k.b]

Originariamente inviato da fcaldera
- a parte che esistono altri metodi che non richiederebbero nemmeno di definire una larghezza alle label (ma che a te non interesseranno immagino)...

Certo che mi interessano! Anzi, il discorso e' iniziato proprio perche' ho chiesto di leggere la pillola a riguardo, ma per ora mi e' stata proposta solo la soluzione "width fissa".

Inoltre ti pregherei di smetterla con questo tono accondiscendente di superiorita'. Di sicuro non siamo d'accordo su alcuni punti ma mi sembra di esprimere le mie idee chiaramente cercando basi tecniche a supporto. Sto parlando in modo civile, non insulto ne' prendo in giro nessuno. Gradirei che il tuo tono si adattasse, solo perche' non sono d'accordo con te non devo essere trattato come un idiota che non vuole ascoltare. Tanto piu' che sei un moderatore.

Se vuoi continuare la discussione sulle tecniche, sono felice di apprendere cose che non conosco. Se pensi di continuare sulla linea di "ma che a te non interesseranno immagino" dimmelo subito che la finiamo qui.

[ricman]

Originariamente inviato da k.b
dico solo che una singola tabella non e' sinonimo di layout fatto da schifo.

Ma di semantica non rispettata SI.
Quindi fossi l'azienda che cerca personale serio ed avessi mille persone e un posto di lavoro avrei scartato colui che che usa UNA tabella per dare struttura al layout

Originariamente inviato da k.b
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

Questa è una tua congettura... Inoltre se non si sanno fare i siti non vengono validati neanche con la struttura "a Div". Inoltre se non si ha il concetto di semantica il sito può essere validato ma non corretto (e qui la grande azienda scarterebbe un sacco di persone!!)

Originariamente inviato da k.b
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.

E' peggio lavorare coi paraocchi!! Progettiamo meglio i nostri siti e non avremo bisogno nè di tag buttati caso nè di hack...
(riguardo a IE6 un mesetto fa la M$ ha dichiarato che si può abbandonare... quindi sei coperto)

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

Sono d'accordo.
Altre persone che non sono sarebbero assunte...
Non sono in grado di progettare un sito!!


Vedo che state andandando sui minicasi particolari e sfide che reputo inutili ...
Progettare, progettare, progettare bene... sta tutto qui... Sia esso un form sia che un sito che qualsiasi altra cosa...

[fcaldera]

Originariamente inviato da k.b
Certo che mi interessano! Anzi, il discorso e' iniziato proprio perche' ho chiesto di leggere la pillola a riguardo, ma per ora mi e' stata proposta solo la soluzione "width fissa".

Inoltre ti pregherei di smetterla con questo tono accondiscendente di superiorita'. Di sicuro non siamo d'accordo su alcuni punti ma mi sembra di esprimere le mie idee chiaramente cercando basi tecniche a supporto. Sto parlando in modo civile, non insulto ne' prendo in giro nessuno. Gradirei che il tuo tono si adattasse, solo perche' non sono d'accordo con te non devo essere trattato come un idiota che non vuole ascoltare. Tanto piu' che sei un moderatore.

Se vuoi continuare la discussione sulle tecniche, sono felice di apprendere cose che non conosco. Se pensi di continuare sulla linea di "ma che a te non interesseranno immagino" dimmelo subito che la finiamo qui.

nessuno sta usando un tono accondiscendente di superiorità, ma il tuo continuo mettersi sulla difensiva (senza che nessuno stia criticando te peraltro, ma solo una metodologia di sviluppo) ignorando di continuo il senso delle risposte che ti vengono date è davvero deprimente.

ti si sta facendo notare con esempi concreti la differenza di efficienza tra i due metodi e tu continui a sollevare come possibile falla, un problema comune che ritroveresti nelle tabelle ignorando (volutamente?) in toto i benefici che avresti da un altro possibile approccio. (per inciso potresti posizionare input e label con i posizionamenti relativi/assoluti se vuoi avere label larghe 100px come 5000px)

Per me quindi, delle due, o non hai volontà di confronto o ti mancano alcuni conoscienze pregresse per farlo in modo ottimale. il che dal mio punto di vista mi porta a considerare questo scambio di post un po' sterile.

Tuttavia se ho detto qualcosa che ti ha disturbato me ne dispiaccio.
ma io ho solo criticato in modo oggettivo un tipo di approccio e non te.

Infine, e poi termino la mia partecipazione, sei libero di continuare l'approccio che ritieni migliore per il tuo lavoro e la tua realtà.

Se per te quello è l'approccio migliore tanto meglio per tutti

[k.b]

Originariamente inviato da fcaldera
nessuno sta usando un tono accondiscendente di superiorità, ma il tuo continuo mettersi sulla difensiva (senza che nessuno stia criticando te peraltro, ma solo una metodologia di sviluppo) ignorando di continuo il senso delle risposte che ti vengono date è davvero deprimente.

ti si sta facendo notare con esempi concreti la differenza di effiecienza tra i due metodi e tu continui a sollevare come possibile falla, un problema comune che ritroveresti nelle tabelle ignorando (volutamente?) in toto i benefici che avresti da un altro possibile approccio. (per inciso potresti posizionare input e label con i posizionamenti relativi/assoluti se vuoi avere label larghe 100px come 5000px)

Per me quindi, delle due, o non hai volontà di confronto o ti mancano alcuni conoscienze pregresse per farlo in modo ottimale. il che dal mio punto di vista mi porta a considerare questo scambio di post un po' sterile.

Ma cosa sto ignorando? Tu mi stai proponendo i difetti dell'approccio table-based, che peraltro io ho riconosciuto e confermato. Per contro io sto dicendo quali - secondo me - sono i difetti dell'approccio "width fissa" (che a tutt'ora e' l'unico controesempio che mi e' stato fornito). Non ho detto che non va bene, non ho neanche detto che non lo uso (infatti l'ho usato spesso), dico solo che nessun sistema che io conosca (per l'allineamento di un form) e' esente da difetti.

Mi hai citato altre possibilita', le leggerei volentieri.

[Nillus]

Salve.

A parte le tensioni, ho trovato utile il thread, e ringrazio tutti della collaborazione, ognuno secondo le proprie idee.

Vorrei sottolineare che non è una guerra; qui non si dovrebbe cercare di avere ragione, ma di dialogare. A parte che si era partiti da una valutazione di impiego computazionale di resa dei browser per div o tabelle, ma in ogni caso la discussione, comunque interessante, sarebbe più piacevole senza contrasti che rischiano di sfociare in guerre ideologiche.

La domanda è: table nidificate sono più lente da rendere di div multipli nidificati, a parità di perfezione di metodo e di bravuza dell'autore del sito?

E' chiaro che l'uso delle table è sbagliato per rendere layout, sia per il principio di separazione citato, sia per l'uso per il quale le tables nacquero. Fino ai CSS non c'erano alternative alcune alle tables e quindi queste trovarono il loro principale uso nella creazione di layout, contro e oltre il loro "scopo".

Andando oltre nell'OT, tanto ormai... Scendiamo nella pratica

Vorrei porre una domanda, da non molto esperto autore di situcci web quale sono, ad ognuno dei due sostenitori di layout, a table o a div, riguardo ad un sito che mi è stato "ordinato".
Il sito vuole una serie di informazioni disposte su due colonne, una a sinistra a sfondo giallo, l'altra a destra di sfondo azzurrino. La colonna a sinistra è più piccola di larghezza, e i contenuti debbono essere disposti su righe come le celle di una tabella (l'originale è una tabella di word che devo rendere online); non è detto che l'informazione di una riga a sinistra sia più piccola di quella a destra o viceversa, vale a dire, ci sono righe con la cella a sinistra con più contenuto e altre con maggior contenuto a destra.
Nota: i contenuti possono essere anche importanti: testi anche lunghi, formattati, immagini... per cui da specifica usare una table è sbagliato.
Questo mi comporta con i div due problemi dovuti temo alla mia inesperienza (sto riprendendo ora il web in mano, anche io progettavo a tabelle quando ero più operativo nel settore!): il primo è che due colonne fatte con due div float separate semplici non vanno bene, perché non ho modo di "sincronizzare" i contenuti delle righe di destra con quelli di sinistra.
Allora creerei un div per ogni riga, con annidati un div per la colonna di sinistra e uno per quella di destra stilati a float; ora però il div contenitore non si estende alla lunghezza della maggiore delle due colonne adattandosi, per cui devo inserire un div vuoto clear:both, che secondo me è una porcata ma non so come fare.
Anche ora però le celle sinistra e destra mantengono il loro sfondo solo per la lunghezza del contenuto; stilare width:100% non le fa estendere per tutto il div contenitore, ovviamente, perché float estrapola i due div dal flusso dati.
Allora, di riga in riga, devo usare un contenitore div con lo sfondo del colore dello sfondo della colonna che viene più corta, a seconda di quale essa sia.

Chiaro, con la tabella non avevo problemi, faceva tutto da solo, bastava dare il colore alle colonne, fissare la loro larghezza e lasciare che il browser scalasse da solo i contenuti. Con i div, per me che non sono più tanto esperto del settore, ammesso che lo sia mai stato (!!!), ora mi trovo in difficoltà perché per ottenere lo stesso effetto sono stato costretto a introdurre due sporcizie nel codice: il div vuoto e un div contenitore diversificato a seconda dei contenuti; la prima lede la chiarezza e minimalità del codice, la seconda annienta la separazione.

Potrebbe essere questo un caso in cui il layout a tabelle è più semplice e forse migliore di quello a div o semplicemente io non sono capace di utilizzare al meglio i div e i CSS? Potreste propormi soluzioni a div+CSS migliori?