Premier Mozilla Doc Sprint
Je me suis laissé embarquer dans un Mozilla Doc Sprint par David Bruant. C'était un samedi, pluvieux de surcroît. Une motivation liée à l'apprentissage et à la découverte de la contribution. C'est quoi contribuer ? Il faut être qui pour contribuer ? Et savoir quoi, surtout.
Documenter c'est pas sexy
À observer la réaction des gens qui se voyaient présenter l'évènement, clairement, ça ne les attirait pas.
Je ne sais pas encore si c'est lié à notre époque (consommer est plus facile que créer — crafter) ou à notre espèce (j'imagine le mec qui a inventé la roue — et le premier homo sapiens qui aurait marketé cette révolution au sein de l'espèce, le premier à vouloir transmettre le savoir et le premier à vouloir améliorer collectivement cet outil — j'ai l'impression que c'est ça qu'on est en train de faire en modifiant une page de wiki sur MDN).
Pour l'instant dire "on fait un apéro et on parle de " réunit plus de monde que "on documente ". Peut-être est-ce le même fossé entre "développer" et "écrire des tests et développer". Le gain se situe après. Après avoir fait l'effort de. Y'a des ponts à construire, et de la communication à trouver et effectuer pour inciter les gens à passer d'une rive à l'autre.
Bref, revenons à nos moutons.
Table de compatibilité automatisée
Un des axes de travail est de renseigner les tables de compatibilité. C'est un travail effectué à la main, essentiellement en se basant sur caniuse.com (mais pas que). Premier réflexe : me dire qu'on peut automatiser la génération des tables, que c'est facile, et que ça peut se scripter avec CasperJS.
David m'indique alors un cas plus complexe de table, celle de la balise HTML a.
Au passage, je découvre 3 choses :
- tout caniuse.com se base sur des fichiers JSON hébergés sur Github (CasperJS devient moins pertinent) ;
-
href="#top"(voir plus bas) ; - des conditions de compatibilité affichées ne viennent pas forcément de caniuse.com.
Le plus gênant est ce dernier point. Il faudrait que le générateur de table de compatibilité ne soit pas un référentiel de données et soit capable de :
- prendre en compte si une table existe ou non pour une fonctionnalité documentée ;
- pour un test caniuse.com : prendre en compte si la donnée a changé ou non (et choisir de l'actualiser) ;
- pour un test manuel : le maintenir en l'état ;
- combiner les deux derniers points pour avoir quelque chose de vraiment pratique ;
- dans un premier temps se contenter de générer du HTML à copier/coller à la main ;
- dans un deuxième temps passer par l'API PUT de MDN pour automatiser l'écriture des tables de compatibilité.
Le constat est qu'il faudrait bien plus que la journée pour faire quelque chose d'efficace et vraiment fonctionnel. La bonne idée tombe un peu à l'eau ; j'aurais aimé avoir quelque chose d'utile/utilisable dans l'après-midi.
href=#top
Par ricochet, je commence à chercher l'origine de la compatibilité avec href="#top". C'est supporté depuis Firefox 10 (janvier 2012) donc autant dire que c'était récent.
L'histoire remonte à … 2001, pour une sombre histoire de compatibilité avec … Internet Explorer 4. Bug réouvert en 2011 après avoir été rencontré dans Firefox Mobile. Époque à laquelle le "Remonter en haut de page" revient à la mode puisque pratique sur mobile.
Puis de constater que ce comportement a été standardisé dans HTML5 (voir le point 6). Ça me fait penser à l'histoire de <main>, implémenté après une observation des usages (et peut-être à cause de la faible popularité d'ARIA ?).
Une bonne heure de passée juste pour naviguer, lire et rajouter … un lien hypertexte dans MDN.
load et beforeunload
beforeunload, ça remonte (déjà) à 2008, dans un résumé hebdomadaire du travail sur HTML5.
Je voulais en savoir plus à propos du comportement de ces deux évènements, leurs différences, quel était l'état du document et ce qu'on pouvait en faire. L'algorithme à implémenter est disponible dans la spécification HTML5. L'occasion de découvrir que le navigateur dispose aussi d'une EventLoop. De me demander ce qu'est le salvageable state d'un Document.
Mais aussi de devoir écrire du code pour comprendre et m'assurer du workflow dans la vraie vie (merci JSBin & cie !).
Au final, une après-midi aura été nécessaire pour compléter 4 pages dans MDN :
Conclusion
Cette journée m'a permis d'infirmer l'assertion qui consiste à dire qu'il faut savoir pour documenter.
Il suffit juste de s'intéresser à un sujet. Il peut être technique ou non. Il peut être en anglais ou non. Il peut être bas niveau ou non. Et comme pour beaucoup de choses, on se lance puis on voit bien comment ça se passe.
Notre bagage de connaissances déjà existant ? Il aide à comprendre et décrypter plus rapidement ce que l'on découvre.
Je vois ce genre d'évènements comme un Code Retreat : une occasion de sortir de sa zone de confort (ou de l'exploiter) afin d'accroitre ses connaissances et sa compréhension des technologies Web. Et d'aider à améliorer la base documentaire par la même occasion.
