ITcms ver. 2.0.01
Realizzazione Sito
Soli 100€!!!
SkinIT
Le skin per ITcms
Tabelle vs Accessibilità
Elenco Documenti Stampa
TITOLO ORIGINALE:
Giù le mani dalle tabelle :-)
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 po' 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:
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
. 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 voltenon sia un lavoro adatto agli umani. E' 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).
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
