HTeuMeuLeu

Ce matin, j’ai lu avec stupeur cet article de Jeremy Kahn, « Je suis pour la mono-culture WebKit » :

Imaginez si Firefox passait à WebKit : ça libérerait des tonnes de temps passé à corriger des bugs de Firefox. Ne vous méprenez pas, un monde sans bugs spécifiques à certains navigateurs est une chimère. Mais standardiser sur un seul moteur de rendu ferait avancer d’un grand pas l’unification du web.

Vous ne serez pas surpris si je vous dis que Jeremy Kahn travaille chez Google. Mais je suis toujours aussi surpris de voir que l’argument en faveur d’un seul moteur de rendu trouve une audience.

Le débat n’est pas nouveau, et j’y avais longuement contribué il y a deux ans avec mon article sur le pixel perfect. Plus récemment, sur Branch, j’expliquais mon point de vue.

S’accorder sur un moteur de rendu unique, c’est comme souhaiter une dictature. Ça peut être bien si le dictateur en question est sympa et oeuvre pour le bien de tous. Mais l’Histoire nous prouve que ce n’est jamais le cas.

S’accorder sur un moteur de rendu unique, c’est choisir un bénéfice à court terme (ne plus avoir à se casser la tête avec plusieurs moteurs de rendu), au détriment de bénéfices au long terme (avoir des navigateurs toujours plus performants et plus complets).

J’aime beaucoup la conclusion de l’article de ce cher Kahn :

La compétition est bonne et nécessaire, mais pas pour tout. J’adorerais voir les fabricants de navigateurs se concentrer sur la compétition pour des fonctionnalités qui bénéficient à l’utilisateur, plutôt que sur leur propre interprétation des standards du W3C.

J’aurais tendance à dire que les navigateurs sont finis. Et même si les quelques nouveautés d’interface bien pensées apparues ces dernières années sont les bienvenues, la vraie différenciation se fait justement sur le moteur de rendu et le moteur d’exécution JavaScript. C’est là le nerf de la guerre. Je ne pense pas qu’un traducteur ou un lecteur PDF intégré soit un argument suffisant pour des vrais gens pour s’imposer la difficile tâche de changer de navigateur. Par contre, un navigateur deux fois plus rapide à afficher une page web, ça peut valoir le coup.

Opera a récemment présenté un projet de navigateur mobile sous WebKit. Mozilla en a fait de même l’année dernière en présentant Firefox Junior. Même Microsoft utilise WebKit pour Outlook 2011 sous Mac. Dans le web mobile, WebKit bénéficie déjà d’un monopole important entre Safari sous iOS et Chrome sur Android.

La perspective d’une mono-culture WebKit semble de plus en plus réaliste. Mais ce n’est vraiment pas quelque chose dont on peut se réjouir. Et encore moins quelque chose que l’on devrait souhaiter.

Vendredi, Aaron Swartz, 26 ans, s’est donné la mort. Je ne vais pas mentir : je n’avais jamais entendu son nom avant d’apprendre la nouvelle. Mais il se trouve que je connaissais malgré moi son travail. A 14 ans, il co-écrit la spécification RSS 1.0. A 19 ans, il créé la société Infogami qui sera rapidement fusionnée avec Reddit, dont il deviendra alors un des co-gérants.

Depuis juillet 2011, Aaron Swartz était poursuivi par la Court Fédérale des États-Unis pour avoir téléchargé 4 millions d’écrits académiques du JSTOR via de simples curl sur une connexion publique du MIT. Bien que les plaintes du JSTOR furent abandonnées, il fut persécuté par le procureur du Massachusetts. Il risquait 35 ans d’emprisonnement.

En lisant tous les articles qui fleurissent à son sujet, j’ai particulièrement aimé l’anecdote suivante où il explique comment il a réussi à rejoindre le groupe de travail RDF du W3C à l’âge de 14 ans.

D’abord j’ai demandé aux membres du groupe si je pouvais les rejoindre. Ils ont dit non. Mais je voulais vraiment être dans ce groupe de travail, donc j’ai essayé de trouver un autre moyen. J’ai lu les règles du W3C, qui était l’organisme de standardisation qui dirigeait ce groupe de travail. Les règles stipulaient que s’ils pouvaient rejeter n’importe quelle demande provenant d’un individu, si un organisme qui était membre officiel du W3C demandait d’ajouter quelqu’un dans un groupe de travail, ils ne pouvaient pas refuser. Alors j’ai parcouru la liste des organismes membres du W3C, j’ai trouvé celui qui me semblait le plus amical, et je leur ai demandé s’ils pouvaient me faire rejoindre le groupe de travail. Ils l’ont fait.

 

Quand j’étais petit, j’aimais bien lire les bandes dessinées Gaston Lagaffe. En particulier, j’aimais beaucoup un gag récurrent dans lequel Gaston cherche un déguisement pour le bal costumé.

Dans son emballement créatif, Gaston oublie à chaque fois le but initial de son déguisement, à savoir d’aller au bal, et s’interroge : « Oui… mais si on danse ? ».

C’est exactement ce qui m’est venu à l’esprit hier en découvrant la tablette IdeaCentre Horizon 27″ de Lenovo. En particulier, regardez à 0:49 dans la vidéo de présentation la gentille maman de famille qui transporte la tablette.

Du haut de ses vingt-sept pouces, la tablette de Lenovo pèse plus de 7,7 Kg. (En comparaison, un iPad mini pèse 308 g, un iPad 652 g, un Macbook pro 15″ 2,02 Kg, et un iMac 27″ 9,54 Kg.) Je peux imaginer l’intérêt d’un écran tactile d’ordinateur de bureau de cette taille. Je peux aussi imaginer l’intérêt d’une table tactile fixe de cette taille. Mais une tablette transportable, sérieusement ? Il semblerait que personne ne se soit dit « C’est bien… mais si on la transporte ? ».

Cette phrase de Gaston, j’y pense aussi souvent quand je reçois des maquettes pas tout à fait finies de graphistes débutants. « Il est joli ton formulaire qui rentre pile poile dans la zone de ton visuel… mais si on fait une erreur ? » Dans son emballement créatif, le graphiste avait oublié le but initial de son formulaire, à savoir valider des données saisies par l’utilisateur pour ensuite les enregistrer.

Le travail d’un graphiste web, mais aussi de tout concepteur web en général, c’est de penser. Et plus précisément de penser à tout. Il est joli ce _______, mais si _______ ?

Le mois dernier, j’ai regardé l’excellente conférence de Marcin Wichary à Fronteers 2012 intitulée « The biggest devils in the smallest details » (45 minutes, plus des questions/réponses). Marcin est développeur chez Google et travaille principalement dans l’équipe des doodles. Au cours de cette conférence, il revient sur plein de doodles réalisés ces dernières années avec des détails vraiment intéressants (et une bonne blague sur IE à la treizième minute).

Mais surtout, il présente un outil maison pour générer les animations des doodles (dont il avait déjà parlé chez Smashing Magazine) : le crushinator.

http://www.youtube.com/watch?v=EqEqGK3uRN8

Voici le doodle qu’on avait pour la fête nationale. Il y a quelques années, on voulait faire un doodle pour Rude Goldberg, mais son anniversaire était le jour de la fête nationale.  Alors on s’est dit « Et si on faisait un doodle tandem », une machine très patriotique à la Rube Goldberg ? Voilà ce que ça a donné !

C’est une jolie petite animation qui marche vraiment bien. Mais réfléchissez-y. Comment feriez-vous pour mettre ça sur la homepage de Google de façon à ce que tout le monde en profite ? Vous avez quelques options :

• Vous pouvez mettre un GIF animé. Mais les GIFs animés sont plutôt bizarres. Ils ne sont pas très jolis et vous ne savez pas vraiment ce qu’il se passe avec eux. Vous ne pouvez pas les arrêter, vous ne savez pas quand ils se chargent exactement, à chaque image, et parfois ils sont longs à charger.
• Une vidéo en HTML5, Flash ou sur Youtube. Flash et Youtube sont plutôt cools mais assez lourds et ne marcheraient pas sur iOS.
• Une vidéo en HTML5, à l’inverse, ne marcherait pas sur tous les navigateurs.
• Des images individuelles : beaucoup de latence, beaucoup de bande-passante.
• Des animations CSS3 : on pourrait imaginer recréer tout ça en CSS avec des transformations et ce genre de choses. Mais ça ne marcherait pas sur les vieux navigateurs non plus.

Donc on a inventé notre propre truc, qu’on a appelé « crushinator ». (C’est une référence à Futurama.) La façon dont ça fonctionne est essentiellement que ça regarde chaque image et la compare à la suivante. Et ça créé un sprite à partir de la différence entre ces images.

J’avais adoré le doodle en hommage à Martha Graham, et j’étais bluffé par le sprite utilisé. C’est vraiment très intéressant de désormais savoir comment ça a été fait.

480×320, 1024×768 et 1280×720. Ah ah, comme je suis drôle. Cette blague est tellement vieille qu’à l’époque on rêvait avec du 640×480 sur des gros CRT 12″.

Bref, c’est à nouveau ce moment de l’année. Plutôt que de vous parler de statistiques de navigateurs et de vous rappeler à quel point c’est une époque extraordinaire pour être développeur web, j’ai envie de partager avec vous mes trois résolutions d’intégrateur pour l’année 2013.

1. Ne plus utiliser jQuery. jQuery fait typiquement partie de ces bonnes pratiques d’hier devenues des mauvaises pratiques aujourd’hui. jQuery a été créé en 2006 pour faciliter le parcours du DOM, faire des requêtes asynchrones et faire des animations, le tout avec une même syntaxe pour différents navigateurs. Sept ans plus tard, les problématiques sont radicalement différentes. Et à l’heure des sites mobiles et du responsive design, ce n’est vraiment plus acceptable d’inclure une bibliothèque JavaScript de 80 Ko. Si je veux parcourir le DOM ou faire des requêtes asynchrones, j’utiliserais du JavaScript vanilla. Si je veux faire des animations, j’utiliserais CSS.
2. Utiliser les préfixes correctement. L’année dernière, la mauvaise utilisation et la mauvaise implémentation des préfixes navigateurs avaient fait beaucoup de bruit. Si des efforts ont été faits du côté des navigateurs et du W3C pour accélérer les processus de standardisation et rapidement abandonner les propriétés préfixées en Recommandation Candidate, j’ai le sentiment qu’il y a encore du travail à faire chez nous, les intégrateurs. En particulier, il est important de garder en tête que les propriétés CSS préfixées restent des propriétés expérimentales. En utilisant des propriétés CSS préfixées, vous signez un contrat implicite avec les visiteurs de votre site vous engageant à garantir une bonne utilisation de ces préfixes, et ce au cours du temps. Si la base consiste à utiliser les préfixes de l’ensemble des moteurs de rendu (-o-, -webkit-, -moz-, -ms, etc.), il est aussi indispensable de laisser tomber ces préfixes dès que possible. C’est déjà le cas par exemple pour les propriétés border-radius et box-shadow. Mais c’est aussi le cas de pleins d’autres propriétés (transform, transition, animation, etc.) depuis Firefox 16, Opera 12.5, IE10 et prochainement Chrome. A moins de devoir supporter des vieilleries comme Firefox 3.6 ou Safari 4, vous pouvez commencer à faire un petit ménage dans vos préfixes. En 2013, correctement utiliser les préfixes navigateurs signifie d’également s’occuper de leur suppression dès qu’ils ne sont plus nécessaires.
3. Écrire et partager. J’ai lancé ce blog en juillet 2010, mais je me suis vraiment mis à écrire régulièrement à partir d’octobre 2011. En 2012, j’ai écrit 164 articles (contre 108 en 2011 et 17 en 2010). Je n’ai vraiment aucune prétention avec ce blog. Mais ceci est mon blog personnel, et c’est vraiment chouette d’avoir un espace personnel où s’exprimer librement. C’est vraiment très formateur, que ce soit dans la simple gestion d’un site personnel, mais aussi dans l’écriture, la formalisation de mes idées, et la prise de recul sur mon métier.
   En 2013, je souhaite continuer à partager mes découvertes, mes anecdotes et mes sautes d’humeur. Mais surtout, j’espère que vous en ferez autant.
   On a la chance d’avoir une communauté web francophone assez grande. Malheureusement, celle-ci n’est pas toujours très active. On a de chouettes sites comme Le Train de 13h37, Openweb, Webdesign Friday, Les Intégristes ou encore des blogs personnels que j’aime beaucoup comme ceux de Nicolas Hoffmann, Raphaël Goetter ou Kaelig (qui malheureusement se met à écrire en anglais). Mais ces lectures francophones restent anecdotiques par rapport à la masse d’articles anglophones intéressants mis en avant chaque jour sur Reddit ou Hacker News. En décembre, j’ai lancé 24 jours de web dans le but de rassembler un peu cette communauté web francophone, et ça a plutôt bien marché. J’espère lire plus d’articles en français cette année.

Comme toutes résolutions, je vais peut-être craquer et il y aura sans doute des exceptions. Mais j’espère que celles-ci pourront vous inspirer à définir vos propres résolutions de concepteurs web, et qui sait, peut-être les partager sur votre propre blog. (Vous voyez ce que je viens de faire ?)