Javascript e CSS: separare l'azione dalla presentazione

Facciamo il punto della situazione:

• La separazione della presentazione dalla struttura è iniziata agli albori della rivoluzione CSS. Si è rivelato un processo molto più complicato di quanto si pensasse, ma con un duro lavoro di prova ed errore, siamo ora in grado di padroneggiare i principi di base.
• La separazione dell'azione dalla struttura non è invece ancora iniziata, ma ci sono le premesse perché sia davvero semplice. (cfr. Articolo: Il nuovo Javascript: separare l'azione dalla struttura)

Questo articolo si occupa del terzo tipo possibile di separazione, quello tra azione e presentazione.

Secondo la moderna teoria del web development, è possibile realizzare con i CSS molte delle funzioni tradizionalmente realizzate con Javascript. Per esempio, le ricerche di Eric Meyer mostrano come si possano creare con i soli CSS persino i menu a tendina, da tempo ritenuti dominio esclusivo di pesanti e complesse librerie Javascript: bastano poche righe di codice costruite intorno al selettore li:hover.

Se ignoriamo i problemi di compatibilità tra i browser e sappiamo di poter creare splendidi menu a tendina sia con i CSS che con Javascript, quale dei due linguaggi dovremmo usare? I menu a tendina hanno a che fare con l'azione o con la presentazione?

Un dilemma simile può sorgere intorno alle tecniche di image replacement. Negli ultimi mesi sono state pubblicate una ventina di estensioni, modifiche, variazioni di questa tecnica, ma tutte si basano sui CSS. Nessuno sembrava interessato alla loro implementazione con Javascript, così l'ho fatto io.

Se confrontiamo il mio script con la migliore variazione sul tema basata sui CSS (probabilmente il metodo della cover-up span di Pixy), quale sceglieremmo? La mia soluzione è superiore a quella con i CSS? O è meglio utilizzare i CSS per implementare un image replacement? E in entrambi i casi, perché?

Preferenze personali

Al momento, molti sembrano rispondere a questi dilemmi in base alle proprie preferenze personali. È legittimo. Se uno lavora bene e velocemente con i CSS ma trova complicato Javascript, è naturale che preferisca operare con ciò che conosce.

Le sole preferenze personali, però, non aiutano più di tanto. Se ci sono ragioni oggettive e stringenti per realizzare un certo effetto con Javascript, dovremmo essere in grado di farlo, a prescindere da ciò che preferiamo.

Uno sviluppatore web client-side dovrebbe sempre avere qualche conoscenza di questo linguaggio. Non significa dover conoscere alla perfezione l'intera specifica del W3C DOM, ma almeno sapere cosa si può fare e come lavorare sugli script creati da altri. Solo così saremo in grado di decidere consapevolmente di non usare Javascript.

Decisioni basate sulle quote di mercato dei browser

Un argomento oggettivo e reale a favore o contro l'utilizzo di Javascript potrebbero essere le quote di mercato dei browser. Se Javascript gode di un supporto più ampio dei CSS -o viceversa- la scelta sarebbe forse più semplice.

Si pensa che la quota di browser che non usano Javascript si attesti tra il 10 e il 15%. Questi dati sono basati su vecchie statistiche di TheCounter. È interessante notare che negli ultimi mesi questa quota si è ridotta del 55%, passando dal 13% del maggio 2003 al 6% del marzo 2004.

Ma questo calo così netto fa sì che io non abbia molta fiducia in questi dati. Non credo che il 5% di tutti gli utenti che navigano sul web abbiano attivato il supporto di Javascript negli ultimi mesi. Ritengo, piuttosto, che theCounter abbia modificato il suo metodo di rivelazione. Cosa che mi fa avere poca fiducia verso entrambi i dati, il vecchio 13% e il nuovo 6%.

E comunque, seguiamo l'opinione comune, supponiamo che i dati sopra riportati siano realistici, facciamo la media. Arriviamo alla conclusione che i browser che non supportano gli script rappresentano una quota del 10%.

Ora dobbiamo solo confrontare questa cifra con quella dei browser che non supportano i fogli di stile CSS. Purtroppo questo dato è sconosciuto. Non conosco una sola società di rilevazione che produca statistiche sul supporto dei CSS.

Secondo TheCounter i browser moderni rappresentano il 98% del mercato. Potremmo allora supporre che il 98% dei browser supporta i CSS, ma è pericoloso. Dopo tutto, potremmo trarre la stessa conclusione per Javascript, ma sappiamo che non è vero.

In buona sostanza, abbiamo pochi elementi per poter effettuare una scelta sulla base delle quote di mercato.

Regole?

Vediamo se è possibile allora elaborare una teoria. Possiamo, cioè, definire con esattezza le circostanze in cui è meglio usare Javascript rispetto ai CSS, e viceversa? In altre parole, possiamo definire un confine netto
tra azione e presentazione? Io ho trovato una regola, ma ho scoperto che non funziona:

Ogni effetto che avviene in base all'input dell'utente è azione. Tutti gli altri sono presentazione.

Il vantaggio di questa regola è che evidenzia la grande forza di Javascript. È davvero difficile scrivere script utili che non siano attivati dall'utente, così possiamo addirittura creare una regola basata su questo assunto. Nella pratica, però, andiamo subito incontro ad una serie di problemi.

Secondo questa regola, infatti, l'image replacement è affare per i CSS poiché non dipende da azioni dell'utente. I menu a tendina sarebbero invece da fare con Javascript, dal momento che dipendono da eventi mouseover e mouseout. Significa che dovremmo eliminare il selettore :hover. È un gestore di eventi che effettua uno pseudo-mouseover e sappiamo che gli eventi dovrebbero gestiti con Javascript, non con i CSS. Poiché penso che l'abolizione di quel selettore non sarebbe salutata con salti di gioia dagli sviluppatori web, dobbiamo concludere che questa regola non ci aiuta ancora molto.

Vediamo se allora funziona una regola più pratica:

Usa la tecnologia che richiede meno codice.

È una regola che non ci dice niente sulla fondamentale differnza tra azione e presentazione. Infatti, vedremo come porti a risultati contraddittori.

Io comunque la preferisco a quella di prima. Il modo migliore per mantenere un sito semplice è scrivere codice efficiente per ottenere un certo effetto, evitando sia gli hack dei CSS sia complessi oggetti Javascript.

Ma quale tecnologia richiede meno codice? In genere i CSS sono la scelta migliore se dobbiamo applicare lo stesso effetto su un gruppo di elementi. Javascript stravince se dobbiamo applicare un effetto simile su un gruppo di elementi.

CSS inefficienti

Un esempio basato sulla tecnica dell'image replacement ci aiuterà a comprendere questa differenza cruciale. Immaginiamo di avere una pagina con qualche header (intestazione) e una manciata di link di navigazione. Vogliamo che tutti siano sostituiti con delle immagini. Ovviamente, ciascun header e ogni link di navigazione ha bisogno di un'immagine specifica, dal momento che hanno testi diversi.

Questo è il codice che dovremo generare:

<div class="nav">
<a href="somewhere.html" class="imgreplacement"
id="somewhere"><span></span >Somewhere</a>
<a href="somewhere_else.html" class="imgreplacement"
id="somewhere_else"><span></span >Somewhere else</a>

[etc]
</div>

<div class="main">
<h1 class="imgreplacement" id="welcome">
<span></span>Welcome</h1>
<p>Text</p>
<h2 class="imgreplacement" id="possibilities">
<span></span>Possibilities</h2>
[etc]
</div>

.imgreplacement {
// insert favorite image replacement technique here
}
.imgreplacement span {
// insert favorite image replacement technique here
}
#somewhere span { background-image: url('pix/somewhere.gif'); }
#somewhere_else span { background-image: url('pix/somewhere_else.gif'); }
#welcome span { background-image: url('pix/welcome.gif'); }
#possibilities span { background-image: url('pix/possibilities.gif'); }
[etc]

Decisamente tanto come codice, non è vero? Aggiungendo ulteriori sostituzioni di immagini, aumenta di molto la quantità di regole CSS che dovremo definire. Se abbiamo bisogno di 10 sostituzioni per pagina -3 per le intestazioni e 7 per i link- e se vogliamo che le intestazioni abbiano tutte un aspetto diverso, gestire il codice diventa un incubo.

Come si vede, i CSS risultano inefficienti quando si deve assegnare un effetto simile ad un gruppo di elementi. Tutti gli elementi rimpiazzati dell'esempio hanno bisogno delle stesse regole generali, ed è facile definirle. Ma ciascun elemento ha poi bisogno di una sua specifica immagine di sfondo, e nei CSS significa dover ripetere più volte lo stesso codice. (Tra parentesi, questo problema riguarda tutte le tecniche di image replacement. Nessuna può gestire al meglio un grande numero di sostituzioni).

La mia soluzione in Javascript ha bisogno di sole 20 righe di codice per gestire un numero illimitato di sostituzioni dell'immagine senza problemi di gestione e manutenzione. Basta creare gli elementi XHTML e assegnare ad ognuno il suo id per aggiungere una nuova sostituzione. Lo script si occupa di intercettarli e di inserire l'immagine giusta.

Nel caso dell'image replacement, insomma, Javascript è più efficiente dei CSS.

CSS efficienti

Il contrario avviene per i menu a tendina. Con i CSS basta una struttura di codice come questa:

#navigation li ul { display: none; }
#navigation li:hover ul { display: block; }

Con una soluzione basata su Javascript dovremmo rintracciare tutti i link di navigazione, assegnare a ciascuno i gestori di eventi, aprire e chiudere i sottomenu giusti, mantenere traccia di tutto quello che avviene.

Purtroppo, entra in gioco l'incompatibilità tra i browser. Internet Explorer su Windows supporta :hover solo sui link, e non sugli altri elementi. Dunque, la soluzione che poggia solo sui CSS non può ancora essere usata. Dovremo ancora per molto tempo basarci su Javascript.

Separazione

Ciò che non dovremmo fare è creare complicati metodi cross-over tipo quello dei menu a tendina Suckerfish. Secondo me gli autori di questo articolo fanno un errore realizzando questo tipo di menu sia in Javascript che con i CSS, il primo per Explorer Win, il secondo per gli altri browser.

Inoltre c'è un rishio, diciamo così, psicologico. I menu alla Suckerfish sono inaccessibili in Explorer Win se Javascript è disabilitato. Credo che non sarebbe accaduto se gli autori avessero scritto il menu solo in Javascript.

Dopo anni di indottrinamento siamo infatti al punto che la semplice menzione di questo linguaggio fa scattare l'allarme accessibilità. I CSS, invece, non sono sentiti come una minaccia per l'accessibilità, così l'allarme di pericolo non scatta. In questo caso particolare, l'uso dei CSS sembra aver dato agli sviluppatori un falso senso di sicurezza, tanto che sembrano aver dimenticato i problemi di accessibilità sollevati dall'uso di Javascript.

Come si vede, dunque, mischiare i livelli della presentazione e dell'azione non è una buona idea. (Qualcuno potrà obiettare che chi usa Internet Explorer difficilmente disabilita gli script: beh, bisogna ricordare che c'è un 10% di utenti che non ha il supporto di Javascript, mentre la quota di chi usa altri browser è tra il 5 el'8%. Qualche utente Explorer che disabilita gli script ci deve essere.)

Azione e presentazione

La conclusione è che non possiamo ancora separare nettamente azione e presentazione. Abbiamo dati insufficienti per fare una comparazione basata sulle quote di mercato. Definire un confine teorico tra i due livelli richiederebbe l'abolizione della pseudo-classe :hover. Scegliere la soluzione che richiede meno codice sembra una via praticabile, ma è contraddittorio come metodo, poiché assegna l'image replacement all'ambito di Javascript e i menu a tendina a quello dei CSS.

In pratica, separare l'azione dalla presentazione, al momento, dipende solo dalle preferenze personali dello sviluppatore. Non c'è nulla di sbagliato, in via di principio, in assenza di motivi oggettivi e reali che portino a dover scegliere tra l'uno e l'altro. Le preferenze personali, però, sembrano oggi rivolte ai CSS, ed è la cosa che mi disturba. Non c'è equilibrio. La gente sembra aver paura di Javascript.