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à: 66% [?]

Ho accolto con immensa gioia l’invito a partecipare a questi seminari. La motivazione principale che mi ha spinto ad accettare l’invito è la possibilità di offrire un contributo concreto su un argomento che mi sta molto a cuore.

Anche se non sono un esperto nel settore dell’accessibilità, ho incominciato ad occuparmi dell’argomento verso la fine del 2005, quando ho scoperto il sito di Michele Diodati, con cui ho cominciato a collaborare nella traduzione di risorse sui CSS. Di li a poco è nato il primo abbozzo del mio progetto sui fogli di stile, che potete trovare all’ormai vetusto indirizzo http://gabrieleromanato.altervista.org/css/. Il sito vero e proprio, CSS Zibaldone, nasce nell’estate del 2006, precisamente l’8 agosto di quell’anno. Il sito è quindi molto giovane, con tutti i limiti del caso.

Ma veniamo agli argomenti principali dei miei due seminari. Idealmente, essi sono divisi in due grandi idee di fondo: struttura e realtà. Struttura e realtà ripropongono il dissidio esistente tra essere ed apparire, un dissidio che si è fatto assai stridente con l’evolversi del Web. Se all’inizio il Web era basato unicamente sulla struttura, in quanto gli stili per la presentazione non erano presenti, con l’andare del tempo e con le richieste degli autori si è assistito dapprima ad una confusione tra struttura e presentazione (marcatura presentazionale) e quindi alla divisione tra queste due categorie con l’avvento dei fogli di stile nel 1996 (anche se si dovette attendere alcuni anni prima di avere una buona implementazione nei browser).

Tuttavia, come ricorda Håkon Wium Lie (uno dei padri dei CSS) nella sua tesi di laurea sui fogli di stile, affinché questa separazione abbia luogo, è necessario che i documenti siano strutturati in modo logico e semantico. Un documento strutturato con criterio ha già compiuto un grande passo in avanti nel cammino che lo porterà ad essere un documento accessibile.

Questo sarà l’argomento del primo seminario, Conversione e formattazione di un documento in XHTML e CSS, in cui vedremo come sia possibile trasformare un documento con dei grandi limiti a livello di accessibilità in un documento fruibile dagli utenti. Questo seminario ci darà l’occasione di parlare degli argomenti di base dei fogli di stile, che saranno poi affrontati nel secondo seminario.

Il secondo seminario, Layout con i CSS: dalla struttura alla realtà, tratterà della realtà dei layout con i fogli di stile. Se nel primo seminario ci eravamo occupati della struttura (e quindi dell’essere), in questo seminario parleremo della realtà delle presentazione, ossia dell’apparire. Vedremo come realizzare dei layout avanzati, delle clonazioni e degli esperimenti con i fogli di stile, sottolineando al contempo il ruolo delle struttura e della semantica nella realizzazione di questi progetti. Alcuni progetti trarranno spunto dai miei test sui CSS, mentre altri saranno creati ex novo per l’occasione. Tratteremo anche della compatibilità con Internet Explorer, affrontando, dove necessario, la proprietà hasLayout.

Infine, alla domanda sul perché bisogna occuparsi di accessibilità, rispondo “perché è giusto farlo”. Questa sarà la filosofia di base che animerà il mio intervento. Spero di riuscire a trasmettere questo messaggio che, al di là dei dati meramente tecnici, rimane di assoluta importanza.

Popolarità: 15% [?]