L'usage d'un élément en Flash dans un site n'est pas toujours pertinent, les animations qu'on ne pourrait pas faire autrement sont relativement rares. Mais y'a des fois où on ne peut pas se passer d'un élément en Flash dans une page HTML : Pour y mettre de la vidéo, pouvoir lire un mp3 à coup sûr, ou tout simplement parce qu'un client veut du Flash, et là, ça se discute pas : « Le Client a toujours raison ».
Alors évidemment, le Flash™ « sapu saimal » parce que c'est un format propriétaire tenu par Macromedia puis par Adobe, même s'il le format de fichier est documenté et qu'il existe un plugin alternatif open-source qui peut lire les documents en .swf (Gnash, mais dont les fonctions sont quand même limitées), mais aussi la plupart du temps, c'est l'inclusion d'un élément en Flash dans le HTML qui fait hurler « cépa codex ! ».

Un des points très importants à noter, c'est que le Flash n'est pas indexé par Google, mais il se trouve que d'autres moteurs (dont Exalead) sont capable d'entrer dedans [NB1] et de suivre les liens accessibles d'entrée...

L'autre souci, c'est que le Flash est rendu indépendamment du navigateur web. Il interagit avec lui, avec l'arbre DOM du document HTML où il est inclu, mais ne tient absolument pas en compte les actions de navigation tels que avancer/reculer/marque-pager. Pour ce dernier, il serait possible d'utiliser dans l'URL IRI [NB2] la position d'ancre (ce qui est après le #) pour indiquer une position dans l'animation Flash (méthode déjà utilisée dans certaines applications Ajax-like), mais dans la pratique, personne ne s'y est intéressé. D'où cette impression que le Flash n'a jamais été dans la partie du web, mais en-dehors de ses fonctions de base. Ce qui donne cette inimitable frustration totale que laissent les sites intégralement en Flash quand on veut en montrer une partie très particulière à un ami par mail : Au lieu de donner directement une URL IRI (Je m'y ferais jamais) d'une page web, éventuellement avec une ancre, on doit expliquer qu'à cette adresse, il faut attendre 4 secondes, cliquer sur le lapin bleu (celui qui galope de droite à gauche), puis aller sur le rectangle à droite et le déplacer de 183 pixels vers le bas [NB3]. Le visiteur doit perdre du temps à comprendre une interface qu'il ne retrouvera sûrement que pour ce site.
“Immersif” soit, mais totalement frustrant.

Utiliser du Flash pour un élément de navigation, pour faire une galerie photo, ou pour faire un effet supplémentaire est souvent une erreur, qui rend le site moins utile, trop lourd [NB4], moins facile à visiter. Souvent, les intros en Flash sont considérées comme interminables et pénalisent l'expérience du visiteur du site plutôt que lui plaire. Je déteste le site de l'ACBD (dont je suis membre) rien que pour ça.

À sa décharge, le plugin Flash est sans contestation possible le plus répandu et peut-être le plus universel. Il permet à coup sûr de lire un document sonore en chargement streamé, ainsi que la vidéo. Mais jusqu'à l'intégration toute récente du codec H264 (une version particulière du MPEG4), la qualité n'est pas franchement top, pour une consommation de ressources honnêtement peu justifiée.

Pourquoi l'extension Flashblock est si populaire

Si vous allez sur le site du journal Libération depuis plusieurs années, vous avez remarqué combien ils ont été très tolérants envers les pubs en Flash : celle qui font du bruit (mention spéciale à la campagne Wanadoo qui faisait Zdoing! Zdoing! avec la mention « cliquez ici pour arrêter ce bruit »), voire pire, celles qui font de la vidéo.
En général ce genre de pub est extrêmement agaçant par le bruit généré, par très work-safe, gourmant dans la puissance demandé à l'ordinateur. En ouvrant une dizaine d'onglets à partir de la une d'un site de news pour lire tranquillement des articles, il m'est souvent arrivé que ma machine soit complètement à genoux à cause des pubs en Flash, ou que je perde un temps monstre à chercher quel onglet je dois fermer pour arrêter ce p↯☭↹∞n de Zdoing! Zdoing!.

Dès que j'ai vu les prémices de l'extension Flashblock pour Firefox, je l'ai immédiatement installé. De suite, ce fut un soulagement. Pouvoir lire Libération sans les pubs sonores, CSO France sans les animations qui mettent à genoux ma petite machine (à l'époque un Pentium IV)... un bonheur.
Flashblock ne bloque pas le chargement du Flash. En fait, il ne fait qu'en geler l'exécution, et le masquer par un place-over.

Alors évidemment, ça fait râler les publicitaires, les annonceurs, les e-régies net-publicitaires.com, les web-@gency et autres flashmasters... Ceux-ci d'ailleurs vont pas tarder à trouver la méthode pour détecter que le plugin est installé pour vous interdire l'accès au site web support de leur pub si gainiale [NB5]

Mais très honnêtement, si la pub ne s'obligeait pas à venir squatter du temps de cerveau déjà occupé par des méthodes aussi irritantes, elle n'emploierait pas autant de pollueurs du web. Le fait qu'elle ne peut s'en empêcher a forcément rendu nécessaire ce genre d'application afin de lire tranquillement une page de texte sans être insupporté par des animations quelconques (les GIF clignotants sont déjà des plaies).

La cabale anti-Flash tient souvent de la réaction épidermique à des publicités trop ”pro-actives“.

Balises et balisons : La guéguerre entre Embed et Object

Historiquement, le langage HTML a été étendu par Netscape, puis « extend and embrance » par Microsoft. Chacun y allait de sa petite innovation. Par exemple, qui se souvient des balises <layer> ? c'était le pendant de chez Netscape aux <div> proposé par Microsoft. Idem pour <object>, qui fut la réponse du berger à la bergère aux <embed> de Netscape.
Mais væ victis, ni les layers, ni les embed ne furent retenus par le W3C. Ces deux propositions furent enterrés avec le reste du code de Netscape Navigator (qui venait de perdre la première guerre du web) par le projet Mozilla qui en hérita, pour justement être conforme W3C et tirer un trait sur les erreurs de programmation du passé.
Étonnement, la doc en ligne écrite à l'époque de Macromedia Flash n'a pas été mise à jour. On nous explique toujours qu'embarquer dans la balise <object> un élément <embed> est très utile pour rester compatible avec tous les navigateurs... Ahem... Non, sans rire, je doute qu'il reste suffisamment de Netscape Navigator version 3 ou 4 justifiant d'utiliser encore cette balise. Et pourtant, pratiquement 95% des appels de Flash se font avec du code redondant qui n'est jamais interprété.

On y notera une des propriétés très intéressantes de la balise <object> : le fallback, qu'on pourrait rapprocher de la « dégradation élégante » qui m'est si chère en manipulation DOM. Si jamais l'interprétation des attributs de la balise <object /> échoue, le navigateur client va prendre le contenu entre les deux balises <object> et </object> pour l'interpréter. Chaque balise <param /> est susceptible dans ses attributs d'apporter des précisions complémentaires pour le plugin et les autres balises sont exécutées telles quelles. Un comportement qu'on pourrait croire analogue à <noscript> ou <noframe>, sauf qu'on intégrerait le source du script (ou des frames) dans l'attribut de la balise, ce qui aurait été largement plus intelligent.

<Applet>us dinosaurus et <Iframe>us archeis ne sont pas dans un bateau...

Quitte à parler de fossiles pré-W3C...
En faisant de recherches pour ce billet, je suis tombé sur une vieille balise, cachée dans les strates de la préhistoire du W3C : <applet>. La balise <applet> a été introduite par Sun Microsystems pour l'usage exclusif d'inclusion d'un programme en Java dans une page HTML. Cette balise fut complètement oubliée, et pour cause : aucun mécanisme codebase n'a été prévu pour signaler où chercher le plugin si celui-ci n'est pas présent dans le navigateur client. Une clause réellement indispensable et pénalisante à l'époque où le Java et le Flash n'étaient pas installés par défauts dans les systèmes d'exploitations (non non, ni dans Microsoft Windows 98, ni ME, ni 2000). Il fallait prévoir le coup dans le mécanisme de fallback.

J'ai aussi déniché pour vous une autre balise potentiellement intéressante. <iframe> a un “avantage” : sortir l'élément Flash du reste du HTML, ce qui fait que MSIE n'est plus fautif vis-à-vis du brevet Eolas (lire plus bas). Néanmoins, cela génère plusieurs bugs :

• l'absence de gestion de codebase et de fallout en cas de plugin défaillant (absence du plugin, ou, cas récemment rencontré, version “archaïque”)
• l'absence de récupération de l'arbre DOM par le programme Flash (si ce dernier modifie la structure de l'ensemble de la page)

La balise <applet> est dépréciée dans HTML4, les frames étant dépréciés dans le XHTML, leur usage n'est donc pas recommandé dans l'optique d'un internet moderne.

La question Eolas

Les “solutions” Javascript par manipulation DOM pour inclure du Flash sont une fausse réponse à une question viciée : celle de la compatibilité avec MSIE suite, non pas à un bug, mais à un procès.
En 2004, Microsoft perd un procès qui met les bases mêmes du web en danger. Eolas, une officine patent-troll [NB6] arrive à faire croire qu'elle a le droit de taxer tout ceux qui osent mettre un contenu interactif dans une page web, le principe même du plugin devient problématique. Non seulement, il y a un prior-art avéré à ce brevet, mais qui plus est on est dans un cas de brevet logiciel lequel n'aurait jamais dû être autorisé. Et les conséquences sont telles que pour une fois, tout le monde a... défendu Microsoft et hurlé contre Eolas (oui, tout le monde : le W3C, Adobe, Mozilla Foundation, Apple, Opera,... dont pas mal de multinationales en faveur des brevets logiciels ! ) au point que l'EFF et d'autres organismes pro-open-source se sont lancé dans un vaste plan de recherche pour contrer le brevet Eolas, estimé comme totalement illégitime.

Peine et procès perdu : Microsoft est condamné à payer plus d'un demi-milliard de dollars au maître-chanteur, et à brider le fonctionnement des plugins (dits « ActiveX controls ») dans son navigateur.
C'est ainsi qu'une mise à jour majeure a fait en sorte que TOUT plugin dans une page HTML (Flash, mais aussi Windows Media, Quicktime, PDF, Microsoft Excel,...) dans les navigateurs de Microsoft doit désormais être “activé” par un clic. Soit un popup s'affiche à l'écran, soit une image prérendue figée doit être cliquée pour activer [NB7] le plugin.
Dans les deux cas, ce comportement est ajouté par l'exécution obligatoire d'un script (très probablement un JScript ou un VBScript) hébergé en local dans MSIE. Et il se trouve que ce petit bout peut faire bugguer de façon aléatoire pas mal d'applications Javascript (et Ajax), dont mon propre site. Microsoft a pallié par un pathétique cache-sexe le refus de l'USPTO de reconnaître ses erreurs.

Très personnellement, je reste étonné que ni Opera, ni la Mozilla Foundation, ni KDE (éditeur de Konqueror), ni Apple (éditeur de Safari) ne furent inquiétés. Seul Microsoft fut la cible de ce patent-troll, très probablement à cause de sa forte rentabilité devant des tribunaux.
Conséquence : MSIE est l'unique navigateur affligé de ce comportement [NB8].

Heureusement, toutes les tares ne sont pas éternelles : Il se trouve que le mois dernier Microsoft a signé en catimini un accord avec Eolas, tandis que l'USPTO se prend actuellement des volées de bois vert de partout, l'EFF déterrant tout plein de cadavres concernant les brevets logiciels. On peut raisonnablement imaginer que bientôt MSIE ne sera plus bridé par le problème, par le jeu d'une mise-à-jour.
Et que donc la solution Javascript est une réponse erronée à une question qui n'aurait jamais dû être posée.

La réponse Javascript, pourquoi pue-t-elle plus que le Flash

SWFobject.js n'a qu'un seul objectif : permettre à une animation en Flash de se lancer dès l'affichage de la page HTML dans MSIE. Sans l'infâme popup, ni clic d'activation.
Voici le code HTML+Javascript qu'on devrait mettre dans un site pour inclure du Flash avec :

<script type="text/javascript" src="swfobject.js"></script>
<div id="contenuflash">
  Ce texte est remplacé par l'animation flash.swf
</div>
<script type="text/javascript">
  var so = new SWFObject("flash.swf", "IdDuBlocDuSwf", "LargeurEnPx", "HauteurEnPx", "version", "CouleurDeFond");
  so.addParam("quality", "low");
  so.addParam("wmode", "transparent");
  so.write("contenuflash");
</script>

Attendez... il faut une balise <noscript>. Parce que ok, SWFobject gère l'absence du plugin Flash (et théoriquement des versions obsolètes), mais il faut aussi gérer l'absence de Javascript... On doit définir 2 fois (DEUX FOIS) la taille et l'aspect du document Flash. En plus, l'objet Flash devient invisible pour les moteurs de recherche comme Exalead. Et pour parfaire le massacre, on se retrouver à pénaliser ceux qui consultent les billets par un lecteur RSS. Ce dernier peut tout à fait être capable de gérer le Flash, mais à condition d'avoir la même référence que votre site, c'est à dire la bibliothèque JS et son insertion ésotérique. Car la méthode préconisée par l'auteur de SWFobject est standard, soit, mais vraiment pas la bonne si jamais on a plus de deux bibliothèques à charger. Quant à son insertion de code Javascript au sein d'un document HTML, il relève vraiment de la préhistoire...

En fait, on est à la fois dans un souci concernant la gestion du plugin Flash, mais aussi du fonctionnement correct de Javascript : Pour peu qu'un incident à l'interprétation d'un Javascript (notamment dans une exécution synchrone comme SWFobject l'impose à ses utilisateurs), qu'une sécurité quelconque dans les paramètres du navigateur (ou de l'antivirus ou du proxy de votre entreprise, voire carrément de votre FAI paranoïaque), ou que vous ayez fâché votre marabout regex, l'édifice s'effondre, et votre Flash n'est définitivement pas lancé [NB9]. Car SWFobject n'offre que le service minimum en terme de dégradation élégante, plombe de redondance le fallback, et doit alourdir sauvagemment son code pour résoudre les problèmes de fuites urina de mémoire de MSIE. SWFobject.js n'est qu'un bricolage de fortune, pas trop mal codé, certes, mais structurellement incomplet voire boiteux.

Tout ça pour éviter un clic (voir plusieurs, re-regardez la page de garde de nrj.fr) chez les gens utilisant MSIE. S'il plante, pas de Flash, même sur les navigateurs qui ne sont pas concernés par le procès Eolas. Soit une très grande partie des navigateurs... Au lieu d'avoir le comportement considéré comme “normal” depuis deux ans avec MSIE, on prend le risque de faire planter son site dans 100% des navigateurs modernes. Quel progrès !
Le problème a l'air d'empoisonner beaucoup de monde, puisque moi qui ne suis théoriquement même pas professionnel, j'ai déjà été sollicité six fois sur le sujet depuis début Août par des “amis” infographistes jouant aux script-kiddies. J'aurais dû leur facturer mes services.

Être propre dans le HTML, élégant dans sa structure

Alors, comment insérer proprement des éléments en Flash dans un site web, avec une dégradation élégante pour les moteurs de recherche et les personnes handicapés, dans un minimum de code, mais parfaitement valide W3C et susceptible d'être fonctionnel pour plusieurs années ?

La solution est idiote. Puisqu'à relire attentivement la spécification de la balise <object>, on s'aperçoit qu'on avait la solution depuis le début. Si, si ! relisez le chapitre plus haut. Eeeeeeh oui...

Donc nous devrions plutôt écrire :

<object data="src.swf" avec en paramètres la taille prévue de l'animation, son typemime...>
  <param les paramètres propre à l'animation/>
  Texte de remplacement, description, éventuels liens internes qui doivent être suivis par les moteurs de recherche... voire une capture graphique pour respecter l'aspect du site
</object>


MSIE vous cause réellement un souci ? Vous voulez vraiment faire l'économie d'un clic ? Il suffit de ne parler qu'à lui pour lui donner vos “solutions” sans polluer les autres. Les recettes existent sur le net (commentaires conditionnels, manip dom, le tout tient en une ligne), pas besoin que j'en usurpe la paternité.

Parce qu'il y a plein de [NB] dans mon billet qu'il faut bien les caser quelque part :

1. ↑ entrer [dans le Flash] : Dans le cas d'Exalead, vu que ce site repose sur le navigateur Konqueror pour faire ses captures d'écrans (User-Agent : « Mozilla/5.0 (compatible; Konqueror/3.5; Linux) KHTML/3.5.5 (like Gecko) (Exabot-Thumbnails) »), je parie qu'ils utilisent Gnash, mais qu'ils se limitent aux liens immédiatement accessibles pour des raisons évidentes de performance et de sécurité.
2. ↑ URL IRI : Comme déjà expliqué ici-même, le terme IRI est recommandé à la place d'URL ou d'URI
3. ↑ on doit expliquer [la navigation dans un Flash] : Je plaisante à peine : je me serais bien passé de devoir donner un modus operandi aussi compliqué dans mon billet « Ballet perpétuel » pour expliquer comment accéder à la section “cashmere knit”. Si un lien était faisable pour aller directement dans cette partie de l'animation, je serais mille fois plus content.
4. ↑ [site] trop lourd : Et bien souvent, difficilement maintenable. Mon camarade Xylpho a fait le tour des sites de photographes avec des galeries en Flash. Ceux-ci sont très rarement mis à jour à cause de la lourdeur de maintenance uniquement pour ajouter quelques photos. Quant à laisser le programme Flash générer dynamiquement la liste des photos, on imagine d'ici la lourdeur côté client et les risques pour le serveur.
   Le projet Lightbox.js et ses compatibles sont d'immenses progrès.
5. ↑ interdire l'accès : Ça demandera du Javascript et de détecter qu'une image est bien présente à l'IRI chrome://flashblock/content/flash.png et [...]flashplay.png ... ou conforter des comportements comme « Why Firefox is blocked ». Politiquement, c'est une énorme erreur de communication.
6. ↑ patent-troll : Un patent-troll est une entreprise de taille ridicule (souvent réduite à un homme de paille, voire une boîte postale dans les îles Caïman) qui gère un important portefeuille de brevets, ici de l'Université de Californie, dans l'unique but de “valoriser” ces brevets devant un tribunal. Ces derniers n'ont souvent même pas été proposés à des industriels. Il n'y a donc aucun intérêt industriel ou technique derrière, juste un cabinet d'avocat qui pose des collets et récolte d'indécents dommages et intérêts si jamais quelqu'un a eu le malheur de “reproduire” en toute innocence un brevet dont il ignorait tout.
7. ↑ cliquer pour activer : Eh mais, attendez, c'est pas le comportement de base de FlashBlock ? Procès pour plagiat !
8. ↑ l'unique navigateur : Si on compte les versions 6+ et 7 ainsi que tous les faux navigateurs qui recarrossent le moteur de MSIE comme AvantBrowser, AOL ou Maxthon.
9. ↑ défintivement pas lancé : Par définitivement, je veux dire que même une interaction du surfeur est inactive. Il n'y a qu'un espace vide, sans rien, là où il suffisait juste d'un clic pour ceux qui gardent un navigateur obsolète.

L'icône IE4Linux a été proposée par JesusDA pour le set d'icônes Tango à la demande de FreeDesktop.