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).

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.

Spesso molti presunti bug dei browser non sono altro che regole di stile sbagliate che il browser ignora. 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. I bug di IE6 e 7, notissimi, sono tipiche violazioni delle specifiche.

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. 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.