Ho lavorato con flash per anni e son sempre stato un pò scontento del markup necessario per inserire un filmato nelle pagine web. Recentemente ho pubblicato un sito in xHtml, la mia insoddisfazione è cresciuta insieme alle righe di codice fino a realizzare che non andava bene in questo contesto e rendeva le mie pagine inaccessibili. C'era bisogno di un metodo snello e compatibile con gli standard.
Flash è sempre fornito insieme a delle applicazioni che generano html per contenere i filmati flash. Inizialmente c'era AfterShock. Fino all'uscita di Flash 4, con il quale si possono esportare direttamente le pagine HTML. Queste pagine che al 99% trovi nei siti web.
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com
/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0"
width="400" height="300" id="movie" align="">
<param name="movie" value="movie.swf">
<embed src="movie.swf" quality="high" width="400" height="300" name="movie" align=""
type="application/x-shockwave-flash"
plug inspage="http://www.macromedia.com/go/getflashplayer">
</object>
Come puoi vedere, è qualcosa di mostruoso. Ci sono due tag principali che dichiarano lo stesso valore due volte. Internet Explorer a bisogno di un tag; gli altri browser usano l'altro. Questo è il metodo biscotto.
<object> è parte delle specifiche xHtml, ma è male implementato. E' usato da IE per inizializzare il Flash Player e caricare il filmato. <param> è il suo compagno, passa tutti i parametri necessari al player dopo che è stato avviato.
<embed> non è parte delle specifiche xHtml e impedirà la validazione della vostra pagina. E' utilizzato da netscape e gli altri browser. I parametri son passati come elementi name/value.
L'elemento <embed> fu creato da Netscape come metodo per caricare plugh-in e players nelle pagine web. Non è parte delle specifiche xHtml, e anche se molti browser lo supportano, non è compatibile con gli standard, quindi è da escludere.
Ciao ciao <embed> !
Togliendo l'<embed>, rimaniamo con l'elemento <object>, quindi dovremmo capirne tutte le potenzialità. La buona notizia è che in un modo o nell'altro tutti i browser più popolari supportano <object>. Questo elemento non richiede attributi, ma che ne sono molti che possono essere usati. Qui sotto c'è un elenco di quelli più interessanti:
classid (URI) Questo attributo può essere utilizzato per indicare la posizione di un oggetto, tramite l'URI. Può essere usato al posto o insieme all'attributo data (vedi sotto), dipende dal tipo di oggetto coinvolto.
codebase (URI) Questo specifica il percorso usato per completare l'URI specificato negli attributi classid, data e nell'archive
data (URI) Questo attributo può essere usato per specificare la posizione degli oggetti, o più in generale, la "serialized" form di un oggetto che può essere usata per ricostruirlo
type (content-type) Specifica il tipo di contenuto per gli elementi specificati da data
codetype (content-type) Specifica il tipo di contenuto per gli oggetti specificati da classid
Un'altra cosa utile che ho imparato è che un <object> può contenere elementi figli che possono essere utilizzati come alternativa se il browser non può visualizzare alcuni oggetti. Allo stesso modo in cui facevamo nel metodo biscotto con il perfido <embed>.
Ho incominciato con il fare qualche test con i vari browser. Per prima cosa ho provato a ripulire il markup di Macromedia e adattarlo all'xHtml:
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
codebase="http://download.macromedia.com
/pub/shockwave/cabs/flash/swflash.cab#version=6,0,0,0" width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
Sfortunatamente, così funziona soltanto in Internet Explorer. Dopo una piccola ricerca in google ho scoperto che il codice(GUID) specificato nella classid è per la configurazione dell'ActiveX del browser, ed è per questo che Netscape e mozilla lo ignorato (ActiveX è una tecnologia Microsoft). Il classid comunque ha un'importante funzione: dice al browser quale player usare. Quindi non possiamo saltarlo senza rimpiazzarlo con qualcos'altro.
Fortunatamente il Flash Player è configurato per rispondere alla seguente chiamata MIME: "application/x-shockwave-flash".
Quindi:
classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000"
se ne và, e arriva:
type="application/x-shockwave-flash"
I cambiamenti qui sopra faranno girare i filmati flash in netscape e gli altri browser. La prossima curiosità è CODEBASE. Esso contiene un collegamento al Plugh-in Flash sui server Macromedia. Questo è un uso incorretto dell'attributo perché ogni path in esso specificato dovrebbe appartenere al dominio del sito che si sta sviluppando e non ad uno esterno, purtroppo è così per motivi di sicurezza.
Senza il codebase, il nostro markup, comincia ed essere abbastanza corto:
<object type="application/x-shockwave-flash" width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
Prova questo codice, non funziona neanche in netscape. A questo punto, potremmo dire che non c'è alcun modo per usare markup valido e visualizzare filmati in Netscape, anche cercando sulla rete, non ho trovato una risposta, così ho cominciato a provare cose da pazzi.
Quando ho provato a inserire l'attributo data, immediatamente i filmati incominciavano a funzionare, sia in netscape che in mozilla. Anche IE sembrava andare ma....
<object type="application/x-shockwave-flash" data="movie.swf" width="400" height="300">
<param name="movie" value="movie.swf" />
</object>
...ma, provando con dei filmati più lunghi, mentre tutti i browser non avevano problemi, IE/Win neanche partiva, lui aspetta che l'intero film sia stato scaricato prima di partire, niente stream! Ho concluso che usare markup valido sarà possibile non appena Microsoft avrà sistemato questo problema con IE/Win.
Qualche giorno dopo ho parlato di questo con J. Zeldman, di come ero andato vicino alla soluzione ma senza raggiungere il risultato. Lui ne fu interessato perché aveva avuto lo stesso problema in un progetto di cui si stava occupando. Questo mi ha fatto pensare e mentre tornavo a casa mi è venuta in mente la soluzione.
L'unico problema col mio codice era che IE/Win non faceva lo stream dei filmati. Questo và bene per tutti i piccoli filmati in cui lo scaricamento è impercettibile. Allora, perché non creare un file piccolissimo che al primo frame carica il filmato che realmente vogliamo visualizzare ?
Non importa se il tuo filmato è di vitello, maiale o pollo, basta che lo getti nella salsa e funzionerà. Questo lo chiamiamo il trucco del piatto.
Ho creato un nuovo flash movie e ci ho messo nel primo frame il seguente ActionScript:
_root.loadMovie(_root.path,0);
Questo dice al player flash di caricare un'altro filmato, il cui nome è nel path della root, nel Level 0 del filmato corrente. Dobbiamo solo accertarci che il nome del filmato che vogliamo caricare sia nella variabile path
Nel nostro caso è sufficiente chiamare il movie così:
c.swf?path=movie.swf
il contenitore è c.swf. E così gli passo una variabile chiamata path con il valore movie.swf.
_root.loadMovie("movie.swf",0);
Ora dobbiamo solo aggiustare un attimo il markup:
<object type="application/x-shockwave-flash" data="c.swf?path=movie.swf" width="400" height="300">
<param name="movie" value="c.swf?path=movie.swf" />
</object>
eccolo infine, lineare, chiaro, significativo e migliorato. Ma cosa facciamo delle funzioni del CODEBASE che abbiamo tolto ?
Il problema principale dell'eliminazione del codebase è che esso è l'unico modo per avvisare gli utenti che il loro player flash non è aggiornato e di fargli scaricare l'ultima versione in automatico.
La cosa si può aggirare: semplicemente usa un movie sacrificale da mettere in cima alla pagina che invece abbia dentro il CODEBASE. Deve essere un filmato che non abbia nessun effetto sul sito, un rettangolo bianco che serve soltanto a avvisare l'utente che deve aggiornate il flash player.
Ho scritto questo articolo sapendo che sono soltanto un uomo che cerca di contribuire al continuo miglioramento. Non considero quello che ho scritto come una teoria scientifica: quello che dico oggi è giusto fino a prova contraria.
Drew McLellan è l'autore di Dreamweaver MX web development e un membro del Web Standard project, lavora con Macromedia per migliorare il supporto agli standard all'interno dei software.
Se ti è piaciuto questo articolo, leggi anche quello di Elizabeth Castro, CIAO CIAO <EMBED>.
Quest'ultimo è più recente ed aggiornato