Quels sont les « entrants » nécessaires pour lancer un projet front-end ?

Derrière cette simple question, il s’agit de faciliter le travail des chefs de projets, mais aussi de tous les corps de métiers qui sont amenés à travailler avec nous autres intégrateurs.

Après avoir réuni quelques éléments de réponse personnels, j’ai posé cette question sur Twitter afin d’obtenir un regard extérieur (encore merci aux nombreux participants). J’ai dû faire des choix, pour en limiter la taille et aller à ce qui me semble essentiel ; mais même si cette checklist n’est pas parfaite, vous avez là une base de travail que j’espère néanmoins très complète.

Notre métier est fait de choix techniques : il nous faut des contextes précis pour y apporter des réponses adaptées. Cette liste permet de mieux les définir.

Bloquant

Informations fournies par le chef de projet

Contexte projets précis. (Qui est le client ? Y a-t-il un site existant ? Quels seront les intervenants sur le projet ? Quel est le budget ? Quelle cible ? Quelle durée de développement ? Etc.)

C’est important pour éviter de faire de la sur-qualité, pour comprendre les enjeux, pour adapter les contraintes ou pour se sentir impliqué…

Informations fournies par la partie design

Maquettes graphiques validées. (Avec éventuellement des prototypes et/ou des wireframes.)

Les maquettes graphiques permettent de se projeter avant de lancer les phases plus techniques de réalisation. C’est une manière de simuler le résultat final sans engager tout le processus.
Si les maquettes ne sont pas validées, le processus sera déjà engagé et les modifications techniques se révèleront plus lourdes.

Sources des polices non web utilisées.

Les polices sont parfois payantes et doivent également être testées avant de les adopter. Elles sont fournies normalement pour un usage « web » clefs en main.
Si ce n’est pas le cas, il faudra se pencher sur les problématiques de licence et de conversion, ce qui demande plus de temps et de nombreux aller-retours.

Animations complexes ? Préciser les déroulements et les timings.

Les animations complexes demandent bien souvent une structure et un code très spécifiques. Ainsi, il faut définir très tôt leurs comportements car il sera très difficile d’en changer en cours de route.

Liste des formats et ratios des images contribuées.

Les images contribuées ou issues d’une base de donnée existante seront plus difficilement déclinables en différents formats, et encore moins en différents ratios. Il est important d’identifier quels seront les formats courants pour faciliter le travail de développement en aval et s’assurer de la bonne homogénéité de l’ensemble.

Planche de composants graphique avec états survolés, activés, désactivés ; palette de couleurs…

Même si les maquettes sont statiques dans un premier temps et aident le client à se projeter, elles servent ensuite de référence pour les intégrateurs. De nombreux états et comportements doivent alors être définis précisément pour bien s’entendre sur le résultat attendu.

Informations fournies par le client

Cible navigateurs. (Bureau, tablettes et mobiles. Indiquer s’il n’est pas possible de mettre en place une dégradation élégante et une amélioration progressive.)

Les choix techniques associés à l’intégration des maquettes se feront en fonction du parc navigateur défini. Plus ce parc est moderne, plus des techniques avancées pourront être mises en place, au profit d’une bonne maintenabilité et de meilleures performances notamment.

Niveau d’accessibilité demandé ? (En précisant si ça entre dans le cadre d’une labellisation.)

Bien que les bonnes pratiques du métier soient généralement appliquées, une contrainte forte en accessibilité changera l’approche technique des choses, il est important de le prévoir (avant même la partie design, cette contrainte va impacter tout les intervenants du projet).

Multilingue ? (En précisant s’il y a du RTL ou des langues asiatiques le cas échéant.)

Là encore, bien qu’il soit d’usage de toujours anticiper sur la longueur des contenus, il sera intéressant d’y porter une attention particulière sur les sites multilingue. Dans le cadre des intégrations RTL ou dans des langues asiatiques, de nouvelles contraintes viennent s’ajouter sur la conception ; mieux vaut anticiper les choses.
Quelle méthode de positionnement préférer quand la maquette doit pouvoir s’inverser verticalement, ou quelles polices utiliser pour les langues asiatiques ?

HiDPI ?

Intégrer pour des écrans à haute densité de pixels demande des sources adaptées (soit des maquettes entières, soit des planches de composants). Il faut également faire des choix entre images matricielles et images vectorielles. Les techniques employées seront ensuite très différentes.

RWD ? (Indiquer si le site sera fluide et/ou s’il y a des paliers.)

Évidement, un travail plus conséquent est à prévoir quand le site doit s’adapter à une grande variété de tailles d‘écrans.
D’un point de vue technique, penser une interface en fluide ou avec des paliers pourra complètement changer l’approche technique. Il est préférable d’avoir cette information dès le départ.

Version imprimée à prévoir ?

Cette partie peut impacter légèrement les plannings et est pourtant souvent oubliée. Les difficultés techniques associées imposent parfois de bien échanger sur le sujet si la demande est précise.

Informations fournies par le client ou la partie développement

From scratch ? (Ou sinon préciser le contexte de l’existant.)

Il sera toujours plus facile de partir sur des bases saines. Hériter d’un existant demande de bien le définir pour mieux l’appréhender.

Contraintes de production ? (Par exemple des bibliothèques imposées, des plugins ou une architecture particulière…)

Il peut arriver que des clients imposent l’utilisation d’outils spécifiques. Il faudra alors maîtriser cette contrainte supplémentaire et sans doute adapter ses processus en fonction.

Contraintes projet spécifiques ? (Par exemple les performances…)

Définir un (ou des) axe(s) de travail permettra de savoir où porter son attention et à être en phase avec les attentes du client.

Informations fournies par la partie développement

Contraintes en développement ? (Par exemple un CMS qui demande du code spécifique, un framework… Fournir les templates adaptés si besoin.)

Il n’est pas toujours possible pendant la phase de développement d’adapter certaines structures imposées par les outils. Aussi, si cela est possible, il est intéressant de communiquer la contrainte aux intégrateurs, qui tacheront alors de contourner le problème différemment.

Format d’échange des données avec les développeurs le cas échéant.

Il sera nécessaire de bien s’entendre sur les formats de données échangées avec les développeurs, pour là encore gagner du temps et éviter des incompréhensions.

Informations fournies par le client ou la partie SEO

Contraintes SEO ? (Par exemple la présence d’un sitemap ou d’une hiérarchisation particulière de l’information, mise en place de microformats ou microdata…)

Il arrive que des contraintes SEO ne soient pas en adéquation avec les bonnes pratiques du métier. Il faut pouvoir l’anticiper pour trouver un compromis, ou simplement ne pas oublier de coder la demande.

Utile

Informations fournies par la partie design

Grille verticale et/ou horizontale.

Intégrer avec des grilles permet d’assurer un meilleur respect du design, tout en facilitant l’étape d’intégration.
Les grilles permettent aussi d’assurer facilement une cohérence graphique tout au long de la vie du projet.

Échelles typographiques.

Les échelles typographiques peuvent être automatisées au niveau code, cette donnée doit être partagée pour qu’elle soit reprise.

Informations fournies par le client ou par la partie design

Contenus types.

Les véritables contenus permettent de mieux appréhender les comportements des maquettes. Il est aussi plus facile d’en contrôler la bonne lisibilité et également d’y apporter les détails sémantiques et micro-typographiques nécessaires.

Informations fournies par le client

Statistiques de navigation du site existant s’il en existe.

Avec ses statistiques, le parc navigateur défini plus haut peut être ajusté plus finement. Les statistiques apportent également un axe supplémentaire sur les questions de contexte projet.

Points d’attention

Informations fournies par la partie design

• Design des messages d’erreurs sur les interactions (formulaires, AJAX…)
• Design des pages d’erreurs. (Erreur 404…)
• Design des e-mails éventuels ? (Avec des contraintes et des besoins dédiés.)
• Design de la favicon et de ses variantes mobiles.
• Design pour les chargements dynamiques (les loaders).
• Design du message relatif aux cookies.
• Design de la page mentions légales si nécessaire.

Ces points sont très souvent oubliés lors de la phase de design. Pourtant ils sont presque toujours nécessaires, et mènent inévitablement à un nouvelle itération.

À vous

Peut-être serait-il intéressant de voir cette procédure copiée à d’autres corps de métiers ? Peut-être qu’il s’agit là d’un travers au travail en silos ? Peut-être qu’il manque quelque chose d’essentiel à cette liste ?

Je serais très heureux de lire vos commentaires.

• Cette cheklist est également disponible sur Trello.
• Et également au format markdown.

Via le biais des plugins, tout le monde a pu commencer à faire des effets « wahou » en deux secondes et a pu commencé à vouloir écrire ses propres plugins… Rendons à César ce qui est à César et remercions jQuery pour avoir apporté une idée différente du framework javascript. Dans une discussion future, je me ferai peut-être moins respectueux en évoquant les différents maux que cette librairie a pu apporter.

Rapidité < Qualité

Ce qui reste très agaçant, surtout lorsqu’on commence à prendre un peu de niveau dans son métier, c’est quand un chef de projet vous pose cette question: « pourquoi tu n’as pas utilisé un plugin tout fait à la place ? »; alors que vous auriez bien aimé tout de même avoir la chance de pouvoir démontrer que vous pouviez faire mieux et surtout : plus adapté au projet.
Qui ne s’est jamais arraché les cheveux à faire rentrer un plugin dans un projet en bidouillant l’impossible, ajoutant des options dans l’objet d’options même si ce n’était pas vraiment le meilleur endroit…

Mais plus loin encore, est-ce là un vrai travail responsable que d’accepter l’utilisation de plugins par son équipe technique ?
Non seulement l’équipe ne risque pas de prendre du niveau et très certainement se ramollir, voir se démotiver, mais en plus, vous rendez votre travail dépendant de ce qui se passe ailleurs, chez les autres… dépendant donc de la veille « plugin ».
C’est un peu comme à l’époque du designers que les intégrateurs bridaient afin de pouvoir avoir des maquettes intégrables « comme on l’a toujours fait depuis des années« , à force on obtenait presque toujours les mêmes briefs: « A gauche donc, on aura une sidebar, à droite.. le contenu et puis au milieu, un jQuery Carousel de chez bidule »; Grisant.
D’ailleurs, la version 2013 de ces pratiques sera « en haut, le header, au milieu… et bah un bon gros jQuery mansonry hein ? t’en dis quoi ? le footer ? Oh y’en a pas besoin... »

Donnez-vous une année comme cela, sans faire un peu de programmation chez vous et vous allez vite voir que vous allez très rapidement perdre vos compétences.

Petite blague à part: Vous n’avez jamais remarqué que sur stackoverflow, à chaque question en js natif il y a toujours une armée de réponses type « pourquoi tu n’utilises pas jQuery« . Et si demain vous ne deviez pas l’utilisez, pour des raisons d’optimisations ? Et si sans jQuery vous vous rendiez compte que vous ne compreniez qu’une partie de la DOM API et donc, à votre métier ? True story que cela et je vous la raconterai peut-être en temps voulu… mais autre sujet, autre journée.

L’artisanat français

Oui monsieur…

Il reste aussi le problème de l’honnêteté.
La plupart de ces plugins sont souvent réalisés à des fins de promotion personnelle, donner à ceux qui ne savent pas programmer l’occasion d’avoir un petit plus sur leur blog ou de réutiliser plusieurs fois un travail réalisé pour un client ou encore simplement démontrer un concept, une idée simple.

Il est évident qu’à un certain niveau de la hiérarchie, on ne se préoccupe pas trop de comment un projet est commencé et fini, il faut tout simplement qu’il soit fini.
Là où cela devient préoccupant, c’est lorsque le chef de projet technique ne s’en préoccupe pas non plus… et encore plus préoccupant d’entendre ce genre de propos dans la bouche d’un développeur front-end.

C’est peut-être du au fait qu’en France, au delà de 8 à 10 ans en tant que technicien, il est inconcevable de ne pas rechercher ou accepter un magnifique poste de manager et / ou de chef de projet, poste qui fera systématiquement, si on n’y prête pas garde, perdre le fil de la veille technologique (en fait plutôt les compétences que la veille).
Quelle belle récompense pour tant d’année de bon et loyaux services, mais ça, c’est déjà un sujet assez récurrent sur ce blog et je n’y reviendrais plus (promis juré !)

Cela est peut-être aussi du au fait que depuis les plugins à tout va, on sait qu’ un site Internet coutera moins cher et sera surtout réalisé plus rapidement. Par conséquent, « on » est toujours plutôt gagnant… enfin sauf pour les « techos » mais eux, ils attendent patiemment leur 8 à 10 ans pour devenir chef de projet (quoi, vous voulez pas être CP ou manager ? Mais puisqu’on vous dit que vous n’avez pas le choix !)

La seule question qui restent à mes yeux importante :  Est-ce un service que nous rendons au métier ?
Je m’étonne bien souvent de notre retard sur les points de l’UX, de l’UI et du design de site Internet mais n’est-ce pas avant tout parce que nous travaillons presque toujours à l’inspiration en regardant un peu ce qui a déjà été fait et finalement très peu en workshop ? Que les commerciaux vendent d’office des promesses impossibles à tenir ? Ou, peut-être est-ce parce qu’on s’obstine à rechercher des ninjas en PHP/MYSQL/AS3/CSS3/HTML5/JS/ASP au lieu de profils spécialisés dans l’interface utilisateur… Ou pire, que certains bloggeurs influents parlent partout de webresponsive sans exactement comprendre les implications (encore un bon sujet potentiel que celui-ci)

Be open! Oui mais…

Alors, au final, merci jQuery mais par pitié, vous, développeurs de plugins, soyez fermes avec vos licences d’utilisations et menez la vie dure aux entreprises qui utilisent vos plugins sans en avoir l’autorisation. De cette manière, nous pourrons ainsi tous combattre l’utilisation de plugins en entreprise tout en permettant aux gens de s’inspirer et/ou regarder directement le code via GitHub pour apprendre sans pour autant réutiliser… sinon dans quelques années, il faudra ajouter la ligne « google-isation de plugins » sur nos CVs.

Il serait d’ailleurs intéressant de savoir ce que pense certaines personnes de l’utilisation de leurs plugins pour des projets professionnels vendus à quelques dizaines voir centaines de milliers de brouzoufs… qui se souvient encore de l’utilisation d’un blog Dotclear pour un site Internet vivant à promouvoir certaines lois que l’état était désireux de passer ? Et qui se souvient du prix à laquelle ce Dotclear avait été vendu ?

Les préprocesseurs CSS ne remplacent pas le langage CSS en lui même et le fait d’apprendre un nouveau langage qui vient se sur-ajouter n’empêche en rien de continuer l’apprentissage de CSS (il n’est d’ailleurs pas possible d’apprendre Stylus sans connaître CSS). Il est de la responsabilité de chacun de maintenir ses connaissances en la matière, la dérive étant parfaitement illustrée par l’usage de jQuery qui dans l’esprit de nombreuses personnes a remplacé le couple JavaScript/DOM à tel point que l’apprentissage de JavaScript fait actuellement un retour en force, il est effectivement primordial d’avoir des connaissances en JavaScript et comprendre le DOM pour comprendre ce que fait jQuery et pouvoir adapter son code en fonction des buts et performances à atteindre, mais ceci fera sans doute l’objet d’un autre article sur le sujet.

J’aurais pu m’en tenir à un article sur les préprocesseurs css en général, mais de nombreux blogs l’ont déjà très bien fait dans le détail (cf la partie ressources de cet article) ou faire un énième article sur Sass qui est déjà super documenté et à qui Kaelig Deloumeau-Prigent a consacré un ouvrage entier : CSS maintenables Avec Sass et Compass (que je n’ai malheureusement pas encore eu le temps de lire), ou encore Less qui a certainement été le premier à être utilisé. Je me suis attaché à regarder du côté de Stylus qui est plébiscité par de nombreuses personnes de mon entourage et qui pourtant n’a pas le même retentissement que les deux premiers, pourquoi ?

Première question : qu’est-ce qu’un préprocesseur ?

Un préprocesseur est un programme qui procède à des transformations sur un code source, avant l’étape de traduction proprement dite (compilation ou interprétation).
source Wikipedia.

Dans le cas d’un préprocesseur CSS la syntaxe simplifiée ou enrichie en entrée est analysée et compilée en un langage que nous connaissons tous et que nous utilisons au quotidien : CSS.

Par exemple ces lignes de code écrites avec un préprocesseur CSS sont analysées et transformées en langage compréhensible par le navigateur.

Input :

body
  font 12px Helvetica, Arial, sans-serif

Output :

body {
  font: 12px Helvetica, Arial, sans-serif;
}

Avant de continuer : qu’est-ce qu’est CSS et qu’est-ce que n’est pas CSS et que viennent compenser les préprocesseurs ?

CSS n’est en aucun cas un langage de programmation, le fait de ne pas pouvoir définir des variables ou des conditions limite ses possibilités d’utilisation. Il est quasiment impossible de rationaliser le code CSS sans faire de nombreuses répétitions. Les préprocesseurs viennent combler ces manques à tel point que certains n’hésitent pas à y voir l’avenir de CSS.

Comment fonctionne Stylus ?

Qui peut le moins peut le plus. La syntaxe de Stylus est simplifiée à l’extrème, elle reprend celle de Jade, le moteur de template pour Node.js : oublions les deux points, points-virgules et parenthèses, ces signes de ponctuations auront leur utilité dans Stylus comme nous le verrons par la suite mais pas celle à laquelle les destine CSS initialement.

Il est ainsi possible avec Stylus d’écrire la propriété CSS suivante :

De cette façon,

body {
  font: 12px Helvetica, Arial, sans-serif;
}

ou de cette façon,

body
  font: 12px Helvetica, Arial, sans-serif;

ou encore de celle-là.

body
  font 12px Helvetica, Arial, sans-serif

Ce qui veut dire que Stylus accepte également l’écriture de CSS en version native.

Point important : l’indentation par tabulation rappelle la syntaxe de Python, et c’est là tout la rigueur de ce langage, selon que vous indenterez d’une façon ou d’une autre l’interprétation en sera complètement différente. Une habitude qui se prend très vite étant données les possibilités offertes.

Pour paraphraser Yves Bonnefoy, je dirais : pour comprendre Stylus installons Stylus.

Etape 1 : installer Nodejs
Etape 2 : installer Stylus en ligne de commande

npm install -g stylus

C’est fait ? Parfait, nous allons pouvoir passer à la pratique.

Vous créez votre répertoire comme d’habitude : fichier HTML, répertoire pour les images, etc. mais à la place de votre fichier.css, vous créez un fichier .styl, c’est ce fichier qui sera analysé par Stylus pour sa transformation au format CSS.

Il suffit juste de lancer Node et Stylus avec l’option « watch » sur le répertoire contenant votre fichier ou sur le fichier en lui même. Le fichier sera compilé à la volée.

stylus -w monrépertoire/monfichier.styl

Très pratique, vous travaillez sur le fichier .styl et vous liez à votre fichier HTML le fichier .css, ainsi vous pouvez voir directement sur votre page les modifications que vous apportez à votre fichier stylus, simple, non ?

Plus d’infos sur ce point particulier ? C’est indiqué là :

1. Les sélecteurs

Nous avons vu dans les quelques exemples donnés plus haut qu’il était optionnel d’indiquer les accolades, les parenthèses, les deux points voire les points virgules à condition d’indenter le code correctement. Il est également possible de ne pas indiquer les virgules à condition de passer à la ligne. Une fois ces quelques règles intégrées, il est très simple de commencer à coder comme vous le feriez naturellement avec CSS.

Pour se référer au sélecteur parent dans le même bloc de CSS, il suffit d’ajouter & devant la propriété définie.

body
  section div a
    color red
  &
    color blue

Un exemple plus parlant ?

body
  section div a
    color red
    &:hover
       color blue

aura pour résultat en sortie

body section div a {
  color: #f00;
}
body section div a:hover {
  color: #00f;
}

2. Les variables

Voilà certainement ce qui manquait le plus aux CSS pour assurer une maintenance facile des feuilles de style. Avec stylus les variables peuvent être préfixées par un $ ou pas. Les noms des propriétés peuvent être utilisées, on peut donc définir les valeurs pour la propriété font en utilisant une variable font, mais par soucis de clarté, il est conseillé de nommer les variables de manières à les identifier rapidement et sans ambiguité.

par exemple

fontarial14=14px Arial, sans-serif;

ou de cette manière

$fontarial14=14px Arial, sans-serif;

Ensuite cette variable sera utilisée partout où on voudra définir la propriété définie.

body
  font fontarial14

A noter que si vous utilisez le signe $ en préfixe du nom de votre variable, il faudra appeler la variable telle qu’elle a été définie (avec le $ donc).

body
  font $fontarial14

Mais le plus intéressant est de pouvoir utiliser la valeur d’une propriété définie dans un bloc CSS pour l’assigner à une autre propriété en ajoutant simplement le préfixe @ devant :

#logo
   position: absolute
   top: 50%
   left: 50%
   width: 150px
   height: 80px
   margin-left: -(@width / 2)
   margin-top: -(@height / 2)

Dans le cas où la propriété est définie plusieurs fois dans un même bloc, la dernière valeur (en remontant à l’intérieur du bloc CSS) sera prise en compte, dans l’exemple ci-dessous @color aura la valeur #00f (blue).

body
  color: red
  p
     color: blue
     a
	background-color: @color

Voilà, vous en savez assez pour pouvoir commencer et intégrer Stylus dans vos outils de travail, je vous encourage à prendre connaissance de la doc officielle de Stylus qui est claire et très bien documentée. Vous me pardonnerez, j’espère, les nombreux emprunts que j’ai pu y faire mais il me paraissait important de poser les bases avant de pouvoir aborder d’autres points plus précis à l’avenir. Les prochains articles consacrés à Stylus seront consacrés à des cas pratiques ou à des aspects plus obscurs du préprocesseur.

Ressources :

• Le manifeste du CSS pur et dur
• Clarence le poney
• Sass And LESS: An Introduction To CSS Preprocessors
• 8 CSS preprocessors to speed up development time
• Deep Dive Into CSS Preprocessors
• Csspreprocessor – Language Design
• How to Write a CSS Preprocessor Using Node.js?
• Sass vs. LESS vs. Stylus: Preprocessor Shootout
• Using CSS preprocessors effectively
• Sass vs. Stylus: Who Wins the Minimal Syntax Battle?
• Préprocesseurs CSS
• CSS Pre-Processors: Stylus, Less & Sass

On ne peut les blamer, depuis tant d’année les intégrateurs vivent dans la honte de ne pas avoir « développeur » dans leur titre ainsi que sur leurs cartes de visite, et nos bon vieux amis développeurs de site internet orienté back-office n’ont pas manqué de nous le faire remarquer.

Enfin l’occasion se présente à nous de pouvoir prendre notre revanche sur le reste du monde.

Un peu d’histoire

Après tout, les choses changent, nous aussi (ce n’est pas sale) et comme notre ami de l’intégration française, monsieur Eric Le Bihan me l’a souvent rappelé lorsque je servais à ses côtés ainsi que sous ses ordres: il existait avant notre ère un poste de monteur HTML (une sorte de baltringue des temps modernes donc).

Par simple définition et compréhension de la langue française, on peut d’ores et déjà comprendre qu’il fut un temps où le monteur HTML se limitait à monter des squelettes HTML alors que l’intégrateur se devait d’intégrer (bien joué Sherlock) plusieurs éléments à des pages qu’il montait, et bien souvent, lorsque le développement du site était optimal, il se devait de tout intégrer sur la plateforme de développement même, reliant ainsi diverses technologies entre elles.
Car oui ne l’oublions pas: l’intégrateur est un jongleur de technologies.
Et bien souvent, il est la personne entre toutes les autres, celui qui reliera le pôle produit au pôle développement.

Bref, le monteur se contente de monter. L’intégrateur intègre (et avec intégrité qui plus est). Pas la peine d’avoir fait Normal Sup.
Certes, vous me direz que c’est le même métier mais si on y regarde de plus près, ce n’est pas exactement la même définition.

Mais à quel moment est-il précisément devenu développeur Front-end ?

Un peu de sémantique

Car pour bien comprendre un ensemble de mot, il est bon de les prendre un par un puis de les confronter.

Développeur

Celui qui conçoit, effectue l’analyse et écrit le code d’un logiciel.

Front-end

Front venant de l’anglais et signifiant « premier plan », ce premier plan étant la … BREF, « interface »

Donc, développeur Front-end signifierait « développeur d’interface » ?
« Mais c’est bien sûr. Maintenant que vous me le dites » ! »

Et là tout de suite, vous vous dites que c’est pas demain la veille que vous aller réussir à draguer avec ce titre et qu’il faudra continuer d’essuyer les bars en prétendant être « éleveur de dauphin », une profession souvent mésestimée qui aura certainement le mérite de soulever plusieurs questions lors de vos soirées mondaines.

De la différence… ou pas

Il y a bien sûr des intégrateurs qui, dans le cadre de leur travail, ont pu se rendre compte que les tâches qu’ils effectuaient depuis des années s’apparentaient à du développement d’interface.

Mais en-est-il exactement pareil pour tout le monde ?
Est-ce que tous les intégrateurs peuvent prétendre à cette appellation, cette spécialité qui, une fois définie, prend bien tout son sens, toute sa particularité ?

Et c’est là que comme tout bon petit malin je vous répondrai: ça dépend.

Et j’exemplerai le tout avec l’exemple de ces nouveaux sites fabuleux qui réagissent au scroll de notre bonne vieille molette.
Ne me dites pas que vous l’aviez raté, c’est la grosse mode depuis un an et on n’a pas fini d’en voir à la pelle de ces « parallaxes » … ou encore tous ces petits portfolios qui tendent à se comporter comme un bon vieux site en flash super bien animé, le tout en HTML5 (/TROLL) couplé à j…Query.

Si je peux me permettre: un parallax n’est pas juste un effet au scroll, mais un effet bien particulier, qui mélange plusieurs plans qui ne se déplaceraient pas à la même vitesse durant le déplacement de l’oeil (du scroll donc), créant une impression de profondeur.

Et je m’offusque qu’on parle de développement Front-end pour ces sites. Oui monsieur, car cela n’est pas du développement d’interface mais bel et bien de l’animation d’interface.

« Animateur HTML » pardi !

Oui, vous me lisez bien et je vous vois tous lever un doigt accusateur dans ma direction: BOOOOOUUUUH. Qu’à cela ne tienne, je fais fis de vos railleries.

Si nous réfléchissons bien, nous sommes tous des intégrateurs mais nous avons aussi nos spécialités, par conséquent certains deviennent développeurs d’interfaces, d’autres des développeurs javascript , d’autres s’orientent vers l’accessibilité et certains même repartent vers le design pur forts de leur expérience d’intégrateur.

Alors, pour tous les animateurs qui me liront, je vous le dis messieurs, et mesdames, : je n’ai pas la patience ni le courage nécessaire à créer ce genre de comportement donc je ne vous juge en nul point et vous salue même pour votre patience (sisi), je ne cherche qu’à rétablir un bon ordre des choses entre plusieurs spécialités qui mériteraient de devenir des titres à part entière car selon moi, l’intégrateur a encore de longs jours devant lui tant qu’il n’aura pas pris exactement conscience de ce qu’il fait et à quel degré il s’implique dans son devoir d’intégrateur et beaucoup travaillant en agence réalisent encore du (très bon même) travail d’intégrateur quand certains sont de magnifiques animateurs HTML et d’autres sont de très compétents développeurs d’interfaces.

Et on peut même le sentir, que certains ont déjà prévu ces changements, n’avons-nous pas, chez les intégristes, posté une note sur Adobe Edge ?

Soyez donc fiers de vos compétences et ne tombez pas dans le piège de mettre à jour le titre de votre C.V., respectons les spécialités de chacun et apprenons à nos chers collègues (une fois de plus) l’utilité de la bonne appellation. Au final, le seul titre que toute personne normalement constituée se doit d’obtenir dans une vie, c’est bel et bien celui de « Chevalier de l’ Internet ».

J’espère donc que beaucoup partageront mon avis, que beaucoup d’autres ne le partageront pas et viendront amener leur petite brique (ou leur grand troll) à cet édifice, cette tâche qui nous incombe: savoir définir et, enfin, professionnaliser, que dis-je, assumer nos métiers.

Mon mot de la fin

Ce n’est pas pour nous brosser dans le sens du poil mais ce qui est formidable avec nos métiers issus de « l’intégration française », c’est que pouvons être au four et au moulin puisque nous sommes constamment à mi-chemin entre les deux, essayant de faire communiquer le meunier et le boulanger, aidant à la réalisation d’un produit fini, répondant à plusieurs normes de qualité, mettant notre nez chez l’un et l’autre, amenant nos recommandations à droite et à gauche sur divers sujets tels que, et pour n’en citer que quelques-uns: la typographie, la sémantique, les bonnes pratiques et l’accessibilité.

Alors, il me vient l’idée qu’il est finalement inutile de rajouter des mots pompeux lors de notre recherche d’emploi pour se justifier de faire ce qu’on fait. Non, il n’y a pas de ninja du CSS, de samouraï du jQuery, ni d’ Intégrateur++ mais bien des intégrateurs qui se spécialisent, apprennent, testent et veillent.

Et par conséquent, nous ne sommes pas tous des développeurs d’interface, des animateurs et des intégrateurs confirmés, l’artisan en chacun de nous le sait.

Developer Toolbar

La Developer Toolbar est disponible ! Elle regroupe les outils de développement existants dans Firefox (l’inspecteur, la console Web, le débogueur), auxquels vient s’ajouter une console. Celle-ci peut assez facilement être étendue pour y ajouter de nouvelles commandes : cet outil va certainement se retrouver indispensable d’ici peu de temps.

La nouvelle barre de développement de Firefox 16

HTML

L’élément meter est supporté

Un petit rappel du rôle de cet élément :

The meter element represents a scalar measurement within a known range, or a fractional value; for example disk usage, the relevance of a query result, or the fraction of a voting population to have selected a particular candidate. This is also known as a gauge.
— The meter element — HTML5

Traduction :

L’élément meter représente une mesure scalaire à l’intérieur de limites connues, ou une valeur fractionnaire. Par exemple : le niveau d’utilisation d’un disque, la pertinence du résultat d’une requête, ou la fraction de votants ayant sélectionné un candidat. Le mot « jauge » peut également définir cet élément.

Je vous invite également à consulter la documentation de l’élément meter sur le MDN, et l’article de HTML5 Doctor. Un petit exemple :

16/30 <meter value="16" max="30" min="10"></meter>
45/50 <meter value="45" max="50" min="0"></meter>

Rendu : 16/30 (meter n’est pas supporté sur votre navigateur), 45/50 (meter n’est pas supporté sur votre navigateur).

Trois pseudo-classes CSS ont également été ajoutées pour nous permettre de styler cet élément : :-moz-meter-optimum, :-moz-meter-sub-optimum et :-moz-meter-sub-sub-optimum.

L’API HTML Microdata est supportée

Quelques liens de référence :

• Un article d’introduction à Microdata et son API sur Dev.Opera
• L’article Microdota sur HTML5 Doctor
• La spécification Microdata à destination des auteurs

Le champ <input> autorise tous les types MIME

Avant cette version, seules ces valeurs étaient disponibles :

<input type="file" accept="audio/*">
<input type="file" accept="video/*">
<input type="file" accept="image/*">

Il est maintenant possible d’être plus précis :

<input type="file" accept="audio/mpeg">
<input type="file" accept="video/*,image/*">
<input type="file" accept="image/*,.autre-extension">

Pardonnez-moi, mais je me sens obligé de rappeler qu’aucune validation dans le navigateur n’est destinée à remplacer une validation côté serveur. Ça va mieux, merci !

CSS

Adieu préfixes

Beaucoup, beaucoup de préfixes ont été supprimés. Voyez :

Les animations : animation, animation-delay, animation-direction, animation-duration, animation-iteration-count, animation-name, animation-play-state, animation-timing-function, animation-fill-mode.

Les transformations : transform-origin, transform.

Les dégradés : linear-gradient, radial-gradient, repeating-linear-gradient, repeating-radial-gradient.

La fonction calc(). Le potentiel de cette fonction CSS est énorme (documentation MDN), et une version non préfixée facilitera son utilisation. Seul Opera supporte pas calc() aujourd’hui.

Animations CSS : reverse

Il est maintenant possible d’utiliser les valeurs reverse et alternate-reverse pour la propriété animation-direction (documentation MDN).

Si vous vous souhaitez voir en quoi ces nouvelles valeurs de direction influent sur une animation CSS, je vous ai concocté une petite démonstration. Allez-donc y jeter un œil avec votre Firefox flambant neuf !

box-sizing sur les cellules de tableaux

Cette propriété, devenue récemment assez populaire (voir l’article de Paul Irish), s’applique maintenant correctement aux cellules de tableaux.

Media queries

Le type de donnée resolution (documentation MDN) permet d’utiliser une nouvelle unité, le dppx (dots per CSS pixel). Il s’agit du nombre de points (sur l’écran) par pixel CSS (virtuel).

Les unités dppx, dpi, et dpcm font maintenant référence à des valeurs CSS (virtuelles), et non plus à des valeurs physiques.

Flex Layout

Il est maintenant possible d’utiliser la valeur auto pour les propriétés min-width et min-height (voir la spécification CSS3 Flexbox : Implied Minimum Size of Flex Items).

DOM : adieu préfixes

• IndexedDB n’est plus préfixé (documentation MDN)
• L’API Battery n’est plus préfixée (documentation MDN)
• L’API Vibration n’est plus préfixée (Mozilla Hacks: Using the Vibration API)

JavaScript

Trois nouvelles méthodes ont été ajoutées sur l’objet Number : isFinite(), toInteger() et isInteger().

L’opérateur Spread

Il est maintenant possible de convertir un tableau en paramètres de fonction, à l’aide de l’opérateur spread du projet Harmony.

Évidemment, n’utilisez pas cette fonctionnalité pour l’instant pour du Web, c’est totalement incompatible avec les autres navigateurs. Mais si vous développez une commande pour la nouvelle Developer Toolbar de Firefox, il serait dommage de vous en priver !

Un exemple :

// Pour appeler cette fonction
function nousIrons(a, b, c, lieu) {
  var str = a + ', ' + b + ', ' + c + ', nous irons ' + lieu;
  return str;
}

// Avec ce tableau
var data = [1, 2, 3];

// Et ce lieu
var lieu = 'au bois';

// Avant, nous devions faire
nousIrons(data[0], data[1], data[2], lieu);

// Ou encore, avec Array.apply()
nousIrons.call(this, data.concat(lieu));

// Mais maintenant, avec la syntaxe spread
nousIrons(...data, lieu);

// Cool non ?

La conclusion ! La conclusion !

Pour cet article, j’ai essayé prendre les notes de version de Firefox et d’y ajouter, en vrac, des informations complémentaires, quelques démos, et mes réactions. J’espère que le résultat sera plus digeste qu’une simple liste : n’hésitez pas à me faire part de vos impressions dans les commentaires !

Il est même possible de styler ce texte sur la plupart des navigateurs, si l’on veut bien concéder l’utilisation de sélecteurs quelque peu pimpants :

::-webkit-input-placeholder{}
:-ms-input-placeholder{}
:-moz-placeholder{}

Le comportement est simple : un texte d’aide apparaît dans le champ de texte, lorsque celui-ci est vide. Ce libellé disparaît dès que le focus est placé dans le champ.

Cet attribut n’a pas vocation à remplacer l’élément <label>. Il s’agit d’un indice, d’une aide supplémentaire, et pas d’un intitulé :

The placeholder attribute represents a short hint (a word or short phrase) intended to aid the user with data entry. A hint could be a sample value or a brief description of the expected format. […] For a longer hint or other advisory text, the title attribute is more appropriate. The placeholder attribute should not be used as an alternative to a label.
— Common input element attributes — HTML5

Traduction (rapide) :

L’attribut placeholder représente un indice (mot ou phrase courte) dont le but est d’aider l’utilisateur à entrer ses données. Cet indice peut être une valeur d’exemple ou une brève description du format attendu. […] Pour un texte d’aide plus long, ou toute autre indication, l’attribut title sera plus approprié. L’attribut placeholder ne devrait pas être utilisé comme alternative à l’élément label.

Sur iOS et OS X (depuis 10.7), une petite variante a été introduite, qui me semble tout à fait intéressante. Le libellé reste affiché au focus, jusqu’au premier caractère tapé. Ce comportement est visible sur Firefox, Chrome et Safari (pas Opera, qui semble implémenter ses propres widgets).

L’attribut placeholder sur OS X

Je trouve ce nouveau comportement intéressant. Il permet d’afficher l’aide plus longtemps, et le risque de confondre le placeholder avec la valeur du champ est le même que sans focus, puisqu’ils sont censés être clairement distingués visuellement.

Seulement voilà : chaque projet est particulier, et une solution, même élégante, ne correspond pas toujours aux besoins du moment. Il peut arriver, par exemple, que le comportement du système ne soit pas celui qui est désiré. Nous avons tous connu ce problème n’est-ce pas ?

Prenons un champ dont le texte est centré. Regardez comme le curseur se faufile, l’air de rien, au beau milieu d’un caractère :

Placeholder centré

Mais enfin Curseur, tu fais n’importe quoi ! La solution est simple, la décision est prise : il faut revenir à l’ancien comportement. Mais il va falloir trouver une ruse, car il est hors de question de revenir à une solution basée sur l’attribut value, avec des classes pour distinguer le focus.

La solution à deux francs

Une solution pourrait être de modifier dynamiquement l’attribut placeholder au focus, à l’aide d’un script. Et pourquoi pas en CSS ? En combinant :focus et :-xx-input-placeholder, il devrait être possible de modifier la couleur du placeholder pour qu’elle corresponde à celle du fond ! Voyons cela :

input:focus::-webkit-input-placeholder { color: #fff; }
input:focus:-moz-placeholder           { color: #fff; }

Placeholder blanc

Ce comportement peut être observé avec Firefox et Safari. La couleur du curseur clignotant correspond à la couleur du champ, ici un gris foncé. Mais pour permettre une bonne lisibilité du texte, ces deux navigateurs vont faire en sorte d’inverser la couleur du texte à l’endroit où se trouve le curseur :

Placeholder blanc, agrandi

Ce qui est tout à fait indésirable dans notre cas.

La solution à trois francs

La solution est maintenant évidente, et permet également d’obtenir une meilleure portabilité, puisqu’elle ne dépend plus de la couleur du fond. Il s’agit de la couleur spéciale transparent.

input:focus::-webkit-input-placeholder { color: transparent; }
input:focus:-moz-placeholder           { color: transparent; }

Placeholder transparent

Accessibilité

Si vous avez pour habitude de traquer les problèmes d’accessibilité, cette technique devrait vous déranger un peu : rendre un texte transparent en CSS, voilà qui sonne faux. Mais n’oublions pas qu’il ne s’agit, encore une fois, que d’un placeholder, une invitation à entrer une valeur, rien d’autre. Ce n’est pas un title, et encore moins un <label>.

Le seul problème que je vois serait plutôt d’ordre ergonomique : un utilisateur d’iOS ou OS X s’attend à voir le placeholder au focus, jusqu’au premier caractère tapé.

Démonstration

Vous pouvez retrouver ces tests sur la page dédiée :

Démonstration

Cette page inaugure également un nouvel espace, code.lesintegristes.net, sur lequel nous publierons désormais nos démonstrations. Ce sous-domaine est hébergé par GitHub, et son contenu est bien entendu sous licence libre.

Avec l’arrivée de html5 et tout le cortège de nouveautés – la plupart du temps non applicables dans un environnement de production, le pauvre intégrateur doit se muer en véritable couteau suisse : en plus de maitriser html5 et css3, sans perdre de vue l’accessibilité et la compatibilité multi-navigateurs, il doit être un crack en javascript et un utilisateur averti des principales bibliothèques basées sur ce langage, il doit avoir de bonnes connaissances en design, en ergonomie, en expérience utilisateur, maitriser les technos pour le mobile et le responsive design, les préprocesseurs CSS, savoir optimiser son code pour le SEO et/ou booster les temps d’affichage d’une page web, connaitre plusieurs langages de templating, avoir de solides connaissances en PHP et des notions en administration de serveurs, n’en jetez plus la coupe est pleine ! Quel autre métier a une telle exigence envers ses professionnels et exige une telle étendue de connaissances ? L’intégrateur est-il en train de devenir le pendant du webmaster du début des années 2000 ? De deux choses l’une ou vous êtes un stakhanoviste de l’intégration et il est fort probable que vous ayez dit adieu à toute vie privée, sociale ou affective ou vos connaissances sont vouées à rester superficielles dans tous ces domaines.

Je pose donc la question de la formation. A quel moment ce processus indispensable à tout métier, et à plus forte raison à un métier dont la matière évolue très rapidement, intervient-il ? Comment est organisée cette formation ? Est-ce que parce qu’un intégrateur est souvent décrit comme une autodidacte passionné, il doit prendre ce temps de formation sur son temps libre – tout benef pour l’employeur ? Quelle est la politique des entreprises à leur égard, si dans certains cas le temps d’auto-formation et de veille est inscrit au contrat, la plupart du temps il est difficile dans le rush des projets à boucler de prendre le temps de se former convenablement. La veille se limitant à quelques articles lus en diagonale et quelques tweets échangés sur le sujet. Ce qui n’empêche pas les agences de vendre des prestations sur des technos non maitrisées et non éprouvées. la formation se fait souvent en cours de projet, selon le vieil adage c’est en forgeant qu’on devient forgeron.

Au-delà de la question de la formation, se pose la question de la valorisation des ces compétences. Quand je vois le niveau de salaire offert dans certaines annonces, je me dis qu’il y a maldonne… Soit vous voulez un junior qui débute et c’est tout ce que vous pourrez vous offrir pour le maigre salaire que vous êtes prêt à verser, soit il va falloir sortir la monnaie ! Oui on n’a pas fait tout ça pour rien ! (Pour ceux qui ne travaillent pas pour l’argent, mais pour la gloire, rien ne vous empêche de négocier vos talents à leur juste valeur et reverser une partie de vos revenus à des œuvres caritatives…). Il est bien entendu que nous parlons d’un contexte commercial et non de projets communautaires ou de bénévolat, quoique certaines entreprises commerciales proposent des postes proches du bénévolat au niveau de la rémunération…

Le besoin de reconnaissance est tel chez les intégrateurs que j’ai pu côtoyer dans ma vie professionnelle, que je suis prêt à me demander s’il n’y a pas un profil psychologique particulier pour ce métier, à ce point là c’est pathologique. Non mais vous en connaissez vous des intégrateurs qui ne râlent pas, qui ne se sentent pas incompris, ou reconnu à leur juste valeur ? A croire qu’en entreprise on s’acharne sur eux ! Alors que ces types sont des experts dans leur domaine, on continue à ignorer nombre de leurs recommandations en matière de conception d’interface ! Pire on leur mets dans les pattes des chefs de projets persuadés d’en connaitre autant si ce n’est plus qu’eux (voir l’effet Dunning Kruger)

Savez-vous que dans les pays anglo-saxons il y a des chasseurs de têtes qui sont spécialisés dans le recrutement des développeurs front-end ? Qu’il y a des annonces qui ne demande que, et seulement que, les compétences nécessaires à un développeur front-end ? Ça laisse songeur…

Quelques citations d’annonces qui m’ont amusé ou fait bondir, (qui rédige ces annonces, sérieusement ?) :

« Diplômé d’une Ecole d’Ingénieurs ou d’un Master 2, vous justifiez d’au moins deux ans d’expérience sur un poste similaire. »
http://www.meteojob.com/candidat/offres/offre-d-emploi-developpeur-h-f-ile-de-france-cdi-1701396

« Vous êtes capable d’architecturer convenablement une application web et modéliser une base de données MySQL (Merise / UML / MVC »
https://remixjobs.com/emploi/Developpement/Developpeur-web-Front-End-H-F/7302

« Vous êtes jeune et dynamique » (So 90’s & si discriminatoire…)
http://emploi.alsacreations.com/offre-512983-Developpeur-js—integrateur-web.html

« Intérêts:
• Ambiance internationale
• Structure jeune et dynamique
• Poste basé à Paris »
http://emploi.frenchweb.fr/offre-emploi/developpeur-front-end-senior-pour-une-agence-digitale/

« Nous voulons quelqu’un capable d’aller au delà des appréhensions »
http://www.jobintree.com/offre-emploi/le-crew-4355/developpeur-web-1664536

Pour le dernier, c’est vraiment du niveau senior, mais pas impossible, combien de profils correspondent ?
http://tbe.taleo.net/NA2/ats/careers/requisition.jsp?org=NURUN&cws=2&rid=1278

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.

Le print c’est en 300 dpi, et pis le web c’est en 72 dpi.

Et donc, ça c’est faux. Le Web n’est pas en 72 dpi (ou ppi ou pixels par pouce), et il n’est pas non plus en 96 dpi. Le Web n’a pas de résolution fixe, car chaque périphérique d’affichage a une densité de pixels qui lui est propre, et il n’y a pas de standard en la matière. J’y reviendrai avec quelques exemples, mais avant ça on va expliquer un peu à quoi correspondent ces fameux pixels par pouce.

Densité des pixels d’un écran: à vos calculettes!

Petit exercice pratique: nous allons calculer ensemble la densité de pixels d’un écran. Cette densité est exprimée le plus souvent en pixels par pouce (en anglais pixels per inch, abrégé ppi). On notera que l’abréviation dpi correspond à dots per inch (points par pouce) et que son utilisation pour des pixels est abusive; donc on va l’éviter, mais remplacez «ppi» par «dpi» dans votre tête si vraiment ça vous bloque.

Sur cet écran, 1 mm correspond à un peu moins de 4 pixels.
On aura un résultat différent sur d’autres écrans.

Pour notre exercice, prenons par exemple l’écran de mon iMac (insérez ici un troll de votre choix). Que sais-je à son sujet?

• Sa diagonale est de 20 pouces (à peu près, c’est probablement une valeur arrondie).
• Sa définition native est de 1680 pixels en largeur, et 1050 en hauteur.

Pour savoir quelle est la densité de pixels de mon écran, je peux diviser la longueur de la diagonale en pixels par cette même longueur en pouces, et j’obtiendrai un résultat en pixels par pouce. Je n’ai pas la longueur de la diagonale en pixels (qui est une valeur théorique bien sûr, car les pixels ne sont pas sagement alignés dans le sens de la diagonale!), mais je peux utiliser le théorème de Pythagore pour la retrouver. Attention les yeux, mathématiques de niveau classe de cinquième:

√(1680² + 1050²) ÷ 20 ≈ 99,057

Mon écran a une densité de pixels d’à peu près 99 pixels par pouce (99 ppi).

Pour être vraiment sûr de mon coup, j’ai pris un mètre et j’ai mesuré la largeur de mon écran: 43,3 cm, soit 17,05 pouces d’après Google. Comme j’ai aussi cette largeur en pixels (1680), je peux faire un calcul plus simple.

1680 ÷ 17,05 ≈ 98,534

Je sens que vous allez me dire, Bah tu vois, à peu de choses près on est bien à 96 ppi!, bande de petits malins. Mais vous allez voir que les écrans ont des résolutions très variables, et rares sont ceux qui s’approchent de 96 ou 72 ppi.

Chaque écran est différent

Les résolutions d’écran ne sont pas standardisées. On peut imaginer que les constructeurs de matériel informatique se seraient mis d’accord, genre Bon les gars, je propose qu’on fasse des écrans de Classe A à 72 ppi, des écrans de Classe B à 96 ppi, et des écrans de classe C super haute résolution de ouf à 128 ppi. Deal? Ben en fait non, chaque constructeur fait ce qui lui plait.

Ça nous donne des résultats comme ces quelques exemples (arrondis à l’unité):

• 61 ppi: écran de 21 pouces configuré en 1024×768
• 132 ppi: écran de 9,7 pouces en 1024×768
• 135 ppi: écran de 11,6 pouces en 1366×768
• 165 ppi: écran de 3,5 pouces en 480×320
• 217 ppi: écran de 4,3 pouces en 800×480
• 330 ppi: écran de 3,5 pouces en 960×640

Vous aurez peut-être reconnu, en vrac: le MacBook Air 11″, l’iPad (1 & 2), l’iPhone (premières générations), l’iPhone 4, et le HTC Evo 4G. (Les résultats sont imprécis car les diagonales d’écran en pouces données par les constructeurs sont arrondies.)

Si on se limite aux écrans d’ordinateurs classiques, en excluant les tablettes et téléphones, et en oubliant certains cas limites, on a des résolutions qui s’étalent, à la louche, entre 60 et 140 ppi. Et nous ne sommes qu’en 2011… possible que d’ici quelques années tous les écrans neufs affichent du 200 ppi et plus.

Laissez tomber les DPI, pensez en pixels

Pour du webdesign classique, ne réfléchissez pas en dpi, ça ne sert à rien. Pensez plutôt en pixels. Si un chef de projet, un client ou un graphiste commence à vous parler d’images optimisées en 72dpi, souriez benoitement.

Photoshop, toujours plus de lol.

Au fait, d’où vient cette valeur de 72 dpi? Eh bien dans les années 1990 les infographistes qui utilisaient Adobe Photoshop ou QuarkXPress devaient, pour chaque nouveau document, indiquer les dimensions du papier (en pouces en en centimètres) et la résolution d’impression (300dpi, 600dpi, etc.). Le logiciel calculait alors le nombre de pixels nécessaires pour le document ou les éléments bitmap.

Avec l’arrivée des cédéroms interactifs (woohoo!) et du Web, on a parfois gardé ces habitudes: on définissait une taille de document physique, et une résolution. Par convention, cette résolution c’était 72 ppi, pour deux raisons:

1. Une bonne partie des écrans avaient une résolution réelle proche de cette valeur.
2. En faisant semblant de croire que la résolution de l’écran est 72 ppi (quelle que soit la vraie valeur), cela permet de faire des équivalences pratiques, notamment l’équivalence 1 point typographique = 1 pixel.

En 2011, la plupart des systèmes d’exploitation et logiciels qui font des équivalences arbitraire entre unités physiques (point, centimètre, pouce…) et pixels utilisent la résolution fictive de 96 ppi. Ainsi si vous demandez à votre navigateur web un texte en 12pt, il affichera un texte de 16px. Dans l’idéal les logiciels devraient être capable de détecter la résolution réelle de l’écran, et donc d’afficher correctement des éléments dimensionnés avec des unités absolues… mais la plupart des systèmes d’exploitation ne partagent pas cette information.

Laissez tomber les pixels, pensez en… euh en quoi au juste?

On a vu que la résolution d’un écran d’ordinateur (hors périphériques mobiles) peut varier entre 60 et 150 ppi (et sans doute plus à l’avenir). Concrètement, cela veut dire que lorsque vous définissez un font-size: 16px en CSS, vous allez obtenir les tailles de texte suivantes:

• 6,8 mm à 60 ppi,
• 4,5 mm à 90 ppi,
• 3,4 mm à 120 ppi,
• 2,7 mm à 150 ppi.

On aura donc un texte énorme sur certains écrans, minuscules sur d’autres, optimal sur certains, un peu trop petit pour une lecture confortable sur d’autres, ou encore un peu trop grand pour conserver le caractère voulu du design, etc. Si vous jonglez régulièrement entre un grand écran de bureau confortable et un portable de 12 ou 13 pouces récent, vous avez sans doute remarqué ces différences dans les tailles de texte.

C’est un problème qui devient de plus en plus pressant, mais qui est difficile à tester car on a rarement accès à des dizaines de postes, périphériques et configurations différents pour tester un design et réaliser l’ampleur du problème. Ce problème est aujourd’hui limité, mais pourrait s’amplifier dans les années à venir. Comment allons nous gérer les différences croissantes de résolution d’écran?

Je n’ai pas de réponse précise, mais voici quelques pistes:

1. Il va falloir diminuer la dépendance aux graphismes bitmap. Donc utiliser les propriétés CSS3 de décoration, les Web Fonts plutôt que des images, SVG pour les pictogrammes et différents éléments de décoration.
2. Côté mise en page, les Media Queries seront utiles. Mais leur utilisation est encore balbutiante, presque toujours combinée avec l’unité px, et je ne suis pas emballé par la stratégie qui consiste à définir plusieurs largeurs de site web fixes en pixels et à basculer sur l’une ou l’autre en fonction de la largeur du viewport.
3. Pour la taille du texte, il faut peut-être faire confiance aux navigateurs et systèmes d’exploitation pour proposer une taille de texte par défaut «optimale» sur chaque périphérique. Dans ce cas, on pourra définir les tailles de texte uniquement à l’aide de l’unité rem (root em en CSS3).
4. Peut-être penser à utiliser les Media Queries pour augmenter la taille du texte sur les écrans les plus larges?
5. Enfin, il est peut-être temps de tanner les éditeurs de navigateur et d’OS pour que les unités CSS absolues (cm, mm, pt, etc.) soient enfin appliquées correctement! C’est je pense une solution d’avenir, mais il faut corriger le problème au plus tôt si on veut pouvoir compter sur cette solution dans quatre ou cinq ans…

Hey, vous avez vu comment je glisse un nouveau troll en douce? Le pixel-perfect est has been, réclamons le point-perfect!

La semaine prochaine, si vous n’avez pas tout cassé en trollant dans les commentaires, on parlera codage de caractères et je vous expliquerai pourquoi la notion de «caractère spécial» est une vaste fumisterie.

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.