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.

Le dernier billet publié sur Les Intégristes parlait d’humilité et de bienveillance à l’égard de nos pairs.

Être bienveillant implique de soutenir nos collègues, d’être indulgent à leur égard, mais cela n’exclut pas d’avoir le courage de leur parler avec honnêteté en cas de problème.

C’est en écoutant des confrères et consœurs travailleurs du web me parler de leurs frustrations au quotidien, qui par email, qui sur Twitter, qui pendant Paris Web, que j’ai eu envie d’écrire sur la relation singulière entre intégrateurs et chefs de projet – une relation ô combien essentielle, sur laquelle on trouve pourtant bien peu de littérature.

Derrière ce billet, il y a un constat : en 2014, j’ai été témoin d’une irritation sourde et croissante chez mes pairs, irritation souvent provoquée par des gestions de projet catastrophiques.

À l’incompatibilité supposée entre intégrateurs et designers a succédé, semble-t-il, la lassitude de certains d’entre nous à l’égard de certains chefs de projet avec qui nous collaborons au quotidien. C’est un ressenti que j’ai perçu de façon assez globale, mais que j’ai trouvé particulièrement exacerbé auprès de mes confrères et consœurs travaillant en agence.

Certes, il est toujours plus facile de voir la paille dans l’œil du voisin que la poutre qui est dans le sien.

J’ai conscience que pointer du doigt les mauvaises habitudes de mes pairs est, sinon politiquement incorrect, du moins délicat. C’est pourquoi je me suis essayée à une forme d’écriture plus légère que d’habitude, sous forme de conte de Noël, ceci afin de provoquer une prise de recul salvatrice.

J’espère de tout cœur que cette prise de risque donnera lieu à des débats enrichissants pour nous tous.

Il était une fois…

Il était une fois, dans un pays très, très lointain, une petite agence web.

Cette petite agence web réussissait toujours à décrocher les projets les plus excitants et les plus valorisants.

Ses clients étaient tous éduqués, sages et riches.

Pour ne rien gâcher, ses locaux rutilants et faciles d’accès se trouvaient à deux pas de la meilleure boulangerie du pays.

C’est dans cette petite agence web que travaillaient main dans la main les Ergonomes, les Designers, les Intégrateurs, les Développeurs, les Commerciaux et les Managers :

• Les Ergonomes avaient toujours le budget nécessaire pour réaliser des tests utilisateurs ;
• Les Designers bénéficiaient à chaque fois d’au moins huit jours pour préparer les avant-ventes ;
• Les Intégrateurs convainquaient à tous les coups leurs interlocuteurs des bienfaits de l’accessibilité ;
• Les Développeurs avaient toujours à leur portée des spécifications complètes et finement rédigées ;
• Les Managers suivaient les plannings à la perfection. Réactifs, c’était des forces positives sur lesquelles on pouvait compter en cas de coup dur ;
• Les Commerciaux quant à eux réussissaient toujours à négocier plus de charges pour que les Ergonomes, les Designers, les Intégrateurs et les Développeurs puissent travailler sereinement, sans pression.

C’est aussi dans cette petite agence qu’officiaient des professionnels réputés : les Chefs de projet idéaux. Ceux-ci orchestraient tous les projets de la petite agence avec flair et doigté.

Que soient narrés aujourd’hui quelques-uns de leurs hauts faits, à travers le prisme de leurs interactions constantes avec les Intégristes Intégrateurs.

Chiffrage et planification

Avant toute chose, les Chefs de projet idéaux pensaient à mettre les Intégrateurs dans la boucle, non seulement pour valider la faisabilité du projet côté front-end et pour macro-chiffrer la charge en intégration, mais également pour lister avec eux tous les éléments dont ils auraient besoin pour commencer à travailler sereinement.

Quand ils savaient qu’un apprenti prendrait part à un projet complexe, les Chefs de projet idéaux veillaient à solliciter un Intégrateur senior afin d’estimer la charge en fonction de ce paramètre.

Les Chefs de projet idéaux faisaient tout leur possible pour éviter que les Intégrateurs soient envoyés du jour au lendemain dans une régie obscure. En effet, les Intégrateurs travaillaient mieux dans un contexte connu. Les régies sont bien souvent synonymes, au mieux, de webmastering désagréable, au pire, de gestion d’urgence, là où une organisation rigoureuse devrait pouvoir éviter ça.

Lorsque Ergonomes et Designers prenaient du retard dans la conception du projet, les Chefs de projet idéaux rassuraient les Intégrateurs en leur confirmant que la date butoir glissait également pour eux.

Enfin, les Chefs de projet idéaux étaient bien organisés, et briefaient les Intégrateurs avant qu’ils ne commencent à travailler.

Qualité du projet

Les Chefs de projet idéaux avaient le cran de parler avec franchise des diverses contraintes à leurs Clients. Ils savaient que, s’ils y manquaient, le projet hériterait d’exigences supplémentaires pour le moins coûteuses.

Les Chefs de projet idéaux avaient à cœur la qualité des projets qui passaient entre leurs mains. Ils ne demandaient pas aux Intégrateurs de mettre en place des mauvaises pratiques par simple peur de devoir dire « non » aux Clients. Par exemple, les Chefs de projet idéaux savaient qu’il était important de former les contributeurs au sous-titrage des vidéos.

Car, oui, les Chefs de projet idéaux accordaient de l’importance à l’accessibilité. Ils savaient que l’accessibilité du web ne concernaient pas uniquement les personnes en situation de handicap, mais qu’elle bénéficiait à tous, et que, si elle était prévue dès la genèse du projet, il serait plus facile de la mettre en œuvre.

En début de projet, les Chefs de projet idéaux prenaient soin d’annoncer aux Intégrateurs que le site devait être responsive, multilingue, optimisé « retina » et/ou compatible avec Internet Explorer 6.

Et, lorsque les Intégrateurs leur demandaient la liste complète des navigateurs avec lesquels le projet devait être compatible, les Chefs de projet idéaux la leur fournissaient facilement.

Les Chefs de projet idéaux prenaient soin de rassembler tous les entrants nécessaires à la bonne exécution des tâches, notamment les maquettes graphiques validées.

Tout affables qu’ils étaient, les Chefs de projet idéaux savaient argumenter face aux demandes parfois surprenantes des Clients.

Recette et maintenance

Les Chefs de projet idéaux apprirent un jour que le Chef de projet d’une autre petite agence web avait recetté un site 48 heures à peine avant la livraison, alors qu’il avait eu plusieurs mois pour le faire au fil de l’eau. Quand ils entendirent cela, les Chefs de projet idéaux éclatèrent d’un rire tonitruant mais noble, que l’on entendit jusqu’au Mont Fuji et au-delà.

Les Chefs de projet idéaux connaissaient très bien la différence entre ce qui relevait du design, du front-end et du back-end. Ils savaient aussi identifier les zones contribuables d’un site. Ainsi, les Chefs de projet idéaux étaient toujours à l’aise pour qualifier les tickets qui passaient entre leurs mains.

De même, les Chefs de projet idéaux assignaient un nombre raisonnable de tickets à une même personne, prenant en compte son degré de connaissance du projet et la difficulté des tâches attendues.

Les Chefs de projet idéaux évitaient aussi d’assigner aux Intégrateurs un ticket concernant, au choix :

• un bug déjà soulevé à plusieurs reprises,
• une anomalie repérée dans un navigateur hors périmètre,
• un problème de contribution,
• une erreur de traduction,
• une demande d’évolution,
• ou encore une majuscule manquante dans un texte, et ce sur 15 gabarits.

Par ailleurs, dans le cadre d’un projet responsive, les Chefs de projet idéaux prenaient soin de rédiger un rapport de bug complet, qui précisait la résolution et le périphérique sur lesquels apparaissaient les anomalies.

Diplomatie et confiance

Les Chefs de projet idéaux gardaient la tête froide. Ils savaient que leur rôle est essentiel pour mener les projets à bien, en particulier pour synchroniser les efforts des différents corps de métiers, et pour arbitrer en cas d’imprévu.

Si, d’aventure, un Intégrateur leur faisait part de ses inquiétudes, les Chefs de projet idéaux prenaient le temps de lui répondre, soit pour le rassurer, soit pour lui montrer qu’ils avaient bien pris en compte ses recommandations ou ses alertes.

Les Chefs de projet idéaux faisaient confiance aux équipes techniques et graphiques. Ils communiquaient suffisamment au quotidien pour que les premiers ne ressentent pas le besoin de devoir soumettre les autres à la question, jour après jour, pour savoir où ils en étaient.

Les Chefs de projet idéaux avaient la même considération pour HTML et CSS que pour n’importe quelle autre technologie web. Ils savaient que ces langages en apparence simples cachent des problématiques complexes.

Après une mise en production, les Chefs de projet idéaux citaient et remerciaient, dans les communications associées, tous les collègues ayant pris part au projet.

Lorsque les Intégrateurs terminaient un projet plus tôt que prévu, les Chefs de projet les incitaient à peaufiner le résultat, ou à rédiger un retour d’expérience lorsque le sujet était intéressant, ceci afin d’améliorer la qualité et de favoriser la capitalisation des connaissances.

Les Chefs de projet idéaux savaient créer un esprit d’équipe stimulant pour que chacun puisse, en toute confiance, donner le meilleur de lui-même.

Enfin, les Chefs de projet idéaux considéraient les contraintes de chaque intervenant avec impartialité. Ils étaient attentifs aux besoins de chacun, et savaient faire preuve d’écoute.

Épilogue

Le monde du travail n’est pas un conte de fées.

Derrière sa forme humoristique, ce billet a pour but d’attirer l’attention sur les éléments stratégiques d’une collaboration efficace entre chefs de projet et intégrateurs.

Les chefs de projet ont une grande part de responsabilité dans le succès (ou l’échec) des projets qu’ils gèrent, mais tout ne repose pas sur leurs épaules. Ils font souvent face à des clients qui n’y connaissent rien, persuadés que créer des sites web est facile et que ça ne coûte pas un rond.

Les chefs de projet doivent souvent réaliser un nombre de tâches indéfinies, qui fluctuent en fonction du milieu dans lequel ils évoluent (agence, annonceur) et surtout du client.

Quant à nous, nous ne sommes pas à la place de nos collègues. Nous ne percevons leur travail qu’à travers nos propres problématiques métier, notre sensibilité ainsi que nos a priori, parfois influencés par les tensions passagères que provoquent parfois les projets ambitieux.

C’est pourquoi nous manquons souvent de recul pour comprendre les contraintes particulières auxquelles les chefs de projet font face, ainsi que les décisions qu’ils sont amenés à prendre, d’autant plus lorsque la communication entre eux et nous est insuffisante.

Ensemble, il est sans doute possible d’améliorer les choses.

En tant qu’intégrateurs, nous avons souvent l’occasion de partager notre expérience professionnelle, que ça soit par tweet, par blog ou par conférence interposés.

Nous participons à l’effort collectif de documentation et de communication, peut-être parce que l’intégration web est toujours, fin 2014, une discipline mouvante, difficile à aborder et à définir.

Donner à voir notre quotidien professionnel fournit – espérons-le – des clés à nos interlocuteurs pour mieux comprendre notre métier et ses particularités.

Or, on n’entend que trop rarement les chefs de projet parler de leur métier et de leurs contraintes spécifiques, alors qu’il s’agit d’un métier tout aussi singulier et stratégique.

Une gestion de projet de qualité est cruciale à la réussite des projets web dont nous partageons la responsabilité et, pourtant, il me semble que les chefs de projet communiquent encore assez peu sur le web.

Les chefs de projet pourraient par exemple donner davantage à voir leur quotidien, leurs méthodes, leurs outils et leurs contraintes, quel que soit leur nombre d’années d’expérience, leur statut ou le type de structure pour laquelle ils travaillent, afin qu’eux et nous puissions mieux travailler ensemble.

J’adorerais aussi lire des retours d’expérience rédigés à quatre mains, par un chef de projet et par un intégrateur, tout comme j’adorerais les voir sur scène ensemble pour nous raconter comment ils ont réussi, jour après jour, à améliorer leur collaboration.

Mais cette collaboration renouvelée pourrait sans doute prendre d’autres formes encore…

Maintenant, c’est à vous : connaissez-vous un∙e Chef de projet idéal∙e ? Quelles sont les caractéristiques de vos chefs de projet préférés ? Racontez-moi une belle histoire, soit dans un commentaire, soit sur Twitter, en mentionnant @lesintegristes.

Et, d’avance, belles fêtes de fin d’année à tous !

Merci à Anne, Corinne, Damien, Delphine, Élodie, Éric, Florian, Fred, JP, Julien, Matthieu, Mehdi, Olivier, Pierre, Samuel et Vincent pour leur relecture et leurs conseils avisés.

Et merci à ma maman, Claire Guillaumet, pour ses illustrations.

Il y a souvent une différence de 10% de salaire entre un senior (4-6 ans d’expériences) qui gagne 47.5K et un simple développeur Front-End qui atteint seulement 34K.

[…] en général le salaire a tendance à progresser énormément et le taux d’évolution du salaire selon les années d’expériences pour un développeur Front End connaît une augmentation de près de 70% en moyenne.

Fiche Développeur Front-End

Il y a également une fiche Intégrateur web qui relègue définitivement ce dernier au rang du webmaster des années 90-2000.

Fiche intégrateur web

Vous en pensez quoi de ces fiches ?

J’aime bien cette partie qui est à mon avis trop souvent oubliée dans les compétences du métier du développeur front-end :

L’objectif du Front-End est de rendre le site internet plus ergonomique (esthétisme visuelle) et de rendre plus accessible la partie fonctionnelle (navigation sur le site).

Aucun savoir n’est immuable. Aucune technique n’est pérenne. Aucune pratique n’est parfaite. Le métier d’intégrateur web en particulier est une leçon d’humilité permanente.

Toute bonne pratique doit être discutée. Tout intégrateur doit se remettre en question.

Chaque projet web auquel je contribue est l’occasion d’apprendre des choses qui me servent pour le projet suivant. Chaque nouveau projet me permet d’expérimenter et de perfectionner mon approche du développement front-end. Je n’ai jamais produit deux fois le même code, même sur des sites très similaires. L’évolution technologique est telle que c’est presque impossible.

« Ça dépend. »

Je commence à avoir un peu de bouteille en matière d’intégration. Pourtant, plus les mois passent, plus j’intègre des sites, moins j’ai de certitudes. La seule chose dont je suis sûre, c’est qu’il n’y a pas de vérité absolue en matière d’intégration web. Même si un point particulier est conditionné par un certain nombre de bonnes pratiques, toute la particularité de ce métier subtil peut être résumé en une phrase : « Ça dépend. ».

Ça dépend du profil des utilisateurs du site, ça dépend du budget, ça dépend du planning, ça dépend du design, ça dépend des contraintes de développement, ça dépend des objectifs en terme de performances, de qualité et d’accessibilité, ça dépend des plateformes ciblées, ça dépend de l’expérience, du savoir et de la souplesse de chaque intervenant. Bref, ça dépend.

Prendre une décision dans cette immense champ des possibles ne dépend ni de vous, ni de moi. Aucune décision technique pour le web ne peut être la décision d’un seul individu. Pour pouvoir trancher, il faut s’en remettre aux objectifs du projet et à sa cible. Tout est question de contexte.

Débattre, confronter ses idées et sa pratique à celles des autres n’est pas utile, c’est indispensable. Remettre en question les pratiques appliquées depuis des années est une attitude saine. Rappelle-moi pourquoi on a l’habitude de faire comme ça, déjà ?

Errare humanum est

De même, reconnaître qu’on s’est trompé, qu’on a pris le problème par le mauvais côté, qu’on a mis en place une usine à gaz n’est agréable pour personne. Il faut pourtant en passer par là pour se perfectionner.

Force est de constater qu’une critique nous marque tous plus durablement qu’une louange. La faute à notre orgueil mal placé, je suppose. Pourtant, remettre en question nos habitudes de développement est la base même de l’apprentissage.

Se tromper et s’en rendre compte est la garantie qu’on ne commettra pas la même erreur deux fois.

Quand on nous a dit qu’il fallait séparer le fond et la forme, certains l’ont pris au pied de la lettre, et ont oublié qu’ils avaient le droit d’utiliser des classes pour éviter de répéter des déclarations de style au sein de la même feuille de style, multipliant les sélecteurs, court-circuitant la cascade et alourdissant le fichier CSS. Je l’ai fait.

Quand on nous a dit que les sprites, c’était bien, certains d’entre nous en ont usé et abusé. Certes, toutes tes icônes sont réunies sur un seul et même fichier, mais ton fichier pèse 800ko, dont une bonne moitié n’est jamais utile sur 95% des pages. Je l’ai fait.

Quand on nous a dit que le @extend de Sass était révolutionnaire, certains d’entre nous ont fait du zêle et l’ont utilisé massivement, sans se rendre compte qu’ils généraient ainsi des blocs énormes et court-circuitaient eux aussi la cascade. Ça aussi, je l’ai fait !

Un jour ou l’autre, en dépit de notre expérience, de notre passion et de notre sérieux, nous produisons tous quelque chose de moins bon que d’habitude. (Quand je dis « moins bon », on s’est compris !…)

Pire, dans notre pratique quotidienne, alors que nous sommes convaincus d’avoir bien fait notre travail, nous créons sans le savoir et sans le vouloir des problèmes aux collègues à qui nous passons le relais dans la chaîne de production web.

En tant que web designer, j’ai parfois créé des problèmes d’intégration alors que l’intégration n’avait même pas commencé, simplement en concevant un élément d’interface über compliqué. Le design de cet élément allait-il stimuler l’expérience émotionnelle des utilisateurs du site ? Peut-être. Le design de cet élément allait-il contribuer à exploser les charges prévues pour l’intégration ? Sans doute.

En tant qu’intégratrice, j’ai parfois créé des problèmes de développement avant même que le développement ait commencé. Quand j’en prends conscience, je jure mes grands dieux de ne plus commettre la même erreur. Et puis, le temps passe, et j’en commets d’autres.

Mais comment éviter ces effets de bord ? La vérité est là, tapie dans l’ombre, et elle nous observe de toute sa majesté, un sourire aux lèvres : nous ne le pouvons pas. Nous allons nous tromper, et nous devons nous tromper, afin de nous améliorer nous-mêmes, de partager nos retours d’expérience et d’éviter à nos condisciples de commettre les mêmes erreurs que nous.

Garder pour soi ce type de conclusions serait une grave erreur. Certains d’entre vous se disent peut-être que « c’est trop la honte » d’admettre de s’être trompé, que les autres vous montreront du doigt et se moqueront de vous. Encore cette histoire d’orgueil mal placé !

Dans les faits, nous sommes tous friands des histoires qui ont mal commencé mais qui finissent bien. Entre nous, quiconque admet s’être trompé, en démontrant ce qui n’allait pas et en proposant une solution, gagne le respect de ses pairs. De base, comme ça, simplement grâce à cette preuve d’humilité – humilité qui nous manque tant.

Car écrire un énième article sur les bonnes pratiques déjà connues, au fond, a une utilité limitée. Quid de tous les cas dont personne ne parle, des sources d’erreur et de confusion, des pièges à éviter, ou encore des leçons apprises à la lumière de la relecture de notre propre code, six mois après ? (« Par la barbe de Merlin, moi, j’ai écrit ça ?! »)

Il y a deux façons de considérer une erreur :

1. soit comme un échec personnel (coucou l’égo démesuré !) ;
2. soit comme une occasion de rebondir et de s’améliorer.

Pour embarrassants que soient ces moments de prise de conscience, s’ils peuvent être la source d’un coup de main donné à toute l’assemblée des experts front, c’est une jolie façon de transformer un vulgaire caillou en or.

À chaque jour son nouveau messie

Le problème, ces dernières années, c’est que tout ce qui se dit sur la Toile à propos des méthodes de développement front-end est relayé sur Twitter et a tendance à être pris pour argent comptant. À chaque jour son nouveau messie. Pour peu que le messie en question ait beaucoup de followers, peu de voix s’élèveront alors pour remettre sa parole divine en question : « Si lui, si elle le dit, c’est qu’ils doivent avoir raison ! ».

Pire, puisque les moteurs de recherche accordent de l’importance aux réseaux sociaux, ces billets messianiques, très partagés, remontent assez haut dans les résultats de recherche. En conséquence de quoi, grand est le risque de faire aveuglément confiance à ces articles, simplement parce que comme ils arrivent en premier dans Google, ils doivent être les plus pertinents.

C’est là tout l’art délicat de faire de la veille : il faut trier le bon grain de l’ivraie, et même parmi les bons grains, il faut expérimenter, encore et toujours, et ne jamais cesser de poser des questions, comme les enfants : « Pourquoi ? Mais pourquoi ? ».

Ajoutons à tout cela que le développement front-end est en train de vivre une révolution avec, entre autres, d’un côté les problématiques apportées par le responsive web design et de l’autre, l’utilisation des préprocesseurs CSS qui permettent une organisation plus modulaire de notre métier.

Les projets web que nous intégrons, vous et moi, sont devenus énormes : l’intégration web n’est plus l’apanage de quelques boîtes innovantes, de quelques geeks intégristes qui se pignolent sur les spécifications du W3C. Non, l’intégration web est devenue un pilier stratégique pour le web actuel. Paradoxalement, les contours de ce métier n’ont jamais été aussi flous.

On constate des différences de niveau importantes entre les professionnels qui exercent ce métier, à tel point qu’on en vient à se demander si tous les intégrateurs web et développeurs web front-end font réellement le même métier. Le développement web côté client est encore plus expérimental aujourd’hui qu’il ne l’a jamais été.

Le simple fait d’hésiter constamment entre l’appellation « intégrateur web » ou « développeur web front-end » participe à ce trouble généralisé. Et que dire de ceux, de plus en plus nombreux, qui non contents de faire de l’intégration, font aussi du web design ? Et encore, je ne parle que du profil atypique que je connais le mieux ; il en existe pleins d’autres.

En plus du socle technique à la base de notre métier (sémantique, feuilles de styles, accessibilité, bonnes pratiques, interactions), les notions d’ergonomie, de référencement, de performances, de marketing et même de droit jouent un rôle important dans notre activité, sans qu’il soit pour autant possible de les quantifier, ni qu’un seul individu puisse exceller dans toutes. Nous avons tous notre spécialité.

La perplexité que nous ressentons lorsque vient le moment de choisir comment décrire notre métier et sous quel titre nous vendre n’est pourtant rien à côté de la grande confusion qui règne dans les discours des recruteurs IT. Les annonces de recrutement trop vagues et en même temps trop précises, les intitulés de poste qui ne prennent pas en compte les profils de moutons à cinq pattes, et les évolutions de carrière délicates – tout cela ne fait qu’ajouter un grosse louche de flou artistique sur une profession en pleine mutation. Déjà qu’on avait du mal à expliquer le métier d’intégrateur à nos proches…

Dans ce contexte troublé, comment aurait-on la maturité nécessaire pour affirmer: « Il faut faire comme ça » ? Les guéguerres sur Twitter, les vendettas par messages privés et les trolls auxquels nous avons fini par nous habituer prouvent bien que les choses ne sont pas claires. Même les intégrateurs expérimentés se prennent la tête sur les nouvelles problématiques – écrans haute définition, performances sur mobile, animations, SVG, préprocesseurs, typographie, etc.

D’autant plus que le parc informatique n’est pas mûr, lui non plus. Les spécifications de HTML5 et de CSS3 sont encore en cours de rédaction. Et, en dépit des petits malins qui codent uniquement pour Webkit et nous narguent avec un « c’est facile, regarde ! », la grande majorité d’entre nous devons assurer une interopérabilité optimale des sites que nous développons.

Je ne suis sûre de rien

Dans ce contexte, camper sur les certitudes que nous avions acquises dès 2003 avec la révolution réprésentée par CSS Zen Garden me paraît dangereux pour notre pratique actuelle.

Aujourd’hui, nous avançons, petit à petit, en continuant à expérimenter massivement. Le web est encore, en 2013, notre terrain de jeu favori. Chaque jour apporte son lot de découvertes, d’interrogations et de débats enflammés. Nous faisons, en quelque sorte, de la recherche sur la meilleure façon de procéder en fonction d’une contrainte donnée.

Mais tout ce que nous apprenons en ce moment risque d’évoluer, jetant aux oubliettes les méthodes et les bonnes pratiques que nous sommes justement en train de théoriser. Les discours consistant à dire qu’on a toujours fait comme ça, qu’on ne parlait pas de ces contraintes-là à l’époque ou encore que Eric Meyer a écrit un article en 2001 sur le sujet et que, par conséquent, ce qu’il y a écrit est vrai pour la postérité – tous ces discours-là sont surannés.

De même que les tutoriaux qui font leur apparition dès qu’un nouveau « buzz word » pointe le bout de son nez (par exemple, retina). Aujourd’hui, personne ne peut affirmer avoir trouvé la solution ultime qui répondra à tous les cas d’usage et à toutes les contraintes web. L’intégration web, c’est une délicate alchimie. On partage quelques astuces, on fait chauffer les alambics, mais aucun d’entre nous ne détient la formule magique – illusoire… – qui fonctionnerait à tous les coups !

C’est pourquoi je vois l’intégration web comme une leçon d’humilité permanente. C’est un métier dans lequel le concept d’obsolescence programmée fait sens : chaque jour, nous produisons des fichiers qui seront obsolètes quelques semaines plus tard. Chaque sortie de site est accompagnée par son lot de regrets et de pis-allers. « On verra plus tard si on a le temps. » Et puis, au final, on ne l’a jamais, ce temps. Il faut l’accepter.

Et quand vient notre tour de juger le travail de nos pairs, ne perdons pas de vue que nous ne connaissons pas les contraintes avec lesquelles ils ont dû jongler. Critiquons, mais de façon bienveillante. Soyons amicaux et respectueux les uns envers les autres. Après tout, nous ne savons pas ce par quoi un collègue intégrateur est passé pour aboutir à ce résultat-là – contraintes, planning, pressions…

Une seule certitude demeure, néanmoins : il devient urgent de mettre notre orgueil de côté, de rester humbles par rapport à une discipline fondamentalement mouvante et surtout, d’assumer nos erreurs.

Personne n’a la science infuse. Ni vous, ni moi.

Tout ce que je sais, c’est que je ne sais rien.

– Socrate

Cette technique a notamment été utilisée par Apple, sur la page de présentation de l’iPhone 5.

Les avantages sont nombreux par rapport à une <video> ou à un GIF :

• Seul le support de <canvas> est nécessaire
• Pas de problème de codecs
• Possibilité de lire ces vidéos sans fullscreen sur iPhone
• Contrôle total sur la vidéo
• Niveaux de transparence (si PNG est utilisé)
• Pas de limitation de couleurs
• Compression sans perte (optionnel)

Évidemment, il ne s’agit pas de l’utiliser pour intégrer de longues vidéos, mais plutôt pour présenter de courtes animations. Les performances sont excellentes, que ce soit en vitesse de rendu ou en temps de téléchargement (dans l’exemple présenté sur cette page, on passe de 7 Mo pour le GIF à 500 Ko).

Faute de mieux, cela permet de combler le manque laissé par les formats APNG ou MNG qui n’ont jamais pu s’imposer. Notre salut viendra peut-être du format WebP proposé par Google qui supporte également les animations, mais que Mozilla refuse d’intégrer à Firefox pour l’instant.

Le script de décompression est open source (licence MIT) et a été publié sur GitHub.

Jon Skinner, l’auteur de l’éditeur Sublime Text, avait proposé une technique similaire pour lire des screencasts. Cette fois, l’outil de compression est libre, multiplateforme (Python) et automatisable.

Saviez-vous que les index de tableaux étaient traités comme des chaînes de caractère en JavaScript ? Et que pour cette même raison, la valeur passée à l’opérateur square brackets ([]) était convertie en chaîne de caractère, ainsi que la première passée à l’opérateur in ? Quelle est la taille maximale d’un tableau ? Et que se passe-t-il lorsque la propriété length est modifiée ?

Pour connaître les réponses à ces questions, foncez lire cet article de Dr Axel Rauschmayer : Arrays in JavaScript.

Je vous invite également également à parcourir l’ensemble du blog, et notamment le guide JavaScript, qui classe et regroupe tous les articles liés au langage.

Dr Axel Rauschmayer (@rauschma sur Twitter) prépare également un livre pour 2013, A programmer’s guide to JavaScript. Il ne fait nul doute que celui-ci s’imposera rapidement comme une référence !

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