Consigli per il debugging CSS

Molto spesso i layout che creiamo non funzionano come sperato. Le cause sono molteplici e di solito ci si concentra su questo o quel browser, ma in realtà  i problemi che incontriamo dipendono più che altro dall'approccio che noi abbiamo al debugging CSS. In linea di massima, il debugging CSS dovrebbe essere impostato nel modo più neutrale possibile. Certo, il browser X necessita di quella regola speciale o di un hack, ma a parte questi casi specifici resta il fatto che in linea di massima i problemi possono sorgere in qualsiasi browser. Come fare?

Per prima cosa, occorre procedere per piccoli passi. L'errore più comune è quello di finire un layout, testarlo in un solo browser e poi rendersi conto che ci sono problemi in altri browser. Se il layout non è troppo complesso, possiamo anche in questa fase isolare la regola (o le regole) CSS che creano il problema e sistemarle. Ma se il layout è complesso, diventa difficile operare un tracking ed isolare le cause.

Quindi bisogna procedere a piccoli passi. Prima le regole di stile generale (e test su più browser), poi il posizionamento degli elementi e il loro dimensionamento (e test su più browser), poi la grafica e le immagini di sfondo (e test su più browser) e infine gli ultimi ritocchi (e test su più browser). Sembra lapalissiano, ma è certamente più semplice analizzare poche regole alla volta piuttosto che decine e decine di regole su centinaia di righe di codice.

Le regole di stile vanno analizzate per dichiarazione. Dobbiamo essere certi che la dichiarazione che stiamo analizzando non crei il problema da noi riscontrato. Se siamo in dubbio, usiamo i commenti CSS su quella dichiarazione e proviamo poi a modificarla. Se il problema è sparito, allora era un valore di una proprietà  la causa di tutto. Se il problema permane, commentiamo la dichiarazione e osserviamo il risultato senza modificarne i valori (in pratica la eliminiamo). Il problema è scomparso? Se si, allora era quella dichiarazione la causa. Altrimenti, passiamo alla dichiarazione successiva e ripetiamo la stessa operazione.

Una parte importante del debugging è la conoscenza della teoria. Spesso molti presunti bug dei browser non sono altro che regole di stile sbagliate che il browser ignora. Per esempio, il contenimento dei float non si ottiene specificando la proprietà  clear sull'elemento flottato, poiché questa combinazione ha l'unico scopo di impedire che altri elementi flottati si affianchino all'elemento corrente.

Un'altra causa di problemi sono gli errori di sintassi: ecco perché è fondamentale sapere sempre se il nostro CSS è valido. Spesso un punto e virgola, una virgola o uno spazio fuori posto possono far si non solo che il browser ignori una dichiarazione, ma addirittura un intera regola o un gruppo di regole. In questo caso la conoscenza della teoria è basilare, poiché se conosciamo la sintassi di una proprietà  evitiamo di cadere in questi errori.

E veniamo ai bug. In realtà  non esistono solo i bug nei browser, ma anche la loro differente interpretazione delle specifiche. Si tratta di differenze contemplate nelle specifiche, quando si afferma per esempio che i browser possono usare un loro algoritmo per il computo della larghezza automatica delle celle di una tabella. Un altro caso sono gli elementi dei form, che non sono contemplati nelle specifiche.

I bug, invece, sono violazioni delle specifiche. I bug di IE6 e 7, notissimi, sono tipiche violazioni delle specifiche. Per questi casi esiste un'ampia documentazione online, per esempio su Position Is Everything, Quirksmode e sul sito di Gerard Talbot.

Con IE il modo più indolore per gestire i suoi bug è quello di usare i commenti condizionali per dare a IE delle regole di stile per rimediare ai bug. Si tratta sicuramente di un metodo che mantiene il nostro CSS principale privo di hack e per questo motivo più semplice da gestire.

E per gli altri browser? Per Firefox, oltre alle risorse online rintracciabili con Google, esiste Bugzilla. La consultazione di questo bug tracker richiede un po' di pratica: occorre specificare la versione, il sistema operativo, il componente di Firefox incriminato e quindi navigare tra i thread.

Opera non dispone di un bug tracker come quello di Firefox, ma è possibile utilizzare i forum per gli sviluppatori messi a disposizione su Opera.com. Per Safari, il punto di partenza è sicuramente webkit.org, mentre per Chrome è il suo blog ufficiale.