Newsgroup: it.comp.www.html
Titolo: div  vs  tabelle

Salve a tutti,
ho assistito all'università ad una lezione sull'accessibilità dei
siti web dove veniva più volte rimarcata l'importanza dell'utilizzo
dei tag div al posto delle tabelle per la realizzazione della struttura
delle pagine in quanto le tabelle impediscono agli screen reader una
lettura efficace.
Io mi ci sono messo di impegno ma, abituato come sono ad utilizzare le
tabelle, ottenere lo stesso risultato con i div mi è sembrato troppo
dispendioso in termini di tempo e di pazienza quindi ho rinunciato.
Qualcuno di voi sarebbe così gentile da mostrarmi come convertire in
un formato accessibile e xhmtl-conforme una pagina fatta con le
tabelle?
L'ultimo sito l'ho fatto completamente con le tabelle
www.autoscuoladeimille.it
Date un'occhiata.
Grazie mille.
Saluti
Stefano

 ha scritto nel messaggio 
news:1120385773....@g14g2000cwa.googlegroups.com...

Anche io, abituato con le tabelle pensavo fosse una cosa complicata, invece 
è molto più semplice di quanto possa sembrare.
Il principio è questo.
All'interno di un div te definisci quello che sarà il contenuto della 
pagina. Attraverso i css, darai forma a questo div.
Per rendere l'idea, prendi pure un foglio di carta, e traccia un rettangolo, 
questo rettangolo sarà un div, poi traccia un altro rettangolo e avrai un 
altro div e cosi via.
quello che metti dentro il rettangolo è il contenuto del div.
Nel css definisci le proprietà di questo rettangolo, gli stili e via 
dicendo.
La parte diciamo più complicata è dovuta essenzialmente a collegare in modo 
opportuno fra di loro questi div, e in questo caso intervengono le proprietà 
float e clear.
Per chi ha iniziato con le tabelle, sicuramente la via più flessibile è 
associare ogni cella di questa tabella a un div.
Con l'esperienza e la pratica ci si renderà conto da soli che molto può 
essere ottimizzato, annidando uno  o piu div fra di loro etc.
-- 
BlueWare WebStudio
  [Internet:] 
http://www.blueware.it
  [icq:] 146-781-935
  [msn:] 
coo...@blueware.it
 


robiweb90 [at] gmail [dot] com
"Nessuno può fabbricare una macchina tanto intelligente che possa essere 
usata da uno sciocco" - Confucio

Esprimo un parere personalissimo:
Uso spesso screen reader e non mi pare che una interfaccia 
"header-menu-content-footer" dia tutti questi "problemi di leggibilità" se 
costruita con tabelle. Semmai i vantaggi dei livelli+css sono legati alla 
logica degli elementi ed al loro corretto utilizzo, alla possibilità di fare 
leggere allo SR prima i contenuti e poi se si vuole il "solito" menù, alla 
maggiore leggerezza della singola pagina (certo una marea di thead, table, 
td, th, tr ecc.... danno peso al foglio), alla migliore separazione tra 
forma e contenuto. Nella lezione a cui hai assistito manca un punto che tu 
non hai citato e cioè "perchè" una interfaccia a div è migliore di una 
tabellare. Cito di seguito un articolo che condivido quasi in toto:
Quello che vorreste sapere ma che pochi hanno il coraggio di dirvi...
Se seguite poco questo tipo di problematiche, potreste restare stupiti del 
furore iconoclasta che ha colpito negli ultimi mesi l'idea di progettare con 
un layout basato a tabelle, come si è sempre fatto. La cosa nasce con i 
migliori intenti: quello di fare finalmente un pó di ordine nella produzione 
di pagine web, applicando degli standard a livello di codice, i quali non 
sono però privi di una componente ideologica (o idealista, se preferite).
La vittima più illustre è uno strumento molto usato per l'impaginazione: la 
tabella. La sua messa al bando deriva dal fatto che è stata progettata per 
contenere dati e non per strutturare lay out, e tale deve ritornare ad 
essere.
A dire il vero, gli standard (x)html anche "strict", non deprecano 
quest'uso, che viene sconsigliato solo nelle WCAG (linee guida per 
l'accessibilità). Però in rete c'è questa convizione e devo ammettere che lo 
credevo anch'io, tanta è la "propaganda" in tal senso e tanti i siti in cui 
trovate anatemi al riguardo.
In realtà si può continuare ad usarla, senza per questo sentirsi né un 
pirata del codice né un progettista vagamente demodé :-)
Si stanno diffondendo molti pregiudizi nei confronti delle tabelle come 
strumento di lay out, che rimbalzano da un sito all'altro... vediamo cosa 
dicono e perché sono, appunto, dei pregiudizi.
Da dove nascono i pregiudizi
Le pagine che tutti noi facevano fino a pochi anni (mesi?) fa usavano molte 
tabelle e tabelline nidificate, e tutte le istruzioni riguardanti colori, 
font, fili e visualizzazione in genere venivano inserite all'interno della 
pagina html.
Questo produceva un codice piuttosto pesante e, se non si usava molta 
attenzione, anche "sporco" e non di rado con istruzioni "illegali".
Inoltre per generarlo si sono usati (e si usano tuttora) editor visuali, la 
maggior parte dei quali davvero pessimi. Se chi li usava non aveva 
competenze html, inoltre, gli errori e i kb aumentavano ancora.
Ovvio che questo tipo di codice sia deprecabile e che una pulitura ottenga 
ottimi risultati comunque.
Su web trovate (in italiano e in inglese) numerose pagine che segnalano pro 
e contro di una progettazione a tabelle e di una progettazione tableless... 
ovviamente a favore di quest'ultima. Sappiate però che il codice sporco, 
ridondante e impreciso non è "colpa" delle tabelle, ma solo del modo in cui 
sono state usate. Si possono fare pagine altrettanto sporche e ridondanti (e 
ben più rischiose) anche usando un'impaginazione basata sui CSS.
Pregiudizio n.1
Impaginare con le tabelle aumenta a dismisura il peso delle pagine
Semplicemente non è vero: usando correttamente un codice standard (x)html 
transitional, tutto quello che dovete scrivere, in più, è nella maggior 
parte dei casi:
<table>
<tr><td colspan="3"></td></tr>
<tr><td></td><td></td><td></td></tr>
<tr><td colspan="3"></td></tr>
</table>
Eliminare queste istruzioni certo non farà risparmiare giga e giga di banda. 
In pratica non fa nemmeno risparmiare bytes... visto che comunque le 
suddivisioni della pagina vanno indicate con dei <div>. Alla prova dei fatti 
il peso è sostanzialmente uguale.
Pregiudizio n.2
Maggior lavoro di manutenzione
Se si affidano tutte le istruzioni di visualizzazione a un CSS, è ovvio che 
il lavoro di manutenzione è identico: in entrambi i casi cambiare il colore 
dei link, piuttosto che quello del fondo e la dimensione di un bordo, si fa 
in entrambi i casi dal CSS (cioè modificando un unico file per tutto il 
sito).
Se si parla di una modifica sostanziale del layout, invece, teoricamente coi 
CSS è possibile (semplicemente cambiando le istruzioni di posizionamento) 
mentre con le tabelle è proprio impossibile.
Quello che nessuno evidenzia, però è che, a meno di modifiche semplici su di 
un layout semplice, questa possibilità è in pratica molto limitata dalla 
impostazione iniziale dei vostri file tableless.
Se voi non prevedete in fase di progettazione queste possibilità, infatti, 
non crediate di poter ri-disporre gli elementi come più vi piace. Questo è 
possibile solo se costruite layout come puzzle (cioè bloccati in tutto e per 
tutto, con larghezza, altezza, posizione strettamente assegnata). In questo 
caso, potrete successivamente ricomporre il vostro puzzle diversamente. Ma 
non pensiate di poter passare, per esempio, da un layout di questo tipo ad 
uno fluido... Una parte concettualmente non trascurabile della costruzione 
del layout "abita" tuttora nei files (x)html.
Pregiudizio n.3
Le table si fanno con gli editor visuali che producono un cattivo codice
Cattive notizie per chi spera di eliminare, insieme alle tabelle, anche i 
progettisti che non sanno il codice. Con gli editor visuali è possibile fare 
anche pagine coi CSS, posizionandoli in modo estremamente rigido e 
controllato: il sogno di tutti i web designer frettolosi e con pochi skill..
Il risultato, tra l'altro, non è meno stabile di quanto si ottenga 
progettando correttamente.
Un buon editor visuale ben usato, invece, fa risparmiare molto tempo ed 
evita molti errori di distrazione e di digitazione. Questo non risparmia, 
ovviamente, di lavorare "anche" sul codice, come non lo ha mai evitato, se 
si punta a una produzione di qualità.
Vantaggi delle tabelle (qui e ora)
Assicurano una maggiore stabilità di visualizzazione, non tanto con Netscape 
4 (che comunque visualizza malissimo anche un codice transitional "spinto"), 
ma proprio con i browser cosiddetti standard.
Questo è utile sempre, ma diventa un must se dovete inserire nella pagina 
una o più tabelle dati. Queste, infatti, continuano a comportarsi come 
tabelle (cioè a preservare il contenuto e quindi ad allargarsi se il 
contenuto lo richiede) e interferiscono molto male con il resto del layout 
di pagina. Gli strumenti di controllo dell'impaginazione tableless, infatti, 
non si allargano per nulla, e vi troverete in presenza di inaccettabili 
sovrapposizioni (la tabella che fa a finire sopra o sotto la colonna che le 
sta a lato). Questo non vi succederà mai, se la base del layout è un'altra 
tabella, perché la logica di comportamento è analoga.
Vantaggi di un editor "anche" visuale (ora et in secula seculorum)
Scrivere il codice col notepad senza sbagliare è senz'altro la prova che lo 
si conosce bene. Ma io credo che noi facciamo siti, non codice, e che 
scrivere 28 volte <h3 class="vattelapesca"> non sia un lavoro adatto agli 
umani. È provato che compiti ripetivi vengono svolti molto meglio dalle 
macchine che da noi. E in effetti, normalmente il codice scritto col notepad 
è zeppo di errori, a meno che non si stabilisca un processo di controllo e 
correzione (che comunque dovrebbe esserci, a prescindere dal modo in cui si 
genera il codice).
Che sia necessario sapere il codice è fuori discussione: l'editor visuale 
non deve essere una stampella per chi ha conoscenze zoppicanti. È 
semplicemente uno strumento per velocizzare la produzione e i controlli 
successivi.
Ovviamente è necessario usare un buon editor, in maniera corretta, e passare 
quasi continuamente dalla modalità visuale alla modalità "sorgente".
Io personalmente uso Golive 6 di Adobe, perché è molto pulito.
In un prossimo articolo, spiego come usarlo bene anche per una progettazione 
tableless (se proprio ci tenete :-).

 quasi continuamente dalla modalità visuale alla modalità "sorgente".
E sperare che il tuo editor visuale supporti almeno il code-keeping
senza perderlo, cosi` io (programmatore PHP) posso passarti i template
su cui tu (grafico) puoi lavorare senza farmi impazzire.
Se non fa nemmeno questo e` un editor da buttare.
Bye.

ecc. ecc. e` tutta un'altra cosa.
A proposito di questo me ne consiglieresti uno?
Saluti. 

la macchina: un linguaggio server-side, non un editor visuale.
Concordo pienamente!
Inutile e perditempo scrivere a mano ciň che puň essere automatizzato.
Indubbio, poi, che il codice vada riletto e sistemato per questioni di
ottimizzazione e personalizzazione. 
--
-Diego (Atos)-
-L'uomo č superiore agli animali-
-Fanno eccezione il nano e la giraffa-
-A.Bergonzoni-
-Per rispondere in privato potare "POTA" dall'indirizzo-



Per Linux finche' vuoi (anjuta, glimmer, kate, emacs, vi, ...)
Per Windows non saprei, sorry.
Bye.

Alessandro Pellizzari ha scritto:

Per Windows SciTE! I love SciTE!
