Les archives du mois de février 2012

Le mantra de l’intégrateur

Après le débat lancé par le W3C face aux préfixes des navigateurs, Raphaël Goetter d'Alsacréations a partagé sa solution pour facilement adapter ses sites en utilisant le script -prefix-free.

Comme beaucoup d’outils de ce genre, -prefix-free nécessite une requête HTTP et un traitement du JavaScript, au détriment des performances du navigateur.

En ce qui me concerne, je considère que les avantages fournis contrebalancent ce handicap. Mais sur mobiles, où les temps de chargement sont prépondérants, la question mérite le détour.

J'ai d'abord cru à une blague, mais il est apparemment très sérieux. Jérémie Patonnier a ce matin très bien détaillé la problématique, en titrant son article "Lier CSS à JavaScript : une mauvaise idée".

De manière générale, ce genre d'interrogations arrive rarement quand on applique un mantra, une philosophie globale, un fil conducteur qu'on applique dans n'importe quelle situation. Personnellement, ma philosophie se résume en une question.

Qu'est-ce qui est le mieux pour l'utilisateur ? 

Le graphiste a maquetté des listes déroulantes personnalisées. Je peux utiliser un script pour simuler une liste déroulante avec la charte maquettée, au détriment des performances de la page, ou laisser les listes déroulantes par défaut du navigateur, au détriment de la charte graphique. Qu'est-ce qui est le mieux pour l'utilisateur ?

Je dois intégrer une page simple avec quelques éléments à rendre dynamique (apparition au clic ou au survol). Je peux utiliser une librairie type jQuery pour coder ça rapidement, ou prendre un peu plus de temps pour coder la même chose en JavaScript seul. Qu'est-ce qui est le mieux pour l'utilisateur ?

J'ai du texte dans une police personnalisée. Je peux importer une police en CSS3 de plusieurs dizaines de Ko, ou découper une image de quelques Ko. Qu'est-ce qui est le mieux pour l'utilisateur ?

En octobre dernier, je partageais déjà mon point de vue sur la finalité d'une page web :

On ne fait pas un site web pour le client. On fait un site web pour un utilisateur. Un utilisateur est une vraie personne. Un utilisateur a son terminal (ordinateur, smartphone, télévision, ...), son entrée (clavier/souris, tactile, ...), sa sortie (écran 16/9, 4/3, 72 dpi, 326 ppi, ...), sa connexion internet (56k, ADSL, Fibre, Edge, 3G, ...). Un terminal à son système d'exploitation (Windows, Mac OS, iOS, Android, ...), son processeur, sa carte graphique, ... En pratique, vous aurez quasiment autant de configurations possibles que de visiteurs. Quand vous travaillez pour le client, vous rendez 1 personne heureuse. Quand vous travaillez pour l'utilisateur, vous rendez des milliers voire des millions de personnes heureuses.

D'autres intégrateurs auront surement un mantra différent, privilégiant par exemple la charte graphique, le temps de réalisation ou le coût d'un projet. On peut y trouver un intérêt sur le court terme. Mais je pense que seule une conception pensée pour l'utilisateur reste valable sur le long terme.

« Le Web Ouvert a besoin de vous »

Daniel Glazman, co-président du groupe de travail CSS du W3C, a lancé aujourd'hui un appel à tous les acteurs du web pour éviter que les fabricants de navigateurs n'implémentent les préfixes -webkit- sur le long terme.

Je demande à toute la communauté des acteurs du web d'arrêter de concevoir des sites pour WebKit seulement, en particulier quand le support d'autres navigateurs n'est qu'une question d'ajouter quelques lignes de propriétés CSS avec des préfixes.

Je demande à toute la communauté des acteurs du web de supprimer immédiatement et d'arrêter d'implémenter la détection (sniffing) de navigateurs basés sur WebKit. Vous possédez un tel site ? Montrez votre soutien pour le Web Ouvert et supprimer cette détection immédiatement après avoir lu cet appel.

Je demande à la communauté des utilisateurs du web et des designers du web d'arrêter de recommander des sites qui nécessitent un navigateur en particulier alors qu'ils pourraient être ouverts à plusieurs navigateurs. Ne faites pas de lien vers ces sites, et mentionnez les uniquement pour faire savoir à la communauté qu'ils échouent dans leur service du Web Ouvert. Ne nourrissez pas les trolls, blacklistez les, peu importe à quel point le service qu'ils fournissent est cool.

Je suis totalement d'accord avec Daniel Glazman sur les deux premiers paragraphes. Je plaide coupable d'avoir moi même déjà utilisé des propriétés CSS avec uniquement leur préfixe WebKit (en particulier il y a 1 ou 2 ans, avant que Firefox ne revienne dans la course et commence à implémenter pleins de nouvelles propriétés).

Par contre, je suis convaincu qu'il se trompe de combat en cherchant à lancer une chasse aux sorcières. Mais puisqu'il insiste...

http://www.w3.org/2008/site/css/minimum
Ligne 134: .w3c_leftCol a:hover,.w3c_leftCol li a:focus{ -moz-transition-property:background-color;-webkit-transition-property:background-color;-o-transition-property:background-color;-moz-transition-duration:.3s;-webkit-transition-duration:.3s;-o-transition-duration:.3s;}
Ligne 181: .button{border:0;-moz-border-radius:3px;-moz-box-shadow:0 1px 3px rgba(0,0,0,0.5);-webkit-border-radius:3px;-webkit-box-shadow:0 1px 3px rgba(0,0,0,0.5);border-bottom:1px solid rgba(0,0,0,0.25);background-color:#555;color:#FFF;cursor:pointer;font-size:81%;font-weight:bold;left:5px;padding:2px 5px;position:relative;text-shadow:0 -1px 1px rgba(0,0,0,0.25);}
http://www.w3.org/2008/site/css/advanced
Ligne 31: .secondary_nav{ -webkit-box-shadow:0 1px 2px #fff;-moz-box-shadow:0 1px 2px #fff;-webkit-border-radius:5px;-moz-border-radius:5px; }
Ligne 35: #search-form{ -webkit-border-radius:5px;-moz-border-radius:5px;}
Ligne 233: #request_form fieldset input:focus,#request_form fieldset textarea:focus{ -webkit-transition:border .2s linear,-webkit-box-shadow .2s linear;-moz-transition:border .2s linear,-moz-box-shadow .2s linear; }

Le site du W3C lui-même n'utilise pas systématiquement les noms de propriétés non-préfixées, et jamais les préfixes pour l'ensemble des navigateurs (pourquoi tant de haine envers -ms- ?). Je suppose que je devrais faire comme Daniel Glazman, et lui envoyer un e-mail.

C'est facile de dénoncer et de pénaliser. Les acteurs du web ont fait quelque chose de stupide en utilisant uniquement des préfixes -webkit-. Les fabricants de navigateurs vont faire quelque chose de stupide en implémentant les propriétés avec le préfixe -webkit-. Le W3C propose une réponse stupide visant à pénaliser les auteurs du web ignorants ou peu consciencieux.

Avant de vouloir pointer du doigt et pénaliser les sites qui favorisent WebKit, il serait peut être bon d'éduquer les acteurs du web. Nous sommes en 2012 et le W3C ne propose aucune documentation simple et claire, compréhensible par le commun des mortels, indiquant le bon usage et le bon fonctionnement des propriétés CSS. C'est regrettable, mais pas étonnant qu'on se retrouve dans une telle situation.

Tous les navigateurs veulent implémenter le préfixe -webkit-

Hier, lors d'un comité du groupe www-style du W3C, réunissant Daniel Glazman (co-président du groupe de travail CSS du W3C), Tantek Çelik (Mozilla), Florian Rivoal (Opera) et Sylvain Galineau (Microsoft), la discussion la plus hallucinante que j'ai pu lire à ce jour.

glazou: Title is: Why and How to Implement Other Vendors' Prefixes
tantek: This is a specific subtopic of vendor prefixes
tantek: The problem statement right now, and this is a problem for
Mozilla and any other non-WebKit browser
tantek: Sites have webkit-specific content, and serve backup content to
everyone else. Specifically for mobile content.
tantek: Non-WebKit browsers face prisoners dilemma
tantek: similar to quirks in 2003 or so
tantek: At this point we're trying to figure out which and how many webkit
prefix properties to actually implement support for in Mozilla
plinss: Zero.
tantek: Currently we have zero. Zero is no longer an option for us.
Florian, Sylvain: Zero is not an option for us anymore either.

Vous avez bien lu : pour Mozilla, Opera et Microsoft, il n'est plus envisageable de ne pas implémenter les propriétés en utilisant les préfixes -webkit-. Et ça ne va pas s'arrêter là :

tantek: We will also need to send a webkit-tricking UA string.
tantek: Just like WebKit sent "like Gecko" in its UA string, we have to do
the same thing again

Je ne sais pas trop comment on peut s'y prendre, mais il va falloir gentiment dire à Mozilla, Opera et Microsoft d'arrêter leurs âneries.

Chrome sous Android ne supporte pas Flash

Hier, une toute première beta de Chrome sous Android est sortie. L'application est disponible uniquement sur Ice Cream Sandwich (qui 3 mois après sa sortie représente 1% des appareils sous Android).

Signe des temps, Adobe et Google ont confirmé que Chrome sous Android ne supportera jamais Flash Player. A terme, Chrome va remplacer le navigateur par défaut sous Android. Si vous pensiez encore pouvoir faire des sites en Flash pour mobiles, repensez-y.

Le coût grandissant du développement interactif

R Blank, entrepreneur, formateur ActionScript et fondateur de la communauté Flash à Los Angeles, a écrit un article qui m'a fait sortir de mes gonds : "La mode majeure du développement interactif" (ou "Le coût grandissant du développement interactif" dans sa première publication).

D'un point de vue d'entreprise, la clé à retenir de cette période est que, dollar pour dollar, les expériences fourniront moins de fonctionnalités, pour un plus petit pourcentage de visiteurs. Dit autrement, produire la même fonctionnalité, livrée au même pourcentage du marché, coûtera plus cher.

Cette conclusion n'est pas un commentaire sur les valeurs particulières ni de HTML ou de Flash. C'est plutôt le reflet d'un fait sous-jacent : Adobe absorbe une portion non-insignifiante des coûts de production pour nous autres qui utilisons Flash pour livrer des expériences riches dans un navigateur. Adobe s'assure que Flash tourne de la même manière, dans n'importe quel navigateur, sur n'importe quelle plate-forme, et que vous n'avez pas à vous en préoccuper. Ainsi, Flash représente une subvention significative de la part d'Adobe au reste d'Internet.

Il n'y a aucune société investissant de manière similaire et aussi consistante pour HTML5.  Au lieu de ça, HTML5 fonctionne juste comme les précédentes versions de HTML. C'est un standard international, et les différents fabricants de navigateurs l'implémente différemment. Chaque navigateur que  vous souhaitez supporter accroît les coûts et le temps de production, d'abord en augmentant le temps passé en tests d'assurance qualité, puis au temps de développement passé à résoudre des problèmes spécifiques à des navigateurs qui sont inévitablement découverts.

Son point de vue est évidemment biaisé, et il y tellement de choses fausses ou erronées dans cet extrait que je ne sais pas par où commencer. Mais je partage son interrogation : un développement interactif va-t-il coûter plus cher en HTML5 qu'en Flash ?

Il n'y a aucun débat sur le fait qu'aujourd'hui, faire du développement interactif en HTML5 coûte sensiblement plus cher que du développement en Flash. Dit autrement : développer sur une plate-forme jeune de quelques années coûte plus cher que développer sur une plate-forme lancée en 1996. Ce n'est surement pas pour rien que la plupart des démos interactives qui me viennent à l'esprit (20 Things I Learned, RO.ME, Cut The Rope) sont sponsorisées par les navigateurs eux-mêmes.

Mais je suis convaincu que sur le long terme, le coût du développement interactif tendra vers zéro. Le seul coût imputé au client sera à la hauteur de ses demandes spécifiques. Je suis convaincu que de la même manière que ces 10 dernières années ont vu émerger des tonnes de CMS de grande qualité permettant de créer des sites gratuitement, ces 10 prochaines années vont voir fleurir le même genre de solutions pour l'interactivité côté client. J'en reviens exactement à ce que j'expliquais en novembre dernier, dans mon article "Flash vs. HTML5".

Avec HTML5, un tout nouveau public découvre les joies et les possibilités de l'animation pour le web. HTML5 est un standard ouvert et gratuit. Avec HTML5, vous facturez à vos clients votre création plutôt que la technologie. Avec HTML5, votre code est constamment visible et accessible aux yeux de tous.

La philosophie de Flash est exclusive; elle pousse à la créativité aux dépends de la technique, à la fermeture et à la lucrativité.

La philosophie de HTML5 est inclusive; elle pousse à la créativité en équilibre avec la technique, à l'ouverture et au libre échange.

Mais évidemment, il s'agit ici de mon point de vue biaisé d'intégrateur. Alors voici maintenant quelques considérations factuelles pour l'avenir.

Plus le temps passe, et moins de plate-formes supporteront Flash. En 2011, la vente d'ordinateurs a continué de chuter, au profit quasiment unique de l'iPad.

Kaelig a publié cette semaine une très bonne conclusion pour "sortir du débat Standards vs. pragmatisme" :

Ne cédez pas au buzz du moment, ne sautez pas sur les nouveautés pour l’amour du risque. Ce n’est pas seulement une affaire de professionnels du web, vous pourriez carrément mettre votre client dans le pétrin si vous manquez de vigilance sur la pérénité des choix techniques que vous effectuez.

En choisissant Flash aujourd'hui, vous assurez à vos clients que votre travail ne fonctionnera plus sur une majorité de plate-formes utilisées dans les 2 ans à venir. Qu'on le veuille ou non, Flash Player va disparaître. Ce n'est plus qu'une question de temps. Vous n'avez pas le choix. A mon avis, la vraie question à se poser pour un professionnel n'est pas "combien ça coûte ?", mais "quand dois-je m'y mettre pour rester compétitif ?".