da scritch net works - Webdev

N2HDF 2026 Toulouse

Da Scritch — 2026-06-07T19:20:00+02:00

Comment s'est passée la N2HDF 2026 édition Toulouse au sein du Tetalab ? Retrouvez les supports et enregistrements.
Webdev

Le Samedi 30 Mai 2026 avait lieu l'édition toulousaine de la N2HDF 2026.

Nothing 2 Hide est une association dont le but est de protéger l’information par la fourniture d'outils face aux menaces et la surveillance numarique, la lutte contre la censure, des formations et l'éducaiton au médias.

Suite à différents événements publics qu'ils ont organisés, ils ont eu l'idée de proposer à de multiples associations disséminées sur la France d'organiser le même week-end des ateliers, conférences, tables rondes, etc… sous le nom N2HDF (Decentralized Festival)

Le Tetalab eu l'honneur d'avoir à organiser l'événement sur Toulouse, qui s'estdéroulé au Topic le samedi 30 dans l'après-midi.

Voici le programme, les supports et enregistremets

Conférence « Le Bluetooth a-t-il définitivement remplacé la prise casque de votre smartphone ? »
Et si oui, pourquoi ? Analysons une suite de décision qui n'est pas toujours en faveur de votre vie privée et de votre porte-monnaie. Et pourquoi ça serait bien de militer auprès de certaines marques pour qu'il remettent la prise casque.

Support de la présentation (utilisez la flèche → ou swiper sur écran tactile pour avancer)

Conférence « Readeck, un logiciel libre d'archivage de contenu en ligne. »
Rien n'est éternel et un marque-page sur navigateur suit la même logique: un beau jour, vous allez cliquer pour revisiter un site ou article intéressant et là c'est le drame. Le domaine a été vendu, l'auteur n'avait plus envie de le maintenir, 404 Not Found, le contenu a changé été censuré...

conférence « Bien se servir des VPN ».
Pourquoi un VPN, c'est très pratique, surtout si vous êtes youtubeur professionnel. Pourquoi les VPN ont été créés, quelle est leur utilité réelle, quelles sont leurs limites techniques, pourquoi l'usage des VPN commerciaux par des particuliers n'est pas franchement utile, en quoi mentent les opérateurs de VPN grand-public, et quelles sont les meilleures alternatives.

Support au format PDF

conférence « Vraiment rien à cacher ? ».
Nous avons tous entendu cet argument stupide, C'est pas grave, moi, je n'ai rien à cacher. Partons du principe que c'est le cas et déconstruisons point par point tout ce qui pose un problème dans cette affirmation.

Support au format .odp, lisible avec Libre Office

Table ronde : Échanges autour des pratiques et des enjeux de l'autodéfense numérique par les intervenants de la journée.

À noter que les enregistrements ont été édités afin de préserver l'anonymat des membres du public.

cpu-audio.js enfin en 7.0

Da Scritch — 2021-04-28T06:51:00+02:00

Ouais, j'avais d'autres billets techniques sur le même sujet, mais là, j'ai avancé sur le code plutôt que l'explication de texte ;)
Webdev

Commençons par un exemple avec une émission sur le son :

(S'il n'a pas encore démarré, un peu de patience, sinon le lecteur reste utilisable, c'est de la dégradation élégante)

Cela faisait un peu de temps que je n'avais pas donné de nouvelles de mon lecteur audio. Alors que pourtant j'avais écrit toute une série de billets à son sujet :

cpu-audio.js vient de passer en version 7.0. Le player audio de l'émission CPU en WebComponent a été revu en profondeur, avec moult corrections et notamment l'arrivée des thèmes graphiques en plus du système simple de configuration

L'idée d'origine de cette bibliothèque était de pouvoir donner une URL qui puisse pointer à un instant précis d'un audio dans une page web. Car le standard existe mais n'est pas implémenté par les principaux navigateurs. Or il est bien utile pour les émissions de 5h30. Et quitte à le faire, le faire avec un minimum de dépendances et un maximum de souplesse.

Par la suite, les principales API sont arrivées pour enfin stabiliser les Web-components, ce qi m'a permis d'enfin réaliser une bibliothèque javascript isolée, transportable, agnostique, petite (sous les 50ko) et toujours en vanilla.

J'ai donc déjà longuement raconté sur ce blog les démarches de conception qui m'ont permis d'y arriver et de le faire dans la licence GPL.

J'avais besoin de refondre complètement la bibliothèque pour la rendre plus maintenable, plus facile aussi pour que n'importe quel dev ou intégrateur front s'en empare. Il est ainsi possible de créer des thèmes graphiques sans toucher au code JS, ce dernier ayant même une tolérance d'implémentation.

Il reste toujours les idées qu'on avait jeté au début, que je ne réaliserai jamais seul mais que j'espère donner une base saine pour construire :

des thèmes plus aboutis et jolis
une WebExtension pour lire n'importe quel audio tranquillement
créer des playlist décentralisées pour montrer que le web est beau car remixable
créer des commentaires à la SoundCloud/MixCloud mais décentralisés
des outils encore plus poussés que l'éditeur de chapitre
ajouter un spectrogramme via add-on
Étendre pour l'utiliser aussi sur de la vidéo

Et n'hésitez pas à me contacter si vous avez besoin d'aide.

J'ai encore beaucoup de choses à dire, mais surtout beaucoup à remercier ; d'abord toute l'équipe de l'émission et ceux de la radio qui font qu'on reste très impertinents depuis 1981. Avec une pensée spéciale pour le Tetalab et Mixart Myrys où nous avions enregistré de nombreuses émissions et dans une panade noire.

Ensuite ceux qui m'ont aidé spécialement sur ce projet de code :

Thomas Parisot pour le standard Media Fragment, qui permet à ce player de créer des liens hypertextes temporels ;
Loïc Gerbaud pour des corrections ;
Guillaume Lemoine qui m'a bien aidé avec du prêt de matos au début ;
Benoît Salles et Michel Poulain pour les tests, Gabi Boyer pour m'avoir passé un iPhone SE, téléphone qui est certes toujours mis à jour, mais Apple n'arrive vraiment pas à tenir Safari aux standards.
@mariejulien pour m'avoir donné envie de ré-écrire un CONTRIBUTING.md plus accessible
Christophe Porteneuve de Delicious Insights, un ami et un formateur JS qui m'a donné un magistral coup de pied au cul. Ses formations JS sont de sérieux cadeaux pour les devs webs.
scombat qui a écrit une intégration minimale de cpu-audio.js dans React
Éric Daspet pour ses précieuses remarques sur la documentation

N'hésitez pas à le faire connaitre, si vous avez un projet audio dans le web qui nécessite un lecteur.

Deux couleurs bizarres en CSS

Da Scritch — 2019-11-13T13:41:00+01:00

Une bête combinaison qui ne me permettent pas de faire un chouette aspect dans un cas très précis. Et vous allez même pouvoir vous amuser avec pour comprendre les limites de certaines propriétés CSS magiques
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de sa version 6.

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web (sur la version 5)
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

Je vous remets le player, dans la dernière version de dev. Sinon, ⇓ sautez ⇓ directement ⇓ au chapitre suivant ⇓

Pour lire ce billet, il est conseiller d'aller sur mon site dascritch.net. Si vous lisez ce texte, c'est que probablement vous n'y êtes pas.

Comment replacer un sujet tiers rien à voir avec le billet sous prétexte d'illustration d'exemple…

La Couleur tombée du DOM

Je vais parler non pas de couleurs interdites (quel nom de film d'horreur génial !) comme le Rouge Surbrillant, le Jaune Bleuté, ou l'Orange Hyperbolique, mais de deux définitions volontairement manquantes dans les CSS. Or, comme mon player a un aspect totalement paramétrable par les utilisateurs via la CSS, lesdits utilisateurs pourraient tenter de faire un effet qui sera systématiquement en échec.

Allez, cadeau ! trois couleurs interdites (impossibles, ou plutôt chimériques).
Observez le point de gauche, votre regard fixé sur le × sans bouger pendant trente secondes,
puis sautez au carré du milieu et restez sur sa ×.
Auteur : Zowie CC-BY-SA pour Wikipédia.

D'autres parlent bien mieux que moi des couleurs en CSS, donc je ne ferais pas l'affront d'en faire un résumé imparfait, mais je sauterais direct au nœud du problème : J'ai deux manques dans la norme, mais qui sont totalement justifiés. Et des effets de bords qui pourraient surprendre des intégrateurs non prévenus.

transparent

Cette couleur existe principalement en valeur de la propriété background : transparent. On a trouve aussi pour border-color ou encore dans l'attribut fill="transparent" d'une balise SVG.

En fait, transparent n'est pas un alias vers une couleur pleine, mais d'une couleur quelconque rendue avec une opacité de 0%.

Sauf qu'il y a une méprise : il n'est pas possible de s'en servir pour la propriété css color dans l'idée d'avoir le rendu derrière le fond du tag courant. Une couleur transparente fera que le texte est virtuellement non affiché mais présent par ses dimensions.

Et c'est normal, car cela voudrait dire que le navigateur devrait être capable d'utiliser la forme des lettres pour découper le fond de l'élément support. C'est pas impossible, mais totalement tordu en terme de pensée, alors que vous pouvez preeeesque facilement le faire en SVG. Bon, dans les faits, je ne vous le conseille absolument pas ! Et ceci pour des raisons de performances de rendu, votre site va commencer à ramer sévère si vous vous lâchez.

currentColor

Cette magnifique couleur définie en CSS3 n'existe qu'en couleur de pinceau : currentColor

currentColor est immensément pratique, car elle fait référence à la couleur de pinceau héritée. Et si cette couleur héritée renvoie par exemple à une variable css au nom à coucher dehors (hello var(--cpu-playing-color)) , sur de nombreux rappels, on gagne de très nombreux octets... Exemple :

main {
    color : var(--cpu-color);
}
main.act-playing {
    color : var(--cpu-playing-color);
}
a, button (je vous la fait courte) {
     color : currentColor;
}
svg {
     fill : currentColor;
}

Bien plus pratique que color : inherit, car pouvant s'appliquer sur d'autres propriétés.
À chaque coup, je gagne.

currentColor est une Valeur Magique en css. Magique dans le sens Noble du terme, au sens que justement, ce n'est pas une constante arbitraire (par rapport au sens commun en informatique, et qui tient de l'insulte) mais qu'elle fait référence à son contexte et elle permet de gagner un temps fou.

Sauf que, hélas, et je ne suis pas seul à m'en plaindre, on n'a pas de currentBackground…

Et c'est tout à fait normal : background a été discuté jusqu'ici dans ce billet en tant qu'écriture raccourcie de la propriété background-color. La propriété background est en fait composite, très complexe : On peut créer des arc-en-ciels, étirer une image, mettre des motifs svg embarqués. Retenez que background-color est la dernière composante définissant le fond d'un élément à être interprétée, lequel fond est défini par le standard comme ayant de multiples couches de rendus.

Alors quel est le problème ?

Et ben tout simplement, je ne peux pas inverser la couleur et le fond hérités.

Ainsi

button:hover {
    background : currentColor;
    color : currentBackground;
}

ça marche pas, puisque la propriété n'existe pas.

button:hover {
    color : var(--cpu-background);
    background : var(--cpu-color);
}
.act-playing button:hover {
    color : var(--cpu-playing-background);
    background : var(--cpu-playing-color);
}

Si vous aviez voulu mettre une des variables de couleur de fond à transparent... ça marchera pas non plus, vous vous retrouverez avec des boutons avec du texte totalement transparent qui ne se distinguera pas du fond. blanc, noir, rose, bleu schtroumpf, qu'importe la valeur que vous avez choisi ça sera illisible !

Et si la couleur de texte est transparente et que la couleur de fond est fixée sur la couleur courante pour le même bloc, vous aurez une superbe disparition !
(pourtour ajouté pour voir le bloc)

Essayez vous-même !

Pour lire ce billet, il est conseiller d'aller sur mon site dascritch.net. Si vous lisez ce texte, c'est que probablement vous n'y êtes pas et donc vous ne pouvez expérimenter avec l'édition interactive.

Le bloc de code CSS ci-dessous est éditable, et il impacte directement le lecteur au-dessus. Sur le détail des variables CSS du lecteur, je vous renvoie à la doc.

Évidemment, y'en a qui vont me dire ça marche pas sur mon appli de news, donc voici une capture d'écran de ce que vous devriez voir :

Le rendu du player en attente à gauche, lors d'un survol souris ou d'un clic sur le bouton de lecture à droite,
lequel devient malencontreusement invisible.

Où tu rêves d'une licorne rose invisible

Alors il y aurait une bonne astuce : au lieu d'utiliser transparent, spécifier une couleur de fond avec une transparence totale genre #ff777700 (le fameux rose invisible de la légendaire licorne, qui est même enseignée en Zététique), et pouvoir mettre la transparence à opacité totale quand je tente d'utiliser cette couleur en guise de couleur de police/remplissage.

La fameuse licorne dans une représentation improbable de sa couleur impossible.
CC-BY Bingo Pajama Bee via Wikipedia, loués soient-ils

Mais là, il me manque (au choix) :

soit une propriété css background-opacity (et son pendant color-opacity),
soit un transformateur standard de valeur css que s'appelerio plain-color() qui me rabote une couleur avec opacité en couleur sans opacité,
soit des billes car ça existe peut-être déjà (j'ai pas dit que je connaissais à fond les CSS).

Tentative 1 : CSS pure, `rgba()` et deux variables

J'ai bien trouvé une solution amusante avec la fonction css rgba() sous la forme
background : rgba(var(--background-color), var(--background-opacity))
mais comme cette astuce joue sur le fait que var() ne fait que restituer une chaine de caractère sans l'avoir interprété, elle induit :

que toutes les couleurs (encre et fond) paramétrées par l'intégrateur soient totalement opaques,
que je doive introduire une propriété de plus à part pour la gestion d'opacité du fond,
que la syntaxe de couleur suive strictement la syntaxe rrr, ggg, bbb, ce qui multiplie les risques d'erreurs,
que l'intégrateur/utilisateur ne peut donc pas utiliser la syntaxe hsl()/hsla() que nombre de graphistes et intégrateurs trouvent extrêmement pratique,
ni les couleurs nommées prédéfinies comme rebecca purple (version audio du billet),
et seraient aussi bloqués ceux qui auraient voulu mettre un motif plutôt qu'une couleur unie.

Pour toutes ces raisons, ce hack me semble limite pour l'Inspecteur Hacky, donc pour l'instant ⇒ c'est non.

Tentative 2 : Polyfill javascript pour déduire une couleur totalement opaque

Certains m'ont suggéré d'utiliser/créer un polyfill en javascript pour extraite la couleur opaque en surveillant les modifications sur la variable d'environnement, et en définissant une autre variable d'environnement à la volée avec le canal alpha complètement opaque. L'idée semblait être une bonne idée, puisque les variables CSS peuvent changer suivant les contextes (position de l'élément dans le DOM, taille de la fenêtre, :hover , :focus, etc...). Les innocents…

Évidemment, il faut convertir la couleur CSS qui peut être retournée en n'importe quelle notation valide vers un format RGBA ou HLSA (peu importe, tant qu'on peut avoir la valeur alpha à part). J'ai vérifié avec la méthode window.getComputedStyle() en l'appliquant sur un élément de référence, seul moyen de résoudre les contextes comme currentColor. Outre que créer un élément de référence uniquement dans ce but est une méthode qui pue un peu, la fonction que j'appelle retourne à peu près le format qu'elle veut, selon l'envie du navigateur, l'historique de la propriété et le système derrière. Ainsi, on peut tout à fait imaginer qu'un écran passif travaille en HLS, ou qu'une évolution prochaine du standard passe d'un rendu de 8 à 16 bits par canal couleur. De petites fonctions pèteront le webcomponent à la gueule des utilisateurs sans que vous ne voyiez rien venir.

Donc il nous faut une regex convertisseur magique qui n'existe pas en standard en pariant très fort que les navigateurs ne retournent que du rgb() ou du rgba().
Là aussi, j'ai tenté, j'ai abandonné : beaucoup trop de taf pour un résultat incertain et un usage marginal.

Si néanmoins vous vous le sentez, tentez de le faire : j'aurais toute une liste de cas d'usages à vous faire tester, vous allez en suer et vous finirez par écrire un billet technique sur le côté complexe et vain de cet exercice. Une bien maigre compensation, mais qui vous permettra de proposer une conf à un devfest.

J'ai même réfléchi à faire un filter : invert(100%); plutôt qu'inverser les variables de couleurs, mais le rendu n'était pas plaisant dans nombre de cas.

Et là, tu peux plus voir cette exception en peinture

Mais tu sais que c'est normal et tu dois l'accepter. Je dois être un genre de fou à la Van Gogh. LIBÉREZ LA PALETTE CHROMATIQUE !

Alors évidemment, il y aura toujours des personnes qui vous diront « Ahlalalala ! Mais il suffisait simplement de passer par un pré-processeur CSS pour obtenir cet effet ». Sauf que

Ces personnes n'ont pas lu l'ensemble de cet article ;
Ni le chapitre d'un article précédant expliquant les contraintes d'écriture d'un web-component réutilisable ;
Que je veux que ma bibliothèque javascript soit utilisable directement en insérant le script et en ajoutant la balise <cpu-audio>,
Qu'elle soit configurable même par des gens qui n'ont qu'un minimum de bagage HTML avec une bête page statique,
Qu'elle utilise en priorité les standards du web et en évitant les rustines,
Et sans avoir à installer une suite d'intégration complexe, genre NPM.js je-te-télécharge-internet-pour-changer-une-couleur.

Donc nous sommes dans un cas limite qui est actuellement bloqué, et qu'on ne tentera pas de palier dans l'immédiat car elle n'impacte qu'un cas de paramétrage d'aspect très marginal, et qui est compensable.

Désolé Larcenet*, on s'est parfois engueulés ensemble, mais j'ai pas pu m'empêcher de citer dans mon billet technique le dos de la couverture du deuxième tome de tes fabuleuses « Aventure rocambolesque », celui avec Vincent Van Gogh. C'est chez Dargaud. Achetez-le !

Eh mais, du coup, je peux clore ce ticket #29 : Some css vars settings won't be useful, non ?

Non :

La couleur tombée du Ciel

J'ai écrit cet article en Avril 2019.
Entretemps, un nouveau groupe d'API natifs commence à arriver dans les navigateurs : CSS Houdini.

Et ce groupe est tellement stupéfiant qu'on dirait une nouvelle de Lovecraft adaptée part Richard Stanley (Personal message : If you read me, I salute you, by the way. You're welcome for a craft beer.).

L'idée est d'étendre les variables CSS pour leur faire porter une partie d'attributs, via l'API accessible en javscript : CSS.registerProperty.
Ce qui permet d'étendre les possibilités des propriété css background.

L'idée est géniale, audacieuse, mais je ne la mettrais pas dans ma bibliothèque, car elle relève plus de la coquetterie de chaque site que de réellement la responsabilité de mon web-component. De plu, il est probable que les performances de rendu navigateur impactent l'expérience utilisateur si vous êtes trop gourmands.
Néanmoins, l'usage des variables CSS dans mon code en laisse la possibilité à tout intégrateur aventureux.

La prochaine fois, on va s'amuser avec des objets DOM incongrus, des méthodes javascripts et des fichiers de sous-titrage. Et croyez-moi, c'est à la fois instructif et éclairant quand une norme a des limites pour rester dans son intention.

We need Web Share

Da Scritch — 2019-06-26T05:21:00+02:00

We finally get a way to add share buttons without forgetting a service or use. And respecting the privacy of our public. Go into all the world wide web and preach the method to all creation ! Well… who can use it, because, alas, that function is not everywhere.
Webdev

This article is translated from french, namely « Le blues du Web Share », in a series describing the development of the cpu-audio.js webcomponent.
Excuse my French as we say in… French.

Today, I talk about what lies behind the button.

Here is my player, in its last development version. You can ⇓ jump ⇓ to ⇓ the ⇓ next ⇓ chapter ⇓

You will need to go on my dascritch.net websit to read and experience my post. If you can read this text, you may probably not be on it.

Yes, I know, I’m talking in French and this show is 5 years old, but I’m not sure to be a better radio host today. Yes, the interface is in French here, because my blog usually gets contents in French. It may be started in English.

The switch

The main interface of the player

This button (on the right of the main interface) will switch it to a share one. It is possible to hide this button and so denying access to the share interface via hide="actions" attribute. It may be useful, by example when your website already have a share system.

Once the button clicked, you get some possible actions, on the whole width of the main interface of the web component :

Seen in full width. If you don’t see exactly that, there is no problem : it’s the subject of my post.

This panel has some different actions as direct downloading the media file (according to which codec can be read by the browser, as we still get some old guns as Safari) and also share the sound via e-mail, twitter or facebook to relatives, sending them the canonical URL of the sound’s page. Due to limitations on those social networks, only e-mail gets a working media-fragment starting the play at the exact moment you were listening.
From left to right :

a copy of the cover, going back to the main interface,
share on Twitter (vanilla link),
share on Facebook (vanilla link),
share by e-mail (mailto: link),
download the media (according to which codec can be read),
cancel, going back to the main interface.

As my web component is in liquid design and mobile first, the interface is simplified on small width : cover and text labels are hidden.

Yes I know. For any critics on icon’s design, please commit me better ones. I'm a coder, not Picasso.

Canonical URL means that if you want to share the radio show on cpu.pm front page, as i’m only showing the last broadcasted episode, its audio tag will be removed after next one is broadcasted, so there is a better choice : providing the page of the episode. And please, don’t look like you don’t use this useful tag. Yes, even if, as I do, you don’t code a website optimized for desktops, and a .m one for mobiles, because, you know, it’s a loss of time.

If the canonical URL is not the one where is hosted the player, the canonical="" attribute will do the job.

The wish

We already have browsers with a share on social networks menu on mobile platforms. I’ve explained in a 2014 post in French about why I put again share buttons on my blog. It was 5 years ago, and, even if the general interface of the browsers moved, this over useful interface is still here.

Seen there in Firefox on Android in 2014, and was literally rocking, getting you directly in their respecting function in the native apps.

Cool. Except that your browser will take the title of the page, a title encumbered with unmeaningful elements as separation glyphs, name of the site before title of the page, in extenso description of old-school SEO with a bunch of keywords names verbs persons marks important etc… Up to the user to clean it up and rephrase it.

The witch

Here enter the good fairies of the web standards : The W3C introduced navigator.share() aka WebShare, a function standardizing how to do it and allowing to suggest a bit longer description.

This function has numerous wins :

being standard (in theory, I’ll explain later) ;
not forgetting a service used by your reader (instead of the facebook/twitter classical duo) ;
use a native control of the host OS, really more useful on smartphones ;
deep sending you to the share function in the native app ;
not tracking the users as do social networks with rich buttons (this is a shared win with classical HTML links) ;
not tracking the users by the hosting website, guessing which sharing service they use ;
not encumbering the small screen of a smartphone with gazillions of services.

Calling it is damn simple.
I’m really delighted having a so lean and perfectly thought process, instead to construct an instance builder with parameters set by another class serving a specific object and call it via an event dispatcher.

♫ In a webpage, https:// served , on a user action (as ), cook * :

navigator.share({
            'title': document.title,
            'text': document.querySelector('meta[name="description"]').content,
            'url': window.location.href
        });

* in French, it sings as the Cake d'Amour song in the famous « Peau d'Âne » movie, directed by Jacques Demy. That’s what I call love.

If you have a clean coded html page, your whole job is done. If it’s a piggy mess, you should start to not forget the <meta... description tag.
By the way, you can share files with this standard’s level 2, and an API to test the share (navigator.canShare()).
Pure genius !

The twist

Except :

CanIUse.com support stats as taken when I wrote the original french post.

This API is not available on desktop computers (except Safari Mac) ;
It is also not available on Chrome Desktop, even in responsive mode (by the way, not a real mobile emulation, and may induce you in error) ;
This API is as today only on iOS and Chrome Android ;
On iOS, each native app should carry its own sharing list, so we had a lot of missing ones due to the lack of a system-wide registry. We have it finally with, guess what ? Experimental support of navigator.share !
It is still not possible of a online service accessed via a browser to be registered, as long Web Share Target API is nowhere implemented (and if it will be somewhere, we need to have it accepted by the user via a specific interface, to avoid spam attempts).

We have a very volatile scene of social networks, and the landing of decentralized hives, where inhabitants is supposed to easily migrate from an instance to another one. For 3 years Web Share is so under-esteemed and only usable on one platform is a real shame. I’m deeply convinced we have technical ability to build a WebExtension doing that job on desktop browsers.

I have some request to add, or being able to add, sharing option for a lambda website. Sure, I’d only put Facebook and Twitter, some people shamed me for forgetting Diaspora*, VKontakte, Mastodon, etc.social.random() in the action interface of my player. They are right.
Except the more you get in a limited place, smaller each button will be and all those services will be tight on the bench a wide as a smartphone. And, whatever we can do, there is no way to keep an exhaustive list of any available share services, even for specialized audience, for a real obvious point : New services appear each day.

So I’m re-using this really lame joke, again.

Looking this image again, we note that a lot of those social services that died during the last 5 years. And having so much begging puppies makes the whole page unreadable.

The tweet

Well, I can not declare those missing services in the webcomponent code, and create an API permitting the web-developer to add some ?

Ahem. No. Wrong idea.

Because a such function will induce other problems : charging the work to whom will include my webcomponent in his website, asking to have some javascript knowledge and read my API's documentation. I can hear you, noisy kids : even with a big RTFM, you won’t.
And I can bet that the web operator will forget some sharing services.

It also means giving to the integrator some parameters that may be harmful :

describing a color, injecting it via the style="background-color" attribute ;
describing a monochromatic SVG logo, needed because of the color inversion on :hover and :focus, and betting the image will be exactly matching my template constraints and is not having an embedded javascript ;
describing an URL canvas where to send for that sharing service, if a such URL exists.

Yes, I’m talking about you, social services with sharing systems that don’t support a simple link for that job. With the main motive to force your users using your mobile app full of tracking ads. You, nasty boys.

So what ?

I don't know what to tell.

Today, a feature detection replaces the facebook/twitter/e-mail buttons by a unique button, launching the navigator.share() function. You can see it only on Chrome Android and Safari.

The action interfaces, with the navigator.share() button

Screenshoted on Safari Mac by Hadrien Lanneau. It pops up a contextual menu where the mouse is.

And later, yes, build a polyfill WebExtension may be a great idea (in a more generic and without jQuery way, compared to web-share-api by C. Zuber). As long as sharing services will collaborate without pollute it with analytics and other ad-tracking.

For me, the best looking interface to add a share service in my browser is to re-use what already exists in Firefox to add a search engine. Because it's a lean interface, explicit one, standard-based and most of the work is already done there.

It’s up to you to build it, now. IMHO, this is not a over-difficult job to complete, and will be still a future-proof solution instead of any old AddThis script.

You can also support initiatives to add WebShare into :

Again, it was a long post talking about code, standard, implementations, but, for me, it worth it because this issue is not limited to my cpu-audio.js.
My next post in this series will be in French and talks about CSS, standards and implementations for some… strange colors.
May be it’s a frightening title, may be related to a horror story, so I have to say the killing sentence :

I’ll be back… soon !

Le blues du Web Share

Da Scritch — 2019-06-18T06:52:00+02:00

Il y a enfin un moyen pour mettre des boutons de partage sans oublier une plateforme ou un usage et ceci, en assurant le respect de la confidentialité de vos ouailles. Allez et partagez la bonne nouvelle ! Enfin, ceux qui l'ont, car évidemment, la fonction est très peu répandue.
Webdev

An english translation is available.
Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de sa version 6. (enfin, la 6.1, car j'ai dû modifier l'icône dont il est question).

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web (sur la version 5)
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

Je continue le tour des coulisses du webcomponent cpu-audio.js. Et aujourd'hui, on va parler de ce qu'il y a derrière son bouton

Je vous remets le player, dans la dernière version de dev. Sinon, ⇓ sautez ⇓ directement ⇓ au chapitre suivant ⇓

Pour lire ce billet, il est conseiller d'aller sur mon site dascritch.net. Si vous lisez ce texte, c'est que probablement vous n'y êtes pas.

Ouais, le sonore date un peu, mais c'est pour illustrer et de toutes façons, je ne fais pas mieux en radio depuis.

The switch

L'interface normale du lecteur ci-dessus

Ce bouton (à droite de l'interface normale) bascule l'interface de lecture, vers une interface de partage. À noter qu'il est possible de cacher ce bouton et rendre l'interface d'action inaccessible via l'attribut hide="actions", ce qui peut se comprendre, par exemple si le site a déjà sa propre interface de partage.

Une fois le bouton cliqué, on se retrouve sur le panneau d'actions qui prend toute la largeur du panneau principal du web component :

Vue en pleine largeur. Pas de panique si vous ne voyez pas exactement ça : c'est le sujet de l'article.

Ce panneau propose différentes actions comme la possibilité de charger directement le sonore (en fonction du format qui est supporté par le navigateur, parce qu'il reste des vieux tromblons comme Safari), et aussi celui de partager le sonore par e-mail, sur twitter et sur facebook à des amis en renvoyant vers l'URL canonique de la page du sonore. À cause des limitations imposées pour les partages sur les réseaux sociaux sus-mentionnés, seul le partage par e-mail permet en l'état de profiter du media fragment pour pointer exactement au même moment.
De gauche à droite :

reprise de la cover pour revenir à l'interface de base,
partager sur Twitter (lien simple),
partager sur Facebook (lien simple),
partager par e-mail (lien mailto:),
télécharger le sonore (en fonction du codec accepté par le navigateur),
annuler, revenir à l'interface normale.

Comme le web component est en interface liquide et en mobile first, l'interface est simplifiée sur les petites largeurs : la cover disparaît, et les textes aussi.

Oui, alors, si vous avez des remarques sur le design des icônes, rien ne vous empêche de proposer mieux. Je suis programmeur, pas Picasso.

URL canonique voulant dire que si par exemple vous partagez l'émission qui est en une du site cpu.pm, vu que c'est la dernière émission diffusée, elle y disparaîtra à l'émission suivante, donc il vaut mieux directement renvoyer vers la page de l'émission. Et ne faites pas ceux qui ne connaissent pas, vous devriez utiliser le tag. Oui, même si, comme moi, vous ne doublez pas un site prévu pour desktop avec un m. pour mobile parce que ça fait trop perdre de temps.

Si l'URL canonique de ce sonore n'est pas celle de la page où est intégré le player, l'attribut canonical="" est là pour ça.

The wish

Il existe déjà sur les navigateurs des plateformes mobiles un menu de partage de lien vers les réseaux sociaux. Je l'avais déjà fait remarquer dans le billet où je parlais de la réapparition des boutons de partage sur mon blog. C'était y'a 5 ans, et si le design général des navigateurs a changé, cette interface hyper pratique est toujours là.

Ici, dans Firefox Android en 2014, et ça déchirait déjà pas mal, renvoyant sur les applications natives correspondantes.

C'est cool, sauf que, bien souvent le navigateur va reprendre le titre de la page, lequel est bien souvent encombrée d'éléments inutiles genre glyphes de séparation, titre du site en plus de la page, description in extenso pour du SEO à la papa bourrée de mots-clés mot-clé keyword key word terme important , etc… Ce qui laisse le boulot à l'utilisateur de nettoyer et de remettre en forme.

The witch

Arrivent les bonnes fées des standards du web : Le W3C a introduit navigator.share() aka WebShare, une fonction qui standardise l'action et permet de proposer un texte descriptif un poil plus long.

Cette fonction présente plusieurs avantages :

être standard (théoriquement, on verra plus loin) ;
ne pas oublier un service de l'utilisateur (au lieu de rester sur le diptyque facebook/twitter) ;
utiliser un contrôle natif de l'OS beaucoup plus pratique sur les smartphones ;
envoyer directement le lien à l'application native installée dans son interface idoine ;
ne pas pister les utilisateurs par les réseaux sociaux en proposant les boutons enrichis (avantage partagé si vous utilisez les liens HTML classiques) ;
ne pas pister les utilisateurs par le site web en devinant quels services de partage l'utilisateur emploie ;
ne pas encombrer l'écran du smartphone avec trouzemillions de services.

L'appel est hyper simple.
Ça fait même hyper plaisir d'avoir quelque chose d'aussi simple et correctement pensé, au lieu de devoir faire appel à un constructeur de classe, à des paramètres instanciés par un autre constructeur pour un objet spécifique, et d'envoyer via un diffuseur d'événement.

♫ Dans une page… ♬ dans une page web *, ♫ servie en h… ♬ servie en https://, sur une action utilisateur (genre ), lancer :

navigator.share({
            'title': document.title,
            'text': document.querySelector('meta[name="description"]').content,
            'url': window.location.href
        });

* Honte à moi, oui, j'ai bien chanté ce paragraphe sur l'air du Cake d'Amour dans « Peau d'Âne » de Jacques Demy. Et maintenant, vous l'avez dans votre tête, votre journée sera foutue. Plaintes en commentaires ↓, merci

Si votre site est déjà bien conçu, vous n'avez quasi plus de boulot à faire. Si votre site est conçu comme un cochon, il va déjà falloir apprendre à ne plus oublier les balises <meta... descriptives.
D'ailleurs, on pourra aussi partager des fichiers avec le niveau 2 de ce standard et une API pour tester l'envoi (navigator.canShare()).
C'est génial !

The twist

Sauf que :

Les chiffres de support par CanIUse.com relevés à l'écriture de ce billet.

Cette API n'existe pas sur ordinateurs de bureau (excepté Safari Mac) ;
Elle est aussi indisponible sur Chrome Desktop, même en mode responsive (qui n'est pas un vrai émulateur mobile, et n'est pas toujours fiable pour tester réellement) ;
Cette API n'est pour l'instant supportée que par Chrome sur Android et iOS (eh !) ;
Sur iOS , chaque application devait prévoir sa propre liste de partage, il y a donc souvent des oublis faute de registre commun au système. C'est enfin arrangé depuis la dernière version d'iOS avec, devinez quoi ? Le support expérimental de navigator.share !
Il n'est pas possible pour un service en ligne accédé via le navigateur de s'inscrire, tant que l'API Web Share Target n'est implémentée nulle part (et si elle l'est, il sera impératif de demander l'autorisation à l'utilisateur par une interface de validation, afin d'éviter le spam).

Devant la volatilité des réseaux sociaux, et surtout l'arrivée des ruches décentralisées où un habitant est supposé pouvoir migrer facilement vers un autre service, il est vraiment dommage de Web Share soit si peu considéré depuis 3 ans, et cantonné que sur une plateforme. Il y a pourtant sûrement le moyen de créer une WebExtension qui fasse le taf pour les ordinateurs de bureaux.

Alors, on m'a souvent demandé la possibilité de rajouter dans le lecteur une option de partage vers un site particulier. Ben oui, j'avais mis que Facebook et Twitter, beaucoup me reprochent de ne pas avoir mis Diaspora*, VKontakte, Mastodon, etc.social.random() dans l'interface d'action de mon player.
Sauf que, évidemment, plus on en met dans un espace délimité, plus les boutons de chaque site sont petits et les services sont serrés sur une banquette large comme un écran de smartphone. Et quoique l'on fasse, impossible de couvrir toutes les solutions de partage, même pour les sites spécialisés, ne serait-ce que pour une raison évidente : Chaque jour naissent de nouveaux sites.

Et du coup, je ressors du même billet précédent cette image à l'humour douteux. .

À revoir cette illustration, on remarque immédiatement que nombre de ces services sociaux ont disparu dans les 10 ans. Et qu'un tel foisonnement rend la page totalement illisible.

The tweet

Donc si je met pas les services dans le code du composant, peut-être pourrais-je créer une API pour que l'intégrateur puisse en rajouter ?

— HIN ! HIN ! F.B.I. Fausse Bonne Idée !
— Hein ? Quoi ? Encore ?
— Ben oui, je ne m'en lasse pas.

Car cette possibilité induirait un autre problème : elle laisse le travail à la charge de celui qui intègrera le composant sur son site, ce qui induit le prérequis qu'il s'y connaisse en javascript et qu'il lise la doc de mon API. Je vous connais bande de petits coquinous : même avec un RTFM, vous ne le faites jamais.
Et évidemment, invariablement, l'opérateur du site oubliera d'autres sites de partage.

Cela induisait aussi d'inclure des paramètres par l'intégrateur qui pouvaient poser soucis :

intégrer une couleur en l'injectant via l'attribut style="background-color" ;
intégrer un logo monochrome en SVG, et on est obligé d'être monochrome à cause de l'inversion de couleur au :hover et :focus, sans compter le pari que l'image soit ajustée aux contraintes de mon canvas et que l'intégrateur n'aura pas mis de js embarqué quelconque ;
intégrer un motif d'URL où renvoyer pour le service ciblé, à condition qu'une telle URL existe.

Oui, je pense à vous, les sites de partages sur réseaux sociaux qui n'ont pas de possibilité d'enregistrer par un lien simple. Souvent par volonté d'obliger leurs utilisateurs de passer par une appli mobile native bourrée de traceurs publicitaires.

Ben alors, on fait rien ?

Je ne sais quoi vous dire…

Pour l'instant, je fais une feature detection, qui fait que les boutons vers facebook, twitter et e-mail sont remplacés par un bouton unique lançant la fonction navigator.share(). Une solution qui n'apparait uniquement que sur Chrome Android et Safari.

Le panneau d'actions, avec le bouton unique lançant navigator.share()

Capture d'écran sur Safari Mac par Hadrien Lanneau. La fonction ouvre un menu contextuel à la position de la souris.

Et pour les autres, oui, construire une WebExtension polyfill serait une bonne idée (dans une version plus générique et sans jQuery que web-share-api de C. Zuber). À condition que les sites de partage participent au mouvement sans vouloir y embarquer du script analytics de traçage publicitaire.

Personnellement, je pense que la meilleure interface possible pour inscrire un site de partage en plus dans son navigateur est de reprendre ce qui existe déjà pour ajouter un moteur de recherche. Parce que cette interface est propre, elle est explicite, elle est standardisée, et les évolutions à y faire apporter ne sont pas énormes.

Pour la réalisation, à vous de tenter, je ne crois pas que cela soit hyper-compliqué, et ça sera toujours mieux à long terme qu'un antique script à la AddThis.

Et en attendant, soutenez les initiatives pour ajouter WebShare dans :

Ce billet fut un poil long là aussi, et j'ai causé de code, de standard et d'implémentation, mais je pense que cela le valait, surtout que ce problème ne s'applique pas, loin de là, uniquement à mon cpu-audio.js. Prochain épisode, on va plutôt parler de CSS, et là aussi, on parlera standard et implémentations pour… des couleurs bizaaaaaaaarres !
Si le titre vous fait peur, c'est que je tiens sûrement le titre d'un film d'horreur, et donc je me dois de sortir la réplique qui tue :

Prochaine épisode : Des couleurs impossibles

Retravailler un lecteur web audio dans les petites largeurs

Da Scritch — 2019-06-05T07:32:00+02:00

Parce que les chiffres ne mentent pas : nous sommes de plus en plus nombreux à avoir un smartphone. (Essayez de prononcer cette phrase d'un ton concerné en public sans rire, ça vous fera l'après-midi)
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de sa version 6.

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web (sur la version 5)
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

Et cet article est long, car comme le premier, je tiens à documenter ma démarche. Et comme j'aborderais plusieurs thématiques, vous aurez plusieurs épisodes. Vous pouvez tester l'application ici ↓ dans sa version de travail en cours.

Pour lire ce billet, il est conseiller d'aller sur mon site dascritch.net. Si vous lisez ce texte, c'est que probablement vous n'y êtes pas.

Avant d'entrer dans le vif du sujet, je rappelle que je ne suis pas web-designer, mais un développeur d'applications web et que je n'ai qu'un minimum de bagages pour construire un web component faisant office de player audio. Que ce composant a été écrit afin de l'intégrer dans un site d'une émission radio, ceci dans le but de lier et de lire des sonores qui durent en moyenne une bonne heure. La plus longue des émissions de CPU dure 5h30, un exemple NSFW qui montre à l'extrême les contraintes.

J'ai qu'un minimum de culture en design, mais j'ai eu la chance d'avoir fréquenté depuis 2000 des designers web (des vrais) qui étaient exigeants et m'ont beaucoup appris à ~~coups de b~~ la dure.

Petits dans la poche, gros dans les contraintes

L'un des gros gros chantiers évolutifs de CPU-Audio.js pour cette version fut la mise au point d'une interface confortable pour les smartphones.

Par rapport à ceux dits de bureau, on a sur ce type d'ordinateurs deux problématiques supplémentaires :

Un écran nettement plus petit,
un dispositif de pointage bien moins précis.

Voici la comparaison avec mon web component sur mon propre blog dans sa version de Janvier 2019, tel que vu sur un ordinateur de bureau (1920 px de large) avec un pointeur de souris.

la souris a une précision au pixel et son curseur ne cache pas tout l'environnement immédiat

… et le même composant, mais vu sur un smartphone d'une largeur de 320 px (virtuels, résolution typique d'un iPhone 5 en mode portrait, en fait l'écran fait dans les 1080 pixels physiques, mais expliquer les dppx dans la foulée serait trop long).
Le disque rouge est une simulation l'espace d'appui d'un gros doigt normal prompt à la bourde.

environ 50 pixels de diamètre, sans compter l'imprécision dû au virage effectué par votre bus à une certaine vitesse

Il existe un certain nombre de règles de bonnes pratiques pour y palier :

mobile first : On présente en priorité les éléments les plus importants de la fonctionnalité voulue ;
On aménage des zones cliquables suffisamment grandes et espacées ;
Le composant doit s'afficher très très vite, et donc avoir un code très léger avec le moins de dépendances possibles, si possible aucune ;
Responsive Web Design (RWD) : On ajoute l'accessoire quand on a plus de largeur disponible.

J'étais déjà parti avec un design liquide (ou fluide ou coulant) pour être le plus confortable, dans l'idée que mon composant puisse être intégré quels que soient les choix sur le design du layout des sites. Pour la légèreté, je tente de maintenir le code compilé sous les 50 kB, même s'il a pris 20% de poids en plus entre la v5 et la v6.

Mais il y avait encore quelques manques dans la version 5 pour que mon player audio soit vraiment confortable à utiliser sur smartphones.

Et déjà un premier souci avec les CSS media queries breakpoints

Car effectivement, il est possible de cibler des définitions CSS par des règles media queries qui s'activent en fonction de la largeur de l'écran ou de la finesse de l'afficheur physique (via l'unité de ratio dppx évoquée plus haut entre parenthèses, oui je sais, ça fait lourd à lire tous ces apartés). Pour les définitions en fonction de la largeur d'écran, cela revient à définir un breakpoint, une dimension critique d'une media query ou le chouïa qui fait changer l'aspect, des propriétés peuvent changer plus ou moins radicalement. J'ai choisi cette stratégie car c'est la plus pratique pour une conception en design liquide.

Mais il y a un gros problème dans l'idée de concevoir un web component installable partout : Il n'est pas possible d'appliquer lesdites règles en fonction de l'espace disponible dans un élément parent en pur CSS. C'est faisable mais avec des polyfill en javascript particulièrement lourdingues.

Je m'explique : Si l'écran est d'une largeur d'écran de bureau (vers 2000 et au-delàààààà), mais qu'un intégrateur installe mon composant sur un site, dans une gouttière qui fait 320 pixels de large, l'aspect de mon composant ne sera pas adapté car les boutons seront trop gros, et par exemple pour les titres, ils ne rentreront pas dedans.
Autre exemple : supposons que la mise en forme du site est entre un bloc principal à largeur variable, et une colonne à taille fixe de 200 pixels. Si le lecteur est dans le bloc principal, il serait logique qu'il change de forme pour une largeur inférieure à 320 pixels quand la fenêtre tombe en dessous de 520 pixels…

@media (max-width: 320px) {
    dommage, hein ?
}

Tommy Hodgins a fait une proposition auprès du W3C qui me serait super utile et totalement indiquée dans mon cas : Les CSS Element Queries qui proposent de définir en breakpoints la dimension d'un élément englobant.

La proposition CSS Element Queries permettrait de définir des règles appliquées si la largeur de l'écran fait 320 pixels ou moins ou que l'élément #conteneur a une largeur de 320 pixels ou moins :

@media (max-width: 320px) , @element #conteneur and (max-width: 320px) {
    J'en rêve, mais j'en rêve ! (c'est déjà dans mon code)
}

Hélas, cette proposition ne semble pas être au programme du CSS working group du W3C et donc pas près d'être implémentée nativement. Et évidemment, tout polyfill est lourd, même avec l'arrivée prochaine de l'API ResizeObserver.
Pourquoi ? Imaginez que vous chargez 4 ou 5 web components dans la même philosophie de conception, qui chacune lance son polyfill… Ouais, évitez le CSS-in-JS dans ce cas-là : vous risquez de ne plus rien contrôler correctement.

Autre frustration : il n'est pas possible d'utiliser des variables CSS pour définir des breakpoints, des changements de résolutions significatifs. Dans mon projet, le style est défini est dans une CSS locale, tandis que les variables reparamétrables par l'utilisateur sont dans une CSS globale, normalement, toutes les variables qui intéressent les graphistes sont dans la CSS globale… sauf ce qui défini les breakpoints !
C'est pour ça qu'ils sont codés en dur à 640 px, 480 px et 320 px.

Pourquoi une telle frustration ? En fait, ce manque est intentionnel : les variables sont justement variables selon les usages et leur définition, pouvant vite devenir un casse-tête pour les navigateurs web à recalculer dans un media query.

Et on pourrait aussi avoir des… maladresses genre :

--largeur : 1000px;
@media (max-width: var(--largeur)) {
    --largeur : 500px;
}

Do not want comme on dit dans le secteur.

Il tourne actuellement au W3C une autre proposition, définir des constantes CSS d'environnement définissant des informations pour l'ensemble du document. Ces constantes peuvent être définies par le système hôte, le navigateur web ou dans la CSS (et on imagine, idéalement sur le sélecteur :root).
À leur appel en lecture, ces constantes peuvent prendre un paramètre optionnel qui sert de fallback. L'invariance de la valeur représentée en quelqu'endroit du DOM le rend alors utilisable pour définir un breakpoint.

Là aussi l'idée est géniale, et le dossier semble un poil plus avancé, l'implémentation native étant satisfaisante pour être jugée comme générale l'année prochaine. On a la lecture, pas encore la déclaration

:root {
    --largeur : 1000px;
}

@media (max-width: env(--largeur, 320px)) {
    ooooh ouuuuiiiii
}

breakpoint sur un élément, comme on peut, comme un porc

Dans l'immédiat, je suis arrivé à le faire sur le mini-site de présentation du projet grâce à une astuce limite du crade à faire dégainer l'Inspecteur Dirty Hacky

Pièce à conviction n°1, faites entrer l'accusé

J'ai utilisé des <iframe>. Et pourquoi est-ce crade ?

Il faut créer une ressource indépendant pour chaque instance appelée, ici 3 documents html de plus ;
Évidemment, il faut recharger le script cpu-audio.js, donc le charger et l'instancier 4 fois pour cette page ;
Idem pour la feuille de style ;
On instancie 3 objets DOM de page en plus, bouffant de la RAM ;
C'est impossible de faire un design liquide propre dedans sans pleurer sur certains cas ;
Et on perd des fonctionnalités comme :
- le lien avec media-fragment (c'est très très con : c'est la fonction qui a motivé l'écriture de mon script),
- l'anti-cacophonie (un seul sonore lu à la fois dans la page),
- les playlists,
- et le contrôleur global (le bouton ▸︎play dans l'encart à fond noir à gauche sur ma capture) ne voit pas ces instances.

Je ne l'ai utilisé que pour faire la démo des largeurs. Ne faites jamais ça chez vous, les enfants !

Le problème de la navigation fine sur une largeur fine

Revenons sur les problèmes fonctionnels de mon web component sur les ordinateurs de poche.

Le manque qui me semblait le plus gênant était de revenir en arrière d'une phrase dans un sonore d'une heure. Le lecteur peut interpréter certaines touches comme ← et →, mais aucun smartphone n'a de clavier avec des touches fléchées depuis la mort du dernier Blackberry à touches physiques. Reste le positionnement au doigt ~~levé~~ posé, et donc la navigation dite fine s'y révèle imprécise.
Améliorer ma time-line était indispensable.

Une time-line c'est ÇA :

N'oublions pas que mon web component est prévu pour être utilisé dans une page web, et qu'il a été conçu en design liquide, donc si on passe son smartphone de l'orientation portrait à paysage et que sa dimension n'est pas fixée, le visiteur gagne autant de largeur, donc de précision pour naviguer dans la time-line. Mais la prise en main me semblait toujours insuffisante.

Dans pratiquement tous les lecteurs audios, la time-line est à la fois un indicateur et un élément de contrôle auquel on s'attend pour tout média audio ou vidéo d'une certaine durée. Elle indique à la fois la position en cours de lecture, la partie préchargée immédiatement lisible sans avoir à attendre, et permet à l'auditeur de sauter à une position. Plus cette time-line est large, plus le positionnement au pointeur par l'utilisateur est précis. Plus le sonore est long, moins ce positionnement est précis.
Je ne saurais dater son apparition, mais il me semble qu'elle est apparue avec le premier Quicktime (1991) en tant qu'adaptation de la time-line des éditeurs de sons qui présentaient la forme d'onde du sonore en cours d'édition, et ceci depuis les années 1970s.

Avant de me remettre ~~au redesign~~ à la refactorisation de mon lecteur, et vu que moi-même je ne suis pas parfait, j'ai regardé ailleurs et essayé des applications natives sur smartphones. En me concentrant sur son comportement lors du passage d'une disposition portrait à paysage. Certains choix y sont surprenants, et pas uniquement sur les durées affichées (passée, restante ou totale).

Quatre exemples de time-line en natif

L'application Youtube l'agrandi aussi en passant en mode paysage. En mode portrait, elle utilise le maximum de largeur d'écran.

Mais pourquoi ai-je pris une vidéo d'Eugène Lawn ?

HenryMP, héritier d'un excellent player audio (Appollo sur Cyanogen OS), se montre encore moins aisé : si on décide de basculer l'écran du mode portrait au paysage.... la time-line n'est pas plus grande pour autant. Frustrant.

J'imagine que la logique y est plus d'écouter des singles d'environ 4 minutes et de mieux voir la pochette de l'album, pas forcément de naviguer dans un DJ-set de 2 heures ou dans une conférence au Collège de France

Note : Cette application n'est plus maintenue depuis 4 ans, elle est présentée ici pour l'exemple.

Podcast Addict, qui est une excellente application orientée podcast (merci Capitaine Évidence), a quelques manques dans sa prise en main pour naviguer. En gros, si l'émission n'est pas chapitrée ou n'a pas de liens explicatifs dans son texte descriptif, on pointe sur la time-line puis on utilise des boutons pour se positionner plus finement.

Dans la vue présentation d'un épisode, basculer en mode paysage étend la time-line.

Sauf que, petite inconsistance : sur la vue propre à un sonore, en mode paysage, la time-line est… plus courte. Oups.

Je termine ce tour avec une application très particulière, celle de Les Croissants, qui propose une matinale par modules, composée en fonction de vos centres d'intérêts.
(Manque de bol : La société Les Croissants a fermé la veille de la publication programmée de cet article. Pas d'bol.)

En haut, vous avez une vue sur l'ensemble de l'émission dans une time-line globale, et au milieu, chaque chapitre a sa propre barre de défilement, mais à la verticale, sur la gauche.

On a certes une redite de la time-line entre la vue totale (horizontale) et celle par chapitre, mais ce qui est nettement plus notable et bizarre est que la progression des time-lines des chapitres n'est pas constante, puisque la hauteur de cet élément est fixe, mais que la durée peut varier (entre 3mn et 7mn). Mais ces bizarreries sont plus une signature et non gênantes à l'usage.

On a vu quelques outils de consultation destinés au public, j'aimerais vous présenter un outil professionnel de lecture de média :

Le jog shuttle du Beta SP

Le magnétoscope Beta SP de Sony est avec sa cassette Betacam un engin de chantier de l'audiovisuel des années 1980s-2000s. Costaud, robuste, très cher et indispensable pour toute production de qualité. La première fois que j'ai pu en utiliser un, j'ai immédiatement adoré l'usage du bouton jog shuttle ! Oui, même en pleine frustrajoie.

Vous ne pouvez pas louper le jog shuttle : c'est ce gros bouton rond noir proéminent idéalement placé sous votre main droite sur le panneau inférieur.
Photo non créditée sur Pinterest

Dans le mode shuttle en pause ou pendant la lecture, vous pivotez le bouton rotatif, la bande défile alors vers l'avant ou l'arrière plus ou moins rapidement, entre le ralenti et l'accélération ×8 en fonction de l'angle de rotation. Relâchez, le bouton rotatif revient en position neutre.
Mais si vous cliquez sur le bouton, le ressort est désactivé, et le mode de fonctionnement passe en jog, où vous faites défiler les images en tournant le bouton. Comme si vous bougiez manuellement la bobine de la bande sur un bon vieux reel-to-reel ReVox, ou que vous caliez un disque vinyle (étant à Radio <FMR>, j'ai voulu être DJ). Ce qui permet un calage à l'image près, indispensable pour le monteur vidéo.

On a donc un outil de calage qui passe d'un clic d'un positionnement grossier au calage à l'image élémentaire. La prise en main est incroyablement intuitive une fois qu'elle vous a été montrée.

À 1m42s, une petite démo avec un lecteur XDCam portable, mais il s'agit d'un bouton combo (voir le paragraphe suivant). Pour 60€, je vous aurais intégré cette vidéo éclairante avec un vrai BetaSP. Et y'a celle-là montrant un autre point de vue.

À noter que certains magnétoscopes très haut de gamme des années 1990s avaient un combo bouton central shuttle rotatif et pourtour jog à ressort. Peut-être fut-il utile pour monter les Sept Premiers Bitomans.

Depuis, la génération Betacam est passée.
Au prix de la bande, les BetaSP sont devenus des pièces de musée, et on monte au clavier et au trackpad. Mais le jog shuttle est resté dans cette micro-culture industrielle pour ceux qui ont connu avant l'informatisation totale du banc de montage. Pas mal de monteurs vidéos, qui ont un jog shuttle wheel sur leur poste de montage. Les control knob prévus pour Windows 10 tels le Surface Dial s'en approchent mais n'ont pas le retour haptique avec ressort, si intuitif.

Et dans les logiciels ?
Il me semble qu'une version (bêta ?) de QuickTime Pro avait tenté à la fin des années 1990s d'ajouter dans un panneau de son interface une molette de défilement… qui ressemblait trop furieusement au jog-dial, une molette crantée cliquable que Sony incrustait absolument partout. Et quand je dis partout, ce jog-dial a été la signature des produits Sony de la fin des années 1990s : sur les baladeurs Mini-Discs (utile pour titrer un MD, mais dont l'usage bourrait de saletés l'intérieur de mon MZ-R35), le téléphone Z5 (celui de l'An 2000) ou encore les PDA Clié. Il me semble que les designers de Sony se soient retenus pour les télés et playstations.
Apple a retiré l'interface avant un procès prévisible, ou peut-être en souvenir de l'échec de la molette de volume du Quicktime 4 ?

Mais je m'égare dans mes rushes.
Alors l'idée d'un jog shuttle dial est super, mais non-intuitive pour le visiteur lambda d'un site à qui il faudrait lui expliquer le manuel, or, rappelons la règle d'or du design réussi :

S'il faut expliquer le fonctionnement d'une interface grand public
⇒ c'est que ton design est loupé
⇒ F.B.I. Fausse Bonne Idée.

Accessoirement, elle est aussi un poil lourd à écrire from scratch. Pas infaisable, juste lourd. Et prendrait de la place sur l'écran.

Maintenant qu'on a fait ce petit tour de l'État de l'Art pour se mettre en appétit, passons à l'action !

Supprimer les bords ronds

Un truc totalement idiot où j'ai pêché par coquetterie : j'ai mis des bords ronds au début et à la fin de la time-line. En fait, cela rend moins facile de viser le début d'un sonore (oui, les recherches avancées ont prouvé que statistiquement, nous cherchons plus souvent à revenir au début qu'à aller dans les 5 dernières secondes d'une émission d'une heure). Donc tant pis pour les bords ronds, on revient au bon vieux rectangle.

Je vais prendre exemple sur mon propre blog, avec une de mes émissions actuelles qui ne dure qu'une heure : Sur 320 pixels de large, le web component fait 291 pixels de large à cause de la mise en page.

La time-line fait 195 pixels de large, les bords ronds en bouffent 2×4 pixels.

Je me suis appliqué la Règle des Cinq Pourquois pour chercher la vraie raison de ma décision graphique. Alors, euuuuuh… les bords ronds sont moins agressifs, parce qu'il y a trop de rectangles, Steve Jobs a inventé les rectangles arrondis… Au final, j'avais mis ces bords ronds sans aucune raison valable.

Bon ben, on vire !

À 18 secondes par pixels pour un sonore d'une heure, cela faisait 2'27" rabotées par pure coquetterie, et non pas par design.

Parce que, oui, il faut se rappeler que le design n'est pas qu'une question de couleurs et de formes mais surtout de praticité pour tous. Faire du décor ne suffit pas et n'est pas du design.

Agrandir la time-line

Passer de la souris à la précision d'un pixel sur un écran de 52 cm de large (1920 px soit 96 dpi) à un écran tactile de 8 cm de large (1080 px soit 400 dpi, plus qu'un album de bd !) avec la précision d'un gros pouce… inutile de dire que sur smartphones, une telle précision peut entrainer autant de dégâts collatéraux qu'une guerre chirurgicale. Et cette imprécision devient de plus en plus problématique quand on a mis en ligne un podcast qui dure une heure (voire 5h30), rendant encore plus problématique un bête besoin comme celui de revenir d'une minute en arrière dans une interview.

Il était évident que garder la time-line contrainte entre les deux boutons ▸︎play/⏸︎pause et action n'était pas une super idée graphique : Je perdais environ 2×48 px en largeur disponible, ce qui n'est pas négligeable quand on a moins de 320 px de large.

Pour reprendre l'exemple de mon blog, la time-line fait 195 pixels de large soit 18 secondes par pixel pour un sonore d'une heure

Il m'a fallu jouer une fugue en CSS mineure pour que cette barre bascule en-dessous de ces boutons pour gagner en largeur. Comme je voulais aussi garder l'indication des longueurs de chapitres (les lignes noires discontinues), je considère qu'elles deviennent transparentes aux actions pointeurs en dessous d'une certaine largeur d'écran, pour éviter un appui malheureux dessus.
Oui, si c'est conditionné avec un breakpoint, c'est que j'ai utilisé une propriété CSS qui influe les interactions du curseur avec des éléments. Cette propriété qui tient de la magie vaudou mérite votre attention : pointer-events : none;

Retravaillée la time-line fait toute la largeur du web component, 291 pixels de large soit 12,4 secondes par pixel pour un sonore d'une heure.
Vous noterez aussi que les deux boutons ont perdu un poil de hauteur et que la place laissée au timecode dans la liste des chapitres est devenue élastique ce qui permet de gagner des lignes dès la première entrée.

Comme l'utilité d'une telle finesse est moins pressante sur de plus grandes largeurs, qui correspondent en général à des ordinateurs avec des dispositifs de pointages plus précis (le doigt occupant une fraction moins importante de l'écran, ou ayant un stylet voire la souris), la disposition entre les deux boutons revient au-delà d'une certaine largeur.

Deviner où l'on vise d'un coup d'œil

On le voit sur la capture au-dessus, j'ai fait apparaitre sous la time-line une indication pointilliste des chapitres. Elle existait depuis un an, mais uniquement dans les grandes largeurs. Celle-ci est désormais aussi visible sur les petites largeurs, mais il n'est pas dit que tous les utilisateurs de mon script vont penser à renseigner un manifeste de chapitrage au format WebVTT. On en reparlera dans un chapitre à part, j'ai beaucoup à dire sur le sujet ; si cela vous intéresse, vous pouvez déjà vous amuser avec mon éditeur en ligne.

Pour aider visuellement à sa navigation, j'ai ajouté une fonctionnalité qui permet d'afficher l'enveloppe du son. Il s'agit d'une option, disponible via l'attribut waveform="".

Pour des raisons évidentes de performances, l'image de l'enveloppe en question est pré-générée au moment de la compression du sonore en PÀD (prêt à diffuser). Afin de tester la fonction et de donner un exemple fonctionnel dans ma doc, j'ai profité d'une fonction méconnue de l'utilitaire en ligne de commande sox, véritable couteau suisse pour travailler du son avec le minimum de dépendances. Un script qu'on trouve souvent dans des chaines de publication audio industrialisées sur des serveurs de rendus.
Anecdote : j'ai utilisé cet outil en 2004 pour faire des messages de répondeurs personnalisé par prénoms et pour biper des ringback tones. Un script de 20 lignes permettait à des ingés son de gagner des journées de travail en supprimant des silences superflus, concaténant des sons et normalisant le rendu.
L'option pour générer ce graphique est spectrogram. Par rapport à la traditionnelle vue de la courbe, elle permet de mieux distinguer les voix et les musiques sur une très petite hauteur, ici 8 pixels de haut. C'est pas toujours vrai et c'est surtout un choix personnel, il est susceptible d'évoluer plus tard.

Comparaison entre une vue d'une forme d'onde (en haut, niveau sonore en ordonnée) et un spectrogramme (en bas, fréquence en ordonnée) de l'émission 🍺 Bière

Naviguer plus finement

Reprenons les problématiques de la navigation sur smartphone : L'écran est tout petit, et notre doigt est démesurément gros pour essayer de se placer précisément. Et donc nous avons toujours le problème de la navigation fine, quand on veut revenir de quelques secondes en arrière.

J'étais parti sur l'idée qu'un appui long sur ma time-line est une tentative pour se placer finement. Ben oui, ça m'arrivait plusieurs fois d'appuyer à un endroit du player, puis de bouger délicatement mon doigt en le faisant pivoter, tout en approchant de près mon smartphone et en tirant la langue afin de contrebalancer le manque de précision… ce qui me rendait totalement idiot dans le bus.

AHEM !
Une requête pour afficher la navigation alternative, nous disions.

L'idée étant évidemment de suivre l'analogie UX de la blague de l'interface : s'il faut l'expliquer à l'utilisateur, c'est que ton interface n'est pas bonne.

j'ai mis des boutons, juste pour voir si la requête en question marchait. Mais j'avais pas forcément idée de le garder. J'avais même réfléchi à zoomer la time-line avec des mouvements genre pinch-in/pinch-out (pincer/étendre), mais je me suis rendu compte que ce n'était ni intuitif, ni pratique, voire complètement frustrant sur iOS : le pinch-out à une certaine ampleur peut vous sortir du navigateur web pour aller vers un sélecteur d'applications (Un parti-pris d'Apple très con et totalement frustrant quand votre appli utilise le pinch, justement).
Et comme mon web component a aussi pour objectif d'être repris, hors de question de risquer une contradiction parce que le site hôte a déjà son usage du pinch-in/pinch-out.

Donc finalement, supposer qu'un appui long sur la time-line est une demande explicite de l'utilisateur vers plus de précision, me semble pas trop erroné.

Mettre des boutons ⏮ ◂◂◂ ◂◂ ▸︎▸︎ ▸︎▸︎▸︎ semblait pas trop pourri.

J'ai dit semblait, une fois de plus, je dis pas avoir raison.

La mauvaise surprise du temps

J'ai tenté de mettre une entrée de temps, utilisant un champ <input type="time">, yep, icelui : . Après tout, les smartphones ont en général un excellent sélecteur de date et d'heure.

Le sélecteur d'heure d'Android, extrait de l'excellent article sur <input type="time"> de Mozilla Developer Network.
Une chouette analogie aux vieilles horloges à aiguilles, compréhensible parce que des équipes de Google (comme Microsoft, Apple et Mozilla) ont investi des milliers d'heures sur ce problème à votre place.

Sauf qu'il y avait un os ! J'ai pris un sélecteur d'heure, faute d'avoir un sélecteur en HTML5 pour exprimer une durée. Ce qui veut dire que… l'heure peut afficher au format 12 heures avec une locale américaine ! Et impossible de le localiser de force avec un attribut comme lang="fr".

Tiens, si je règle un champ time à 0h1mn23s, dans Firefox avec l'interface paramétrée en Français, vous aurez :

bon là, vous m'comprenez si vous me lisez en Français

Et avec l'interface paramétrée en Anglais Américain (en-US), qui est l'interface par défaut pour beaucoup de monde :

Tempora mori, tempora mundis recorda comme dirait le roi de Loth,
ça veut pas du tout dire la même chose, et surtout pas une durée

En fait, il n'y a pas de règle uniforme du comportement basculant entre les affichages en 12 h ou 24 h : certains navigateurs se basent sur la langue de leur interface, d'autres celles du système d'exploitation (heureusement, le DOM expose au javascript une représentation unique au format 24 heures, idem pour l'envoi d'un formulaire à un serveur, sinon je serais devenu fou).

J'avais le même souci dans mon éditeur de chapitrage puisqu'il utilisait le même type de champ. Pour le résoudre, il suffirait d'écrire un polyfill d'affichage agissant sur un champ <input type="time"> caché… ouaip, ça craint.
Ben j'ai écrit une mécanique différente.

En résumé, pour un champ natif de durée, il manque :

soit un type de champ <input> pour gérer la durée, une décision à prendre au niveau du W3C ;
soit le respect de la propriété lang="" dans les contrôles, ce qui peut être implémenté par les navigateurs mais peut poser des soucis d'UX ;
soit la possibilité de styliser un champ <input type="time"> dans sa présentation et son interface pour basculer entre les modes 12 et 24 heures, une décision qui peut être testée par les navigateurs par une propriété CSS préfixée expérimentale avant standardisation.

Néanmoins, je n'étais pas satisfait de cette navigation alternative.

L'enfer des petits détails

La barre de navigation alternative apparaît quand on clique plus de 400 ms : au-delà, Chrome sur Android et surtout l'affreux iOS considèrent que l'utilisateur veut une autre fonction, genre sélectionner du texte. Alors qu'on a déjà désactivé la sélection de texte. Le pire étant iOS qui va lancer un sélecteur d'application qui n'a rien à voir.
À noter que pour les ordinateurs de bureau, il est possible de l'afficher en faisant un clic droit à la souris sur la time-line (la fonction normale est disponible en combinaison avec ⇧Shift).

Voilà où en était mon brouillon, que j'ai finalement gardé. Ici en faisant abstraction du champ input type="time" pour ne pas plus vous distraire avec…

Pour être le plus standard possible, j'ai créé des boutons ◂◂ et ▸︎▸︎, calqués sur les appuis de touches ← et → tels qu'interprétés dans mon web component (faisant des sauts de 5 secondes, durée paramétrable) , ainsi que ⏮ sur la touche ↖. Puis j'ai ajouté ◂◂◂ et ▸︎▸︎▸︎, qui font comme ◂◂ et ▸︎▸︎, mais répétés 4 fois.

J'ai tenté ce sélecteur, mais design liquide oblige, j'étais obligé de cacher certains boutons qui me semblaient moins utiles, d'un usage moins fréquent. notamment ◂◂, un choix décidé grâce à une technique scientifique de pifométrie, ce qui une fois de plus, vaut ce qu'il vaut et que je n'ai pas forcément eu raison.

Dans la plus petite largeur recommandée (320 px de large, soit un iPhone 5 en portrait), on a l'essentiel utilisable

Mais ces boutons étaient câblés sur l'événement click (clic de souris). Vous cliquez, l'avance se fera. Une fois. Ça serait cool de rajouter la répétition, non ? Tant que vous ne relâchez pas, l'action continue au même rythme.

Donc au final, j'ai dû écrire un gestionnaire d'appui-long/répétition pour 4 boutons, avec un mode de fonctionnement proche d'un clavier de bureau : Une première attente (400 ms) avant de commencer à répéter, puis répéter l'action sur des intervalles nettement plus courts (100 ms). Des durées paramétrables par le site, car je déteste les constantes magiques au milieu du code, et pour qu'un webmaster qui n'aime pas les réglages puisse faire mumuse avec, comme ça, il se sentira plus fort.
Ouarf.

Peut-être pouvait-on faire une accélération de l'avancée en fonction du temps qu'on appuie sur le bouton, mais je ne suis pas sûr qu'un tel système à accélération progressive soit pratique.

Bref…

In fine, j'ai travaillé les fonctionnalités sur mon lecteur audio pour qu'il soit aussi pratique à utiliser sur un ordinateur de bureau que sur smartphone.

Je ne garantis rien. Maintenant reste le plus difficile : en faire autant sur la navigation fine pour l'accessibilité.

En plus de la navigation fine, il faudrait aussi parler du chapitrage audio, mais le sujet est très vaste, il interviendra après qu'on ait parlé de Web Share...

Reconstruire son lecteur audio pour le web

Da Scritch — 2018-11-06T12:25:00+01:00

Ou comment j'ai bricolé longtemps les pages web pour mettre du son, les différents players que j'ai essayé, que j'ai écrit et la livraison du petit dernier.
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de ses versions 5 et 6.. Dans cette série :

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web (sur la version 5)
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

TL;DR Trop Long; Vous ne lirez pas ?

La démo du player :

Si vous voyez ce texte, c'est que le lecteur ne s'est pas lancé, très probablement parce que vous ne lisez pas mon billet depuis mon blog
Sauter au milieu de ce sonore d'un simple lien, même en dehors de la page
Une autre démo avec les chapitres
Le repository github du player
Le site de démonstration du player, n'hésitez pas à tester le configurateur et l'édition de chapitres
et tout ça pour une émission radio

Et si on étendait ce tag ?

Mais revenons au moment où on a déclaré deux sources de sons, ce qui permettait le support par la totalité des navigateurs web supportant l'<audio>.
Ladite balise ne venait pas seule : Elle était accompagnée d'une API très riche, permettant de suivre l'état de chargement du fichier, de changer le volume sonore, de connaitre la position actuelle de lecture et même de changer la vitesse de restitution ! En fait, rien ne vous interdit de ne pas afficher l'interface native et de construire la votre derrière.

L'occasion était trop belle : je changeais d'émission radio en lançant CPU et je lançais plusieurs projets liés en parallèle. L'idée étant que les contenus produits pour l'émission radio servent comme cas d'usage pour les projets afférents. L'occasion d'explorer ce que l'on pouvait explorer en production et en ~~consommation~~ écoute d'émissions radio sur internet et de jouer avec les spécificités d'une émission radio par rapport à un pure player audio du web.

Un de mes projets était de reconstruire un player audio au look un poil passe-partout, partageable/réutilisable avec d'autres sites, pour proposer des idées comme une playlist partageable.

Pointer dans le temps

En fait, l'écriture de ce player était une évolution d'une autre bibliothèque de mon crû : j'interceptais déjà les liens d'une page pour lier vers un moment dans le sonore d'une page, ce qui est bigrement utile…

Un menu contextuel de Firefox, généré par ma bibliothèque timecodejs, permettant de récupérer une URL pointant sur le moment du sonore pointé par le menu contextuel.

…et prévu par un standard du W3C depuis 2009, les media fragments !

L'idée est simple : transposer dans le hash d'une url le principe de segmentation des paramètres query par un &, et utiliser les paires clé=valeurs, les valeurs étant séparées par des virgules clé=valeur,valeur. Le hash n'est interprété que par le logiciel client (le navigateur web), charge à lui d'optimiser finement la requête avec le serveur, en utilisant les requêtes partielles Content-Range, répondues par des HTTP 206 Partial Content.
Et, beauté de la dégradation élégante, si le hash n'est pas compris… il est simplement ignoré.

Il existe de multitudes de fragment de média possibles. Ainsi, si je veux afficher un bout de carré d'une grande image à partir des coordonnées (80,160) sur un carré de 80×80, je ferais un <img src="https://dascritch.net/post/2018/11/06/image.jpg#xywh=80,160,80,80" alt="" />.
Vous trouvez qu'il y a comme une similarité avec les sprites ? L'idée partait justement de là.
On retrouve des stratégies équivalentes pour les polices de caractère mais qui n'étaient pas décrites dans ce standard-là.

Soyons honnêtes : À ce jour, en natif, seules les vidéos sont considérées.
Et le standard n'a jamais été implémenté pour les sonores dans les pages, considérant que le chargement fragmenté via les requêtes Content-Range pouvait y palier. (Tu parles ! ça marche efficacement que pour les sonores encodés en CBR, sinon on tourne à la pifométrie, mais j'en causerais dans un autre billet).

Car oui, trop longtemps on a oublié que le web a été conçu pour lier entre eux des documents d'une manière pérenne, que le web sémantique va de pair avec l'espace d'adressage où est le document et qui existe à l'intérieur du document, et qu'on a la technologie pour lier à des chapitres (si on pense à utiliser le nommage id="", j'ai écrit un outil pour vous aider)…

Importance du web documentaire : les hyperliens autour de la page de garde de Wikipédia

…mais si ces technologies sont très bien implémentées pour du texte, voire des vues pour certaines PWA, il n'y avait à l'époque malheureusement aucune implémentation propre et standardisée dans les navigateurs pour lier un sonore ou une vidéo embarqué dans une page à un moment très précis via une URL. Ce qui pose de sacrés soucis, par exemple quand on veut pointer une phrase dans une émission de 4 heures. Oui, je fais parfois des émissions avec 4 heures de parlotte, et elles sont très très bien.

Il existe néanmoins des implémentations de la notation t=<secondes> sur des médias au sein d'une page sur des sites à très fort traffic :

Vimeo et Soundcloud l'utilisent dans la partie hashtag, comme je le fais (…#t=10) ;
Youtube et Peertube en sont très proches mais l'information temporelle est placée dans les paramètres de l'URL (…?t=10), charge aux serveurs de vous envoyer une page directement au bon repère, et qui impose d'intercepter les modifications d'URL plutôt que seulement ceux du hash (exemple dans les chapitres de cette vidéo de Ça Fait Écho).

À noter que plusieurs notations sont autorisées pour le timecode en valeur de t= : notamment le nombre de secondes, ou la notation SMPTE HH:MM:SS.FFF très utilisée dans le monde professionnel (avec des frames d'une durée d'un millième de secondes).

Bonus que j'ai ajouté dans ma petite bibliothèque : quand on quitte une page avec un tel sonore par inadvertance (lien, formulaire, chat qui saute sur Alt et F4), ben si je fais ←back, ou si la page s'ouvre avec exactement le même sonore, j'aimerais bien qu'il reprenne exactement là où je suis. Ça serait la moindre des choses, non ?

Voilà qui m'a écrit…

Mes règles de base :

être toujours au plus près des standards, pour ne plus revivre l'enfer d'avant leur respect, et avoir un code qui restera fonctionnel dans le temps ;
minimalisme de code, pas de bibliothèques/frameworks externes (JS ou CSS), si on s'appuie sur un framework, vous ne pourrez jamais virer cette béquille et elle vous posera des problèmes à l'avenir ;
si besoin de code externe, appliquer les polyfill les plus proches de ces mêmes standards ;
pouvoir le développer avec le moins d'outils tiers (genre Bower, Less, etc...). Tout au plus des linters et des compresseurs JS et CSS ;
par dégradation élégante, pouvoir fonctionner sur des vieux tromblons de plus de 2 ans au minimum ;
que le lecteur natif du navigateur web puisse fonctionner et s'afficher même si votre javascript est complètement planté, car si votre site de contenus ne présente aucun contenu sans javascript, c'est qu'il est sémantiquement mauvais ;
un design liquide, pour s'adapter à tous les styles et largeurs ;
assurer un minimum d'accessibilité ;
rappeler l'importance d'un bon web sémantique.

Le papa player

Alors tout ça, je l'ai braficotté dans mon coin dans une petite bibliothèque javascript. Elle faisait ça :

Le player “ondemiroir” dans deux résolutions

code javascript avec l'excellent framework vanilla js
en liquid reponsive web-design,
avec i18n (internationalization, baille ze ouéy excuse my french)
affichage de pochette
ajout de lien vers la page canonique du sonore
navigation au clavier dans le sonore
reprise à la volée si on a quitté le sonore (donc la page) inopinément au même endroit (très utile quand on lit la dernière émission dans la home du site CPU.pm, puis qu'on clique sur la page de l'émission)
partage sur des réseaux sociaux avec le moment en cours
avoir un contrôleur cloné pour l'entête fixé (qui apparait quand le lecteur principal n'est pas visible)

À l'usage, notre player est réellement devenu un outil très utile pour dérusher les émissions, et pas que pour moi, mais aussi pour les journalistes qui ont participé à l'émission.

Mais le code de génération est assez.. dégueu...
En plus, je voulais tenter un système de playlist centralisée (pour tous les podcasts de la radio), qui impliquait de charger la lib JS depuis un domaine précis. Très grosse erreur.

je voulais rafraichir mon projet avec les Web Components. En fait, je voulais le faire avec dès 2015, quand je lançais l'émission, sauf qu'à ce moment-là, l'ensemble Web Component n'est pas encore gravé dans le marbre et les implémentations parfois masquées dans les navigateurs.

Les WC étaient fermés de l'intérieur

J'ai jamais vu une discussion sur les WC qui n'est pas partie en couille
(@myagoo, in slack communautés-toulouse )

Bon, on va pas troller, on va y aller simplement :

L'idée des Web Components est dans l'air depuis 2012. Il a commencé par être implémenté dans Chrome avant que le standard soit correctement validé. Puis nous eûmes soit des implémentations avec leurs propres API et concepts (ReactJS, VueJS,…) , soit des polyfills plus ou moins proches des standards (Polymer,…)
Le choix d'un polyfill au plus proche des standards me semblait évident, et je voulais utiliser le génial Bosonic de mon camarade Raphael Rougeron.

Si je radiographiais le code source d'un Web Component, je verrais ça :

<template>
  <style>
    …
  </style>
  …
</template>

<script>
  class TonElement extends HTMLElement {
      constructor() {
      }
      …
  }
  window.customElements.define('ton-element', TonElement);
</script>

Un motif HTML, un stylage CSS et une classe javascript pour piloter le module.
Dans l'idée de départ, le tout était enregistré dans un document .html importé dans ta page via <link rel="import" href="https://dascritch.net/post/2018/11/06/webcomponent.html" />

Et dans ta page, tu l'appelles comme ça :

<ton-element>
</ton-element>

Le choix de nommage est assez malin car le standard impose dans le nom d'utiliser un -, afin de ne pas se marcher sur les pieds ultérieurement.

Les Web Components sont formidables

Et en quoi ils vont nous être bigrement utiles :

ils présentent un ensemble d'API totalement standardisées par le W3C, dans 10 ans, le code tournera encore ;
ils obligent à concevoir un design atomique : réfléchir non plus en terme d'aspect global d'une page comme on le fait pour un site, mais en briques élémentaires, indépendantes, donc réutilisables ailleurs ;
ils peuvent se passer des frameworks de rendus pour les intégrer ; fini la panique de mettre à jour bloated code, ranger ReactJS à côté de MooTools dans l'étagère du fond ;
il sont isolés du reste de la page avec le Shadow DOM, une API document fragment d'un DocumentRoot (comme une iframe) appelée shadowRoot. L'isolation peut être stricte, mais laisse la possibilité de discuter par des points d'entrée ;
ils n'ont plus besoin de CSS reset pour nettoyer les règles venant de la CSS du site, ou de filtrer des événements sur des tagNames. À noter que les variables CSS3 passent, on s'en servira ;
leur insertion est simple au possible, à condition que le développeur pense à la dégradation élégante ;
mais ils peuvent inserer des éléments déclarés dans leur code d'appel HTML, ce qui permet une dégradation élégante si le Web Component n'est pas fonctionnel ;
ils disposent d'une mécanique standard pour l'inclusion et la suppression d'une instance d'un Web Component dans une page, déjà cablée sur tout manipulation d'éléments, ce qui facilite la gestion mémoire sur les Single Page Application ;
comme la version de javascript imposée accepte les extensions de classes, on peut construire des héritages de web-elements.

En fait, un Web Component, vous vous en serviez sûrement des prototypes via <input type="date">, <input type="range">, le tandem <summary>/<details> ou encore <video controls> , car les implémentations natives de ces composants dans les navigateurs datent à peu près de cette période.

Dégradation élégante

Pour moi, il me semblait absolument évident que le script doit être capable de ne pas fonctionner sans bloquer l'accès au contenu publié. Il y a milles et unes raisons que cela arrive :

La bibliothèque ne se charge pas,
votre code est bugué,
le navigateur client n'a pas toute les fonctionnalités nécessaires,
le visiteur bloque volontairement tout javascript pour des raisons hygiéniques,
le web n'est pas parcouru que par des navigateurs webs connus et le Google-bot.

Il faut donc que le lecteur audio natif reste fonctionnel, mais qu'il soit facilement capturé et caché par le Web Component. Et ses propriétés d'invocations sont extrêmement intéressantes :

<cpu-audio>
  <audio controls>
  </audio>
</cpu-audio>

Sur un navigateur ancien, la balise du Web Component sera toujours interprétée, mais le navigateur ignorera sa signification sémantique. En fait, elle serait vue par un <div> que ce serait pareil. C'est un fonctionnement d'intégration par fallback qui a toujours été prôné par le W3C et qui est utilisé dans les exemples plus haut avec <object> et <audio>, et c'est ce qui permet de garder un minimum de support le temps que les navigateurs clients soient renouvelés.
La balise <audio> que j'y ai mis serait du coup intégrée normalement, et son interface graphique normalement affichée, invoquée via l'attribut controls.

Les précédentes opérations ont lieu sur un navigateur moderne, sauf que la classe TonElement liée à la balise sera invoquée via sa méthode constructor() ; méthode qui insère le shadowDom (l'interface graphique), lance les interactions avec cette interface, et retire l'attribut controls de la balise <audio> pour la cacher.

J'avais néanmoins besoin, même si les API Web Components n'étaient pas supportés, qu'un navigateur daté profite néanmoins de la fonctionnalité d'adressage dans le temps du sonore. Ce qui voulait dire avoir une vraie politique de développement en amélioration progressive et pour cela, il fallait isoler du code ce qui concerne purement cet adressage et la gestion de l'interface graphique. Bon, dans les faits, tout n'est pas proprement isolé, mais l'essentiel y est.

Brique-olons

Chrome avait une excellente démonstration du ShadowDOM v0 mais avait des petites craditudes derrières. Il y avait aussi la possibilité d'insérer des variables dynamiques dans la CSS et le HTML, mais l'implémentation jouait avec des rafraichissement continués en écrivant directement dans le .innerHTML, avec donc d'énormes soucis de performances. Mozilla avait sa propre implémentation, les X-Tags, qui n'étaient vraiment pas facile à prendre en main. Enfin bref, fallait implémenter de façon très expérimentale, des fois pas accessible par défaut, car on allait changer pas mal de paradigmes sur lesquels les navigateurs web étaient construits.

Puis virent les BONNES nouvelles : ShadowDOM v1 fut enfin finalisé. Chrome en fit une implémentation propre. Et l'équipe de Google proposa un polyfill, WebComponentsJS, qui était vraiment au plus proche du standard des Web Components, à se demander quel intérêt on a encore à utiliser le framework Polymer.
Bon en fait, WebComponentsJS n'est pas parfait, notamment il crée des javascript inline pour émuler les HTML import et les inclusions… une réponse extrêmement mauvaise en terme de sécurité car on doit alors réduire les Content Security Policies de son site, et pour moi, réduire les fonctions de sécurité est une ligne rouge.

Il fallait attendre patiemment les implémentations natives qui n'allaient pas tarder. Le navigateur multi-plateforme qui était apparemment le plus en retard était Firefox, l'implémentation native était là, activable par des paramètres cachés car pas encore considérée comme suffisamment solide. En fait, Mozilla attendait une stabilisation de l'API, dont leur implémentation était cachée jusqu'à Firefox 63 quand il était en version nightly.

Étonnement, Safari était assez vite prêt, Apple n'étant pas pressé de rendre le web aussi puissant que les applications natives.
Il reste le support de Edge, qui habituellement adapte bien plus vite les standards que Safari. Je tiens de source sûre que Microsoft le proposera pas pour la fin de l'année, car le support demande une refacto assez conséquente.

L'interface

Voici un exemple de l'interface en mode large :

Euh.... vous savez quoi ? Vaut mieux vous le montrer en vrai :

Pas de bol, votre navigateur ne supporte pas les Web Components

Mais voici une capture écran de ce que vous manquez :

On voit le panneau horizontal standard avec la pochette, le bouton lecture/pause, le titre qui renvoie à la page canonique, le temps écoulé, la timeline (où l'appui long entraine l'apparition du mode de navigation smartphone) et le bouton d'action.
Et le panneau optionnel de chapitrage.

Pour ceux qui ne peuvent l'afficher, ou pour les archivistes du XXIII^ème siècle, deux captures du player, une en largeur normale, et une autre dans une largeur de smartphone. Captures de début octobre 2018.

La puissance du chapitrage

Dans les fonctions qui sont hyper-pratiques et donc je suis fier, il y a le support des chapitres.

Normalement, il existe la possibilité de chapitrer un fichier mp3/mp4 MAIS chaque format audio a sa propre spécification et il n'est pas dit que si un sonore a deux sources différentes, qu'elles soient raccord sur les déclarations de chapitres, et donc d'avoir des données uniformes. De même, un des problèmes les plus récurrents est que celui qui a encodé le média ne pense pas toujours à vérifier que les métadonnées soient en début de fichier, car certains encodeurs partent dans l'idée que vous voulez faire du vrai stream, sans début identifiable, et donc le chapitre déclaré au moment où il apparait (c'est comme ça que les radios transposent les informations contextuelles RadioText du RDS dans leur stream mp3 sur le net).

Un sac de nœuds ? Non. Il se trouve qu'il existe un standard du W3C (dérivé des fichiers de sous-titres .srt , donc... issus du piratage, mais chut) : Les WebVTT. Et pour les exploiter, une API standard parfaitement supportée par les navigateurs peut prévenir quand on entre ou sort d'un de ces chapitres.
Il est probable que vous les ayez déjà vus à l'œuvre dans une vidéo… sauf qu'ils sont quasi jamais utilisés en audio, et donc sans interface utilisateur dans le navigateur… Jusqu'à maintenant.
Pour des raisons éditoriales, l'interface des chapitres est activée sur mon blog, pas sur le site de CPU.

De même, le player intègre désormais une fonction playlist dans une page : si une balise termine sa lecture, la lecture d'une suivante peut démarrer dans la foulée.

Ce que j'ai appris

Plein de méthodes du DOM que je ne connaissais pas, et qui m'ont facilité le travail. Une fois de plus, on ne relit jamais assez les standards du W3C, sachant qu'ils font actuellement plusieurs milliers de pages. Une de mes découvertes, par exemple, me permet de gérer le blocage des lectures de son automatiques introduits depuis Avril 2018, document.hasFocus() m'évite de lancer une lecture trop tôt et d'attendre que le visiteur a cliqué dans la vue de ma page.

Plein d'événements et autres subtilités sur des balises HTML que je croyais connaitre. Comme quoi, on ne relit jamais assez les documentations officielles.

Utiliser les variables CSS3 pour pouvoir customiser l'aspect du Web Component de l'extérieur sans avoir à bricoler le code ou mettre trop d'attributs HTML dans la balise d'appel.

Modifier du balisage sur les billets descriptifs de 95 émissions de CPU.
J'avais prévu de cacher la liste des chapitres si elle a été chargée et affichée par le lecteur. À la main, et plus d'une fois, pour finalement ne pas m'en servir de suite. Quand vous allez dans vos toilettes avec votre laptop, y'a comme un signe. J'ai tiré une croix pour les 390 Supplément-Week-End et tous les autres émissions archivées. Moralité : toujours déclarer des id="" par blocs reproductibles suffisamment tôt et s'y tenir, ce qui aurait permit d'automatiser ces modifs triviales.

Garder une séparation entre les sources HTML, feuilles de style et javascript.
L'implémentation de HTML Imports restera dans les limbes pour des raisons de sécurité. Heureusement, on peut faire sans, tout en gardant la possibilité de séparer le <template>, le <style> et le javascript : Pour cela, j'ai écrit un make.sh maison crade, certes, mais il fait le taf avec un minimum d'environnement, et je vous invite à participer, il est dans le repo de ce projet.

Avoir attendu 2018 pour développer la nouvelle version m'a permis de bénéficier de :

API enfin stabilisées et réellement standardisés ;
meilleur support de ces standards dans les navigateurs ;
par amélioration progressive, pouvoir toucher 50% d'audience ayant un navigateur à jour de moins de 6 mois (et avoir au moins deux navigateurs cibles multiplateformes) ;
n'utiliser aucun polyfill ;
modulariser pour avoir un fonctionnement possible sans le support des Web Components ;
usage des variables CSS3, ce qui permet de pouvoir personnaliser plus facilement le player ;
relevé deux bugs dans Firefox, 1476302 et 1476301 (yay !) ;
passer mes serveurs en HTTP2, mais sans le mode push, faute d'un support correct du mode HTTP 206 Partial content ou de pouvoir désactiver le push en fonction du type-mime ;
résoudre le problème posé par le blocage des autoplays sonores par Chrome (mars 2018) et Firefox (Octobre 2018).
étoffer la doc et proposer un outil de configuration live et d'édition des chapitres

Je me suis néanmoins planté

J'ai perdu un contributeur (désolé NerOcrO) car j'ai repris le projet ondemiroir-player de zéro à grands coups de copiés-collés et je l'ai surtout annoncé beaucoup trop tôt avant de pouvoir prendre des tiers. Cela a toujours été ma peur bleue quand j'ouvrais mon code, et le meilleur moyen est d'écrire suffisamment tôt une guideline des contributeurs pour que les règles soient posées d'entrée.

Il y a toujours ce souci insupportable qu'il est impossible d'essayer Safari sur iOS sans avoir un iPhone/iPad sous la main. Et d'expérience sur les interfaces, un émulateur peut être vraiment trompeur. J'en veux pour exemple le mode émulation d'appareils mobiles de Chrome à qui il manque des API telles que navigator.share. Alors payer pour un émulateur en ligne… ahem…

Et tout ça pour arriver trop vite, ayant quasi-terminé 6 mois avant de pouvoir lancer mon player :/ Les Web Components totalement fonctionnels sont arrivés dans Firefox 63 sorti officiellement le 23 Octobre, bien après Chrome et Safari, mais la version LTS (Long Term Support) actuelle est Firefox ESR 60 et Tails utilise une version encore plus vieille. Ce qui veut dire que Firefox ESR et Tails vont voir le nouveau lecteur dans sa version fallback un petit moment : pas avant juillet 2019.

Eh oui, le support à long terme est souvent synonyme de… long tail

Je terminerai par un tweet de @mariejulien (le gars des badges en tissu) lors de Paris Web

Question de @SkyNebula à #parisweb sur comment contribuer au libre quand on est designer, début de réponse "déjà tu peux voir si y'a un contributing md sur le repo…" 😅🤗

Vous le voyez toujours pas le problème ? Tout le monde n'utilise pas des outils de dev. Get over it. 😁

… ce qui m'a fait écrire le message d'accueil aux contributeurs extérieurs AUSSI pour les non-développeurs. Ne serait-ce pour les traductions, le graphisme, la doc, etc… Il faut que je complète encore pour expliquer comment faire sans avoir à installer d'outils via le site web de Github, notamment l'épineuse question des localisations (utiliser les .po ? un tableur ?).

Ce qui m'amène à…

L'avenir imaginé pour mon lecteur

Oui, je sais, il ne faut pas documenter le futur d'un produit. Néanmoins, voilà ce que j'aimerais faire :

avoir un vrai travail de design et d'accessibilité, et le documenter ;
résoudre le problème du positionnement fin en tactile sur smartphone : la barre de progression n'est bien qu'à la souris sur ordi, on compense la précision par le clavier. Aucun de ces dispositifs sont sur portable… j'ai prévu une interface avec des boutons en appui long sur la timeline (ou click droit à la souris), mais c'est pas encore ça ;
le support des règles CSS en fonction de la largeur d'un élément ; @element est prête pour moi, mais implémentée nulle part ;
plus de tests de non-régression ;
encore plus de tests ;
documenter encore plus ;
construire en même temps que la compilation des add-ons pour des CMS communs, notamment dotclear ;
créer des add-ons WebExtensions pour les navigateurs avec un ProtocolHandler custom pour basculer la lecture vers une application native (ex: VLC), et donc gérer les touches multimédias, ou les copier dans une clé USB à emporter ;
créer des fonctions décentralisées, sur le modèle (ou basées sur) mastodon :
- pouvoir faire des commentaires comme pour SoundCloud mais de façon décentralisée ;
- pouvoir créer des playlists et les partager de façon décentralisé. Par exemple, lier des émissions qui ont la même thématique comme « Tout est numérique » d'Olivier Tesquet sur France Inter, « Libre à vous» de l'April, le podcast « NoLimitSécu avec la mienne, et les annoter ;
générer des infos côté serveur comme
- un spectrogramme ;
- découper en MSE API ou MPEG-DASH (Dynamic Adaptive Streaming over HTTP), notamment pour sauter plus vite à des fragments (mais y'a des brevets dessus) puis les navigateurs Chrome et Safari se montrent très mauvais dans le chargement partiel d'un sonore via les requêtes Content-Range ;
- avoir un système de pige automatique des textes, pour l'accessibilité aux sourds et malentendants. Je remercie infiniment le travail des bénédictins de l'April, se faire transcrire par eux est un honneur. Accessoirement, cela aide aussi au référencement naturel (sifflote) ;
traduire ;
supporter les localisations RTL (Right To Left), notamment pour les langues arabes, hébreu,… ce qui signifie renverser les icones, la timeline et.... les touches fléchées du clavier, eh oui ;
supporter la vidéo aussi ;
rester sous les 100Ko.

« Mais pourquoi t'embêter ? y'a les apps natives maintenant ! »

Alors oui, malheureusement, la plupart des utilisateurs d'internet sont désormais clients d'applications mobiles…

mais pour moi, le Web n'est pas mort !
Il est ce que nous en ferons : du partage, de l'accès à tous et dans le <a href="https://dascritch.net/post/2018/11/06/"> tous les lier. Il peut même remplacer fortement ces applications, éviter la fragmentation des langages et des frameworks, et conforter ses missions premières via les hyperliens et la décentralisation,…
Qu'on puisse mettre un marque page à un endroit, partager ce lien et donc le contexte à ses amis, dans ses billets de blogs, et retrouver le contexte si la page est publique bien plus tard (à condition que le site existe et qu'il a maintenu son plan d'adressage).

C'est un peu ce que je fais inconsciemment avec ce petit bout de code, qui ne sert qu'à une chose : rendre les sonores plus navigables et plus partageables.

L'étape suivant a été de travailler dans les petites largeurs.

Mettre de l'audio dans le web n'a pas été simple

Da Scritch — 2018-11-06T12:24:00+01:00

…alors autant raconter ce qui m'a mené à écrire un lecteur audio pour une page web.
Webdev

Cet article est dans la série consacrée au développement de la bibliothèque cpu-audio.js et documente les affres de ses versions 5 et 6..

Dans cette série :

Mettre de l'audio dans le web n'a pas été simple
Reconstruire son lecteur audio pour le web
Retravailler un lecteur web audio dans les petites largeurs
Le blues du Web Share (english version)
Deux couleurs bizarres en CSS
cpu-audio.js enfin en 7.0
Tout-terrain WebVTT pour de l'audio
Dichotomie entre podcast et web sur l'audience

J'ai eu une chance incroyable

L'année où j'ai eu mon bac, en 1993, je suis entré dans une radio associative, Radio <FMR>, au moment où elle faisait encore une audience d'importance, supérieure aux 3%. On entendait cette radio de punks dans les bars, les friperies et les magasins de disques. Je pensais faire le désespoir de mes parents, et à mon grand désarroi, j'ai appris que mon père avait bricolé le premier bloc émetteur.
Au même moment sortait Netscape, le premier navigateur web construit par un opérateur commercial. J'ai touché aux deux le même automne, inutile de vous dire que mes passions furent partagées entre les deux, et que j'ai souvent croisé les deux : j'ai toujours cherché comment un message était transmit pour l'adapter au mieux du support, voire hacker les deux.

Les premières pages web de Radio <FMR> sont datées de 1996. Et les sons furent mis en ligne quelques mois plus tard. Dès 1999, on a eu la première diffusion stream de notre antenne, qui était… un piratage amical.

Mais pour les sons à écouter, au début, nous n'avions que Quicktime (1991), Window Media (1991), Real Player (1995) et WinAmp (1997).

Real player 8 plus, un joli bloatware lancé pour écouter un sonore de 15 secondes

Et encore… au début, ces logiciels ne s'intégraient pas dans le navigateur, il fallait télécharger les sonores complètement, puis lancer le bon logiciel pour les lire, en le devinant depuis l'extension du nom de fichier ou le type-mime déclaré par le serveur. Des fois, ces logiciels de lecture devaient charger des drivers d'imports complémentaires car le format était plus ésotérique que prévu.
Et quand ces logiciels furent inclus dans le navigateur, les plugins n'étaient pas forcément disponibles partout : les versions manquaient selon les systèmes d'exploitations ou l'API plugin exposée par les navigateurs, et les méthodes d'appels en HTML variaient entre Internet Explorer et Netscape, les autres navigateurs hésitaient entre les deux camps. Inutile de vous dire que y'avait de quoi s'arracher les cheveux en tant que dev et en tant que surfeur des internets. D'où les sites web optimisés exclusivement pour Windows 98 avec Internet Explorer.

Je ressors cette image insoutenable, j'espère qu'aucune tentative de suicide n'aura lieu cette fois-ci.

Là où je tresse des lauriers à… Flash !

En 1996, Macromedia eu le bon ton de faire évoluer son logiciel Flash de l'animation de CD-Rom à un plugin navigateur pour presque toutes les plateformes. le plugin Flash devint vite extrêmement populaire, il était même installé par défaut avec presque tous les navigateurs dès 1999. Et pour la fonction qui nous intéresse, sa version 6 en 2002 a apporté la faculté de lire des fichiers .mp3 via des adresses http://.

Malgré l'urticaire que pouvait déjà provoquer Flash chez certains, cette fonctionnalité devint importante pour ceux qui cherchaient à intégrer du son dans une page web car elle permettait de pouvoir intégrer en presque un seul snippet de code HTML un lecteur mp3 qui serait lisible de quasiment partout. Ce qui tombait bien car le mp3 était devenu un format ultra-populaire sur internet grâce au… piratage… ahem.
Rappelons que l'iPhone n'allait arriver qu'en 2007, et qu'à sa sortie, tout le monde était persuadé qu'Apple négociait et installerait Flash Lite.

Sauf que les premiers lecteurs de son en flash prêts-à−intégrer dans son site étaient particulièrement lourds avec plein d'effets graphiques, voire des bannières publicitaires.
Heureusement, gloire à toi, Dew, il a fait un player audio ultra-minimaliste, dewplayer (miroir).

Différentes configs du dewplayer, capturé d'un site archive (normal, mini, multi-sonore et rect)
Image zoomé × 2

Revoyons ses caractéristiques :

Un bouton start ▸︎, un pause ⏸︎, un stop ⏹︎
Une barre de temps, indiquant la progression de chargement et celle de lecture
Pas de titre
Pas de gestion de volume sonore ou de mute
Pas de gestion de vitesse de restitution
4 aspects différents possibles
Couleurs paramétrables
4121 octets

Tu cliques, il joue le sonore, et pis cé tou. Le génie est dans la simplicité.

Un lecteur flash avec la même inspiration minimaliste, les actions lecture ▸︎ et pause ⏸︎ confondus dans le même bouton.
Image zoomé × 2

Mais franchement, ce satané plugin Flash n'était qu'un pis-aller : un logiciel propriétaire lié à une boite au code source fermé, une sécurité pas au top dans son insertion dans les navigateurs, et les appels affreux en HTML en fonction du navigateur. Sur le site de ma précédente émission Supplément Week-End (2004-2014), j'avais écrit à grand coup de commentaires conditionnels un code HTML qui se voulait universel, marchant aussi bien avec MSIE (Microsoft Internet Explorer) que le reste :

<!--[if IE]>
  <object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,40,0">
<![endif]-->
<!--[if !IE]> <-->
  <object type="application/x-shockwave-flash" data="https://dascritch.net/post/2018/11/06//interface/player_mp3.swf">
<!--> <![endif]-->
    <param name="src" value="/interface/player_mp3.swf" />
    <param name="FlashVars" value="mp3=zou.mp3&loadingcolor=304b5f&bgcolor1=ffffff&bgcolor2=e6f4ff&buttoncolor=304b5f&buttonovercolor=000077&slidercolor1=6096BF&slidercolor2=304b5f&sliderovercolor=000077" />
    <param name="wmode" value="transparent" />
    … (fallback pour ceux qui gèrent pas)
</object>

Oui, assez gerbant.

Entre les crises de nerfs, les mises à jour différentes entre plateformes et l'arrogance de Macromedia puis d'Adobe, cette solution ne pouvait qu'être provisoire.

Hosanna, résonnent les <audio> au plus haut du W3C !

Enfin arriva en 2009 la balise <audio> dans des navigateurs web en support natif. Facile, bien plus facile, kawaii ♥♥♥ :

<audio src="https://dascritch.net/post/2018/11/06/zou.wav" controls>
   … (fallback pour ceux qui ne gèrent pas)
</audio>

Mais c'était trop facile : parmi les manques dans la description des balises <audio> et <video>, aucun format de média n'a été imposé par le W3C aux navigateurs web, ni même un support minimum.

Code code code codecs : entre libres et payants

Pourquoi le W3C et le WHATWG ont-ils laissé un tel flou ?
Il se trouve que nous connaissions déjà une situation similaire avec les balises <img> figées dans un status quo empirique : les formats de compression les meilleurs sont payants, ils pouvaient rançonner le web tout neuf. Et évidemment, certains ayants-droits ont un peu poussé leur stratégie du coucou pour essorer la poule aux œufs d'or. Coucous donc à MPEG-LA, Microsoft (VC1), Apple et bien d'autres.
Une situation qui va devenir crispante pour certains webmestres qui doivent se soucier de la légalité de leur site (ceux qui pensent à l'achat d'art, et à créditer correctement les logiciels), jonglant entre les implémentations universellement utilisables et non-payantes (libres), sans trop dupliquer le même sonore.

Car oui, si vous ne le savez pas, jusqu'en 2017 l'usage du format mp3 (MPEG 1 layer III) pouvait vous être facturé, étant sous le coup de plusieurs brevets. C'est toujours le cas pour tout ce qui relève du MPEG-4, et d'ailleurs, si vous achetez une caméra professionnelle, il est écrit dans la doc que l'usage est strictement familial et qu'il vous faut acquérir une licence auprès du MPEG-LA pour tout usage à destination publique et/ou professionnelle.

Si si : Extrait du manuel de la caméra professionnelle Sony PXW-Z190, page 119 (garanti sans trucage) :

Ce produit est accordé sous licence, sous le couvert de la licence de portefeuille de brevets AVC pour une utilisation privée et non commerciale d’un consommateur pour :
(i) encoder des vidéos conformément à la norme AVC (AVC vidéo) et/ou
(ii) décoder des vidéos AVC encodées par un client dans le cadre d’une activité personnelle et non commerciale et/ou obtenues auprès d’un vendeur de vidéos sous licence AVC vidéo.
Aucune licence n’est attribuée ou ne doit être destinée pour tout autre usage. il est possible d’obtenir des informations complémentaires auprès de MPEG LA, L.L.C. voir http://www.mpegla.com

Pour une caméra professionnelle vendue à 4000 €, ne pas pouvoir utiliser les images tournées avec, ça fait un peu mal. BTW si vous souhaitez m'en offrir une pour les captations vidéos, je ne vous retiens pas :D...

Le MPEG-LA n'est pas un organisme de recherche, mais la structure juridique facturant l'usage des brevets liés aux formats MPEG, mis dans un pot commun par plusieurs sociétés. Il propose un ensemble de formules de facturations, allant du volume horaire de diffusion TV (cable, satellite et hertzien), au nombre de puces de décodage produites et au nombre de vues d'une vidéo sur le web. Pour donner une idée, Mozilla aurait dû payer à l'époque 9 millions $ par mois pour que Firefox puisse lire du MPEG sur les systèmes d'exploitations qui ne paient pas une licence, c'est à dire Linux, *BSD et consorts. Avec une telle somme, on pourrait financer d'autres projets logiciels.

D'où l'union improbable entre certains développeurs de navigateurs (Mozilla et Google en premiers) pour la conception commune de codecs libres. La reprise du Ogg Vorbis, le Ogg Theora puis spécifiquement conçus pour le web comme WebM, voire des implémentations en n'utilisant que des parties libérées de brevets (comme OpenH264 sponsorisé par Cisco pour que Firefox puisse faire de la visioconférence) et bien d'autres, etc… Sauf que ces licences libres ne sont pas disponibles sur tous les navigateurs et et manquent cruellement d'implémentations hardware. Les politiques commerciales des fondeurs de puces pour smartphones sont à blâmer.
Comme aujourd'hui, on parle surtout de son et vue la puissance de calcul de nos smartphones, on se contentera d'engueuler un navigateur web pour mobiles qui refuse d'inclure les formats libres populaires : Safari.

Évidemment, une telle fragmentation n'a pas aidé à voir se dégager un format de référence sans risque juridique pour ceux qui font des sites web. Donc on en vient à proposer au moins 2 formats de sonores différents.
Pro tip : proposez votre sonore encodé en mp4 ou ogg ou webm, puis terminez par une source encodée en mp3 traditionnel pour compléter le support, comme suit :

<audio controls>
  <source src="https://dascritch.net/post/2018/11/06/zou.ogg" type="audio/ogg; codecs=vorbis" />
  <source src="https://dascritch.net/post/2018/11/06/zou.mp3" type="audio/mpeg" />
</audio>

Et là, on a pu s'amuser quand il y eu un support correct des streams. Notamment avec le HLS aka Http live Streaming d'Apple, mais là aussi, il ne fut pas le seul protocole de streaming et il n'était pas supporté partout, avec des concurrents aussi clivants. À ce jour, l'API standard Media Source Extension n'est toujours pas supporté par les iTrucs d'Apple, malgré sa standardisation par le W3C.

Et tous ces soucis sont aussi survenus pour avec WebAudio par effet de Ric Hochet.
l'API WebAudio est l'équivalent fonctionnel de la balise <canvas> pour le graphisme : une feuille blanche adressable d'où l'on peut créer ou manipuler n'importe quel son.

Et la suite explique pourquoi et comment j'ai étendu la balise <audio>.

En 20 lignes pas plus : Le focus sur le champ de recherche

Da Scritch — 2018-08-17T13:42:00+02:00

Tout est une question d'accessibilité, donc de praticité de votre site web : moins y'a de clics, mieux c'est.
Webdev

Le site de mon émission CPU me demande parfois bien du temps pour résoudre des problèmes. Des problèmes d'interactions, des problèmes d'aspects ou d'accessibilité. Et pas uniquement parce que je fais ça sur mon temps de loisir, mais aussi parce qu'il vient après l'objectif de publication hebdo de mon émission, laquelle émission demande énormément de temps de préparation. Alors certes, je pourrais d'autant plus déléguer que je publie le source du thème Dotclear modifié, mais je fais aussi mes sites web pour acquérir de l'expérience, voire pour expérimenter.

Le problème dont je vais vous parler aujourd'hui, j'étais persuadé que j'allais le résoudre avec des déclarations HTML et du stylage CSS. Cela me semblait évident.

Et en fait, non.

Vous êtes ici

Dans le site de CPU, comme pour la plupart des sites à contenus, comporte 3 grandes régions fonctionnelles :

Il y a un layout de présentation générale, qui se veut minimaliste ;
une partie centrale de contenu, qui est l'intérêt de votre passage sur mon site, normalement ;) ;
et une partie secondaire de navigation censée permettre au visiteur de farfouiller dans le site si icelui l'intéresse (on peut toujours rêver).

Les 3 zones, dans une résolution confortable de bureau.

Cette partie secondaire se présente en sidebar si la largeur du navigateur le permet, sinon, elle est tout en bas de page, parce que je suis un fanatique du liquid responsive web-design. Peut-être que cette partie de navigation secondaire est trop présente et qu'il faille alléger son contenu, mais le débat n'est pas là.

La partie layout comporte un entête du site, un bandeau horizontal dont la hauteur est limité au logo de l'émission, et qui reste fixe en scrollant (merci display : sticky). Et comporte aussi une ligne de navigation rapide en 5 segments qui chapeaute le contenu et la navigation secondaire, laquelle disparait normalement en défilant.

Le header, la navigation rapide, et un exemple de contenu précédé de sa navigation contextuelle

La problématique

Ce qui m'intéresse, c'est mon lien Chercher, qui est un lien interne à la page et doit renvoyer sur le champ de recherche texte, lequel est situé dans la navigation secondaire. Et ce que je veux, c'est qu'en cliquant dessus, on voit le champ de recherche et qu'il aie le focus, pour qu'on n'aie plus qu'à rentrer des mots clés.

Je veux ça : Le champ de recherche visible, avec le focus.

Seulement, quand on cible un élément avec une ancre dans un lien, suivre celui-ci est censé faire ne sorte que l'élément entre dans la partie visible du viewport, et autant que possible, les navigateurs le mettront en haut à gauche. Et c'est pas le cas à cause de notre entête sticky qui cache le champ.

Du coup, on ne voit pas le champ texte. C'est ballot.

Note pour les experts : Cela aurait mérité de regarder comment se comporte la méthode Element.ScrollIntoView() et la toute nouvelle API IntersectionObserver.

Le laboratoire de Dexter

Donc, je me suis dit, tentons en appliquant une marge sur l'élément, pour qu'il sorte de sous le header.

#q { […] margin-top : 100px;; }

Sauf que : 1, c'est moche, le bouton OK se déforme, et 2, c'est inutile car le navigateur place l'élément sur le coin haut-gauche de son bord. excluant la marge.

du coup, le navigateur fera en sorte que le border soit collé en haut à gauche, mettant margin hors limites.

Donc, je me suis dit, appliquons les translations… pour voir…

#q { […] transform : translateY(200px); }

Ha ben oui, j'ai vu : ça fait effectivement le job, mais il faut alors appliquer tout un bazar pour décaler l'ensemble des autres éléments. On commence à entrer dans des crâderies qui feraient dégainer l'Inspecteur Dirty Hacky. Et il aurait raison tellement que ça pue.
Et puis, même si j'y serais arrivé, il faudrait toute la patience d'un vrai spécialiste CSS pour tout me remettre d'équerre. Donc, FBI : Fausse Bonne Idée.

Il existe une autre méthode, celle d'utiliser le pseudo-element :before, et du coup de lui appliquer une translation. Alors oui, cela marche, mais là aussi, j'ai un problème : le code n'a rien d'élégant à mes yeux.

Il y a un ensemble de propriétés CSS, scroll-snap points, qui semblaient intéressante, mais absolument pas pour ce que je voulais. L'idée est plus de faire une sorte de pagination et toucher le nirvâna du smooth-scrolling natif, ou, comme dans la démo du lien, faire des diapositives pour une présentation.
Note pour les experts, encore : le standard est encore en état de brouillon mais sa couverture commence à être correcte pour envisager de remplacer Reveal.JS EDIT : Cela a été fait par l'immense Nicolas Hoffmann. Je suis confus.

Le truc

Le truc n'est pas de cibler l'ancre de l'<input>, mais de son propre <label>, lequel a un padding-top confortable. Parce que vous avez été propre, et que vous avez positionné l'attribut for= pour lier le label à son champ, ce qui permet qu'en cliquant sur ce label, le champ prenne le focus clavier.

<form […]> <label for="q" id="search">Chercher avec un mot</label> <fieldset> <input type="search" id="q" name="q" /> <button type="submit">ok</button> </fieldset> </form>

Le problème, c'est qu'aucun navigateur ne songe à passer le focus au champ <input> quand vous ciblez son <label>, ce qui est un comble en manière d'accessibilité.

En fait, j'ai même remarqué que Firefox ne donnait même pas le focus quand on ciblait directement <input>, et j'en suis resté stupéfait J'ai ouvert un rapport bugzilla où vous trouverez un test-case.

Du coup, j'ai dû écrire un petit snippet javascript de ce qui pourrait bien être un polyfill pour une accessibilité évidente et mobile first.



function focus_on_label_moves_to_input() {
    let focused_on = document.getElementById(location.hash.substr(1));
    if  (focused_on === null) {
        return;
    }
    let focus_for = focused_on.getAttribute('for');
    if (focus_for === null) {
        return;
    }
    let new_target = document.getElementById(focus_for);
    if (new_target === null) {
        return;
    }
    new_target.focus();
}

window.addEventListener('hashchange', focus_on_label_moves_to_input);

Sous le capot

L'événement hashchange a lieu si vous changez la partie après le # dans l'adresse d'une page, donc sur une modification du fragment identifier. J'ai déjà fait joujou avec pour cibler un temps précis

Pour l'événement lancé, inutile de se référer à un objet event, la propriété location.hash vous donnera la partie hash (ou fragment) de votre URL, auquel on soustrait le premier caractère, forcément un # avec un .substr(1).

On va chercher l'élément cible du label, on voit s'il a un for="" avec la méthode .getAttribute('for').

À chaque étape où on frise l'incertitude, on vérifie qu'on a bien un objet et pas rien (null), sinon on return proprement, pour laisser la fonction suivante gérer l'événement. Je vous déconseille fortement de tout cacher derrière un try { } catch (e) { } : une telle structure doit rester exceptionnelle, sinon vous aurez vite d'immonde plats de spaghettis.

À la fin, on crée un événement focus en invoquant simplement la méthode .focus() de l'élément DOM du champ de recherche, parce que construire un trigger d'un focus, j'avais grave la flemme : il était 3h30 passées.

Moralité : ça fait le taf et le code n'est pas affreux.

C'était tout ce que je voulais. C'était si compliqué que ça ?

Bonus : le code est suffisament générique pour servir pour tout champ de formulaire : login, entrée de commentaire, formulaire d'adresse ou fishing de carte-bleue.

En 20 lignes pas plus : gérer les options d'appel de tes scripts bash

Da Scritch — 2018-01-08T05:07:00+01:00

Quitte à avoir des scripts bash de plus en plus sérieux, on va appliquer les standards d'interface pour que tout le monde s'y retrouve.
Webdev

Cette petite série est aussi disponible sur Github, avec le snippet du code commenté dans ce billet.

Bash n'est pas un langage facile.
Ou plutôt, il y est incroyablement facile d'y faire une erreur dont les conséquences seront catastrophiques. Écrire un script bash demande vite une énorme rigueur et des ruses de sioux. De fait, sa puissance est méconnue : Certains font même du TDD avec !

Pour l'instant, on va partir dans l'idée que vous avez un serveur applicatif professionnel, que des scripts tournent dessus (par exemple en cron), ou sont disponibles pour une administration en remote. On va voir comment rendre vos programmes plus pratiques et professionnels en y proposant une interface en ligne de commande digne de ce nom, avec des options dans le style POSIX.

Et on va se concentrer sur les options GNU-style, c'est à dire explicites. Parce que le one-letter porridge -lhAzkjfsoplS… au secours.

Alors, de suite, une question : Pourquoi l'avoir fait en bash ?
Parce que des fois on ne maitrise absolument pas ce qui tourne sur l'ordinateur où il va être déployé, ou même son architecture (y'a pas que x86 dans la vie), et plutôt que réinventer un récupérateur de données via https:// ou écrire un parseur json, il est plus facile de demander à ce que deux/trois utilitaires standards soient installés. Et d'une manière étonnante, bash est souvent mésestimée. Oui, zsh et bien plus puissant, mais il ne fait pas tout, et n'est pas disponible partout.

TL;DR Montre ton code !

Attention : ce snippet doit être dans le code principal, pas en fonction. Le script doit absolument fonctionner en bash, précisez donc bien #!/bin/bash dans votre entête.

set -e
while [ '-' == "${1:0:1}" ] ; do
    case "${1}" in
        -h|--help)
            echo "${HELP}"
            exit 0
        ;;
        -u|--unlock)
            _unlock_script
            exit 0
        ;;
        -v|--verbose)
            VERBOSE="y"
            option_sub_script="${option_sub_script} --verbose"
        ;;
        -i|--interactive)
            ALWAYS_AUTO="n"
            option_sub_script="${option_sub_script} --interactive"
        ;;
        --)
            shift
            break
        ;;
        *)
          echo "Invalid \"${1}\" option. See ${0} --help"
          exit 1
       ;;
    esac
    shift
done

Simple et basique

set -e forcera votre script bash à crasher au moindre bug. C'est un comportement nettement plus acceptable si vous faites des opérations destructives en fin de traitement, ou s'il manque un exécutable important. Sérieux, invoquez-le le plus souvent possible. Cette option est réversible avec set +e, les autres options de bash devraient aussi vous intéresser.

J'encapsule et j'échappe toujours les chaines de caractères.

Quand j'utilise une variable, je fais toujours en sorte d'utiliser la notation échappée ${VAR}, c'est un réflexe à prendre qui peut vous être bien utile.

Nommez explicitement vos variables, vos constantes et vos valeurs magiques, dit le mec qui utilise extensivement ${1} dans cette démo.

Je préfixe les fonctions internes par un _. Parfois je le fais pas (voir le script de lock), quand c'est non pas le script principal, mais une inclusion d'utilitaires.

Le bash étant encore plus susceptible de vous faire des blagues à la moindre typo qu'un javascript, il est bienvenu dans une comparaison de mettre la constante comme premier argument. Donc if [ 'y' == ${VERBOSE} ] ; then, ce qui se montre parfois plus lisible que l'inverse.

Soyez très discipliné avec l'indentation, sinon vous allez vous y perdre... La coloration syntaxique d'un IDE ou de vim ne fait pas tout.

Les arguments, ou paramètres d'une ligne d'appel d'un script shell, sont découpés par les espaces, et classés dans ${1}, ${2}, ${3}... Ainsi dans truc.sh muche bidule, ${2} retournera bidule
Attention :

Si vous êtes dans une déclaration de fonction, ces paramètres font référence à l'appel de la fonction,
${0} est l'appel à votre programme,
Il y a une autre méthode, getopt, mais je l'ai écartée car elle incite à de mauvaise pratiques

Les options sont en début de train de paramétrage, on va donc faire une boucle tant qu'on a un argument dont le premier caractère commence par -

La notation étendue des variables permet des choses assez magiques comme la substitution ou encore de n'utiliser qu'une partie de la chaine de caractère. ${VAR:0:1} est une manière habile de ne récupérer que le premier caractère de la variable ${VAR}

Boucle si jamais, tant que :
While [ condition ] ; do […] done
. dont on peut s'échapper avec break. Ici, tant que le paramètre analysé a comme premier caractère un -

shift est une commande qui décale/dépile les paramètres positionnels, à rapprocher dans l'idée d'un Array.pop() dans tout langage plus structuré. Ainsi ${2} devient ${1} ... Une fonction particulièrement magique pour faire des boucles sur les paramètres

case <var> in est un switch-like . À noter sa syntaxe très alambiquée, comme tout ce qui est un peu technique en bash. Ainsi, il se termine avec son mot clé renversé, esac, comme fi pour un if... C'était quel personnage DC qui prononce des invocations à l'envers pour les annuler ?
Chaque cas commence par <regex>). Nous avons donc pour le premier cas une règle qui accepte -h ou --help, puisque | est une alternative logique, un ou.
La fin du cas est symbolisée par ;;.
Le traitement d'un cas non expressivement décrit se fait via *), regex oblige ;)

Rédigez toujours un message d'aide en début de votre script. La documentation atomique toujours au plus près de votre code atomique, ce qui permet de le lier directement à vos commits git. Je le déclare en multiligne dans la variable HELP, que je ressors dans le programme avec l'option --help, ou -h pour les personnes pressées.
Inspirez-vous des autres programmes pour faire une jolie sortie d'aide en ligne, avec la mise en forme, les rubriques et les chapitres les plus standards possibles. Plus elle informera l'utilisateur, moins vous chercherez rageusement à faire un man, un help, un lynx bing.com/search?q=site:stackoverflow...
Avec ça, vous pourrez vous passer de créer une manpage, un .rst spécifique et autre help files exotiques.

option --unlock parce que si votre script est global, pensez toujours à mettre un lock pour éviter une désastreuse exécution concurrentielle. J'ai expliqué précédemment comment. L'intérêt de cette option est de ne pas avoir à chercher comme un fou où est ce ~~foutu~~ satané lock s'il n'est pas dans /var/run.

option --verbose parce que si votre script est assez tarabiscoté, pensez à documenter ce que fait chaque fonction dans la sortie standard, et à passer ce paramètre à chaque programme important que vous utilisez

option --interactive pour que le pupitreur puisse valider ou sauter des étapes internes à votre script sans pleurer à tout commenter. Voici typiquement l'invite que cela produit sur mes scripts d'administrations :

Dump de la base vers /backup/2018-01-05-07h15.sql : [E]xécuter, [S]auter, [C]ontinuer automatiquement, [Q]uitter ?

Croyez-moi que mes collègues me bénissent quand ils découvrent cette option.

option -- , une excellente convention des utilitaires GNU pour éviter qu'un fichier qui s'appelle --truc ou -h ne vous mettent un bazar incroyable dans votre ligne de commande parce qu'elle est interprétée comme une option. Oui, cela arrive. Méfiez-vous des rm * dans un répertoire avec beaucoup de fichiers. #protip
Je sors de ma boucle while avec un break en toute tranquillité.

Plantez à la moindre option d'appel inconnue, sauf en mode --help.

Pour terminer votre script, exit accepte un paramètre numérique pour informer d'une fin normale ou malheureuse :

0 si tout va bien
Tout autre nombre, mais de préférence entre 1 et 255, si vous avez un bug ce qui fera aussi planter un éventuel script bash parent si set -e est présent. La signification de ces valeurs magique manque singulièrement de standardisation.

À améliorer

Le code actuel ne gère pas les options paramétriques du type --verbose=8
J'ai volontairement écarté pour cet exemple getopt car

il n'est pas toujours facile à lire par tous les devs,
sa syntaxe incite plus à écrire des options en un caractère, et donc d'être beaucoup moins explicite.

À sa décharge, l'accusé a néanmoins une très bonne prise en charge des valeurs d'arguments, ce que ne fait pas ce script. Si vous préférez getopt, je vous recommande cette excellente ressource en français.

L'ensemble est très nettement perfectible, j'en suis absolument sûr. Mais pour les antiques scripts init, cette construction était parfaite.

En 20 lignes pas plus : un verrou non-concurrentiel pour tes scripts bash

Da Scritch — 2017-09-25T20:12:00+02:00

Toi qui ne comprends absolument pas la ligne de commande sous Linux, ne t'attends pas à comprendre plus, bien au contraire : On fait dans les bonnes recettes pour démarabouter un serveur unix.
Webdev

Depuis que je suis arrivé chez GPDis, je me rends compte que je ressors de temps à autres ce que j'ai fait dans les autres boites. Notamment des petits bouts de code qui font ce qui est pour moi évident. Comme cela faisait trop longtemps que je n'avais pas écrit de billet techniques très fouillés, je reprends pour cette série ces petits snipets de code que je reproduis souvent pour en expliquer la stratégie, et accessoirement augmenter mon klout sur les réseaux sociaux en tant que dev, parce qu'écrire des billets sur la balise <img> ou la série des Dirty Hacky m'ont pris parfois plus de trois mois. Et si vous croyez que j'ai que ça à faire, imaginez que je ponds aussi mon émission radio hebdomadaire CPU, qui demande son quota sacrificiel en nuits blanches.

Occasion de commencer une petite série, qui est doublé d'un projet git.

Le principe (de la série)

Écrire des petites lignes de code, pour explorer des petites astuces autour d'un langage, des petits bouts de code qu'on peut étendre à loisir pour son usage, en utilisant le langage dans sa version la plus pure/simple/indépendante/vanilla possible et faisant appel aux standards normaux.

L'énoncé du problème

Supposons que tu aies un script bash sur un serveur, qui est lancé toutes les minutes via crontab (supposons !), sauf qu'il ne doit pas être lancé concurrentiellement (une et une seule fois à la fois), et que parfois, il dure plus d'une minute.
Problèmes :

Bash n'est pas super lisible,
mais il est l'intepréteur de commande le plus présent sur un serveur unix alors que zsh doit être explicitement installé,
il existe très peu de libs qui propose ce genre de snipets
et on veut un petit bout de code qu'on puisse facilement étendre à sa propre convenance (d'où la licence GPL)

TL;DR Le corrigé

Soit vous clonez le repo git, soit vous copiez-collez sans comprendre les lignes suivantes (et bonne chance) :

LOCK_DIR=~/locks
LOCK_FILE=${LOCK_DIR}/cron.lock

function lock_script() {
    mkdir -p ${LOCK_DIR}
    if [ -f "${LOCK_FILE}" ]; then 
        LOCKING_PID=`cat ${LOCK_FILE}`
        >&2  echo "ERROR : Script ${CALLED_FUNCTION} already locked on PID ${LOCKING_PID}. Cannot run PID $$ . Still running ?"
        exit 1
    fi
    echo $$ > ${LOCK_FILE}
}

function unlock_script() {
    rm ${LOCK_FILE}
}

Usage

Commencez votre script par lock_script et concluez avant de quitter par unlock_script.

Préliminaires

Pour des facilités de refactoring, je définis toujours mes variables en début de fichier. Je me suis mis dans le répertoire utilisateur, mais en cas de redistribution, il vaut mieux créer son arborescence dans /usr/var/lock si on suit le Filesystem Hierarchy Standard.

En bash, les définition de fonctions peuvent être écrites soit :

function lock_script {

ou sous cette forme :

lock_script() {

Pour aider mes petits camarades à la lecture, je mixe (sûrement très improprement) les notations de déclarations de fonctions bash, ce qui ressemble plus à la convention C/JS/PHP/etc… On notera que la parenthèse n'est pas interprétée

lock_script() ligne à ligne

Je crée inconditionnellement le sous-répertoire qui va accueillir mes fichiers locks

    mkdir -p ${LOCK_DIR}

Est-ce qu'un fichier lock est déjà présent ?

    if [ -f "${LOCK_FILE}" ]; then

Je lis son contenu, lequel contient le PID du script l'ayant lancé. La notation `command` est plus compacte que $(command) et surtout plus lisible car déjà imbriquée.

        LOCKING_PID=`cat ${LOCK_FILE}`

J'envoie un message expliquant la situation vers STDERR, via la très cabalistique notation >&2 qui préfixe une commande dont la sortie normale est redirigée vers le canal d'erreur. La variable $$ donne le PID du script courant.

        >&2  echo "ERROR : Script ${CALLED_FUNCTION} already locked on PID ${LOCKING_PID}. Cannot run PID $$ . Still running ?"

Évolutions possibles :

En profiter pour vérifier si ledit script tourne toujours.
Internationaliser le message

Sortir avec un code d'erreur

        exit 1

Fin de la conditionnelle.

fi

Sinon implicite : Enregistrer dans le LOCK_FILE le PID du script courant.
J'aurais pu utiliser un touch qui crée un fichier vide. Mais stocker le PID dans le lock d'un script permet, par exemple, de vérifier qui le script est toujours en cours d'exécution ou a brusquement planté. Si vous avez des outils de monitoring, cela vous laisse de quoi vous amuser.

    echo $$ > ${LOCK_FILE}

unlock_script() ligne à… ligne

On supprime le lock.

    rm ${LOCK_FILE}

Et voilà.

Alors certes…

Y'avait mieux et plus propre. Pour celà, je vous invite à râler dans ⇓ les commentaires ⇓ ou sinon à commiter sur mon github.

Les joies de la communauté open-source

Da Scritch — 2017-09-04T13:45:00+02:00

… comme par exemple s'ajouter un truc à faire, et quelqu'un te dit qu'il a déjà fait.
Webdev

Afin de me familiariser avec les add-ons du navigateur Firefox, j'avais conçu une extension extrêmement simple : anchors-reveal, qui permette de lier à un paragraphe précis au milieu d'une longue page. J'avais déjà blogué à ce sujet. Trèèèèès utile quand on blogue sur un sujet technique.

Des add-ons qui proposent ce service, il en existait déjà une demi-douzaine, mais elles n'ont clairement pas été conçues dans une optique de simplicité d'usage. Le but du jeu était de faire une fonctionnalité le plus minimaliste possible : un bouton qui s'installe dans la barre d'outils et qui révèle les ancres nommées d'une page en superposant un lien direct.

Je voulais à la fois me frotter à l'écriture d'un add-on, mais surtout au framework (obsolète) cfx, que j'ai vite converti vers le framework (obsolète) JetPack qui facilitait l'écriture de ces add-on. Cela m'a aussi permis d'essayer le processus de validation de la communauté Mozilla, qui a été formidable, prévenante et qui aide vraiment à gagner en qualité de code.

Et par ailleurs, j'avais poussé mon code source sur mon repo github, ce qui m'évitait à devoir maintenir un repo git. Ce qui me permettait d'éventuellement profiter de quelques fonctions sympathiques comme la fusion de branches et un rapport de bugs.

Arrive la ré-écriture de Firefox

La Mozilla fondation s'est lancé dans un projet audacieux, nom de code : Quantum (la blague ne marche qu'en France). Objectif : reprendre de vitesse le Chrome de Google. Un retour en avant car le terme chrome désignait à l'origine l'interface de Firefox.
Le travail est titanesque : ré-écrivant des parties importantes de son navigateur, en passant à Rust, un langage bas niveau conçu pour éviter les bugs fréquents, et surtout en virant un nombre impressionnant de technologies dont les buts furent atteint par d'autres technologies standardisées. C'est le cas du vénérable XUL (le langage qui décrivait le chrome, l'interface graphique de Firefox), hélas,… mais pas tant hélas.

Mais cela voulait aussi dire abandonner Jetpack, et donc devoir faire un nouveau portage, dans le format Web-Extension.
Web-extension est standardisé par le W3C. Cela veut dire qu'un add-on Firefox est utilisable quasi tel quel par Chrome, Opera, bientôt par Edge et d'ici 10 ans, peut-être par Safari…
Que du bonheur !

J'ai donc ouvert un ticket sur le repo.
Ce bug, je me l'étais écrit comme mémo, en me disant que je ferais ce travail le week-end suivant où à la prochaine nuit d'insomnie.

C'est là que la magie de la communauté opère

À ma grande surprise, 6 heures plus tard, un individu du pseudo de Makyen, m'annonce qu'il a déjà effectué ce travail et qu'il a même corrigé quelques bugs.

Quelqu'un avait déjà fait le travail ! Je n'avais plus qu'à merger sa contribution, ajouter un script de packaging et l'envoyer sur le site des add-ons de Firefox.

Ben voilà, ce petit projet sans prétention, purement égoïste, se trouvait être utile pour d'autres personnes, au point que certains étaient prêts à me donner un coup de main pour le maintenir à jour. Pourtant, je savais que cela pouvait m'arriver, mais la surprise fait chaud au cœur.

Thank you a lot, Makyen !

Et n'oubliez pas : vous pouvez toujours aider un projet open-source. Pas forcément en codant, mais simplement en aidant au design, en écrivant la doc, des tutos, en aidant à répondre aux questions des gens perdus. N'hésitez pas !

Oh ! Une dernière chose !

Je suis actuellement sur Firefox Nightly (57), et je peux vous dire que d'ici deux mois, vous allez être décoiffés par le gain de vitesse de Firefox. Ils ont viré plein de vieux trucs, retravaillé une partie du reste, et le coup de boost s'en ressent !

Une (pompeuse) histoire de la cryptographie

Da Scritch — 2017-02-15T06:27:00+01:00

...à l'usage d'étudiants en design. Donc, promis, pas de maths ou de lignes de code, mais des esclaves, de l'astrologie, des amants infidèles et des consoles de jeu. Bref, un programme pour éveiller l'attention du Jeune Moderne. Si si.
Webdev

Vue du clavier d'entrée, du panneau de lecture et des rouleaux de chiffrement d'une machine Enigma, dans sa version Marine militaire allemande (4 rouleaux de complexité)
Photo par Greg Goebel, CC

J'ai eu l'insigne honneur d'avoir été invité par les master DTCT (Design Transdisciplinaire Culture et Territoire) pour une intervention sur le thème des dystopies de la communication. En tant qu'amateur de SF, et après ma carrière de critique BD de 20 ans, j'étais d'autant plus flatté que cette invitation venait de mes participations aux cryptoparties. J'ai eu envie de donner un vrai cours bien pompeux.

C'est évidemment dans ma grande tenue de cyberguerrier 2.0 que je me suis pointé ce Mercredi 1^er Février dans la fac du Mirail, tellement rénovée qu'elle mérite son rebranding en Université Jean Jaurès.

Photo twittée par Anthony Masure, CC

Plan

Le cours proprement dit dure 49 minutes (j'ai débordé).

Questions :

49:20 : Quelle est la prochaine étape dans l'histoire du chiffrement ?
51:20 : Qu'est-ce que c'est qu'une cryptoparty ? (voir aussi ma conf sur le sujet)
52:55 : Est-ce que la navigation privée nous protège ?

J'avais un support sous la forme de slides lisibles sur votre navigateur web. Selon les recommandations du grand sachem Nota Bene, elles ne font que ~~me servir d'antisèche~~ reprendre mon propos. On avance en appuyant sur →.
Sinon, vous pouvez vous reporter sur les notes graphiques d'une des auditrices :

Dessin twitté par Léa Vuillaume, DR

C'est pas pour cafter, mais j'ai eu un mal fou à rester docte et sérieux, malgré mon collègue Jules David qui était très dissipé quant à ma présentation au lieu de se concentrer sur son intervention.

Je tiens à remercier Pia Pandelakis et Anthony Masure, les autres intervenants Jules David, Mélanie Bourdaa, Johann Chaulet et Yoan Richard, les copains de Tetaneutral aussi présents et surtout mille mercis aux étudiants en master de design et aux autres étudiants qui sont venus remplir l'ampli. Avoir plus d'une centaine de personnes en face de soit reste toujours intimidant, que vous soyez restés jusqu'au bout et êtes même venus poser des questions après était… gratifiant. Merci d'avoir accepté mes élucubrations.

Licence du cours et du sonore en Creative Commons. Pas impossible que je le remonte pour la radio ;)

Venez les rencontrer !

Une journée portes ouvertes est prévue le Samedi 25 Février, et conclue justement la semaine de travail des étudiants en master de design. Et ils montreront à cette occasion leurs travaux. Occasion de voir comment ils verront ce futur effrayant : comme l'occasion de se distinguer comme meilleur officier panoptique, ou en tant que militant de la vie privée.

Un point intéressant pour ceux qui seraient intéressé par cette voie universitaire, les étudiants ont accès à un vrai fablab, ils ont donc la possibilité de prototyper leurs travaux.

Firefox, l'invisible

Da Scritch — 2017-01-12T06:26:00+01:00

Est-ce que le navigateur Firefox n'aurait pas une audience sous-estimée ? Pourquoi ? Et si certains se contentaient de chiffres d'audience biaisés ?
Webdev

Mon discours sera un peu long. Il n'est pas étayé de chiffres, mais si quelqu'un veut étayer mon hypothèse, je lui donne les éléments qui lui permettrait de faire l'analyse. Seule condition, il faut les logs serveurs d'un site qui a une audience significative.

Parlons de la publicité sur le web

C'est un fait, la publicité est devenue incontrôlable, au point que même l'IAB, l'association des publicitaires sur internet, reconnait que ces abus sont devenus dangereux pour leur secteur économique :

La publicité est devenue trop distractive entre les animations, les couleurs criardes, le son voire la vidéo. Apparaissant des fois en plein milieu du contenu alors qu'on déroule un article, elle donne plus envie de fuir que de persévérer ;
Elle a pris ses aises avec le support et se substitue au contenu du site, avec des encarts en pop-over, pop-under, des vidéos en pre-roll… ;
Les publicités sont extrêmement lourdes à charger et à jouer. On frise parfois le délire avec des spots vidéos en HD pas optimisées, des polices de caractères dépassant la dizaine de Mo, un contenu 600 fois plus lourd que le reste de la page, impactant la réactivité du navigateur, les performances de l'ordinateur et l'autonomie de la batterie. Une machine qui peut faire tourner un FPS sans sourciller devient brusquement un veau en allant lire un article d'un quotidien ;
Le javascript des encarts est souvent de mauvaise qualité et peut faire planter la page hôte ;
Elles sont très indiscrètes, profilant le plus possible le visiteur, souvent au mépris des lois Européennes. Pourquoi les quotidiens français veulent connaître ma position géographique ? Sans compter une multitude de trackers posés par des réseaux sociaux, des régies publicitaires et autres ;
Les publicités posées s'affichent souvent avec retard, entrainant le phénomène de reflow d'une page. Outre leur poids, certaines régies travaillent avec un système d'enchères sur l'audience acquise, dans le but de vendre au plus cher l'écran du visiteur en fonction des intérêts qu'il a manifestés. Résultat : une pénalisation de la lecture par le délai d'attente, créant un effet de clignotement/déplacement de la mise en page ;
Elles sont devenues un vecteur d'attaque très prisé pour les virus et autres logiciels malicieux, et même indirectement les autres utilisateurs du réseau ! Le malvertising joue sur le fait que des sites réputés servent du code extérieur sans aucun contrôle, et même les experts sécurités peuvent se retrouver vecteurs d'infection malgré eux

Il ne faut donc pas s'étonner de la part importante de personnes qui surfent sur internet avec un bloqueur de publicités, pas uniquement pour avoir un ordinateur plus réactif, ni pour protéger un minimum sa vie privée, mais carrément pour se protéger les logiciels malveillants !

Un exemple de taxe à la performance dû aux publicités et outils de tracking sur un article du journal Guardian, relevé par Paul Irish dans un article où il liste les éléments forçant un repaint

Et c'est ainsi que naquirent les filtreurs de pubs

Illustration : Christophe Andrieu

Sur internet, il ne suffit pas d'apposer un petit sticker Pas de pubs, merci sur sa boîte aux lettres… une page web part d'un document HTML, de là, votre navigateur va charger ses assets (images, style, scripts,…), et dans ces derniers sont présents les éléments publicitaires. Il faut donc trier pour pouvoir les retirer.

À noter que le choix de ne pas charger/afficher des pubs est légale en Europe, mais réprimandable aux États-Unis. C'est même une des bases du fameux procès Betamax qui avait opposé studios de productions et fabricants de magnétoscopes, qui furent ravivées 30 ans après avec TiVo, l'enregistreur numérique capable de sauter les pubs.

D'abord, il y eu les filtrages écrit à la main par des utilisateurs développeurs… Soit en définissant localement certains noms de domaines dans /etc/hosts, soit en injectant spécifiquement des règles dans les navigateurs.

Puis arrivèrent les premières extensions de navigateurs, afin de permettre à d'autres utilisateurs de profiter de la fonctionnalité.

Puis une industrie se construisit, avec les filtreurs de publicités qui en ont fait un business model, comme Ad Block Plus, et dont le comportement est clairement prédateur, avec un chantage d'extorsion envers les régies publicitaires et les annonceurs.

Mais maintenant, avec Firefox (et tout récemment Brave), des navigateurs précablent des fonctions de filtrage et le signal Do Not Track, le jeu change car il implique une décision par défaut d'utilisateurs d'un logiciel.

Or, justement, je veux faire le parallèle avec une autre tendance, qui me semble contemporaine : la perception de la chute d'audience des pages web vues via le navigateur Firefox.

Apple a sa culture insulaire et a oublié le web

Cette chute d'audience n'a pas été commentée pour Safari, alors qu'Apple a lui aussi largement favorisé le blocage des publicités.
Et pour cause : sur l'audience des ordinateurs purs, Safari n'a jamais dépassé les 10%. Par contre, dans le domaine des tablettes et des smartphones, Apple est dans une position de force, et donc Safari en monopole dans son écosystème. Car le fabricant Apple refuse totalement qu'un autre moteur de rendu que Safari puisse être installé sur les appareils de sa marque. Je rappelle que les apps Chrome pour iOS et Firefox pour iOS ne sont que des recarrossages du moteur de Safari, et qu'ils en ont les mêmes limitations techniques.

La position d'Apple est encore plus extrémiste que celle que s'autorisait Microsoft il y a 15 ans et qui lui a pourtant valut des procès pour abus de position dominante..

Et comme l'époque ou MSIE régnait sans partage, Safari est un navigateur indigent, une catastrophe : Il lui manque plein d'API du W3C, de fonctions javascript, de propriétés DOM ou SVG qui sont déjà implémentées dans Microsoft Edge. Un comble !

Apple a certes remis une équipe de développement sur son navigateur pour iOS9, mais le retard reste titanesque.
Mais est-ce que le constructeur est motivé à avoir un navigateur web dans les canons actuels ? Car la firme de Cupertino fait principalement sa marge via la vente d'applications natives sur son App Store. Avoir la possibilité de faire des applications à partir du navigateur web en single page application ou en progressive web app n'est absolument pas dans l'intérêt de la firme à la Pomme. Par une culture forte de la marque (et la qualité du matériel, il faut bien l'avouer), ses consommateurs sont bien peu enclins d'aller voir ailleurs. Il reste donc très difficile de faire une application web universelle qui puisse se comparer avec les applications natives.

D'un autre côté, sous prétexte de protection de ses usagers, Apple a autorisé les bloqueurs de publicité à être installés comme extension de Safari mobile. Ce qui fait réduire mécaniquement le nombre d'utilisateurs de Safari mobile dans les rapports d'audiences des sites. La situation n'est pas pour déplaire à Apple, puisqu'il entretient l'illusion que les utilisateurs préféreront toujours avoir une application native plutôt que passer par un navigateur web, et que Safari Mobile n'a strictement aucune concurrence face à qui se mesurer.
Alors que les statistiques montrent que les applications installées sont très vites boudées.

Et puis, la publicité dans les pages web, Apple avait tenté de s'y aventurer en rachetant plusieurs régisseurs d'encarts et en construisant iAd. Mais ils n'ont pu faire jeu égal avec un mastodonte qui regroupe réseau publicitaire, outils d'analyse de trafic, profilage et surtout un écosystème mobile concurrent.

En faisant rejeter la pub par ses afficionados, Apple attaque via le porte-monnaie le Maître de l'Univers Android…

L'écosystème global de Google

Source : shortblacktechie.com

Google édite un navigateur, Chrome.
Il a gagné la bataille des features, il a gagné la bataille de la vitesse avec son moteur javascript V8, il a gagné le cœur des développeurs avec son mode développeur F12. Puis Google a attiré les développeurs avec d'autres technologies, notamment AngularJS (même dépassé, l'attrait existe toujours), Dart (abandonné), Polymer (qui sert de polyfill aux web components mais avec moins de respect au standard que Bosonic les dernières fois que je les aient comparés) et Go (un langage principalement serveur)…

Personnellement, je n'ai absolument rien contre : Google est un acteur très important qui fait énormément de R&D, contribue énormément aux standards en respectant les règles, libère très souvent publiquement les sources et ses technologies web,… et moi même, je suis un grand fan de nombres d'entre elles.
Google est un des rares contributeurs du web à continuellement le faire avancer, tout comme la Mozilla Foundation.

Mais trop de développeurs oublient de tester leurs sites ailleurs que sur Chrome. Certains développeurs livrent encore des propriétés dans leur version expérimentales préfixées -webkit- sans avoir vérifié que celles-ci étaient retirées de Chrome depuis plus de 2 ans. Pire que tout, j'ai vu récemment un développeur essayer sa création sur Opera pour se donner une bonne conscience… sauf qu'Opera a abandonné son propre moteur et utilise le Blink qui motorise Chrome. Bref, un coup dans l'eau.

La plupart de ces développeurs tiers me sortent le fait que Chrome représente actuellement plus de 60% de la fréquentation de leurs sites, selon leurs chiffres d'audience.
Et, forcément, si leur site très riche en javascript se montre moins utilisable avec d'autres navigateurs, leur prophétie est auto-réalisatrice.

Mais reprenons les chiffres de fréquentation. Si Google Chrome a effectivement une place de leader, j'ai un doute : celui que Google Analytics sous-évalue les parts de marchés de Firefox.

Et étonnement, les deux font exactement le travail qui leur a été confié en toute bonne foi.

The mission

Par défaut, Firefox demande désormais que le trafic de son utilisateur ne soit plus pris en compte, entres autres via le signal Do Not Track, et dans les dernières versions via une bibliothèque qui bloque par défaut les trackers et les malwares en se basant sur la liste maintenue par uBlock Origin. D'ailleurs, en accédant aux paramètres des add-ons, c'est la deuxième suggestion proposée, après un thème graphique, et il démarre sans redémarrer l'application.

Google tente à l'inverse de tracer au mieux les usages de son navigateur, les liant au plus vite nativement avec les identités de ses utilisateurs. Avoir Chrome qui ne remonte pas par défaut son trafic vers Google Analytics est contre-productif pour Google, surtout que leur source principale de revenus est leur régie publicitaire. (Et je ne parle pas du fait qu'il n'est pas possible d'empêcher un tracker d'audience faire son travail dans une application native)

Voilà pourquoi j'en suis venu à la conclusion que la position dominante de Chrome dans le statistiques d'usage me semble un poil sur-évaluée, et Google n'est évidemment pas bien pressé de corriger les chiffres qui sont en sa faveur.

Bref, j'abandonne l'audience-turfing

J'ai (enfin) viré Google Analytics de mon blog.

Depuis plusieurs mois, voyant une certaine dissymétrie entre les visites de Firefox relevées dans mes logs apache et ce qu'il me rapporte, ses chiffres ne me semblaient plus assez exacts. Ils me rappelle le flou des chiffres de la Alexa Toolbar à ses hautes heures il y a une décennie, laquelle ne comptabilisait que le trafic des utilisateurs anglophones sous Windows...
Analyser quels sont les sujets qui intéressent le plus les gens qui viennent me lire, c'était grisant il y a 10 ans, mais comme je ne fais pas une activité commerciale de mon blog, il y a peu d'intérêt (sinon le bonus supposé d'indexation dans le moteur de recherche Google)

Alors certes, je gardais Google Analytics pour faire des démonstrations de traçage publicitaire aux Brown Bag Lunch vie privée et des cryptoparties,… Mais finalement, je faisais rarement ces démonstrations.

De plus, les rapports de Google Analytics sont de plus en plus encombrés par les spam-referrer, au point d'avoir des résultats de moins en moins précis.

Je déconne à peine : dans mes statistiques par langue de navigateur, j'ai 20% de pollution avec des entrées qui ne sont clairement pas au format IETF. Le tableau a été édité pour mieux voir les déchets.

Comment vérifier cette intuition

Sur cette idée que Firefox (et sûrement aussi Brave et Safari) sont sous-estimés par les outils d'analyse de trafic, j'ai regardé mes logs de serveur web, mais l'audience de mon site est beaucoup trop typé et anecdotique pour être une mesure concluante.

Si vous comptez vérifier de votre côté, sachez qu'il va falloir pas mal travailler dans le filtrage des données de vos logs :

Il faudrait un site qui enregistre selon plusieurs outils de mesures (Piwik et Google Analytics), au moins 500 visites quotidiennes.
Filtrez les IP des administrateurs (et donc la votre, on compte pas, c'est tricher)
À partir des logs du serveur web, isoler les visites qui semblent réelles : les chargement de pages canoniques (donc écartez les miroirs, les repompeurs et les lecteurs de flux rss), accédées par le verbe GET, accompagnées du chargement d'assets statiques (CSS, js, webfonts, svg, images) et dynamiques (si vous chargez des éléments en asynchrone, par exemple lors de DOMContentLoaded).
Écartez les user-agent qui annoncent clairement un bot ou un crawler (on ne sait jamais, si un vous a échappé).
À partir du user-agent, comptabiliser chaque navigateur
Et de là, vous aurez des métriques à comparer.

Si en termes de proportion, la différence est flagrante, vous saurez quoi penser des chiffres analytics.

Si j'avais des recommandations

Apple relance timidement le développement de Safari, qui reste le navigateur moderne le plus en retard. Il faut l'encourager dans cette voie en refaisant un procès pour abus de position dominante. Si vous êtes propriétaire de votre ordinateur, vous avez le droit d'installer n'importe quel logiciel. Et vous êtes bien propriétaire de votre smartphone, non ? Forcer Apple à accepter que ses clients puissent avoir le choix d'un autre navigateur web, indépendamment des moteurs de rendus vieillissants webkit. Qu'enfin nous puissions construire des web-apps complètes qui tournent aussi sur iPhone. Songez que Firefox sur Android est capable d'incrustation 3D sur une image de caméra.

Ensuite, La publicité est très utile pour les contenus gratuits, mais elle est devenue un vrai fléau. Il faut libérer de la dictature de la publicité certains sites, en s'y abonnant. Oui, reconnaissez la valeur de ce que vous utilisez gratuitement. Abonnez-vous à la Presse Libre pour mutualiser des abonnements (Ou laissez La Moustache vous hypnotiser), soutenez Wikipédia, et donnez aux projets open-source. Le navigateur Brave propose de filtrer les publicités, et en contrepartie de centraliser des abonnements. Si vous utilisez régulièrement un service, reconnaissez-en le prix. (et je ne dis pas ça pour mon compte Flattr : il n'a connu des versements que quatre mois).

Et enfin, n'utilisez pas le même navigateur que tout le monde. Sinon, nous allons revenir vers les mêmes travers que l'époque où MSIE avait gagné une guerre : une monoculture et la perte d'interopérabilité du web. Ça serait dommage.

Alors ? Stop ou encore ?

Soutenons le web que nous voulons.

Ressuscitez le bouton du milieu !

Da Scritch — 2016-12-06T12:32:00+01:00

Je dois être vieux, j'aime bien les détails, les outils qui sont finalisés avec amour, et quand mes instruments jouent parfaitement leur partition. J'ai la même attente du bouton du milieu de ma souris. Or, il est sacrément important, ce bougre de centriste : il ouvre le lien dans une nouvelle tab !
Webdev

Il y a très longtemps que je voulais écrire ce billet.
Je me le réservais pour les 24 Jours de Web, devenus #Nowwwel.

Il raconte une situation qui me gêne.
Elle me démange, me gratte, me met dans la même situation d'inconfort qui m'a poussé à écrire ma série « Dirty Hacky » : j'ai la forte impression qu'elle est crade, qu'elle heurte profondément mes convictions religieuses qui me font vénérer la Très Sainte W3C, WhatWG au plus haut des validateurs.

Cette situation est l'objet d'une intense frustration personnelle, car, dans ma jeunesse professionnelle et laborieuse du déchiffrement des Saintes Écritures, j'ai conçu quelques back-offices et que je remarque que nombre d'interfaces se voulant aussi primordiales pour les entreprises présentent ce qui est pour moi un défaut, une économie qui montre un certain irrespect du client.

Mais avant que je parle de ce clic du milieu…

Parlons de la souris

Oui, oui, le mulot !

Il fut une époque où la souris avait deux boutons, et qu'un troisième niveau de fonction était accessible en appuyant sur les deux à la fois.

L'iconique souris de l'Amiga. Forever

Alors arriva le troisième bouton.

La souris du Xerox Alto.... qui date d'avant la précédente. C'est à cause d'elle que X Window demandait par défaut une souris 3 boutons

Que l'on remplaça par une molette de défilement vertical, mais le bouton se cachait dedans : on pouvait cliquer sur la molette.

Got this. Elle a 10 ans. Oui, c'est une Microsoft.

À quoi servaient ces boutons ?

Oui, parce qu'un jour, quand nous n'aurons plus que des interfaces tactiles et même plus de clavier physique, il faudra bien se souvenir de l'intérêt d'une souris…)

Sans souris, les environnements fenêtrés auraient été bien plus difficiles à mettre en place. Pas impossible, mais très difficiles.
Si le bouton gauche a toujours eu une fonction d'action directe (appuyer sur un bouton, suivre un lien), le bouton droit faisait ouvrir un menu contextuel à l'objet qui était pointé par la souris. Le bouton du milieu, dans l'environnement X Window a eu une fonction plus ou moins dérivée de l'Alto, encore une fois, celle de copier : Copier le texte qui a été surligné au bouton gauche, ou, dans le cas des navigateurs, le clic du milieu ouvre le lien dans une nouvelle fenêtre, puis dans un nouvel onglet.

(Et un jour, je vous parlerais des boutons 4 à 7, de la molette de défilement horizontal et de l'indication d'élévation de la souris Logitech Cyberman).

~~Du côté de chez snob, chez les riches~~ Dans l'environnement Macintosh, les souris n'avaient qu'un seul bouton, gauche. En chef de projet tyrannique et gaucher, Steve Jobs avait décrété que la politique du Bouton Unique était suffisante. Mais ses ingénieurs et bien des développeurs d'utilitaires en avaient décidé autrement dans une dissidence polie et fonctionnelle, et les utilitaires rentrèrent dans le système sans que la hiérarchie ne fut tenue au courant. Les boutons droits et central sont accessibles et même fonctionnels, c'est plus simple en branchant une souris de PC.

je dois le confesser, j'utilise des outils de GAFAM

J'en connais plein qui vont me railler, me jeter la pierre, prononcer publiquement mon anathème, mais mieux vaut connaître son ennemi pour mieux l'affronter.
J'utilise tous les jours les outils Google Drive et Amazon Web Services. Parce que c'est mon travail, parce que j'ai pas pu faire un choix, et aussi, il faut le reconnaître, parce qu'ils sont pratiques.

Je trouve leur interface terriblement limitée, j'ai même l'impression d'être bridé dans ma productivité parce que je sais que mon navigateur peut faire des choses formidables, mais que les interfaces de ces deux géants du web ne sont absolument pas capables de le gérer.

Exemple numéro 1 : la console AWS

J'ai la chance d'avoir avec mes collègues une flotte conséquente de serveurs à administrer, EC2 dans le jargon Amazon Web Services. Or, quand je gère via l'interface d'AWS, Il m'est impossible d'ouvrir de dérouler plus d'une instance à la fois. Des fois, j'aimerais justement utiliser le clic du milieu pour ouvrir plusieurs onglets afin de comparer/grouper les serveurs… sauf que… Eh ben non, le clic du milieu sur les liens ne marche pas !
Et ce manque se retrouve dans pratiquement tous les outils de l'univers AWS.

Autre surprise, tant que vous êtes dans la console EC2, si vous regardez les détails d'un de vos serveurs, les devices qui y sont montés ont des liens qui sont des… faux liens : ils sont interceptés par le code JS, et donc ne peuvent être compris par un clic du milieu, ni être partagés aux collègues via la messagerie interne.

Il a l'aspect, le balisage d'un lien, mais non, c'est un faux-nez !

Exemple numéro 2 : Google drive

Je consomme aussi énormément Google Drive, où l'on retrouve toute une suite bureautique, mais aussi ce qui ressemble très fortement à un navigateur de fichiers. Et comme dans mon équipe, nous créons énormément de fichiers, nous les classons par sous-répertoires. Et plus d'une fois, j'aimerais ouvrir chaque sous-répertoire dans un onglet différent, ou transmettre dans via messagerie un sous-répertoire particulier à un collègue.

Que nenni !
Toutes les entrées sont des <span> dans des <div>, dont le fonctionnement ressemble très fortement à des liens, mais dont la gestion est purement javascript. Il est donc impossible d'utiliser le clic du milieu pour ouvrir vers de nouveaux onglets, et le fonctionnement du bouton droit est émulé pour avoir une fonction équivalente à Copier l'URL du lien.

Ici aussi, aussi bien le menu à gauche que les sous-répertoires ne sont pas des liens

Le Dernier Empereur de L'Empire du Clic du Milieu

Certes, à l'heure des interfaces tactiles, le bouton du milieu est vu par une curiosité ou est totalement inconnu de la plupart des macophiles. Mais, à la différence du comportement de survol du pointer, le :hover devenu infâme à cause d'usages catastrophiques, le bouton du milieu a été jusqu'ici plutôt constant car son usage était moins flagrant, donc moins prioritaire à bidouiller/braficoter par des donneurs d'ordres trop enthousiastes.

Et il faut reconnaître que les interfaces tactiles nous ont fait nous concentrer sur l'essentiel et la praticité immédiate.
L'adjectif immédiat fut à la fois sain, mais aussi porteur de risque.

Qui dit professionnel dit interaction avec une foule d'outils et d'utilisateurs, du novice au power user, qui tous en feront une consommation industrielle, 8 heures par jour, 39 payées 35 par semaine, et qui chercheront toujours à en améliorer leur pratique afin de grappiller de précieuses minutes pour fumer plus longtemps en se gelant les miches dehors. Je ne dois donc pas être le seul à m'attendre à profiter de mon usage avancé de mon navigateur web sur ces outils supposés industriels.

Très sincèrement, mes considérations de power-user semblent intéresser surtout qu'une minorité de personnes.
Sauf que l'absence de gestion du clic du milieu dans certains sites révèle un symptôme : nous faisons l'impasse sur de réelles problématiques d'accessibilité et d'utilisabilité. Et ces questions deviennent vite crispantes dans une situation de productique. Et justement, il se trouve que AWS et les Google Tools sont marketés comme des outils de production professionnels.

Sauf qu'au lieu d'avoir des vrais liens, on y trouve des aspects de liens posés sur des <div>, donnant lieu à des frustrations pile poil au moment de faire cette livraison ultra-urgente.

Mais comment sommes-nous en venus là ?

Nous sommes passés du Web document au Web applicatif

Cette révolution a réellement éclaté avec l'arrivée de G-Mail. Pour la première fois, nous avions le concept de XHR (qu'on appelait alors AJAX, nous étions innocents et faisions encore du XML et pas du JSON) et de Single Page Application ou page persistante, qui n'a pas besoin d'être rechargée pour toutes les fonctions.

Et avec notre enthousiasme le plus communicatif, nous nous sommes tous mis à fond dans la manipulation des arbres DOM, des objets générés par le document HTML via le javascript au point que nous essayons maintenant de ne plus jamais arriver à la situation où une page web complète doit être rechargée durant la navigation sur un site.

Dans son article « Checkboxes that kill your product », Alex Limi supposait que seulement 2% des utilisateurs ont JS désactivé. Non seulement il avait raison, mais ce pourcentage a sûrement baissé depuis. Sauf que…

Sauf que l'on oublie que le point d'accès d'un site internet peut être n'importe quel endroit. Et en soi, il n'y a meilleure méthode pour se rendre compte des risques qu'en désactivant Javascript.
Nous avons oublié le principe d'un accès aléatoire. Ce que j'appelle un accès aléatoire, c'est que n'importe quelle position de votre application doit pouvoir être reprise à un point arbitraire. Songez que l'ordinateur peut tomber à court de batterie, ou la connectivité perdue, ou encore la session de navigation partagée entre plusieurs ordinateurs, et que votre application web doit pouvoir reprendre depuis ce point, comme si elle avait été suspendue.
Je ne demande pas à ce que nous puissions nous passer totalement de javascript, mais qu'il y aie cette réflexion du point d'entrée aléatoire, et donc de réfléchir à nouveau nos applications en termes d'URL.

En soi, que nous puissions encore utiliser une navigation standard doit garantir que votre site fonctionne, même si votre javascript part en panique. Pourquoi ? Parce qu'en cliquant sur un lien, la page sera entièrement rechargée et donc votre applicatif javascript redémarré. Vous gagnez en solution de redressement.

La culture du document web échappe à la nouvelle génération

Il n'y a qu'à voir un applicatif AngularJS à nu : c'est un template. Un canevas, un modèle à trous. On expose une composante de source directement au lieu de le ranger à part !
Super.

En 2010, j'avais été chargé d'intervenir sur une application web pour la Google TV, alors en pleine hype. À l'époque, on réfléchissait encore aux boîtiers set-top box posés ~~sur~~ sous votre dalle immense comme des PC complets avec une interface graphique foisonnante et avec une télécommande... aussi complexe.

La télécommande de la Google TV présentée par Sony. Recto, verso. Sans trucages.

Nos ChromeCast actuelles se pilotent au smartphone, ce qui résout bien des problématiques et a épuré interface, boutons et points noirs. Mais revenons à il y a 6 ans et notre engin pré-Biactol :
La Google TV consistait en un OS Android sertie d'une interface purement web (plus Flash) embarquée dans des téléviseurs haut-de-gamme et avec un app-store dédié.

Je m'attendais donc à ce que le vocabulaire HTML soit correctement géré. Première mauvaise surprise : la documentation officielle de Google TV recommandait d'éviter la balise <a href="https://dascritch.net/post/2016/12/06/"> pour un <div class="tv-link" href="https://dascritch.net/post/2016/12/06/">. La raison invoquée était assez oiseuse : le changement de couleur des liens déjà visités.

« what the fuuuu ??? » marmonnèrent mes yeux exorbités par une nuit où le café ne suffisait plus.

Plutôt que d'inclure dans son framework d'application TV une règle CSS qui fasse le job, Google poussait à une balise HTML bricolée, fermant par là-même la porte à un portage simple des applications GoogleTV au Grand Internet.

Et la situation est encore plus démentielle dans la plupart des frameworks modernes, tel dans AngularJS avec la directive ng-href="https://dascritch.net/post/2016/12/06/". Si la raison originelle était de ne pas casser de lien après la build, son usage est vite devenu n'importe quoi et a même pénalisé nombre de sites dans leur indexation.

Nous avons abandonné les standards pour cause de Hype Driven Development en oubliant les problèmes qu'ils résolvaient.

Parait que je ne suis pas seul (à râler)

Maxime Thirouin, développeur d'applications web doué et loin d'être allergique aux dernières nouveautés javascript, a professé lors du dernier DotJS qu'une page web doit pouvoir être consulté sans forcément avoir javascript activé. Une position qui me plaît. Mais est-elle trop conservatrice ? Suis-je un vieux croûton qui râle que c'était mieux à vents ? (prout)

Récemment, j'ai conçu une web-app en page persistante avec un JS assez… complexe. Comme il ne peut être utilisé qu'avec du javascript, j'avais commencé quick & dirty avec des boutons et une gestion de navigation par des variables internes. J'ai décidé de ré-écrire sa navigation afin de remplacer tous les <button> et <div> par des liens <a href="https://dascritch.net/..."> internes aux événements interceptés.

Et bien vous savez quoi ? J'ai gagné sur deux points :

en accessibilité, puisque les <div> étaient remplacés par de vrais liens et l'historique navigateur redevint fonctionnel sans avoir à le ré-écrire
en fonctionnalité, puisque les liens profonds dans mon application devenaient partageables.

Typiquement le genre de détails que je suis le seul à remarquer, mais ce détail a été aperçu par un autre, et il m'a dit que c'était diablement pratique d'y avoir songé.

Songez-y : supporter le clic du milieu peut être utile à d'autres.

Moralité : Laissez le navigateur fonctionner, ne tentez pas de recréer la roue ; en 25 ans, ils auront pensé à bien plus de choses que vous.

CPU Ex0012 : Bonjour à toi, enfant du futur immédiat : Histoire de paquets

Da Scritch — 2015-12-10T13:19:00+01:00

Internet, c'est une série de tubes où les paquets se passent ... euh non, attends... efface, je vais expliquer différemment.
Webdev

Ceci est une partie du script de la release Ex0012 du programme CPU, diffusé Jeudi 10/12 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, enfant du futur immédiat, toi qui est désormais branché par wi-fi, bluetooth, 4G mais qui aimerait bien savoir comment marche tout ça.
Bon, en fait, ça ne marche pas, ça fonctionne, parce que si ça marcherait, on serait toujours derrière à galoper après et cela ne serait pas pratique du tout.

Aujourd'hui, on va tenter de t'expliquer ce qu'est internet, dans les tuyaux, dans les câbles, dans les faits et dans les routeurs. Comment fonctionne-t-il, mais surtout, comment a-t-il été conçu.

Oui, un petit cours technique, très simple à comprendre, on s'est dit qu'il était indispensable de se détendre un peu après deux releases assez éprouvantes. Et si tu t'y connais un peu, revoir ses classiques depuis la base n'a jamais fait de mal à personne. Ou alors tu te gausseras mais t'aurais pas trouvé forcément mieux pour expliquer.

Internet s'explique déjà dans son nom : inter network, c'est l'union de plusieurs réseaux informatiques, totalement disparates, mais qui au final, grâce à un peu de salive et d'huile de coude, arrivent à communiquer entre eux, voire à être interopérables. Ainsi, quand ton smartphone passe de ton opérateur mobile au réseau wi-fi de chez toi, les interfaces et protocoles techniques sont très différents, mais les applications arrivent à tourner sans trop de problèmes.

Alors, c'est quoi un réseau informatique ? C'est au moins deux ordinateur qui veulent discuter entre eux. Et toute la difficulté est de faire discuter plusieurs d'entre eux. Là commence la magie du routage, de gestion de trafic, etc...

Comme c'est bientôt Noël, je vais te raconter comment arrivent les paquets…

Disons que, dans un Village, 8 personnes sont plus ou moins éloignées et qu'elles se sont numérotées entre 1 et 8. Disons que la n°6 a un paquet pour le n°2. Le n°6 (qui maintient qu'il n'est pas un numéro, mais on va quand même la désigner par ce numéro, sinon il va vite devenir chiant) va coller une étiquette sur le paquet, indiquant envoyé par n°6, et destiné à n°2. Il passe le paquet au numéro 5, parce que numéro 5 est à mi-chemin et qu'il veut bien s'en occuper, mais surtout parce que le passer au numéro 7 est un peu débile, s'il en croit la carte du Village. Numéro 5 lit le destinataire, voyant que ce n'est pas pour lui, va le passer au n°4, etc... jusqu'au n°2 qui va l'ouvrir, puisqu'il lui est destiné.
Bonjour chez vous !

Alors certes, c'est un peu schématique, n'est pas Jamy dans un camion qui veut, et cela ne se passe pas exactement comme ça, mais en gros, le paquet est la charge utile, ce sont les données elles-mêmes, et les adresses de départ et d'arrivée sont les métadonnées pour que le réseau fonctionne. Et le tout fait un datagramme.

En résumé, internet, c'est ça : différents réseaux qui discutent entre eux, basés sur des adresses et pour différentes fonctions.
En certains points, on accède à d'autres réseaux, tout comme on accède à l'international téléphonique, sera le genre humain pardon je m'emporte

Et quitte à faire une analogie téléphonée, comme retenir le numéro de téléphone de tous ses amis n'est pas toujours faisable, il existe des annuaires, les DNS, et ça, enfant du futur immédiat, on t'en a déjà parlé précédemment.

Dans la réalité, Internet ne s'est pas conçu rapidement. Il a fallut passer par différentes étapes, et notamment une unification des fonctions de bases de réseaux. Par exemple, pendant des années, il y eu des réseaux qui refusaient d'utiliser le même protocole. C'était ainsi le cas de réseaux comme celui d'AOL, l'AppleTalk qui reliaient les Mac, ou l'IPX de Microsoft. Ils ont tous les trois disparus, parce que mettre en œuvre les protocoles d'internet étaient moins chers et souvent plus fiables.

Internet a aussi une propriété particulière : les paquets peuvent arriver dans le désordre, c'est le destinataire final qui reconstruit dans l'ordre. . Un peu comme si pour ton étagère ikéa, tu recevais d'abord les planches, ensuite le plan et enfin les clous parce que les livreurs se sont trompés de direction sur la rocade. Peu importe l'ordre dans lequel les paquets arrivent, tu sauras quand tu peux commencer à monter l'étagère quand il aura tous les éléments attendus.

Puis les services apparurent. Internet avait heureusement été conçu pour ne pas être limité fonctionnellement. À l'adresse sur les paquets que l'on se transmet, on a rajouté un numéro de port, compris entre 1 et 65535. Si on s'adresse au port 80 ou 443, vous parlez à un site web. Les ports 25,110 et 143 servent à envoyer et recevoir des e-mails.

Enfant du futur immédiat, on vient de t'expliquer quelques bases sur comment fonctionne internet. Et encore, on ne t'a pas parlé des chats (ceux des dialogues) ou des licornes (celles à un milliard).
Dans cette release, on va plutôt t'expliquer comment internet se construit et il évolue techniquement. Et on peut aussi te faire cette blague sans avoir besoin de te l'expliquer :

« C'est deux paquets UDP qui discutent :
— Ha bon ?
— Tu sais que je peux arriver avant toi ?»

Bonjour à toi, enfant du futur immédiat : Journalisme de données

Da Scritch — 2015-11-13T13:50:00+01:00

Des données en très gros volume, des feuilles de calculs et des formules, des générateurs de graphiques et des interactions pour les lecteurs.
Webdev

Ceci est une partie du script de la release Ex0009 du programme CPU, diffusé Jeudi 12 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, enfant du futur immédiat, toi qui nous écouteras parce que tu te dis que tu écoutes un programme d'information, alors qu'en fait pas du tout : nous faisons un programme d'informatique. Nuance. Et à ne pas confondre avec un programme informatique. Nous, on se télécharge dans ton oreille.

Aujourd'hui, nous allons parler d'information, (comme quoi...) , et de journalisme dans une branche assez spécialisée mais actuellement très en vogue : Le datajournaliste. Pour ceux qui furent attentifs à la release de la semaine dernière, oui, c'est un mot valise, qui associe un mot français à un mot anglais, mais là n'est pas la question M. Elkabbach !

Le datajournalisme, n'est pas que l'alliance entre le Word qui édite les articles et l'Excel qui manipule des données dans le même Office. Non, le datajournalisme est une nouvelle manière de mettre en scène l'information, de façon moins textuelle et plus globale.

Globale au sens qu'au lieu de prendre des témoignages épisodiques par micro-trottoirs et best-of des lieux communs les plus affligeants, le datajournalisme fait une vraie analyse statistique, voire même parfois une anonymisation de données englobant une population complète. On est bien au-delà du ressenti au doigt mouillé, avec une précision manométrique des courants.

Avant, le datajournalisme consistait surtout à représenter l'information autrement qu'avec des mots. Ainsi apparurent dans la presse les cartes, camemberts et autres chartes. Les sources de données sont forcément des sources de référence, fiable, ou sinon de terrain. Ainsi, les informations statistiques publiques ou de grandes compagnies sont considérées comme de référence, alors que les informations qui sont recueillies par des volontaires, par des lecteurs, etc.. doivent passer par une étape de modération afin de s'enquérir de sa fiabilité.

D'une manière assez amusante, le datajournalisme est une discipline assez ancienne, qui est apparu dès que s'est montré le besoin d'afficher des cartes, ou de monter des proportions entre nombres. Comme le disait Napoléon à ses généraux dans sa war-room, tout en planquant sa bouteille de fine (Napoléon, of course) dans son veston, Une dataviz vaux mieux que qu'un rapport de 100000 signes.

Si vous lisez aussi les textes des chroniques et les références de nos émissions sur notre site web cpu.pm, vous avez peut-être remarqué que nous tentons d'éviter de lier vers la Wikipédia, afin de mener des recherches d'articles de référence par notre chef. Or, il se trouve que l'article journalisme de données de l'encyclopédie collaborative fait référence à une carte établie en 1854, des quartiers miséreux de Londres, avec un point noir devant chaque foyer comptant un décès dû au choléra. Avec l'indication des pompes à eau publique, cette carte montrait directement la corrélation entre les victimes de l'épidémie et les fontaines à eau publiques. Durant cette même décennie, en 1858, on a une représentation en camemberts indiquant les proportions entre les différentes causes de décès des soldats de Sa Majestée.
Un siècle plus tard, lors des élections présidentielles américaines de 1952, la chaine CBS réalise un coup de maître en estimant la victoire d'Eseinhower à partir de projections faites sur ordinateur. Alors attention, projection non pas graphique, mais lue par un speaker à partir d'une sortie papier d'imprimante.

Mais si ces métiers sont désormais passés de l'illustration au crayon et à la plume à celle produite par infographie et aux templates graphiques alimentés des feuilles de calculs ; nous avions toujours des présentations surtout statiques.

Le datajournalisme, c'est aussi la présentation de données d'une manière interactive. ce sont les pages webs dynamiques côté navigateur qui en montrent vraiment l'importance. De Flash aux technologies HTML5 comme le tri de données dans les tableaux dynamiques, puis le graphisme vectoriel en SVG, aux représentations en 3D avec WebGL. Et je n'oublie pas le présentateur TV qui se met sur un fond vert et fait mine de toucher une incrustation OpenGL, ou qui touche un gigantesque écran graphique, histoire de montrer que sa chaîne TV a mis plus de moyens blingbling que ses concurrentes, et que donc les informations se voient mieux sur le canal 3D. Chaussez vos lunettes.

Mais au-delà du talent d'écriture, de présentation et de mise en forme des données, il faut désormais aussi être un réel développeur front-end, c'est à dire un spécialiste des navigateurs web. Si des bibliothèques javascript facilitent la transformation graphique de données, tel l'excellent D3.js, il faut néanmoins s'y connaître un minimum en programmation et aussi en design et en accessibilité pour en faire une présentation attrayante, informative, fonctionnelle et compréhensible.

Et donc, il n'est pas étonnant de voir des développeurs étroitement associés, soit dans le quotidien britannique The Guardian, soit en France avec le regretté site OWNI.
Il y a donc parfois autant de développement logiciel dans un dossier en datajournalisme qu'en investigation de fond.
L'énorme différence est la pluridisciplinarité de l'exercice.

Désormais, il y a aussi l'open-data, et l'application (enfin !) de la loi n° 78-753 du 17 juillet 1978 instituant le libre accès des citoyens aux données produites par l'Administration.
...
Oui, 1978, et on ne parle d'open-data que maintenant... un tel délai démontre le retard de l'administration à répondre.
Ce qui permet de vérifier, mais aussi de faire apparaître certains sujets qui n'apparaissaient pas jusque là. Les détails qui ressortent comme quand on joue sur une photo en jouant les contrastes, les couleurs, en zoomant ou en la tordant.
Arrêtez de jouez Les Experts Miami™ dans le fond pendant que j'explique, ça me déconcentre.

Mais de là, il y a aussi le problème de l'information qui est déformée pour correspondre à une conclusion espérée. Même dans le datajournalisme, il n'est pas impossible de fausser les faits, puisque très peu de personnes regardent derrière les graphs les données d'origine. En modifiant les unités par exemple, ou même, méthode connue depuis les débuts des instituts de sondages, en ayant une question qui n'est pas totalement neutre.
À l'inverse, le datajournalisme peut réfuter un discours mensonger ou erroné. Mais il devient alors d'autant plus critique d'avoir des sources au-delà de toute critique. Forcément, fact-checking amène inspection d'autant plus inquisitrice.

Enfant du Futur Immédiat, de même qu'il faut apprendre à lire et contextualiser comment est reporté un fait d'actualité, il t'est tout aussi important d'apprendre à lire un graphique. Croise tes sources, une personne bien informée vaut mieux qu'une aux infos biaisées.

Plantage : Sex.com

Da Scritch — 2015-11-03T06:18:00+01:00

Du stupre ! De la nudité ! De l'argent ! De l'escroquerie ! Et des bannières publicitaires honteuses :... Manque plus que le jingle de Personne ne bouge qui fait SCAAAANDAAAAAALE !
Webdev

Ceci est une partie du script de la release Ex0007 du programme CPU, diffusé Jeudi 29 à 11h. Plus d'infos sur le site de l'émission.

Au moment où les registres DNS furent mis en place, l'obtention d'un nom de domaine était une formalité gratuite. Puis les noms de domaine devinrent une forme de location, obtenue par des services de registrar, contre le paiement d'un bail annuel.
Mais nous restions dans la règle du premier arrivé, premier servi.

Gary Kremen réserva en mai 1994 le nom de domaine sex.com ; se disant qu'un nom aussi court, quasi universel, et très sulfureux ferait sûrement un bon investissement dans le futur. Mais dans l'immédiat, notre entrepreneur est plus préoccupé à développer son service de rencontre match.com. Pour rappel, le navigateur Netscape 2.0 venait à peine de sortir.

Mais il se trouve que ce nom était vraiment trop attirant pour ne pas l'exploiter. Ainsi Stephen M. Cohen, qui a été maintes fois convaincu d'escroquerie à l'identité et de vol, dont deux peines de prisons, la dernière qu'il termina de purger en 1995, se dit qu'il pourrait se ré-insérer dans la société. L'audacieux décida de tenter d'attraper le train d'internet sans payer de billet. M. Cohen passa plusieurs coups de fils et envoya plusieurs lettres au registrar de tous les noms en .com, Network Solutions, en tentant de se faire passer pour le représentant légitime du possesseur de sex.com. Une attaque classique en brute-force, sans même utiliser d'e-mail, puisqu'il n'avait pas d'abonnement internet ! (si ! si ! ce scabreux détail est dans les attendus du jugement)

Un jour d'Octobre 1995, le registrar reçu un fax.
Un fax.
Un simple fax qui ordonnait de changer de propriétaire ledit nom de domaine.
L'employé de Network Solutions qui lu le fax s'exécuta sans plus de vérifications, et transféra le nom de domaine sex.com de M. Kremen à M. Cohen

Plantage…

Un fois de plus, PEBKAC, le problème est entre la chaise et le clavier, l'humain s'est révélé être la plus grande faille de sécurité.

L'affaire révéla que les procédures de vérification d'identité de Network Solutions n'étaient pas très solides, voire même totalement inexistantes. Par la-même, cette erreur manifeste mis un très sérieux doute pour tous ses clients qui louaient un nom de domaine en .com ou en .net.
Mais surtout, la désinvolture de l'opérateur choqua : Quand Kremen s'aperçut du transfert imbu avant même son premier coïtus interruptus, il demanda à Network Solution de restaurer sa propriété sur le titre en opérant l'opération logique inverse. Network Solution haussa des épaules et lui répondit que le mieux serait d'aller au tribunal. Sans aucun embarras ou excuse.

Ben voyons...

C'est ce que fit Kremen bien sûr !

Le mot sex était déjà sulfureux dans la très puritaine Amérique, le nom de domaine sex.com devient un feuilleton qui ébranla le secteur économique naissant des sites webs, avec un viol manifeste d'une proprété virtuelle.

Pénétrant sans préliminaires et façon gonzo, Stephen Cohen fit une belle fortune : un chiffre d'affaire estimé à 100 M$ sur l'année 1998, facturant un million de dollar mensuels la présence d'une bannière sur ses pages, et les services de Nude As A Service, vendus 25 $/mois à 9 millions d'onanistes baveux connectés.

Quand il dû expliquer sa manœuvre et surtout quel droit il avait à ~~sucer~~ sucrer ce nom, le margoulin expliquait que dans les années 1980, il gérait le BBS French Connection, un serveur télématique de discussion qui fut accusé d'être lié à des activités de proxénétisme, dont l'exécutable s'appelait SEX.COM . À l'époque, dans le monde MS-DOS et CPM, la plupart des fichiers exécutables se terminaient en .COM . Si une telle défense avait abouti, n'importe qui aurait pu revendiquer n'importe quel nom de domaine en 8 lettres ou moins.

Cohen perdra le procès, fut condamné à payer 65 M$ en dommages et intérêts. Le filou convaincu organisa une faillite frauduleuse, vidant ses comptes vers des banques au-delà du Pecos et s'envolera pour Tijuana sans payer l'amende au nez et à la barbe de la Justice. Inutile de dire que le Ministère Public a assez peu apprécié que le condamné joue la fille de l'air avec sa fortune et envoya les U.S. Marshalls à ses trousses !
Son exil au Mexique ne l'empêcha pas de se retrouver en prison pour immigration clandestine (eh oui), d'où il fut extradé aux États-Unis. À ce jour, il n'a toujours pas payer son dû, s'étant déclaré en faillite.

Dans un autre procès intenté par Kremen, Network Solution fut bien reconnu comme en partie responsable, mais sans aucune pénalité à payer. Car il n'y eu aucune transaction financière et aucun contrat de signé entre Gary Kremen et le registrar. Eh oui, rappelez-vous ! Kremen ayant obtenu gratuitement son nom de domaine. Chou blanc, mais au moins, il récupéra le contrôle sur sex.com

Dès qu'il récupéra le contrôle du nom de domaine, Kremen compris qu'il ne fallait pas le laisser dormir, et donc ouvrit une page web uniquement peuplé de publicités, qui s’avéra rentable malgré l'explosion de la bulle spéculative d'internet en 2001. Il le revendit pour 13M$ à Escow LLC, ce qui reste à ce jour une des 5 transactions les plus chères du mercato des noms de domaines.

Sex.com sera un bon coup, le genre à ébranler l'ensemble de l'immeuble.

Depuis, des protections minimales durent mises en place pour éviter un transfert de nom de domaine entre registrars si le locataire ne le désire pas, et un procédé par un numéro de dossier jetable fut mis en place pour éviter qu'un simple fax ou e-mail permette ce genre de cafouillage.

CPU Ex0007 : J'ai loué cpu.pm

Da Scritch — 2015-10-29T13:20:00+01:00

On a commencé par un annuaire, on va finir par une grosse bulle et des noms creux dévalués...
Webdev

Ceci est une partie du script de la release Ex0007 du programme CPU, diffusé Jeudi 29 à 11h. Plus d'infos sur le site de l'émission.

Bonjour à toi, enfant du futur immédiat, toi qui nous écouteras parce que tu as trouvé notre programme d'une manière quelconque.

La première chose qu'un enfant apprend à faire, et la première chose avec laquelle on note son intelligence, c'est de nommer les choses. Ainsi fut le verbe, et p-a-papa !

Dans les protocoles réseaux d'internet, les machines discutent entre elles en s'appelant par des adresse chiffrées, qu'on appelle une adresse IP. Celles-ci ne sont pas forcément faciles à retenir pour les humains. D'ailleurs, maintenant que nos téléphones ont tous un carnet d'adresse intégré, je doute que vous ne connaissiez plus d'une dizaine de numéro de téléphones de vos proches.

Pour accéder à un site internet, le faire à partir de son adresse numérique est nettement moins évident. Il y a des cas qu'on retrouve facilement, par exemple une page web grâce à un moteur de recherche, comme on en a parlé il y a 15 jours. Mais pour un serveur non indexé, pour une adresse e-mail, et que sais-je encore, n'avoir qu'une adresse numérique est tout sauf pratique.

Heureusement, il est possible de donner un nom d'alias à votre ordinateur. Et donc indiquer que le site cpu.pm pointe vers l'adresse IPv4 89.234.156.173 ou en IPv6 2a01:6600:8083:ad00::1. Ceci peut se faire en éditant le fichier hosts, en général dans le répertoire /etc de votre ordinateur. Et d'ailleurs, c'était plus ou moins comme ça que faisait les gros centres informatiques reliés aux origines d'internet dans les années 1970s et 1980s, avec les responsables systèmes qui s'envoyaient par e-mail les modifications d'adresse IP et leurs noms.
Mais comme ce n'était pas très pratique à maintenir surtout une fois passé de 10 machines à quelques centaines, en 1984, les responsables décidèrent de créer un annuaire commun, le système de nom de domaine, ou Domain Name System (oui, je m’entraîne déjà pour l'émission de la semaine prochaine). Avec une convention de nommage allant de la droite vers la gauche.

Tout à droite, vous avez le TLD, ou Top Level Domain, ou encore Domaine de Premier Niveau. Les 6 TLD génériques qui furent d'abord créés permettaient de catégoriser et donc de comprendre à qui on s'adresse :

en .com, à une entreprise
en .edu, à une université
en .org pour une organisation à but non lucratif
en .net, à un prestataire technique d'internet
en .gov pour un ministère ou tout autre organisme du gouvernement fédéral américain
en .mil, à un ordinateur du Pentagone, classement totalement à part rien que pour faire plaisir aux illuminés des théories du Complot

< De ces 6 TLD, on commença par la suite à créer des TLD en deux lettres, ou cc-TLD, rattachés à des pays. Le code est lié à une nomenclature déjà existante, la ISO 3166-1. Vous connaissez le .fr, qui est celui de cocorico, la Frrrrrance. Il y a .uk pour le Royaume Uni, le .de pour l'Allemagne.
Sauf que tout le monde a oublié qu'il existe un .us pour les États-Unis, sans compter les pays qui ont disparu de nos jours comme le .su pour ... l'URSS (que l'on peut encore demander) ou le .cs pour la Tchécoslovaquie.

Avant le TLD, vous avez le qualificatif de domaine, par exemple radio-fmr . C'est en général le nom de la marque d'une entreprise. Le qualificatif et un TLD forment un nom de domaine, et c'est pour l'obtenir que l'on loue à l'année.

Et en dessous, on peut mettre des sous-domaines. Comme par exemple "www" pour www.radio-fmr.net , ou encore "admin" ou encore "pc-de-dascritch". Mais ces sous-domaines sont quasi gratuits : je peux en créer autant que je veux, addossé à mon nom de domaine. Leur création relève de la responsabilité de celui qui aloué le nom de domaine, et à son entière discrétion.

En fait, ces registres DNS sont les derniers éléments réellement centralisés d'internet. Et l'enregistrement d'un nom de domaine se fait en s'adressant, directement ou non , à une entreprise gestionnaire du TLD voulu.
Et la règle d'obtention est la plupart du temps très simple : si le nom est disponible et que tu paies, premier arrivé, premier servi !

Alors évidemment, la question de la légitimité d'un nom de domaine fut très vite posée. Prenons lotus.com . Laquelle de ces entreprises pourrait y avoir plus le droit que les autres ?

(le plateau passe en mode quizz)

L'éditeur de la suite logicielle d'entreprise Lotus 1 2 3 et Lotus Notes ?
Le constructeur britannique de voitures de course, que vous pouvez vous payer si vous avez été revendeur de la suite logicielle précédemment nommée ?
Le fabriquant de papier toilettes ultra-doux que vous ne manquerez pas d'utiliser la première fois que vous aurez eu à faire un freinage d'urgence avec votre voiture de course homonyme ?

Allez, je tue le suspens : actuellement, c'est IBM qui l'a, ayant racheté l'éditeur logiciel.

Afin d'organiser la gestion de ce business est créé en 1998 l'ICANN (Internet Corporation for Assigned Names and Numbers) qui régule à la fois les règles de ce business, distribue les TLD entre registrars et maintient les serveurs DNS racines qui sont à la base des annuaires d'internet.

À partir de la fin des années 1990s eurent lieu des réservations de noms de domaines dits en or. Parce qu'ils représentaient ceux d'une marque, d'un mot commun ou d'un verbe en anglais, d'une ville ou d'un nom de famille plutôt courant.
La plupart de ces noms de domaines aboutissaient nulle part. Ou plutôt, presque nulle part : un site web était placé derrière, une simple page, qui disait que le nom de domaine est disponible à la vente, à un prix d'achat singulier.
Singulier au sens que le nombre n'a pas qu'un chiffres, mais plusieurs, parfois les possesseurs de certains noms demandent plusieurs centaines de milliers d'euros, et que tant que personne n'est prêt à débourser un tel chiffre, et bien ils continuent à louer leur nom pour une dizaine de dollars annuels.

Bien évidemment, il y eu très vite des abus, que l'on appelle cybersquatting, l'art, non pas de faire de la trottinette en tenue de Robocop, mais bel et bien de revendiquer un nom connu sans en avoir dessus le moindre droit, et en exiger une somme escroquatoire assez importante.
L'ICANN a créé une procédure de résolution en 1999, le UDRP (ou Uniform Dispute Resolution Policy). Pour l'Europe, ces conflits se résolvent devant l'OMPI, Office Mondial de la Propriété Intellectuelle.

Seulement... Si vous êtes dépositaire d'une marque internationale, il faut néanmoins la protéger le plus possible, donc déposer le plus possible de noms de domaines, dans le plus de TLD possibles. Or, il y a depuis une dizaine d'année une inflation délirante du nombre de Top Level Domain, avec parfois des limitations ubuesques comme le .mobi mais plus souvent des tarifs démentiels .

Et ça, je suis retombé dedans en voulant déposer un nom de domaine pour l'émission qui redirige vers son site web, mais qui soit facile à prononcer à la radio, à retenir dans la tête et à écrire sur un téléphone portable.
Il est vrai que les noms en 3 lettres en .com en .net ou en .org sont tous occupés depuis la fin du précédent millénaire. Mais j'ai quand même testé...
Sauf qu'en faisant mon shopping chez le registrar Gandi, j'ai eu des propositions plutôt délirantes, genre "cpu.space" pour 423,32 €/an, inutile de dire qu'on obtient vite des prix stratosphériques sans réelle justification.
J'ai pris les 5 plus chers.

Or qui "classement" dit "top" et qui dit "5" dit .... Le Top 5

cpu.tech pour 11347,64 € /an
Ex-aequos cpu.online , cpu.site, cpu.review, cpu.software pour 3816,18 €/an
cpu.website pour 1670,07 € /an
cpu.八卦 (gossip en chinois) pour 1579,36 €/an
cpu.market pour 1353,35 € /an

Classement non exaustif, effectué en fonction des noms disponibles et des tarifs proposés par gandi.net cette semaine, hors promotions et rabais pour achats en lots.

À noter qu'on tombe à 9€/an avec trois autres lettres, genre "zlo". Car certains noms sont considérés "en or", et donc revendu au même prix au gramme par le gestionnaire du TLD, mais hélas sans divulgation publique des critères. Je lis la réponse officielle de Gandi sur le sujet, que nous avons donc sollicité, faute de documents officiels et publics sur le sujet :

Depuis un peu plus d’un an, 600 nouvelles extensions de noms de domaine (TLD) sont venues s’ajouter aux extensions existantes (.COM, .FR, .NET, …), et il est courant de constater depuis des différences de prix substantielles sur une même extension.

L’enregistrement de zlu.tech, par exemple, serait facturé au tarif standard de 50€ par an, tandis que le domaine cpu.tech se retrouve propulsé à plus de 11.000 euros.

En cause, l’utilisation par les registres du mécanisme dit « premium », à savoir l’application d’un tarif plus élevé à une liste de noms de domaine ayant la particularité d’être facilement mémorisables, souvent très génériques et par conséquent très intéressants en termes de référencement naturel.

Qu’il soit générique ou qu’il vise un secteur niche, les registres établissent leur liste de noms premiums parmi ceux qui semblent les plus bankables, et en fixent les tarifs de manière discrétionnaire, le bureau d’enregistrement (registrar) n’ayant d’autre choix que de l’appliquer lorsqu’un client souhaitera l’enregistrer, à moins qu’il préfère ne pas les commercialiser.

Chaque liste de noms premium est spécifique à chaque nouvelle extension, tout comme la politique tarifaire appliquée. Ainsi, le nom de domaine cpu.tech est il considéré comme un Premium, mais pas les noms de domaine cpu.photos ou cpu.immo qui sont commercialisés à un tarif annuel standard, leur attractivité publicitaire étant moindre.

Ainsi lol.news monte à 46788 €/an. Pour vous iTélé, puisque vous allez changer de nom.

Évidemment, inutile de vous dire que quand j'ai dû choisir le nom de domaine de l'émission, je me suis attardé sur le moins cher, le plus logique et le plus facile à écrire avec un téléphone portable.
C'est pour ça que le programme CPU a comme site web raccourci cpu.pm , nom que j'ai donc déposé, pour 12 € annuel. Le .pm est le ccTLD de Saint-Pierre Et Miquelon, que j'ai le droit d'utiliser en tant que citoyen Français. Mais je le renvoie sur un sous-domaine, au cas où...

Enfant du futur immédiat, le système de nom de domaine est le dernier service centralisé d'internet, mais très pratique. Il ne repose que sur de la location d'adresse, mais a ses vices : il est devenu un business très lucratif, et l'explosion du nombre de TLD "génériques" démontre que nous sommes clairement dans une bulle spéculative latente. Il est probable qu'un jour, cette bulle éclate, des noms de domaines ne résolvant plus rien.

Mercis à Sophie Gironi, Alexandre Hugla et les équipes de Gandi qui ont pris le temps de rédiger une réponse officielle.

Ainsi naquit l'EFF

Da Scritch — 2015-10-05T13:17:00+02:00

L'Electronic Frontier Foundation est là pour votre salut internet.
Webdev

Chronique lue pour l'émission radio CPU Ex0003 : Les élus politiques face aux geeks

Nous sommes aux États-Unis en 1990 et l'histoire commence par un vol de logiciel.

Apple soupçonne que le code source des ROM, l'équivalent du BIOS de ses ordinateurs MacIntosh, n'aie été dérobé. La firme à la pomme est dans un instant critique, car la gamme ultra-rentable de ses ordinateurs Apple II a été retirée du marché, mais les ventes de MacIntosh ne décollent que doucettement, sûrement dû à un prix de vente assez imposant ; pendant ce temps, des émulateurs de MacIntosh commencent à fleurir et pourrait noyer l'original si ces ROM courent dans la nature, comme cela a faillit être le cas avec ses Apple II.

L'enquête dudit larcin est confiée au FBI, qui peut enquêter sur les crimes fédéraux, c'est à dire ayant eu lieu sur plusieurs états, grâce à son maillage de bureaux locaux et d'agents de terrains.
John Perry Barlow, entres autres parolier du groupe de rock Grateful Dead, se retrouve perquisitionné dans cette affaire. Mais lors de cette intervention dans son domicile, il se rend vite compte que les agents fédéraux menant la procédure ne comprennent pas l'informatique. Il n'était donc pas sûr que ses droits de citoyen soient correctement protégés, et notamment le premier d'entre eux qui est d'être présumé innocent, puisque la nature même du délit était totalement imperméable aux agents de police. Comme il le dit lui-même : « avant même de pouvoir prouver mon innocence, il fallait que je décrive le délit. »

Or, depuis la fin des années 1980s, les États-Unis sont dans une époque de forte judiciarisation des délits informatiques, allant jusqu'à l'absurde : l'éditeur de jeux de rôles Steve Jackson Games fut perquisitionné sur des soupçons de piratage informatique. En fait, la préparation éditoriale d'un jeu de rôles sur l'univers cyberpunk était vue comme un manuel criminel. On y parlait à outrance de hackers et de piratage. Oui, pour une œuvre littéraire de science-fiction, les ordinateurs de Steve Jackson Games furent confisqués, mettant à mal une entreprise qui était florissante.

Ainsi naquit l'EFF, le 6 Juillet 1990, organisation à but non-lucratif est fondée par John Perry Barlow, John Gilmore et Mitch Kapor.
Elle a pour mission de concilier les « conflits inévitables qui ont commencé à se déclencher à la frontière entre le cyber-espace et le monde physique ».

Si de nombreuses organisations de défense citoyennes existent déjà aux États-Unis, comme l'ACLU (l'American Civil Liberty Union), elles n'étaient pas encore suffisamment spécialisées et impliquées dans la révolution informatique.

La Electronic Frontier est une référence directe à l'ère des pionniers du Far West : une zone de liberté, d'opportunités, au-delà des frontières connues où tout est à écrire. Cette référence libertaire, libertarienne et libérale se heurte à une autre logique : Le bloc de l'Est s'effondre et l'URSS est en train d'imploser. Les forces de l'ordre doivent donc repérer au plus vite quelles sont les menaces potentielles, quitte à s'y méprendre : Pour elles, il est acquis que l'ennemi intérieur est là, les hippies de la Silicon Valley veulent faire tomber l'ordre établi.

En réponse à cet état d'esprit, John Perry Barlow écrit en 1996 la Déclaration d'Indépendance du CyberEspace, attaquant la Communication Act, loi qui selon lui risquait de mettre internet sous la coupe du gouvernement Américain.

Des organisations existent à travers le monde qui tentent elles aussi de réduire ces cassures idéologiques entre le monde physique et internet, comme La Quadrature Du Net, mais l'EFF reste la référence, car elle est sur l'ensemble de la chaîne politique : du lobbying auprès des législateurs, l'interpellation des gouvernements, et surtout l'assistance juridique.

Et l'EFF se montre bien vite forte utile pour le secteur informatique, allant aussi bien avant les lois, devant l'exécutif et au créneau devant les tribunaux, parfois jusqu'à la Cour Suprême des États-Unis. Et à l'heure de la multiplication des traités internationaux économiques, qui remettent en cause lois nationales et droits des citoyens, l'EFF a la masse critique suffisante pour attirer le regard des médias.

Très rapidement, l'organisation s'est internationalisée, comme Internet. Et avec l'apparition d'autres fondations autour des standards informatiques (comme le W3C), du logiciel libre (comme Mozilla) ou de gestion de l'infrastructure d'internet (comme l'IETF), elle a trouvé des alliés de poids, qui n'hésitent pas à relayer ses campagnes.

L'EFF est désormais un modèle non seulement pour la Quadrature Du Net, mais aussi pour Amnesty International et Reporters Sans Frontières, qui sont désormais sensibilisés sur les armes numériques, extrêmement puissantes contre la Démocratie.
Mais tout le problème est justement l'omniprésence du numérique, et donc la démultiplication des terrains d'intervention de l'EFF. Du coup, n'est-elle pas allée trop large ? et ne fait-elle pas un peu trop le jeu de certaines très grandes entreprises ?

Références :

da scritch net works - Webdev

N2HDF 2026 Toulouse

cpu-audio.js enfin en 7.0

Deux couleurs bizarres en CSS

La Couleur tombée du DOM

transparent

currentColor

Alors quel est le problème ?

Essayez vous-même !

Où tu rêves d'une licorne rose invisible

Tentative 1 : CSS pure, rgba() et deux variables

Tentative 2 : Polyfill javascript pour déduire une couleur totalement opaque

Et là, tu peux plus voir cette exception en peinture

La couleur tombée du Ciel

We need Web Share

The switch

The wish

The witch

The twist

The tweet

So what ?

Le blues du Web Share

The switch

The wish

The witch

The twist

The tweet

Ben alors, on fait rien ?

Retravailler un lecteur web audio dans les petites largeurs

Petits dans la poche, gros dans les contraintes

Et déjà un premier souci avec les CSS media queries breakpoints

breakpoint sur un élément, comme on peut, comme un porc

Le problème de la navigation fine sur une largeur fine

Quatre exemples de time-line en natif

Le jog shuttle du Beta SP

Supprimer les bords ronds

Agrandir la time-line

Deviner où l'on vise d'un coup d'œil

Naviguer plus finement

La mauvaise surprise du temps

L'enfer des petits détails

Bref…

Reconstruire son lecteur audio pour le web

Et si on étendait ce tag ?

Pointer dans le temps

Mes règles de base :

Le papa player

Les WC étaient fermés de l'intérieur

Les Web Components sont formidables

Dégradation élégante

Brique-olons

L'interface

Pas de bol, votre navigateur ne supporte pas les Web Components

La puissance du chapitrage

Ce que j'ai appris

Je me suis néanmoins planté

L'avenir imaginé pour mon lecteur

« Mais pourquoi t'embêter ? y'a les apps natives maintenant ! »

Mettre de l'audio dans le web n'a pas été simple

J'ai eu une chance incroyable

Là où je tresse des lauriers à… Flash !

Hosanna, résonnent les <audio> au plus haut du W3C !

Code code code codecs : entre libres et payants

En 20 lignes pas plus : Le focus sur le champ de recherche

Vous êtes ici

La problématique

Le laboratoire de Dexter

Le truc

Sous le capot

En 20 lignes pas plus : gérer les options d'appel de tes scripts bash

TL;DR Montre ton code !

Simple et basique

À améliorer

En 20 lignes pas plus : un verrou non-concurrentiel pour tes scripts bash

Le principe (de la série)

L'énoncé du problème

TL;DR Le corrigé

Usage

Préliminaires

lock_script() ligne à ligne

Tentative 1 : CSS pure, `rgba()` et deux variables