[Precedente] - [Successivo] - [Pagina principale] - [Sommario rapido] - [Sommario completo] - [Proprietà]

CSS FAQ - Domande frequenti sui CSS

Sommario

  1. Cosa sono i CSS?
  2. I CSS sono un linguaggio di programmazione?
  3. Qual'è la sintassi dei CSS?
  4. La validazione è importante?
  5. Qual'è il browser con un supporto completo ai CSS?
  6. Da cosa dipendono i bug nei browser?
  7. Come posso risolvere i bug dei browser?

1. Cosa sono i CSS?

I CSS (Cascading Style Sheets, Fogli di stile a cascata) sono un linguaggio di stile per la formattazione di documenti web.

2. I CSS sono un linguaggio di programmazione?

No. Per esempio, i CSS non possono fare questo:

<?php // Checks to see whether it needs a sidebar or not
if ( !$withcomments && !is_single() ) { ?>
(istruzioni PHP)

Ma possono fare questo:

#page { 
background: url("stylesheet_directory/images/kubrickbg.jpg") repeat-y top; 
border: none; 
}

ossia modificare l'immagine di sfondo di un elemento di un documento web. Se combinati con un linguaggio dinamico lato server, i CSS possono essere ancora più versatili:

<style type="text/css" media="screen">

<?php // Checks to see whether it needs a sidebar or not
if ( !$withcomments && !is_single() ) { ?>
	
#page { background: url("<?php bloginfo('stylesheet_directory'); 
?>/images/kubrickbg.jpg") repeat-y top; border: none; } 
<?php }

else { // No sidebar ?>	
#page { background: url("<?php bloginfo('stylesheet_directory'); 
?>/images/kubrickbgwide.jpg") repeat-y top; border: none; } <?php } 
?>
</style>

come nel caso dei moderni CMS (Content Management System). Nel codice visto prima, il linguaggio dinamico lato server (in questo caso PHP) verifica che nella pagina ci sia un determinato contenuto. Se il contenuto è presente, inserisce un'immagine di sfondo tramite i CSS; in caso contrario, ne inserisce un'altra.

Un altro esempio servirà a chiarire meglio il concetto:

<?php get_header(); ?>	
<div id="content" class="narrowcolumn">
...</div>

In questo caso PHP inserisce la parte iniziale del documento. Come si può notare, PHP non definisce come questa parte verrà presentata all'utente. Questo è compito dei CSS, che formatteranno l'elemento div tramite l'ID content e la classe narrowcolumn:

.narrowcolumn {
float: left;
padding: 0 0 20px 45px;
margin: 0px 0 0;
width: 450px;
}

#content {
font-size: 1.2em
}

Queste due regole dicono al browser che il div dovrà essere posizionato sulla sinistra ('float: left') e che dovrà essere largo 450 pixel ('width: 450px'), con una dimensione del font pari a 1.2 volte la dimensione del font del suo genitore (in questo caso l'elemento body).

Come si può notare, i CSS definiscono solo la presentazione, lasciando al linguaggio del documento (in questo caso XHTML) il compito di definirne la struttura.

3. Qual'è la sintassi dei CSS?

Un esempio:

selettore {proprietà: valore;}

Tutto quello che è compreso tra il selettore e la parentesi graffa di chiusura viene detto blocco di dichiarazione. Un blocco di dichiarazione è composto da uno o più selettori e da una o più proprietà che agiscono su quei selettori.

Le proprietà possono avere uno o più valori. Si notino i due punti (:) uniti alla proprietà. Lo spazio tra i due punti e il valore è facoltativo. Il punto e virgola finale è facoltativo solo nel caso in cui il blocco di dichiarazione abbia una sola dichiarazione o nel caso dell'ultima dichiarazione di una serie. Per esempio:

body {
margin: 2em;
padding: 0;
font-family: Verdana, sans-serif
}

è corretto, mentre:

body {
margin: 2em;
padding: 0
font-family: Verdana, sans-serif;
}

è errato, in quanto mancano il punto e virgola alla fine della seconda dichiarazione. In questo caso il browser ignorerà la seconda dichiarazione.

Le parentesi graffe dopo il selettore sono obbligatorie. Quando il parser CSS di un browser incontra un errore come questo, l'intero blocco di dichiarazione verrà invalidato, il che significa che le regole di stile espresse non saranno applicate.

Anche gli errori di battitura possono invalidare le dichiarazioni. Per esempio:

#box {
width: 200px;
border: 1px dashed #ccc:
background: #ffc;
color: #000;
}

In questo caso il bordo non verrà applicato, in quanto alla fine della dichiarazione ho inserito i due punti e non il punto e virgola.

Per chi fosse interessato, questo è lo scanner lessicale dei CSS:

%option case-insensitive

h		[0-9a-f]
nonascii	[\200-\377]
unicode		\\{h}{1,6}(\r\n|[ \t\r\n\f])?
escape		{unicode}|\\[^\r\n\f0-9a-f]
nmstart		[_a-z]|{nonascii}|{escape}
nmchar		[_a-z0-9-]|{nonascii}|{escape}
string1		\"([^\n\r\f\\"]|\\{nl}|{escape})*\"
string2		\'([^\n\r\f\\']|\\{nl}|{escape})*\'
invalid1	\"([^\n\r\f\\"]|\\{nl}|{escape})*
invalid2	\'([^\n\r\f\\']|\\{nl}|{escape})*

comment		\/\*[^*]*\*+([^/*][^*]*\*+)*\/
ident		-?{nmstart}{nmchar}*
name		{nmchar}+
num		[0-9]+|[0-9]*"."[0-9]+
string		{string1}|{string2}
invalid		{invalid1}|{invalid2}
url		([!#$%&*-~]|{nonascii}|{escape})*
s		[ \t\r\n\f]+
w		{s}?
nl		\n|\r\n|\r|\f

A		a|\\0{0,4}(41|61)(\r\n|[ \t\r\n\f])?
C		c|\\0{0,4}(43|63)(\r\n|[ \t\r\n\f])?
D		d|\\0{0,4}(44|64)(\r\n|[ \t\r\n\f])?
E		e|\\0{0,4}(45|65)(\r\n|[ \t\r\n\f])?
G		g|\\0{0,4}(47|67)(\r\n|[ \t\r\n\f])?|\\g
H		h|\\0{0,4}(48|68)(\r\n|[ \t\r\n\f])?|\\h
I		i|\\0{0,4}(49|69)(\r\n|[ \t\r\n\f])?|\\i
K		k|\\0{0,4}(4b|6b)(\r\n|[ \t\r\n\f])?|\\k
M		m|\\0{0,4}(4d|6d)(\r\n|[ \t\r\n\f])?|\\m
N		n|\\0{0,4}(4e|6e)(\r\n|[ \t\r\n\f])?|\\n
P		p|\\0{0,4}(50|70)(\r\n|[ \t\r\n\f])?|\\p
R		r|\\0{0,4}(52|72)(\r\n|[ \t\r\n\f])?|\\r
S		s|\\0{0,4}(53|73)(\r\n|[ \t\r\n\f])?|\\s
T		t|\\0{0,4}(54|74)(\r\n|[ \t\r\n\f])?|\\t
X		x|\\0{0,4}(58|78)(\r\n|[ \t\r\n\f])?|\\x
Z		z|\\0{0,4}(5a|7a)(\r\n|[ \t\r\n\f])?|\\z

%%

{s}			{return S;}

\/\*[^*]*\*+([^/*][^*]*\*+)*\/		/* ignore comments */
{s}+\/\*[^*]*\*+([^/*][^*]*\*+)*\/	{unput(' '); /*replace by space*/}

""			{return CDC;}
"~="			{return INCLUDES;}
"|="			{return DASHMATCH;}

{w}"{"			{return LBRACE;}
{w}"+"			{return PLUS;}
{w}">"			{return GREATER;}
{w}","			{return COMMA;}

{string}		{return STRING;}
{invalid}		{return INVALID; /* unclosed string */}

{ident}			{return IDENT;}

"#"{name}		{return HASH;}

"@import"		{return IMPORT_SYM;}
"@page"			{return PAGE_SYM;}
"@media"		{return MEDIA_SYM;}
"@charset "		{return CHARSET_SYM;}

"!"({w}|{comment})*"important"	{return IMPORTANT_SYM;}

{num}{E}{M}		{return EMS;}
{num}{E}{X}		{return EXS;}
{num}{P}{X}		{return LENGTH;}
{num}{C}{M}		{return LENGTH;}
{num}{M}{M}		{return LENGTH;}
{num}{I}{N}		{return LENGTH;}
{num}{P}{T}		{return LENGTH;}
{num}{P}{C}		{return LENGTH;}
{num}{D}{E}{G}		{return ANGLE;}
{num}{R}{A}{D}		{return ANGLE;}
{num}{G}{R}{A}{D}	{return ANGLE;}
{num}{M}{S}		{return TIME;}
{num}{S}		{return TIME;}
{num}{H}{Z}		{return FREQ;}
{num}{K}{H}{Z}		{return FREQ;}
{num}{ident}		{return DIMENSION;}

{num}%			{return PERCENTAGE;}
{num}			{return NUMBER;}

"url("{w}{string}{w}")"	{return URI;}
"url("{w}{url}{w}")"	{return URI;}
{ident}"("		{return FUNCTION;}

.			{return *yytext;}

Per maggiori informazioni, si consulti la pagina http://www.w3.org/TR/CSS21/grammar.html. Su questo scanner lessicale, ovviamente adattato nei vari linguaggi di programmazione, si basano molti dei parser CSS dei vari browser.

Sulla grammatica, si consulti in italiano http://www.diodati.org/w3c/css2/syndata.html.

4. La validazione è importante?

Dipende. È fondamentale se si vogliono fugare dei dubbi su possibili errori sintattici e su presunti malfunzionamenti nei vari browser. È futile se si vuole ostentare il bollino 'Valid CSS' come garanzia di qualità e di professionalità. La qualità di un sito si misura con altri parametri. Per esempio, si consideri la seguente dichiarazione:

#pagina {
-moz-border-radius: 4px;
}

La proprietà '-moz-border-radius' è un'estensione sperimentale dei browser Mozilla (Mozilla, Firefox) che in futuro servirà per estendere il supporto alla proprietà CSS3 'border-radius'. Questa proprietà serve ad arrotondare i bordi di un elemento.

Poiché è un estensione e non una proprietà standard non verrà validata. Tuttavia il suo impatto sulla pagina è pressocché nullo, in quanto si tratta di un effetto puramente estetico, la cui presenza o assenza non pregiudica in nessun modo la fruizione dei contenuti. Nondimeno, non è valida.

Se usate questa estensione, il vostro CSS non verrà validato. Ma da un punto di vista dell'accessibilità e dell'usabilità del sito, questo non è a vostro detrimento, in quanto non ha nessun influenza sulla serietà del vostro lavoro. Semplicemente, gli utenti di Firefox e Mozilla vedranno i bordi arrotondati, gli altri no. Volendo potreste usare JavaScript per dare un foglio di stile separato a Firefox:

var x = "<link rel='stylesheet' href='css/ff.css' 
type='text/css' media='screen'>";
var ua = RegExp(" Firefox/").test(navigator.userAgent);
if (ua) {
document.write(x)
}

Ma così inserireste un altro file tra quelli già collegati alla pagina, con un aumento del consumo di banda. Un'altra soluzione è quella di usare delle immagini di sfondo per simulare i bordi arrotondati. In questo caso, dovrete a volte usare della marcatura aggiuntiva, con un aumento del codice della pagina.

Usare un'estensione CSS o una proprietà di una specifica non ancora ufficiale (come i CSS3) non è come usare i famigerati tag proprietari della tristemente nota guerra dei browser. I CSS possono sempre essere disabilitati, ma un tag come marquee (testo scorrevole) no, con tutti gli svantaggi connessi.

Infine, è sempre possibile validare il proprio foglio di stile usando i parametri messi a disposizione dal W3C. Per esempio:

http://jigsaw.w3.org/css-validator/validator?uri=http%3A%2Fwww.sito.com%2F
&amp;warning=no&amp;profile=css3&amp;usermedium=all

I parametri fondamentali di questo URI sono:

&profile=css3
Validiamo il nostro CSS secondo i CSS3. Quindi se vogliamo usare una proprietà come 'opacity' possiamo farlo. Ovviamente possiamo cambiare il profilo in CSS2.
&warning=no
Disabilitiamo gli avvisi del validatore, che il più delle volte ci ricordano che non abbiamo impostato un colore di sfondo o che abbiamo ripetuto due volte lo stesso colore.
&usermedium=all
Validiamo il nostro CSS secondo tutti i media disponibili (screen, print, ecc.). Ovviamente possiamo scegliere un media specifico (per esempio screen).

5. Qual'è il browser con un supporto completo ai CSS?

Nessuno. Ci sono browser (come Safari, Konqueror, Opera e Firefox) che hanno un supporto più esteso di altri (come Internet Explorer), ma nessuno copre la totalità delle specifiche CSS attualmente in uso. Questo dipende in parte dal fatto che le attuali specifiche ( CSS 2, revisione 1 ) sono piuttosto vaghe nel definire il livello di supporto di un browser. Per esempio, Internet Explorer (versione 7, 6, 5 per Windows) non supporta il contenuto generato, ma le specifiche non affermano che il contenuto generato sia una parte ineludibile del supporto ai CSS.

Questo limite sarà superato nei CSS3, dove, usando il principio dei moduli, un browser che supporta un modulo dovrà farlo in toto, senza eccezioni. Bisogna comunque tenere presente che i browser non sono solo degli strumenti per sviluppatori, ma soprattutto dei programmi con cui gli utenti navigano sul Web.

Come tali, devono rispondere alle caratteristiche di affidabilità, usabilità e sicurezza. Va da sé che se un browser ha dei problemi con una di queste caratteristiche, le sue priorità cambiano drasticamente.

Per esempio Internet Explorer, che è il browser di gran lunga più usato e proprio per questo più esposto ad attacchi, ha dovuto affrontare dei seri problemi di usabilità e sicurezza nel corso della sua storia. Questi problemi hanno fatto si che le sue priorità si incentrassero di più sulla correzione di questi difetti (con patch, Service Pack e aggiornamenti) che non sul supporto agli standard del Web (come i CSS).

Ciò è comprensibile, se si pensa che raramente una pagina con le tabelle è più pericolosa di una pagina infetta da un trojan o da un adaware. Internet Explorer 7 si è mosso in questo senso e, anche se sono condivisibili le ragioni di chi è rimasto deluso, non bisogna dimenticare che c'è ancora spazio per uno sviluppo positivo. In fondo, Opera è dovuto arrivare alla versione 9 per avere un eccellente supporto ai CSS, quindi c'è ancora un ampio margine per la crescita.

6. Da cosa dipendono i bug nei browser?

È opportuno a questo punto lasciare la parola ad uno dei creatori dei CSS, Håkon Wium Lie, che nella sua tesi sui CSS ne espone i limiti:

Fare l'authoring di una specifica tecnica vuol dire spesso trovare un equilibrio tra funzionalità da un lato ed implementabilità dall'altro. La funzionalità deve essere abbastanza ricca per affrontare i bisogni degli utenti, e abbastanza semplice per essere implementata in modo interoperabile.

Tradizionalmente i CSS hanno rivalutato la semplicità rispetto alla funzionalità. Per esempio, il sommario dei CSS1 afferma che i CSS sono un semplice meccanismo di fogli di stile. L'autore crede che questa sia stata una scelta corretta, ma vi sono tuttavia delle aree in cui i CSS avrebbero dovuto offrire una funzionalità più ricca:

Oltre all'elenco specifico di cui sopra, vi sono altre aree generali dove sarebbe stato importante uno sforzo maggiore:

Lie passa quindi ad esaminare il problema dell'eccesso di funzionalità nelle specifiche:

Come la mancanza di funzionalità, l'eccessiva funzionalità può essere pericolosa per una specifica. Gli implementatori possono giudicare la specifica troppo complessa e scegliere quindi di implementare solo alcune parti o ignorarle in toto. Il risultato è un'interoperabilità povera o mancante.

Le caratteristiche elencate di seguito sono descritte nelle specifiche CSS ma, si può dire, potrebbero essere tralasciate senza una perdita significativa. Tali caratteristiche sono relativamente complesse da implementare, e ci è voluto un lungo periodo per raggiungere l'interoperabilità.

Si può anche dire che altre parti dei CSS2 siano eccessive, dal momento che non sono state ampiamente implementate. Queste parti comprendono:

Quindi egli passa ad analizzare direttamente il problema delle implementazioni da parte dei browser:

Questa tesi si concentra sullo sviluppo dei CSS e di altri linguaggi di stile, ed è oltre il suo àmbito specifico l'analisi del livello di supporto CSS nei vari browser. Tuttavia, deve essere citato il fatto che, dal punto di vista degli autori, il problema più pressante nei primi anni dei CSS era la qualità del supporto CSS nei browser. Jeffrey Zeldman descrive la situazione nel 1998:

Se Netscape 4 ignora le regole CSS applicate all'elemento <body> e aggiunge dello spazio bianco casuale su ogni elemento strutturale delle vostre pagine, e IE4 riconosce <body> ma pasticcia col padding, quale tipo di CSS si potrebbe mai scrivere? Alcuni sviluppatori scelgono di non scrivere affatto i CSS. Altri scrivono un foglio di stile per compensare le falle di IE4 e un altro per compensare gli errori madornali di Netscape 4.

La citazione descrive efficacemente la difficile situazione nella quale si venivano a trovare gli autori: solo un piccolo sottoinsieme di proprietà CSS era implementato interoperabilmente tra Netscape4 e WinIE. La situazione gradatamente cambiò quando diminuì l'uso di Netscape4 e migliorò il supporto CSS in Internet Explorer [WASP 2004]:

Il W3C ha inventato i fogli di stile a cascata (CSS) nel 1996, per aumentare il grado di complessità presentazionale e l'accessibilità dei siti web, e per eliminare la marcatura proprietaria che minacciava di frammentare il Web emergente. Nel 1997, alcuni browser cominciarono a supportare parte dei CSS-1, ma lo standard non divenne realmente usabile fino al 2001.

Come suggerito nella precedente citazione, il 2001 fu un anno di svolta per i CSS. In quell'anno Microsoft rilasciò Internet Explorer 6.0 che, per quanto ancora incompleto e non esente da bug, ha un supporto usabile ai CSS. Da quell'anno sono stati rilasciati altri browser con un supporto eccellente dei CSS, tra cui Opera, Mozilla, e Internet Explorer for MacOS.

Un motivo per l'aumento di qualità nell'implementazione CSS è probabilmente la CSS1 Test Suite del W3C. La suite di test fu pubblicata per la prima volta nel 1998, 18 mesi dopo che i CSS1 divennero una Raccomandazione W3C. Se la suite di test fosse stata disponibile in una fase precedente, la svolta per i CSS sarebbe potuta avvenire prima.

Nessuno dei browser è stato in grado di competere con WinIE in termini di numero di utenti, e WinIE, perciò, ha in effetti definito un sottoinsieme di proprietà CSS che gli autori possono usare. Il supporto limitato ai CSS di WinIE, combinato con un monopolio de facto sui browser web, è attualmente il più grande problema per lo sviluppo dei CSS sul Web.

7. Come posso risolvere i bug dei browser?

Esistono molti siti sul Web che trattano nello specifico i bug dei browser ed offrono delle soluzioni. Il più celebre è sicuramente Position Is Everything. Su questo sito è anche disponibile una guida alla risoluzione dei bug:

I bug dei CSS possono essere difficili da isolare in modo osceno, specie quando si trovano nel mezzo di una pagina complessa e vasta con molti fogli di stile esterni. Oltre a questo vi è il fatto che pochi web designer hanno abbastanza esperienza per essere sicuri che quello che vedono è davvero un bug e non un errore nella stesura del codice.

Spesso la gente, quando si trova di fronte ad un bug misterioso, ci si butta alla cieca, e solo per pura fortuna troveranno una risposta. Così non va.

Seguendo la procedura riportata di seguito, si può ottenere rapidamente una chiara comprensione del problema, liberando così il web designer dall'onere di trovare una scappatoia o di evitare il bug in toto.

Fase uno: Validazione

Troppo spesso questa fase non viene seguita, il che è una vergogna, poichè la maggior parte dei bug misteriosi sono semplicemente dovuti a errori nel codice o nella digitazione. Per fortuna, sono disponibili strumenti di validazione online (HTML, CSS). Questi strumenti metteranno in luce errori nella validazione, e daranno anche degli avvertimenti sul codice qualora questo può causare dei conflitti con i fogli di stile utente et similia. Attenzione comunque: sono noti anche casi di errori anche con un codice apparentemente valido. Questo è abbastanza raro, comunque.

Fase due: Semplificare la cascata

Se tutto il CSS della pagina è contenuto nel documento sorgente, o se si trova all'interno di un solo file .css esterno, allora andate alla fase successiva. Altrimenti, è meglio inserire il CSS in un singolo documento.

Nota: Assicuratevi di avere copie di tutti i documenti prima di iniziare, non dopo, quando è troppo tardi.

Dopo aver tagliato ogni collegamento esterno, salvate e visualizzate la pagina. Se il collegamento è rimosso e il bug scompare, incollate il file .css nella locazione del collegamento. Se il collegamento è tagliato e il bug persiste, andate al collegamento successivo. Nel caso del tag <link>, il nuovo CSS incorporato deve essere racchiuso in <style></style>. Importante: ogni file .css esterno deve essere collocato nella stessa locazione del collegamento che lo richiama nella pagina.

Se non ci sono più file .css esterni e il bug è ancora presente, è tempo di iniziare il vero lavoro.

Fase tre: Taglia e incolla

Qui si tratta di tagliare sezioni di codice, salvare il file, e vedere se il bug è scomparso o meno. Se il bug è scomparso, incollate la sezione appena tagliata e tagliate la sezione successiva. Ovviamente, se il bug è ancora lì, non incollate la vecchia sezione di nuovo, ma passate alla successiva. Questo metodo si applica sia al CSS che all'HTML. Fare prima l'uno o l'altro dipende da voi.

Un metodo alternativo è quello di circondare le sezioni di codice con dei commenti. Questo vi semplifica la vita se dovete recuperare il codice nel caso abbiate 'perso' il bug e il sorgente risulti confuso, anche se è fin troppo facile annidare per sbaglio i commenti (non buono). Questo metodo non è veloce come il primo.

Dovete tenere a mente anche tutti i CSS 'inline' all'interno dell'HTML, e trattarli come il CSS incorporato. Se tagliate una regola di stile inline, e il bug ne risulta influenzato, incollatela nell'elemento head all'interno della regola appropriata e dopo le altre proprietà che si trovano in quella regola. Questo dovrebbe prevenire ogni alterazione nella cascata. Non dimenticate di visualizzare la pagina, tanto per essere sicuri.

Ricordate che qui il nostro obiettivo è quello di mantenere il bug presente mentre rimuoviamo quanto più codice possibile. Man mano che si va avanti le porzioni di codice si fanno sempre più piccole. Passate dall'HTML al CSS e viceversa, e non fermatevi finchè non c'è rimasto neppure un solo bit di codice che possa essere rimosso senza perdere il bug.

Fase quattro: Analisi

A questo punto la pagina è quello che si dice un 'test case minimale'. Ora potete aver risolto il problema e avergli detto addio, ma se non è così, fate un passo indietro e date un'occhiata a fondo al codice e alla pagina. Qui è dove la conoscenza del codice, le capacità di analisi e un osservazione acuta danno i loro frutti. Potreste 'giocare' col codice o andare su una buona risorsa come il W3C, o un pò l'uno o un pò l'altro. È fatta, comunque: a questo punto avrete imparato, garantito.

Come ultima spiaggia c'è sempre la mailing list css-discuss. Ogni bug che può sopravvivere a questo trattamento e continuare a ridersela, mi presenterà come una persona davvero in gamba ai suoi amici. E non dover mettere le mani su una montagna di documenti è davvero una gran cosa, prendetemi in parola. Sotto ora! Voglio dire, sbrigatevi ! Bè, lo sapete quello che voglio dire.

Nello specifico, oltre agli articoli sull'argomento, è presente anche una guida per la risoluzione dei bug di Internet Explorer:

È un fatto risaputo che il browser Internet Explorer (per Windows) ha un'ampia varietà di bug di visualizzazione. Per quanto possa sembrare appagante criticare questo browser, IE è di gran lunga il più popolare browser sul Web, sicchè piagnucolare sui suoi errori non è di grande aiuto. È triste che molti autori che desiderano passare ad un design senza tabelle inizino con grandi speranze, solo per vederle infrante da quella che a volte è conosciuta come la "collezione di bug di Explorer".

Alcuni di questi bug non sono affatto "bug", ma piuttosto errate applicazioni degli standard W3C. Sebbene una totale comprensione di come IE "sbagli" sia un lavoro a tempo pieno, è possibile farcela con un minimo di strumenti per risolvere i bug, che è proprio quello che questo articolo vuole insegnarvi. Pronti? Via!

Prepararsi all'azione

Prima di risolvere qualunque bug, è necessario assicurarsi che il problema sia davvero un bug, e non un modo improprio di scrivere il codice o la mancata comprensione di come funzioni il posizionamento con i CSS. Come prima cosa nella caccia ai bug dovreste leggere Debugging CSS, the Easy Way, che descrive in dettaglio questa fase preliminare. Descrive anche il modo con cui creare un "caso-test minimale", che può semplificare di molto l'individuazione dei problemi.

Ma realizzare questo caso-test richiede tempo, e gli impegni di lavoro spesso impediscono alla gente di percorrere questa strada. Comunque sia, è un metodo da usare caldamente raccomandato, ed è quello che mettiamo in pratica regolarmente. Anche quando si è realizzato un caso-test, non è sempre facile dare solo un'occhiata e dire "Ah! Ecco qua!". Sebbene sia vero che avere una vasta conoscenza dei bug aiuti a localizzare un problema, molti sviluppatori impegnati non hanno tempo di dedicarsi allo studio esteso dei bug.

Tuttavia, una volta che si è preparato un caso-test minimale, di solito restano davvero pochi elementi della pagina da considerare, e diventa possibile sparare "pallottole magiche" a vari elementi nel tentativo di risolvere il problema. Sappiate comunque che queste soluzioni non servono contro qualunque comportamento corretto dei browser scambiato per bug dai principianti dei CSS. Tocca a voi avere una salda padronanza delle basi dei CSS. Sull'argomento potete leggere i seguenti articoli:

Le soluzioni da discutere sono inutili contro ogni deliberata violazione delle specifiche CSS che s'incontrano in IE/Win. Per saperne di più sulle errate applicazioni degli standard (che non sono bug), si legga:

Un problema speciale su cui è importante soffermarsi è il modo in cui i float vengono annullati col clear, come descritto nell'articolo "Float: The Theory" citato sopra. IE di solito consentirà (in modo errato) ad un contenitore di includere un float innestato, anche quando non è presente alcun elemento di clear. Questo crea l'impressione che i browser diversi da IE sbaglino, quando chi sbaglia veramente è IE/Win. Non fatevi ingannare così come molti altri. Potete trovare utili informazioni sui problemi minori di visualizzazione nella serie di articoli "Common Coding Problems" qui su CMX (una ricerca dei termini Common Coding Problems vi darà una lista di tutti gli articoli della serie).

Presupponendo che questi problemi siano stati ben compresi o che non siano rilevanti per il vostro attuale problema, andiamo a vedere proprio i metodi di risoluzione dei bug, va bene?

{ position: relative }

Questa "pallottola magica" è stata la prima ad essere scoperta nel lontano dicembre 2001 da un certo autore le cui iniziali sono "BJ" (ehm...). Comunque sia, il problema era una tecnica sviluppata da Eric Meyer qui, che sembra "perforare" un box fuori dell'angolo di un altro box. Il metodo di Eric consiste nel far fluttuare un box nell'angolo superiore sinistro di un elemento che contiene del testo, e poi nell'usare i margini superiore e sinistro negativi della misura di 1px, che ha l'effetto di "spingere" il float in alto e a sinistra di 1px.

Questo consente al float di coprire (o oscurare) i bordi di 1px del box contenitore in quell'area. Poi il float ottiene un bordo inferiore e destro che sembra essere parte del bordo complessivo. Fantastico! Il problema di questo metodo era che Explorer per Windows falliva nell'oscurare in maniera esatta il bordo dell'elemento grande, rovinando il previsto effetto "scatola perforata". Sembra che IE/Win abbia un problema quando un elemento è posizionato con i margini negativi fuori dal box genitore che lo circonda.

La porzione ancora all'interno del "contenitore" genitore è visibile, ma ogni altra parte che va oltre il limite interno del bordo del contenitore sparisce! Succede che, applicando un semplice { position: relative; } al box interno posizionato coi margini negativi, le porzioni mancanti riappaiono magicamente. Perchè? Bè, spostando a destra... seriamente, nessuno sa perchè questo accada, eccetto forse gli sviluppatori Microsoft (ma loro non parlano). Basti dire che funziona.

Presto si scoprì che questa soluzione funzionava anche su altri bug di IE, nello specifico il Peekaboo Bug in IE6. Torneremo sul Peekaboo Bug fra un pò. Un altro uso principale di questa soluzione ricorre quando un'immagine flottata è in un contenitore, ed anche il contenitore o l'immagine flottata è stata resa "relative". In questo caso, l'immagine flottata si "nasconderà" dietro ogni background posto sull'elemento contenitore esterno. Rimuovendo il posizionamento relativo o rendendo emntrambi gli elementi relativi, si riporterà l'immagine flottata "sul davanti", permettendo che sia vista.

Problemi con la soluzione "relative"

Di solito questa soluzione non influenza in modo sfavorevole gli altri browser ma, come è stato spiegato nel caso delle immagini flottate, può essere necessario adottare una "doppia" soluzione, usando due volte { position: relative; }. Capire dove applicare questa soluzione non è di solito un problema. Si deve solo applicarla ad un elemento per volta e vedere se il bug viene eliminato. Nel caso in cui questa soluzione causa dei problemi negli altri browser, si può nascondere, dandola solo a IE/Win con i metodi illustrati nella prossima sezione.

Soluzione dei bug dimensionali

Una percentuale molto alta di bug di IE/Win è causata dalla mancanza di dimensioni date per gli elementi che contengono float innestati. In altre parole, se avete un box senza una width o un'height e vi innestate uno o più float all'interno, possono presentarsi i bug di visualizzazione più strani. Tali bug possono verificarsi senza float, ma sono molto più rari della varietà di quelli col float. Il Peekaboo Bug ricade in questa classe di "bug dimensionali", come l' Escaping Float Bug. C'è di nuovo il Peekaboo Bug!

Così questo diavolo dalla scorza dura è vulnerabile sia alla soluzione con "relative" che alla soluzione dimensionale! Molto interessante. Tale è la natura della "scienza" dei bug di IE. Questa specie di "buggosità" di IE relativa alle dimensioni si conosceva da diversi anni, ma conoscerla soltanto non era abbastanza. Molto spesso non è desiderabile applicare una dimensione al box con bug. Usare una height è di solito inaccettabile, poichè l'altezza settata di default su auto permette al contenuto del box di determinare l'altezza verticale visualizzata del box.

Se date al box un'altezza definita, essa può non uguagliare l'altezza del contenuto, specie se il testo è complesso e l'utente cambia la dimensione del testo del browser. Una width a volte può essere usata, ma spesso il design della pagina richiede che il box in questione sia "liquido", così da allargarsi o restringersi automaticamente a seconda del variare della dimensione della finestra. Si, una larghezza in percentuale può anche farlo, ma cosa succederebbe se il box è una colonna centrale che ha bisogno di colonne laterali dimensionate in pixel accanto ad essa? È impossibile avere una larghezza in percentuale in un box e margini in pixel sullo stesso box, perchè nessuno può prevedere l'esito di un confronto fra pixel rigidi e percentuali fluide.

Chiaramente usare width come una dimensione per risolvere i bug è meno che soddisfacente. Non sembrava esserci un modo limpido di svolgere questo compito, ma, per uno strano scherzo del fato, lo stesso browser Explorer ci venne in aiuto.

Il trucco del box che si espande

I guru dei CSS sanno da tempo che quando IE/Win vede che un box ha una dimensione fissa che non è larga abbastanza da racchiudere il contenuto del box, il browser allargherà erroneamente l'ampiezza del box per farci entrare righe che non possono essere spezzate, come lunghi URL. IE/Win estenderà anche l'altezza di un box, così che il contenuto non fuoriesca oltre il bordo inferiore del box. I browser che seguono più strettamente le specifiche del W3C lasciano che il contenuto extra sporga oltre l'altezza o la larghezza del box.

L'Holly Hack

Poichè IE/Win sbaglierà in questo modo, quando c'è bisogno di una dimensione per risolvere un bug nel float, una piccola altezza, come { height: 1% }, si può applicare al contenitore del float, ed IE/Win renderà comunque il box più alto. Così una piccola altezza non cambia l'aspetto del box, ma IE sembra pensare che il box ora è "dimensionato", e così la nostra pallottola magica colpisce nel segno. Un bug in meno.

Dettagli dell'hack

Poichè gli altri browser non hanno il bug e, cosa più importante, non espandono erroneamente box definiti in altezza, questa altezza per risolvere i bug dovrebbe essere nascosta ai browser diversi da IE/Win. Non è necessario nascondere questa soluzione alle precedenti versioni di IE/Win, perchè sebbene non abbiano il Peekaboo Bug, hanno altri bug dimensionali e tutti applicano il trucco dell'espansione. Comunque, IE5/Mac non espande i box in modo scorretto, così far vedere a questo browser la piccola altezza di sicuro danneggia la sua visualizzazione.

Quindi l'altezza deve essergli nascosta, come per gli altri browser diversi da IE. Il codice seguente è un esempio dell'Holly Hack. Per prima cosa, l'Holly Hack consiste in un gruppo di metodi per nascondere messi intorno all'height 1%, che è la chiave dell'hack. Ricordate: l'idea è di far vedere ad IE/Win (e solo ad IE/Win) questa altezza e di applicarla al box con bug. 

/* Nasconde da IE5-mac \ */
* html .buggybox {height: 1%;}
/* Fine per IE5-mac */

Due hack in uno: La prima riga del codice è un commento CSS con un "escape" prima del tag di chiusura del commento. La presenza di un carattere di escape fa si che IE5/Mac ignori il tag di chiusura del commento, e pensi che il commento sia ancora attivo. Così ignora tutto finchè non vede quello che pensa sia un corretto tag di chiusura di un commento CSS. L'ultima riga dell'hack è un normale commento CSS, e il suo tag di chiusura è quello che fa iniziare a IE5/Mac ad interpretare di nuovo il codice.

Ci riferiamo generalmente a queste due righe (la superiore e l'inferiore nel codice di sopra) come al "Mac-hack", o meglio "comment-backslash hack". Il secondo (o riga di mezzo) ha, in questo esempio, tre voci separate da combinatori discedenti, che sono gli spazi che vedete, e quindi la proprietà height all'interno delle parentesi graffe. La prima voce è un selettore universale (o stella, *), che seleziona ogni elemento, seguito da html (entrambi in rosso), seguito dall'elemento sospettato di avere il bug. Il codice di sopra seleziona un elemento con l'attributo di classe buggybox, che è un discendente di un elemento html (il che sarà sempre vero), quando lo stesso html è discendente di ogni elemento (*), e applica una { height: 1% } a questo elemento (in questo caso .buggybox).

Accade così perchè tutti i browser IE, sia Win che Mac, riconoscono un invisibile e misterioso elemento contenitore intorno ad <html>. L'uso del selettore universale che precede html, conosciuto anche come Tan Hack (o Star HTML Selector Bug), funziona nei browser IE e in nessun altro. Sicchè il motivo per usare il "Mac-hack" è di impedire che IE5/Mac veda l'altezza come gli altri browser, dato che non allarga erroneamente il box come IE/Win, ma gli fa leggere il Tan Hack.

Si noti che l'elemento a cui va data l'altezza non ha bisogno di una classe. Ogni valido selettore può essere inserito al posto di .buggybox, e si possono usare anche intere stringhe che usano combinatori discendenti. La cosa davvero importante è che * html deve sempre precedere qualunque elemento da fixare, e che * e html hanno uno spazio fra loro, seguito da un altro spazio, e poi l'elemento. Ci sono altri metodi che possono essere usati per dare ad IE/Win l'altezza corretta di cui ha bisogno, senza darla agli altri browser.

Un metodo è impostare la piccola altezza nel selettore regolare per l'elemento, e poi sovrascrivere questa altezza col valore auto in un successivo selettore che usa un combinatore figlio ( > ), che IE/Win non riconosce. Ciò richiede la conoscenza del genitore diretto del box con bug. Non è una buona idea usare spazi attorno al combinatore figlio, perchè può provocare bug. Un altro metodo è usare il Tan Hack per nascondere l'altezza ai browser diversi da IE, e poi sovrascrivere questa altezza solo per IE5/Mac, usando una versione modificata per Mac del Tan Hack, che di nuovo usa il combinatore figlio per impedire ad IE/Win di leggere il valore ridefinito.

La versione Mac richiede un carattere di escape (un backslash, \), da usare in ogni nome di proprietà incluso in un gruppo di regole per impedire ad IE5/Win di leggere le regole. Nella versione del Tan Hack modificata per Mac, il combinatore figlio rimpiazza il combinatore discendente normalmente usato fra la stella (*) e html. Ciò è mostrato in rosso nell'ultima riga sotto. L'escape (il carattere backslash, anch'esso in rosso) è usato nella proprietà height. Entrambi i metodi alternativi appena descritti sono mostrati nel seguente codice. 

Sovrascrittura col combinatore figlio
.buggybox {height: 1%;}
#parentElement>.buggybox {height: auto;}

Tan Hack modificato per Mac
/* per IE/Win */
* html .buggybox {height: 1%;}
/* per IE5/Mac */
*>html .buggybox {he\ight: auto;}

Quale metodo scegliere? Bè, come con la maggior parte delle cose relative ai CSS, dipende. Delle tre opzioni presentate, quello che useremmo con meno probabilità è il metodo di sovrascrittura col combinatore figlio. Preferiamo avere il selettore originale per un elemento che contiene il corretto valore per le proprietà definite al suo interno, e usare un hack (o filtro, come vengono chiamati a volte), per fornire valori alternativi ad IE/Win. Gli altri due metodi derivano da una questione di preferenze.

Nota: Il metodo di sovrascrittura col combinatore figlio è il nome che abbiamo dato al metodo descritto nel codice di sopra. Per quel che sappiamo, non c'è attualmente alcun nome usato per questo metodo, nè per la versione del Tan Hack modificato per Mac. Sappiate comunque che se una futura versione di IE/Win supporterà alla fine il combinatore figlio, questo hack può ritorcersi contro di noi, facendo vedere ad IE/Win l' "errato" valore dell'altezza, a seconda di quali cambiamenti possono verificarsi in questo browser.

Uso dei trucchi

Per quanto avere un "caso-test minimale" per provare queste soluzioni sia il metodo migliore, a volte è possibile per uno sviluppatore CSS saltare questo passo ed applicarle direttamente alle parti di una grande pagina complessa nella speranza di "avere fortuna". Questo approccio può essere comunque problematico per i principianti, poichè quello che può sembrare come un bug è spesso un comportamento corretto, o una violazione delle specifiche di IE/Win. Una buona regola (a lume di naso) è comparare la visualizzazione di un sospetto bug di IE/Win con la visualizzazione in Opera 7 e in un browser basato su Mozilla.

Se entrambi questi browser visualizzano bene, allora è sicuro che state vedendo un bug di IE o un comportamento scorretto. Riconoscerlo è un'altra faccenda, che richiede la conoscenza del modello float di IE, del box model di IE, del problema dei 3px di IE e a volte anche d'altro. Queste due "pallottole magiche" possono fare meraviglie, mettendo gli autori in condizione di utilizzare molti layout che in precedenza erano fuori portata a causa dei bug di IE. Non ci sono affatto panacee, per quanto a volte possa sembrare così, e certamente non vi sono sotituti per le giuste pratiche di scrittura del codice. Sebbene vi siano altre soluzioni non descritte qui, quelle di cui abbiamo parlato sono le principali armi in uso oggi per eliminare i bug nei design complessi senza tabelle. Un recente (e pieno di trucchi) layout col float usa ben otto Holly Hack per forzare "quel browser" verso la conformità. Bang! Bang!

Un altro documento da conoscere è sicuramente quello relativo alla proprietà di scripting hasLayout e alla sua influenza sul rendering di Internet Explorer, dal titolo On Having Layout:

Introduzione

Molte delle insufficienze di rendering di Internet Explorer possono essere risolte fornendo ad un elemento "layout". John Gallant ed Holly Bergevin hanno classificato queste insufficienze come "bug dimensionali", ossia che si possono risolvere applicando una width o height. Questo ci porta alla domanda sul perchè "layout" può cambiare il rendering e la relazione fra e degli elementi. Alla domanda, seppur buona, è difficile dare una risposta. In questo articolo gli autori si concentreranno su alcuni aspetti di questa complicata materia. Per ulteriori discussioni ed esempi, si faccia riferimento ai link forniti.

hasLayout - Una definizione

"Layout" è un concetto proprietario di IE per Windows che determina come gli elementi, in analogia ad una finestra, delineino e delimitino il loro contenuto, interagiscano e si rapportino con gli altri elementi, e reagiscano e trasmettano eventi utente-applicazione.

Gli sviluppatori della Microsoft hanno stabilito che gli elementi di tipo box debbano essere in grado di acquisire una "proprietà (nel senso della programmazione orientata agli oggetti) che essi indicano come layout, o in alternativa hasLayout. hasLayout non è probabilmente nè una proprietà e neppure un comportamento, ma piuttosto un concetto di rendering insito nel motore che da una qualità ad un elemento.

Di fatto questa qualità di rendering può essere irreversibilmente inizializzata a true da alcune proprietà dei CSS, ed alcuni elementi HTML hanno "layout" di default.

Nomenclatura

Diciamo di un elemento che "ha layout" o che "ottiene layout", quando per quell'elemento la proprietà proprietaria di Microsoft hasLayout è settata a true. Un "elemento layout" può essere qualunque elemento che ha layout di default o che ha ottenuto layout con un'appropriata impostazione di una proprietà CSS.

Negli elementi "non-layout", hasLayout non è settato (o meglio è false), per esempio un semplice div senza alcuna dimensione può essere un "contenitore non-layout".

Dare o applicare "layout" ad un elemento che non lo ha di default vuol dire impostare una proprietà CSS che inizializzi hasLayout=true per l'elemento in questione. Si veda 'Elementi aventi layout di default' e 'Proprietà' per questa elencazione. Non c'è modo si settare hasLayout=false tranne che rimuovere la proprietà CSS che ha causato hasLayout=true.

Le carte che abbiamo giocato

Il problema di hasLayout riguarda designers (e scrittori di codice) di ogni livello di esperienza. Layout ha sia effetti insoliti e difficili da prevedere sul comportamento della visualizzazione di box che hanno layout, sia implicazioni per gli elementi figli all'interno dei box.

Le conseguenze di un elemento che ha o non ha "layout" possono includere:

La lista di sopra è breve ed incompleta. Questo articolo cercherà di descrivere più nel dettaglio i problemi incontrati nell'applicazione di "layout" o dalla mancanza di questo.

Da dove viene layout

Diversamente dalle proprietà standard, o anche dalla proprietà CSS disponibili nei vari browser, layout non è assegnato direttamente tramite dichiarazioni CSS. In altre parole, non vi è una "proprietà CSS layout". Alcuni elementi "hanno layout" automaticamente e per altri esso è semplicemente aggiunto quando si fanno varie dichiarazioni CSS.

Elementi aventi layout di default

I seguenti elementi hanno layout di default.

Proprietà

Le seguenti coppie CSS valore-proprietà permetteranno ad un elemento, se applicate, di ottenere layout.

position: absolute
Si riferisce al suo blocco contenitore. Qui iniziano alcuni problemi.
float: left|right
Il modello float ha molte stranezze dovute ad alcuni aspetti di un elemento layout.
display: inline-block
A volte è un rimedio quando l'elemento è a livello inline ed ha bisogno di layout. Applicare layout è probabilmente l'unico effetto reale di questa proprietà. Il "comportamento inline-block" stesso può essere ottenuto in Internet Explorer, ma indipendentemente: IE Windows: inline-block e hasLayout.
width: qualunque valore
È spesso una soluzione implicita, e più spesso una causa quando hasLayout sbaglia qualcosa.
height: qualunque valore
height: 1% è usata nell'Holly Hack.
zoom: qualunque valore ( MSDN)
Proprietaria Microsoft, non supera la validazione. zoom: 1 può essere usato per il debugging.
writing-mode: tb-rl ( MSDN)
Proprietaria Microsoft, non supera la validazione.

In Internet Explorer 7, overflow è diventato un inizializzatore di layout.

overflow: hidden|scroll|auto
Nelle precedenti versioni questa proprietà non aveva effetto, tranne quando il box aveva "layout" per altre cause.
overflow-x|y: hidden|scroll|auto
Come parte del modulo del box model CSS3, overflow-x e y non sono ancora stati ampiamente implementati. Non inizializzavano hasLayout nelle precedenti versioni di Internet Explorer.

E nuovi attori di hasLayout sono apparsi sullo schermo di Internet Explorer 7. Per quanto riguarda hasLayout, le proprietà min/max agiscono similmente a width ed height e gli effetti del posizionamento fisso ed assoluto sembrano identici.

position: fixed
./.
min-width: qualunque valore
Anche il valore 0 fa ottenere layout all'elemento.
max-width: qualunque valore oltre a none
./.
min-height: qualunque valore
Anche il valore 0 setta hasLayout=true.
max-height: qualunque valore oltre a none
./.

Basato su query con la Developer Toolbar di Internet Explorer e su test preliminari.

Note sugli elementi di tipo inline

Per gli elementi inline (sia inline di default come span, o che hanno display: inline)

Gli elementi che hanno sia "layout" che display: inline si comportano in modo simile a quanto detto dagli standard sugli elementi inline-block: fluiscono orizzontalmente come parole in un paragrafo, sono sensibili al vertical-align, e "si stringono" attorno al loro contenuto. Non appena gli elementi inline hanno layout, si comportano come elementi inline-block, e questo spiega perchè, in IE/Win, gli elementi inline possono contenere e controllare elementi block-level con meno problemi che negli altri browser, dove display: inline rimane inline.

La proprietà script hasLayout

Abbiamo scelto di riferirici a hasLayout come ad una "proprietà di script" per distinguerla dalle proprietà CSS a noi familiari.

Si noti che quando un elemento ha layout, non v'è modo di settare hasLayout=False.

La proprietà hasLayout può essere usata per verificare se un elemento ha layout: se ad esempio esso ha "eid" come id, allora semplicemente scrivere nella barra degli indirizzi di IE5.5+ javascript:alert(eid.currentStyle.hasLayout) testa il suo stato.

La IE Developer Toolbar consente di fare un'ispezione in tempo reale dello stile corrente di un elemento; quando hasLayout è true il suo valore è riportato come "-1". Editando in tempo reale gli attributi di un nodo, si può settare "zoom (css)" a "1" per dare hasLayout a scopo di debugging.

Altra cosa da considerare è come "layout" condizioni lo scripting. Le proprietà clientWidth/clientHeight restituiscono sempre zero per gli elementi senza "layout". Questo può confondere i neofiti dello scripting ed è diverso da come si comportano i browser basati su Mozilla. Possiamo usare questo fatto per determinare "layout" per IE5.0: se clientWidth è zero allora l'elemento non ha layout.

CSS hack

I seguenti hack per inizializzare hasLayout sono stati testati con successo in IE6 ed inferiori. Future versioni di IE potrebbero reagire differentemente. Li riesamineremo quando saranno pubblicate nuove versioni di questo browser.

John Gallant e Holly Bergevin hanno pubblicato l'Holly Hack nel 2003.

  1. /* \*/
  2. * html .gainlayout {height: 1%;}
  3. /* */

Oppure possiamo usare l'underscore hack:

  1. .gainlayout {_height: 0;}

In alternativa, e forse più validi per il futuro, ci sono i commenti condizionali:

  1. <!--[if lte IE 6]>
  2. <style>
  3. .gainlayout {height: 1px;}
  4. </style>
  5. <![endif]-->

L'uso di un foglio di stile esterno per tutto ciò che soddisfa i bisogni di IE-Win, linkato all'interno di un commento condizionale, è una soluzione altrettanto sicura ed elegante:

  1. <link rel="stylesheet" href="allbrowsers.css" type="text/css" />
  2. ...
  3. <!--[if lte IE6]>
  4. <link rel="stylesheet" href="iefix.css" type="text/css" />
  5. <![endif]-->

Preferiamo height: 0 e 1px - height dovrebbe "sempre" essere usata a meno che non vada in conflitto con qualcos'altro (overflow: hidden). Per quel che riguarda il valore, preferiamo evitare 1%, poichè può (seppur molto raramente) causare problemi.

Un caso notevole, quando non possiamo usare height, è quando, in modalità standard, abbiamo un elemento inline. Questo è un caso in cui useremmo display: inline-block, o zoom: 1.

Abbiamo visto disperati tentativi di "holy" hacks (sic!) applicati ad elementi flottanti, o ad elementi che hanno già una larghezza. Si ricordi che l'obiettivo di questo hack non è quello di applicare un'altezza ad un elemento, ma di inizializzare hasLayout = True.

Non date layout a tutti: * {height: 1px;}. Questa concentrazione è veleno, ed avere layout non è una panacea, poichè cambia il rendering alla base.

Gestione degli hack

I browser cambiano, e dobbiamo affrontare il problema che deriva dai bug che saranno risolti in IE7 e superiori: inevitabilmente alcuni hack per IE6 potrebbero diventare dannosi nelle nuove versioni del browser, oppure nuove versioni del browser con simili bug nel layout potrebbero non accettare più filtri come * html. Sotto questo aspetto, l'uso del proprietario zoom può essere tenuto in considerazione.

  1. <!--[if lt IE 7]><style>
  2. /* style for IE 6 + IE5.5 + IE5.0 */
  3. .gainlayout {height: 0;}
  4. </style><![endif]-->
  5. ...
  6. <!--[if IE 7]><style>
  7. .gainlayout {zoom: 1;}
  8. /* or whatever we might need tomorrow */
  9. </style><![endif]-->

Anche se pensiamo che "pronto per il futuro" sia una contraddizione in termini, raccomandiamo caldamente al web designer di "andare sul sicuro" e di rivedere le sue pagine per gli hack impliciti ed espliciti, usando i commenti condizionali per servire questi hack alla versione del browser appropriata.

Breve nota su Internet Explorer per Macintosh

IE Mac e IE Win sono due animali diversi, che vivono in parti separate dello zoo. Ciascuno ha il suo proprio motore di rendering, e IE Mac non conosce affatto il comportamento di "hasLayout" (o di contenteditable). Il motore di rendering di IE Mac tende ad essere piuttosto conforme agli standard, ad esempio con height trattata come height, come dovrebbe essere. Gli hack e i workaround per i problemi di "hasLayout" (specie quando si usano le proprietà height e width) avranno spesso effetti nocivi su IE Mac, e dovrebbero essere nascosti a questo browser. Più informazioni sui problemi di IE Mac si possono trovare nella pagina sulle stranezze e sui bug di IE Mac.

Documentazione MSDN

In MSDN vi sono davvero poche pagine legate alla proprietà Microsoft hasLayout, ed ancor meno è spiegato come tale proprietà sia correlata con il modello di formattazione visuale di IE.

Andando indietro fino ad IE4, quasi ogni elemento aveva una specie di layout, tranne semplici elementi inline non posizionati assolutamente e senza alcuna dimensione ( MSDN ). Ed in questa antica concezione di layout vi erano "proprietà di layout" come border, margin, padding, che non potevano essere applicate ad un semplice elemento inline. In altre parole, "avere layout" era solo un altro termine per esprimere rozzamente: "possono avere queste proprietà".

MSDN parla ancora di "proprietà di layout", ma il significato è cambiato, non essendo più associate con elementi che hanno layout. In IE5.5, la proprietà Microsoft hasLayout fu introdotta più o meno come un flag interno.

In IE5.5, la documentazione della Editing Platform MSHTML (che consente l'editing in tempo reale, il ridimensionamento ed il trascinamento di elementi di layout tramite <body contenteditable=true>) rivela tre importanti aspetti legati all'avere layout:

Se un elemento con layout ha contenuti, il layout dei suoi contenuti è determinato dal rettangolo che lo delimita.

Avere layout significa essenzialmente che un elemento è rettangolare.

Internamente, avere layout significa che un elemento è responsabile della rappresentazione del suo contenuto.

( Editing Platform )

Il funzionamento interno di IE correlato al layout stesso non era stato documentato fino all'agosto 2005 quando, come risultato della task force del Web Standards Project e di Microsoft, Markus Mielke [MSFT] aprì la porta ad una esauriente discussione:

In generale, gli elementi nel motore Dynamic HTML di Internet Explorer non sono responsabili della loro stessa sistemazione. Un elemento div o p possono avere una posizione all'interno dell'ordine del codice sorgente e del flusso del documento, ma i loro contenuti sono sistemati dal loro antenato più prossimo con layout (di frequente body). Questi elementi si relazionano al layout dell'antenato per determinare le informazioni di dimensione e di misurazione per loro.

( HasLayout - Sguardo d'insieme )

Interpretazione

La nostra interpretazione è un tentativo di spiegare ciò che accade nei casi conosciuti, e dovrebbe servire da guida per i casi non ben conosciuti. Il tentativo di decifrare una scatola nera inserendoci solo dei casi-test ed ascoltando se fa rumore è destinato al fallimento. Alla domanda "perchè" non si può rispondere. Dobbiamo cercare di comprendere la struttura in cui l'intero modello "hasLayout" opera, e come esso influenzi il rendering dei documenti web. Perciò si possono sviluppare delle linee guida (e queste possono essere solo delle linee guida, non soluzioni definitive).

Pensiamo che un elemento con layout sia come una piccola finestra. Il suo contenuto sarebbe completamente indipendente da ogni cosa al di fuori del confine dell'elemento, e il contenuto allo stesso modo non potrebbe influenzare nulla al di fuori.

La proprietà Microsoft hasLayout è una sorta di flag: quando è settata, l'elemento ha questa speciale "qualità" layout, la quale include capacità speciali sul floating, sul clearing, sullo stacking, sul counting e così via, sia per l'elemento stesso che per gli elementi figli che non hanno tale "qualità" layout.

Questa maggiore indipendenza degli elementi con layout è probabilmente la ragione per cui essi sono di solito più stabili, e quindi sono utili per risolvere alcuni bug. Il prezzo che si deve pagare può essere sia una minore aderenza agli standard, che ulteriori bug e problemi ai loro confini.

Estrapolando un pò, il modello di pagina web della Microsoft può essere visto come un'insieme di piccoli blocchi di storie scollegate tra di loro, mentre il modello W3C è piuttosto una narrazione continua, un insieme di blocchi collegati tra di loro.

Esame delle conseguenze

Clearing dei float ed estensione per includere

I float sono auto-contenuti dagli elementi con layout. Questo è il motivo per cui molti principianti hanno difficoltà con le loro pagine costruite per Internet Explorer in un browser compliant, dove i float sporgono dal contenitore quando non viene applicato il clear.

Il comportamento opposto: cosa succede se un float deve sporgere dal suo contenitore, cioè quando l'auto-contenimento non è l'effetto desiderato? Per una dimostrazione dei problemi frustranti che si possono incontrare, controllate le nostre discussioni approfondite:

In IE, un float "apparterrà" sempre al suo contenitore con layout. Gli elementi successivi potrebbero rispettare il contenitore con layout, ma non il float stesso.

Questo, e l'espansione in IE6 di un contenitore per includere ogni contenuto più ampio (l' "estensione-per-includere"), possono essere visti come un aspetto della regola "determinato dal rettangolo che lo racchiude".

Anche peggio: clear non può influenzare un float al di fuori del contenitore con layout che include il clear. I layout di pagina che utilizzano i float e si basano su questo bug di IE non si possono trasferire per farli funzionare su un browser standard-compliant senza un generale rifacimento.

Si veda la sezione 'Similarità con le specifiche CSS' per ulteriori informazioni.

Elementi vicini ai float

Quando un blocco segue un elemento che flotta a sinistra, il contenuto di testo dovrebbe scorrere a destra del float e poi scivolare sotto il float. Ma se il blocco ha layout, ad esempio perchè è impostata una larghezza per qualche motivo, l'elemento con layout si comporta come un rettangolo ed il testo non scivola sotto il float. La larghezza è erroneamente calcolata partendo dalla destra del float, sicchè width: 100% si va ad aggiungere alla larghezza del float, ed il risultato è una barra di scorrimento orizzontale. Questo è ben lontano dalle specifiche.

Similmente gli elementi posizionati relativamente vicini ai float dovrebbero scostarsi rispetto al limite del padding del genitore (ad esempio left: 0 in un elemento posizionato relativamente lo posizionerebbe sopra un box flottato che lo precede). In IE lo scostamento left: valore inizia dal limite del margine destro del float, causando un disallineamento orizzontale della complessiva ampiezza esterna del float (una soluzione è usare margin-left, ma bisogna stare attenti ai problemi nel calcolo delle percentuali).

Secondo le specifiche, i float si intrecciano con i box che seguono. Ciò non si adatta con rettangoli bidimensionali che non si intersecano.

(Ri)visitando questa pagina sul bug:

vedremo che il box con layout che segue il float non mostrerà il 3px jog del testo, perchè i 3px che circondano il float non possono più influenzare il contenuto dentro l'elemento con layout, ma spostano l'intero documento di 3px. Come un guscio, layout impedisce al contenuto di essere influenzato, ma l'energia della spinta del float sposta il box stesso racchiuso nel guscio.

Si veda la sezione 'Similarità con le specifiche CSS' per ulteriori informazioni.

Liste

Le liste sono influenzate da layout applicato sia alla lista (ol, ul) che agli elementi di lista (li). Differenti versioni di IE reagiscono in modo diverso. Gli effetti più evidenti sono sui marcatori di lista (liste completamente personalizzate dove i marcatori non sono richiesti non avranno questi problemi). I marcatori sono creati probabilmente dall'interno aggiungendo alcuni elementi che sono in qualche modo "agganciati" agli elementi di lista (solitamente sporgono al di fuori di essi) e sembrano piuttosto instabili. Sfortunatamente, essendo solo oggetti "interni", non possono essere raggiunti per cercare di correggere i comportamenti errati.

Gli effetti più evidenti sono:

A volte essi possono essere ripristinati cambiando i margini sugli elementi di lista. Ciò appare come una conseguenza del fatto che un elemento con layout tende a tagliare gli elementi interni sporgenti al suo esterno.

Un ulteriore problema è che (nelle liste ordinate) ogni elemento di lista con layout sembra avere un suo proprio contatore. Poniamo di avere una lista ordinata con cinque elementi dove solo il terzo ha layout. Vedremo questo:

1... 2... 1... 4... 5...

Inoltre quando un elemento di lista con layout si dispone su linee multiple, il marcatore è allineato verticalmente alla parte inferiore (non a quella superiore, come ci si aspetterebbe).

Alcuni di questi problemi non possono essere risolti, sicchè quando si vogliono avere i marcatori è megli evitare layout sulle liste e sugli elementi di lista. Se è necessario applicare delle dimensioni, è meglio applicarle ad altri elementi: per esempio l'ampiezza può essere applicata ad un contenitore esterno, e l'altezza al contenuto di ogni voce di lista.

Un altro problema comune con le liste in IE accade quando il contenuto di ogni li è un'ancora con display: block. In queste condizioni lo spazio bianco fra le voci di lista non è ignorato, e di solito è mostrato come una linea extra per ogni li. Uno dei metodi per evitare questo spazio verticale extra è dare layout alle ancore di tipo blocco. Questo sistema ha anche il beneficio di rendere cliccabile l'intera area rettangolare delle ancore.

Tabelle

Una table ha sempre layout, e si comporta sempre come un oggetto di larghezza definita. In IE6, table-layout: fixed di solito equivale ad una tabella di ampiezza pari al 100%, con tutti i problemi che ciò comporta (computazioni erronee). Come nota aggiuntiva, solo poche cose sulla situazione in IE5.5 e il "quirks mode" in IE6.

Elementi posizionati in modo relativo

Si noti che position: relative non inizializza hasLayout, che porta ad alcuni errori di rendering, per lo più facendo scomparire o posizionando male il contenuto. Queste insufficienze si possono incontrare ricaricando la pagina, ridimensionando la finestra, facendo scrolling o selezionando. Con questa proprietà, IE scosta l'elemento, ma sembra dimenticarsi di inviare un segnale di "ridisegnamento" agli elementi suoi figli aventi layout (un elemento con layout l'avrebbe inviato correttamente nella successione di segnali di ridisegnamento).

sono descrizioni correlate. Come regola pratica, non posizionate mai un elemento relativamente senza settare layout. In aggiunta, si deve controllare se il genitore di un tale costrutto necessita di layout e/o anche di position: relative. Questo diventa essenziale quando vengono coinvolti i float.

Elementi posizionati in modo assoluto: blocco contenitore, quale blocco contenitore?

È essenziale comprendere il concetto CSS di blocco contenitore, che risponde alla domanda su dove si debba relazionare un elemento posizionato in modo assoluto, sia per definire l'origine dello scostamento che per stabilire rispetto a cosa si calcolino le percentuali delle misure.

Per gli elementi posizionati in modo assoluto, il blocco contenitore è stabilito dall'antenato posizionato più vicino. Se non vi è tale antenato, viene usato il blocco contenitore iniziale html.

Normalmente imposteremmo tale blocco contenitore tramite position: relative. Il che vuol dire che possiamo far relazionare gli elementi posizionati in modo assoluto a misure e origini indipendenti dal flusso degli elementi, sia per soddisfare i bisogni del concetto di accessibilità che recita "prima il contenuto", che per semplificarci la vita nei layout complessi basati sui float.

Questo concetto di design è messo in discussione da IE, a causa del concomitante concetto di layout: l'elemento posizionato in modo assoluto è scostato rispetto al suo più vicino antenato posizionato e con layout, ma una dimensione in percentuale si relaziona al più vicino antenato. Si noti la netta differenza, e come detto poc'anzi position: relative non inizializza hasLayout.

Posto che un genitore non-layout sia posizionato relativamente, siamo costretti ad impostare layout per questo genitore per far funzionare lo scostamento:

Posto che un genitore non posizionato debba avere una dimensione, e che il design faccia affidamento sul calcolo di una larghezza espressa in percentuale, possiamo abbandonare tale idea, per una carenza di supporto nel browser:

Filter

La Microsoft-proprietaria filter è applicabile solo ad elementi di layout. Alcuni ampliano i confini di un oggetto. Mostrano i loro errori specifici: http://www.satzansatz.de/cssd/tmp/alphatransparency.html.

Risistemazione degli elementi renderizzati

Una volta che tutti gli elementi di una pagina sono renderizzati, se avviene una transizione a:hover (per esempio un cambio di background di un link) IE risistema l'intero blocco contenitore avente layout. A volte gli elementi vengono posizionati in una nuova posizione, poichè al momento in cui si incorre nell'hover IE conosce tutte le ampiezze e gli scostamenti degli elementi correlati. Di solito questo non accade al primo caricamento della pagina, quando l'ampiezza non è ancora determinata a causa della caratteristica estensione-per-includere. Ne può conseguire un salto sull'hover:

Questi bug relazionali, basati sul problema della risistemazione, creano problemi nei layout liquidi, dove è più comune l'uso di percentuali per margini e padding.

Origine del background

La proprietà Microsoft hasLayout influenza l'estensione ed il posizionamento del background. Ad esempio, secondo le specifiche CSS, background-position: 0 0 dovrebbe riferirsi all' "estremità del padding" dell'elemento. In IE/Win si riferisce all' "estremità del bordo" quando hasLayout = false, e all' "estremità del padding" quando hasLayout= true:

Margini che collassano

La proprietà Microsoft hasLayout influenza il collassamento dei margini fra un box ed i suoi discendenti. Secondo le specifiche, il margine superiore di un box senza padding superiore e senza bordo superiore collassa con il margine superiore del suo primo figlio di tipo blocco nel flusso:

In IE/Win questo non accade mai quando il box ha layout: sembra che layout impedisca ai margini del figlio di sporgere fuori dal box contenitore. Inoltre quando hasLayout è true, sia sul contenitore che sul figlio, si evidenziano altre computazioni errate dei margini:

Link di tipo blocco

hasLayout influenza l'area cliccabile e di hover di un'ancora di tipo blocco. Di solito con hasLayout = false solo la parte coperta dal testo è sensibile. Con hasLayout = true l'intera area del blocco è sensibile. La stessa condizione è vera per ogni elemento di tipo blocco con annesso handler di un evento onclick/onmouseover.

Navigazione da tastiera nella pagina: un'odissea

Quando si usa il tasto TAB in una pagina e si seleziona un link nella pagina, la successiva pressione del tasto TAB non riprenderà sul link successivo:

Il tasto TAB porterà (spesso in modo errato) l'utente al primo target del più vicino antenato con layout (se l'antenato con layout è uno tra table, div, span e certi altri elementi).

Contenitori che si "stringono" attorno al contenuto

Alcune proprietà applicate ad elementi con width: auto li spinge a computare la loro ampiezza con un algoritmo che rimpicciolisce l'elemento stesso fino a stringersi attorno al suo contenuto. Esempi di tali proprietà sono:

Questo funziona in IE/Win, naturalmente limitato alla proprietà supportate. Ma quando l'elemento che dovrebbe restringersi contiene un blocco con "layout", allora nella maggior parte dei casi tale figlio si espande per l'intera ampiezza disponibile, indipendentemente dal suo conteuto, e previene l'effetto di rimpicciolimento del genitore.

Il rimpicciolimento del contenitore resta attivo solo se il figlio con layout ha una larghezza assegnata, o ha una proprietà di restringimento esso stesso, come ad esempio float.

Il clipping oltre l'estremità

In generale, quando un box contiene più strutture complesse come contenuto sporgente, "hasLayout" su questo contenitore è spesso necessario per evitare problemi di rendering. Questo quasi-requisito causa un dilemma nelle zone di confine, poichè un elemento che ottiene "layout" diviene una sorta di box chiuso in sè stesso.

Box interni che vengono mossi al di fuori di tale elemento (usando ad esempio margini negativi) vengono "ritagliati".

Le porzioni ritagliate possono essere ripristinate inizializzando "hasLayout" sui box interni e si richiede anche position: relative in IE6. Il comportamento di IE7 sembra lievemente migliorato, in quanto position: relative non è più necessaria.

Lo stack, il layering e layout

Sembrano esservi due ordini di layering e di stacking all'interno di IE/Win:

Entrambi i modelli di stacking, sebbene incompatibili, sono residenti nel motore di IE. Regola pratica: quando si fa il debug, non dimenticarsi di vagliare entrambi i sospetti. Vediamo di frequente problemi correlati nei menu drop-down o in altri di simile complessità, dove lo stacking, il posizionamento ed il float possono portare a svariati disastri, e le soluzioni ai bug possono includere il dare layout ad elementi posizionati con z-index (ma variano, così siete avvisati).

La debacle del contenteditable

L'attributo contenteditable=true, impostato su un tag HTML come body consente l'editazione in tempo reale, il trascinamento ed il ridimensionamento dell'elemento e dei suoi figli con layout. Ora si provi ciò con i float o l'elemento di layout li in una lista ordinata.

Al fine di manipolare gli elementi (editarli) "contenteditable" e "hasLayout" introducono un ordine di stacking separato per gli elementi con layout.

La Editing Platform eredita il concetto di layout, a riprova del fatto che la contenteditable è la causa dell'errata interpretazione del layout (con l'implicazione che le applicazioni che in qualche modo integrano il motore di editing di IE forzano una compatibilità a ritroso verso questo concetto di layout).

Similarità con le specifiche CSS

Le vostre pagine concepite per IE falliscono negli altri browser? Non c'è alcun motivo di farlo accadere, sappiatelo. Qualunque buon browser può gestire bene i design per IE, se lo chiedete gentilmente - e gli fornite dei validi CSS.

Utilizzare le deboli similarità che si trovano fra hasLayout e la creazione di un nuovo contesto di formattazione dei blocchi ci da degli strumenti per riprodurre gli effetti di hasLayout per il contenimento dei float e per il comportamento degli elementi vicini ad un elemento flottante nei browser standard compliant.

Modalità quirk

Si faccia riferimento al nostro capitolo sulla modalità quirk per le informazioni su questa modalità di rendering.

Layout - Una conclusione

Il concetto di layout nella sua interezza non è compatibile con un numero di concetti base dei CSS sul modello di formattazione visuale, ovvero il contenimento, il flusso, il floating, il posizionamento ed il layering.

Questo porta a specifiche violazioni da parte di IE/Win delle specifiche CSS a causa della presenza o dell'assenza di layout negli elementi della pagina.

hasLayout - Parte di un altro motore?

Il modello ad oggetti all'interno di Explorer appare come un ibrido di un modello di documento e del loro modello di applicazione tradizionale. Cito questo perchè è un importante aspetto per capire come Explorer rende a video le pagine. Il procedimento per passare da un modello di documento ad un modello di applicazione consiste nel dare ad un elemento "layout".

( Dean Edwards )

A volte non è possibile dare un'intepretazione ad un comportamento: dipende semplicemente da quale motore fra i due venga usato, in funzione dello stato di hasLayout, ciascuno con i suoi bug e le sue modalità quirk.

L'assurdità dei bug

I bug nel software sono il risultato di errori umani e della mancanza di completezza e di logica durante il processo di creazione. È una basilare manchevolezza umana, per la quale una cura definitiva deve essere ancora trovata. Ogni tentativo di correggere software con bug senza ricrearli da zero, porterà inevitabilmente a scoprire bug sempre più complessi nel software, a causa delle stesse manchevolezze umane. Ogni software che si relaziona ad un altro software, fra cui naturalmente i sistemi operativi, si relazionerà con i suoi bug. Così otteniamo una cascata di bug da ogni singolo bit coinvolto del software, che rende anche il solo pensiero di trovare del software senza bug completamente assurdo.

( Molly, the cat )

In generale, quando si affrontano layout complessi con i fogli di stile, la conoscenza del comportamento degli elementi in relazione alle proprietà applicate ci può aiutare a risolvere situazioni che all'apparenza possono sembrare bug o anomalie.

Per esempio, se osservate questo esempio con un browser basato su Mozilla, noterete che i link della barra di navigazione con sfondo verde non sono cliccabili. Il perchè è nel codice riportato:

.left {
position: absolute;
top: 30px;
left: 10px;
width: 220px;
margin: 0;
padding: 70px 10px 10px 10px;
border: 1px solid;
}

Poichè ho impostato un padding superiore (padding-top) di 70px, l'altezza della colonna di sinistra fa si che quest'ultima si sovrapponga alla barra di navigazione. Essendo posizionata in modo assoluto ('position: absolute'), gli altri elementi non sono a conoscenza della sua posizione e si comportano come se non esistesse. Quindi il suo box (riquadro) copre i link, che vengono a trovarsi sotto di essa nel contesto di stratificazione a livelli (layering).

Da tutto ciò si capisce come una solida conoscenza della teoria ci aiuti a risolvere dei problemi comuni nel layout con i CSS.

Infine, consiglio la lettura delle mie interviste a Bruno Fassino, Luca Di Casoli e Mark Schenk per approfondire l'approccio ai fogli di stile.

[Precedente] - [Successivo] - [Pagina principale] - [Sommario rapido] - [Sommario completo] - [Proprietà]