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

Durante il seminario il pubblico era numeroso e attentissimo. Nei 100 minuti di tempo ho alternato le questioni squisitamente tecniche, relative al contenitore-macchina audiovisiva, con le riflessioni sui contenuti audiovisivi, con l’obiettivo di dimostrare che l’accessibilità dei video su Web non prosciuga il messaggio: non costringe cioè a togliere e a semplificare, non è una disciplina che impedisca di fare quello che si vuole. Richiede più lavoro, ma questo lavoro alla fine produce un contenuto che è più ricco di comunicazione per tutti.

L’importanza della traduzione dei codici, dal visivo al verbale e viceversa, risiede nel fatto che un messaggio può essere trasmesso in molti modi diversi: il segreto della comunicazione senza barriere sta proprio nella capacità di tradurre quello che si ha in testa in forma visuale o testuale, con la musica o in altro modo.

Ma fino a quando non si dominano i linguaggi, si pensa che il linguaggio che si usa sia l’unico giusto da utilizzare. E’ una questione culturale.

Tutti questi aspetti (audio, video, testo, immagini) ci si deve abituare a tradurli costantemente uno con l’altro. E’ una ginnastica mentale che aiuta ad approfondire qualsiasi messaggio si intenda trasmettere. Il risultato è che si migliora la propria capacità di comunicare.

Continuare a pubblicare video non accessibili significa non solo discriminare (cosa importante per diversi aspetti), ma anche rinunciare ad approfondire gli aspetti linguistici dei video. E questo è un danno culturale su cui è bene riflettere.

Indico alcune risorse disponibili per rivivere l’esperienza del seminario e approfondire la conoscenza dell’accessibilità dei video sul Web:

• Trascrizione completa del seminario (coi rimandi alle slide).
• Slide del seminario.
• Video integrale del seminario, con sottotitoli.

Riporto alcuni passi dalla trascrizione del mio intervento, per una scorsa veloce dei temi trattati.

Rinforzo dei codici

Ogni mondo generato da un testo, che può essere un testo fatto di parole oppure di immagini o di suoni, può essere convertito o tradotto da un canale all’altro. Ed è questa traduzione da un canale all’altro, quindi fare vedere con l’udito e far sentire con la vista, è questo lavoro che si fa con l’accessibilità dei video che consente di abituarsi a passare da un codice all’altro e quindi di conoscere le caratteristiche principali di ogni linguaggio. In questo modo, con l’accessibilità, si approfondisce anche la sensibilità per i contenuti e il linguaggio audiovisivi, e si migliora la propria capacità di progettare un audiovisivo.

“Radianza Web-centrifuga”

Intendere il Web nel suo carattere “radiante” significa intenderlo come strumento capace di recepire contenuti provenienti dai media audiovisivi tradizionali e di irradiarli in forma diversa, in modo da attirare l’attenzione del fruitore Web e di spingerlo a voler fare esperienza di quell’audiovisivo nel medium originale. Questo è il grande valore didattico del Web, che secondo me dovrebbe essere sviluppato: cercare di rendere sinteticamente il contenuto di un messaggio audiovisivo, ad esempio di tipo televisivo, di adattarlo al Web per catturare l’attenzione dell’utente e di invogliarlo a ricorrere alla sede originaria della comunicazione audiovisiva per conoscere interamente il testo.

L’accessibilità dei video migliora la capacità di comunicare

Domanda: Questo sito per i sordomuti non è quindi accessibile? Non è accessibile per noi…
Roberto Ellero: E’ accessibile per la comunità dei sordi, l’ho fatto vedere per far capire che la comunità dei sordi ha una propria cultura, e farò poi vedere dei video che hanno l’idea di mettere in dialogo la comunità degli udenti con la comunità dei sordi. La comunità dei sordi ha una propria cultura e una grande forza, si può dire che sia una minoranza linguistica. Non possiamo pertanto ragionare in termini assistenzialistici fornendo un servizio in LIS. La LIS è la loro lingua, si deve cercare piuttosto di mettere in dialogo la cultura degli udenti con la cultura dei sordi. Ho provato con dei video, di cui poi vedremo degli estratti, a mettere in parallelo - grazie a Smilery player con il doppio flusso video - l’esperienza di trasmissione del messaggio in forma visiva e attraverso il canale della parola parlata. Da qui si comprende bene l’importanza della traduzione dei codici.

L’accessibilità dei video arricchisce i contenuti ed è un vantaggio per tutti

Vi faccio vedere un esempio, uno spettacolo teatrale che ho adattato al Web, e che contiene una audiodescrizione per le persone non vedenti, progettata in termini drammaturgici. E’ uno spettacolo ideato e diretto da Marco Pernich, di Studio ‘900 di Milano, uno spettacolo con sole attrici che interpretano vari aspetti dell’anima femminile attraverso le dee dell’antichità greca (”Il Grande Nudo Rosso”). Lo spettacolo dal vivo ha una durata di un’ora circa. Ho effettuato una riduzione a una ventina di minuti, aggiungendo però alcune scene tra un episodio e l’altro con una narratrice che spiega i singoli episodi in modo da renderli comprensibili anche da chi non vede. Ritengo che con questa integrazione con parti anche visive, come si vede nella schermata, il video risulti arricchito per tutti. Si tratta di un’audiodescrizione che aggiunge interesse perché, mentre la scena è all’interno di una scenografia teatrale al chiuso, l’audiodescrizione rappresenta una realtà naturale, un giardino, che serve ad aumentare il coinvolgimento del fruitore Web che cerca sempre di scappare via. Lo si tiene fermo il più possibile con dei contrasti cromatici e di ambientazione diversa: questa alternanza di scena teatrale e di ambientazione esterna aumenta l’interesse e il coinvolgimento. In questo modo c’è la speranza che qualcuno arrivi a vedere tutto il video - cosa abbastanza rara sul Web, spesso si guarda qualche secondo poi si passa ad altro. La fruizione Web è una fruizione frenetica, e progettando un video si deve considerare anche questo aspetto.

Due punti di vista simultanei e l’integrazione dei codici

Avete visto come in questa bozza si succedano due punti di vista. Avere due punti di vista in successione aumenta l’interesse, poiché posso focalizzare su dettagli che si ritiene possano interessare il fruitore, quindi c’è un approfondimento rispetto a una sola videocamera. C’è più lavoro di montaggio, però il risultato finale è più ricco. Questo risultato si può ottenere anche in un altro modo: invece di mettere in successione i due punti di vista, li metto a disposizione simultaneamente. Ed è quello che avviene nell’ultimo video che presento qui oggi e che da ieri è disponibile su Webmultimediale.org. È un video che rappresenta un musical, teatrale e musicale, “Dio era tra noi”, con un gruppo musicale che fa indie rock (i Malazeta), una compagnia di teatro che fa uno spettacolo di tipo Kolossal, e con un attore sordo dalla nascita, Antonio Pellegrino, che trasmette con la lingua dei segni e con il corpo la vibrazione musicale alle persone sorde. Ora, se lo vedrete con calma a casa noterete che anche senza conoscere la lingua dei segni, di fatto, questo lavoro di traduzione, ovvero di trasmissione attraverso il visivo aumenta molto l’interesse della comunicazione dello spettacolo. […] Avendo a disposizione uno strumento che mi consente i due punti di vista in modo simultaneo, ottengo un risultato che è sicuramente più interessante rispetto alla successione dei punti di vista all’interno di un solo video, una successione decisa dall’autore. Con la compresenza dei due punti di vista è il fruitore invece a decidere dove guardare, pertanto la selezione dei punti di vista la fa il destinatario del messaggio, il fruitore. Questo aumenta l’interazione multimediale.

Popolarità: 100% [?]