Les dernières news, intégration XHTML/CSS, HTML5, développement web, Terragen 2…

News au format RSS
Suivez-moi sur Twitter (Nico3333fr)

« Je hacke le retour d’expérience via un phrasé velouté » (Sud Web) (le 22/05/2017)

Il est dit dans les temps anciens, il y a de longues Décades,
Que chaque homme s’accomplit aux côtés de ses frères d’armes.
C’est mon idéal de chevalier de la Sainte Cascade,
Descendant vers le Sud, dont les chemins me charment.

Je n’ai pas été de toutes les croisades itinérantes,
J’ai pris part à certaines qui furent vibrantes,
Qui tels des héros me firent endosser leur cape.
Par contre, point d’adoubement dans la cité des Papes,
D’un curieux ménestrel venant d’une étrange crypte,
Qui se plaint de la difficulté… des dates en JavaScript ?!

Me voici loin de ma Borée, dans cette province nommée Provence,
À la recherche d’une bienfaisante et douce providence,
Appréciant l’accueil agréable, par une délicate et apaisante ablution,
Ne manquaient que les Dames du Lac, qui de mon bonheur font la complétion.

Je fus venu avec mes forces et quelques certitudes,
Espérant étudier le docte parchemin des workers,
Çà et là la structure des Fermetures – qui m’est bien rude,
Ou bien la Conception Universelle, si chère à mon cœur.
Que nenni, rien de ces secrets ne me fut enseigné !
Mais les leçons furent ailleurs, de mon mal je fus saigné.

Lors de l’assemblée autour de la manquante table ronde,
J’en fus plutôt coi, mes frères d’armes n’ont pas d’armes,
Ou en tout cas plutôt celles d’une douce force calme,
Et voilà que mon armure telle une porte se dégonde.

Je m’incline donc bas devant mes frères et sœurs d’armes,
Dans mon cœur ont pris place, en ont délogé les larmes.
Voici que ma prose s’emballe, je sème vers à tous vents,
Tout ce qui a un début a une fin, voici un commencement :
Prenez mon âme, du moins un petit morceau, partagez-la,
J’en ferai de même avec vous, notre richesse sera là.

Ne voyez pas de vanité dans la forme, plus une liberté
Que je m’offre prestement, ce sera mon butin !
Je hacke le retour d’expérience via un phrasé velouté,
Mais ne manie le vers en aucun cas pour être au thym.
Mon parchemin digital – pardon numérique – s’étiole,
Partageons l’amour, il n’y a rien à perdre, sans fariboles !

In fine, je repars avec moult questions et autres turpitudes,
Néanmoins émerge en moi une indéfectible certitude :
Sans vous – sans toi – je ne suis ni entier ni accompli,
Laissez-moi donc en conter la beauté qu’en vers je brode,
Qui en ce moment me fait toucher un brin d’infini,
Point de délirant péché d’hybris, juste une ode.

Ne me demandez donc pas de ne pas avoir de pleurs,
Car toutes les larmes ne sont pas un malheur.
J’en arrive à l’évidente et simple conclusion
Que je suis submergé par une vague d’émotion.

Vous êtes désormais mon Élysée, mon petit coin de paradis,
ma seconde vie une fois finie, vous serez de ma théogonie,
votre humble serviteur n’a de mot assez beau ici,
alors pour tout ceci, je vous laisse un simple et vibrant…

merci.

Note de lecture : Qualité Web, la référence des professionnels du web (le 06/02/2017)

Cela fait des années que je suis le projet Opquast (pour Open Quality Standards), si vous en doutez, voici ce billet antédiluvien qui parle à l’époque des temps anciens d’un projet intéressant à suivre.

Un peu d’histoire

Historiquement, le projet a connu son premier référentiel en 2004, j’avais pu participer modestement à sa création. La version 2 était arrivée quant à elle en 2010, je n’avais pas pu y participer pour tout un tas de raisons. La version 3 est arrivée en 2015, et là, j’ai pu me faire plaisir en proposant, discutant lors de longs échanges passionnants avec les contributeurs du projet.

Le premier livre est sorti il y a 5 années, et c’était un bon cru, comme ce billet le disait : Qualité Web, le livre, première édition.

Alors, posons la question clairement. Qualité Web : stop ou encore ?

Qualité Web, les bonnes pratiques pour améliorer vos sites

Cette nouvelle édition s’organise différemment de la précédente :

  • la première partie présente les bases de la Qualité Web et de son management ;
  • la deuxième partie contient toutes les fiches dédiées aux 226 bonnes pratiques ;
  • la troisième partie présente les autres checklistes (SEO, performances, etc.) ;
  • la dernière partie est une boite à outils pour tous les professionnels (glossaire, outils, références, etc.)

Durabilité

Là c’est mon côté pragmatique qui va vous faire remarquer que ces bonnes pratiques ont un point fort : elles vieillissent très bien. 29 ont été abandonnées ou transformées en recommandations depuis le précédent référentiel, ce qui correspond à environ 13 %. C’est extrêmement peu, pour ne pas dire que dalle.

Vous en connaissez beaucoup des bonnes pratiques que vous pratiquez depuis plus de 10 ans et que vous n’avez pas abandonnées ? Nos métiers ont énormément changé, les pratiques aussi. Et pourtant, ces bonnes pratiques restent là, presque en pied de nez à l’évolution parfois insolemment rapide. Et très peu ont été totalement abandonnées, la plupart ont été placées en simples recommandations (de bons conseils, à garder à l’esprit si elles sont applicables).

Ces bonnes pratiques ne s’intéressent pas aux technologies ni à des objectifs chiffrés, selon les désormais célèbres 10 règles du contributeur Opquast.

Un livre multi-publics

En général, vous ne lirez pas ce livre comme je l’ai fait, c’est-à-dire intégralement (privilège du relecteur). :)

Non pas que je vous déconseille de le lire en entier – c’est très bien écrit et très intéressant – mais selon votre profil ou votre besoin, vous aurez peut-être juste le besoin d’aller consulter une partie (par exemple e-commerce) ou de simplement apprendre d’autres bonnes pratiques.

Ne vous arrêtez pas au côté impressionnant du livre : les bonnes pratiques sont sur des fiches très simples et dans un format très pratique.

Un livre qui diminue « le prix du ticket d’entrée »

En tant que profil ayant plusieurs années d’expérience, j’ai parfois tendance à oublier que des choses qui me sont acquises sont loin de l’être pour des personnes débutantes. Et avec l’explosion des compétences qui partent tous azimuts, il est facile de vite se retrouver débutant. Certains choix techniques ont un coût d’entrée quand on débute qui n’est pas simple.

Quoi qu’on en dise, maintenir un socle d’objectifs, de connaissances et de culture générale aide à garder un ticket d’entrée aussi bas que possible pour travailler sur et dans le Web, et cette idée me plait toujours plus. Les fiches sont écrites dans un langage clair, accessible et précis, et ça fait du bien, bordel !

Disons-le clairement, ce livre ne fera pas de vous un génie dans une technologie donnée, mais ce que j’apprécie, c’est qu’il contribue à nous ramener à l’essentiel : s’occuper des risques et servir les utilisateurs (qui eux se moquent bien qu’on utilise telle ou telle technologie).

Le renforcement de certains domaines

Le mobile et les formulaires se voient étoffés dans cette nouvelle édition. La sécurité se voit également considérablement étoffée pour cette version, en-têtes de sécurité (x-content-type: nosniff, x-frame-option, CSP, etc.). Aller tester un site sur Mozilla Observatory, et vous comprendrez pourquoi ces bonnes pratiques y sont entrées. Mon petit doigt me dit que l’on n’a pas fini de parler de ces sujets de sécurité cette année !

Conclusion

Stop ou encore ? Clairement, encore. Et même plus que jamais. Des années que ces bonnes pratiques tiennent la route et nous guident vers une montée en compétence (et en qualité !), et accessoirement nous permettent de rendre durable notre écosystème.

La marque Opquast s’impose comme la référence, donc autant le dire clairement, si vous croyiez que le titre était un peu mégalomane… il n’en est rien. C’est clairement la bible des professionnels du web, et donc « la référence des professionnels du Web  ». En toute simplicité. Il pose aussi les bases de métiers en voie d’apparition : responsable Qualité Web.

Ce n’est pas pour rien que je suis ce projet depuis le début, et que je compte continuer de m’y impliquer. Bravo la team Temesis et tous ceux qui ont participé à l’écriture de ce bien bel ouvrage !

Pour trouver ce livre incontournable : Qualité web – Le livre, la référence des professionnels – 2e édition.

Bilan 2016 et perspectives 2017 (le 07/01/2017)

2016 s’est terminée il y a peu, et en lisant le bilan de @hellgy, je me suis dit que ce ne serait pas une mauvaise idée de faire de même. À la fin 2016, j’avais l’impression de n’avoir pas fait énormément de choses, et en relisant, je me dis que cette année n’était pas un si mauvais cru… en tout cas pas si horrible et totalement à jeter comme on nous l’a vendue.

Des peurs et du trop plein

Je crois que 2016 a été suffisamment anxiogène (attentats, etc.), c’est la première année où je me suis surpris à éteindre la radio (un des rares médias que j’écoute bien volontiers en allant et revenant au travail) en disant « stop, j’en peux plus ». Finalement, l’info en continu/temps réel, c’est bien, mais sur des événements qui tapent à l’émotionnel, c’est pas indispensable. Et on s’évite souvent les âneries fausses de journalistes/politiques en mal de matière pour meubler…

Idem côté réseaux sociaux, les (non-)infos relayées à la va-vite sans aucune vérification me font fuir. Sur Facebook, c’est proprement horrible le nombre d’âneries qui sont relayées sans vérifications (et idem sur d’autres réseaux sociaux). Ajoutons à cela qu’un paquet de gens sont dans la pure posture, il est donc difficile voire impossible de discuter avec. Maintenant, je fuis ce genre de trolls.

Même si je suis toujours bon appréciateur de Twitter, j’ai réduit le temps que j’y passe et le volume de tweets. Et de manière encore plus drastique pour Facebook. Par contre, je me suis récemment remis à IRC, et… au bon vieux mail pour de délicieuses correspondances. :)

Des réalisations et des projets pas si mal

Même si j’ai eu la sensation du contraire, j’ai pu participer à des projets très intéressants, notamment la refonte du Directory d’ESOMAR et d’autres projets. Röcssti a tourné la barre des 100 sites réalisés, et encore, je suis à la bourre pour la mise à jour de la galerie, d’autres ont été mis en ligne aussi. :)

Et il y a le lancement de Van11y. Ok, ces scripts sont des versions 1.0, totalement imparfaites, mais c’est un début, et il vaut mieux commencer imparfait que de ne rien faire.

Ajoutons à cela que je me suis improvisé relecteur/correcteur pour la deuxième édition de Qualité Web - Le livre, du coup, j’ai mêlé l’utile à l’agréable, en quelque sorte. Je ne pensais pas tant aimer faire le relecteur.

Des articles et des billets

Cette année, côté articles, ce n’était pas mal non plus :

Côté billets sur ce site, c’était pas si mal non plus, je retiens :

Parmi d’autres.

Des conférences et des gens

Vraiment, c’est le meilleur de cette année. Une année standard, c’est habituellement la possibilité de participer à deux conférences maximum pour moi (temps libre très limité, oui, j’assiste aux conférences sur mes vacances !). Cette année, j’ai pu participer à 3 conférences : Sud Web, Paris Web et Codeurs en Seine. 3 sujets en tant qu’orateur pour 2 conférences, c’est déjà bien.

Ces 3 événements étaient super, chacun avec ses bonnes idées et ses bons moments, j’ai pu connaitre de nouvelles personnes, en revoir d’autres que j’aime beaucoup, et même tisser des liens très forts. Sans parler des sujets, j’ai de quoi apprendre pour au moins tout 2017. :)

En plus, autant j’ai été le débutant sur bon nombre de sujets (et témoin d’énormément de bienveillance en tant que), autant j’ai pu accompagner des personnes sur d’autres. Vraiment ces moments restent parmi les meilleurs de 2016, je me languis d’en revivre de tels. Laissez-moi être votre débutant !

Sur le plan personnel

J’arrive à environ un peu plus d’une semaine supplémentaire à la fin de l’année, environ 50 heures. Un des progrès pour cette année 2016, cela a été lissé sur toute l’année, je n’ai pas eu un mois à bosser comme un taré à faire plusieurs semaines à 60 heures. J’espère bien continuer cette régularité. Et surtout la reprendre pour les projets à côté, j’ai été trop irrégulier en 2016.

Côté personnel, vous ne m’en voudrez pas de ne pas détailler plus. Sachez juste que c’est contrasté.

Pour 2017, des idées en vrac

Plus aider les initiatives

J’ai jamais eu aussi peur que de bonnes choses puissent s’arrêter (événements, initiatives, etc.). Cela a déjà été le cas pour Firefox OS et d’autres, et j’en ai marre de voir de bons projets sacrifiés et des choses bien qui s’arrêtent. Pour ça que je compte soutenir plus ouvertement et même financièrement des initiatives (Let’s Encrypt, La Quadrature du Net, Wikipedia, Paris Web, et d’autres…).

Moins de silos…

La première chose qui m’importe, c’est de continuer à dé-silo-iser certains aspects, et principalement dé-Googliser un paquet de trucs. Je pense que certains de mes sites vont dégager Google Analytics et plutôt utiliser des Piwiks auto-hébergés. Pour mes besoins, c’est largement suffisant, j’ai testé ça sur Van11y, c’est parfait.

Toujours dans cette idée, je suis passé à Qwant au travail et à la maison, et croyez-le ou non, ça fonctionne très bien et cela suffit largement à mes besoins et les résultats sont très pertinents.

J’étais déjà pas un fanatique de Medium, mais une expérience à la limite du dark pattern m’a refroidi de l’utiliser pour longtemps. Facebook me fatigue, j’ai dû faire disparaître la moitié ce que publient les gens, quand ce ne sont pas les gens eux-mêmes.

…Ou du moins les remettre à leur place

Je n’ai rien contre les réseaux sociaux en particulier, néanmoins l’expérience de Nowwwel que Rémi voit avec un petit pincement au coeur, je trouve que c’était un régal : les gens ont écrit (beaucoup), et ont partagé. En clair, j’aimerais bien que Nowwwel, ça soit toute l’année. J’ai de nouveau envie d’écrire, que ça soit ici ou ailleurs. J’espère que d’autres vont retrouver le plaisir de publier chez eux aussi. Remettons les réseaux sociaux à leur place, en simples caisses de résonance !

Du Fact-Checking

Ne comptez pas sur moi pour faire suivre des âneries, surtout que cette année se profile une présidentielle qui risque d’être abracadabrantesque, comme disait l’autre.

Parlez-moi de données vérifiées, croisées, de discours argumentés, de non-manichéisme, d’humilité, d’honnêteté intellectuelle et de prudence dans le propos. Typiquement, j’ai beaucoup les vidéos de Hacking social (leur dernière vidéo sur l’effet Julien Lepers vaut vraiment le détour) ou de Hygiène mentale, qui parle de zététique (visionnez celle sur les arguments fallacieux, qui vaut aussi le détour).

La sécurité

Comme mentionné plus haut, le sujet de la sécurité des sites me passionne, je m’éclate comme un gosse à apprendre sur ces sujets. Mozilla Observatory est un projet fantastique qui m’a énormément appris.

J’ai pas fini d’écrire et de faire des trucs sur le sujet, autant vous le dire de suite !

Apprendre et continuer les projets

Cette année est vraiment intéressante : avec les PWA, de nouvelles API, plein de nouvelles choses sur la sécurité, et tout le reste… on ne va pas s’emmerder !

Mes petits projets comme Van11y, les plugins accessibles (ou d’autres…) vont sûrement progresser, pas aussi vite que je le voudrais, mais c’est un de mes objectifs.

Et je place aussi l’objectif… de ne rien prévoir. Se laisser du temps libre pour découvrir, c’est très bon aussi !

Conclusion

Je pensais avoir très peu écrit/fait de choses cette année, refaire ce bilan me montre que mon sentiment est plutôt faussé. Faites ce bilan aussi si jamais vous avez l’impression de ne pas avoir fait grand chose.

Et surtout, accordez-vous du temps, le droit de ne pas faire parfait, le droit de ne pas tout savoir, le droit de ne pas être au top, le droit de ne pas être dispo 24H/24, le droit de demander de l’aide.

Et des gens, de l’amour et du bon temps partagé, en toute simplicité. C’est le plus important.

Les bonnes résolutions de l’entourage des travailleurs du web (le 22/12/2016)

Pour l’initiative de Nowwwel, j’avais pensé écrire un truc très inspirant et sérieux, et… ça sera pour la prochaine fois.

À la place, rions un peu en cette presque fin d’année où il est souvent question de bonnes résolutions : j’ai imaginé ce que seraient les bonnes résolutions… des entourages proches (familles, amis, etc.) des personnes travaillant dans le Web (ou plus largement dans l’informatique), enfin de certains de ces entourages. Oui, les gens qui ne connaissent pas forcément bien nos métiers, nos vies, etc.

Bien évidemment, toute ressemblance avec des personnes existant ou ayant existé… est absolument fait exprès !

Je vous invite à rêver d’entendre votre entourage vous dire cela :

  • Oui, je ne dirai plus que tu passes ton temps à buller sur Internet.
  • Je promets de tenir la première résolution. Si si.
  • Promis, juré.
  • Et… oui, je ne dirai plus non plus que ton job consiste à lire des e-mails.
  • Oui, je ne dirai plus que ton métier n’est pas un vrai métier parce que tu ne lèves pas 50 kilos de ciment ou tu ne laboures pas un champ.
  • Corolaire : je ne ferai plus de remarque déplaisante du genre « Tu passes ton temps sur un ordinateur, tu ne peux pas être fatigué ». Promis.
  • Corolaire : j’ai compris que ta relative jeunesse n’empêche pas la fatigue et même l’épuisement.
  • Oui, tu as un humour et une culture qui me semblent particuliers, mais non, je ne dirai plus systématiquement que ce ne sont que des « blagues d’ado attardé ».
  • Non, je ne te suggèrerai plus jamais de « faire tomber de la neige sur ton site » !
  • Je ne te dirai plus que tu devrais faire comme sur Facebook ou autre, car j’ai compris que le budget de ton projet/équipe est sûrement différent.
  • Oui, j’ai vraiment compris que le fait que tu travailles avec un ordinateur n’implique pas que tu en maitrises toutes les arcanes.
  • Corolaire : oui, tu n’es pas un spécialiste de l’installation des imprimantes.
  • Corolaire : j’ai aussi compris que tu n’es pas un spécialiste du dépannage informatique.
  • Corolaire : j’ai également compris que le dépannage informatique t’emmerde profondément, même si tu n’oses pas me le dire.
  • Corolaire : je ne profiterai plus de cette excuse pour te demander de faire n’importe quelle tâche en ligne à ma place.
  • Je prendrai des notes de ce que tu m’expliques, afin d’éviter de te demander 20 fois la même chose.
  • D’ailleurs, si je te demande conseil, j’écouterai ce conseil.
  • Corolaire : d’ailleurs, j’arrêterai de me plaindre devant toi des conséquences du non-respect de tes conseils.
  • Oui, je comprends que travailler dans le Web nécessite que tu apprennes constamment.
  • Même si je n’y connais rien, oui, je comprends que tu n’exagères pas en disant que tu dois te tenir à jour quotidiennement.
  • Corolaire : je te permettrai donc d’apprendre, en te laissant aller à des formations/conférences/meet-ups/etc.
  • Corolaire : oui, j’ai compris que tu dois compter majoritairement sur toi-même pour te former.
  • Corolaire : oui, j’ai compris que tu peux avoir le besoin de parler à des gens de ton métier, fût-ce des inconnus pour moi.
  • Oui, j’ai compris que le fait que tu sois sur l’ordinateur à la maison n’est pas nécessairement un prolongement de ton travail.
  • Corolaire : j’ai même compris que si tu pratiques des choses de ton travail à la maison, cela pouvait te détendre.

Note finale : c’est de l’humour… nous sommes également très loin d’être parfaits.

Dans le même genre :

Refonte du site Directory d’ESOMAR (le 13/11/2016)

J’ai récemment participé à la refonte du Directory d’ESOMAR. Voici pêle-mêle quelques pensées, car ce projet a été particulièrement intéressant point de vue intégration. Les plus gros défis d’un point de vue CSS sur cette refonte étaient :

  • Intégrer des composants avec une certaine complexité en responsive (surtout sur la page d’accueil) ;
  • Garder une CSS aussi légère que possible.

ESOMAR Directory

État des lieux

La précédente version du Directory avait énormément de dette technique. Nous parlons d’un projet qui avait à la base été prévu pour être IE6 compatible (si si !). Bien évidemment, hors de question de repartir de ce travail qui n’avait plus rien d’actuel.

La page d’accueil ne pesait pas moins de 1,5 Mo à l’époque, la faute à beaucoup trop de contenus (images, éléments de design ne pouvant être faits en CSS, etc.), pas de stratégie de chargement, etc. on partait de loin. Je n’ose même pas parler des indicateurs de performance, proprement catastrophiques. Je ne me souviens plus exactement du score sur Dareboost, mais il n’était pas fameux non plus. :)

Stratégies

Dès le début du projet, je suis parti de plusieurs postulats.

  • Tout ce qui n’est pas strictement indispensable côté front (principalement des images) sera chargé plus tard.
  • Autant que possible, le positionnement d’éléments se fera avec des classes atomiques.
  • Hors de question de créer un style spécifique pour des éléments triviaux, par exemple les styles d’un lien/bouton seront créés à coups de classes atomiques.
  • La logique atomique sera même poussée plus loin avec des helpers atomiques sur les breakpoints majeurs (onmobile-aligncenter, onmobile-mt2, etc.), toujours dans l’esprit de ne pas utiliser de styles trop spécifiques pour des comportements simples.

Bien entendu, les bonnes vieilles règles sont toujours (et plus que jamais) valables !

  • Séparer le positionnement d’un élément de son design propre (popularisé par OOCSS) ;
  • Décorréler la structure des styles ;
  • Factoriser, à fond. Un comportement revient ? Un style pour ! ;
  • Utiliser des classes d’états (SMACSS) via is-, qui seront en fait très souvent des attributs d’état : [aria-selected="true"], [aria-expanded="false"], etc. ;
  • Etc.

Cela vous surprendra peut-être mais… pour tout un tas de raisons qu’il serait trop long d’énumérer ici, je n’ai pas utilisé de pré-processeur (même si ç’aurait pu être utile).

Les attributs dans tous leurs états, les classes pour le JavaScript

SMACSS avait popularisé le concept de classe d’état, très pratique. En fait, l’utilisation des attributs ARIA ou data-* le cas échéant permet (souvent) de se passer de ces classes. Les composants comme les onglets, accordéon, panneaux dépliants, etc. se stylent très élégamment et efficacement ainsi :

.animated-country-expandmore__button {
/* les styles communs aux divers états */

}
[aria-expanded=true].animated-country-expandmore__button {
/* ici les styles uniquement nécessaires à la surcharge */
}

J’ai même pu placer un très joli :

[aria-busy="true"] { 
background-image: url('../images/ajax-loader.gif'); …
}

Pour des éléments en cours de chargement. Idée suggérée par Matthias lors de la dernière Kiwiparty si ma mémoire est bonne. Idem, votre interface a besoin d’un bouton présent mais désactivé, pas besoin de classe additionnelle, utilisons un attribut disabled en HTML qui se stylera :

[disabled].rfp-results__button {

Et on ne surcharge que le strict nécessaire.

Côté JavaScript, c’est pareil, on ne manipule pas (jamais !) de styles en ligne, mais directement les attributs ou des classes. Résultat, le JavaScript tire parti de classes atomiques comme hidden/is-hidden. Certaines parties sont des mini-applications, on se retrouve à manipuler des classes comme .nonvisible (visibility: hidden), qui permettent d’avoir les éléments présents mais de les rendre invisibles : parfait pour enlever/faire apparaitre des options selon ce que l’utilisateur fait.

Des composants compliqués en responsive

La grosse difficulté a été la page d’accueil. Pour vous donner une idée : on a des onglets… qui contiennent des onglets, et selon les résolutions cela se transforme en panneaux dépliants qui contiennent des modales… toujours avec les mêmes contenus (et je vous passe quelques étapes intermédiaires).

Vous pouvez cliquer sur les images pour mieux voir les interfaces.

Des onglets pris dans des onglets
Le même composant avec des panneaux dépliantsLe même composant avec une modale ouverte

C’est là que le côté structurant des plugins accessibles va donner tout son potentiel, clairement : je n’aurais pas pu m’en sortir sans. Par exemple, pour transformer des onglets en panneaux dépliants, le contenu de chaque onglet contiendra un panneau dépliant via :

<h3 class="js-expandmore nodesktop notablet" data-hideshow-prefix-class="mobile-expand">Company location</h3>

Le contrôle de ce dernier sera caché sur desktop et tablettes et son état « fermé » de son contenu sera affiché. Pour le mobile, les contrôles des onglets seront cachés, tous les contenus des onglets sont affichés, et on rétablit le fonctionnement normal des panneaux dépliants. Le principe sera le même pour les onglets qui vont se transformer en modales. Avec un peu de plomberie en JavaScript pour gruger certains attributs selon la résolution.

Si cette partie est trop compliquée (je reconnais que c’est un peu sioux), n’hésitez pas : demandez. J’écrirai un pas à pas, car le principe est simple, mais la résultante est un peu dure à suivre (et je n’ai peut-être pas utilisé la méthode la plus simple non plus).

Le test ultime pour voir la robustesse de votre intégration : utilisez un BrowserSync (exemple ici), ouvrez plusieurs fenêtres à différentes résolutions, et utilisez votre interface dans une fenêtre. Comme les fenêtres sont synchronisées entre elles, vous allez voir des choses assez amusantes se produire. Bien entendu, cela peut se faire sur différents navigateurs sur un réseau local, cela simplifie bien le debug cross-browser. En quelques minutes, vos collègues vont vous dire « ah, Safari Mac, un petit souci en desktop », le cas échéant, vous pouvez même débugger en live et fixer.

Et y a un côté rigolo à prendre le contrôle d’une fenêtre à distance.

Des tendances intéressantes en « atomique à la main »

Si certaines règles peuvent surprendre dans la source HTML (il n’est pas rare de croiser un button class="bg-eso-blue strong pl1-5 pt0-75 pb0-75 pr1-5 color-white"), elles sont totalement justifiées pour la maintenance de la CSS, une fois les gros modules posés (onglets, modales, etc.), je ne suis que peu retourné dans la CSS.

On peut souvent entendre que l’atomique ne fonctionne pas en responsive, c’est inexact selon ce que vous en faites. Typiquement, des onmobile-pl1-5 onmobile-pr1-5 onmobile-pb1 onmobile-aligncenter permettent d’adapter des éléments sans revenir dans la CSS et, sans redéfinir des styles spécifiques. Si vous pensez que c’est inutile, avec une tonne de composants ayant quelques variantes et pleins d’éléments, le bénéfice est énorme : la CSS minifiée ne pèse au final que 31 ko (sans compression gzip, sinon ça tombe à 7,5 ko). Pour un site de cette taille, c’est plutôt raisonnable.

In fine, ajouter de nouveaux éléments sur le site consiste à reconstruire avec les helpers de positionnement existants (en ajouter le cas échéant), je ne suis pas loin de designer dans le navigateur pour la plupart des nouveaux ajouts. Ce n’est pas une approche entièrement atomique comme Atomic CSS, mais c’est le même principe, à la différence près que ce n’est pas généré automatiquement, de la CSS atomique à la main en quelque sorte.

Le gros de la CSS est sur les modules (expand, modales, onglets, etc. qui ne se marrient pas forcément avec une approche atomique) et sur la structure : je me voyais mal commencer à surcharger mes composants avec des helpers (là où cela n’a pas de sens). La partie consacrée aux pages est très courte, ce qui indique que très peu de CSS a été utilisé qu’une seule fois sur le site.

Au final, je trouve que les CSS atomiques sont parfaites pour positionner des éléments, effectuer des comportements simples (centrer sur mobile…) et éviter de produire des styles pour des éléments simples. Par contre, ils me semblent très peu adaptés pour des composants complexes. Le tout est de savoir où l’on pose la limite. :)

OOCSS parlait de relation 1/n (1 style pour n composants), mais c’est en fait dans les deux sens : 1 style peut servir n composants, et 1 composant peut être composé par n styles.

Conventions

Certes, les helpers sont préfixés par ontablet/onmobile/onsmallmobile pour de simples raisons de compréhension. D’autres systèmes utilisent large/medium/small/etc. ou d’autres conventions, là je dirais que peu importe la convention que vous choisirez, tant que vous vous y tenez.

D’ailleurs, comme le site est intégré en em, que ce soit mobile/small/etc., cela n’a pas de sens, car en zoomant fortement, on peut se retrouver avec le template « small » sur desktop en gros caractères, etc.

Le gros effort – et c’est encore largement améliorable – est surtout sur l’ordre et le rangement de la CSS. Si ce point est souvent négligé, là sur ce projet, c’est vraiment très très appréciable maintenant que je suis passé en maintenance. Ne négligez pas cet aspect. Là, l’organisation de Röcssti me permet de tirer parti de la cascade tout en mélangeant plusieurs approches CSS.

Des positionnements divers et variés

Côté intégration, ce site m’a fait sortir à peu près tous les positionnements CSS. Positionnement absolu, fixé, relatif, statique, flottants, inline-blocks, table-layout, inline-table, multi-colonnes et même un peu de flexbox pour le réordonnancement d’un élément sur le mobile.

Les plus utilisés sont le table-layout et l’inline-table. Ils sont redoutables en CSS, hyper-robustes et très prédictibles. Le multi-colonne est un régal quand on a de longues listes d’éléments, ce qui était exactement mon cas.

Conclusion

Bien entendu, rien n’est terminé, des parties sont encore en cours d’amélioration. Les indicateurs sont plutôt encourageants côté performance :

  • Document complete est à 13 requêtes pour 163 ko ;
  • Le fully loaded est par contre lui à 24 requêtes pour 233 ko ;
  • La CSS pèse actuellement 58 ko, 31 ko minifiée, ce qui donne 7,5 ko après la compression gzip ;
  • Le specificity graph de la CSS a des valeurs plutôt basses, une majorité est à 10, les composants à état sont à 20 et quelques rares surcharges ou élément sont à 30 ;
  • Côté qualité, Dareboost indique un petit 94 au moment où j’écris ce billet.

Specificity Graph de la CSS

Vous pouvez essayer, vous ne trouverez aucun !important dans la CSS. :)

En tout cas, cela montre bien le progrès monstrueux qui a été fait sur les sites à une échelle de plusieurs années. Même si objectivement, les sites que nous faisons il y a un peu plus de 6 ou 7 ans n'étaient pas mauvais en soi (en les replaçant dans le contexte de l'époque), les sites actuels peuvent en faire beaucoup plus (responsive, interfaces plus riches, etc.) tout en étant beaucoup moins lourds et bien meilleurs qualitativement parlant. Ce projet en est un exemple exemple, le poids du site a été divisé presque par 10 tout en ayant beaucoup plus de possibilités.

Par contre, cette richesse se paie en gestion plus rigoureuse, bien entendu !

Paris Web 2016, retour de l’orateur (le 16/10/2016)

Je vous avais déjà fait le retour du spectateur de Paris Web 2016, voici maintenant celui de l’orateur, entre accessibilité décomplexée et lightning talks.

Si vous croyez que se retrouver orateur est un long fleuve tranquille, je vous invite à lire ce qui suit et j’espère vraiment que vous relativiserez vos refus de sujets ou vos mésaventures après.

L’accessibilité décomplexée

Cela faisait quelque temps que j’avais envie de parler d’un retour d’expérience passé sur plusieurs années de plugins accessibles, et de comment ça peut valoriser un CV de développeur.

Coquin de sort, la première fois que j’ai voulu aborder le sujet était pour Sud Web 2016, je me suis dit qu’un lightning talk serait parfait. J’improvise dans ma voiture pour voir l’idée (oui, on meuble comme on peut son temps de trajet !), et c’est là que me vient stupidement l’idée du nom Van11y, Vanilla-Accessibility. Du coup, même si Sud Web a refusé la proposition, sans le savoir ils m’ont bien rendu service. (quand je vous dis qu’être refusé à un appel à orateur est une bonne chose)

Arrive quelque mois après l’appel à orateur pour Paris Web. Au début, j’étais parti sur une mini-intervention de 15 minutes, plus pour dire « faites-vous des projets en accessibilité, c’est cool et ça fait bien progresser ». Je discute avec une charmante femme qui se reconnaitra, qui écoute mon idée et l’expérience des plugins, et qui me sort cash « charité bien ordonnée commence par soi, c’est un sujet de 40 minutes que tu as là, pas une mini-intervention, et tu aurais dû faire pareil pour CSP l’année précédente », et elle m’a présenté mon idée complètement différemment. En retournant mon idée à l’envers, elle m’a juste ouvert les yeux sur le potentiel du sujet, j’étais loin du compte.

Une autre charmante femme me balancera même l’idée du titre (que je n’arrivais pas à trouver), comme quoi il ne faut pas hésiter à discuter de vos idées et à demander de l’aide pour les synthétiser. J’ai adoré et maudit ce titre un paquet de fois durant la préparation : un jour je le trouvais génial, un jour je n’arrivais pas à en faire façon. Bref, le plan sortira avec grand peine (et comment parler d’un retour d’expérience personnel sans trop parler de soi ?).

Finalement, je fus à peu près prêt, et pondre un transcript n’a peut-être pas été bon pour mon sommeil avant Paris Web, mais cela m’a aidé à clarifier certains points mal embouchés. Et comme plusieurs personnes ont vraiment apprécié l’initiative du transcript ;), finalement ce fut du temps bien utilisé. En plus, je voulais à tout prix annoncer le lancement du site Van11y, histoire de faire un bon pied de nez à mon propre sujet qui parlait d’accessibilité égo-centrée.

Côté conférence, je n’ai pas vu la vidéo, je sais que je me suis quelque peu emmêlé sur certaines parties, mais à priori, cela ne s’est pas trop vu. Finalement, au vu des retweets, le message « décomplexez-vous » semble avoir été reçu et apprécié.

Ce que j’ai discrètement abordé à la fin de ma conférence : 3 ans après la création de ces plugins, je suis en train d’en apprendre encore énormément sur le sujet, car Yvain Liechti et Jérémie Patonnier (entre autres) m’ont montré des pistes auxquelles je n’avais pas pensées. Pour de bon, décomplexez-vous de commencer petit, les améliorations viendront toutes seules après un certain temps.

Progression

Une participante m’a indiqué après en off que le petit graphe ci-dessus que j’ai mentionné durant ma conférence lui rappelait son domaine, qui pourtant n’avait rien à voir avec l’accessibilité. Content que le propos ait parlé plus loin que prévu.

Côté accessibilité, plusieurs idées m’ont été suggérées par plusieurs personnes, a11ykathon, communauté autour de ces plugins, etc. espérons que cela puisse aboutir.

Les lightning talks

Le staff de Paris Web m’avait proposé de reprendre l’animation des lightning talks, passage que je connaissais bien, pour y avoir participé (et méchamment flippé) deux fois. Je ne me voyais pas une seconde animer cela tout seul. Le premier nom qui m’est venu à l’esprit est Élie Sloim pour co-animer. Élie est mon parrain de Paris Web, et surtout, il m’amène des choses sur lesquelles je suis en général très mauvais (la planification, le côté réflexion, etc.) et on s’équilibre bien en général (même si ça fait parfois des étincelles entre nous :) ).

Vous avez peut-être assisté à l’événement ou vu le streaming… voici l’envers du décor, ce qu’on ne vous raconte pas.

Le staff nous avait fait part de son envie d’avoir la parité hommes/femmes (ce qui est tout à fait en accord avec nos valeurs). On passe en mode retro-planning à la rache, et on arrive assez facilement à des dates posées. En tant qu’ancien participant aux lightning talks, je pousse pour qu’on fasse ça le plus tôt possible, pour que les personnes retenues aient le temps de se préparer. Vous vous doutez bien que les embuches vont arriver !

Seul souci : les sujets peinent à arriver. On a bien quelques propositions (dont certaines assez cryptiques), mais ce n’est clairement pas assez. C’est là que le staff va s’arracher pour nous aider, en poussant sans arrêt pour que les gens envoient des sujets, quitte à même aller les chercher directement. Et le planning en question doit reculer de quelques jours pour qu’on s’en sorte). Finalement, nous arrivons à un nombre satisfaisant de propositions avec une certaine diversité. Rien que pour cela, merci à ceusses qui ont proposé !

Le choix sera cornélien, et nous nous arrêterons à 4 hommes et 4 femmes. Gag, deux proposants retenus n’auront pas confirmé leur inscription, hop, exit la parité, nous aurons 2 hommes de moins. Finalement, une improvisation de dernière minute nous amènera à 7 participants, dont 4 femmes.

Le temps étant compté sur place pour préparer un peu, on a rapidement cogité. Est-ce qu’on renouvelle le format ? Est-ce qu’on fait le show ? Quelles bêtises va-t-on improviser ? Est-ce qu’on fout la méga-pression aux retenus sur scène en bons enfoirés que nous pouvons être ? Etc.

On a même pensé à faire un lightning talk en forme de sketch pour présenter les lightning talks, en mode « Nico vous explique les effets d’un lightning talk » (le stress, etc.) et « Élie dédramatise »…

On avait eu pleins d’autres idées : montrer le chronomètre au public, etc. mais nous nous sommes quasi-effacés car les stars des lightning talks, ce sont les orateurs et les oratrices. Et ils et elles ne nous ont pas déçus : hormis un léger débordement pour le premier sujet, tous ont fini dans les temps, tous ont bien joué le jeu et tous se sont donnés, avec des sujets tous intéressants. Je vous invite à vous essayer à cet exercice si vous ne l’avez jamais fait, vous comprendrez pourquoi je les admire autant.

Il y a eu aussi le moment dit de « léger souci » avec la présentation de Sylvie, qui a catégoriquement refusé de marcher. Certes, si vous étiez dans le public, vous avez dû bien vous marrer, néanmoins, vu depuis la scène, c’était beaucoup plus stressant pour Sylvie et Élie. Je ne savais plus trop quoi faire non plus, entre faire le clown pour meubler alors que la situation est bien plus comique à côté, en rajouter… ou pas !

In fine, Élie qui disait « ne pas servir à grand chose » va improviser un mic-mac improbable pour que la présentation se passe (utiliser deux laptops, un pour présenter et un pour que Sylvie puisse utiliser sa plage braille, et passer les slides en même temps pour que l’illusion soit parfaite). Et Sylvie va assurer comme une bête pour faire passer son message, qui parlait des frustrations et joies du quotidien qu’elle rencontre, en tant qu’internaute aveugle. Magnifique sujet, merveilleusement démontré avant même… d’en parler. Le plus drôle, c’est que cette magnifique illustration de la loi de Murphy… va sûrement rester comme un grand moment ! Bravo Élie, tu as été grand, même si tu étais accroupi, caché entre deux laptops et à hauteur du chien-guide de Sylvie. :)

En tout cas, encore bravo Coralie, Willy, Enza, Vincent, Sylvie, Valérie et Goulven !

Dites-nous ce que vous souhaiteriez voir, que ça soit pour nous ou pour les suivants qui animeront ce moment, si vous avez des suggestions, faites-les remonter, au staff, à Élie ou à moi-même.

Perso, j’avais surtout envie d’aider de nouvelles têtes qui n’avaient jamais fait cet exercice. Pour ma part, comme c’est un exercice plutôt stressant, mais une fois qu’on l’a fait, on en est en général content et ça aide pour en faire d’autres ou pour prendre confiance en soi. J’espère vraiment que celles et ceux qui s’y sont risqués en seront pour leurs frais et inciteront d’autres à se lancer. Lancez-vous !

Paris Web 2016, retour du spectateur (le 06/10/2016)

J’ai eu le plaisir de participer à la onzième édition de Paris Web. Je ne résiste pas à l’envie de partager plusieurs retours, ce premier billet sera celui du simple spectateur.

L’édition de tous les dangers ?

Une fois n’est pas coutume, j’étais quelque peu inquiet avant cette édition. Un staff en plein renouvellement, une sur-multiplication des événements web, une édition 2015 qui avait fait très fort, je ne cache pas que j’étais inquiet.

Autant le dire de suite, je n’ai pas été déçu, et même bien au contraire.

De très bonnes surprises en conférence

Que ce soit les sujets qui tirent sur la société (Anatomie d’une désintoxication au Web sous surveillance, Organisez des cryptoparties !), sur le développement personnel (Libérée, délivrée… du syndrome de l’imposteur), sur la sécurité (Web security by design), de la technique pure (HTML5.1 + web platform APIs, Progressive Web Apps : le futur du web arrive) ou des sujets un peu surprise comme L’audio n’a pas dit son dernier mot ou La blockchain, quand l’individu sert au collectif… malgré lui, j’ai été servi.

D’autres sujets restent des valeurs sûres, comme sur l’internationalisation des sites, Vers l’infini et au delà des référentiels, etc.

Je note (enfin !) le retour en force de l’éco-conception via Éco-conception : mon site web au régime avec Frédéric Bordage, que je fus ravi de rencontrer enfin, même si ce fut fugace.

Après, il y a des sujets auxquels je n’ai pu assister, soit par impossibilité de dédoublement de ma personne, soit pour d’autres raisons. Mais je compte bien me rattraper avec les vidéos, car il y avait pléthore de sujets intéressants. Le moins qu’on puisse dire, c’est que ça a envoyé du lourd à tous les étages.

J’ai l’impression que cette année nous a mis un beau miroir en indiquant notre responsabilité au niveau même de la conception dans notre travail.

Quelques grosses claques dans la gueule

D’habitude, j’en prends plein la tronche aux conférences, et les ateliers sont la journée bonus où je suis les sujets de manière plus cool…

Pas cette année. J’en ai pris plein la tête aussi aux ateliers. Des promesses en JavaScript (qui m’ont en plus fait découvrir un paquet d’autres trucs), de Jérémie Patonnier qui me fait un mini-cours particulier très dense qui va servir mes plugins accessibles, en passant par un bon gros sujet sur Git qui m’a permis de décrotter beaucoup de choses biens obscures pour moi (merci Guillaume et Tûtie… heu Agnès !).

Le dernier atelier fut une source d’inspiration grâce à Emmanuelle et aux participants, un des plus beaux moments de diversité qu’il m’ait été donné de vivre. Observer Jean-Philippe communiquer, apprendre avec Emmanuelle/Sylvie, échanger tous ensemble… un bien beau moment.

Bref, j’avais déjà l’habitude avec Christophe Porteneuve et ses conférences sur ES2015, mais là, tous, vous m’avez donné au moins un an de trucs à apprendre et à digérer, bande de grands malades. En une journée, l’investissement est plutôt rentable. :)

Seule frustration : beaucoup, mais alors beaucoup de sujets intéressants en même temps. Au bas mot une dizaine m’intéressaient sur trois possibles. Appel du pied : écrivez des articles sur vos ateliers ou connexes à vos conférences, ça serait cool.

Bienveillance

Certaines éditions sont plus rigolotes, d’autres sont plus folles… cette année, j’ai eu l’impression de voir une forme de transmission, et ce même dans certains sujets comme D’imposteur à mentor ? et d’autres.

Autant sur certains sujets, j’ai été dans le rôle du vieux sage, autant sur de nombreux autres, j’ai été le débutant.

Ce qui me fait dire qu’on est tous le débutant d’un autre sur un sujet donné, et probablement le mentor d’un autre sur un autre sujet. Comme disait ce bon Einstein, tout est relatif. Pour ma part, j’ai été la cible d’énormément de bienveillance : « n’hésite pas à demander », « recontacte-moi si tu as besoin ». C’est bon de se sentir pas seul dans un monde de plus en plus individuel.

Les rencontres

Ne faites pas comme moi, ne soyez pas timide. Allez voir les gens, même s’ils semblent être des monuments pour vous. Perso, j’ai à peine osé glisser un mot à Léonie Watson (grande figure de l’accessibilité), tellement j’étais impressionné par son charisme. Soyez plus dégourdi que moi, vraiment.

Cet événement ne serait rien sans les gens qui y sont. J’ai juste un gros regret, ce fut bien trop court. J’ai eu l’impression que ces 3 jours ont duré à peine la moitié. Je n’ai pas pu discuter comme je l’aurai voulu avec la moitié des gens.

Quand je suis parti, j’en avais comme on dit vulgairement « gros sur la patate ». Quoi qu’il en soit, j’ai été ravi de partager ces moments très sympas.

Un événement à part

J’ai pu voir, comme le dit assez justement Christophe Andrieu dans un billet de retour sur cette édition, « le débat fait encore rage sur Twitter et par billets Medium rageurs interposés ». Qu’il fasse rage ailleurs, ce n’est pas l’image de Paris Web que je veux garder ici.

Cette édition a été à mes yeux une des plus inclusives, et j’ai ouï dire que le staff souhaitait encore faire mieux. Donc encourageons-le avec bienveillance. J’ai vu par exemple de nombreux orateurs/oratrices faire un transcript de leurs conférences, on va faire simple : je ne connais aucun événement où une telle émulation sur l’inclusivité se met en route. Ce n’est pas parfait, ce n’est pas toujours facile, on est parfois maladroit, c’est du boulot… mais ce n’est pas grave. Continuons. Le passé m’intéresse moins que l’avenir, et encore moins que les trolls.

Comme disait Jean-Philippe, je préfère sacrifier le buffet et manger un petit jambon-beurre plutôt que de sacrifier cet esprit.

Et enfin, ceux qui enterrent les conférences généralistes comme Paris Web ont été un peu vite en besogne. Une locomotive comme cet événement est forcément mis en difficulté, mais cette année, je lui trouve un aspect rutilant. Quoi qu’il en soit, ces fossoyeurs en seront pour leurs frais : je crois au contraire qu’on n’a jamais eu autant besoin de sortir le nez de nos spécialités et d’aller voir ce qui se raconte ailleurs. Nous en sortirons plus ouverts, plus inclusifs, plus empathiques et tout simplement… meilleurs.

Merci le staff

Maintenant, on va parler de ceux dont on ne parle pas assez : le staff. Je vais essayer de vous rappeler quand même l’essentiel, car on l’oublie un peu trop souvent. Ces bénévoles se donnent sans compter pendant une année et turbinent comme des malades. En plus, c’est presque une forme de masochisme, car ces personnes ne voient parfois pas le quart des conférences de l’événement pour lequel ils se donnent comme des tarés. C’est quand même hallucinant un tel niveau d’abnégation !

À la fin de la conférence, le staff s’incline devant nous pour nous remercier de notre présence, mais je crois qu’on fait faux-bond.

C’est à nous de nous incliner et de vous dire merci pour tout ce que vous faites. Je n’ai pas de mot assez fort pour vous dire à quel point cet événement a changé ma vie professionnelle depuis 6 ans et par ricochet ma vie personnelle. Alors, j’essaierai de le condenser en un simple « Merci ». Du fond du cœur.

Obtenir une bonne note sur Mozilla Observatory : HTTPS/CSP/SRI/CORS/HSTS/HPKP/etc. (le 08/09/2016)

Un projet très intéressant est sorti il y a peu nommé Mozilla Observatory. Cet outil permet de tester divers points concernant la sécurité des sites Web.

En grand joueur, je me suis amusé à essayer d’obtenir la meilleure note possible, qui selon le barème est de 135/100. Je suis arrivé à 130/100 sur le site de Röcssti, ce qui n’est déjà pas si mal.

Mise à jour du 27 Octobre 2016 : Röcssti étant désormais sur HSTS preload list, ce n’est plus 120/100 mais 125/100 au score.

Mise à jour du 22 Novembre 2016 : Röcssti envoyant un en-tête Referrer-Policy, ce n’est plus 125/100 mais 130/100 au score.

Résultats de Mozilla Observatory pour Röcssti

Comme cela a l’air d’intéresser pas mal de monde sur Twitter, je vais essayer d’expliquer au mieux ce qu’il faut faire pour faire péter le A+, et essayer de vulgariser tous ces noms barbares. :)

Autant le dire de suite : certains points peuvent être difficiles à obtenir selon vos conditions. Je ne suis pas non plus un expert sur chacun des points, vous m’excuserez d’avance le langage de béotien. Si un expert ou une experte en sécurité veut bien vulgariser ceux que je ne maitrise pas, il ou elle est le ou la bienvenu(e) !

Attention, bon nombre des choses que je présente ici vous font entrer dans le merveilleux monde du HTTPS, mais il sera très difficile voir quasi-impossible d’en sortir si vous déployez tout cela. Réfléchissez bien avant de déployer toute cette armada, car certains points ne s’annuleront vraiment pas facilement.

HTTPS/TLS

Le premier point sans lequel vous n’irez pas très loin est HTTPS. Curieusement, on croit que la sécurité vient du type de certificat (cela joue), mais en fait c’est aussi et surtout la configuration serveur qui va vous octroyer une bonne ou mauvaise note. Si le serveur est configuré pour utiliser des protocoles dépassés (et donc vulnérables), vos notes risquent de vite baisser. Par contre, si votre serveur ne supporte que les protocoles les plus récents, de vieux navigateurs pourront être exclus : si un agent utilisateur n’arrive pas à se mettre d’accord sur un protocole avec le serveur, fin de la discussion. C’est très bien expliqué dans « Le réveil de la crypto forte ». C’est un équilibre à trouver.

Si vous avez la maitrise de votre serveur, vous pouvez vous lancer à étudier cela. Personnellement, j’admets bien volontiers que la config serveur n’est pas mon fort. La documentation donnée par Mozilla est intéressante : Recommended Configurations for TLS. Je reconnais que ce point est délicat si on n’a pas de connaissances sur le sujet.

Si vous n’avez pas la main sur votre serveur, c’est là que votre hébergeur doit prendre le relai… et une initiative est tombée à point nommé : Let’s Encrypt. Cela vous évite déjà le fait de payer pour votre certificat, et l’outil est réputé plutôt simple. De ce côté-là, Röcssti étant hébergé chez Infomaniak (partenaire de Let’s Encrypt depuis un certain temps), cela a été très facile à gérer. Un simple clic dans l’admin permet d’installer un certificat, et ce dernier se renouvelle automatiquement.

Ajoutons à cela qu’en début d’année, je leur ai gentiment demandé d’améliorer leurs configurations… et ils l’ont fait !

Bref, n’hésitez pas à challenger vos hébergeurs, et à les féliciter quand ils jouent le jeu. Et n’oubliez pas que ce qui est fait pour vous bénéficie à tout le monde.

Pour tester votre configuration :

HTTP Strict Transport Security (HSTS) et redirections

Maintenant que votre site peut être servi en HTTPS, il va falloir… ne plus rien utiliser d’autre. Pour cela, vous pouvez commencer par mettre en place des redirections (via htaccess ou en-tête PHP). La logique de Mozilla Observatory est la suivante : le nom de domaine doit d’abord être redirigé vers le même en HTTPS (ce qui permettra d’utiliser HSTS correctement), et quoi qu’il arrive la destination finale doit être en HTTPS.

Là, rien de bien particulier. Cela peut se faire via htaccess par exemple :

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

La redirection renvoie vers la version sécurisée avec le rewrite flag permanent redirect, toutefois, cela est insuffisant. C’est là qu’entre en scène HTTP Strict Transport Security (HSTS). Selon Wikipédia, « HSTS est un mécanisme de politique de sécurité proposé pour HTTP », qui intime à l’agent utilisateur de remplacer automatiquement tous les liens non sécurisés par des liens sécurisés (on n’attend même plus la redirection côté serveur pour aller directement vers la version sécurisée). Voici l’en-tête en question chez moi :

Strict-Transport-Security: max-age=16000000; includeSubDomains; preload

Grosso modo, dès que l’agent utilisateur reçoit cet en-tête : il ne va plus utiliser autre chose qu’HTTPS durant plus de 6 mois (15768000s = 6 mois, donc un peu plus de 6 mois dans mon cas) et ce même si on utilise une URL non sécurisée (elle sera automatiquement « upgradée » vers HTTPS), les sous-domaines auront également le même traitement.

C’est pour cela que par exemple vous aurez l’impression chez Infomaniak que dès que vous utilisez une URL en HTTPS, HTTPS sera activé automatiquement pour tout le domaine. C’est le cas sur votre machine (qui a reçu l’en-tête HSTS), mais pas nécessairement partout si vous n’avez pas activé les redirections. Par contre, n’importe qui qui reçoit cet en-tête de votre site sera systématiquement renvoyé vers HTTPS.

La seule limite de cet en-tête surpuissant est la première connexion : tant qu’on ne l’a pas reçu, on n’est pas protégé. C’est là qu’un autre mécanisme entre en jeu pour compléter cela : on peut inscrire son nom de domaine sur une liste de pré-chargement HSTS preload list pour demander son inclusion dans cette liste. Cette liste est utilisée par les navigateurs modernes. En clair, si votre site est dans cette liste, les navigateurs utiliseront HTTPS de suite et quoi qu’il arrive.

Le preload dans l’en-tête au-dessus indique qu’on donne le consentement pour y être inclus. Pour Röcssti, j’ai déjà fait la demande, mais c’est toujours en attente, et d’après ce que j’ai lu, c’est plutôt long pour y être ajouté, et aussi long pour en être retiré. Un point de détail, ne mettez pas de point-virgule après preload, sinon HSTS preload list vous gueulera dessus. J’ai eu le probème avec l’en-tête mis par défaut chez Infomaniak, vous pouvez le surcharger en attendant que cela soit fixé (le bug a été remonté et a été fixé).

Mise à jour du 27 Octobre 2016 : Röcssti est désormais sur HSTS preload list, hop, 5 points de plus !

Je le redis, attention, bon nombre des choses énoncées ici vous font entrer dans le merveilleux monde du HTTPS, mais il sera très difficile voir quasi-impossible d’en sortir. Si vous avez le moindre doute qu’un jour vous deviez revenir à du HTTPS sans le « S », réfléchissez bien.

HTTP Public Key Pinning (HPKP)

Là on touche du doigt un point délicat à gérer si vous n’avez pas la main mise sur votre serveur et/ou si vous n’avez de bonnes compétences en la matière.

Grosso modo, l’idée de l’en-tête HPKP est de faire présenter une liste à la première connexion réussie (sur le principe joliment nommé TOFU, tout comme HSTS) représentant les clés de confiance par le serveur (via un hashage cryptographique, un SHA-256). Le navigateur mémorise cette liste. Aux prochaines connexions, les navigateurs ayant gardé en mémoire la liste des clés de confiance vont re-vérifier les clés publiques, et, si le certificat a été compromis, le navigateur refusera la connexion.

Voici des ressources sur le sujet :

Je le redis (et les ressources ci-dessus aussi) : faites vraiment gaffe avant de vous lancer là-dedans, procédez doucement en mode Public-Key-Pins-Report-Only, car il est très facile de se blackbouler soi-même si on ne fait pas attention. N’utilisez pas bêtement l’outil ci-dessus, ne foncez pas tête baissée, il est vraiment facile de se planter si on ne lit pas la documentation (j’insiste, mais vous ne pourrez pas dire que vous n’avez pas été prévenus).

Pour ma part, je n’ai pas encore tous les tenants et les aboutissants de cette techno sur mon hébergement, donc je préfère attendre et apprendre avant de m’y frotter. Peut-être la solution viendra de l’hébergeur directement, cela sera à voir.

Referrer-Policy

Comme son nom l’indique, Referrer-Policy indique votre politique en matière de Referrer. Essayons d’expliquer cela simplement.

Typiquement, si vous chargez une image http://www.foo.com/image.jpg sur un site depuis http://www.monsite.com/plop.htm, votre navigateur va envoyer une requête en indiquant dans les en-têtes que l’origine de la requête est Referer: http://www.monsite.com/plop.htm. C’est ce que vous voyez dans certains outils de logs qui vous disent par exemple que votre fichier a été affiché depuis « telle adresse ». Le principe est équivalent pour des liens, ce qui vous permet de savoir que « telle adresse » a un lien vers une page du vôtre (par exemple sous Google Analytics).

Le seul souci de cette valeur, c’est qu’elle peut transmettre à votre insu des informations sensibles. C’est là que cet en-tête entre en jeu, il permet de définir explicitement votre politique à ce propos. Voici les valeurs recommandées par Mozilla Observatory :

  • no-referrer : on n’envoie jamais l’en-tête
  • same-origin : on n’envoie l’en-tête que sur les requêtes ayant la même origine
  • strict-origin : on envoie l’en-tête à toutes les origines, mais seulement l’URL sans le chemin (on sait que cela vient de « tel site » mais sans en savoir plus)
  • strict-origin-when-cross-origin : on envoie l’en-tête complète sur la même origine, et seulement l’URL sans le chemin sur les autres origines

Pour ma part, j’ai utilisé la dernière valeur.

SubResource Integrity (SRI)

Là je vais être fainéant, je viens d’écrire un billet sur le sujet : À propos de SubResource integrity (SRI) et de traduire en français Subresource Integrity sur le MDN.

Grosso modo, le cas classique d’utilisation est la vérification de l’intégrité d’un fichier qu’on télécharge par exemple depuis un CDN. Dans mon cas, ce n’était pas obligatoire, néanmoins je me suis amusé à l’ajouter pour mon fichier JavaScript.

<script src="./layout/js/jquery-mini_1460217696.js"
async="async"
integrity="sha384-pQLaaAifGwNK5mu6Y9T+zVs8G05K8aE3JBHEIzwnzhmJ5QR1mNwR8/QtV4lRkrm2"></script>

Si le hash ne correspond plus (autrement dit si le fichier a été compromis), patatrac, le navigateur n’exécutera plus ce fichier JavaScript.

Cross-origin Resource Sharing (CORS)

CORS est un en-tête HTTP (encore un !) indiquant votre politique concernant les sites souhaitant accéder à vos ressources depuis un autre nom de domaine, via des méthodes comme XMLHttpRequest.

Pour vous donner un exemple, supposons que je mette en place un CDN proposant les versions minifiées de Röcssti. Il faudra que sur ce CDN, je spécifie qui a le droit d’accéder à ces fichiers. Supposons que j’autorise tout le monde, cela donnerait dans un htaccess :

Header set Access-Control-Allow-Origin "*"

Dans le billet précédent sur SubResource Integrity, j’ai fait mention de CORS pour utiliser l’outil SRI Hash Generator.

Bref, c’est bien de savoir que cela existe, mais CORS me semble un peu moins important que les autres points. Typiquement le genre de trucs que l’on peut ignorer jusqu’au jour où on s’y retrouve confronté (« mais pourquoi on n’arrive pas à accéder à mon API depuis tel autre site en AJAX ? »).

X-Content-Type-Options, X-Frame-Options, X-XSS-Protection

Ce sont d’autres en-têtes de sécurité, voici le détail pour chacun.

X-Content-Type-Options: nosniff doit être activé sur tous vos fichiers. Cela peut se faire via un htaccess :

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
</IfModule>

Cela évite aux navigateurs de jouer aux devinettes avec les types MIME de vos fichiers, et donc de risquer des failles XSS avec des fichiers malicieux. Si les types MIME ne sont pas bons, les navigateurs ne les exécuteront pas, point barre.

Header set X-Frame-Options "DENY" indique que vous interdisez que votre site soit embarqué dans des frame et autres iframe. Cela évite les attaques de type clickjacking, grosso modo qu’on embarque votre site dans un jeu de frames pour berner un utilisateur peu attentif. Si vous voulez gagner quelques points, il faut également doubler cette disposition en utilisant la directive frame-ancestors 'none'; dans vos directives CSP (voir plus bas).

X-XSS-Protection: 1; mode=block indique aux navigateurs disposant de certains filtres de protection pour certaines attaques XSS de – s’ils détectent ces attaques – bloquer la totalité du contenu. Toujours bon à activer.

Ces trois en-têtes sont assez simples à mettre en place, c’est pour cela que j’avais beaucoup poussé pour qu’ils soient tous pris comme des bonnes pratiques Opquast dans la version 3 du référentiel. Ils y sont, les voici :

Les cookies

Pensez à spécifier le paramètre secure et si le cookie n’a pas besoin d’être accédé par JavaScript, mettez le flag HttpOnly à true. Bien entendu, si vous pouvez vous passer des cookies, ou limiter leur champ d’action et leur durée de vie autant que possible, c’est préférable.

Content Security Policy (CSP)

Ah, Content Security Policy, c’est une de mes possibilités préférées depuis 2 ans. Un article de ma part devrait arriver d’ici quelque temps, donc je ne vais pas tout détailler.

Ajout du 13 Septembre : l’article vient de sortir sur Smashing Magazine, faites donc un tour sur Content Security Policy, Your Future Best Friend.

Revenons au principe : vous envoyez un en-tête CSP avec les directives que vous souhaitez voir exécutées.

Grosso modo, vous dites ce que vous allez autoriser sur votre front. Voici des ressources sur le sujet :

Pour avoir un bon score sur Mozilla Observatory :

  • Interdisez-vous les scripts 'unsafe-inline' (ce qui me semble être le minimum)
  • Mieux, n’autorisez pas les styles ou les scripts en ligne et pas de fonction eval (pas de 'unsafe-inline' ou 'unsafe-eval')
  • Plus restrictif, interdisez-vous default-src: 'self' et utilisez default-src: 'none', ce qui va vous forcer à définir chaque directive à la main.

Pour obtenir cela, tout dépend d’où vous partez. Si vous avez déjà implémenté des directives CSP sans 'unsafe-inline' ou 'unsafe-eval' pour les styles/scripts, vous avez fait le plus dur ! Passer à default-src: 'none' ne sera pas trop difficile, je l’ai fait en 15 minutes sur Röcssti. Par contre, si vous n’avez pas encore éliminé les styles en ligne et les scripts en ligne, le travail risque d’être plus long.

Pour vous donner un ordre d’idée, sur ce site dont le code est plutôt correct (mais ancien), j’ai eu un peu de travail pour éliminer quelques vieux cancrelats. Pas plus tard qu’hier, j’ai reçu environ 2 à 300 notifications d’erreurs CSP sur mon site (qui n’est pas monstrueusement fréquenté). Quelques mises à jour massives entre hier et aujourd’hui ont bien calmé le jeu, même si ce n’est pas totalement fini.

Par contre, sur une refonte, c’est en théorie beaucoup plus facile, vous pouvez même vous mettre de suite des garde-fous. Typiquement, c’est un long travail de propreté et d’orthogonalité dans votre code. Pour ma part, les plugins accessibles en sont une des parties les plus visibles. Sur des sites avec un existant plus compliqué, cela peut prendre plus de temps, dans ce cas, il vaudra mieux utiliser l’en-tête Content-Security-Policy-Report-Only avec un report-uri.

Détail, pensez bien à ajouter frame-ancestors 'none'; comme indiqué plus haut. CSP est également évoqué via une bonne pratique Opquast : le site propose un mécanisme de sécurité permettant de restreindre l’origine des contenus.

Conclusion

Ouf, si vous êtes arrivé au bout de ce billet fleuve, et moi aussi par la même occasion.

Quoi qu’il en soit, cet outil Mozilla Observatory arrive à point nommé, il met en exergue certains efforts à fournir pour proposer des sites toujours plus sûrs, et s’inscrit parfaitement dans une démarche de qualité et d’amélioration continue. Bien entendu, la sécurité de vos sites ne s’arrêtera pas là.

De mon expérience, je dois reconnaître que sans mon hébergeur actuel qui est sérieux et Let’s Encrypt, je n’aurais pas été capable d’obtenir ce A+ pour le site de Röcssti. Il y a un moment, il faut savoir reconnaître ses limites et déléguer, gérer des serveurs, c’est un métier, et je ne suis pas admin serveur non plus ! :)

Cela pose définitivement la question du sérieux des partenaires de vos sites. Mon ancien hébergeur dont j’étais plutôt content il y a quelques années – je viens de déménager ce site il y a quelques jours après des années chez eux – n’a pas voulu installer Let’s Encrypt (entre autres nombreuses conneries). La sanction est arrivée petit à petit : d’abord le site de Röcssti qui lui est passé sous le nez, ensuite celui de « Est-ce qu’on met en prod », après deux autres sites où j’avais besoin d’HTTPS, et enfin mon site personnel. Et ce n’est pas dit que je ne fasse pas déménager d’autres sites. Certes, ce sont quelques poissons noyés dans un océan, mais si tout le monde s’y met…

Ajoutons à cela qu’en tant que personnes averties, nous avons un devoir minimum d’encourager les services qui essaient de sortir du lot et qui nous écoutent. Ils ne sont malheureusement pas la majorité, parfois obtenir un simple en-tête X-Content-Type-Options: nosniff sur certains CDN est un chemin de croix… c’est tout le sens du billet que j’ai publié chez Openweb : « chers services tiers, et si vous vous associez à nous ? ».

Le second plus gros effort à fournir est pour CSP, hormis HPKP, le reste peut s’obtenir si vous êtes capable de paramétrer quelques en-têtes.

N’hésitez pas à partager vos découvertes ou vos connaissances/infos sur ces sujets, on apprendra tous et toutes les uns des autres !

À propos de SubResource integrity (SRI) (le 22/08/2016)

Au hasard de mes pérégrinations webesques du week-end, je suis tombé sur un utilitaire assez sympathique : SRI Hash Generator.

SRI Hash Generator

Subresource integrity, késaco ?

Cet utilitaire permet d’utiliser simplement SRI, qui est une spécification du W3C. Grosso modo, l’idée de SRI est simple : vérifier l’intégrité d’un fichier (CSS ou JavaScript par exemple) qu’on télécharge par exemple depuis un CDN. L’intégrité est faite à l’aide d’un hash (une fonction de hachage cryptographique en bon français), exemple :

<link rel="stylesheet" href="https://rocssti.net/downloads/rocssti-fr.css" integrity="sha384-7e5gIv4ZjCNGuNodi1FRsA2KxKWIp+ambTxw9xGhjpkTIJGneKrLp7j8jHBIYNtD" crossorigin="anonymous" />

Le navigateur qui lit ce genre d’appel va recalculer l’intégrité, et, si les valeurs coïncident, va exécuter le script ou la CSS. Si les valeurs ne coïncident pas, le navigateur refusera d’exécuter le script et/ou d’appliquer la CSS.

L’idée à la base de SRI est – si un CDN est compromis – d’empêcher que le vilain code malicieux qui a été inséré dans la bibliothèque que vous utilisez ne vienne se propager sur vos sites.

Exemples

Je me suis amusé à faire deux exemples simples avec Röcssti : chacun appelle Röcssti avec un hash différent (un bon et un bidonné) et essaie d’utiliser une classe de ce dernier.

Comme vous pouvez le voir dans le second cas, c’est radical si votre navigateur supporte SRI, même une pauvre classe n’est pas appliquée.

Peut-être l’aviez-vous vu par exemple sur le CDN de jQuery ?

<script src="https://code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script>

Bon à savoir

Si vous vouliez tester l’outil, pensez à autoriser CORS pour le fichier en question. Cela peut se faire via un .htaccess avec :

Header set Access-Control-Allow-Origin "*"

Côté support, c’est ok pour Firefox et Chrome, espérons que cela arrive vite pour les autres.

Pour en savoir plus sur SRI :

Ajout : piqué au vif de ne pas proposer le moindre lien francophone sur ce sujet, j’ai traduit la page sur le MDN en français : SRI, en français !

« De dieu, mon bon BDD » (le 15/06/2016)

Je me faisais la remarque récemment que, globalement, les réseaux sociaux et autres moteurs de recherches en savent de plus en plus sur nous et notre travail.

Il suffit de se faire « Googler » pour que sortent les infos d’où l’on travaille (via Microsoft LinkedIn © et apparentés), pour que l’on puisse connaitre une partie de notre réseau proche de collaborateurs, il suffit de tomber sur nos portfolios et autres sites personnels – même si le mien n’est pas très à jour, doux euphémisme – pour voir nos réalisations, etc.

Par contre, il y a un truc que je trouve dommage, en bon humaniste comique de service, très peu de choses filtrent sur l’ambiance qui règne au boulot. Il y a bien des recommandations très formelles où en général on loue les qualités professionnelles de la personne. Mais on ne sait rien de l’essentiel. Au mieux, quelques photos de croissants.

Vous savez, ces petites choses qui font tout le sel des relations entre collègues. Maintenant, vous saurez :

  • pourquoi le Jeudi, je commande les burgers en me faisant passer pour un certain Oscar : c’est un gag récurrent avec un ancien collègue (salut Oscar) ;
  • pourquoi toujours le Jeudi, je prends en photo un burger quand je ne suis pas au travail, et on se fait signe ainsi ;
  • pourquoi j’imitais – mal – E.T : parfait pour faire claquer de rire une ancienne collègue (salut Elsa) ;
  • qu’on pratique l’analyse politique de Rocco : Rocco commente une actualité façon service après-vente des émissions (Yo Fabien) ;
  • qu’on me surnommait « mon bon BDD » lors de mon ancien travail (hein mon bon Gérard, qui a relevé que je disais souvent l’expression « Brut De Décoffrage ») ;
  • qu’on s’appelait tous Jean-<mettez ici le prénom>, ce qui provoquait l’incompréhension des non-initiés ;
  • que je disais sans arrêt « Ach, leu gro mossieur t’abord » (12 travaux d’Astérix) en décrochant au téléphone quand c’était mon collègue ;
  • pourquoi on adorait lire les petites annonces du coeur du journal : un lisait, l’autre commentait (yo Dadou) ;
  • que quand mon collègue me disait « mais qu’il est con ce BDD », je lui répliquais au choix, soit la vanne de Coluche « et on se rend pas compte à quel point », soit la réplique de Léonard est un génie « Pas de flatteries, j’ai horreur de ça » ;
  • Etc.

Entres autres gags récurrents impossibles à retranscrire ici. Dommage que ces petits plaisirs ne ressortent que trop rarement.

Si vous êtes inspiré, racontez ça en commentaire ou sur votre site, ça vaut la peine d’être partagé, on est quand même des humains avant tout.

Retour sur Sud Web 2016 à Bordeaux (le 06/06/2016)

J’avais découvert Sud Web en 2012 – souvenez-vous, la fin du monde – et je n’avais malheureusement pas pu y retourner depuis, même si l’envie était toujours là. L’édition 2012 m’avait beaucoup plu et garde une place à part dans mes souvenirs, pour tout un tas de raisons qu’il serait trop long d’énumérer ici.

Alors quid de cette édition 2016 ?

Autant ne pas tourner autour du pot, ces moments font du bien.

Ils nous invitent à lever la tête de nos guidons à 104 touches et d’emmener nos réflexions un peu en dehors du temps. On se fait plaisir à découvrir de nouvelles choses, et surtout à constater que bien souvent, les mêmes problématiques que celles que nous rencontrons reviennent dans des domaines à priori éloignés des nôtres.

Et de remarquer que de la contrainte nait la créativité !

Côté conférences

Que ce soit les sujets longs ou les interventions plus courtes, toute la journée fut intéressante, autant dans la découverte de l’audio API que dans l’émotion à la lecture de « J’ai dix ans », autant dans « Mon pire client à 5 ans » qui a fait sourire le parent que dans le « Zero Waste Fashion » qui tape sur ma fibre recyclable, même si je ne connais rien à la couture. Mention spéciale au Bus Factor, qui m’a rappelé pourquoi j’ai décidé d’arrêter de sauver le monde depuis quelques années.

Les conférences donnaient l’impression de nous faire voyager à travers divers âges, et cette sensation était parfaitement accompagnée par Pauline Calmé entre les interventions. D’où une certaine prise de perspective, fort salutaire.

Côté élaboratoires

J’avais adoré le concept en 2012, et je crois que je l’aime toujours autant, sinon plus. Fonctionner à la bonne énergie des participants, c’est une énergie durable et propre, j’avais l’impression d’être dans un camp de vacances de gens passionnés.

En bon atteint du syndrome de l’anti-imposteur (merci Raphaël, je peux enfin mettre un mot sur ce qu’il m’arrive), je n’ai pas pu m’empêcher de proposer un petit atelier sur la survie en internationalisation des sites, complètement improvisé et bien sympathique, j’espère que les participants ont apprécié ce moment autant que moi. Encore une fois, le mot important était d’aller voir ailleurs pour voir les différences de culture, pour en apprécier toutes les saveurs, et se remettre en cause. C’est pour cela que je ne mens pas quand je dis que j’adore intégrer un site en Arabe ou en Japonais, même si ce n’est pas toujours facile… c’est enrichissant.

La seule frustration finale des élaboratoires est… que j’aurais bien rempilé pour une journée.

Côté gens

Bien entendu, ce genre d’événement n’est rien sans les gens qui le font, que ce soit le staff ou les participants.

De ce côté-là, j’ai autant été content de retrouver des visages bien connus que d’en rencontrer pleins de nouveaux. Les discussions en off étaient bien sympathiques, je me suis même surpris à ne participer à aucun élaboratoire durant un créneau de l’après-midi… juste pour le plaisir de discuter.

Des réflexions qui « m’interrogationnent »

Un très gros retard sur mon avion du retour me libèrera du temps pour achever la version 3 de Röcssti, et me forcera à être créatif, vu le côté limité de la connexion à l’aéroport. Si en une grosse journée, j’arrive à propulser ainsi un projet perso, peut-être me faudrait-il plus de temps libre au travail ? Cela m’interpelle.

La question de la transmission de la connaissance et de l’expérience reste importante, sinon nous sommes condamnés à revivre les mêmes problèmes, régulièrement. Pour cela, des idées intéressantes sont sorties, à voir jusqu’où elles iront.

Un point qui me fait très plaisir, les discussions de visu nous ont éloigné des postures qu’on affiche parfois bien malgré nous sur les réseaux sociaux, lesdites postures qui me fatiguent de plus en plus. La conscience des problèmes des silos (comme Medium) est très forte et est revenue plusieurs fois lors de discussions, j’avoue avoir apprécié l’idée du fanzinat des gens du web.

Je vois de plus en plus de gens qui veulent se lancer, essayer des conférences, des billets, etc., je leur dis un très clair : allez-y, proposez ! Intervenir en conférence n’a en fait rien à voir avec la façon dont le monde vous voit, même si cela peut effectiver changer, mais surtout va changer la façon… dont vous vous voyez vous-même.

Bref, j’aime bien ces valeurs et ces questions. Peut-être qu’à l’instar de Montaigne, je préfère des têtes bien faites que des têtes bien pleines ? Là, en matière de têtes bien faites, j’ai été servi, c’est le moins que je puisse dire.

En conclusion

Le maitre mot que je retiens de cette édition est la congruence (être en accord entre ses actions, ses sentiments, son être, etc.). Ce n’est pas toujours facile, mais c’est la seule voie pour durer.

Même si j’adore la thématique des super-héros, je crois que la thématique de cette année était le temps. Nos espaces-temps sont tous différents, et pourtant cela fonctionne quand on choisit de prendre le temps. J’apprécie de passer en moins d’une heure de vieux briscard du web à jeune débutant impétueux.

En tout cas, Sud Web a trouvé sa singularité, et cette parenthèse bordelaise fut fort appréciée et salvatrice. Bravo le staff, vous avez assuré en tous points, je vous remercie pour ces moments.

Les media-queries et les préférences utilisateurs (le 15/05/2016)

Maintenant que les avantages indéniables des unités relatives pour la taille de fonte ont été posés du point de vue du respect des paramètres utilisateur, voyons leurs effets sur les media-queries.

Vous avez peut-être déjà pu voir certains effets sur les pens précédents.

Rappelons un fait : les media-queries sont un système pour adapter les contenus d’un site selon les caractéristiques du visiteur (largeur d’écran, etc.). En général, l’idée est de les adapter au mieux en fonction du design et du contexte de l’utilisateur. Ce « truisme » (je rêvais de placer ce mot depuis longtemps) tombe sous le sens, mais vous allez voir qu’il prend une certaine dimension dans notre sujet.

Au fait, les media-queries se basent sur quoi ?

Cela va peut-être vous surprendre, mais les media-queries se basent sur les préférences utilisateur ! Si vous n’en êtes pas convaincu, je vous prie de faire cette expérience sur cet exemple : une taille de fonte en unité relative (em). Vous noterez que j’ai défini un breakpoint à 50em (qui va faire apparaitre un texte).

Voila l’expérience en question :

  • Mettez-vous en conditions « standard », soit avec une taille de fonte de 16px.
  • 50 fois 16 = 800 pixels. Redimensionnez votre fenêtre, vous verrez apparaitre le texte en-dessous de 800px.
  • Maintenant, augmentez votre taille de fonte par défaut à 32px.
  • 50 fois 32 = 1600 pixels. Redimensionnez votre fenêtre (si elle fait plus de 1600px de large), vous verrez apparaitre le texte en-dessous de 1600px.
  • Si comme moi, votre écran fait moins de 1600px de large, le texte sera déjà visible, et il va falloir agrandir votre fenêtre pour le faire disparaître.

Surprenant n’est-ce pas ?

Une erreur assez commune est de croire que les media-queries sont basées sur l’élément html. Ce n’est pas le cas, c’est bien basé uniquement sur les préférences utilisateur. Si vous doutez que l’élément html n’influe en rien, vous pouvez tester sur le pen suivant : une taille de fonte en em sans « reset ». Comme vous pourrez le voir, qu’il y ait un « reset » ou pas n’y change strictement rien, le comportement est le même.

Les paramètres utilisateurs, seulement la taille de fonte par défaut ?

C’est principalement la taille de fonte par défaut, mais… pas uniquement. L’utilisateur a deux autres possibilités : le zoom global et le zoom texte.

Le zoom global, comme son nom l’indique, effectue un zoom sur tous les éléments, vulgairement : tout le site grandit proportionnellement.

Le zoom texte, comme son nom l’indique aussi, n’effectue un zoom que sur le texte.

Il y a quelques subtilités en pratique entre ces deux zooms, nous allons voir lesquelles dans de futurs exemples. Si vous souhaitez tester sans tout faire à la main, je vous conseille d’utiliser une extension comme NoSquint, qui permet de tester directement avec l’un ou l’autre.

Alors, quid des media-queries en pixels ?

Comme dans le billet précédent, les pixels sont indépendants des préférences utilisateur. Ce qui suit va encore vous le prouver.

Si vous mettez en place une media-query en pixels, avec une taille de fonte par défaut à 16 ou 32px, elle ne s’appliquera que quand la fenêtre fera 800px. En quelque sorte, c’est l’écrasage « presque » ultime des préférences utilisateur.

Pour les zooms, c’est quelque peu différent. Comme le zoom global grossit tout (les préférences utilisateur comprises), la media-query s’appliquera quand le zoom sera à 200% (cela peut sembler assez intuitif). D’où le « presque » entre guillemets dans la phrase précédente.

Par contre, le zoom texte n’impactera pas le déclenchement de la média-query. Encore une fois, comme les pixels sont indépendants des préférences utilisateurs, cela semble plutôt logique.

Voir l’exemple sur Codepen : une taille de fonte en em avec une media-query en pixels.

Si vous regardez le pen tout en em, que ce soit en zoom texte ou en zoom global, la media-query s’appliquera à 200%.

Qu’en déduire pour nos sites ?

Une citation résume bien ce phénomène :

Designing for the Web is like visualizing a tesseract. We build experiences by manipulating their shadows. — Tim Brown

Traduction expresse : concevoir pour le Web est comme visualiser un tesseract (un cube à 4 dimensions), on construit une expérience en manipulant ses ombres (nous ne pouvons voir que 3 dimensions).

Vous pouvez tester sur le site de Röcssti. Le conteneur principal a été défini en em et les tailles de fonte ainsi que les media-queries ont été définies également en em.

En fait, travailler en em permet, sans le savoir, de travailler au mieux sur toutes les dimensions utilisateur (zoom, préférences de typo, zoom texte, etc.), sans même en avoir forcément conscience.

Si vous voyez la bibliothèque dans le film Interstellar, c’est exactement le même principe.

InterStellar

Vous avez le cas « standard » avec ses déclinaisons responsive. Imaginez-vous 3 ou 4 images sur une droite.

Maintenant, imaginons une troisième dimension, où l’on augmente la taille de fonte standard. On rajoute le zoom global ? Une dimension de plus.

Zoomez fortement sur le desktop ? Vous aurez l’adaptation mobile du cas « standard », sur un grand écran. Ayez une taille de fonte de base légèrement diminuée et un zoom texte léger ? Vous aurez peut-être le rendu tablette ou équivalent.

Et même parfois, vous aurez une singularité dans tout cela. Lisez Double breakpoint bug de Thomas Tzilliox, le cas où ces dimensions laissent un espace vide, en quelque sorte. :)

La (sur)vie avec les em

Le guide de survie avec les em du billet précédent n’était pas complet.

Après, je crée le site dans les conditions « standards », et ô miracle, changer la taille de fonte par défaut ne cassera rien.

C’est même le contraire, je ne casse rien mais je construis en même temps dans d’autres dimensions : les breakpoints que je définis pour le mobile dans le cas standard vont resservir pour toutes les variétés de réglages selon les périphériques ou les utilisateurs.

C’est quand même extraordinaire quand on y pense, car le fait d’adapter au mieux les contenus pour le cas « standard » (en gros, en connaissant sa division par 16), vous fait travailler en même temps pour de forts zooms sur desktop.

Pour de bon que si vous aviez le doute de travailler le responsive uniquement d’après les contenus plutôt que de viser des résolutions fixes, cela va achever d’enterrer ce doute.

En tout cas, j’espère que vous voyez mieux le sens de « lâcher prise sans perdre le contrôle » : vous n’avez pas prise sur les media-queries, vu qu’elles sont basées sur les préférences utilisateurs… sur lesquelles vous n’avez pas de prise. Et pourtant, vous pouvez faire au mieux, même pour un cas que vous n’imaginez pas.

Les em/rem avec les préférences utilisateurs (le 14/05/2016)

Je suis surpris de voir que les unités relatives ne font pas encore consensus dans la communauté Web, notamment sur la typographie. Nicolas Hoizey avait fait une chouette conférence sur le sujet, que je vous invite à aller voir ou revoir : Un petit pas pour l’em, un grand pas pour le Web.

Dans sa grande mansuétude, il tue également un vieux troll qui dit que la taille de fonte par défaut est toujours de 16px : People don’t change the default 16px font size in their browser. Je résume : c’est souvent le cas, mais pas toujours.

Un autre point quand vous hésitez à choisir une unité, la question à vous poser est : de quoi dépend réellement la valeur que je veux mettre, de quel contexte ? (gardez toujours cela à l’esprit)

Maintenant que c’est posé, avançons ! Suite à un échange sur Twitter hier après-midi, les notions de respect des préférences utilisateurs ne semblent toujours pas claires, tout comme le comportement des media-queries. Alors décortiquons le tout avec des exemples très simples.

Notes : si vous souhaitez tester les exemples que je vais donner, sous Firefox, il faut aller dans Options, Contenus, et là vous pourrez changer votre taille de fonte par défaut. Afin de simplifier les exemples, je les ferai avec une taille de fonte par défaut de 16px et 32px, j’ai choisi le double juste pour des raisons de simplicité d’explication. Je ne redonnerai pas tout le code à chaque fois, il y aura des pens pour cela.

Taille de fonte sur Firefox

Une taille de fonte par défaut en pixels

html { font-size: 10px; }

Pourquoi dit-on que c’est mal ? Voici la raison : que ma taille de texte par défaut soit de 16px, 32px ou n’importe quoi, l’utilisation des pixels fera que le site imposera ses valeurs au visiteur. Le texte que j’ai paramétré sera affiché en 16px dans tous les cas.

C’est quand même gênant si j’ai paramétré mon navigateur pour qu’il affiche le texte plus grand ou plus petit par défaut. Ne le faites pas pour la typo, à aucun endroit. Vraiment pas.

Voir l’exemple sur Codepen : une taille de fonte par défaut en pixels.

Une taille de fonte par défaut en unités relatives

Pour cet exemple, je n’ai pas utilisé de pixels, mais des unités relatives. Rappelons que les em sont fonction de la taille de fonte de leur parent, et les rem (root-em) sont fonction de la taille de fonte de l’élément racine, soit html.

Avec une taille de fonte par défaut à 16px, pas de souci, le texte est bien affiché en 16px et le titre h1 en 32px.

Si je mets ma taille de fonte par défaut à 32px dans mon navigateur, le texte sera donc bien affiché en 32px et le titre h1 en 64px. Là, les valeurs utilisées respectent les préférences de l’utilisateur.

Voir l’exemple sur Codepen : une taille de fonte en unité relative (em).

Avec l’unité rem, le résultat est exactement le même, les préférences utilisateur sont respectées. Voir une taille de fonte en unité relative (rem).

Ok, en relatif, mais avec ou sans « reset » ?

Une pratique assez courante est d’utiliser ce genre de propriété sur l’élément html :

html { font-size: 62.5%; }

À quoi cela sert ? C’est une simple astuce pour se simplifier le calcul (que moi-même j’utilise dans Röcssti). En partant de l’idée que la taille « standard » est de 16px, 62,5% de ces 16px donneront 10px à l’affichage.

Mais alors, on ne respecte plus les préférences utilisateur ???

Bien sûr que si, on les respecte. C’est pour cela que je mets « reset » entre guillemets. Comme c’est un chiffre rond, cela simplifie juste les calculs, surtout pour l’unité rem. Avec ce « reset », 10px équivalent en permanence à 1rem. 1.4rem donne… un affichage de 14px, et ce où que l’on soit dans le document (sur le body ou ailleurs).

Si vous n’êtes pas convaincu, testez une taille de fonte en em sans « reset » ou une taille de fonte en rem sans « reset ». Les préférences utilisateur sont respectées et le résultat est le même.

Bref, avec ou sans « reset » et en em ou en rem, le résultat est le même, seules quelques valeurs changent. C’est juste un peu de gymnastique intellectuelle, à votre convenance ! Si vous préférez que 1rem soit équivalent à 10px pour vos calculs ou qu’il soit égal à « une fois la taille de fonte par défaut », c’est à votre convenance, je ne suis pas sectaire.

Le seul souci de ce « reset » est sous Internet Explorer (du 9 au 11). Une bête erreur d’arrondi peut fausser les valeurs affichées des fontes, cela se fixe ainsi :

html { 
font-size: 62.5%;
font-size: calc(1em * 0.625); /* fix */
}

Bref, pas dramatique.

Pourquoi les gens n’aiment pas le « reset » ?

En fait, c’est souvent à cause d’un oubli : le « reset » est appliqué sur html mais il n’y a pas de taille par défaut sur le body. Du coup, le moindre oubli fait qu’on se retrouve avec une taille de fonte affichée à 10px, ce qui est rikiki et souvent très disgracieux au milieu d’un beau site.

Des em ou des rem ?

Cela dépend de votre contexte. Même si je suis un très gros utilisateur des em, je les utilise surtout parce que mon contexte s’y prête bien. Ajoutons à cela que les em fonctionnent partout, même sur les vieux Internet Explorer !

Les em nécessitent :

  • soit un minimum de conventions posées,
  • soit une certaine vision d’ensemble.

Et ce afin de pouvoir gérer l’héritage de la taille de fonte du parent.

Si vous avez une équipe éclatée sans aucune vision d’ensemble sur la CSS, avec des modules développés de manière complètement autarcique, les rem seront sûrement plus faciles à gérer, vous n’aurez pas de souci d’héritage. Les rem ont cependant une petite faiblesse, ils ne sont pas du tout supportés sur Internet Explorer 8 et inférieurs.

Sur des projets plus simples à cadrer ou avec des guidelines bien posées, les em se gèrent sans trop de souci.

Après, on voit souvent cette notion d’héritage dans les em comme quelque chose de compliqué, mais cela peut aussi être une force. Un module défini en em, si l’on doit le réutiliser dans une zone différente où la taille de fonte sera plus grande, évoluera tout naturellement avec son contexte. Par exemple, un helper genre margin-top: 1em s’adaptera où qu’il soit.

Croyez-moi sur parole, dans certains cas comme pour l’obtention et la conservation d’un rythme vertical, c’est très utile. Et dites vous que vos espacements s’adapteront en fonction des préférences utilisateur.

Mon guide de survie avec les em

Quand je commence une intégration, la première question que je pose est la taille du texte courant. Car quasiment tout va dépendre de cela.

Une fois que je la connais, j’applique cette valeur sur le body (avec ou sans « reset » sur html).

Ensuite, je calcule les tailles pour les Hx et autres classes comme .big, etc. (automatisé par un pré-processeur ou via le Röcssti-Builder).

Après, je crée le site dans les conditions « standards », et ô miracle, changer la taille de fonte par défaut ne cassera rien.

Contrairement à ce que beaucoup de gens croient, appliquer une classe qui modifie la taille à un élément dont la taille est également directement modifiée en em ne pose pas de souci. Par exemple, un h1 class="h2" sera bien à la taille de la classe .h2 (vu que c’est le parent qui sert de référence). Les soucis ne sont pas là !

Par contre, les em sont compliqués quand on commence à imbriquer les classes modifiant les tailles, genre un span class="big" dans un h2.

En pratique, j’évite les imbrications hasardeuses, pas ou peu de souci d’héritage et tout se passe comme un charme.

Même mes collègues qui étaient – doux euphémisme – très réfractaires aux em s’y sont plutôt bien habitués, donc c’est bien preuve que c’est possible. :)

Alors on doit jeter les pixels aux oubliettes ?

Du calme ! Et je n’ai pas dit ça ! :)

Oui, jetez-les pour la typo. Utilisez les em, et si c’est compliqué, foncez sur les rem. Mais quoi qu’on en dise, les pixels sont bien pratiques pour discuter avec un graphiste ou un client (qui n’a aucune notion des unités relatives). C’est une unité plutôt intuitive – quoique cela se discute dès qu’on commence à discuter écran à haute densité de pixels – et que tout le monde comprend. En gros, parler en pixels est une simplicité pour l’esprit.

L’autre cas problématique est lié aux arrondis, notamment sous Chrome/Webkit. Si vous avez un sprite avec diverses images et que vous dimensionnez en em l’élément dans lequel l’image va s’afficher, des fois les arrondis sont foireux et même si la valeur est bien censée donner 15px, il peut y avoir des dépassements, catastrophique si les images dans le sprite sont serrées. Bref, dans ce cas, autant utiliser les pixels.

Idem pour les images. Ceci dit, si l’on garde la question du début « de quoi dépend réellement la valeur que je veux mettre, de quel contexte », pour une image, la réponse est tout simplement : d’elle-même. À méditer.

Et pour les media-queries ?

Je m’aperçois que ce billet est déjà bien long, je vous propose d’y revenir dans un prochain billet. N’hésitez pas à tester et à réagir.

Ajout : suite de ce billet dans Les media-queries et les préférences utilisateurs.

Grogne sur l’accessibilité (le 29/04/2016)

Un monstre coup de grogne d’un développeur concernant l’accessibilité a fait un bruit certain, la newsletter Opquast en a parlé et je vais rebondir dessus.

Remettons-tous dans l’ordre. Un article explique certains problèmes des design patterns sur des utilisateurs clavier. Voici l’article en question : Danger! ARIA tabs.

Je passe sur le côté maladroit de certaines formulations et volontairement trollesque de cet article. Je passe aussi sur le code donné en exemple, qui me semble insuffisant (comme indiqué dans ce commentaire).

Il y a par contre un problème réel (entre autres) qui mérite d’en parler (que je n’avais pas compris au début) : l’utilisateur clavier n’est pas habitué à ce qu’on lui propose ces design patterns, et souvent il est perdu (par exemple, il ne sait pas qu’il peut utiliser les flèches gauche et droite pour afficher les onglets). Ça c’est un souci réel.

Et en guise de propos, le classique « ça dépend ». Sauf que le coup de grogne mentionné plus haut est monté, et je ne suis pas loin de donner bien raison à ce développeur. Étant moi-même impliqué à développer des plugins accessibles que je déploie massivement (à peu près tous les sites que je fais les utilisent), je ne peux clairement pas entendre un « ah bin, ça dépend, et il va falloir jeter ce que vous avez fait ». Même pas en rêve.

Là je serais du genre à répondre : « sérieux les gamins, vous êtes gentils, mais je respecte vos standards, j’y contribue, j’ai des dizaines et des dizaines de sites en prod, j’ai pas le temps ni même la possibilité de faire dans le détail, bordel ! » (et encore, je suis resté poli). Pire, ce genre de naufrage peut ruiner une chiée d’efforts et de motivation. La cause de l’accessibilité n’a me semble-t-il pas besoin de ça.

Par contre, ce que je peux entendre et je regrette de ne pas l’avoir lu, c’est « continuons avec ces standards, mais améliorons-les en pratique, soyons constructifs », ce qu’Aurélien Lévy (qui m’aide beaucoup sur ces plugins) fait déjà très bien, régulièrement, on va plus loin que ce que les standards proposent pour faire mieux en pratique. On sait très bien que ce n’est pas parfait, mais il vaut mieux faire quelque chose que rien du tout.

Franchement, ne serait-il pas plus simple de partir de ces standards (qui me semblent plutôt bons), de les améliorer et d’éduquer ou d’aider l’utilisateur ?

CSS et sa légendaire facilité (le 06/04/2016)

Des fois, CSS a l’art de m’amuser. La difficulté n’est pas toujours là où l’on croit.

Je travaille actuellement sur un template monstrueusement compliqué, et au milieu de plein de trucs bien retors, j’ai une chose simple à faire. Faire un lien précédé d’un « > ». Enfin, je dis « simple », à vous de juger.

Le site en question a supprimé le soulignement des liens par défaut et l’active quand on les survole ou quand on a le focus clavier dessus. Rien de bien extraordinaire.

Je me dis qu’un pseudo-élément before suffira. Très logiquement, je fais ainsi :

.arrow-left:before {
content: '>\a0';
speak: none;
}

Petit souci, quand on survole le lien, le soulignement apparait en-dessous du « > ». Pas de souci, je me dis que je vais l’annuler. Sauf que cela ne marche pas, la propriété du pseudo-élément est héritée du lien. Sauuuuuuuuuuf…

En cherchant un peu, je trouve une solution dans la spécification CSS 2.1 de text-decoration (oui rien que cela).

Note that text decorations are not propagated to floating and absolutely positioned descendants, nor to the contents of atomic inline-level descendants such as inline blocks and inline tables.

Le soulignement n’est pas propagé si le pseudo-élément est de type inline-block. Soit.

.arrow-left:before {
content: '>\a0';
display: inline-block;
speak: none;
}

Sauvé ! Cela marche partout. Sauuuuuuuuuuf…

Sous Internet Explorer 8… jusqu’au 11 compris. C’est un bug. En continuant de chercher, je trouve une solution bizarre, mais fonctionnelle.

.arrow-left:before {
content: '>\a0';
text-decoration: underline;
display: inline-block;
speak: none;
}
/* IE… */
.arrow-left:before,
.arrow-left:focus:before,
.arrow-left:hover:before,
.arrow-left:active:before {
text-decoration: none;
}

En gros, tout redéfinir explicitement pour ré-écraser le tout après. Là notre ami Internet Explorer ne bronche plus. Voici un pen qui montre le tout.

Qui a dit que CSS était simple ? Hé bien, qu’il/elle sorte. :)

Ces articles ont été écrits par Nicolas Hoffmann.

Lister toutes les autres news
(long à charger si connexion lente)
Ce site est la propriété de Nicolas Hoffmann. Tous droits réservés.