SWF, riepilogo delle soluzioni

A list apart ha scritto di recente un interessante articolo dove vengono mostrati modi differenti per ovviare al problema dei file SWF.

Le problematiche, per chi non le conoscesse ancora, sono differenti:

1. l’elemento embed non è mai stato riconosciuto come standard
2. SWF non significa necessariamente un intero sito, può anche essere una piccola parte dello stesso che vorrebbe, magari, passare la verifica da parte dei validatori più comuni
3. gli ultimi updates del browser Internet Explorer hanno imposto un click da parte dell’utente prima di poter godere a pieno delle funzionalità dal contenuto eventualmente interattivo

Sebbene le critiche riguardo la scelta del click siano ancora oggi accese, dato che il contenuto viene attivato parzialmente e la sola navigazione dello stesso richiede quindi questo click di attivazione, pochi giorni dopo questa novità qualcuno si è accorto che scrivendo tramite JavaScript l’elemento object con o senza il relativo embed, questo non avrebbe richiesto all’utente alcunchè.

Diverse in questo caso le posizioni in merito, da una parte i sostenitori del “power to users“, convinti delle buone intenzioni del nuovo controllo, dall’altra la numerosa schiera di sviluppatori, costretti a dover aggiornare tramite stratagemmi più o meno validi ogni progetto Flash realizzato nel tempo.

Una delle librerie client che ha avuto più successo da quando è stato introdotto il controllo di Internet Explorer sugli ActiveX, è stata SWFObject, non tanto per le sue caratteristiche, analoghe a tante altre versioni scritte in altri linguaggi, quanto per la sua capacità intrinseca di aggirare “il problema”.

L’ultima novità proposta è un’altra libreria client, chiamata SWFFix, la quale dovrebbe racchiudere l’esperienza degli sviluppatori delle due librerie più note, la citata SWFObject e la valida alternativa UFO, al fine di risolvere definitivamente il problema colmando anche le lacune delle librerie appena nominate.

Secondo alcuni però, non c’è alcuna necessità di avere una libreria dedicata, dato che 3 linee di codice potrebbero risolvere in modo analogo, mentre secondo altri non si dovrebbe utilizzare JavaScript ma sfruttare semplicemente il buon vecchio metodo Satay, incapace però di eliminare il vincolo del click.

Altra considerazione sul metodo definito non intrusivo, la nuova scrittura tramite outerHTML di tutti gli oggetti della pagina, se utilizzata in evento onload, è sulla gestione della cache, che se satura o non attivata comporterebbe un duplice download di ogni file proposto, generalmente non proprio caratterizzati da un peso contenuto. Un condizionale o almeno una verifica all’evento DOMContentLoaded dovrebbero essere una buona soluzione.

Un pò di confusione presumo sia normale e per quel che mi riguarda il metodo migliore è quello di scrivere l’oggetto tramite JavaScript, con o senza l’ausilio di una qualunque libreria, sfruttando l’emento noscript per proporre il metodo Satay, inserendo all’interno di entrambi i casi un contenuto alternativo al fine di:

• evitare il problema del click per i browser compatibili JavaScript e Flash Player
• presentare un contenuto alternativo per i browsers compatibili JavaScript ma senza player
• mostrare l’oggetto ai browsers non compatibili o con JavaScript disabilitato, tralasciando il problema del click (caso statisticamente raro)
• mostrare il contenuto alternativo dell’oggetto ai browsers che non supportano javascript, o l’hanno disabilitato, e non hanno nemmeno il Flash Player installato (caso ancora più raro del precedente)

Sebbene quella appena descritta sembri la soluzione più idonea, questa comporta l’aggiunta di altre problematiche, quali:

1. maggiore difficoltà nella gestione di variabili dinamiche da passare al file SWF per via della duplice proposta (via script e tramite l’elemento noscript)
2. aumento, seppur irrisorio, del markup proposto
3. conoscenza almeno basilare dell’ActionScript necessario per filtrare l’eventuale versione del player richiesta, fornendo un contenuto alternativo all’interno dello stesso swf qualora questa dovesse essere obsoleta.

Ovviamente il secondo punto non è da considerare grave, poichè si tratterebbero di pochi caratteri in più presumibilmente ininfluenti, mentre il primo punto rappresenta al meglio il vero limite di qualunque proposta basata su soluzioni client.

Si può dire, quindi, non esista ancora una soluzione definitiva adatta per tutte le esigenze ma allo stesso tempo non è chiaro il perchè gli sviluppatori continuino a non proporre soluzioni server, piuttosto che client, in grado di sfruttare tutti i vantaggi di ogni proposta, quale il JavaScript, per evitare di dover attivare l’swf, Satay, per rispettare entro il limite gli standard ed in fine il server, tramite una funzione o classe portabile ed altrettanto facile da utilizzare.

Voi che soluzione adottate?