La chaîne des prototypes, le contexte d’exécution, l’objet d’activation, le scope, les closures, tout y est expliqué de manière précise et exacte, ce qui est malheureusement assez rare quand il s’agit de JavaScript.

C’est ici : Voyage au coeur de JavaScript.

Et si l’anglais ne vous rebute pas, je vous invite également à lire l’ensemble de la série ECMA-262-3 in detail (autrement dit ECMAScript 3) par Dmitry Soshnikov.

Comme le nom l’indique, il y sera question de traiter de la qualité web, selon plusieurs points de vue : webdesign, accessibilité, développement front-end, suivi de qualité web, etc.

Pour commencer, plusieurs intervenants tentent de définir ce qu’est la qualité web, et c’est déjà pas mal !

À suivre ici : http://w3qualite.net/

(enfin, dès qu’un flux RSS sera disponible ;-)

Grossièrement il s’agit d’un langage objet « classique », qui à première vue ressemble beaucoup à Java : des classes, un typage statique (optionnel), et d’autres choses intéressantes. Je vous laisse découvrir ses fonctionnalités plus en détail sur la page de présentation du langage. Sa conception a été orientée vers les performances, la sécurité, et les outils de développement. Il disposera d’une machine virtuelle qui sera intégrée dans les navigateurs qui voudront le supporter (et pourquoi pas ailleurs, comme sur le serveur), et d’un compilateur vers JavaScript pour la compatibilité (un peu comme CoffeScript).

Il y a environ un mois, un mail interne datant de novembre 2010 avait été publié sur le web. Je vous en cite quelques extraits (il s’appelait alors Dash), puisque ces prises de position n’apparaissent pas sur le site du nouveau langage (les emphases sont de moi).

The goal of the Dash effort is ultimately to replace JavaScript as the lingua franca of web development on the open web platform. We will proactively evangelize Dash with web developers and all other browser vendors and actively push for its standardization and adoption across the board. This will be a difficult effort requiring finesse and determination, but we are committed to doing everything possible to help it succeed.

Au cas où un doute subsisterait, le contexte est posé : le but est clairement de remplacer JavaScript.

Why are you circumventing the standards process? We fully intend to cooperate fully with standards processes–the problem is that the current standard processes are limited to Javascript, which is not viable in the long term. Any effort with the historic baggage that Javascript has will be extremely limited. We need to make a clean break, make progress, and then engage the community.

Google ne croit pas à « l’innovation ouverte ». Ils préfèrent concevoir en secret, puis commencer à discuter avec la communauté pour en faire un standard lorsque le langage est terminé.

What will Google developers be using? We will strongly encourage Google developers start off targeting Chrome-only whenever possible as this gives us the best end user experience. However, for some apps this will not make sense, so we are building a compiler for Dash that targets Javascript (ES3). We intend for existing Google teams using GWT and JSCompiler to eventually migrate to the Dash compiler.

Nous le savions déjà, mais les services de Google seront de plus en plus rapides et avancés dans Chrome, car il y aura des optimisations spécifiques pour ce navigateur. Chrome interprètera donc du Dart dans les futurs services de Google, tandis que les navigateurs qui ne supportent pas le langage auront du Dart compilé en JavaScript.

Le remplacement de JavaScript n’est pas ce qui me gène le plus dans cette histoire. Cette nécessité est certes discutable, car JavaScript est en train d’évoluer très rapidement avec le projet Harmony, mais toutes les nouvelles idées sont bonnes à prendre.

Ce qui est très dérangeant en revanche, c’est cette tendance de plus en plus présente chez Google à faire les choses de son côté, et à bénéficier de fait d’un avantage technologique sur ses concurrents.

Brendan Eich, concepteur du langage JavaScript et travaillant actuellement sur le projet Harmony (le futur de JavaScript), est évidemment fortement hostile à ces méthodes de conception. Si vous souhaitez connaître son avis sur le sujet, je vous invite à lire ce fil de discussion sur Hacker News, dans lequel il y explique son point de vue. Selon lui, les concepteurs du langage Dart n’ont pas connaissance des évolutions futures de JavaScript, puisqu’aucun n’a participé à Harmony.

Pour terminer, il ne faut jamais perdre de vue que les standards du web ne gagneront jamais définitivement : c’est un combat qu’il faut mener en permanence pour maintenir l’équilibre entre innovation et standardisation.

En voici quelques-unes que je vous recommande, toutes sont hebdomadaires :

• JavaScript Weekly
• HTML5 Weekly
• Web Design Weekly
• Hacker Newsletter (sélection de posts Hacker News)

Si vous en connaissez d’autres, n’hésitez pas à les indiquer dans les commentaires !

Cette histoire vous rappellera peut-être celle de _why, qui est très similaire. Et comme pour _why, des miroirs ont tout de suite été mis en place pour que ses travaux restent accessibles à tous.

Une partie du compte GitHub : https://github.com/diveintomark
Dive Into HTML5 : http://diveintohtml5.ep.io/
Dive Into Python 3 : http://diveintopython3.ep.io/

L’outil de création ultime, le « Flash du web », n’est pas arrivé, et tous les regards se tournent évidemment vers Adobe. À la différence d’un outil dédié au Flash Player, la création d’un outil pour le web est beaucoup plus complexe, car il s’agit d’un « environnement ouvert ». Les technologies permettant l’animation sur le web sont nombreuses et très différentes.

HTML

Il est bien sûr possible d’animer les éléments HTML en JavaScript, comme cela se fait depuis des années. On définit un timer, et on modifie des propriétés CSS au fil du temps. Il est aujourd’hui possible de profiter des optimisations que le navigateur peut proposer, avec la méthode window.requestAnimationFrame.

CSS peut également être directement utilisé pour animer les éléments d’une page, et il n’est pas rare de combiner plusieurs modules :

• Pour l’apparence, l’ensemble des propriétés CSS, ainsi que CSS 2D Transforms et CSS 3D Transforms.
• Pour les animations elles-mêmes, CSS Transitions et CSS Animations.
• …et les shaders arrivent. Devinez qui a fait cette proposition et l’a implémentée ? Adobe bien sûr !

SVG

Pour animer du SVG, il y a également plusieurs possibilités : du simple JavaScript, comme pour les éléments HTML (les éléments SVG sont intégrés de manière transparente au document HTML). Ensuite, l’ensemble des technologies CSS citées pour le HTML peuvent (ou pourront) également être utilisées pour le SVG. Enfin, SVG peut utiliser une technologie d’animation spécifique, SMIL.

Rappelons qu’Adobe a misé sur cette technologie autrefois, mais ils ont arrêté le développement de leur plugin SVG après le rachat de Macromedia ; peut-être préparent-ils leur grand retour sur cette technologie ?

Canvas

Canvas (2D) est une zone de pixels qui peut être directement dessinée en JavaScript, on ne manipule plus de document comme en HTML ou SVG. Les animations se font donc directement avec JavaScript, mais là aussi, il est possible d’utiliser window.requestAnimationFrame pour optimiser ces animations.

WebGL

WebGL, ou Canvas 3D, c’est le roi. Cette technologie permet de dialoguer directement avec la carte graphique, à l’aide d’une API OpenGL simplifiée (WebGL donc). C’est toujours l’élément canvas qui est utilisé, nous avons donc une zone de pixels qui n’attendent plus qu’à être dessinés !

Les outils

Vous le voyez, il existe beaucoup de technologies très différentes, et elles peuvent interagir les unes avec les autres. C’est toute la puissance du web ! Mais cette puissance est difficile à maîtriser, et il est nécessaire de revoir la plupart des concepts proposés (notamment par Flash) ces dernières années pour l’exploiter efficacement. Un seul outil ne peut pas se charger de tout, et il faudra certainement passer d’un outil spécialisé à un autre selon les technologies utilisées.

Chez Adobe, pour l’instant, nous avons une pré-version du logiciel Edge, en cours de développement, qui permet d’animer des éléments (CSS transitions) et même d’ajouter des actions (fonctions JavaScript), mais il y a encore beaucoup de travail pour passer d’un petit outil d’animation simple à quelque chose de beaucoup plus riche, comme la partie animation de Flash. Toujours dans les labs d’Adobe, nous avons également Muse, qui permet de créer des pages web sans écrire une ligne de code. Pas de gestion des animations, et la version actuelle déçoit un peu, en passant complètement à côté de la sémantique.

Sencha (ExtJS, Sencha Touch) vient de sortir la version finale de son outil d’animation CSS, Sencha Animator. Les démonstrations me semblent très prometteuses, mais l’outil se positionne sur le mobile, et se limite volontairement au support de Webkit pour cette raison, dommage.

Animatable semble également très intéressant, mais la sortie du soft (qui sera disponible sous la forme d’une application web) commence à se faire attendre.

Pas grand chose à ma connaissance pour créer de manière graphique du Canvas 2D ou du WebGL. Ces technologies sont très différentes de HTML et SVG puisqu’elles ne reposent pas sur la manipulation de documents. Je les vois beaucoup plus s’orienter vers un outil complet de type IDE, ou vers des environnements dédiés à certaines librairies (et là je rêve d’un IDE basé sur three.js).

Je n’ai pas mentionné les librairies JavaScript dédiées à l’animation, évidemment nombreuses, mais certaines offrent des approches intéressantes qui pourraient servir de base pour la création d’outils. J’ai notamment été bluffé par d3.js, qui s’affranchit (presque, puisque l’outil tourne essentiellement autour de la manipulation d’attributs et d’éléments) de la technologie de rendu utilisée pour permettre d’exploiter des données dans le cadre de visualisations. Il est ainsi très facile de passer de SVG à HTML/CSS, puisque l’outil fournit l’animation, les états, les manipulations de données, mais ne se préoccupe pas de la manière dont les changements de style vont être appliqués pendant l’animation. Il est tout de même possible d’utiliser un ensemble d’aides pour manipuler le SVG, mais c’est totalement optionnel.

Voilà, un peu en vrac, ce que j’avais en tête sur le sujet. N’hésitez pas à indiquer d’autres outils dans les commentaires (j’en ai certainement oublié un paquet !), et à partager vos idées sur les évolutions récentes et à venir de nos outils.

Isaac Z. Schlueter n’utilise les points-virgules que lorsqu’ils sont nécessaires dans ses scripts. Il a reçu beaucoup de critiques à ce sujet puisqu’il est l’auteur de npm, un projet très populaire dans la communauté Node.js. Il y a répondu sur son blog, en reprenant les arguments de ses détracteurs. Je trouve l’explication très claire : il présente en quelques lignes l’ensemble des règles, puis se concentre sur les seules exceptions qui comptent, c’est à dire celles que l’on rencontre vraiment en programmant.

L’article en question : An Open Letter to JavaScript Leaders Regarding Semicolons.

Je vous recommande également la lecture d’un autre document, JavaScript Semicolon Insertion: Everything you need to know. Inimino y décrit de manière plus approfondie toutes les subtilités de cette règle, et les exemples présentés sont très intéressants.

Pour terminer, il est important de préciser qu’aucun de ces auteurs n’essaie d’imposer cette manière de coder : il s’agit juste d’expliquer en quoi cette partie de JavaScript, qui a la réputation d’être « imprévisible », est tout à fait valide en plus d’être facile à maîtriser.

Une dernière chose, si vous utilisez JSHint, il vous suffit de placer ceci en haut de vos scripts pour désactiver l’erreur de point-virgule absent : /*jshint asi: true */

Multiple negation pseudo-class

La pseudo-classe de négation était déjà disponible avec le Level 3, mais il est maintenant possible d’indiquer plusieurs négations.

Définition : E:not(s1, s2)

Avant :

p{ /* on définit un style */ }
p.ma-classe-1, p.ma-classe-2{ /* …puis on l’annule */ }

Après :

p:not(.ma-classe-1, .ma-classe-2){}

Matches-any pseudo-class

Cette pseudo-classe permet de restreindre une sélection sur un élément, mais avec plusieurs possibilités.

Définition : E:matches(s1, s2)

Avant :

body div p.ma-classe-1,
body div p.ma-classe-2{}

Après :

body div p:matches(.ma-classe-1, .ma-classe-2){}

Local link pseudo-class

Cette pseudo-classe permet de cibler les liens pointant sur le document lui-même (<a href="#mon-element"></a>) avec :local-link, et les liens qui pointent sur le même domaine (avec le :local-link(0)). Pratique non ?

Définition : E:local-link, E:local-link(0)

Reference combinator

Définition : E /foo/ F

Permet de cibler un élément F dont l’attribut id correspond à l’attribut foo. L’intérêt n’est pas évident au premier abord, mais avec l’exemple ça va beaucoup mieux :

label:matches(:hover, :focus) /for/ input{}

On voit ici qu’il est possible d’agir sur l’élément input dont l’attribut id correspond à l’attribut for d’un élément label qui a reçu le focus ou été survolé, et ceci peu importe son emplacement dans le document.

Determining the subject of a selector

Et enfin pour finir, le Messie, celui qu’on attendait tous, le sélecteur de sujet ! Il suffit de préfixer un composant du sélecteur par le signe dollar ($) pour qu’il devienne l’élément ciblé.

Il est donc possible d’obtenir un sélecteur de parent, en le combinant avec le sélecteur d’enfant direct :

$section > h1{
  /* C’est l’élément section qui sera stylé ici */
}

Et d’une manière plus générale, nous pourrons déplacer le sujet n’importe où dans un sélecteur, et ça c’est merveilleux.

L’ajout d’un tel sélecteur a longtemps été repoussé pour des raisons de performances. Je n’ai pas connaissance des discussions qui ont eu lieu sur le sujet, mais si vous en savez plus, n’hésitez pas à l’indiquer dans les commentaires. À suivre de très près !

Mise à jour : Daniel Glazman parle du sélecteur de sujet sur son blog.

Peux-tu te présenter rapidement ?

On peut résumer mes années d’études à deux ans de DUT réseaux et communication après un bac scientifique, deux ans dans une école de design assez quelconque, et deux ans dans une école d’art (l’ERG à Bruxelles) en arts numériques et typographie. Ce sont ces dernières années en Belgique qui m’ont ouvert au libre, à l’art en ligne, et qui ont renforcé mes connaissances en création Web. Mon profil peut sembler assez étrange mais il sera sans doute de moins en moins rare, bien que je sois incapable de lui donner un titre précis. Je me situerais quelque part entre le design graphique, l’artisanat, les arts numériques, le hack et la culture libre.

Je travaille en freelance et depuis quelque temps je concentre mon activité professionnelle sur le Web design, d’abord parce que c’est par le Web que j’ai commencé le design, ensuite car l’état actuel du médium me semble favorable à l’innovation : j’aime quand les choses ne sont pas complètement établies.

Comment perçois-tu le Web design actuel ?

On vient de passer d’une période où il fallait sans cesse combler des différences d’implémentations pour faire du Web, à la période actuelle où la liberté de création s’émancipe enfin. C’est un bon moment pour commencer le métier : de nombreuses choses sont à venir et les monstres technologiques contraignants s’éteignent pour laisser la place à un Web plus flexible.

La technologie change, le processus de création doit lui aussi changer. Les designers doivent suivre l’évolution de leurs outils, être flexibles, passionnés et curieux. Il n’y a pas une seule méthode de création comme il n’y a pas une seule façon de répondre à une commande de Web design, surtout de nos jours. Globalement je trouve que les grilles sont encore très figées et tournent autour de quelques clichés :

Les technologies de mise en page nous permettent maintenant de penser multi-format, le même site doit pouvoir se décliner sur différents écrans (je pense entre autres aux CSS Media Queries) et donc nous libérer des mises en pages établies durant les premières décennies du Web. La plupart des sites d’information ou de services n’exploitent pour leur contenu – hors publicitaire – qu’une partie de l’écran. Il n’est pas nécessaire que les utilisateurs (re-)découvrent les applications en plein écran pour penser des mises en pages souples et modulaires.

Peux-tu parler de ton processus de création ?

Aujourd’hui, un navigateur Web bien équipé (je pense notamment aux outils de développement intégrés ou disponibles sous forme d’extensions) peut surpasser une chaîne de logiciels propriétaires généralement utilisés pour le design de site Web. Il ne s’agit pas de remplacer les logiciels de conception Web « tout en un » ou « wysiwyg » tels qu’ils sont aujourd’hui : je ne m’en sers pas, il ne font qu’alourdir la tâche, le code généré, et sont un terrible frein à l’apprentissage. Je parle plutôt de conception Web directement du papier au navigateur, voire directement sur le navigateur en utilisant des outils de débuggage et un éditeur de texte. Je n’utilise en ce moment que le logiciel open source Inkscape lorsque c’est nécessaire. En plus d’être open source, il est un outil très précis et parfois mieux conçu qu’Illustrator : je pense aux filtres paramétrables, plugins, fontes SVG, édition SVG…

Mes recherches sont dans un premier temps graphiques et s’organisent autour d’une documentation selon la demande du client. Je travaille ensuite des maquettes de navigation en HTML et il arrive fréquemment que des modifications de structure ou d’ordre typographique viennent à changer au cours du développement du site. C’est une méthode qui peut comporter des risques mais qui laisse une grande place à la création. Je tiens aussi à ce que le résultat de mon travail parle de ce processus, les deux sont pour moi indissociables.

Site Web de Pablo LONDONO Sarria

Je puise mon inspiration dans mon processus, étroitement lié à l’erreur. Je ne suis pas le seul designer à voir l’erreur comme une bénédiction. Il est intéressant de provoquer l’erreur à condition de savoir la cultiver. J’apprends chaque jours de nouvelles choses, je fouille, détourne et provoque, puis j’archive les résultats. Cette méthode est pour moi une source d’inspiration fertile et pérenne.

Il est important de partir sur de nouvelles bases avant la conception d’un projet Web, oubliant ce qui se fait pour adapter la demande à l’état des technologies Web. Prendre le recul nécessaire sur les tendances assurera la singularité et la qualité d’une idée. Il est nécessaire de penser au design d’une manière globale, sans que la technologie devienne prétexte. Elle ne doit que servir l’interface, c’est pourquoi le designer doit amorcer la réalisation, par exemple en participant à l’intégration.

Par conséquent, un Web designer doit savoir coder. Il ne s’agit pas de savoir programmer un site entier, de manière impeccable, de connaître les langages sur le bout des doigts, mais d’être capable de livrer des maquettes fonctionnelles et de réaliser des sites simples. La conception et la réalisation se confondent, provoquant des accidents et un engagement graphique certain.

C’est en codant que le designer va trouver une inspiration neuve, concrète, détachée de ses logiciels préférés qui sont malheureusement devenus le mainstream du design ; générant ainsi des solutions identiques quel que soit le pays ou la culture, mais aussi une demande identique car beaucoup de gens ne veulent que ce qu’ils connaissent déjà.

J’ai retenu de l’école d’art que créer ses propres outils était une manière pertinente de se distinguer, cela sous-entend profiter de l’open source, améliorer des outils existants et partager ses recherches. Aujourd’hui par exemple, la typographie sur le Web profite largement de l’open source et décloisonne l’usage des polices systèmes. Les designers s’intéressent aux licences et aux technologies jusqu’au dessin typographique libre. Les designers deviennent un moteur de la création open source pour répondre à une demande croissante de polices diffusables sans restriction.

Pourquoi refuser Photoshop ? Est-ce un choix éthique ?

Pas seulement, je pourrais utiliser Gimp pour éviter Photoshop, mais c’est surtout parce que ces outils peuvent être écartés aujourd’hui. Ces outils de retouche d’image ne sont pas faits pour assurer tous les comportements de navigation et demandent du temps de travail supplémentaire. L’utilisation de Photoshop ou Gimp avait du sens quand on demandait à un Web designer de faire de l’image, maintenant beaucoup de gens préfèrent la simplicité fonctionnelle à la surcharge graphique.

Site Web d’Aude Debout

Quels sont tes clients et comment perçoivent-ils ton travail ?

Je travaille principalement pour des projets culturels autour de l’art, de l’architecture, du design ou de la photographie. Le plus souvent, les sites que je conçois sont dépourvus d’image décoratives et d’éléments graphiques non fonctionnels. Cela me permet de rechercher un équilibre entre radicalité graphique et efficacité. Le contenu est mis en valeur et le ton de la création devient plus juste.

Il m’arrive aussi de travailler pour des clients plus frileux ; je m’efforce alors d’expliquer ma démarche même si cela ne servira pas pour le projet en question. N’est-ce pas le rôle du designer que d’impliquer un commanditaire dans un choix créatif, faisant ainsi tendre le projet vers un idéal ? Par exemple aujourd’hui, peu de clients sont intéressés par l’open source. S’ils connaissent le terme et les enjeux, il est toujours intéressant de leur présenter des applications concrètes, pointer les avantages dont ils vont pouvoir bénéficier et expliquer que l’open source n’est pas réservé aux développeurs.

Comment et pourquoi les designers peuvent-ils bénéficier de l’open source ?

Un designer est potentiellement un utilisateur de logiciels libres. Utiliser ces logiciels et signaler des idées ou des problèmes est une manière de contribuer à leur développement. Mais l’open source a constamment besoin de designers, c’est un terreau favorable pour l’innovation et pour l’inspiration comme j’en fais en ce moment l’expérience.

Il est du rôle d’un Web designer de s’interroger sur le libre, ses mécanismes et son avenir, parce que la profession de designer est basée sur la curiosité et l’ouverture. Aujourd’hui plus que jamais, l’open source a besoin de spécialistes de l’interface, de l’image et de la conception. Les portes sont grandes ouvertes.

• Travaux de Raphaël Bastide
• @raphaelbastide sur Twitter

1. HTML5 ne peut pas interagir avec une webcam

L’article souligne également que ce n’est pas près d’arriver, en raison de problèmes liés au respect de la vie privée. Bien sûr, Flash n’est pas concerné par ce problème, contrairement à HTML5, qui l’est (répétez plusieurs fois cette phrase intérieurement, jusqu’à l’assimiler complètement).

Une des premières inepties que pourrait utiliser votre interlocuteur sera de vous dire qu’une spécification existe à ce sujet. On ne peut donc pas dire que HTML5 ne permet pas d’utiliser la webcam ! FAUX. Rejetez fermement cet argument. Ce document est un document de travail, il n’a donc officiellement aucune existence. Comme CSS 2.1, il n’a pas encore obtenu le précieux statut de Recommandation (au besoin, précisez à votre interlocuteur que CSS 2.1 n’est pas encore une technologie mature). Cet argument constitue l’une des fondations de votre défense, n’hésitez pas à l’utiliser dès que vous êtes à court d’arguments.

Une personne bien informée pourra aller jusqu’à vous citer un exemple d’implémentation, comme celle de Ericsson dans Webkit, en proposant d’associer cette technologie à canvas pour manipuler vos vidéos à la volée. Je vous recommande de rejeter cet argument à l’aide d’un revers de main, une tentative d’explication risquerait de vous embarrasser, voire même de vous faire douter (voyez comme les standards sont vicieux !).

2. La vidéo en HTML5 ne peut pas être utilisée en 3D

Si l’on vous parle des CSS Transforms 2D et 3D, précisez à votre interlocuteur que CSS3 n’est pas HTML5 ! Ha ! L’affirmation est donc vraie : HTML5 ne permet pas d’afficher une vidéo sur un plan 3D. Si votre interlocuteur insiste, ne vous laissez pas tromper par ce genre de démonstration : il y a certainement du Flash quelque part. Si l’on tente de vous prouver que cette démonstration n’utilise que des technologies web ouvertes, expliquez calmement que votre choix de ne pas croire doit être respecté.

Si l’on vous parle de Canvas, WebGL, SVG et autres inepties, vous devrez faire preuve d’imagination : vos interlocuteurs ont tort, mais sauront se montrer convaincants. Le plus simple reste de simuler une allergie au changement, mais vous pouvez également trouver d’autres manières d’esquiver cette discussion gênante. Soyez imaginatif, et n’hésitez pas à laisser vos idées dans les commentaires !

3. HTML5 ne peut pas enregistrer le son de votre microphone

Si votre arrogant compagnon vous ressert, comme pour la webcam, sa soi-disante Media Capture API, la discussion est malheureusement arrivée à son terme. Cassez-lui la gueule.

4. HTML5 ne propose rien pour la vidéoconférence

Absolument rien. Quelques rabats-joie isolés pourraient, à tort, vous faire douter à ce sujet. N’en croyez rien. Posez vos mains sur vos yeux, et répétez tout haut « Flash, c’est l’avenir, HTML5 est mort. » jusqu’à oublier ce à quoi vous pensiez (cette technique est très efficace).

5. HTML5 ne permet pas d’ajouter des éléments au-dessus des vidéos, comme des sous-titres, des informations contextuelles, ou encore des boutons de navigation

Cet exemple peut sembler embarrassant. Des initiatives comme Universal Subtitles existent, et la superposition d’éléments n’est pas vraiment quelque chose de neuf en CSS. Soyons réalistes : vous ne pourrez pas convaincre qui que ce soit sur ce seul exemple. Ne vous attardez pas dessus, passez directement au point suivant.

6. HTML5 ne peut pas enregistrer votre webcam

Comme vous le voyez, la répétition est l’une des clés de notre argumentation. Voici déjà la troisième déclinaison de l’argument de la webcam, mais cette liste n’est qu’un exemple, vous pouvez décliner l’idée à l’infini : est-il possible de changer le monde avec une webcam en HTML5 ? Non. Peut-on réparer une webcam avec HTML5 ? Non ! Une webcam peut-elle tenir une discussion cohérente en HTML5 ? Non, non, NON !

7. HTML5 ne peut pas créer d’applications « desktop »

On essaiera de vous rétorquer que Flash non plus. Si vous parlez d’Adobe Air, on pourra vous rétorquer que cette technologie embarque un moteur Webkit, ce qui permet de se passer de Flash pour n’utiliser que HTML, CSS et JavaScript. On vous parlera des widgets de Mac OS X réalisés en HTML, de Mozilla Prism, de Fluid. On vous dira que cette question n’a pas de sens, car si des initiatives existent, HTML5 n’a pas été conçu pour ça, tout comme Flash. Les défenseurs des standards ouverts n’ont aucune pitié, ils ne vous feront pas de cadeau. Prenez quelques jours de repos pour oublier tout ça.

8. HTML5 ne permet pas d’afficher des vidéos avec des niveaux de transparence

Flash non plus, en fait. Il s’agit d’une particularité du bon vieux codec vidéo VP6, qui peut toujours être utilisé avec Flash. Pas d’inquiétude, votre adversaire n’en saura rien. Mélangez tout : affirmez que Flash permet de faire des vidéos transparentes, voire même qu’il a été conçu pour ça (testez les connaissances de votre interlocuteur pour éviter tout malaise). Expliquez que HTML a été conçu pour structurer des documents, pas pour afficher des vidéos transparentes. Si l’on vous parle de manipulation de flux vidéo en temps réel à l’aide de canvas, faites comprendre à votre interlocuteur que le sujet vous ennuie, et avant même qu’il ne vous réponde, montrez-lui quelques exemples d’images animées de chats.

9. HTML5 ne supporte pas encore le P2P

L’auteur de l’article de l’article d’Activetuts+ nous montre ici qu’il n’est pas dupe : entre l’API Websockets et les autres technologies associées à ce besoin, nous savons déjà que ça va bientôt arriver dans les navigateurs. Et alors ? Ce n’est pas implémenté aujourd’hui, profitez de cette petite avance ! Flash doit être utilisé pour faire du P2P, donc Flash n’est pas mort, donc Flash ne mourra pas. CQFD.

10. HTML5 ne propose pas de mode plein écran

Certes, les navigateurs proposaient du plein écran bien avant Flash, et sans avoir à l’implémenter dans votre application. Mais HTML5 permet-il de passer en plein écran en cliquant sur une petite tortue animée ? Non. Enfin presque non. Toute avancée, même mineure de Flash doit être amplifiée et répétée jusqu’à convaincre.

Derniers rappels

Nous l’avons vu, il est parfois difficile d’expliquer aux non-initiés que HTML5 va mourir, car Flash le surpassera pour toujours, dans tous les domaines. Ne vous laissez pas convaincre. Utilisez de gros titres. Présentez votre point de vue en 10 étapes, ce sera plus impactant. Remplacez vos arguments par de grosses images, comme dans l’article d’Activetuts+. Au besoin, fermez les commentaires de votre blog.

Ne doutez plus. Flash sera toujours là. HTML n’est qu’une mode. Soyez patients, ça va passer.