Cell. +39 3479684755
Il Blog di Instant Websites
Il box-model e la proprietà box-sizing
Principio generale
Il c.d. box-model indica il modo in cui, nei CSS o Cascading Style Sheets, vengono interpretate le principali proprietà dimensionali assegnate ad un certo box contenitore in larghezza e/o altezza, tenendo presente che quasi sempre le problematicità si presentano con riferimento alla larghezza (essendo lo scrolling operazione comune nella fruizione dei siti web).
Facendo dunque riferimento alla larghezza, in sintesi il box-model è il seguente:
LARGHEZZA EFFETTIVA DI UN BOX = width + padding orizzontale + bordi sui lati sx e dx
quindi un box definito dalle seguenti dichiarazioni:
#box { width:600px; padding-right:20px; padding-left:20px; border: 2px solid #333; … }
avrà larghezza effettiva pari a 600 +20 + 20 + 2 + 2 = 644px
In maniera analoga, con riferimento all’altezza, avremo invece:
ALTEZZA EFFETTIVA DI UN BOX = height + padding verticale + bordi sui lati superiore ed inferiore
Perché abbiamo detto che il problema si presenta di solito con riferimento alla larghezza?
Per il semplice motivo che segue: se l’altezza di un contenitore si rivela maggiore del previsto, si tratterà per l’utente di effettuare uno scrolling maggiore verso il basso senza altre conseguenze problematiche; se invece è la larghezza ad essere maggiore, può accadere che la disposizione degli elementi ne risenta negativamente come ad esempio nel caso di due colonne flottanti affiancate (la seconda, non trovando sufficiente spazio, si posiziona sotto alla prima invece che di fianco determinando la “rottura” del layout).
Il problema nelle vecchie versioni di Internet Explorer
Tutto facile dunque? Macchè! Nelle vecchie – vecchissime … diciamo pure preistoriche – versioni di Internet Explorer, la 5.5 e precedenti, l’interpretazione del box-model era completamente invertita giacché la larghezza dichiarata con la proprietà width era quella effettiva, comprensiva di padding e bordi (nell’esempio di cui sopra: 600px).
Il fatto che IE fosse praticamente l’unico browser presente sul mercato, eccezion fatta per Netscape Navigator – che avrebbe a sua volta inciampato nella famigerata versione 4 così difettosa da comprometterne un futuro stabile e duraturo – pose agli sviluppatori di fronte a due scelte:
- interpretare il box-model così come definito in Internet Explorer,
- aggirare il problema in questo modo: assegnare la sola proprietà width al box contenitore e crearne un altro al suo interno a cui attribuire il padding.
La soluzione 2. comportava un appesantimento – peraltro modesto – del markup nel senso che là dove sarebbe stato possibile avere solo un elemento, ce n’erano in definitiva due ma appariva un prezzo da pagare più che ragionevole per applicare correttamente le regole del box-model ed ottenere un risultato appropriato anche in IE.
La fase di transizione
Con l’arrivo della versione 6 di IE (comunque disastrosa a causa dei numerosi e rilevanti bug), l’interpretazione del box-model divenne corretta e allineata agli altri browser che si stavano sviluppando, in particolare Firefox cioè il dichiarato erede di Netscape Navigator.
Il problema non era però sparito perché le versioni precedenti di IE continuavano a girare su numerose macchine.
Non dimentichiamo che eravamo ancora nell’era dei modem analogici quindi gli aggiornamenti non erano così facili, inoltre in molti li vedevano come pericolosi per via dei primi virus mascherati e il passaggio ad altri browser non era frequente per la sfiducia istintiva nei confronti di tutto ciò che non fosse firmato Microsoft (quanto sono cambiate le cose da allora!).
Per potere creare layout idonei a tutti i browser, quindi, diventava indispensabile adottare la soluzione 2. esplicitata nel paragrafo precedente oppure ricorrere ai cosiddetti commenti condizionali che portassero alla lettura ed esecuzione di regole CSS sostitutive e/o aggiuntive qualora venisse impiegato un browser caratterizzato da bug.
Ecco un esempio di commento condizionale inserito nella sezione <head> del file HTML, dopo il collegamento al foglio di stile di base:
<link href=”css/miosito.css” rel=”stylesheet” type=”text/css” />
<!–[if lt IE 6]>
<link href=”css/miosito-ie.css” rel=”stylesheet” type=”text/css” />
<![endif]–>
dove la prima riga carica lo stylesheet di base e il commento condizionale successivo carica il foglio speciale con le regole sostitutive qualora il browser sia una versione precedente a IE6.
Gli operatori dei commenti condizionali erano:
[if IE] … I.E. qualsiasi versione
[if IE 6] … I.E. versione 6
[if lte IE 6] … I.E. versione 6 o inferiore
[if lt IE 6] … I.E. versione inferiore a 6 (esclusa quest’ultima)
Questa soluzione era evidentemente piuttosto noiosa ma sarebbe stata applicata anche dopo l’arrivo di IE6 e IE7, per rettificare alcuni bachi tanto stupidi quanto fastidiosi.
C’era un altro approccio possibile, inaccettabile nell’ottica di chi scrive: rinunciare del tutto a garantire compatibilità con le versioni via via superate di IE dando per scontato che chi non avesse proceduto ad aggiornamenti e non utilizzasse gli altri browser disponibili (il già citato Firefox, sempre più forte nel tempo fino all’avvento di Chrome) non meritasse di fruire di un sito correttamente visualizzato.
Approccio impossibile da condividere, come si diceva, perché l’obiettivo di uno sviluppatore professionista è quello di assicurare la visibilità del sito ad una platea più ampia possibile di fruitori, non di “educare” gli stessi ad abbandonare IE.
Ovviamente, restando nei limiti del ragionevole: se ancora qualcuno là fuori impiega Windows XP con IE7, beh … a questo punto, peggio per lui!
Retrocompatibilità: fino a che punto?
La domanda che ci si pone in questo articolo è: fino a che punto è necessario ed opportuno garantire la retrocompatibilità di un sito con i vecchi browser (programmi di navigazione) e, in particolare, con le versioni precedenti di Internet Explorer (IE)?
A dispetto di quanto sostenuto dagli sviluppatori “anti-Microsoft militanti”, secondo i quali a chi usa Internet Explorer non deve essere garantita per forza una corretta fruizione dei siti semplicemente perché dovrebbero passare ad un altro browser, il dovere professionale di uno sviluppatore professionista è quello di assicurare ad una platea più vasta possibile di utenti un’appropriata esperienza di navigazione del sito realizzato.
Poco importa se lo sviluppatore stesso è di base utilizzatore di Firefox, Google Chrome, Safari o magari Opera: il proprio lavoro deve essere testato su tutti i programmi succitati, laddove necessario nelle rispettive versioni per PC e per Mac.
La questione si pone in particolar modo per il già menzionato Internet Explorer per via della sostanziale difettosità delle versioni meno recenti: la 5.5, con il suo clamoroso errore interpretativo del box model; la 6, ancora zeppa di bug; la 7, ulteriormente migliorata ma non perfetta – dove con “perfetta” intendiamo semplicemente “rispondente alle raccomandazioni del W3C“.
Gli altri browser non hanno una storia così tribolata, inoltre è ragionevole pensare che l’utente di uno di questi programmi alternativi – che stanno però rapidamente acquisendo quote di mercato a dispetto proprio di IE – sia più predisposto ad effettuare aggiornamenti, per non parlare di Chrome che li effettua sempre e comunque in automatico.
Infine va considerata la compatibilità dei successivi rilasci di IE con le versioni di Windows. Chi usa Windows XP, può utilizzare al più IE8 perché IE9 e IE10 sono installabili solo sotto Windows Seven o 8. Pensiamo agli uffici, più ancora degli ambienti domestici, in cui l’acquisto di PC nuovi con i relativi sistemi operativi è evento raro e lungamente ponderato, per ragioni economiche e magari di compatibiità con gli applicativi: supporre che tutti gli utenti dispongano di hardware e software allo “stato dell’arte” sarebbe una premessa azzardata.
CSS3, HTML5, Flash, jQuery … sarà rivoluzione?
La prossima introduzione a tutti gli effetti della nuova versione di HTML, cioè la 5, e dei Cascading Style Sheet, cioè la 3, lasciano presagire una sorta di rivoluzione nel campo dello sviluppo web per via dei nuovi strumenti che verranno messi a disposizione dei web designer.
Fin da oggi è possibile iniziare a sperimentare alcune delle nuove proprietà dei CSS3, poiché a) queste dovrebbero essere definite nella loro versione definitiva, b) i browser più intelligenti già le supportano, c) nel caso dei browser meno intelligenti (vale a dire IE, ma qualcuno ne dubitava?) la degradazione non comporta problemi di visualizzazione.
Ci siamo ad esempio occupati nel precedente articolo della proprietà fontface che consente di utilizzare font non standard nelle pagine web.
Questa è supportata persino da IE, addirittura nelle sue versioni più vecchie, quindi è utilizzabile da subito.
Un’altra proprietà interessante che andrà a risolvere un problema annoso – e diciamo con sincerità, noioso – è border-radius: questa permette di arrotondare gli angoli di un box in base ad un certo valore di raggio e può essere applicata a tutti gli angoli ovvero solo ad alcuni.
Vediamo un semplice esempio di un contenitore con tutti e quattro i bordi arrotondati:
#angoli-arrotondati {
width: 450px;
height: 300px;
margin: 20px 0;
background-color: #FF0000;
-moz-border-radius: 10px; /* per Firefox */
-webkit-border-radius: 10px; /* per Safari e Google Chrome */
border-radius: 10px; /* per IE9 */
}
ed un altro con i soli angoli inferiori arrotondati:
#angoli-inferiori-arrotondati {
width: 450px;
height: 300px;
margin: 20px 0;
background-color: #FF0000;
border: 1px solid #333333;
-moz-border-radius: 0 0 10px 10px; /* per Firefox */
-webkit-border-radius: 0 0 10px 10px; /* per Safari e Google Chrome */
border-radius: 0 0 10px 10px; /* per IE9 */
/*
Le ultime tre righe equivalgono a:
-moz-border-radius-bottomleft: 10px;
-webkit-border-radius-bottomright: 10px;
*/
}
In questa pagina sono presenti entrambi gli esempi: visualizzandola con Internet Explorer 8 e precedenti, gli angoli non risulteranno arrotondati mentre con tutti gli altri browser l’effetto funziona.
Un’altra questione che ha agitato le acque del web design è rappresentata dall’ostracismo attuato da Apple nei confronti di Flash, non supportato da iPhone né da iPad.
Qualcuno si è affrettato a dichiarare la morte di Flash, con comprensibile scarsa soddisfazione di Adobe; altri hanno affermato che la necessità di questo strumento verrà comunque meno per via delle opportunità offerte dai framework come jQuery e dallo stesso HTML5 che promette di gestire i file multimediali.
Chi scrive non è d’accordo su queste visioni estreme. Flash ha tuttora la sua utilità, a patto che non se ne abusi, soprattutto perché può compromettere la fruibilità di un sito (e la sua accessibilità).
jQuery è un framework duttile ed efficiente ma non sempre di facile utilizzo: i plugin richiedono numerosi test per accertarne la loro efficacia cross-browser e l’applicazione di più d’uno nella stessa pagina può generare incompatibilità.
L’ottica più corretta per uno sviluppatore web che deve garantire la massima fruibilità possibile per il proprio lavoro è ancora costituita dalla scelta dello strumento di volta in volta migliore per ottenere un certo risultato in termini di leggerezza della pagina, universalità tra i vari browser (o quantomeno degradazione accettabile), qualità del risultato ottenuto.
Tutti questi argomenti vengono trattati nell’ambito del nostro Corso Base di Web Design organizzato da INSTANT WEBSITES a Milano.
Il prossimo corso comincerà il 25 gennaio 2011.
Potete trovare i dettagli in queste pagine: http://www.instantwebsites.it/corsi.html e http://www.corsiwebdesign.it/corsobase.php