HTeuMeuLeu

Ce week-end, je suis tombé via Hacker News sur Adaptor, un énième slider en jQuery. J’ai été particulièrement surpris en essayant l’effet de défilement horizontal. Je vous invite à l’essayer sur la page de démo en cliquant sur le bouton « Horizontal scroll ». (MAJ : suite à un commentaire sur Hacker News, le script et sa démo ont été corrigés)

Au premier abord, j’ai eu l’impression que le défilement du slider était à l’envers. En cliquant sur la flèche de droite, j’affiche bien l’image suivante dans le slider, mais celle-ci apparaît par la gauche. Naïvement, mon petit cerveau s’attend à ce que les images soient côtes à côtes, de gauche à droite (comme le suggèrent les petits points de navigation en bas à droite), alors qu’en réalité elles sont placées en sens inverse. Pourtant, après quelques minutes passées à tester ce slider, mon cerveau a fini par s’habituer et à s’adapter. En cliquant sur la flèche de droite, je ne m’attends alors plus à voir l’image de droite, mais je m’attends à faire défiler l’ensemble du slider vers la droite. Et une fois que j’ai ce modèle mental en tête, je n’ai plus de problème à utiliser ce slider, et j’ai totalement oublié ma première intuition.

Ce n’est pas la première fois que je tombe sur un slider comme celui-ci. Ça arrive même assez souvent. Le premier qui me vient en tête, c’est celui d’iTunes. Je ne vais pas souvent dans iTunes, mais à chaque fois que j’y vais, je mets quelques secondes avant de comprendre le fonctionnement de ce slider.

Initialement, je m’attends à ce qu’en cliquant sur la flèche en bas à droite, j’affiche la vignette suivante sur la droite. Je m’attends alors à un défilement des vignettes de droite vers le haut. Or, c’est l’inverse qui se produit. En réalité, les vignettes vont défiler vers le bas, et c’est la vignette la plus en bas qui va prendre la place de la vignette principale. Mais comme dans le premier exemple, une fois que j’ai joué un peu avec ce slider, son fonctionnement me semble tout à fait correct, et mon premier modèle mental initial incorrect.

Ces problèmes de sliders m’ont alors rappelé un vieil article sur les interfaces utilisateurs qui traitait du problème des boutons d’ascenseurs :

Imaginez la situation suivante. Vous êtes au 3ème étage de cet immeuble et vous souhaitez vous rendre au 10ème. L’ascenseur est au 5ème étage et il y a un indicateur qui affiche où il se trouve. Sur quel bouton appuyez vous ?

La plupart des gens diront probablement « appuyez en haut », puisqu’ils veulent aller en haut. Il n’y a pas si longtemps j’ai vu quelqu’un faire l’inverse, et je l’ai interrogé à propos de son comportement. Il m’a dit : « et bien l’ascenseur est au 5ème, et je suis au 3ème, donc je veux qu’il descende vers moi ».

Comme pour nos sliders, sur le papier, les deux comportements semblent tout à fait valables. Mais tout est une question de point de vue. Quand je clique sur une flèche d’un slider, ou sur le bouton d’un ascenseur, est-ce que je dois indiquer l’action que moi je veux effectuer (comme afficher l’image suivante, ou me rendre à un étage supérieur) ? Ou est-ce que je dois indiquer l’action que je veux faire faire à l’appareil que je manipule (comme faire défiler le slider vers la droite, ou faire descendre l’ascenseur jusqu’à moi) ?

Si dans le cas de l’ascenseur, on devrait simplement trouver un unique bouton d’appel, je pense qu’une interface informatique doit se mettre à la place de l’utilisateur, et non l’inverse.

La semaine dernière, le WHATWG a annoncé discrètement son intention de dissocier officiellement ses spécifications HTML de celles du W3C. Si l’annonce a été plutôt bien relayée par la presse anglophone (comme chez TheVerge ou TechCrunch), j’ai l’impression qu’en France elle a été mal comprise, déformée et sensationnalisée (comme chez PC Inpact, Le Journal Du Net, et surtout chez Numerama). Voici ma modeste contribution d’intégrateur revenant sur ce qui a été annoncé, et sur ce qui pourrait changer dans le petit monde des standards du web.

Mais pour commencer, il faut bien comprendre ce que sont le W3C et le WHATWG.

Le W3C et le WHATWG

Le W3C est un organisme de normalisation, créé en 1994 par Tim Berners-Lee. Son but est de définir et promouvoir des normes libres et ouvertes pour le web. Le W3C s’occupe de standards tels que HTML, CSS, SVG, WOFF, XML, XSLT, HTTP. Administrativement, le W3C est une « institution hébergée » dirigée conjointement par le MIT, l’ERCIM et la Keio University. Le W3C est composé d’une équipe de 62 personnes à temps plein, et d’environ 350 membres participants au total. Le W3C est financé par les inscriptions de ses membres (entre 1950€ et 68000€ pour la France), par des fonds de recherches privés ou publics, et par des dons individuels.

Le WHATWG est un groupe communautaire en ligne, créé en 2004 par des membres d’Apple, Mozilla et Opera après un workshop du W3C, lors duquel ils ont relevé leur inquiétude face au désintérêt du W3C pour HTML par rapport à XHTML. Le but du WHATWG est de définir et faire évoluer les spécifications HTML, et certaines APIs intrinsèques (Web Storage, Web Workers, Web Sockets, …). Administrativement, le WHATWG n’a pas d’existence, c’est simplement une communauté sur le web. Le WHATWG est dirigé par un petit comité, le nombre de membres est illimité et la participation est gratuite.

Le principal intérêt du WHATWG, c’est de regrouper des développeurs web anonymes et des fabricants de navigateurs également membres du W3C. La volonté du WHATWG est de permettre une pratique beaucoup plus pragmatique des standards, là où le W3C a des processus de standardisations très administratifs et très longs. A titre d’exemple, les spécifications de CSS2.1, dont le premier brouillon a été publié en août 2002, sont devenues une Recommandation W3C seulement le 7 juin 2011. Il y a quelques années, le WHATWG estimait qu’à ce rythme, HTML5 deviendrait une Recommandation W3C en 2022. Le W3C a aujourd’hui comme objectif de faire de HTML5 un standard en 2014.

Pour bien comprendre la place du W3C sur le web aujourd’hui, j’aime bien faire la comparaison entre le W3C et l’Académie Française. L’Académie Française est l’institution qui s’occupe de normaliser et perfectionner la langue française. Pour formaliser ses avancées, l’Académie Française publie un dictionnaire, une à deux fois par siècle. Actuellement, on en est à la 9ème édition (mais seulement jusque la lettre Q). Le travail de l’Académie Française est avant tout un travail normatif, qui dixit Wikipédia « cherche à préserver en l’état la langue française littéraire, telle qu’elle devrait être écrite ». A l’opposé, des sociétés privées publient des dictionnaires annuellement, comme Le Petit Larousse ou le Petit Robert, « qui visent à décrire l’état de la langue française telle qu’elle est parlée aujourd’hui ». Ça a permis de voir arriver de nouveaux mots dans le Petit Larousse 2012, comme alien, jouabilité, ou abracadabrantesque. Mais ça ne signifie pas que ces mots n’existaient pas auparavant. Et surtout, peu importe le travail de l’Académie Française, ça n’empêche pas les gens de parler « comme c’est qu’ils veulent » (je sais de quoi je parle, j’habite dans le Nord). C’est un peu la même chose avec le W3C : les développeurs web et fabricants de navigateurs restent libres de tout néologisme.

HTML, HTML5 et HTML.next

Le 19 juillet dernier, Ian Hickson (un ancien de chez Netscape et Opera, actuellement chez Google, et auteur des spécifications HTML au sein du W3C et du WHATWG) annonçait sur une mailing list du WHATWG :

Il y a quelques années (vers 2007), nous avons commencé à travailler avec le W3C sur ce nous appelions officieusement « HTML5 », et officiellement « Web Applications 1.0 ». Nous avons renommé la spécification en « HTML5 », et le W3C a commencé la publication d’une copie en même temps. Peu de temps après, l’équipe en charge de ces essais au sein du W3C a décidé de séparer leur version des spécifications en sous-spécifications (ex : séparer l’API 2D canvas, les événements serveurs, postMessage, etc.), et pendant un temps nous avons essayé de reproduire cela de notre côté au WHATWG. Le résultat a été l’augmentation de la confusion des versions de ces spécifications, alors nous avons fini par revenir à une seule spécification du côté du WHATWG qui contient tout ce sur quoi nous travaillons, que nous appelons désormais « HTML Living Standard ». Au fil des années, ce document et les documents du côté du W3C ont doucement bifurqués, comme documenté en haut des spécifications du WHATWG.

Plus récemment, les objectifs du W3C et du WHATWG sur le front HTML ont divergé également. Les efforts du WHATWG se sont concentrés sur le développement de la description canonique de HTML et des technologies associées, ce qui inclut la correction des bugs dès qu’on les trouve, l’ajout de nouvelles fonctionnalités dès qu’elles deviennent nécessaires et viables, et plus généralement le suivi des implémentations. Les efforts du W3C, pendant ce temps, sont maintenant concentrés sur la création d’un instantané développé selon le vénérable processus du W3C. Cela a poussé les présidents du groupe de travail HTML du W3C et moi même à décider de diviser le travail en deux, avec une personne responsable de l’édition des spécifications de HTML5, canvas et des microdata pour le W3C différente de celle qui édite les spécifications du WHATWG (moi).

En réalité, deux versions de HTML5 cohabitent déjà depuis plusieurs années. Comme le précise Ian Hickson, les différences sont particulièrement bien détaillées dans l’entête des spécifications HTML du WHATWG. A titre d’exemple, le W3C tolère l’utilisation de <table> pour faire de la mise en page (en utilisant l’attribut role="presentation"), alors que le WHATWG l’interdit strictement. Autre exemple : le WHATWG a introduit un nouvel attribut download, pour l’instant totalement ignoré par le W3C, mais déjà implémenté dans Chrome.

L’objectif de Ian Hickson, et du WHATWG, est donc désormais de faire de HTML un standard vivant, en constante évolution, et adapté au rythme de mise à jour des navigateurs comme Chrome et Firefox. Cela peut sembler nouveau et effrayant, mais comme le précise Ian Hickson dans un message sur Google+ :

Notez que nous savons que ce système marche. HTML a été développé en modèle de « standard vivant » (appelé « working draft » et « editor’s draft » par le W3C) depuis maintenant 7 ans et demi. Au cours de cette période, l’intéropérabilité sur le web est devenue incroyablement meilleure qu’elle ne l’a jamais été sur l’ancien système « instantané ».

Une autre crainte ressentie dans certains articles ou commentaires, serait que cette nouvelle spécification vienne remettre en cause des spécifications validées par le W3C et déjà implémentées par les navigateurs. Là encore, Hickson se veut rassurant :

Avec un standard vivant, on ne peut pas changer des choses arbitrairement. Les seuls changements possibles sont l’ajout de nouvelles fonctionnalités, le changement de fonctionnalités pas encore implémentées ou qui n’ont eu qu’une implémentation expérimentale, et des changements pour amener la spécification encore plus en accord avec ce qui est nécessaire pour une communication infaillible, c’est à dire la correction de bugs dans la spécification.

Dans la pratique, je pense qu’il n’y a pas grand chose à craindre sur l’état des spécifications de HTML5 telles qu’elles existent aujourd’hui. Par contre, j’ai quand même quelques réserves sur ce qui arrivera après : HTML.next (« l’après HTML5 » dixit le W3C). Dans le meilleur scénario, le W3C continuera de s’inspirer des spécifications établies par le WHATWG, et les navigateurs pourront implémenter la version de leur choix, selon leur rythme de mise à jour.

Dans le pire des scénarios, les spécifications HTML du W3C et du WHATWG finissent par totalement différer dans quelques années, et les navigateurs choisissent d’implémenter seulement une version. En sachant que le WHATWG ne compte aujourd’hui aucun membre de chez Microsoft, ce ne serait pas totalement improbable de voir une version d’Internet Explorer supporter uniquement les spécifications HTML du W3C.

Mais pour l’heure, ces deux scénarios ne sont que des suppositions, et il ne reste donc qu’à suivre l’adage habituel : wait and see.

Après un premier et un deuxième trimestre exceptionnels, Apple a présenté hier ses résultats pour le troisième trimestre 2012.

La société a publié un chiffre d’affaires pour le trimestre de 35 milliards de dollars et un bénéfice de 8,8 milliards de dollars. […]

La société a vendu 26 millions d’iPhones au cours du trimestre, représentant une hausse de 28% par rapport au même trimestre l’année précédente. Apple a vendu 17 millions d’iPad au cours du trimestre, soit une hausse de 84% par rapport au même trimestre l’année précédente. La société a vendu 4 millions de Mac au cours du trimestre, soit une hausse de 2% par rapport au même trimestre l’année précédente. Apple a vendu 6,8 millions d’iPod, soit une baisse de 2% par rapport au même trimestre l’année précédente.

Des résultats en baisse par rapport aux deux précédents trimestres, mais toujours en hausse par rapport aux années précédentes. Quelques chiffres en vrac, annoncés au cours de ces 6 derniers mois :

• Apple écoule la totalité de son inventaire en 5 jours, là où il en faut 45 pour une société typique de production, 21 pour Samsung, et 10 pour Dell. (source)
• Chaque seconde, il se vend plus d’iPhone qu’il n’y a de bébés qui naissent dans le monde (source)
• Apple a vendu ce trimestre 1,3 millions d’Apple TV. Même si la comparaison n’est pas tout à fait pertinente, c’est plus que ce qu’a vendu Microsoft de Xbox ce trimestre. (source)
• Ces 3 derniers mois, Apple a fait 97 777 777$ de bénéfices, chaque jour. (via)

Encore une fois, que vous aimiez ou détestiez Apple, ces chiffres sont hallucinants. Je racontais il y a quelques semaines que Google est le nouveau Microsoft. Apple est là où aucune autre société informatique n’a jamais été.

En début d’année, kangax mesurait la performance des propriétés CSS3 (box-shadow, border-radius, transform, …). Résultat : ces propriétés sont gourmandes en temps de calcul. Cependant, je suis convaincu qu’en comparant tous les critères de qualité d’une intégration, l’utilisation de ces propriétés CSS3 reste une meilleure solution que l’utilisation d’images, de JavaScript ou de Flash.

Parce que sur le web, en intégration, tout a un coût. Je ne parle pas d’argent, mais de l’impact sur le poids, le temps de chargement, le temps de rendu, l’interopérabilité, et la facilité de maintenance d’une page web. La moindre ligne de code que vous ajoutez a un coût. Le moindre effet visuel a un coût. La moindre fonctionnalité a un coût.

Au fil du temps, j’ai fini par me construire le modèle mental suivant.

C’est une estimation personnelle du coût de l’utilisation de CSS3, d’images, de JavaScript ou de Flash. C’est une estimation allant de 0 à n, sans unité, valable quasiment aussi bien en Ko de poids de téléchargement, en millisecondes de temps de rendu de page, ou en difficulté de maintenance. Le premier échelon, représente le code HTML et CSS le plus petit possible pour représenter une page avec toutes ses fonctionnalités. La répartition du coût d’utilisation de CSS3, d’images ou de JavaScript peut varier selon les cas, mais restera la plupart du temps dans cet ordre.

Prenons un exemple : vous devez utiliser une police non web. Vous avez le choix. Vous pouvez utiliser des images, mais vous réduirez considérablement la maintenabilité de votre site, nécessitant une retouche d’image pour la moindre retouche de texte. Vous pouvez utiliser les déclarations font-face de CSS3, mais qui imposent d’emblée un lourd surpoids et un énorme surcoût de rendu. Vous pouvez utiliser des librairies JavaScript, comme Cufón, mais vous ne rajoutez qu’une couche supplémentaire côté client très coûteuse. Et dans le pire des cas, vous pouvez utiliser une solution en Flash, comme sIFR. Dans cet exemple, la répartition de CSS3, des images et de JavaScript se ferait clairement dans la zone orange/rouge du modèle ci-dessus. Quelque soit la technologie utilisée, le coût de l’utilisation d’une police non web est très important. Mais CSS3 reste la moins pire des solutions.

Autre exemple : vous devez faire des bords arrondis. Vous pouvez utiliser 1 ligne de CSS3. Cette ligne sera relativement lourde à exécuter par le navigateur, mais rapide à télécharger et facile à maintenir. Si vous devez supporter des navigateurs plus anciens, vous pouvez ajouter quelques balises supplémentaires puis utiliser des images de fond pour chaque coin. Même en utilisant des sprites et en simplifiant au mieux votre code, vous alourdissez quand même votre page HTML et le nombre de requêtes pour faire ça. Vous pouvez alors utiliser un fichier JavaScript qui exécutera des bords arrondis uniquement pour les navigateurs nécessiteux (comme border-radius.htc). Mais en faisant cela, vous alourdissez de manière considérable le poids et le temps de rendu de votre page.

Si les intégrateurs ont parfois l’air de rechigner à intégrer certains éléments graphiques (comme une liste déroulante personnalisée), ce n’est pas probablement par fainéantise, mais plus par conscience du coût engendré sur la page web.

Si les intégrateurs sont enthousiastes de l’arrivée de CSS3, ce n’est pas par esprit de revanche, mais parce que les propriétés CSS3 diminuent considérablement le coût des choses. Mais elles ne font que le diminuer.

Que vous soyez chef de projet, graphiste, ou développeur, il est impératif de garder toujours en tête que quoi que vous fassiez, ça aura un coût sur le web. Si de plus en plus de sites adoptent un design minimaliste, ce n’est pas forcément par style, mais bien parce que sur le web, c’est une nécessité.

L’excellent Jeff Atwood (de Stack Overflow) a rassemblé sur son blog quelques exemples de jargon de développeurs, ces expressions inventées qui collent parfaitement à une situation souvent rencontrée en développement. J’avais déjà twitté un article basé sur le même sujet il y a 2 ans, et j’aime bien découvrir de nouvelles expressions de ce type.

Voici mes cinq préférées.

1) Les conditions de Yoda

Utiliser if(constant == variable) au lieu de if(variable == constant), comme par exemple if(4 == foo). C’est comme dire « si bleu est le ciel » ou « si grand est le monsieur ».

2) Les accolades égyptiennes

Désignent des accolades écrites avec l’accolade ouvrante sur la même ligne que le bloc d’instruction, comme ceci :
if (a == b) {
alert("hello");
}


3) Bugfoot

Un bug qu’une seule personne a vu, et qui n’a jamais été revu depuis.

4) Moustache

Vu chez apgwoz, la moustache est tout simplement un petit nom pour désigner une accolade.

5) Bébé ours, Maman ours et Papa ours

Vu chez CSS-Tricks, c’est une autre façon de nommer les versions responsives d’un site.

// Papa ours
@media (max-width: 1600px) { }
// Maman ours
@media (max-width: 1250px) { }
// Bébé ours
@media (max-width: 650px) { }