Tabelle, xhtml, css, W3c, standard e l’evoluzione del web
Torniamo sull’argomento, visto che è stato eviscerato in una recente discussione proprio su queste pagine. In questi giorni mi è capitato di parlare almeno con un paio di persone sul perchè si usano le tabelle, perchè alcuni le odiano, perchè altri continuano ad usarle…
Vi segnalo un paio di articoli in cui ne abbiamo parlato in passato:
ma forse è stato tralasciato un piccolo grande dettaglio.
La questione è: ragazzi, esiste un consorzio, chiamato W3C (World Wide Web Consortium) che ha dettato degli standard, perchè non dobbiamo seguirli?
Il W3C: cos’è?
Come già detto è un consorzio, un’associazione che cerca di definire degli standard e permettere al web di essere sfruttato e fruibile al 100% delle sue potenzialità. Lo dice il suo stesso sottotitolo!
Forse per alcuni può essere un po’ più utile visitare il sito dell’Ufficio Italiano del W3C, dove alcuni meccanismi possono essere più chiari. Ad esempio da chi è composto: associazioni, università, fondazioni universitarie, ministeri, ma anche e soprattutto società dei campi delle telecomunicazioni e informatica, ma anche no. Chiunque, insomma, possa avere una voce in capitolo al fine di rendere il web qualcosa di veramente universale e fruibile.
Come nasce e perchè
Il W3C è stato fondato dal papà del web così come lo intendiamo oggi, il signor Tim Berners-Lee, nel 1994 (!).
Ecco perchè, checchè se ne vantino certi professionisti, che dicono di aver cominciato con un Commodore 64 negli anni 80, se non si aggiornano ovviamente rimarranno sempre indietro e al modo di fare web pre-’94.
Gli interessi per il mondo del web prima del 94 erano dettati da opposti estremi: da un lato la ricerca, la scoperta di nuovi strumenti, dall’altro gli interessi delle sotware house (prima fra tutte la Microsoft) che hanno creato dei browser con linguaggio proprietario e che facevano un po’ quel cavolo che volevano. Con feature carine, per carità, (vedi le barre scorrevoli colorate di explorer), ma completamente fuori standard.
Ed ecco anche perchè si è voluto che certe società facessero parte del W3C: sia per rendere uniforme la fruibilità del web secondo certi standard, sia perchè le stesse società erano interessate a capire come superare la concorrenza, scoprendo poi che il miglior modo per farlo, ad oggi, è rendere il proprio browser compatibile al 100% con questi standard e non andare ad inventarsi cose nuove e non compatibili.
Da qui la grande indignazione nei confronti di Internet Explorer 6, che uscito nel 2001, a distanza quindi di due anni dalle specification dell’html 4.01, dava ancora segni di incompatibilità profonda. Figuriamoci con l’attuale xhtml 1! E non parliamo di Netscape, che fino alla versione 4, presente fino al 2002, non supportava nemmeno i css. Per fortuna questo secondo browser è stato soppiantato completamente, mentre il primo è usato ancora da una buona fetta di utenti, pertanto non da ignorare nei test di compatibilità (ahimè).
Tabelle sì, tabelle no
Detto ciò risulta molto più semplice capire perchè le tabelle non si devono usare per creare i layout: semplicemente perchè non hanno quello scopo. Le tabelle servono infatti a contenere dati e l’uso che ne facciamo è spesso non corretto, poichè non vengono spesso evidenziati headers e altre proprietà intrinseche e necessarie.
L’uso improprio delle tabelle nasce antecedentemente al 1994 appunto, anni cioè in cui gli sviluppatori del web erano principalmente anche programmatori e trovavano l’uso delle tabelle molto pratico per impaginare i contenuti. Per carità, era lecito e anche una soluzione piuttosto intelligente visto il poco supporto dei browser di allora.
Ad oggi però sono stati definiti degli standard, e con grande fatica; inoltre abbiamo dei browser che per fortuna supportano i css, persino i browser per i cellulari, pertanto perchè non imparare ad usare xhml+css nel modo corretto definito dal W3C già da diverso tempo? Capisco le difficoltà, ci sono passata anche io, ma una volta imparato il lavoro si velocizza non poco, e già in passato ho elencato i vantaggi dei css.
Chi si ostina a non usare i css pertanto sono solo programmatori che sanno fare benissimo il loro lavoro, ma non sanno fare i webdesigner e (giustamente!) non hanno tempo da perdere per imparare ad usare i css. Noi webdesigner invece non abbiamo scusanti, è il nostro lavoro, perciò tiriamo tutti fuori la testa dalla sabbia e per favore usiamo sti benedetti css. D’accoooordoooo?!?!? 
L'Autore
Laura Gargiulo, webdesigner freelance. Web architect senior, esperta xhtml, css, usabilità, design, cms, webmarketing e Seo, Wordpress specialist. Membro del progetto di prossima pubblicazione Piperita Lab e dell'IWA Italy Visita il mio sito personale Lauryn.it e contattami pure per un preventivo gratuito.
Add to Google
32 Commenti
Si è vero che bisogna utilizzare i css, ma penso che se microsoft si adeguasse con i suoi browser agli standard molta più gente userebbe i css.
La penso anch’io come Filippo, il problema è Microsoft, anche se molti comunque stanno incominciando ad abbandonare la compatibilità di IE6. Poi dipende molto a chi ci si rivolge, per un sito istituzionale, ad esempio, la compatibilità aIE6 non va tralasciata assolutamente.
Comunque bell’articolo Lauryn e grazie per gli approfondimenti!
Microsoft con le nuove versioni 7 e forse anche 8 si è adeguata…è la 6 il dilemma di tutti, ma nn per questo non bisogna imparare i css.
Rendiamoci conto: un programmatore impara il php da un manuale, noi l’html dalle specifiche del w3c che sono state ponderate nonostante i difetti dei browser (tra l’altro superabili, non è che i bug di ie6 sono insuperabili, è che sono pallosi…). Perchè “inventarci” un nuovo web?
Domanda da non professionista del web, mi occupo di altro: esiste un editor html (WYSIWYG) che scriva codice conforme agli standard? O che quantomeno si avvicina?
So che sarebbe meglio imparare il codice, ma come ho già scritto non è il mio mestiere e non avrei davvero il tempo.
Quell’immagine con i 12 layout da dove l’hai presa?
@Flavio, da quello che ho visto iWeb del mac lo fa. Dreamweaver forse potrebbe anche avvicinarsi…
Grazie Lauryn per l’articolo molto esauriente, capisco ora perchè mi ostinavo ad usare le tabelle, vedi io nasco come programmatore in effetti e solo ora mi sono affiancato al web design, ma devo dire che da quella bella discussione mi sono messo sotto per studiare per bene i css=)…so che ci vorrà un pò prima di usarli correttamente, ma mi sto impegnando…e spero presto di fare un buon lavoro. una domanda:dovendo fare un sito dove mettere le anteprime di alcune foto, in quel caso posso usare le tabelle oppure?
Ottimo articolo. Immaginate un lettore di schermo che deve leggere 3 tabelle annidate con colonne e righe asimmetriche senza summary nè caption e senza tabindex….un massacro. Meno male che esistono i CSS!!
Sono d’accordo con quello che è stato detto, in particolare le tabelle vanno usate per rappresentare dati, ma non è vero che i programmatori non conoscono il w3c o non sanno usare i css, altrimenti non esisterebbero neanche i cms! Più che altro…non si preoccupano del colore, del bordo,del positionamento, del background di un tag, ma il programmatore dovrebbe sapere…se certi dati, magari letti da un database, andrebbero “sputati fuori dal codice” dentro un table piuttosto che un div . no?!?!?
@Flavio: Dreamweaver 8. definisci all’inizio che tipo di xhtml usare e ti corregge lui stesso
@Brucee: appena lo trovo lo scrivo, tra l’altro è molto utile perchè ci sono layout già pronti da scaricare in css
@roberto paris: grande, quanti ne vorrei di commenti come i tuoi! anche per gestire le gallery si usano i div, ma magari è una cosa già più difficile da gestire inizialmente…qualche tabellina di aiuto per ora te la concediamo
(scherzo 
)
@antonio2: esatto! il discorso sarebbe molto più ampio!
@giancarlo: purtroppo molti programmatori ignorano l’esistenza del W3C…conoscono solo il manuale di php o quel che è ahah
basta che guardi il portale del cms Xoops :S
Spesso, purtroppo, si tratta di pigrizia, sia per i programmatori che i web designer.
Molte volte chi lavora nel settore sì limita ad accontentare il cliente e a incassare senza tener conto dei vantaggi che un codice validato e semanticamente corretto può portare ad entrambi.
@Giuliano : Secondo me non si tratta di pigrizia…si tratta di costi. Se il cliente è disposto a coprire il maggior costo di un cms accessibile e usabile sviluppato ex-novo e su misura (attenzione ex-novo…non usando joombla, xoops, magento o qualunque altro cms pronto) lo si fa…se invece il cliente mira al risparmio…mica l’azienda fa beneficienza..o si lascia scappare il cliente che si accontenta di poco. In più l’usabilità ( e non l’accessibilità) è un costo aggiuntivo.
L’accessibilità e il cross browsing invece sono parte integrante del lavoro.
Pensate a dinamicizzare in php i tag accesskey e tabindex…in modo tale, che aggiungendo o rimuovendo dinamicamente dei link dal pannello di amministrazione, questi link contengano sempre i corretti valori nei loro attributi. E’ o non è tempo da perdere nella programmazione…e quindi un costo che il cliente deve sostenere?
un articolo sulle tabelle? nel 2009?
buh, pensavo che dopo dieci anni la questione fosse, come dire, superata.
@giancarlo: lascia il fatto del dinamico, quello si paga, ovvio. ma inserire un paio di accesskey e un tabindex non fa male alla manina…è proprio questo che dobbiamo sfatare. un sito ACCESSIBILE e USABILE nondeve avere dei costi in più. deve essere il nostro normale modus operandi!!
quando vi entrerà in testa?
Vero, pero spesso il cliente vuole avere un prodotto in tempi rapidi, e non sa nemmeno cosa sia l’usabilita o l’accessibilita. Pensa che tutti abbiano javascript, i browser siano tutti uguali e via dicendo. Purtroppo sappiamo che non e’ cosi
Comunque bell’articolo.
Max (7 comments) 4 marzo 2009 alle 09:51
@Flavio, da quello che ho visto iWeb del mac lo fa. Dreamweaver forse potrebbe anche avvicinarsi…
————————————–
paragonare iWeb a Dreamweaver…ragazzi su siamo seri perché questo è un blog serio.
@Luca: se il cliente non è informato è nostro compito istruirlo. Se non lo facciamo noi che siamo a stretto contatto con l’usabilita e l’accessibilità difficilmente lo farà qualcun altro.
@giuliano: esatto, tocca a noi. e poi a forza di riperterlo risulteremo anche più convincenti no?
Vero, dobbiamo informarlo, ma appena c’e’ la parvenza di allungare leggermente i tempi, o dover progettare un’interfaccia meno “cool”, spesso preferiscono chiudere un occhio su usabilita e accessibilita.
@luca: ma perchè dite che fare i siti con i css allunga i tempi? una volta imparato li accorcia e di molto. modificare in corso d’opera un sacco di cose ,ripensamenti del cliente etc è molto più veloce da fare con i css che con il vecchio “sistema” (chiamiamolo così)
@Lauryn: che significa aggiungere un paio di accesskey o tabindex? parlare di dinamicità conta e come!!! forse in un sito statico…con pochi link si può fare quello che dici tu (scrivere a manina qualche attributo in più nn fa male). Ma questi attributi andrebbero messi solo nel menu o in qualunque link? perchè le problematiche sono tante…esempio.. il commento che sto scrivendo in questo blog è il 18°…se ogni utente che lascia un messaggio qui mette il proprio url…e vorresti che ogni link sia “usabile”…dovresti tener conto che le lettere dell’alfabeto e le cifre sono finite…e che quindi per avere le accesskey funzionanti e univoche dovresti non solo automatizzare le accesskey in ogni pagina ma suddividere i commenti in più pagine. Cioè…in questo caso sarebbe l’usabilità a importi un certo tipo di programmazione, oltre al fatto che comunque è buona norma prevedere un massimo numero di messaggi per pagina, per motivi di velocità. Comunque io un sistema simile automatizzato l’ho realizzato, e sinceramente mi ha richiesto più tempo, perchè non si tratta di scrivere un accesskey…ma di pensare a come far funzionare l’automazione, anche per questi attributi, scrivendo funzioni e cercando di star attento alla sintassi che si intreccia tra html e php.
Insomma…è tempo in più da perdere…e se dovessi fare un preventivo a qualcuno io lo farei in base al tempo che perdo.
@giancarlo: io capisco il perdere tempo…ma l’esempio che riporti è proprio una perdita di tempo, nel senso che non serve a niente avere 10.000 accesskey sparse per il sito se l’utente deve studiarsi una manfrina per ogni sito che naviga per sapere che tasti premere.
infatti non per questo gli accesskey sono un’usanza di accessibilità non strettamente necessaria se non per funzioni basilari.
basta inoltre usare solamente i tabindex per muoversi nella pagina…
insomma, in sintesi bisogna prima addentrarsi nell’accessibilità per poi addebitare effettivi costi per lavoro in più da fare…io stessa credo di non saperne abbastanza, ma quel poco che faccio per render accessibile un sito statico di poche pagine non vale un aggravio di costi esagerato.
per il resto hai ragione
Trovato!
http://www.intensivstation.ch/en/templates/
utilissimo per velocizzarsi
@Lauryn: non dico che scrivere con i CSS allunga i tempi, anzi. Ma dico che scrivere con i CSS non e’ sinonimo di usabilita e accessibilita, non totalmente almeno.
@luca: ovvio che no, ma chi ben comincia…
@Lauryn: d’accordissimo con te
@bu: commento 13 che era finito in spam: pensa te, anche io lo credevo…
Vorrei fare un ulteriore riflessione, che secondo me merita pari attenzione della “diatriba” programmatori-web designer…
Più volte mi sono scontrata con grafici, che di web non ne hanno proprio alba, che progettano bozze web assolutamente irriproducibili senza l’ausilio minimo di layout tabellari. Per fortuna queste cose non mi accadono più…avete presente quei layout con menù curvilinei, con i link messi a cerchio o a cornice proprio in mezzo alla pagina? Correvano gli anni.. beh direi inizi 2000, quindi non proprio mesozoico.
Voi direte, embè? si fa lo slicing con photoshop settando come opzioni di output “div” anzichè “table”…
Ok, ma se la quantità di div è uguale se non superiore alle righe di codice di una table? Allora siamo punto e a capo.
Il problema qui non è tanto usare tabelle o no, il problema è che si dovrebbe pensare che il web è ben diverso dalla carta stampata, non è una questione di programmatori o grafici, è una questione di capire una buona volta quali sono i principi di buon web design. Anche un grafico pubblicitario ha un suo “mestiere”, e questo non è quello del web designer, a meno di studi fatti in seguito, aggiornamento ecc…
La colpa è anche di molte piccole agenzie web che come grafica si affidano proprio ad agenzie publicitarie (che lavorano al 90% su carta stampata), per preparare bozze che poi il buon caro vecchio programmatore dovrà prepare in xhtml…capovolgendo così tra l’altro l’ordine delle fasi di creazione di un sito, dove la veste grafica è l’ultima cosa a cui pensare, e mescolando erroneamente le figure professionali che stanno dietro la realizzazione di un sito!
Chiaramente sono molti gli accorgimenti per rendere un sito pienamente accessibile (progettare un sito compliant a tutti i 22 requisiti Stanca non è affatto banale, così come renderlo WCAG AAA), ma si dovrebbe perlomeno garantire l’accesso alle risorse del sito alla più ampia gamma di utenti.
Apprezzo davvero i programmatori che si pongono i problemi di acessibilità in rapporto all’automazione, spesso il nocciolo della questione è proprio quello…
@Emanuele MTA: brrrr lungi da me anche l’estremo opposto dei grafici da stampa eheheh
loro poi non sanno neanche una riga di codice, per cui che vuoi che ne sappiano.
hai fatto bene a segnalare questa cosa, è curioso saperla per chi non ci si è mai imbattuto
fin dalla progettazione grafica bisogna avere in testa l’html
Ho letto con piacere questo articolo e se mi è permesso vorrei fare delle precisazioni:
- parlare di programmazione accessibile significa parlare sia di css (per la presentazione) che di corretto codice (per la renderizzazione dei contenuti. In effetti il D.M. 8 Luglio 2005 al requisito 1 dice chiaramente:
per chiunque desiderasse, link.
- per quanto riguarda il discorso Microsoft, da una parte posso garantire che tramite i commenti condizionali (quindi prevedendo un CSS per IE6) si possono creare siti senza differenze visibili tra i browser, dunque si può sopportare ancora IE6, anche se avanti con gli anni; di contro un discorso a parte va fatto per le tecnologie Microsoft.
ASP, C# e fratelli vari hanno dei controlli che renderizzano i contenuti di una pagina, a farla breve riproducono i contenuti di un database all’utente finale.
Questi elements di default inseriscono degli attibuti inline per gli elementi che creano e spesso non sono escludibili. Questo a mio avviso è il male di Microsoft, perché, come ben sapete, ciò che viene scritto inline (direttamente sul codice xhtml), venendo processato dopo, sostituisce quanto dichiarato nel css…
E’ bello leggere dilettanti allo sbaraglio tipo Lauryn ed Emanuela MTA. Gentili signorine purtroppo siete molto ma molto in errore. Alla base di ogni progetto di comunicazione – il media non ci interessa – c’e’ il concetto da comunicare, poi si cerca uno stilema indentificativo che leghi il concetto al marchio o al brand e solo a quel punto si elabora un progetto grafico specifico media per media. No Signore, non bisonga minimamente pensare al codice quando si progetta un sito internet, perche; se lo si fa’ si ottiene di riprodurre stilemi ovvi e scontati. A ben vedere il gap di comunicazione dei siti web e’ proprio questo, ecco perche’ sempre piu’ spesso si ricorre a soluzioni flash o si sente la necessita’ di sviluppare una versione HTML 5 sempre meno orientata alla Vostra, sbagliata e primitiva visione del problema. Un progetto grafico potente, funziona punto e basta, indipendentemente dal media, perche’ si fonda su una forza comunicativa intrinseca al progetto. Certamente un sito web non e’ un oggetto stampato’ l’immaterialita’ del primo confligge con la matericita’ del secondo. Lo stilema pensato per comunicare non dovrebbe confliggere con entrambi. Non confondiamo un progetto grafico confuso non supportato da un progetto di comunicazione con altro.
Saluti
tralascio sul “dilettanti allo sbaraglio” perchè è evidentemente una provocazione e faccio notare, caro Luca, che sei andato completamente fuori tema. E’ indubbio che ci deve essere alla base un progetto di comunicazione, qui si parlava di tecnicismi che evidentemente non conosci.
Saluti.