Web Senza Barriere ‘08

Nel corso dei miei seminari quello che è mancato è stata una breve discussione sul corretto approccio al layout con i CSS. A mio avviso un corretto approccio permette allo sviluppatore di superare agevolmente gran parte dei problemi derivati dal diverso grado di implementazione dei vari browser. In questo articolo illustrerò alcune strategie che potranno essere impiegate nel quotidiano lavoro di sviluppo di siti web.

Prima la marcatura

La prima cosa da cui bisogna partire è la scelta degli elementi che andranno a costituire il nostro layout. La scelta dovrebbe essere improntata ad un rispetto semantico del ruolo degli elementi (X)HTML e alla loro giusta collocazione nel flusso. Nello specifico, ecco alcuni consigli pratici che potrebbero risultare utili.

1. Prima i contenuti.
   I contenuti andranno posti prima di tutto il resto. Ciò permette una più agevole lettura da parte dei lettori di schermo ed una migliore indicizzazione.
2. Evitare la ridondanza
   Si dovrebbe evitare di ripetere alcuni elementi la cui prima istanza è già sufficiente a chiarirne il senso. Esempi di tali elementi sono abbr, acronym, dfn, i quali, data la presenza dell’attributo title possono risultare fastidiosi se ripetuti più volte. Per esempio, se nel primo paragrafo ho specificato che l’acronimo CSS sta per “Cascading Style Sheets” è inutile ripeterlo ancora nel resto del documento.
3. Rispettare la semantica
   Bisogna rispettare il ruolo che gli elementi svolgono all’interno del documento, senza alterarne la funzione a scopo presentazionale.
4. Usare gli elementi in modo logico
   Gli elementi andrebbero usati seguendo una logica. Per esempio, per un menu di navigazione è più indicato usare un elenco piuttosto che inserire i link direttamente all’interno di un elemento di blocco (come un paragrafo).

Niente copia e incolla

Per “copia e incolla” si intende quella pratica che prevede l’importazione di stili e formattazione da un altro sito allo scopo di adattarlo al proprio. Sebbene questa pratica sia un utile mezzo didattico quando si inizia a lavorare con i CSS, essa si rivela deleteria con l’andare del tempo. Lo sviluppatore professionista sa bene che ogni singolo layout è una storia a se, e che quindi cercare di adattare soluzioni prese in prestito da altri non è una soluzione vantaggiosa a lungo termine. Tale pratica impedisce di acquisire una propria autonomia a livello lavorativo, restando di fatto dipendenti dal lavoro di altri. Si noti che questa pratica è in uso anche in altri linguaggi lato client, come JavaScript, con risultati ancor più difficili da gestire a livello implementativo.

Calcolare lo spazio

Nel layout con i CSS è fondamentale sapere sempre quanto spazio abbiamo a disposizione all’interno del layout. Il box model CSS si basa essenzialmente sulle operazioni di somma e sottrazione. Ci si ricordi sempre che le dimensioni complessive di un blocco contenitore sono date dalla somma dei margini, del bordo, del padding oltre che dalla larghezza e dall’altezza impostate esplicitamente. Attenzione inoltre alle misure relative (em) o percentuali (%): queste misure vengono automaticamente convertite in pixel al momento del rendering finale. Non è affatto vero che un box impostato in percentuale venga trattato in modo diverso dal browser. Le sue dimensioni si adattano si alla dimensione della finestra, ma tali dimensioni vengono calcolate nei corrispettivi pixel. Di fatto, un box in percentuale occuperà sempre una dimensione che viene resa in pixel. Questo è particolarmente vero nel caso delle immagini in percentuale, il cui rendering è sempre dipendente dalle dimensioni del loro blocco contenitore (e tali dimensioni, ricordiamolo, sono calcolate in pixel).

Bug e anomalie

Esiste un importante differenza tra un bug ed un anomalia: un bug è un esplicita violazione delle specifiche CSS, mentre un’anomalia è una differente interpretazione di queste ultime. Al primo tipo appartengono alcuni bug nel float di Internet Explorer 6 (ed inferiori), mentre al secondo alcune peculiarità di Explorer nel calcolo dell’indentazione negativa del testo o del posizionamento di un elemento flottato con un margine orizzontale negativo. Nel caso delle anomalie, le specifiche affermano che “possono esservi dei limiti nell’implementazione specifica”, ossia che i browser possono comportarsi in modo non del tutto prevedibile.

Test e debugging

Sia che si tratti di un bug o di un anomalia, la cosa fondamentale è isolare il problema. Per far questo occorre individuare l’elemento affetto dal problema. Per esempio, se si lavora con Internet Explorer 7 (ed inferiori), gran parte dei problemi vengono causati dalla proprietà hasLayout. Per verificare se un elemento ha layout, è possibile usare il seguente pseudo-url JavaScript da inserire nella barra degli indirizzi:

javascript:alert(document.all(“id-elemento”).currentStyle.hasLayout)

Se il risultato è ‘true’ l’elemento ha layout, se ‘false’ l’elemento non ha layout. Si tenga presente che tale proprietà si trasmette da genitore a figlio, quindi molto spesso si tratta di risalire l’albero del documento fino ad individuare l’elemento in questione. Un’altra cosa da tener presente è la modalità di rendering: spesso infatti alcuni bug di Explorer si presentano in modalità standard ma non in modalità quirks e viceversa. A questo punto si può isolare la parte di codice e gli stili relativi che la regolano e creare una pagina di test separata in cui testare varie combinazioni fino a trovare una soluzione. I CSS non dispongono di una modalità step-by-step di debugging, ma è possibile simularla usando i commenti:

#box {
/* width: 50%; */
width: 49%;
}

Possiamo in questo modo provare varie combinazioni tenendo traccia dei cambiamenti. Per Internet Explorer, la soluzione migliore per dare stili separati è quella dei commenti condizionali. Per gli altri browser possiamo utilizzare JavaScript. Per esempio, ipotizzando di dover dare degli stili solo ad Opera potremmo scrivere:

if (window.opera) {
var head = document.getElementsByTagName("head")[0];
var css = document.createElement("link");
css.setAttribute("href", "opera.css");
css.setAttribute("rel", "stylesheet");
css.setAttribute("type", "text/css");
css.setAttribute("media", "screen");
head.appendChild(css);
}

I cosiddetti hack andrebbero evitati perché 1) spesso non sono validi e 2) rallentano il lavoro del browser in fase di parsing e 3) sono una soluzione a breve termine.

Popolarità: 69% [?]