divitis, tagitis, classitis e altre malattie del Web design: come prevenirle?
Da dove vengono queste malattie, e perché si propagano in modo virulento? Uno dei motivi è senza dubbio il tentativo di replicare layout grafici anche molto elaborati con gli strumenti disponibili sul Web, ovvero markup e CSS.
Il designer crea il suo progetto, con Photoshop, Fireworks o lo strumento grafico disponibile, e poi lo riporta in HTML per pubblicarlo sul Web. Una volta, tanti anni fa in un’epoca remota, l’immagine sarebbe stata ritagliata in tante fettine da porre in una bella tabella di layout per riassemblarle. Ora questa tecnica non è più di moda, e si replica il layout sostituendo le celle delle tabelle con tanti bei div, ognuno dotato di una classe CSS che con tanto tira e molla viene posizionato opportunamente.
Completare il puzzle è un bel pasticcio, sembra che quando un div va a posto gli altri impazziscono e si spostano a tradimento. E via a colpi di margin, padding, posizionamenti di qualsiasi tipo, float e altre amenità. Poi, provi in un paio di browser e ti accorgi che si disfa tutto. A questo punto il designer, esausto, comincia a consultare San Google o qualche amico più esperto per risolvere uno o più degli innumerevoli bug dei browser.
Dopo un po’, aggiungi qualche altro div di qui e di là, sposta tira e spingi, fiuuu, regge.
Non penso di essere tanto lontano dalla realtà, anche se sembra buffo.
Perché succede tutto questo? Un problema è rappresentato dal mancato completo supporto di CSS da parte dei browser, però questo aspetto per fortuna con il passare del tempo e gli aggiornamenti si è attenuato.
Credo però che una delle cause più sottovalutate di queste difficoltà sia rappresentata da quello che viene chiamato il foglio di stile di default. Secondo CSS 2.1, i browser dovrebbero utilizzare come regole di base quelle contenute nel “Default style sheet for HTML 4“, in modo che anche in assenza di un foglio di stile creato dall’autore della pagina gli elementi vengano presentati nel browser secondo certi criteri.
Però, come al solito, i produttori di browser hanno dotato i propri browser di regole non completamente standard e piuttosto personalizzate, ed ecco spiegato perché, per esempio, per sistemare un elenco puntato o numerato bisogna fare i salti mortali e il browser sembra agire per moto proprio invece che seguire le regole così faticosamente scritte dall’autore. Che succede? Basta dare un’occhiata ai fogli di stile predefiniti dei browser.
Per Firefox, date un’occhiata nella cartella res del programma: troverete diversi CSS, osservate html.css e form.css: queste sono le regole di visualizzazione predefinite per Firefox. Per Safari, il foglio di stile di default è quello di Webkit. Per Explorer, non si sa, è compilato in qualche libreria. Per un’analisi approfondita, leggete “User Agent Style Sheets: Basics and Samples” di Jens Meiert, che si è divertito (?) in uno studio interessante.
Dopo aver passato un po’ di tempo a vedere le differenze (sì, differenze) fra i vari fogli di stile di default, saranno molto più chiari i motivi per i quali i layout sembrano comportarsi in modo bizzarro, e perché tutti quei div, span e liti con margin, padding e float alla fin fine potevano essere evitati.
Basta usare un “Reset CSS”, per esempio quello proposto da Eric Meyer, per riportare a una condizione di partenza pulita qualsiasi browser (però, approfondite anche pro e contro). Già che ci siete, provate a usare anche il Diagnostic CSS. Tenete a portata di mano la legenda e osservate le vostre pagine1.
Sono certo che dopo un bel reset tutto sarà più pulito e chiaro, e ne basteranno molti di meno di quei div… (grazie a MetalSho per lo spunto). O almeno, quelli che ci sono forse avranno un motivo di esserci.
Un’altra spiegazione per la divitis potrebbe essere il non aver compreso il posizionamento con CSS, il cosidetto CSS-P. Lo sapete, vero, che non c’è bisogno di div per posizionare un elemento e che le stesse regole applicate al div funzionano pari pari anche se applicate direttamente all’elemento che avete racchiuso in quell’inutile, prolisso div? Qualche volta mi viene il dubbio.
- Basta caricare il CSS come foglio di stile utente: intorno agli elementi compariranno i box colorati definiti nel Diagnostic CSS per evidenziare gli errori più comuni. ↑
9 Responses to “divitis, tagitis, classitis e altre malattie del Web design: come prevenirle?”
mitico.
come mai hai ricambiato tema? era molto bello quello di prima
perché ci devo lavorare un po’ e sono affezionato a questo un po’ ciabattone
Ottimo articolo… un utilissimo approfondimento al precedente. Complimenti
PS: a me piace parecchio questo tema
Una splendida base di partenza, dopo il salvifico reset, è anche 960 Grid System: basta aggiungere degli ‘id’ un minimo semantici al framework fornito e avrete una griglia e una struttura di impaginazione (con i div che servono e basta) pronta per essere stilizzata con un po’ di selettori discendenti.
Vero Paolo, anche se un po’ troppo tipografico nel naming. Comunque già il reset può essere uno shock.
Molto tipografico nel naming, vero, ma hanno intelligentemente usato ‘class’: per cui si può recuperare semantica nell’id’ oppure aggiungendo altri nomi di classi.
Fammi vedere il link dello shock che sono curioso.
Veramente colpito dalla qualità di questi tuoi articoli! Hai un metodo di scrittura che mi piace veramente molto!
[...] divitis, tagitis, classitis e altre malattie del Web design: come prevenirle? [...]
[...] Un post di Livio Mondini mi ha ispirato hAtomGrid (file ZIP, 40KB), un tema o meglio un wireframe per WordPress che, oltre a ridurre al minimo indispensabile i div, integra il microformat hAtom per la struttura XHTML dei post e 960 Grid System per l’impaginazione: [...]