da scritch net works - Mot-clé - javascript

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.

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 !

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.

Souvenirs de Paris Web 2016

Da Scritch — 2016-10-04T06:30:00+02:00

Paris Web te rappelle une chose fondamentale : c'est beau d'avoir des valeurs communes et l'amitié avec. Célébrons nos compétences !
Sortons

Si vous êtes sur un ordi de bureau, cliquez la première image, puis clic à droite (désolé, le script a 10 ans, faut que je le remettre d'équerre)

Mon premier Paris Web (2013) fut au Palais Broignart. Depuis, c'est chez un autre Grand Dieu que je respecte…

La rituelle soirée des orateurs, où se font des confidences très indiscrètes. Ce sont les premiers amis de 5 minutes que je revois, déjà le cœur qui bondit. Et là aussi, j'ai eu la surprise de voir combien notre émission CPU pouvait susciter d'émotions.

Et puis le lendemain, prendre son accréditation, découvrir la fresque en hommage à Mœbius (que tu nous manques...), parler avec d'autres amis, faire de nouvelles rencontres.

Je passe sur le fait que la licorne est toujours très joyeuse, pour confirmer que ce t-shirt est une référence à « Everything is a remix ».

Puis c'est parti pour les premières conférences

Encore une fois, le sujet de la vie privée montre qu'il prend dans les conférences techniques une vraie importance, vectrice de valeurs aussi importantes que l'accessibilité qui est la signature de Paris Web.

Sans conteste, l'adorable petite release d'Agnès Hasseer était la star de l'événement. Ça gazouillait et réagissait aux présentations, mettant quelques sourires

Eh oui, qu'on ne me dise pas que je suis seul à ne pas être en costard cravate lors de ce genre d'événement. C'est même plutôt l'inverse… Quant aux goodies, mention spéciale à celui d'Elie qui m'a bien fait rire

(insérer ici un trou noir)

Sur la dernière photo, je suis super heureux de retrouver Tim Carry, qui m'a convaincu de devenir développeur web professionnellement en 2007, c'était sur un commentaire chez Boulet, et il l'a amèrement regretté depuis. Une petite pause (jetons un voile pudique sur les soirées), et on enchaîne sur ce qui se passe sans enregistrements vidéos...

Les ateliers du Samedi

Oui, j'ai adoré l'atelier éducation animé par Coding School. Et comme vous pouvez le voir sur plusieurs portables, les stickers du bouquin de Laurel (on en reparle prochainement) !

Le samedi soir sur les rotules, tout le monde est bien content que cela se termine, mais on est déjà au regret de se quitter.

Si vous cherchez d'autres photos, je vous renvoie sur le pool flickr. Je n'aurai qu'un mot : hâte d'y revenir au plus vite. Comme pour Sud Web.

CPU Ex0010 : Bonjour à toi, enfant du futur immédiat : Organisons des conférences

Da Scritch — 2015-11-27T06:58:00+01:00

Une chronique qui n'est vraiment pas évidente à écrire car rien ne s'est passé exactement comme prévu.
Sortons

Ceci est une partie du script de la release Ex0010 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 bien au chaud dans ton oreille.

Il nous est difficile de faire une émission comme la notre après les événements du Vendredi 13 Novembre dernier.

D'abord parce que certains de nos amis, de nos connaissances, de nos contacts pour ce programme furent proches voire sur une scène du drame à l'heure fatidique.

Ensuite, parce que nous sommes certes un peu rigolos, mais que surtout nous sommes volontairement décorrélé de l'actualité immédiate, dans l'optique d'être le plus objectif possible. Or la release que nous avions initialement prévu la semaine dernière concernait la surveillance globale, avec comme invités La Quadrature Du Net, thématique importante du Capitole Du Libre de cette année.
Une situation qui s'est très brusquement accéléré avec l'état d'urgence.

Or, le sujet des libertés numériques est très en désaccord avec l'ambiance générale suite aux attentats. Donc l'enregistrement que nous avions prévu samedi 14, soit le lendemain des tragiques événements, a été annulé. Nous avions l'impression que parler de vie privée sur l'espace numérique pourrait nous être publiquement reproché. Impression confirmée dimanche 15 par le passage de Bernard Cazeneuve, le ministre de l'intérieur, au journal de 20h de France 2 qui a clairement exprimé qu'il allait combattre de chiffrement.

Comme nous ne voulons ni mettre en péril l'ambiance de notre programme, ni celle de notre radio hôte, nous avons préféré décaler cette thématique, malgré son actualité immédiate. Donc nous en parlerons la semaine prochaine, dans une release de notre programme CPU qui s'annonce là aussi très jouasse.

Ahem.

D'un autre côté, Solarus et moi-même étions en charge d'une suite de conférences pour l'événement Capitole du Libre sus-nommé. Une suite de conférences et d'ateliers que nous avons maintes fois couvert sur cette antenne par des directs, et que donc nous connaissons bien.
Il était donc intéressant pour nous de vivre l'expérience depuis l'intérieur, mais aussi de faire venir après coup les organisateurs pour parler des conférences professionnelles. Car nous avons déjà parlé de Paris Web, mais il y a aussi les JS Conf, les PHP forum, les Journées Mondiales du Logiciel Libre, et plein d'autres.

Alors nous avons voulu comprendre pourquoi mais surtout comment sont organisés des journées de conférences destinées à un public surtout professionnel, ou à un niveau de formation digne de l'enseignement supérieur, et tout ceci uniquement en bénévole, sans aucun bénéfice derrière.
Car nous ne parlerons pas des showcases technologiques de sociétés comme IBM, Amazon, Apple, Google et autres Salesfront qui peuvent se payer les prestations d'organisateurs de salon ; Non, nous parlerons en cette heure d'individus qui se regroupent en association pour parler de technologies tout aussi importantes, mais sans les moyens marketing derrière. Et là dedans, j'y compte aussi des manifestations qui réunissent des makers comme TedX, Fablab Festival, THSF ou l'Agile Tour qui a lieu cette semaine à Toulouse ; par opposition par exemple à Futura-Polis qui aura aussi lieu ce week-end, mais dont le grand barnum est lourdement sponsorisé alors que le public attendu est plus dans les CSP+ lecteurs du Point et autres élus politiques qui sont là pour bien se faire voir en période électorale.

Alors comment choisi-t-on un espace, comment prépare-t-on le programme, comment sélectionne-t-on des orateurs, comment réserve-t-on des hébergements pour eux, comment négocie-t-on la restauration sur place voire comment trouve-t-on des goodies qui vont du tour de cou jusqu'au mug. C'est notre enquête de cette semaine

[jingle reportage]

Sauf que pour notre enquête d'investigation dans le Capitole Du Libre, la situation s'est brusquement compliquée suite aux attentats. Les faiblesses des événements autour de logiciels organisé par des bénévoles sont ressortis d'autant plus cruellement : en l'occurrence, il a suffit d'une demande de durcissement des conditions d'accès, et donc d'un refus de prêt de locaux.

À moins de 5 jours de l'événement, il a fallut pour les organisateurs trouver de nouveaux lieux pour se retourner ou annuler purement et simplement le Capitole Du Libre.

Eh ben figurez-vous qu'ils ont fait les deux !
Le Capitole du Libre fut annulé, et en lieu et autre place fut institué le Bazar Du Libre.

Enfant du Futur Immédiat, alors que je ne fais que conclure le billet d'introduction de cette release, je peux déjà te donner la morale : rien ne vaut la résilience d'un projet quand tous les acteurs sont très motivés.

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.

Les joyeuses suggestions de LinkedIn

Da Scritch — 2014-09-19T07:25:00+02:00

Faut arrêter de mettre des suggestions n'importe où, ça devient n'importe quoi. Et en plus, cela révèle que votre service est parfois mal conçu.
2 ¢ d'humour

Depuis quelques mois, quand vous écrivez vos pensées que vous souhaitez faire partager les sites comme Twitter et LinkedIn se mettent à vous suggérer automatiquement des utilisateurs si vous tapez le début de leur nom. Avant, ils avaient au moins la politesse de ne le faire que si vous tapiez un caractère spécial du type @ ou + avant d'ouvrir cette interface de suggestion qui se montre souvent archi-pénible.

Alors que j'allais décrire à mes contacts professionnels toute la joie qui m'habite quand j'ai appris que par le travail indispensable de la Commission générale de terminologie et de néologie, mon activité pythonesque non-monty se requalifiait en ingénieur logiciel architecte en arrière-guichet, voilà ce qui m'a sauté à la <figure> :

Cette aide trop pro-active se retrouve être à double tranchant : pour les grosses boîtes qui n'ont pas un vrai CM et pour ces services qui ont des fonctions trop bien planquées ou qui manquent sérieusement d'études UX.

Donc, ne soyez pas triste, même si nous les avions perdus de vu depuis un bail, Le Trombone et Patachon de Microsoft Office ont retrouvé un emploi tout aussi qualifié. Et pénible.

Accessoirement, si vous voulez vraiment les remettre d'actualité, vous avez une bibliothèque javascript et la banque d'image :

J'ai toujours adoré le chat, mais impossible de le caresser.

Timecodehash : Lier vers un moment d'un sonore

Da Scritch — 2014-09-03T10:04:00+02:00

Un petit javascript autonome qui va plaire aux podcasteurs, aux musiciens et aux médias. Enfin, s'ils acceptent de jouer le jeu du web et des hypertextes.
Webdev

J'avais précédemment écrit une petite bibliothèque javascript qui permet de voir les ancres d'une page web, ceci à fins de faire des liens sur le bon chapitre (s'il est indexé) dans un très long article. J'ai ensuite monté Anchors Reveal en add-on pour Firefox, qui se montre redoutablement efficace.

Or, depuis le temps que je monte et héberge le Supplément Week-End — l'un des plus vieux podcast francophone qui s'arrête cette semaine — je regrettais qu'il manque un dispositif équivalent pour un sonore ou une vidéo embarquée dans une page distante. Un truc aussi simple qu'un <a href="page#element">…

Il existe néanmoins la possibilité de chapitrer dans certains formats containers, comme le mp4. Mais cette possibilité est très rarement implémentée et le problème reste entier dans le contexte d'une page web.
Ici, une piste marqueur dans le logiciel d'édition Audacity.

Tiens, encore ce matin, dans un e-mail, je voulais pointer la séance des lightning talks du dernier Paris Web les passages de David Rousset et David Catuhe, ben Vimeo ne propose pas de pouvoir pointer à un point temporel précis.

Et comme que des fois, on enchaîne beaucoup d'interviewes dans une émission qui dure deux heures. Et qu'on ne veut pointer que sur une seule à partir d'une autre page. Ouais, il me manquait de pouvoir faire ça :

0:26:20 : David Tsang-Hin Sun et Joseph Saint-Pierre pour le Campus Fab, fablab de l'Université Paul Sabatier
0:56:35 : Laurent Guerby pour Tetaneutral et co-organisateur du TSHF
1:17:41 : Philippe pour le Tetalab, co-organisateur du THSF et pour le badge programmable à souder
1:25:28 : Julien Peccoud pour le collectif Cortecs

Dont acte :

Chaînon manquant

Je me suis lancé dans l'écriture d'une petite bibliothèque javascript, à appeler à partir des pages qui seront appelées. L'idée est qu'il suffit de simplement insérer l'appel, et tout se fera tout seul :

<script src="…/timecodehash.js"></script>
Rappel : ne liez jamais ce genre de ressource extérieure à votre site ! Copiez la lib chez vous, elle est GPL !

Le code est du pur javascript, parfum vanilla. Vous n'aurez donc besoin d'aucune autre bibliothèque ~~ou framework~~ tel que jQuery. À une unique exception, à savoir si vous voulez vérifier les tests, le développement a été commencé en TDD. J'ai craqué car il fallait des promesses à QUnit. Oui, je suis faible.

J'ai aussi tenté d'avoir une syntaxe d'URL la plus propre possible, qu'elle n'interfère pas avec les standards et que les ancres soient relativement transparentes. J'ai fait l'impasse sur un fallback, donc en cas de plantage javascript, il ne se passera rien.

Autre chose sur le développement : j'étais aussi en déploiement continu sur mon propre blog. Donc vous ne l'aviez pas vu passé, mais il y tourne depuis le podcast du THSF 2014.

Il y a un standard

Mon script utilise strictement les API de base. Non seulement les éléments natifs sont gérés, mais tout polyfill, script, add-ons ou plugins (ben oui) qui peuvent les prendre en charge sont du coup aussi compatibles.

Il y a peut-être une petite vérification à faire, car oui, il existe encore des vieux tromblons à travers notre vaste mode, que votre serveur web supporte bien les requêtes HTTP Content-range et réponde bien par le status code 206 Partial content. Le chargement par morceaux de ressources n'est d'ailleurs pas toujours supportés par certains reverse-proxy.

Grâce à Thomas Parisot, qui fait moult tours de magie javascript à la BBC, j'ai redécouvert le standard media fragment. Oui, je l'avais lue à une époque et je l'avais stupidement oubliée.
Il permet d'adresser et de n'utiliser qu'une partie d'une ressource média, du type image, audio ou vidéo. Mais il manquait la gestion du lien vers la page où cette ressource est embarquée. C'est pour ça que j'ai construit ce petit bout de code.

Dans les faits, à son implémentation, j'ai parfois une invalidation de cache. Je tente donc d'abord de forcer le lecteur à se positionner au timecode demandé et en cas d'échec, je tente avec la syntaxe que j'utilisais jusqu'ici, à savoir en changeant la propriété element.currentTime.

Comme ces manipulations risquent de lever une erreur, j'ai utilisé non sans honte un try { … } catch(e) { … }. Oui, je sais que cette structure est l'œuvre de Satan, qu'elle n'est pas Bien™ du tout et que ce démon tue les performances, mais je vous fais remarquer qu'on risque pas la dizaine d'appels par seconde pour cette fonction, donc le besoin avoir des perfs de F1 n'est pas ici un facteur de décision.

Autoplay, la sale manie

Rien n'est plus insupportable que les sons/vidéos qui se lancent toutes seules, sans demander d'autorisation. Pourtant ... si vous venez d'une autre page, j'ai considéré que mettre le sonore à une position précise équivalait à une lecture automatique.

Je me demande si c'est raisonnable…

Enfin, là, ça ne marche pas à cause d'un souci d'événement. Assez pénible.

La syntaxe

Elle est très simple : l'URL de la page, suivi du hash de l'élément multimédia (au aucun pour le premier), d'un séparateur (par défaut &t=) et le timecode, exprimé en secondes (123), deux-points séparateur (00:02:03) ou unités (2m3s)

Ce qui donne ceci :

<a href="http://dascritch.net/post/2014/05/31/Suppl%C3%A9ment-Week-End%2C-samedi-31-Mai-2014#&t=2m3s">…

Remerciements et TODO list

En plus de Thomas Parisot et des débuggueurs Loïc Gerbaud et Benoît Salles, il me faut aussi remercier l'équipe éditrice de Touchalize, à savoir Phonitive et son créateur Guillaume Lemoine, pour m'avoir prêté de l'équipement afin de faire différents tests. Ce qui m'a permis de vérifier qu'effectivement Safari est vraiment ~~bugué à la moelle~~ capricieux au possible.

Tout n'est pas terminé : il manque encore le support des éléments AV non indexés (je rappelle que c'est pas franchement l'idéal), et des chapitrages déjà existants.

Cadeau !

Petit bonus propre à Firefox : le menu contextuel sur l'élément (clic droit ou appui prolongé sur l'élément média) permet de récupérer le lien vers la position en cours de lecture. Mais comme on n'a plus le droit de modifier le presse-papier comme on veut pour d'évidentes raisons de sécurité, vous aurez alors l'interface roots d'un bon vieux alert() des familles.

Travaux d'été

Da Scritch — 2014-07-08T14:23:00+02:00

Profitons de ce temps superbement maussade pour refaire son site “pro”, et vous inonder à la rentrée avec plein de nouveaux articles techniques. Ça m'oblige à m'ouvrir, à apprendre de nouvelles langues et si visse pas sème, part à Belloume comme disais je ne sais plus qui…
Webdev

C'est comme ça.
Ça vous démange pendant un bail, mais vous êtes intimidés ou peu motivé. Et d'un coup, vous avez envie de refaire ce câblage électrique qui a eu chaud, de couper ce lierre en petites bûchettes, de refaire cette tuyauterie qui donnait des signes de faiblesses et de ressouder ces prises bourrées de faux-contacts à force de manips.

Moi, repeignant mon plafond et m'accrochant au pinceau. Selfie de 2006.

Ben c'est un peu ce qui m'arrive cet été.

Je refais mon site corporate

Le design actuel de dascritch.com date de 2011. Oui, il était déjà en responsive web design, mais de nouveaux éléments méritaient d'y être intégrés, notamment mes conférences et plus de textes explicatifs.
Et aussi d'être un poil plus habillé, même si les css ne sont toujours pas mon fort.

La différence, c'est que j'ai voulu le faire sur un serveur statique. L'actuel (backup de la page web) fonctionne sur dAgence, et utilise son moteur de pages, de sous-images et de news grâce à l'extension de feeds. Le code front est quasi-intégralement statique. Difficile de faire un code plus lisible à intégrer :

<section id="rea"> <h3>Quelques réalisations récentes :</h3> <T:Pages limit="5"> <article> <a href="https://dascritch.net/post/2014/07/08/{{T:PageText name="lien"}}"><img src="https://dascritch.net/post/2014/07/08/{{T:PageImage format="realisat"}}" alt="{{T:PageTitle}}"></a> <div> <h4>{{T:PageTitle}}</h4> {{T:PageText}} </div> </article> </T:Pages> </section>

Seulement, dAgence est en fin de vie, son code n'a pas bougé depuis 2 ans. Avec Nicolas Guilhou, j'y ai mis beaucoup de cœur, de travail et j'aurais beaucoup à écrire sur ce qu'on y a fait, mais je n'ai ni l'envie de le continuer, ni de l'ouvrir. Ce dernier point à cause d'un client qui m'a dégoûte et aussi la qualité de mon propre code en 2007.

J'ai alors pris une décision bizarre : Je me suis rendu compte que pratiquement personne n'a vu de code de ma part. Je suis très timide et j'ai pas eu l'occasion de travailler sur des projets open-sourcés. J'ai donc décidé d'utiliser mon github pour cette refactorisation. Accessoirement, cela facilite mon boulot quand je suis entre plusieurs machines.

Mais pourquoi faire simple ?

J'ai donc inversé le concept : le backend est statique, le frontend puisera ses données.

J'ai tenté une version AngularJS + Bootstrap volontairement pas codex, je l'avoue ;), une autre en ReactsJS + Foundation + Sass stupidement bloquée pour les raisons ci-dessous. Finalement, je suis reparti sur mon squelette, j'ai intégré le TinyTypo de la fabuleuse Romy “Tétue” Duhem-Verdière. J'en viens à la même conclusion que Paul Rouget et Maxime Thirouin : des fois, on va nettement plus vite sans s'encombrer de frameworks-couteau-suisse.

Et maintenant, ça marche comme je le voulais en MSIE9. Oui oui. Merci IE Net Renderer

Bon, par contre, le design RWD liquide avec 5 breakpoints de largeurs différents, je doute que ça soit une solution viable à terme ^^;

Je voulais faire des requêtes cross-sites, mais les mesures de sécurité prophylactiques (CSP + CORS) que je loue tant me posent des soucis en développement local ou en hébergement github.io. J'en ai donc profité pour écrire un parser pour récupérer mes derniers articles. Et plutôt que le faire en Javascript, en PHP ou même avec des regex via le shell, j'ai tenté de le faire en python pour sortir de ma zone de confort. Oui, le code est crade, mais il coupe la moutarde.

Normalement, je devrais déployer cette nouvelle version avant la fin du mois. Vous pouvez toujours commenter en bas ou ouvrir un ticket bug/suggestion sur github

Le truc rageant, c'est que quand tu termines ton site, tu tombes sur jsonresume.
Ah ben flute.

Le faux calme

Vous verrez moins d'articles techniques publiés cet été. Des articles comme les bug reports, la licence JSON, la balise <img />, les floating labels, les boutons de partage sociaux et d'autres peuvent demander de la recherche. J'ai décidé de prendre le temps là-dessus pour gaver vos listes d'articles à lire en urgence.

J'en profite aussi pour essayer différents projets qui justement vont me servir à écrire ces articles. Certains projets sont déjà consultables sur github pendant leur construction :

Une bibliothèque javascript pour faire des ancres timecode dans les pages web incluant sonore ou vidéo, par exemple un podcast
Un jeu de programmation robotique sur une idée et avec Fabien Tregan,
Un addon Firefox pour les auteurs utilisant dotclear
Bricoler un peu pour me forcer à apprendre Dart, Python (c'est déjà parti), Ruby, Rust et Go
Écrire des composants web-components avec la fantabuleuse bibliothèque Bosonic de Maître Raphaël Rougeron & associates
Ré-implémenter en js, php, ruby et python avec tests uniformes le système de numéro de commande de dagence
Améliorer encore le thème de mon blog
Parler des implémentations des systèmes de login sur les sites webs, et du faux conflit UX/Sécurité
Reprendre après son long hiatus ma Psychanalyse du Clavier
Disséquer la navigation documentaire
Comparer BBCode-like et Wysiwyg HTML (je sais qu'il est très attendu, ce dossier)
IPv6 sans pleurer

Ça va m'occuper.

À l'heure Californienne : Google I/O 14

Da Scritch — 2014-06-26T09:43:00+02:00

Hier, c'était la conférence Google IO, à destination des développeurs. Petit compte rendu du stream de San Francisco pris à Toulouse avec le TAUG en Extended™.
Gizmo

That's how we sell gizmos in California, USA

Nous nous étions préparés, solidement documentés, chauds comme la braise ce soir-là chez Epitech.
L'événement Google I/O à destination de sa communauté de développeurs s'ouvrait sur une gigantesque machine infernale. L'horloge à boules donnait le décompte avant d'envoyer dans le décor une grosse de bowling.

Note : 18 minutes de mire, et pas de son avant 3 minutes après le début. On a eu pareil.

Mais en soit, rien de franchement phénoménal ne devait y être annoncé pour le Grand Public : On était là pour parler surtout technique et gizmos qui vont avec. Si vous ne comprenez rien de rien à HTML5, que vous n'êtes pas prêts à apprendre à coder une appli Android (avec Androsium), vous risquez d'être perdus à la lecture de ce compte-rendu.

Moi, je m'en fous, j'étais là pour ~~troll~~ twitter, goûter aux pizzas et démontrer KDE Connect :

RT @sim_previdente: Petite démo de KDE Connect avec @dascritch et @_PolyAd ! #magique #io14 pic.twitter.com/FxuPPt1Ws2 #ioextended_tlse
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

D'abord un nouveau style d'interface pour la prochaine version d'Android. Désormais, les boutons du bas seront ◁ □ ◯.
Oui, moi aussi, ça m'a choqué : il manque × pour que Sony soit heureux de leur faire un procès.

Google continue dans son optique connectée avec sa gamme Google Wear. Après les Google Glass, les Google Watch, et notamment une montre avec un écran rond, preuve des avancées de Sharp dans la production de dalles non carrées.
Cela reste un gadget coûteux, très coûteux. Les applications proposées comme la biométrie n'en valent pas forcément le prix, et pouvoir consulter la recette de cuisine avec sa montre ne passera pas le test pratique quand vous aurez les doigts plein de farine. Et il faut toujours recharger toutes les 24 heures, n'en parlez pas à Jack Bauer.

Trouble-fêtes

Deux interruptions dans le public par des “anti google”, ou plutôt des personnes qui posent la question du rôle social de Google et de son slogan Don't do evil. n'ont pas apprécié l'acquisition de Boston Dynamics. Je dirais qu'ils ont raison : on parle du rachat d'une entreprise qui construit des dispositifs militaires, des engins de guerre. Faute d'une communication claire sur son avenir moral, Google fait peur.

#io14 #ioextended_tlse "Voice enabled" par défaut. ne dites plus « OK Google » mais « Hello NSA » Soyez poli, quoi , bordel ! merde !
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

La privatisation des API système continue

Et je me demande de plus en plus ce qu'il va rester dans l'Android Open Source Platform. Apple aussi avait ouvert l'iOS et MacOSX, mais maintenant, vous ne trouverez pratiquement plus grand chose concernant les versions modernes.

Pour me faire l'Avocat du Diable (but he doesn't do evil), je plaiderais que ce mouvement est logique. Il est dû aux péchés originaux de la plateforme Android : impossible de pouvoir facilement faire migrer la majorité l'écosystème à la dernière release de l'OS, contrairement à Apple. Les appareils sont souvent encombrés de surcouches constructeurs (Samsung en tête), opérateurs (hein Orange et SFR), et maintenant applicatives (Facebook).

Donc une partie des API importantes ne sont plus dans les parties open-source d'Android, mais dans des applications Google, le framework Google Play Services, actuellement déployé sur 93% des terminaux. Couplage fort en vue, moins d'expérimentations intéressantes ? Là où une app comme Focal fait bien mieux que la plupart des applications d'appareil photo par défaut, ben ce choix alternatif risque de disparaître. Résultat, si vous installez une ROM alternative comme CyanogenMod pour libérer votre gizmo, il est plus que probable que vous installerez rapidement Google Play et les applications Google de base.

Fail.

La conquête du prochain milliard de devices

Un milliard d'appareils tournant sous Android actuellement en fonction (je ne compte pas les tablettes no-name qui calent vos commodes).

Le prochain milliard, tout le secteur le sait, il sera dans les pays en voie de développement.
Google l'a donc clairement annoncé hier qu'il y lancera un smartphone à 100 $. Par là-même, il tente donc de chasser sur les terres promises à Firefox OS et Tizen. Non, sans rire, Microsoft ne peut proposer de Windows Phone décent dans ce prix-là, et l'activité feature phone de Nokia va donc péricliter.

Des pays où les téléphones à double carte SIM y sont très populaires. Forcément, Google va donc proposer le double compte Google sur les appareils, ce qui amène enfin la possibilité de différencier sa vie privée de son activité professionnelle. Effet de bord très bienvenu.

Le retour de la Google TV

4^ème lancement.
Va-t-il enfin voler ?
A-t-il une chance de commencer sérieusement en France ?
Ce segment de la conférence avance, un panneau annonce une vingtaine de partenaires industriels, et dans le lot on notera 2 FAI Français !
Bouygues Télécom et SFR trouveront là le moyen de sortir rapidement une box triple-play puissante, puisque les actuelles avaient été ridiculisées par la Freebox Revolution, et ceci malgré un investissement conséquent. BouygTel encombré d'une interface flash très vieillissante, SFR d'un manque d'applications tierces. C'est encore plus drôle quand on sait que la Freebox Revolution était annoncée officiellement quelques mois après les premières Google TV, et, selon certaines rumeurs parisiennes, devaient même embarquer la Google TV.

Oui, mais la première Google TV était très mal conçue : Basé sur le navigateur Chrome en plein écran, il accusait déjà deux ans de retard par rapport au navigateur qu'on pouvait installer sur son PC. Y développer une belle interface était si pénible qu'on arrivait à un résultat bien plus probant en Flash.

SFR/Numéricable et Bouygues Tel se préparent une très belle nique à Free (ils n'attendaient que ça), faisant valoir de plus leur meilleure connectivité vers les services de Google.
Et Google lui-même va enfin pouvoir s'installer ans le pays qui a inventé le triple-play ADSL et où ni Google TV, ni AppleTV n'ont jamais pu s'implanter, s'assurant un parc d'abonnés plus que conséquent.

#io14 #ioextended_tlse Mantenant, vous pourrez dire « OK Google, skip this ad » si pratique sur la TNT
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

Coding in the cloud

La démonstration de l'offre d'hébergement de services par Google avait du mal à démarrer, effet Bolnadi oblige, mais elle valait l'attente.

Écrire du code dans n'importe quel langage à partir de son navigateur ? Oui on peut, on a des IDE complètes, souvent basées sur l'excellent éditeur Ace de Cloud9 , comme par exemple chez GitHub.

Éditer, compiler, déployer ? plus rarement.

Éditer, compiler, texter, déployer mais aussi faire du débug dans une console, toujours dans votre navigateur web, en posant des breakpoint ? Et ben là, ils ont fait hier la démonstration et nous étions bluffés.

Mais pas pour tout le monde car à Toulouse, la tireuse à biaires venait d'ouvrir. Ou le foot ?

Bière vs breackpoint et cloud programming #ioExtended_tlse pic.twitter.com/UD94uuRpVN
— Maxime Warnier (@maxdow) June 25, 2014

@maxdow @dascritch Certains ont essayé de résister mais pas longtemps hein 😀 pic.twitter.com/NrMdTU79PK
— Simon Prévidente (@sim_previdente) June 25, 2014

#ioextended_tlse this one is for @nitot and @mozilla_fr @MozillaZineFr pic.twitter.com/Rl6qDAb4yN
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

Le HTML5 en force

Et à un point qui est surprenant : Android suit la voie inverse d'iOS. Au sens qu'au lancement d'iOS, aucune application n'était installable donc tout devait être fait en HTML5. Android lui, était prévu pour installer des applications d'entrée, mais en concevoir les vues, l'aspect de l'interface, tourne au cauchemar car il faut prévoir un code spécifique pour pratiquement chaque dimension d'écran existante. Mais, par les joies du Responsive Web Design, en intégrant une page html directement dans votre application, ce que l'on appelle une WebView.
Dans les annonces d'hier, Android pousse de plus en plus vers HTML5 et pas que dans WebView.

Énormément d'API montent dans le navigateur web, mais aussi l'arrivée en force des web-components. En résumé : Polymer va ainsi proposer les éléments d'interface du système Android transposés en HTML5 et en web-components. Ce sujet mérite un article complet, donc je le traiterai de manière approfondie la semaine prochaine.

Depuis 6 ans, des gens très futés tentaient de faire des interface à la iPhone en HTML. La raison est que l'interface utilisateur a été énormément travaillée par des graphistes et des ergonomes et qu'elle possède sa propre logique. Mais jamais Apple n'avait proposé d'implémentation officielle de ses guidelines UI, et bien souvent, ces implémentations sont complètement foireuses, je pense notamment aux extensions “mobile” Wordpress pénibles et peu lisibles au final.

Google va donc proposer son interface Android en web-components standards, et en plus via Polymer, donc non limité à Chrome, mais compatible Firefox, Opera, Safari et même MSIE9.
C'est très important car cela sonne enfin le glas des frameworks css monolithiques à la Foundation et surtout (kooff koooffff) Bootstrap. Nous allons donc très sérieusement y gagner en professionnalisme et en qualité d'interface pour nos applications web. Et Google offre aussi par là-même un moyen efficace de faire tester son univers mobile à tous les utilisateurs du web. C'est aussi une ouverture publique d'une partie du code-source.

new polymer demos are cool http://t.co/Zid5ko0ion http://t.co/9B2qUl3Ifx http://t.co/IWIVdyMlNv except for keyboard or assistive tech users
— Steve Faulkner (@stevefaulkner) June 25, 2014

Petit bémol pointé par Steve Faulkner dans son twit : il y a encore des efforts à faire en terme d'accessibilité, ce qui est plutôt primordial dans le web.

Et sur place

Outre la retransmission de foot qui n'a intéressé qu'une demi-douzaine de masos, les boissons, pizzas, charcuteries et fromages fins, une douzaine de startups ont pu présenter leurs activités comme Unitag, Androsium (de circonstance) et le très prometteur Jukast.

On a eu droit à de belles démos technologiques, mais c'est une fois de plus le bac-à-sable interactif de Science Animation qui a attiré ces grands enfant de devs hardcores. Internet des Objets, mais bien sûr ;)

La blague de la soirée

Les participants de la soirée IO Extended à Epitech Toulouse pouvaient gagner des goodies sur un concours de bits. Euh pardon de retweets.

J'ai stratégiquement axé mon sujet sur le chiffre des 93 millions de selfies par jour dans le monde fait avec un gizmo android.

One more selfie bite the dust #ioextended_tlse pic.twitter.com/xp7rqZuuWl
— Xavier Mouton-Dubosc (@dascritch) June 25, 2014

Que j'ai gagné… d'une courte tête face à Lisbé, sur une immonde faute d'anglais. J'étais mortifié quand je m'en suis rendu compte 30mn trop tard.

@dascritch #ioextended_tlse JulienKT David et Xavier sur la même photo. Stylé les gars.
— Julien Del Rio (@JulienDelRio) June 25, 2014

“@dascritch # #ioextended_tlse roooonnroooooon >^.^< pic.twitter.com/FJ6NA0YCsV” thanks to @BeMyAppFR and @intel france
— Julien Del Rio (@JulienDelRio) June 25, 2014

Et pas ~~peu~~ fier en brandissant mon Galaxy Tab 3 tout bô qui d'ailleurs, n'est pas vraiment le mien, c'est un outil de développement HTML5 fourni par Intel. Avantage : j'ai un numéro de helpdesk aux US. Hello IT ?
N'empêche… une prise électrique américaine ^^, mes toilettes Toto vont se sentir moins seules sur mon transfo 110V/60Hz de salle de bain.

Milles mercis à tous !

Merci à tous !! #io14 #ioExtended_tlse @EPITECHToulouse pic.twitter.com/Dha11Zx6cG
— ToulouseAndroidUG (@ToulouseAUG) June 25, 2014

À Intel et BeMyApp France pour le superbe cadeau, au Toulouse Android UG, as usual à l'Epitech Toulouse pour leur accueil et surtout à Julien Del Rio qui était dans la salle de conférence à San Francisco et qui visiblement n'arrêtait pas de pouffer de mes blagues twittées sous les regards intrigués de ses voisins américains.

Sniffeur d'ancre

Da Scritch — 2014-06-24T15:40:00+02:00

Un petit utilitaire qui va plaire à plein de rédacteurs techniques. Dispo en javascript vanilla, ou sinon en add-on pour Firefox*.
Webdev

J'aime bien écrire des articles techniques. Sur les images, les emoji, le clavier et autres analyses peu pertinentes…

Mes textes peuvent parfois devenir immensément longs. Parce que du coup, en me documentant, j'apprends, j'ai envie de mettre encore plus de choses, je rajoute des illustrations, et puis encore des choses… Et là, j'explose, je dois atomiser mon brouillon d'article en plusieurs éléments d'un dossier.

J'aime bien aussi mettre plein de liens. Oui, je sais, vous ne les cliquez pratiquement jamais mes foutus liens que j'essaie à chaque fois de choisir de façon pertinente.

J'essaie de trouver des liens vers des articles de référence. Malheureusement, souvent ces articles sont longs, parfois beaucoup plus longs que les miens. Par exemple, certains documents dépassent les 100 000 caractères, à se demander si on a vraiment un document de specs ou juste un burning performance test…

Voilà pourquoi on met des ancres

Vous remarquerez qu'en règle général, chaque chapitre de mon blog a une ID, un index, une ancre. En général sur le titre, comme suit :

<h3 id="voilapourquoi">Voilà pourquoi…

Le problème, c'est que souvent, on a pas de mini-sommaire de la page, donc il faut le trouver soit en lisant le code source du html (suuper), soit en inspectant la page (suuuper).
C'est si compliqué que ça de mettre un mini-sommaire ?!??

Donc, des fois, comme ça me les brise, ben j'ai écrit un petit snippet de code javascript. Ce petit bout de code fonctionne sur n'importe quel navigateur, pour peu qu'on le lance en mode console dans l'interface de développement. En général, t'appuies sur la touche F12 et tu colles mon code…

T'as vu ? Je l'ai fait dans Chrome parce que mon code fonctionne sans problème quelque soit le navigateur, pour peu qu'il soit récent et décent. Donc ça exclu… Non, pas Internet Explorer, mais Safari…. pfff… bande de trolleurs.
Sur Firefox, tu peux le faire dans l'ardoise magique (⇧Shift+F4) et hop, tu exécutes.

Et ça donne ça :

Chaque ancre de la page est révélée, et donc je vois immédiatement les liens directs aux chapitres d'une page. Bonnard.

Quitte à le faire pour Firefox…

Et surtout comme j'ai mis le code sur GitHub, je me suis tenté la création d'un add-on pour Firefox. J'avais fait en 2000 des sidebars pour Mozilla, j'avais tenté des addons au moment où Firefox les proposaient, fallait que je me dérouille.
Donc, j'ai vite choppé l'add-on SDK entre mes coups de fils, implanté après avoir lu en diagonale, rédigé un rapport de bogue sur la VF que je ne voulais pas, charogné une icône Oxygen de KDE, et roule ma poule !

Ben c'est fait : https://addons.mozilla.org/fr/firefox/addon/anchors-reveal/ *.

Yes ! Restartless, je ne me refuse rien…
Cela rajoute un bouton on/off dans la barre d'adresse, comme ça :

Et c'est tout.

Mais vous pouvez pas savoir comme cela va me faciliter la rédaction. Rogntudju.

À venir

D'abord, quelques correction de bugs, ensuite je passerais à un add-on adaptant le fabulous Zoodvinsen du mythique Wmcoincoin pour toutes les tribunes trollesque genre LinkedIn, Google+ ou Twitter afin d'améliorer votre productivité. Et ensuite faire un Dotclear companion, puisqu'on me demande souvent mes snipets d'édition.

Et n'oubliez jamais : avoir des add-ons c'est sympa, mais en abuser ça craint. Désintallez ce que vous n'utilisez plus.

* NOTA BENE : J'ai été un peu trop rapide, il faut compter 10 jours avant que l'add-on soit validée dans le “store proprio” de Mozilla.
Vous avez le droit de ne pas me faire confiance du tout.

Proposals about ‹img /›

Da Scritch — 2014-06-18T09:51:00+02:00

This is the translated final part of a series about the ‹img /› tag. I'm focusing on the srcset="https://dascritch.net/post/2014/06/18/" attribute, created to resolve the problem to load a source accordingly to the device pixel density. I believe in a better solution. So let's try to make a proposal to the W3C…
Webdev

This article is the engrish translation of the last of a 7 parts series. Sorry my bad French, yell any corrections by commenting, thanks.

In the previous post, i've explained why bothering the display of an image according to the logical/physical pixel ratio of the support (a problem dating since you were able to print a page in Netscape 1) and showed some hacks to do so. Let's see the W3C proposal, why it bother me… and let's try to build a better thing.

Within W3C communities, the Responsive Image working group is trying to build an elegant and standard solution to that very one problem. After lot of conversations came the <img srcset="" /> attribute. Its function is to change on the fly the source named in src="" according to different display rules, including the pixel density. It was the only concern of the first proposal.

srcset="https://dascritch.net/post/2014/06/18/" according to its documentation

Warning : This attribute is still in its infancy, neither its syntax or implementation are fixed, its most up-to-date version is actually published at the Responsive Image Community Group. Today, you must use it with the same precautions as an experiment and as if it was prefixed in javascript or css, as this kind of experimentation syntax is, alas, still missing in html.

The content of this attribute is a list, comma-separated. Each entry of the list is an url source, then a space and application rules like the available width (640w) or the pixel density of the display resolution (4x).

So, i quote here the W3C reference draft, you can get a rule by the containing width :
<img src="pear-desktop.jpeg" srcset="pear-mobile.jpeg 720w, pear-tablet.jpeg 1280w" />
or the logical/physical pixel ratio :
<img src="pear-desktop.jpeg" srcset="pear-mobile.jpeg 2x, pear-tablet.jpeg 4x" />
or both :
<img src="pear-desktop.jpeg" srcset="pear-mobile.jpeg 720w, pear-tablet.jpeg 1280w, pear-desktop.jpeg 1x" />

Yes, we have repetitions and mixed pixel density and responsive webdesign issues. In a so so confusion, you can't be sure what was done, even a mother cat will lost her kitties.

<img src="/vrac/.blog2/webdev/1403-Img/.1406-Img-KittyPrinter_s.jpg" srcset="/vrac/.blog2/webdev/1403-Img/.1406-Img-KittyPrinter_m.jpg 2x , /vrac/.blog2/webdev/1403-Img/1406-Img-KittyPrinter.jpg 4x" alt="" />

« Our kitty printer is running out of toner »
Sure.

A bright idea that might goes dark

This attribute is already living in some browsers. Well, in fact, mainly Chrome when they were still using webkit. Firefox just installed it in Nightly the last week, so we'll probably got it in Firefox 32 in 3 monthes. Apple made an iOS8 promise and the Microsoft IETeam is still considering it.

Screenshot, part of the Addy Osmani's tweet announcing it in Firefox Nightly

Sincerely, when I read that srcset="" is the very best way to manage HiDPI issues, I can't believe it. Geoffroy Crofte from Alsacréations is also concluding that the syntax is not so good. And the question is still bothering for two years.

And reading it again, I fear the very same problem that we already inherited in favicons declarations. The one that give you very bad <head></>-eaches :

15 icon subformats, and so many different declarations for the very same one resource !
Source : Tweet from @Judofyr

IMHO, this html attribute will be more a problem than resolving one. First of all, it is more about presentation than document semantics itself so pal, why did thou let thy piggy in thy html's dinnin' room ?. Add it the <picture>/</> tag to the recipe, you will get a worrying level of verbosity, but you can avoid it before.

When you know html “conventions” code from Google, so abbreviated that you've got implicit html everywhere, I'm really surprised that Chrome accepts so many repetitions, autant de redites, redudant informations. Decide or take again a little time for…

Thinking about the current uses of images

Oh please, don't believe I'll chat about sociologically or whatever, I'm talking about assets distribution in a website, as it's done in the state of the Art. In the pictures, we have the ones describing something, and the ones that are insignificant decoration…

Variations about « The Treachery of Images » by Magritte.
Source : the very good writing about this painting in Du bleu dans mes nuages (french speaking) blog

We have ~~four~~ three main image sources :

the ones called by css, strictly decoration and not intented to be changed by the website users ;
the ones in <img /> but called via templates or created by DOM manipulations ;
~~the emoji ones, sinked in the text by any hypster who believe living in 原宿 ;~~
the ones in <img />, being sent by users via a CMS (or the front of a social service, or small ads sites) and that are processed in backend (anti-XSS, resizing, watermarking, optimization…).

In the first case, background-image populated, we don't bother about it : CSS media-queries can work in relation with the physical pixel density using resolution, or directly using the .svg furbished by the artist designer.

In the last case lies the srcset="" attribute where it's becoming a complicated nightmare : How to deal with the existing ? How updating all the holdings if newer resolutions must be supported by the website ?
We are obviously more often working with CMS (or so), as the one motoring my blog by example. Creating on the fly lots of sub-formats from any picture accordingly to some programmed parameters is a classical job for any CMS. If you were using direct html edition, you can't easily put this attribute without an important rewrite of all the back-catalog pages. I already see how long it will be for my blog, having 2000 posts in 10 years, and I don't have high-def source for all the illustrations. So think about it for a e-commerce business having dozen of thousands references or any daily newspaper that publish hundred of stories every single day.
(Insert here a joke about your regional newspaper, the one having in front page a “email jokes” category.)

Just take this very single post, hand-made html crafted, and think that every picture I made reference should have multiple definitions, while any sub-formats was automated/normalized by its CMS.

NO F☵⚧⚼☭G NO srcset="" is NOT at all « …a good thing » by that way.

What should the specifications have been

So typical : Life cycle of specifications

Here are what would be the basic rules in my humble opinion :

No repetitions, the source URL should not be demultiplicated in the html code, moreover when those URLs are automatically generated. The less verbosity, the more users will use it
The number of DOM constructed elements should be the lesser
In being simple, html code should encourage good practices
Dimensions should be implied, as the browser will know them in decoding the image file, and css may change them presentation constraints. Forcing sizes may lead to unsolvable issues
All that is about resolution and pixel finesse should be managed by the browser alone. As it is not about semantics but about presentation, any mention of it must be in the CSS
For being futureproof, adding new sub-formats lied to the resolution must be solved in no more 5 lines, even if you have thousands of pictures.
The solution must be protocol independent, never asking back-end recoding or parameterizing. Yes, it must work on any dynamic server but also any static one or locally hosted.
It should be feasible by any lambda webmaster
And, last bu not the least, it must be easy to implement for browsers' coders, elsewhere don't think about it

If you compare with each trick explained in French in the previous post, you'll see that srcset="" is not so well placed...

So why not using CSS ?

Source : Vancoosh, starring Frida

If i moved my ass sooner, chatted in the W3C WG and put my 2 cents, I would have done this proposal : we must be able to change URL source on the fly via a regular expression, as the greatest majority of subformat pictures are automated even in their naming.

OK, but you'll have to implement lot of brand new parts :

Proposal : srcset in css

All of my socks at the same place.
Source : AngryJulieMonday

The best way is having a resource rule by the pixel density of the screen. So as we have srcset="" implemented in html, why not do it in css ?

srcset : "img-4x.jpg" 4x;

And we can chain other scenarii :

srcset : "img-2x.jpg" 2x , "img-4x.jpg" 4x;

This property would dictate both the substitution and the scale to apply to your image. We would have a generic declaration, more easy to change as you edit css rules, example : when you have to change a responsive design theme. So the width-available notation would be past and forgotten.

As I mean it, if the resource is missing, the property must be ignored.
In CSS, it will be also useful for other tags as <video></> or <iframe></>

Proposal : Using regex into css

Source : Halibustuff.com

I mean, creating a brand new css operator, namely a regex and its replacement pattern. Nearly every browser have a javascript engine, so a standardized regex library. I think this is the biggest piece of work to do, to debate and to code, as we will have to adapt css parsers to accept a brand new unknown syntax for them.

Example : regex(attr(src) , "^/images(.*)/([^/]+)$" , "/images\1/.\2,x2").
First parameter is the string to operate, here the content of the src="" attribute in the html code, the second one is the regex formula, and the third one is the replacement formula. In this example, /images/examples/test.jpg would be substituted by /images/examples/.test.jpg,x2

So, as any integrator, you will just have to describe once the naming strategy of the subformat pictures, if the variation is in the repertory (“/x1/img.jpg”), by internal suffix (“img_x1.jpg”) or final (“img.jpg,x1”).

The relief code would be enormous on most of the websites compared to the srcset=""-in-each-tag strategy.

Proposal : async="no"

CC0 author : Hans. Source : Pixabay.

If we want to avoid the browser to load the <img src="" /> default resources, then the “good” ones afterwards, we need to flag for the browser that an asset (css or javascript) should not be parsed asynchronously. So having async="no".

Yep. I know.

From my sunny hometown in the South of France, I can hear you shouting that my proposal is a completely stupid and inefficient one, I can see you wanting to thrown rotten fruits to my face, and dialing the Spaninsh Inquisition for a surprise inquiry.
You're almost right : This property would help avoiding that the browser load a file that might be invalidated by a stylesheet later. But it goes completely backwards what everyone have done in performance. Yes, there is a abuse risk, but web integrators will learn by failing. And if I don't have a completely messy proposal, I risked to be eared seriously by you.

Currently, the most used solution for that is direct inclusion of js/css in the html source. I can't tell for you, but it hurts my eyes every time I see that.

In fine

Jumping water frog by agnatha3141

Yes i know this is very pretentious to have so many proposals, as a part of them are completely rotten ones. So I have to present each one independently, eventually having them accepted by W3C and WHAT-WG, seeing perhaps implementations in browsers... and fight against their misuses.

Bref. There is work to do, but I believe these proposals would help a lot to get the html syntax less verbose, to ease a lot resource maintenance and to extend easely for the very very high density screen yet to be marketed. I can't believe someone will soon selling me a 3200 dpi screen device…

Just imagine :


article img {

    srcset : regex(attr(src) , "^/images/articles/(.*)/([^/]+)$" , "/images/articles/\1/.\2,x2") x2,

           regex(attr(src) , "^/images/articles/(.*)/([^/]+)$" , "/images/articles/\1/.\2,x4") x4;

}
 
.decor img {

    srcset : regex(attr(src) , "^/images/layout/(.*)/([^/]+)$" , "/images/layout/\1/.\2,x2") x2,

           regex(attr(src) , "^/images/layout/(.*)/([^/]+)$" , "/images/layout/\1/.\2,x4") x4;

}

Hard to be simplier…

And thank you for all the fish

Writing the whole <img /> tag series was very long, and I cannot claim to be exhaustive or perfect. I have to thank every one that re-read me, advised, or corrected in the comments. Writing on a subject is an occasion to question yourself, to document and having again fun to learn and writing not only crappy puns.

I have to thank a thousand times the srcset="" syntax that gave me inspiration to write on it.

Hope you so ;)

da scritch net works - Mot-clé - javascript

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

Les joies de la communauté open-source

Arrive la ré-écriture de Firefox

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

Oh ! Une dernière chose !

Firefox, l'invisible

Parlons de la publicité sur le web

Et c'est ainsi que naquirent les filtreurs de pubs

Apple a sa culture insulaire et a oublié le web

L'écosystème global de Google

The mission

Bref, j'abandonne l'audience-turfing

Comment vérifier cette intuition

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