Cross-Browser Debugging CSS

Questa settimana aiutavo Laura (una developer che lavora con me) a comprendere il debugging cross-browser, e ho voluto subito condividere il mio metodo.
Cross-Browser Debugging CSS

Specifiche sulla traduzione

Di seguito la traduzione dell’articolo “Cross-Browser Debugging CSS” di Nicole Sullivan.

Debuggin CSS Cross-browser

Questa settimana aiutavo Laura (una developer che lavora con me) a comprendere il debugging cross-browser, e ho voluto subito condividere il mio metodo.

Il primo paradigma è semplicemente:
Lavora con i CSS, non contro di loro.

Il CSS ha una sua logica di fondo e quando ci lavori, quando lavori con il flusso naturale di come il linguaggio CSS è pensato per essere utilizzato, ti renderai conto di incorrere in molti meno bug. Ho imparato il CSS leggendo le specifiche W3C, che è il motivo per cui ho cominciato a scrivere codice in base alla struttura del linguaggio stesso, ma in qualsiasi modo tu lo abbia imparato, puoi cogliere alcuni dei suoi punti principali.

Discrepanze tra browser moderni

La prima cosa che faccio è creare il codice per un buon browser sin dall’inizio. La nostra scelta ricade su Google Chrome, di base perché i suoi tool per lo sviluppo sono superiori. Quando qualche lavoro funziona su Chrome e ne sono soddisfatta, gli do uno sguardo in Safari o Firefox.

Se c’è discrepanza tra questi browser, è probabile che tu stia lavorando contro il CSS. Non provare a implementare hack per colmare le discrepanze fra i browser più avanzati. Il tuo obiettivo è capire perché ci sono interpretazioni diverse del codice. In genere c’è un’ottima ragione. Queste sono alcune cose che controllo se ho dei bug:

  • L’interpretazione HTML: hai dimenticato di chiudere un tag? Hai wrappato un elemento blocco con uno inline? Qualsiasi cosa finisca fuori standard sarà interpretata diversamente a seconda del browser.
  • Avvia il tuo CSS con CSS Lint. Ti darà una buona panoramica su qualsiasi errore ti possa essere sfuggito (ad esempio, un punto e virgola mancante). Quando si tratta di differenze di debug cross-browser, gli errori sono più interessanti degli avvisi.
  • Hai dimenticato di usare uno stylesheet Reset o Normalize e ti stai basando sui diversi stili di default per browser diversi.
  • Differenze nel supporto dei browser. Stai usando proprietà avanzate CSS3 o elementi HTML5? Controlla il supporto del browser per assicurarti che tutti i browser che ti interessano siano coperti (quirksmode è dove di solito controllo questo aspetto). Altrimenti puoi sempre usare le proprietà superelaborate, avrai solo bisogno di progettare alternative astute di ripiego per i browser più obsoleti. Ad esempio, bordi anziché ombre o forme quadrate anziché rotonde.
  • I margini non sono racchiusi correttamente. Se hai strani spazi in posti inaspettati, è probabile che i tuoi margini stiano collassando in modo sbagliato.
  • Hai creato un contesto di formattazione in un browser ma non in un altro. In genere succede se si usa con troppo zelo la proprietà zoom:1 per richiamare l’hasLayout in IE. L’hasLayout equivale essenzialmente ad un nuovo contesto di formattazione in browser più avanzati.
  • Usi position absolute senza impostare un offset orizzontale e verticale. Per questa ragione, l’elemento posizionato in absolute avrà la stessa posizione che avrebbe avuto se impostato come static. Comunque se provi a modificare i valori top, right, bottom o left l’elemento sarà improvvisamente posizionato rispetto al suo più prossimo elemento padre settato in relative.
  • Hai combinato tipi di display in modi inaspettati? Ad esempio, la documentazione non spiega ciò che accade quando un element table-cell è posizionato al fianco di un elemento flottante senza che sia presente un elemento con valore table-row o table nel mezzo. Questo non significa che non sia possible farlo, ma di sicuro significa che provandoci ti esponi a potenziali bug e avrai bisogno di più tempo per test cross-browser.
  • Il whitespace influisce sul layout? Quasi mai si desidera avere dipendenze da whitespace in relazione alla proprietà display CSS, ma a volte accade, in particolare con display inline, inline-block oppure con le immagini; questo perché hanno l’aspetto degli elementi block ma non si comportano allo stesso modo, a meno che non vengano impostati come display block.
  • Errori nell’arrotondare possono creare differenze nella visualizzazione. Tutti i layout e le griglie flessibili hanno a che fare con gli errori di arrotondamento, ciascun browser ha modi diversi per ridurre al minimo la visibilità di queste differenze.

Se non leggi il resto dell’articolo, leggi almeno i prossimi due paragrafi

La cosa più importante da tenere in mente è che l’errore di comportamento non è definito nella documentazione. Se vai fuori pista non puoi sapere cosa accadrà. È probabile che il comportamento sia diverso a seconda del browser. Se stai combinando proprietà strane (come i margini su un elemento inline), troverai differenze cross browser.

Display

Credo che il CSS sia come scegliere il proprio percorso. Quando hai fatto certe scelte, le altre diventano ovvie. Prima di tutto è necessario scegliere il valore della proprietà display da associare al nostro elemento, block, inline, inline-block, table. Una volta scelto, basta utilizzare l’insieme delle proprietà associate per modificare la visualizzazione dello stesso. Ad esempio

  • Gli elementi di livello blocco dovrebbero essere usati con margini, padding, altezza e larghezza. L’interlinea non è appropriata.
  • Gli elementi inline hanno interlinea e allineamento verticale e possono essere sensibili al whitespace. Margini, padding, altezze e larghezze non vanno bene.
  • Le tabelle hanno allineamento verticale e orizzontale e a volte possono comportarsi in modo strano se in una tabella hai un elemento ma non un altro(ad esempio, una riga senza una cella). I margini sono inappropriati per le righe e le celle. Il padding non va bene per tabelle e righe di tabella.

Se utilizzi l’insieme delle proprietà che si addicono naturalmente al tuo valore di display, avrai molti meno bug e differenze cross-browser.

Posizionamento

Se hai scelto display block, adesso devi scegliere il tuo meccanismo di posizionamento (gli altri in genere sono posizionati seguendo il normale flusso). Per i block puoi scegliere:

  • Float – porta gli elementi del tutto a destra o a sinistra. Se hai scelto il float, rendi l’elemento un block level: questo significa che un eventuale allineamento verticale o interlinea applicati in precedenza potrebbero non funzionare più.
  • Absolute – posiziona l’elemento in relazione al suo ancestor piu prossimo posizionato in relative. Ricorda che gli elementi in position absolute non provocano riposizionamenti nel flusso e non lo subiscono quando gli ancestor e i sibling vengono modificati. Questo è un punto di forza per le animazioni, ma può creare problemi di visualizzazione se usi troppi elementi in position absolute con contenuti che si aggiornano dinamicamente (l’esempio classico è quello delle estremità di un elemento che non si spostano quando viene aggiunto più contenuto al box).
  • Static – è il valore di default, questo è il modo per tornare ad avere un elemento standard nel flusso normale.
  • Fixed – posiziona un elemento relativamente al viewport. Si usa raramente.
  • Relative – perlopiù non influisce sul nodo al quale è applicato, ma i children verranno posizionati in absolute rispetto a questo nodo.

Non sono abbastanza organizzata per elencare tutti I tipi di display e posizionamento e dire quali dovrebbero essere usati o meno e con quali altre proprietà, quindi dovrai pensarci da solo quando scriverai e farai il debugging del tuo codice. Ci sono due cose importanti da considerare:

  1. Queste proprietà vanno bene con il tipo di display e di posizionamento che ho scelto?
  2. Le tipologie di posizionamento dei sibling possono coesistere?

Ad esempio, ha senso far interagire elementi float, table-cell e inline? Come dovrebbe reagire il browser? È definito nella documentazione? Se la risposta è no, è probabile che tu stia andando contro l’essenza del CSS. A volte questo può andare anche bene, ma in genere dovresti sapere esattamente perché hai fatto una scelta e concederti del tempo in più per i tuoi test cross-browser.

Internet Explorer

Quando hai risolto tutte le discrepanze fra i browser migliori, sei pronto per confrontarti con IE. La mia raccomandazione è iniziare con la versione più vecchia che devi supportare perché molti bug continuano ad esserci nelle version più nuove, in forma leggermente modificata, quindi avrai meno cose da fixare se inizi con la versione peggiore.

Anche con IE, quello che si vuole cercare di capire è il perché le regole vengono interpretate in modo diverso invece solo di provare ad utilizzare gli hack css. Aggiungere a casaccio gli hack * e _ al tuo codice è come scoprire che una funzione ti dà il valore sbagliato (ad esempio meno quattro rispetto a quanto previsto) e aggiungere semplicemente la differenza, anziché cercare di capire dove il procedimento matematico è sbagliato.

return result+4;

Detto questo, va bene ed è a volte necessario forzare IE6 e 7. IE8 di solito ha solo bisogno di hack per far fronte ad una mancanza di supporto al moderno CSS3. Se credi di dover applicare degli hack, prova a capire esattamente con quale bug stai avendo a che fare.

Ci sono quintali di risorse online per fare questo (vi ricordate PIE?). I problemi specifici che richiedono hack in IE6 e 7 sono:

  • Il bisogno di aggiungere hasLayout con zoom:1
  • Position relative che fa scomparire elementi
  • Il bug dei 3px sul float
  • L’utile expanding container float bug e l’overflow hidden, che sfortunatamente lo fixa.
  • Hai un bug IE preferito? Mi farebbe piacere conoscerlo nei commenti.

Ci sono ovviamente altri problemi, ma questi sono i pochi che ho dovuto gestire in giro per OOCSS. Gli altri ostacoli capitano molto meno spesso, come il “duplicated content bug”; quando hai un commento posto fra due elementi flottanti. Non so spiegare come risolvere i bug di IE perché, nella maggior parte dei casi, ho reso i bug miei. È come parlare una lingua straniera. Il migliore consiglio da darti è di esaminare con attenzione quello che vedi e descriverlo al meglio quando lo ricerchi su Google. Non cominciare con gli hack prima di aver identificato il bug. I tool di sviluppo per IE sono terribili, quindi potresti aver bisogno di usare colori di background per visualizzare i problemi. A questo scopo creo stylesheet dedicati per il debug.

Implementare soluzioni

Quando hai capito bene il problema e sai come risolverlo, sei pronto a capire come inserire la soluzione nel tuo codice senza rovinare tutto. Ecco il mio processo:

  1. Fai affidamento alla cascata dei CSS
  2. Usa i vendor prefix
  3. Usa hack * e _ per IE 6 e 7
  4. Non usare quasi mai \9 per IE8
  5. Sappi quando smettere di provare con gli hack per IE
  6. Non usare mai hack per le versioni più recenti di Firefox, Chrome o Safari.

Si tratta di molti concetti da assimilare, quindi li spiegherò uno per volta.

1. Fai affidamento alla cascata dei CSS
Prima di tutto, fai affidamento alla cascata ogni volta che puoi. CSS ha al suo interno un sistema di fallback naturale. I browser considerano l’ultimo valore che sono in grado di capire (così è stata progettata la cascata). Questo vuol dire che se ordini soluzioni diverse allo stesso problema dalla meno alla più avanzata, i browser useranno in modo naturale la soluzione più avanzata che riescono a capire. Ad esempio:

.foo{
  background-color: #ccc; /* older browsers will use this */
  background-color: rgba(0,0,0,0.2); /* browsers that understand rgba will use this */
} 

2. Usa i vendor prefix
Il prossimo tool da impiegare è il vendor prefix. Ti permette di dare valori diversi per browser diversi, in particolare nel caso di proprietà non stabili.

Fai caso alle due sintassi del webkit. Proprio come i normali fallback delle proprietà, i vendor prefix devono essere ordinati dalla versione meno nuova a quella più recente, in modo che ogni browser attinga al miglior codice che è in grado di sostenere.

background: #1e5799; /* Old browsers */
background: -moz-linear-gradient(top, #1e5799 0%, #2989d8 50%, #207cca 51%, #7db9e8 100%); /* FF3.6+ */
background: -webkit-gradient(linear, left top, left bottom, color-stop(0%,#1e5799), color-stop(50%,#2989d8), color-stop(51%,#207cca), color-stop(100%,#7db9e8)); /* Chrome,Safari4+ */
background: -webkit-linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Chrome10+,Safari5.1+ */
background: -o-linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* Opera 11.10+ */
background: -ms-linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* IE10+ */
background: linear-gradient(top, #1e5799 0%,#2989d8 50%,#207cca 51%,#7db9e8 100%); /* W3C */

Se c’è una sintassi standard metti quella alla fine in modo che, mentre il supporto dello standard aumenta, più browser useranno il codice migliore. Questo è segnato con il commento “W3C” nel codice sopra.

3. Usa gli hack * e _ per IE 6 e 7
Quando avrai riconosciuto bug specifici di IE e capito come risolverli, usa gli hack * e _ per puntare al singolo browser. Ad esempio:

.clearfix {
  overflow: hidden; /* new formatting context in better browsers */
  *overflow: visible; /* protect IE7 and older from the overflow property */
  *zoom: 1; /* give IE hasLayout, a new formatting context equivalent */
}

Tutti gli hack di IE puntano ad un browser particolare e tutti quelli precedenti, quindi, ad esempio:

  • “_” individua IE6 e precedenti
  • “*” individua IE7 e precedenti, e
  • “\9” individua IE8 e precedenti. AGGIORNAMENTO: IE9 viene anch’esso intercettato con alcune proprietà css.

Quando utilizzi
Ciò significa che quando si utilizzano più hack, bisogna metterli in ordine; “_”, poi “*”, quindi “\9”.

4. Non usare quasi mai \9 per IE8
Detto questo, non mi è capitato di aver bisogno di usare \9 per alcun capriccio di IE8. Lo uso solo per riempire gli spazi se c’è una differenza di support. Ad esempio, se uso una box-shadow in browser migliori e il box in IE8 sembra strano senza qualcosa intorno, userò \9 per aggiungere un bordo in quel browser. La tecnica della cascata non funzionerebbe in questo caso, perché il metodo è applicato ad una proprietà diversa.

5. Sappi quando smettere di applicare hack per IE
Non cercare di rendere tutto perfettamente uguale con IE. È importante considerare le cose nell’interesse di ciascun gruppo di utenti. Sprechi numerose richieste HTTP, più HTML, JS e ancora più CSS solo per forzare gli angoli arrotondati da IE6 ad 8? Nel mio caso, la risposta è un No secco.

È importante sapere quando rinunciare ad una feature particolare. Ad esempio, non usare filtri per simulare i gradient CSS3. Creano problemi di performance e bug nei layout. È meglio non cedere al desiderio di rendere il tuo sito esattamente lo stesso in ogni browser a prescindere dalla possibilità di farlo. Agli utenti di IE da 6 ad 8 andrà molto meglio un’esperienza semplificata (non ostacolata, solo più semplice) che un sito che suona le campane e fischietta usando una tonnellata di proprietà dedicate ma incredibilmente lento.

6. Non usare mai hack per le versioni più recenti di Firefox, Chrome o Safari
Infine, se credi di aver bisogno di inserire hack per colmare differenze di visualizzazione tra Firefox, Chrome o Safari, qualcosa è andato davvero storto. La cosa più sensata è fare un passo indietro e osservare quello che hai scritto per vedere se stai andando contro l’essenza del CSS.

Ne utilizzi altre?

Hai tecniche particolari per il debug del tuo CSS? Oppure per implementare fix quando hai trovato una soluzione? Segnalameli pure nei commenti.

Search
Tags
Seleziona rubrica
Seleziona rubrica
Codice Github