Risoluzione dei problemi dei CSS

Link copiato negli appunti

In un mondo ideale le nostre pagine progettate con i fogli di stile hanno una resa perfetta su tutti i browser. Nella realtà ci si scontra con problemi di visualizzazione su uno o più browser che spesso non si sa come risolvere. In questo articolo, suddiviso in tre parti, cercheremo di capire come ci si deve muovere per ottenere una maggiore aderenza alle nostre aspettative.

L'importanza del test multi-browser

Un sito progettato con i fogli di stile richiede molte più attenzioni di un sito basato sulle tabelle dal momento che spesso ci si può trovare di fronte a rese differenti sui vari browser. Se presenta imperfezioni o difetti macroscopoci a livello presentazionale non fa altro che fornire un'impressione negativa, e può perfino risultare inutilizzabile. È per questo che la fase di test multi-browser è essenziale. Per prima cosa, il sito dovrà essere perfetto su Internet Explorer. Del browser di casa Microsoft è essenziale effettuare i test di resa almeno sulla versione 5.5 e 6, ed è consigliata anche la verifica sulla versione 5.0. Se disponete di un sistema che Windows 2000 o XP, l'articolo «Tutti gli Explorer insieme su Windows» merita una lettura.

Se è vero che Internet Explorer detiene il 90-95% dei browser utilizzati su internet, non si possono trascurare gli altri, specie se la verifica dei log di accesso dovesse far rilevare un'alta perecntuale di utenti con browser alternativi a quello di Microsoft. Ricordiamo, intanto, Opera (va bene una versione dalla 7 in poi) di cui esiste una versione per tutti i sistemi operativi; non è poi possibile trascurare una versione recente di Mozilla o Firefox (anch'essi disponibili per diverse piattaforme). Per la piattaforma Mac, oltre ai due appena citati, si dovrà testare su Safari e sulla versione 5 di Internet Explorer per Mac.

Con una compatibilità garantita su questo ventaglio di browser saremo quasi certi di mostrare ad un'altissima percentuale di visitatori un sito senza, o con pochissimi, difetti di resa.

Non è quello che mi aspettavo: come mai?

Può capitare che testando le pagine progettate con i CSS su uno o più browser il risultato non coincida con le nostre aspettative. Le possibili cause sono:

il problema è a monte: ci sono errori nel codice HTML;
ci sono errori di digitazione nel CSS;
ci sono errori concettuali nel CSS;
è colpa del browser.

Difficilmente attribuiremo da subito la "colpa" a noi stessi, ma comunque è la prima opzione da considerare. Procediamo con l'analizzare alcune delle possibili cause e delle cure nei problemi di resa con i fogli di stile.

Errori nel markup

Un buon foglio di stile nasce da un buon codice HTML, ed è importante scongiurare da subito errori concettuali e digitazione nel markup: per questo, ancora prima della stesura del CSS sarà opportuno predisporre le nostre pagine HTML (o XHTML) con un corretto doctype e procedere a validare le pagine. Se il validatore non riscontra problemi, abbiamo già scartato la prima opzione.

Errori di digitazione nel CSS

Stare al computer parecchio tempo, l'affaticamento della vista e la distrazione sono una delle prime cause da considerare. Un carattere omesso, i due punti mancanti, un punto e virgola fuori posto: a chi non è capitato? È per questo che come prima cosa, ancora prima di verificare i problemi di resa, è un'ottima pratica la validazione del foglio di stile: è in grado di rilevare errori di digitazione e alcuni errori concettuali.

Errori concettuali nel CSS

Arrivare a progettare bene siti e pagine con i fogli di stile può risultare un processo lungo. Per prima cosa, i fogli di stile non si improvvisano, richiedono studio e applicazione: la teoria è un aspetto fondamentale. È per questo che, come ho detto nell' articolo dedicato all'ottimizzazione dei CSS (cfr. Articolo: «Ottimizzare i CSS - I), seguire per intero la guida ai CSS e tenere a portata di mano la reference del W3C è importantissimo.

Rilevare, e soprattutto risolvere, i propri errori concettuali o le carenze teoriche è un compito difficile, è per questo che un buon livello di preparazione è l'unico modo per evitarli a monte. Soprattutto nel momento di mettere in pratica ciò che abbiamo studiato, possono riverlarsi molto utili forum, newsgroup e mailing list per avere supporto e imparare dalle moltissime questioni che vengono poste.

Un esempio: contenere i float

Un esempio classico, affrontato probabilmente da molti dei lettori, è il comportamento di elementi float in una pagina HTML. Ecco un caso tipico, con stili in linea:

Vediamo come rende. Noterete che l'immagine "sborda" dal suo contenitore. Questo perchè gli elementi float vengono traslati dal flusso degli elementi di una pagina HTML e, mentre gli elementi circostanti di un elemento float ne risentono, disponendosi di conseguenza, per gli "antenati" è come se non ci fossero.

Se non conosciamo un po' di teoria e non sappiamo che il float va contenuto difficilmente potremo venirne a capo. La soluzione è un semplice div vuoto o un br che dà il clear prima della chiusura del div contenitore:

Con questa semplice aggiunta, abbiamo risolto il problema.

"Colpa" dei browser

Se abbiamo validato HTML e CSS, abbiamo una buona padronanza dei fogli di stile, abbiamo letto e riletto il foglio di stile alla ricerca di una dichiarazione mancante o una di troppo ma ancora niente... Se soprattutto riscontiamo un problema su un browser, ma su un altri no, in questo caso potrebbe essere un problema di errata interpretazione o mancato supporto del nostro CSS da parte del browser problematico. È importante servirsi come punto di riferimento di un browser fedele, ossia con maggiore aderenza agli standard possibile. Tra questi, le ultime versioni di Firefox, Mozilla o Opera sono senz'altro indicate. Nel 90% dei casi il browser che ci darà problemi è quello debole, ossia Internet Explorer per Windows. È a questo browser, infatti, che è attribuita la maggior parte dei bug e dei comportamenti errati relativi ai fogli di stile. Vedremo in questo articolo alcuni dei più comuni bug e come risolverli. La progettazione con i fogli di stile implica, infatti, anche una buona conoscenza dei browser e della strategia per difendersi dai loro piccoli e grandi difetti.

Evidenziare e isolare il problema

Fare il debug di una pagina HTML con il relativo CSS è una pratica abbastanza comune quando si riscontrano problemi. Isolare il problema è il primo passo da fare. Ecco alcune idee per individuare errori nel codice:

Intervenire sull'HTML, eliminando porzioni di codice. Ancora meglio è racchiudere le parti che pensiamo problematiche tra commenti.
Attribuire via CSS un colore di sfondo o dei bordi agli elementi che possono risultare critici.
Eliminare (racchiudendole tra commenti) dichiarazioni o regole CSS relative agli elementi interessati.
Usare la Web Developer Toolbar per Mozilla e Firefox.

Una volta isolato il problema, si potrà procedere a risolverlo. Come vedremo, ci sono diverse strategie.

Risolvere il problema senza trucchi

Ci sono due tipologie di bug:

bug innocui;
bug dannosi.

Mentre i primi risulteranno come piccolissimi difetti, i secondi (molto più frequenti) danno problemi di impaginazione, di consultazione o di usabilità. Quale che sia l'entità del bug, il primo approccio che si tenterà sarà aggiungere dichiarazioni apparentemente ininfluenti per cercare di sistemare le cose. A volte si riesce a risolvere senza trucchi: è il caso del prossimo esempio, in cui tratteremo uno dei pochi bug innocui di Internet Explorer.

Esempio: link block-level e IE

Consideriamo un semplicissimo menu verticale in cui vogliamo ottenere link "a tutto campo", ossia che si estendono per tutto il list-item che li contiene. Ecco le regole CSS sui link:

div#menu a{display: block;text-decoration:none;padding: 5px 0 5px 5px;
background-color: #FFFFC5;color: #6E6EB1}
div#menu a:hover{background-color: #FF7E00;color: #fff}

Mentre su Opera e Mozilla il risultato è quello che ci aspettiamo, in Internet Explorer (sia nella versione 5.x che nella 6) il link si attiva solo passando il mouse sulla scritta. La soluzione a questo problema è attribuire una delle due dimensioni (altezza o larghezza) al link. Specificando una delle due dimensioni bisognerà aver cura però di non trovarsi di fronte ad un altro problema, ossia l'errata interpretazione del box model di IE5.x (cfr. Articolo:«Il box model errato di IE5.x e il box model hack»). Non potremo quindi specificare una delle seguenti dichiarazioni combinate per i link:

larghezza e padding orizzontale;
altezza e padding verticale.

In questo caso, una possibile soluzione è attribuire altezza e line-height. Quest'ultima proprietà ha infatti il compito di centrare verticalmente il testo all' interno del link evitando così di specificare padding verticale. Ecco le due regole che sistemano le cose:

div#menu a{display: block;height: 25px;line-height: 25px;text-decoration:none;
padding-left: 5px;background-color: #FFFFC5;color: #41418A}
div#menu a:hover{background-color: #FF7E00;color: #fff}

Abbiamo quindi risolto il problema senza hack. La migliore strategia, però, consiste nel prevenire possibili comportamenti anomali.

Se conosciamo i bug, a volte possiamo prevenirli. Un workaround è un modo per aggirare il bug, invece che risolverlo con dichiarazioni aggiuntive o hack: spesso l' intervento è nell'HTML invece che nel CSS. Questo sarà possibile solo se abbiamo una profonda conoscenza del bug e delle situazioni in cui avviene. È il caso del prossimo esempio.

Esempio: evitare il box model hack

Come abbiamo visto nell'articolo sul box model, Internet Explorer 5.x (e IE6 senza corretto doctype) hanno un'errata interpretazione delle dimensioni effettive di un elemento (cfr. articolo:«Capire il box model»). Specificare insieme dimensioni e padding concordi e/o dimensioni e bordi di un elemento ci farà sicuramente cadere in problemi di box model. In alcuni casi il problema si può aggirare. Per esempio, se volessimo realizzare un div largo in totale 200pixels con bordi e padding (supponendo che questo abbia id="box") l'unica regola CSS, usando il box model hack semplificato, sarebbe la seguente:

div#box{ border: 5px solid #000;padding: 10px;
width: 170px; width: 200px; width: 170px;
background-color: #ffc}

È però una buona pratica separare contenitore da contenuto. L'HTML dell'esempio, si può rivedere a favore di una versione più semantica, in cui il testo è racchiuso in un paragrafo:

<div id="box">
<p>Testo...</p>
</div>

A questo punto si può attribuire al div larghezza effettiva di 200 pixel, spostando le dichiarazioni su bordi e padding sul paragrafo. Ecco il CSS, in cui abbiamo quindi eliminato l'uso del box model hack:

div#box{width: 200px}
div#box p{margin: 0;border: 5px solid #000;padding: 10px;
background-color: #ffc}

È importante notare che si è forzato a zero il margine del paragrafo, che viene assegnato di default da tutti i browser. Il risultato è identico all'esempio che usa il box model hack.

In casi reali un approccio simile può risultare a volte scomodo, e causare una maggiore codifica CSS e/o HTML. Supponiamo di avere un layout a due o tre colonne, e di avere in una delle due colonne laterali il menu di navigazione, un form di ricerca o di login, dei banner e dei link esterni al sito. Per ciascuno degli elementi figli diretti della colonna laterale dovremo infatti replicare il padding (o il margine) laterale. Le cose si fanno ancora più complicate se oltre a un po' di spaziatura vogliamo dei bordi. Una soluzione di compromesso è usare un div aggiuntivo per contenere tutto quanto: si tratterà pero di un contenitore puramente presentazionale, con una leggera complicazione del codice HTML.

La soluzione più versatile si rivela quindi l'uso del box model hack, a parer mio uno di quelli a cui è difficile rinunciare e che può essere usato con tranquillità.

Hack o non hack: questo è il dilemma

I webdesigner si dividono spesso sul tema hack: c'è chi li usa con tranquillità e chi li evita sempre. La via di mezzo è forse la migliore: gli hack dovranno essere considerati come ultima risorsa, ma se non si potrà risolvere facilmente (sia in termini di tempo che di codice) un bug, uno di questi 'trucchetti' diventerà quasi indispensabile. A favore degli hack c'è la rapidità di risoluzione di un bug. Di contro, al momento di usare un hack non potremo sapere come si comporterà con le versioni future dei browser. È per questo che un hack si può usare con maggiore tranquillità su un sito che prevede aggiornamenti e/o restyling abbastanza frequenti.

In generale, dunque, la strategia di fronte ad un bug è la seguente:

se possibile, evitare il bug: questo ci eviterà di usare il relativo hack. Spesso richiede un intervento a livello di codice HTML;
in alternativa, cercare di risolvere il bug in maniera pulita, ossia aggiungendo dichiarazioni e/o regole CSS che risolvono il bug, ma che sugli altri browser non creano problemi;
se non si è potuto risolvere ai punti 1 e 2, si potrà usare tranquillamente l'hack.

Come mostrare o nascondere regole e dichiarazioni ai browser

C'è una varietà di modi per far passare o nascondere regole solo a certi browser. Vedremo qui di seguito alcuni dei più utili.

Soluzioni HTML per IE/Win: il conditional comment

Agli altri browser, e al validatore, risulterà come un semplice commento nel codice HTML, ma in realtà è possibile specificare regole per determinate versioni di IE, a partire dalla versione 5. Il suo uso è sicuro e semplice. Il prossimo esempio linka un foglio di stile esterno solo per IE5.0:

Analogamenente possiamo specificare un commento condizionale per IE 5.5 e 6, sostuendo la prima riga del codice precedente in:

<!--[if IE 5.5]>    per IE 5.5
<!--[if IE 6]>    per IE 6
<!--[if gte IE 5.5]>    per IE 5.5 e superiori
<!--[if lte IE 5.5]>    per IE 5.0 e 5.5
<!--[if lte IE 6]>    per versioni di IE dalla 5 alla 6

In particolare l'ultima viene applicata a tutte le versioni di IE dalla 5 alla 6, escludendo quindi le versioni future. Usare i commenti condizionali e dichiarare le regole necessarie ad IE in un foglio di stile a parte ci consente di creare un CSS principale il più pulito possibile, libero da hack o workaround.

Soluzioni CSS per IE/Win: il selettore discendente

Il selettore discendente non è supportato da tutte le versioni di Internet Explorer per Windows. Usandolo nel foglio di stile potremo creare regole specifiche per IE e, quindi per differenza, gli altri browser più standard. Ecco un esempio:

div#content{height: 200px}
*>div#content{height: auto; min-height: 200px}

In realtà non è un vero e proprio hack, e per questo è una tecnica piuttosto sicura e largamente utilizzata.

Soluzioni CSS per IE (sia Win che Mac): lo "star HTML" hack

Lo star html hack sfrutta il selettore discendente in maniera un po' particolare. Sappiamo tutti che il "capostipite" di una pagina HTML è, appunto, l'elemento html. Internet Explorer, sia per Windows che per Mac, applicano la seguente regola:

* html p{ color: green}

Proprio come se l'elemento html avesse un "padre invisibile". Tutti gli altri browser non interpreteranno la regola. Il mio consiglio è di usarlo con la massima prudenza: ad oggi non possiamo sapere se le future versioni di IE interpreteranno la regola o meno.

I Filtri di banda passante

Ci sono modi per importare fogli di stile per un determinato set di browser, tenendo così il CSS principale libero da hack o workaround che però possono risultare problematici per altri browser. Ne parla Molly Holzschlag nell'interessante articolo Strategies for Long-Term CSS Hack Management. La strategia dei filtri, seppure complessa da applicare, consente di creare fogli di stile liberi da hack, quindi adatti per i browser attuali e futuri con buon supporto di CSS e di importare file CSS specifici per i browser problematici.

High Pass Filter

Questo filtro, ideato da Tantek Çelik, serve a importare un foglio di stile solo per i browser con un buon supporto dei CSS. Per prima cosa linkiamo il CSS:

Il file highpassfilter.CSS contiene solo le seguenti due righe:

@import "null?"{";
@import "highpass.CSS";

Il file "highpass.CSS" conterrà il CSS effettivo, che sarà visibile solo dai seguenti browser:

Mac IE5
Opera 5 e successivi
Netscape 6 e i tutti i browser Mozilla e famiglia
IE6 per Windows (e probabilmente versioni successive)

Da notare che, come riportato nell'articolo di Tantek, sarà necessario ai fini della validazione del CSS che un file "null" (senza estensione) sia presente nella stessa cartella degli altri due CSS, e che questo file contenga al massimo un commento o sia totalmente vuoto.

Mid Pass Filter

Il Mid Pass Filter, anch'esso ideato da Tantek Çelik è decisamente potente e utile. Ci consente infatti di importare un foglio di stile esclusivamente per IE5.x per Windows. Ecco la regola da aggiungere nel CSS principale:

@media tty {
i{content:"";/*" "*/}} @import 'ie5x.CSS'; /*";}
}/* */

Il file 'ie5x.CSS' conterrà quindi le regole specifiche per Internet Explorer 5.x. Un uso notevole che si può fare di questo filtro è includerlo come ultima regola del CSS principale. Verrà quindi importato, nel caso il browser sia IE5.0 o IE5.5, un foglio di stile dedicato. In questo modo potremo evitare anche l'uso del box model hack nel foglio di stile principale: le regole importate solo a IE5.x andranno infatti a ridefinire le quelle del CSS generico.

Altri filtri per IE Windows

Çelik ha anche ideato filtri specifici per IE5 e IE5.5, di cui potrete leggere in questa pagina.

Nascondere regole per IE5 Mac

C'è un hack per nascondere regole a IE5 per Mac.Si tratta di racchiudere il codice CSS da nascondere a IE5Mac tra due commenti, di cui uno ha un backslash prima della chiusura:

/* commented backslash hack v2 */
qui le regole per tutti i browser, escluso IE5Mac
/* end hack */

Ovviamente potremo usare tra i due commenti anche la direttiva @import per importare un altro foglio di stile.

Regole specifiche per IE5 Mac

È possibile anche creare un insieme di regole, o importare un intero CSS, di modo che siano visibili solo a IE5 Mac. Ecco la sintassi:

/**//*/
@import "ie5mac.CSS";
/**/

Anche in questo caso, per gli altri browser risulterà come commento.

Le risorse e gli approfondimenti

Sono davvero molte le risorse su hack e filtri. Le seguenti riportano molte tecniche con le relative compatibilità dei broser:

Presentiamo alcuni bug di Internet Explorer e le loro soluzioni.

Holly Hack

Prima di cominciare, vorrei citare una delle risorse più complete per i bug di Internet Explorer e le relative soluzioni. Recentemente gli autori di Position Is Everything hanno scoperto e presentato l'Holly Hack come soluzione di molti bug di IE. L'Holly Hack combina due hack insieme, per creare una regola rivolta solo a IE/Win. La tecnica contiene il commented backslash hack per nascondere la regola a IE Mac, e lo star-HTML hack per creare una regola vista, quindi, solo da IE/Win:

/* Hide from IE5-mac */
* html .buggybox {height: 1%;}
/* End hide from IE5-mac */

La mia idea, come ho già detto commentando lo star-html hack, è che al momento non sappiamo se questa tecnica verrà interpretata, e soprattutto gli effetti che potrà avere, sulle future versioni di IE/Win. Il mio consiglio è quindi di usarla con molta prudenza e come ultima risorsa. Ora non ci resta che procedere con altri bug.

Peekaboo bug: ossia il testo che sparisce

Questo bug è in grado di sacrificare moltissimo l'usabilità del sito: infatti, alcune sezioni di testo non saranno visibili con IE6. Ecco un esempio e una possibile soluzione.

Quando avviene: capita quando un contenitore di larghezza non specificata contiene un elemento float e del testo, e c'è un elemento successivo che dà il clear.

Cosa succede: all'interno del contenitore si vedrà solo l'elemento float. Tutto il resto sarà invisibile, fino a quando non si seleziona il testo con il mouse, non si fà lo scroll della pagina oppure non si passa il mouse su un link.

Come risolvere: ci sono diversi modi. Tra questi:

Dichiarare una delle due dimensioni del contenitore esterno.
Usare la proprietà line-height.
Dichiarare position:relative sia il contenitore che l'elemento float

Doubled-Margin Float

Questo bug raddoppia i margini di un elemento float con margini concordi e diversi da zero.

Ecco un esempio e una possibile soluzione.

Quando avviene: avviene se l'elemento è float:left e ha un margin-left oppure float:right con margin-right.

Cosa succede: il margine dal lato del float viene raddoppiato.

Come risolvere: se possibile, evitare di specificare il margine critico, usando ad esempio il padding e, eventualmente un contenitore aggiuntivo. Oppure, la soluzione è dichiarare l'elemento display:inline. Questa dichiarazione non ha effetti sugli altri browser (e neanche su IE, a parte quello di sistemare il bug) dato che un elemento float viene reso di default come elemento block-level.

3 Pixels Jog

Questo bug di IE fa sì che il testo all'interno di un elemento adiacente al float ne subisca un margine aggiuntivo di tre pixel. Ecco un esempio e la relativa soluzione.

Quando avviene: avviene quando del testo subisce un float.

Cosa succede: il testo adiacente al float viene allontanato di 3 pixel, anche in presenza di margini dichiarati, per tutta la lunghezza del float.

Come risolvere: in questo caso la soluzione è un po' più complessa, dato che non è possibile sistemare con dichiarazioni innocue per gli altri browser. Nell'esempio abbiamo due casi. Nel primo, il testo dovrebbe toccare l'elemento float. Per sistemarlo, basterà dichiarare un margin-right sull'elemento float. Nel secondo caso, in aggiunta, dovremo dichiarare per l'elemento adiacente al float un'altezza pari all' 1% ed eliminare il suo margine sinistro. Per Internet Explorer elementi con altezza molto piccola verranno comunque resi per intero. Le dichiarazioni aggiuntive vengono importate solo per IE grazie a un commento condizionale:

Il file CSS importato verrà quindi letto da IE fino alla versione 6. Gli altri browser, e il validatore, non riconosceranno il testo del commento. Ecco le regole del foglio di stile specifico per IE:

div.floated{margin-right:-3px}
p.p2{height:1%;margin-left:0}

Italic bug

Questo bug è decisamente misterioso, e non si sa bene quando si verifica.

Quando avviene: Di sicuro c'è che avviene quando c'è del testo corsivo sia attribuito via CSS, sia racchiuso in un elemento em. Se il testo è giustificato oltre che corsivo, è più facile che si verifichi. Ecco un esempio e una possibile soluzione. Si verifica sia con IE5.x che con IE6.

Cosa succede: Il contenitore del testo, anche se ha dimensioni esplicite, viene allargato di una decina di pixel.

Come risolvere: Dipende dai casi. A volte basta dichiarare overflow:visible il contenitore con dimensioni esplicite. Ricordo che visible è il valore di default per la proprietà overflow, e non ha ripercussioni quindi sugli altri browser. Oppure si può evitare di giustificare il testo. Un'altra alternativa, se non fosse possibile risolvere altrimenti, è forzare via CSS il testo ad essere normale anzichè corsivo nel caso si trattasse di Internet Explorer. Ecco il codice, che crea una regola visibile solo ad Internet Explorer, ridefinendola attraverso il child selector per gli altri browser:

div.ita em{font-style: normal}
html>body div.ita em{font-style: italic}

Conclusioni

Termina qui quest'articolo dedicato alla soluzione dei problemi CSS, in cui abbiamo visto l'approccio teorico e quello pratico, parlato di workaround, filtri, hack e dei più comuni bug di Internet Explorer. Ci si troverà sempre di fronte, purtroppo, a comportamenti strani e differenze di resa tra i vari browser. Teoria, pratica e informazione restano comunque le migliori difese da problematiche simili.

Indice lezioni