La méthode "classique"

Voici le code que nous propose Flash lorsque il génère une page html pour contenir notre animation :

<object classid="clsid:d27cdb6e-ae6d-11cf-96b8-444553540000" codebase="http://fpdownload.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=8,0,0,0" width="550" height="400">
<param name="allowScriptAccess" value="sameDomain" />
<param name="movie" value="animation.swf" />
<embed src="animation.swf" width="550" height="400" allowScriptAccess="sameDomain" type="application/x-shockwave-flash" pluginspage="http://www.macromedia.com/go/getflashplayer" />
</object>

On s'est donc depuis toujours contenté de ce code, pour la simple raison que ça fonctionne. Mais il pose un problème de taille : il n'est pas du tout compatible XHTML 1.0 Strict, la faute à l'élément obsolète embed, crée par Netscape à la bonne époque.

La méthode "Flash Satay"

Pour palier à ce problème, Drew McLellan a publié en 2002 (déjà...) un article sur A List Apart intitulé "Flash Satay: Embedding Flash While Supporting Standards". Voici le code correspondant à sa méthode :

<object type="application/x-shockwave-flash" data="animation.swf" width="550" height="300">
<param name="movie" value="animation.swf" />
Contenu alternatif
</object>

Cette méthode repose donc sur l'utilisation exclusive de l'élément object, en conformité avec la norme XHTML Strict. Autre avantage, le contenu alternatif est inclus directement à l'intérieur de l'élément, dans le cas ou le navigateur se trouve incapable de lire l'animation.

Génial donc... pas tout à fait malheureusement :

  • Cette méthode empêche Internet Explorer de lire l'animation en chargement progressif, c'est à dire qu'il attend que celle-ci soit complètement chargée avant de pouvoir la lire, plutôt embêtant donc pour des animation "lourdes".
  • Le contenu alternatif n'est pas lu par JAWS

Pour le premier point, on peux bien contourner le problème en chargeant un premier Flash vide (donc léger) qui chargera ensuite l'animation principale avec la fonction loadMovie, mais appliquer ce principe à chaque fois est plutôt rébarbatif.

Comme si ça ne suffisait pas, il faut depuis peu prendre en compte l'activation des contenus actifs sous Internet Explorer. Kezako ? Suite à une sombre histoire de procès, le contenu actif (animations Flash, mais aussi applets Java, films Quicktime, etc...) ne sera pas interactif (il ne sera pas réceptif aux événements souris ou clavier, par exemple) tant que l'utilisateur n'aura pas cliqué une première fois pour activer le contrôle.

Passer par javascript

La seule solution pour contourner ce problème, et rendre les animations directement utilisables sous Internet Explorer, est de passer par du javascript pour insérer notre animation. Adobe a notamment proposé sa solution, disponible ici, Microsoft en propose une autre là.

SWFObject

Au delà de ces solutions est apparue SWFObject (anciennement FlashObject, mais Adobe n'a pas aimé l'utilisation du terme "Flash"...) qui combine très bien les différentes solutions à tous ces problèmes :

  • C'est également une solution Javascript, donc ça règle le souci de l'Active content sous IE
  • De ce fait, c'est compatible XHTML
  • Le flash vient dynamiquement remplacer un bloc HTML que l'on détermine dans la page et détecte la version du plugin Flash. Si celui-ci n'est pas installé ou la version n'est pas suffisante, le contenu HTML reste affiché comme contenu alternatif.

Après quelques tests, c'est une solution fiable et la plus simple à utiliser. Le script principal fait une dizaine de ko, ce qui reste très raisonnable.

Bien sur on continue de passer par du Javascript, seul moyen d'éviter l'activation sous IE. Si celui-ci est désactivé, alors le contenu alternatif s'affichera même si l'internaute dispose de Flash. Mais on est bien aujourd'hui obligé de faire ce choix.

SWFObject est displonible ici.