da scritch net works - Mot-clé - dom

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.

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...

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.

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.

CPU Ex0045 Bonjour à toi, Enfant du Futur immédiat : Sans les yeux

Da Scritch — 2016-12-09T06:45:00+01:00

Une émission qui a été très éprouvante à cause du chat dans la gorge. Et n'ayant pu enregistrer un reportage sur un utilisateur de synthèse vocale, j'ai téléchargé Pico, le moteur de la synthèse vocale d'Android, pour lire mon texte à ma place. Le programme a été intégralement pigé par Stéphane Deschamps sur la page de l'émission, milles mercis à lui.
Radio

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

Bonjour à toi, enfant du futur immédiat, toi qui n'a peut-être pas eu la chance de découvrir la clarté quand tu as ouvert tes yeux sur le monde.

De nos sens, celui qui semble le plus essentiel à la majorité des humains, est la vue. La vision permet de percevoir notre environnement lointain, même au-delà de notre atmosphère. C'est notre sens le plus exact, au sens qu'un événement distant observé est précisément orienté et à peu près placé dans l'espace.
Perdre ou manquer l'usage de ses yeux pose un sacré handicap pour percevoir le monde, plus que la perte de la sensation du goût sucré ou de l'ironie.

Alors oui, récemment, nous avons fait une émission sur les couleurs. Aujourd'hui, pas de couleurs, ni de noir et blanc. Rien. Zilch. Nada. Pendant une heure , tu n'auras que du son, de la radio pure.

L'ingéniosité de notre cerveau l'amène à développer les autres sens pour compenser l'absence de la vue. Les aveugles peuvent être des super-héros. Non, je ne pense pas forcément à Daredevil, rien n'est moins sexy que ~~Matt Damon~~ Ben Affleck obligé de cachetonner sur grand écran dans un nanar histoire de payer ses impôts... Bon, allez, je reconnais que la série actuelle m'a tapé dans l'œil, mais revenons à nos non-voyants.

Le pouvoir le plus intéressant que développent par la force des choses les personnes malvoyantes est dans la concentration : les technologies assistives qu'on leur a créé sont imparfaites pour donner une vision globale d'un écran, ils avancent donc à tâtons (désolé) pour découvrir chaque élément affiché. Leur compréhension de l'ensemble passe par leur capacité à construire une image mentale de l'environnement.

Comme la moitié du chemin était fait par les utilisateurs improprement dits déficients, les technologies pouvaient leur proposer des alternatives viables : l'écran à aiguilles Braille et la synthèse vocale.
Mais alors il n'y a pas de vision globale ou géométrique, il fallait que ces interfaces dictent une priorisation des contenus aux programmes qui étaient d'abord prévus pour une interface graphique.

Et croyez-moi que devoir repenser une interface graphique en terme de priorisation plutôt qu'en esthétique n'est pas simple. Pourtant, il y a un réel gain à faire ce travail : il permet de se poser et de songer à l'essentiel et à être clairement explicite, jusque dans les termes utilisés.

Enfant du futur immédiat, les concepteurs d'interface travaillent souvent dans le noir, jusqu'à ce qu'ils réfléchissent à ne pas voir le résultat, mais à songer à le rendre accessible. Car oui, le paradoxe est qu'il ne faut jamais perdre de vue que le handicap peut aussi être une chance pour tous. On ne voit bien qu'avec le cœur. L'essentiel est invisible pour les yeux…*

* « Le petit prince », Antoine de Saint-Exupéry

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.

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.

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 ;)

Propositions en ‹img /›

Da Scritch — 2014-06-17T10:57:00+02:00

Fin du dossier sur la balise ‹img /› avec l'attribut srcset="https://dascritch.net/post/2014/06/17/", sensé résoudre le problème de source en fonction de la finesse d'image. Oui, mais je pense qu'on pouvait faire bien mieux. Bien bien mieux. Cela mérite proposition au W3C…
Webdev

English speaking audience : a translation is available here.
Ce billet fait partie de la série en <img /> :

Histoires en <img />
Manuel en <img />
Ressources en <img />
Bricolages en <img />
Progressivement en <img />
Finesse en <img />
Proposition en <img /> / English version

Maintenant que j'ai bien expliqué les soucis de l'affichage d'une image en fonction de la finesse du support, et présenté différents hacks pour y arriver, voyons la proposition du W3C, là où elle me fait tiquer… et proposons quelque chose de constructif.

Au sein des communautés W3C, le groupe Responsive Image réfléchit à trouver une solution élégante au problème des finesses d'images. C'est comme ça qu'après de nombreuses négociations est arrivé l'attribut <img srcset="" />. La fonction de l'attribut consiste à remplacer à la volée la ressource indiquée en src="" en fonction de différentes règles d'affichage, dont la finesse de la résolution. L'idée originelle ne travaillait que cette question.

srcset="https://dascritch.net/post/2014/06/17/" selon sa doc

Attention : Cet attribut est en chantier, ni sa notation, ni son adoption ne sont définitives, et la version la plus récente est actuellement chez le Responsive Image Community Group. En fait, il doit être vu avec la même précaution qu'une expérimentation et avec les mêmes retenues que pour tout préfixe propriétaire javascript ou css, dont il n'existe malheureusement pas de notation expérimentale en html5.

La syntaxe de l'attribut repose sur une liste, séparée par des ,. Chaque élément de la liste est une url ressource, suivi par des règles en fonction de la largeur disponible (640w) ou de la finesse de la résolution d'affichage (4x)

Si je reprends le brouillon de référence du W3C, on peut donc avoir soit une discrimination en fonction de la largeur disponible :
<img src="pear-desktop.jpeg" srcset="pear-mobile.jpeg 720w, pear-tablet.jpeg 1280w" />
soit du pitch de l'écran :
<img src="pear-desktop.jpeg" srcset="pear-mobile.jpeg 2x, pear-tablet.jpeg 4x" />
soit des deux :
<img src="pear-desktop.jpeg" srcset="pear-mobile.jpeg 720w, pear-tablet.jpeg 1280w, pear-desktop.jpeg 1x" />

Vous l'avez compris, on a à la fois des redites, et mélangé les problématiques de finesse d'affichage et de responsive webdesign. Avouez que dans une telle cafouillade, on n'est vraiment sûr de rien, une chatte y perdrait ses petits.

<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 »
Tu m'étonnes.

Une idée qui risque de tourner à l'échec

L'attribut est déjà implémenté sur certains navigateurs, enfin surtout Chrome quand ils étaient encore avec le moteur webkit. Firefox vient de le mettre en place en Nightly la semaine dernière, donc arrivera probablement avec Firefox 32 dans 3 mois, Apple le promet pour iOS8. L'équipe IETeam de Microsoft considère d'implémenter l'attribut.

Capture d'une partie d'écran, extrait du tweet d'Addy Osmani annonçant la fonction dans Firefox Nightly

Franchement, dire que srcset="" est la meilleure alternative sur la gestion du HiDPI, j'ai vraiment du mal à le croire et Geoffroy Crofte d'Alsacréations trouve lui aussi la syntaxe contre-intuitive. La question titille de nombreuses personnes depuis deux ans.

À relire, j'ai peur que nous ne retombons dans les mêmes travers que les déclarations de favicons. Celle qui entraîne une inflation de la <head></> qui fait peur :

15 formats, autant de déclarations différentes pour exactement la même ressource !
Source : Tweet de @Judofyr

À mon sens, cet attribut html risque n'engendrer plus de problèmes qu'en résoudre. Déjà, il parle plus de cas de présentation que de sémantique du document lui-même, donc kesk'il me fout là en n'html, purin ?. Si on ajoute la balise <picture>/</>, on arrive à un niveau inquiétant de verbosité, alors que cela pourrait être évitée.

Et quand on connaît les conventions de code html qu'utilise Google, tellement concis qu'il ne reste plus grand chose, on est surpris que Chrome accepte autant de redites. Décidez-vous, ou prenez le temps de réfléchir...

Réfléchir aux usages actuels d'images

Et attention, je ne parle pas sociologie ou quoi que ce soit, je parle de l'organisation des assets dans un site web, tel qu'il est monté en l'état de l'art. Dans les images, nous avons celles qui nous décrivent quelque chose, et celles qui ne sont qu'un insignifiant décor…

Variation autour de « La Trahison des images » de Magritte.
Source : l'excellent billet sur le sujet par le blog Du bleu dans mes nuages

Nous avons ~~quatre~~ trois principales sources d'images :

celles appelées en CSS, purement décoratives et qui ne sont pas destinées à être modifiées par les utilisateurs du site ;
celles en <img /> mais qui sont appelées via des templates ou des manipulations d'éléments DOM du document ;
~~les emoji, noyés dans le texte par quelque hypster qui se croit à 原宿 ;~~
celles en <img /> résultantes d'un envoi par l'utilisateur via un CMS (ou parfois front-office pour les réseaux sociaux ou les sites de petites annonces) et qui sont conformées par le site (anti-intrusion, retaillage, éventuellement filigranage,…).

Dans le premier cas qui regorge de background-image, on ne se pose pas de questions puisque les media-queries CSS peuvent détecter la densité des pixels logiques via le paramètre resolution, ou alors utiliser directement les .svg de l'artiste designer.

C'est surtout dans ce dernier cas que la balise srcset="" devient particulièrement compliqué et contre-productif : Comment gérer l'existant ? Comment mettre à jour si de nouvelles finesses de résolution doivent être gérées pour ce site ?
Nous travaillons nettement plus souvent avec des CMS, comme le moteur de ce blog par exemple, qui génèrent à la volée plein de sous-formats d'images selon des contraintes d'aspects programmables, un classique des CMS. On ne peut mettre en place rapidement cet attribut sans un important travail de re-conformation du contenu existant. J'imagine déjà la complexité pour mon blog qui comporte plus de 2000 billets en 10 ans, et dont toutes les sources en très hautes résolutions ne sont pas forcément disponibles. Alors imaginez la situation pour un site d'e-commerce qui possède plus de 10 000 références ou pour un quotidien régional qui produit des dizaines d'articles par jour.
Et encore, La Dépêche a arrêté la rubrique des blagues mails suite à la concurrence frontale.

Sincèrement, ne prenez que cet article et imaginez que chaque image dont j'ai fait mention dans sa source doit avoir des définitions multiples, alors que la création de ses sous-formats a été automatisée/normalisée par le CMS que j'utilise.

NON P☵⚧⚼☭N NON srcset="" n'est pas du tout « …a good thing » de cette manière-là.

Ce qu'aurait dû être le cahier des charges

Un grand classique : Le cahier des charges tel qu'il a été compris

Pour moi, les règles de bases devraient être :

Pas de redites, l'URL de la ressource ne devrait pas être démultipliée dans le code source, surtout quand ces multiples adresses sont générées automatiquement. Moins on a de verbosité, plus on a de chance de convertir des utilisateurs
Le nombre d'éléments construits en DOM doit rester succinct
En restant simple, le code doit aussi inciter aux bonnes pratiques
Les dimensions doivent être implicites, le navigateur les connaît forcément en décodant le fichier image, et les css peuvent les changer pour des contraintes de présentation. Forcer les dimensions peut générer des aberrations insolubles
Tout ce qui concerne la gestion de résolution en fonction de la finesse de l'écran devrait être gérée naturellement. Comme cela fait partie non pas de la sémantique du document, mais de la présentation, cela devrait être délégué à la CSS
En termes de maintenabilité, l'ajout d'un nouveau sous-format d'images en fonction de la finesse de l'écran ne devrait pas demander plus de 5 lignes en tout et pour tout, même si on parle de milliers d'images.
La solution doit être indépendante du protocole, ne pas demander de modifications côté serveur, ni même de reconfiguration. Il faut que cela marche aussi bien sur un serveur dynamique, qu'un serveur statique ou en ressource stockée localement.
Elle doit être facilement réalisable par un webmestre lambda
Et évidemment, elle doit être facile à coder pour ceux qui écrivent les navigateurs, parce que sinon, c'est peine perdue

Si on reprend les astuces présentées dans le précédent chapitre, on verrait que srcset="" ne score pas forcément mieux...

Et si plutôt on passait par les CSS ?

Source : Vancoosh, starring Frida

Si je m'étais bougé dans les temps, que j'aurais choppé les discussions du W3C et mis mon ptit grain de sel de Guérande, j'aurais fait la proposition suivante : on devrait proposer de pouvoir modifier à la volée l'URL de source par une regex, puisque la grande majorité des sous-formats d'images sont automatisés jusqu'à leur stratégie de nommage.

Cela demande beaucoup de nouveautés :

Proposition : srcset en css

Toutes nos chaussettes au même endroit.
Source : AngryJulieMonday

En fait, le mieux serait d'indiquer une règle de ressource en fonction de la finesse de l'écran. Et quitte à avoir srcset="" en html, autant le remonter en css, non ?

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

Où l'on pourrait chaîner plusieurs scénarii :

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

Ce qui fait que cette propriété gérerait à la fois la substitution de source et l'échelle à y appliquer. Nous aurions une déclaration générale et beaucoup plus facilement modifiable en cas de modification des règles css, par exemple en cas de changement d'un thème responsive design. D'ailleurs la notation en fonction de la largeur disponible deviendrait caduque.

Bien évidemment, en cas de ressource absente, la propriété serait ignorée.
Nous aurions aussi un gain pour d'autres balises, telles que <video></> ou <iframe></>

Proposition : Intégrer les regex en css

Source : Halibustuff.com

La gestion d'un nouveau type d'opération en css, à savoir une regex et son pattern de remplacement. Tous les navigateurs possèdent forcément un moteur javascript, et donc une bibliothèque regex standard. Je pense néanmoins que c'est là qu'il y aura le plus de travail, de débats et de code à écrire car il demandera d'adapter les parsers css à une syntaxe qui leur est inédite.

Par exemple : regex(attr(src) , "^/images(.*)/([^/]+)$" , "/images\1/.\2,x2").
Le premier paramètre indique la chaîne de caractère à traiter, ici le contenu de l'attribut src="" dans le code html, le deuxième indique la formule de travail, et la troisième la formule de remplacement. Dans cet exemple, /images/examples/test.jpg serait remplacé en /images/examples/.test.jpg,x2

Du coup, il suffit de ne décrire qu'en une seule fois les stratégies de nommage des sous-formats d'images, selon que l'on a choisi par sous-répertoires (“/x1/img.jpg”), par suffixe interne (“img_x1.jpg”) ou externe (“img.jpg,x1”).

L'allègement de code du source html serait phénoménal sur bien des sites par rapport à la stratégie srcset="" dans chaque balise.

Proposition : async="no"

CC0 Auteur : Hans. Source : Pixabay.

Si nous ne voulons pas que le navigateur charge les ressources <img src="" /> par défaut, puis charge celles à la bonne résolution après coup, il faut avoir la possibilité d'indiquer au navigateur qu'un asset (css ou javascript) ne doit pas être traité de façon asynchrone. Et donc proposer un async="no".

Ouais, je sais.

D'ici, je vous entends hurler que cette proposition est totalement contre-productive, vous voulez me jeter à la figure des fruits pas frais, et vous me menacez d'une visite de l'Inquisition Espagnole.
Vous avez presque raison : Cette propriété éviterait que le navigateur appelle des sources d'images qui sont destinées à être invalidées dans une feuille de style. Évidemment, cela va complètement à rebours de tout ce qui est tenté en termes de performances, et il y a des risques d'abus, mais les intégrateurs apprendront à faire attention à leurs dépends. Et puis, si je ne fais pas une proposition totalement ridicule, vous risqueriez de me prendre au sérieux.

Actuellement, la solution adoptée est l'inclusion de js/css dans le html source. Et je ne sais pas pour vous, mais pour moi aussi, ça pique un peu les yeux.

In fine

Jumping water frog par agnatha3141

Je sais, c'est extrêmement prétentieux de faire autant de propositions, et une partie de celles-ci sont à coup sûr complètement erronées. Ensuite, il faudra les proposer indépendemment, les faire éventuellement accepter par les groupes du W3C et du WHAT-WG, les voir peut-être arriver dans les navigateurs et en éviter les abus.

Bref, il y avait du boulot, mais elles aideraiement à rendre la syntaxe html nettement moins verbeuse, l'entretien nettement facilité des ressources et la possibilité d'étendre très facilement pour les très très fortes densités encore à venir. J'ose à peine imaginer des malades capable de nous vendre des écrans à 3200 dpi…

Imaginez :


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;

}

On ferait difficilement plus simple…

And thank you for all the fish

Ce dossier sur la balise <img /> fut un travail long, et qui n'a pas la prétention d'être exhaustif ou parfait. Donc je remercie tous ceux qui m'auront relus, conseillé, corrigé dans les commentaires. Écrire sur un sujet exige de se remettre en question, de se documenter et à reprendre le désir d'apprendre et de rédiger sans se limiter à caler des jeux de mots foireux.

Je remercie milles fois la syntaxe de l'attribut srcset="" qui m'a donné l'inspiration de m'exprimer à ce sujet.

Sans rancune ;)

Finesse en ‹img /›

Da Scritch — 2014-06-12T10:47:00+02:00

Plus gros, plus gros, plus gros, encore plus gros, plus gros, vous pouvez mettre encore plus gros ? Parce que j'ai un écran très très fin et vos images ont un grain beaucoup trop gros…
Webdev

Ce billet fait partie de la série en <img /> :

Histoires en <img />
Manuel en <img />
Ressources en <img />
Bricolages en <img />
Progressivement en <img />
Finesse en <img />
Propositions en <img /> / English version

Après le problème de l'affichage progressif des images qui correspondait à l'époque des modems RTC, attaquons notre souci actuel de riches : Comment adapter une image en fonction de la finesse du support client ? De votre écran, quoi.
Un problème de finesse des écrans, des millions d'insultes proférées par tous les intégrateurs qui tentent de faire du responsive web-design beau et soyeux sur des supports en High-DPI (densité conséquente de pixels).

Comparaison de la finesse d'écran entre iPhone 3G et le 4 dit à écran Retina.
Source : iphone3gsystem.fr

La situation s'était brusquement aggravée depuis que le pixel décrit dans nos documents HTML/CSS/JS n'est plus le pixel physique d'un écran, la triplette de photophores de couleur primaire. Non, maintenant, ce qu'on décrit avec l'unité px est un pixel logique, le multiple divisible de pixels affichés. La dernière unité quasi-certaine en notation css est devenue aussi abstraite que les autres.

Vous croyiez ne pas avoir tout compris au paragraphe précédent, mais la situation est encore pire ! Tentez d'inclure un SVG dans un HTML et là, vous allez commencez à perdre la raison comme si vous aviez entrevu le nom d'un dieu plus ancien que l'Humanité dans le code source On peut même arriver à définir des pixels non-carrés sans le faire exprès. J͔͖̗͇͒ͫ̒͒͝e̸̬̠̟͎̥̬̙ͥͨ͑̅͂̅ ̸͚̞̫͕͇̠̊́̔ͩͪ̏v̥́̋̇a̷̺ͩi̭̙̥̩̜ͩ̚s͌͌̈ ̖̙̪̯̣͎͒ͅd̡̖͊̄̆e̸̱̎̊̈ͭ͊ͅv̙̺̱̻͖͕̫̀̏͒̍̾̚e̎͐̔n̛̹̺̩̬i̼̙̩̣ͤͦ́ͬ͒ͩr̈́͑ͥ҉̹͈ ̞̯̯̫̪̥̰̽̇f͎̹̲̆̽͂̂ͧ̑o̩̓͛u̵͈̰̗ͤͅ ̱̘ͮͥ̆̄ ̳͈͔̜͚̦̯͒̓͛͊ͦ͗̀g͒̑ͩ̉҉̯̮̫̣͓̼lo͚̯͖̻̥͙̻̓ͯ̊̋i̮̤͕͖̲̐̒̂͗͋̓rͬ̉̽ẹ͎̹̜͙̮͑ͭ͋ ̼͎̾ͬͫ͑̀ạ͍͔̳̀ͥ̽̏̇͗ͧ ̢̽̽ͨ̍̈́Ĉ̤͈̗̼̘͕ͪt͎͚h̜̪͕͍̭ͬͩ͞ͅu̲̫͆ͥ̑ͮ̂͑l̂̿͞ḫ̙̹̞ͣ͌̐ͫụ̪͇̫̝͗̅ͦ͛̕ͅ

Et pourtant…

Le problème Retina ? En fait, rien de nouveau

Le fameux souci d'avoir des images plus précises en fonction de la finesse de résolution de l'affichage existe depuis qu'il est possible d'imprimer une page web comportant des images, donc depuis… 1993.

À cette époque, les imprimantes laser proposaient déjà une résolution de 300 dpi. 300 dpi, c'est-à-dire 300 points (ou pixels) indépendants par pouce sur une ligne horizontale ou verticale, ou, parce que nous sommes civilisés, modernes, éclairés et donc métriques, 118 pixels par centimètre linéaire.
Du côté des écrans d'ordinateurs, le Macintosh présentera systématiquement ~~à son heureux pigeo~~ 72 dpi, finesse empiriquement choisie à la conception du tout premier Mac de 1984, d'une résolution de 512×342 sur son écran de 9" de diagonale ; cette finesse de résolution restera en vigueur dans l'univers Apple jusqu'à la popularisation de Mac OSX en 2003.
Du côté des PC, rien n'est standard mais la moyenne sera d'environ 96 dpi à la fin des années 1990s, selon les études marchés menées par Microsoft, et restera dans ces eaux-là jusqu'à la mort des tubes cathodiques. Et j'oublie de préciser que le pixel carré n'est pas une évidence…

Donc à l'impression d'une page web, tous les navigateurs ajustaient les images par rapport à la taille rendue des polices imprimées en les zoomant. En fait, le processus passait par l'OS, le service d'impression, le driver, voire l'imprimante elle-même… mais ne nous encombrons pas de détails bien oiseux. Plouf… plouf…

Pour vous donner une idée, voici une simulation de rendu où je passe un extrait d'une page web prise au hasard de 100 dpi à 300 dpi. Les polices suivent, les images sont lissées, la plupart du temps par interpolation cubique.
Imprimer les images comme si elles étaient en 96 dpi donnera donc ce résultat magnifique comme si un graphiste avait oublié d'inclure ses images sources dans son document Quark XPress™ avant de l'envoyer chez l'imprimeur. Et en oubliant de vérifier le BAT, tant qu'on y est. Ne rigolez pas : j'ai déjà vu cet incident arriver chez des éditeurs de BD..

Cela ne vous rappelle rien ? Ben si, c'est très exactement ce que nous avons avec un écran High-DPI comme ceux des smartphones, des tablettes et des portables haut-de-gamme.

La question n'a donc absolument rien de neuf, sauf que l'impression des pages webs a de manière générale toujours été négligée. Il existe parfois des feuilles de styles spéciales @media print, mais bien peu de personnes ont considéré que les images ne devaient pas être mosaïquées à 72 dpi quand elles sortent en papier.
Sachant que désormais les imprimantes lasers couleurs peuvent largement monter à une résolution de 1200 dpi, on peut en déduire le postulat suivant :

La résolution Retina™ professée par Apple révèle juste que les intégrateurs de sites web ne se soucient que maintenant d'un problème vieux comme le premier navigateur Netscape.

Faut avouer que c'est un peu dommage : on s'y serait attaqué nettement plus tôt, on aurait déjà les bonnes réponses, standards, utilisables, éprouvées et tout ça…

Comme a ultime-soupiré George Abitbol tout en finesse :

Heureusement, on a presque les bonnes réponses.

La sur-résolution

La sur-résolution semble être la méthode actuellement la moins honnie. Elle fonctionne naturellement et fait confiance au navigateur pour que son moteur fasse le travail.

Le principe est d'envoyer une image qui contient largement plus de pixels que les dimensions dans lesquelles elle sera insérée, Par exemple, à envoyer une image qui fait 1200×900, mais la contraindre dans sa balise d'appel à 300×225, comme suit :

<img src="image.jpg" width="300" height="225" alt="" />

Pour un navigateur qui a un pixel physique pour un pixel logique, il fera un rendu adouci en moyennant 16 pixels pour en afficher un. Sur les (très vieux) navigateurs, le redimensionnement naturel de l'image peut être traité à la serpe (je ne prend que le premier pixel du carré, et j'oublie les autres), ce qui donne un rendu un peu rustre que j'avais parlé justement en abordant les attributs de dimension.
Pour les écrans très fins où les navigateurs utilisent 16 pixels physiques (4×4) pour un logique, nous aurons l'image dans toute sa finesse.

La technique de la sur-résolution peut mener à des réglages très fins. Google a récemment finement raboté d'un pixel son logo à cause du rendu en sous-résolution sur Chrome :

La différence de rendu entre les deux images, réduites à 50% sur Chrome.
Le flou du L sur la barre du haut ou du bas, c'est comme la barbe de Haddock :
Vous n'en dormirez pas !

Le principal inconvénient de cette méthode est qu'évidemment les images sont nettement plus lourdes, et peuvent prendre un temps plus que conséquent à se charger dans certaines conditions (genre smartphone en GPRS ou sur la 3G parisienne). Et, réalité que nous avons oubliée depuis Free Mobile, le volume de données transférées peut coûter cher dans certains cas à l'utilisateur, et donc attirer une mauvaise réputation pour certains sites.
Les graphistes consciencieux pensent à réduire la qualité des images lossy générées, par exemple en passant le jpeg de 85% à 75%. Vu que 300 dpi est la limite perceptible pour l'œil humain, les artefacts résultants ne se voient pas trop. Une autre astuce courante est de préciser au compresseur quelles sont les zones les plus humainement importantes en terme de détails.

Un autre inconvénient est la maintenance : le style est embarqué dans l'image, mais en cas de changement de la ressource et de sa dimension, il faut repasser derrière tous les appel <img /> pour corriger les attributs de dimension. De la maintenabilité digne des années 1990s, quoi…

Les images vectorielles

Source : vectorise.fr

Ce serait l'idéal.

Malheureusement, une large partie des images qui composent le web sont issues de photos, scans ou captures vidéos. Si on converti une image raster pour le format vectoriel svg, on atteint un poids délirant, des pertes de qualité conséquentes et…

Bref : Contre-productif, passons.

Les images à formats multiples

Comme le format .ico qui peut contenir des images à de multiples résolutions différentes. Les éventuels soucis de brevets détenus par Microsoft sont nuls et non-avenus vu son âge canonique. Sauf que ce format d'image n'est pas du tout supporté par Apple, et que son support n'est pas consistant entre Chrome et Firefox.
On peut rester dans la même idée d'utiliser un format d'image conteneur, à savoir le PNG, mais il faudrait là aussi que tous les navigateurs puissent en adresser une ressource interne particulière, soit via l'URL, soit via une propriété DOM.

On peut alternativement jouer avec les formats d'images à chargement progressif, le PNG en mode progressif Adam7 ou encore le jpeg/jfif progressif. On garde une compatibilité parfaite avec l'ensemble des navigateurs. Le problème est que nous envoyons une quantité de données aux clients qui ne sera jamais entièrement exploitée. Ce souci pourrait être indirectement résolu par une transmission partielle interrompu des données. Techniquement, on le fait déjà depuis 2007 via un Request-Range et les retours de requêtes HTTP code 206 partial content, donc c'est faisable.

Mais pour le faire proprement, il faudrait modifier les infrastructures côté serveur. Cette solution demande donc beaucoup d'huile de coude sur les serveurs et les proxies en plus d'adapter les navigateurs. Beaucoup de si avant d'arriver au résultat escompté on est loin de l'économie espérée…

La méthode <noscript>

Il existe une méthode intermédiaire qui consiste à charger l'image avec la bonne finesse par javascript. Je n'aurais jamais découvert cette méthode sans Sud-Web où ~~Thomas Parisot~~ les éditions Eyrolles m'ont offert l'excellent livre « Intégration web : les bonnes pratiques » de Corinne Schillinger.
Je vous laisse goûter la syntaxe de l'astuce :

<span class="retina-holding" data-width="600" data-height="400" data-lowres="img-x1.jpg" data-hires="img-x2.jpg" data-hireszoom="2"> <noscript> <img src="img-x1.jpg" width="600" height="400" /> </noscript> </span>

Le hack peut sembler “élégant” par rapport à d'autres mais
… Cela ne vous rappelle rien ?

Source : « Astérix en Corse » par René Goscinny et Albert Uderzo, cité sur le tumblr officiel. © Éditions Albert René

Eeeeeehh si !
Le lazy loading qui nous a tant fait hurler ~~de rire~~ dans le précédent épisode. Et comme lui, cette méthode possède de nombreux inconvénients :

À moins que javascript ne soit désactivé par le navigateur, l'image n'est pas chargée naturellement et donc peut ne jamais apparaître en cas de plantage ;
La syntaxe ne se montre pas de la plus belle des légèretés, même si elle tente de respecter approximativement la sémantique. Malgré tout, le référencement et les outils de lecture différés tels que Wallabag ou Pocket ne trouveront pas l'image ;
Comme pour la sur-résolution, il faut déclarer explicitement les dimensions logiques de l'image, ce qui alourdi la notation et n'aidera pas à la maintenance ;

Le Web Component

Le Web Component est une proposition de standard du W3C pour construire ses propres balises HTML. Vous pouvez les définir comme des macros côté client pour du code html, javascript et css. Une partie du html généré peut même être caché en shadow-DOM.
La méthode n'existe pas encore en natif dans les navigateurs, mais je vous fais le pari que sa généralisation native ne va pas tarder car elle est vraiment très pratique. En attendant, des bibliothèques polyfill comme Polymer ou Bosonic peuvent facilement vous aider à implémenter ce nouveau standard.

Oui, bon, j'aurais tenté de vous faire passer un maquereau pour une macro…
Je voudrais vous y voir à illustrer un sujet technique. Source : La rousse

Utiliser un Web Component peut pénaliser votre indexation si vous créez une mauvaise sémantique, et là aussi, il deviendra impossible aux outils tiers de voir vos images ou en cas de plantage javascript. C'est là encore un comportement à éviter pour tout ce qui est publication, blog ou site d'e-commerce.
Néanmoins, si je devais implémenter l'exemple précédent de la manière la plus propre possible, j'arriverai à :

<responsive-img data-x2="img-x2.jpg"> <img src="img-x1.jpg" width="600" height="400" alt="" /> </responsive-img>

Une balise <img /> standard dont l'appel n'est pas bloqué, à priori, je ferais difficilement plus propre. Et je peux me passer des attributs de dimension si je fais excessivement confiance aux dimensions servies comme on dit en Côte d'Ivoire. En fait non, je ne peux pas. RAAAHHH !

Via Content negotiation

La solution serait théoriquement transparente dans le code HTML, puisque tout se passe dans l'étape de négociation HTTP entre le navigateur et le serveur. Effectivement, quand le navigateur demande une ressource à un serveur, il dit ce qu'il peut accepter comme format de document pour cette ressource.
Ainsi, pour les ressources images, mon navigateur indique au serveur ce qu'il attend, et ses préférences :
Accept: image/png,image/*;q=0.8,*/*;q=0.5

La solution me semble élégante. Mais elle réclamerait beaucoup d'adaptation côté serveur, et aussi beaucoup de technicité car il faudra travailler les fichiers de configuration de vos Apache, n'ginx ! Or qui dit bricoler dans la configuration serveur, dit solution inatteignable dans un très grand nombre de situations, ce qui serait très frustrant. Sans compter qu'une nouvelle finesse d'écran sur le marché demandera de reparamétrer à nouveau les serveurs. Et elle ne résoudrait pas le problème de la différence de dimensions à prendre en compte par le navigateur.
En clair, ce n'est pas la meilleure car elle ne peut fonctionner que sur un hébergement dynamique.

Exemple de négociation de contenu : ici un texte est disponible entre différentes versions linguistiques, mais celui qui est servi dépend de la langue de l'ordinateur du client.
Source : Blog W3C, « Content Negotiation : why it is useful, and how to make it work. »

Si je devais la construire, voici comment fonctionnerait mon polyfill :

Un javascript côté client stocke un cookie pour le domaine indiquant la finesse d'écran attendue. Disons X-pitch=4
Un .htaccess peut rediriger la requête en fonction de la cookie et de la disponibilité de la ressource, en indiquant la finesse servie par un paramètre GET image.jpg?pitch=4 ou une sur-extensionimage.jpg,pitch_4.
Si jamais la finesse demandée n'existe pas, la redirection se fait vers une finesse moindre, par ex.: image.jpg,pitch_2.
Si aucune autre finesse que l'image par défaut n'est disponible, aucune redirection n'est effectuée.
Côté navigateur, à la réception de l'image, le javascript (ou la css en trickant comme un taré ?) applique le ratio de réduction correspondant si l'url de ressource d'image chargée comporte cette indication de finesse

Ce que j'aime dans ce scénario, c'est que si nous avons un souci de javascript ou côté serveur, le comportement par défaut du navigateur n'est pas impacté. De même, nous n'aurons aucun souci de syntaxe et pour les outils tiers.

Enfin bon, c'est juste une idée jetée comme ça à 2 h du matin, sans même en vérifier la faisabilité. Il y a sûrement un os quelque part si personne n'y avait pensé jusqu'ici, non ?
Genre, comment fais-tu quand la requête vient de la CSS et pas de <img /> ?

La proposition du W3C : srcset="https://dascritch.net/post/2014/06/12/"

Vue la longueur de mon billet uniquement sur les hacks possibles, et vu ce que j'ai à écrire sur la proposition de cet attribut, je vais réserver ça pour un dernier chapitre.
Parce que, il y en a à dire, mais surtout à proposer.

Progressivement en ‹img /›

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

Que faire quand on a trop d'images ou qu'elles sont trop lourdes pour les tuyaux d'internets ? Comment donner l'illusion qu'elles arrivent dans un délai raisonnable ? Jouer avec l'affichage plus tôt ou plus tard d'une image, bonne ou mauvaise idée ?
Webdev

Ce billet fait partie de la série en <img /> :

Histoires en <img />
Manuel en <img />
Ressources en <img />
Bricolages en <img />
Progressivement en <img />
Finesse en <img />
Propositions en <img /> / English version

Dites-moi, les jeunes, quelle est la vitesse de votre débit ? 12 Mbds ? 20 Mbds ? 500 Mbds ? Eh bien dites vous qu'il fut une époque où la vitesse moyenne de téléchargement plafonnait à 4,8 kbds ! À cette vitesse, cela voulait dire qu'un document de 100 ko mettait au mieux plus de 3 p☠♝☈➿ns de minutes à arriver en entier !

Internet, n'a pas toujours connu le haut-débit.
Des fois, les images sont chargées trop lentement alors on tente de les afficher prématurément. D'autres fois, on retarde exprès son chargement.

Ce dernier comportement peut se justifier, mais comporte de multiples erreurs.

Les images à chargement progressif

Donc, lors de sa préhistoire, le web n'arrivait à des débits de 1 Mbds que dans certains laboratoires, c'est à dire à moins de 10 mètres du serveur. La plupart du temps, quand on chargeait une image, ça se passait comme ça :

Image fortement accélérée : Parfois ça prenait plus d'une minute…
Source : voir plus bas

Certains formats de fichiers ont été spécialement conçus pour être transmis et affichés progressivement. Dans ce cas, l'algorithme de compression de l'image ne peut être optimum, mais cela permet un meilleur confort côté utilisateur si son modem est très lent.

À la haute époque dinosauriale des BBS, les serveurs qui se contactaient en RTC (donc par téléphone avec des modems qui allaient de 300 bauds à 4 kbds), un format a émergé en 1987, le GIF.
Le format GIF avait donc à la fois un excellent format de compression d'image pour l'époque (LZW) et un mode progressif d'affichage de l'image. Son principe était simple : au lieu d'enregistrer chaque ligne horizontale l'une après l'autre, on enregistre chaque ligne en en sautant 8, arrivé en bas de l'image, on repart du haut en prenant la ligne non-enregistrée suivante avec un pas deux fois plus fin. C'est un format entrelacé, dans un concept plus évolué que la télévision analogique qui alternait les lignes paires et impaires. L'idée étant de permettre d'avoir un aperçu (certes très pixelisé) global de l'image avant qu'elle ne soit complètement chargée.

Comme l'image ainsi enregistrée était plus lourde, eh bien on attendait moins longtemps. Logique.

Pour les logiciels clients qui pouvaient le gérer, nous obtenions un effet de stores vénitiens qui s'ouvraient progressivement. L'image complète se reconstituait en 4 “passes”.

Excellente recréation de l'effet avec le logo de la Wikipédia.
Source : Dominique Toussaint sur Wikimedia

À noter que le PNG possède aussi un mode entrelacé, un algorithme appelé “Adam7”, pour 7 passes :

Ce qui, dans les faits, donne un effet de mosaïque inverse :

Source : Le toujours excellent blog technique Coding Horror

Le format JPEG n'était pas prévu pour être un format de transmission bas débit, mais une fois qu'il fut supporté dans Netscape 1, il fut lui aussi doté d'un mode d'enregistrement progressif. Ce dernier tire parti du mode de compression par macroblocs, suivi d'un affinage par vaguelettes. Mais là encore, il se paie : le poids du document est sensiblement plus lourd.

L'affichage d'un JPEG enregistré en mode progressif.
Source : l'excellent article de Stoyan Stefanov sur le YUI-blog

Comme j'en ai déjà parlé dans un précédent chapitre de ce dossier, il se trouve que MSIE n'a jamais pris en compte l'affichage progressif d'une image. Et comme MSIE était devenu le navigateur dominant de l'ère proto-ADSL, enregistrer une image en mode progressif était devenu complètement contre-productif.

Cette solution du chargement progressif des images fut traité très différemment dans le cadre du son et de la vidéo, puisque lesdits types de documents sont techniquement conçus pour un décodage à la volée des données, au fur et à mesure de la temporalité du document, avec parfois une capacité à s'adapter à la vélocité de la transmission.
Vous ne m'avez pas compris ? Raaaah flûte !

L'attribut lowsrc="https://dascritch.net/post/2014/06/10/"

Une autre solution fut proposée par les constructeurs de navigateurs, l'attribut lowsrc="". Oui, j'en ai déjà parlé dans le deuxième volet, mais il mérite d'être mieux expliqué ici.

Donc, je vous en rappelle le principe, une image est appelée comme suit :

<img lowsrc="preview.gif" src="image.jpg">

L'idée étant que le navigateur commence par charger preview.gif qui est une version monochrome de l'image normale et donc largement plus rapide à télécharger, une ombre théoriquement fugace qui ne persiste que les 4 minutes nécessaires pour récupérer tout les autres éléments de la page.
Cela demande forcément de traiter en avance l'image, puisque dans les années 1990s, vous n'aviez pratiquement pas de solution pour éditer une image côté serveur.

Si je reprends l'image du dessus, ça donne ça :

Aaaah, ce bon vieux Floyd-Steinberg. J'espère que tu m'excuseras de t'avoir trompé avec le true-color, qui, je sais, n'est qu'un mirage devant l'infinité des nuances de la vie… Oui, je t'ai aimé et je t'ai quitté…

À noter que l'apparition progressive de l'image pouvait avoir lieu selon certaines conditions passant de vaudou à black magic jusqu'au fatidique en fait, non, arrête : ça ne sert strictement à rien…

La troisième capture simulée n'est pas complète ?
Eh ben oui, forcément, comme il faut charger deux fois l'image, ça prend largement plus de temps pour l'afficher proprement au final. Or c'est justement cette double négociation qui peut prendre le plus de temps dans certains cas. Finalement, cet attribut a plus ralenti les navigateurs que donner une impression de rendu accéléré, il s'est montré contre-productif. lowsrc="" n'a d'ailleurs jamais été standardisé par le W3C, et a disparu dans les cendres d'une époque pré-CSS. Il a été oublié par tous les navigateurs qui l'avaient implémentés, à ma connaissance, Netscape, Opera et quelques navigateurs embarqués dans des feature phones.

Sauf quelque SEO-LOL qui me soutenait mordicus qu'il faut déclarer deux fois la même ressource <img lowsrc="image.jpg" src="image.jpg"> parce que « Ça donne plus d'importance à l'image pour les moteurs de recherche ». Si ! Si ! Il y croyait fermement. Facepalm dans sa tronche.

Lazy loading : Le chargement volontairement différé

Le lazy loading est une “mode” apparue en 2010. Elle consiste à ne pas laisser les navigateurs charger naturellement les images, mais attendre que l'endroit où l'image doit apparaître soit visible dans le viewport. Ce comportement est réalisé par une bibliothèque javascript. Une idée qui fonctionne pour les pages web qui ont une certaine longueur.

Attention : nous ne sommes pas dans le concept de scroll infini, où des portions complètes de contenus sont chargées au fur et à mesure qu'on descend dans la page. Ici, l'ensemble du texte, du layout, du DOM, des éléments du document sont chargées, SAUF les images, et donc il faut descendre pour que le chargement se déclenche.

Sincèrement, je trouve ce système extrêmement désagréable. Je prends par exemple un article que je commence à lire. Au bout d'une minute, souhaitant lire la suite, je scrolle avec ⇟ Page down, des espaces blancs apparaissent brusquement dans le texte, puis des images arrivent. Cela distrait le lecteur, et donne une forte impression de lenteur au site. T'avais pas le temps de tout charger alors que je lisais tes premiers paragraphes ? SRSLY

Flickr fait un infinite scroll totalement justifié, mais qui ressemble à ce dont je veux illustrer : une impression de lenteur.
Source : pool flickr de Sud Web 2014

Pourquoi Dirty Hacky va dégainer et tirer sans sommations ? Parce que la sémantique html de votre page est cassée, elle perd de son sens. Un peu comme si je mettais une passoire à un endroit, et que si je la regarde, au bout de 3 secondes, une casserole apparaît à sa place.

Les navigateurs chargent toutes les ressources sans chercher à voir s'il y en a immédiatement besoin. Oui, bravo, tu viens de définir exactement le principe d'intégrité d'un document. Mais peut-être ne sais-tu pas que le web est utilisé bien au-delà de ton navigateur web ?
Forcément, ignorer la sémantique casse beaucoup de fonctions normales du web :

Si votre javascript ne se charge pas ou plante brusquement, les images n'apparaissent absolument pas ;
L'indexation de votre page par les moteurs de recherches risque de devenir incohérente voire fortement pénalisée ;
L'indexation des images par ces mêmes moteurs ne se fait plus ;
Cela gâche l'impression d'une page, puisque les images ne sont pas chargées par défaut, il faut faire défiler entièrement la page dans son navigateur avant, et encore… ;
En cassant le web sémantique, on casse aussi l'usage de services tiers comme les flux RSS, ou encore les lecteurs différés comme Wallabag ou Pocket puisque les images n'y apparaîtront jamais ;
Les avantages à venir des navigateurs, notamment un éventuel chargement intelligent des ressources selon leur position géométrique, ne sera jamais exploitable ;

Je me suis rendu compte que la plupart des sites qui utilisent de genre d'artifice ont du texte au kilomètre, suivi d'un nombre très conséquent d'images, le tout préfixé par un titre dans le genre « Les 500 images de clowns se cassant la gueule qui font rire » ce qui leur assure un fort trafic.
Après avoir longuement tortionné à l'épluche-légume une des personnes qui l'utilise (Oui, l'épluche-légume m'a semblé être l'outil le plus à même de faire comprendre la torture induite par ce genre de script à la con), j'ai enfin eu des raisons “valables” :

« Parce que j'ai une page trop lourde donc elle met trop de temps à se charger. » Déjà, enlève 50% de tes javascripts de pubs, tasse tes assets, optimise la compression de tes images et surtout simplifie au maximum ta maquette : elle est sûrement trop complexe ;
« Parce que mon serveur a beaucoup trop de traffic à encaisser. » Alors commence à investir dans un serveur auxiliaire, fait appel à un vrai CDN, voire commence à faire du load balancing au cas où ton serveur crashe ;
« Parce que je me fais sans cesse piquer mes images. » C'est le principe du web, même si tu bloques l'accès à “Voir le code source” ou à "Enregistrer l'image sous" par le menu contextuel, tu n'as aucune chance d'empêcher ni le Ctrl+U, ni le F12. Alors un wget des familles, n'en parlons pas. Peine perdue ;
Et enfin ce p'tit con qui est trop jeune pour avoir eu un modem 28kb de chez US Robotics, il me dit que « mais c'est trop génial, ça donne un effet totalement inédit… ».

C'est à ce moment-là qu'il a perdu d'une manière inédite ses dernières dents, dommage collatéral à cette enquête de terrain par votre serviteur. Dirty Hacky conclu l'interrogatoire avec sa phrase habituelle :
BANG ! BANG ! BANG !

Le chargement avec… une iframe ?!?

Ça, c'est tout récent, et c'est surtout le fait de Getty Images. Getty Images comporte le plus important fonds de photos historiques et un des plus importants en images d'illustrations, ce qu'on appelle improprement le libre de droit. En temps normal, l'usage de ce trésor est loué à prix d'or aux professionnels et l'achat d'art est un poste souvent négligé par des web-agencies d'amateurs. Getty a d'ailleurs une réputation agressive à pousser son copyright parfois très loin.

Depuis Mars dernier, Getty Images met gracieusement à disposition des blogueurs une partie de son catalogue d'image, mais avec d'importantes contreparties. Notamment l'insertion doit être fait avec <iframe></>. Avantage : le design est conservé, les crédits de l'image aussi et l'agence peut parfaitement tracer l'usage et l'audience de son catalogue. Et, oui, nous avons bien un chargement différé de ce contenu par rapport au reste du document, puisqu'une iframe est souvent chargé en tout dernier par rapport aux autres assets de la page.

#79989152 / gettyimages.com

Pour embarquer l'image précédente, voici le code source totalement overkill que Getty Image me propose d'insérer :
<div style="[…]"> <div style="[…]"> <iframe src="//embed.gettyimages.com/embed/79989152?[…]" width="594" height="482" scrolling="no" frameborder="0" style="[…]"></iframe> </div> <p style="[…]"></p> <div style="[…]"><a href="http://www.gettyimages.com/detail/79989152" target="_blank" style="[…]">#79989152</a> / <a href="http://www.gettyimages.com" target="_blank" style="[…]">gettyimages.com</a></div> </div>

Je me demande si je n'aurais pas dû prendre comme illustration l'image d'un garçon présentant une obésité morbide…

Là, c'est même pas moi qui va m'énerver, mais les constructeurs de navigateurs web, car une insertion d'<iframe></> est loin d'être gratuite en terme de consommation mémoire ; j'ai rapidement abordé ce sujet à propos des boutons de partage sur les réseaux sociaux. Alors imaginez quand une page en comporte une cinquantaine… L'abus d' <iframe></> est actuellement l'une des principales causes de crash de navigateurs.

Ce qui explique que vous voyez souvent cette erreur quand vous visitez certains sites.
Source de la capture : astucehebdo

Bientôt la fin ?

Dans le chapitre suivant, je parlerai enfin du problème qui m'a motivé à écrire ce dossier : le problème de l'affichage d'une image en fonction de la résolution de son support. Vous verrez qu'on va parler à la fois des formats ésotériques, d'un retour du lazy-loading et ce d'une proposition que Daniel ne peut pas refuser…

Bricolages en ‹img /›

Da Scritch — 2014-05-12T10:15:00+02:00

Où l'on apprendra comment les images sont gérées par les serveur web, et comment les navigateurs utilisent le document et ses méta-données header http. Avec une très belle astuce pour les CMS.
Webdev

Ce billet fait partie de la série en <img /> :

Histoires en <img />
Manuel en <img />
Ressources en <img />
Bricolages en <img />
Progressivement en <img />
Finesse en <img />
Propositions en <img /> / English version

Maintenant que nous avons défini la méthode d'appel dans la syntaxe html et que nous connaissons les formats d'images actuellement supportés, intéressons-nous sur la manière dont les navigateurs web travaillent, avec en prime un petit hack amusant.

Reverse engineering : comment les navigateurs gèrent <img />

Le plus important à savoir est que pour les clients web l'extension du nom de fichier n'a aucune influence.
Croire qu'il faut un .gif en fin de nom de fichier pour mettre votre truc animé, c'est un peu la même croyance que croire mordicus que .html en fin d'url aide précieusement votre référencement. Le W3C, l'IETF et toutes les cyberpolices qui définissent internet se foutent de chaque charlatan qui professe le contraire. Ces derniers sont des SEO-LOL qui travaillent exclusivement sous Windows et qui ne connaissent rien au web, ni à internet, ni à l'informatique.

Un spécialiste SEO diplômé Sup-De-LOL avec son appeau à crawlers.
Photo CC de Rodrigo Álvarez avec Oscar Zimmerman

Parce que cela n'a jamais été le cas : Il n'est pas rare dans la vie d'un crawler de moteur de recherche de tomber sur du texte ou des images générés dynamiquement et servis par des URL se terminant en .pl, .php ou .aspx. Une extension de nom de fichier n'est jamais une information fiable pour identifier un type de document.
Dans le protocole HTTP, si un logiciel client, qu'il soit navigateur web ou crawler, doit identifier le type de document (si c'est une image ou une page de texte) autrement que par son contenu, il doit se référer au type-mime indiqué dans l'entête Content-type: par le serveur. Si cette information ne semble pas fiable, on passe alors à une analyse divinatoire du type de document, familièrement appelée magic.

Le format réel de la ressource image est devinée par la bibliothèque de décodage graphique embarquée par le navigateur. GIF ? JFIF ? PNG ? Pas de souci : ces bibliothèques procèdent à une divination magic optimisée, testant les formats de documents qu'elle supportent. Elles sauront très bien se dépatouiller avec l'image.

Mais je vais être honnête : Dans les faits, quand il faut construire l'header d'une ressource à servir, les serveurs web en production correctement paramétrés ne se basent pas sur les définitions magic des fichiers, mais… sur l'extension de leur nom. Nettement plus rapide qu'analyser le contenu du document et le confronter à plusieurs milliers de règles regex.
Arrêtez de pouffer dans le fond, nous verrons plus bas que son utilité est toute relative pour <img />.

C'est l'histoire d'un trou de fort beau gabarit

Et puisqu'on parle de cela, il que je vous conte l'histoire d'un trou de sécurité qui resta très longtemps béant.
Il était une fois un navigateur qui avait gagné une guerre, et qui fut le plus populaire des navigateurs de son temps : MSIE (MSIE 6 inclus jusqu'à la XP SP1).

En ce temps-là, le navigateur fourni d'office par Microsoft était tellement imbriqué dans Ms-Windows qu'il demandait aux procédures standards de l'OS de deviner à sa place les fichiers images. Jusqu'ici rien d'anormal : les équipes de développement Microsoft utilisaient pragmatiquement sans le savoir l'approche DRY. Do not Repeat Yourself (il est inutile de répéter les mêmes fonctions) est une très bonne pratique de développement de projet.

MSIE n'étant disponible que dans l'OS de Microsoft (l'équipe de la version Mac mourrait d'inanition), la IETeam n'allait pas s'embêter à ré-inventer la roue et se baser sur la gestion des types de documents propre à Ms-Windows.
Du coup, si le système hôte supporte un nouveau type de document qui est un format d'image, le gestionnaire de document tout comme le navigateur imbriqué vont aussi le gérer, comme tout logiciel de cet éditeur. Ce mode de conception se retrouve dans d'autres OS et navigateurs : Rekonq se base sur les bibliothèques Qt de l'environnement KDE, et Safari se reposait en défaut sur Quicktime pour les ressources qu'il ne comprenait pas.
On y retrouve d'ailleurs le même manque fonctionnel par construction : l'affichage durant le chargement du gif 89a entrelacé et du jpeg progressif n'est pas possible, toute image n'est affichée qu'une fois complètement décodée.

Sauf que dans l'écosystème de Microsoft, cette procédure était trop permissive : Gestion par extension de fichier plus oubli de limite de périmètre fonctionnel. Les documents “images” appelés via <img /> se finissant en .exe ou .dll étaient… exécutés… avec le plus haut niveau de privilège possible…

Double facepalm, quand un seul ne suffit pas.

Si je vous dis qu'il était à l'époque “courant” de piéger des pages web qui changaient par ce biais le numéro d'appel du modem pour accéder à Internet en un 08 99… soigneusement surfacturé. Oui, Monsieur le Président, je plaide la complicité.

Ce fut la dernière fois qu'un navigateur se basait sur une extension de nom de fichier pour gérer les éléments d'une page web au lieu de vérifier son contenu effectif. Et depuis, MSIE fait comme tout le monde et utilise une bibliothèque compartimentée pour le décodage et l'affichage des images.

D'ailleurs, c'est suite au comblement de cette faille qu'on a commencé à voir arriver des favicons animées. La recette est simple : renommer une animation gif de taille 16×16 en favicon.ico et le mettre à la racine du site. Encore une fois terriblement efficace.

C'est cette astuce qui allait me donner l'idée d'un hack…

(teasing)

Classique des CMS : Image source et sous-formats

Quand vous construisez un CMS ou n'importe quel service qui doit servir des images fournies par des utilisateurs dans un contexte formaté, l'exercice de style archi-classique est la gestion des sous-formats d'images.

Tout outil de blogging ou d'e-commerce doit forcément gérer le fait qu'un contenu texte ou qu'un item soit enrichi d'une image. Il est dans les faits extrêmement rare que l'utilisateur qui crée le contenu envoie au serveur une image aux dimensions exactes préconisées par le designer.

Mock-up d'un design d'article magazine. Flottant à gauche, un espace contraint est prévu pour des images.
Source : Étude de redesign du site news.uci.edu

Et il est probable que cette image d'illustration soit reprise dans d'autres contextes, par exemple une page de une, de sommaire ou de recherche mais dans d'autres dimensions contraintes. Cette image doit donc être réduite ou/et coupée par l'interface d'édition afin de tenir dans un ou plusieurs certain canevas. Une opération plus cohérente et largement meilleure que de faire de la sur/sous-résolution.

Le CMS crée à partir de cette image source (ou master) des sous-images qu'on a conformé aux dimensions du design graphique du site. Ces sous-formats sont parfois optimisés pour le transfert en jouant sur les paramètres de compression, en suppression des métadonnées embarquées, etc…

L'écueil du nommage des sous-formats

« Qui amat bene, castigat bene. » (maxime latine qui explique qu'au rugby, on aime beaucoup ses adversaires).
Pour l'avoir beaucoup trituré dans tous les sens, je vais parler du moteur de blog qui motorise mon site depuis 10 ans. Dotclear, dans sa version 1 n'avait qu'un seul format de sous-images. Si j'envoyai capture.jpg, le script créait capture.TN__.jpg. Ce qui posait un souci de lisibilité dans les répertoires, puisque les entrées étaient doublées dans les gestionnaires de transfert.

Dotclear 2 propose une gestion paramétrables de multiples sous-formats. Cette fois-ci, Dieu décida de cacher le sous-formats d'images en préfixant par un point le nom de fichier (le standard Unix pour cacher un document, dans l'univers MS-DOS, c'est un bit d'état dans les métadonnées). Ainsi, on passait d'une structure :

capture.png
capture.__TN.jpg

capture.png
.capture_m.jpg
.capture_s.jpg
.capture_sq.jpg
.capture_t.jpg

La génération de certains sous-formats ne se fait pas si l'image master est en-dessous des tailles maximales du canevas de ce format.

Extrait d'une vue de l'arborescence des illustrations de ce dossier. À droite, les documents originaux que j'ai envoyé, à gauche, les sous-formats générés par Dotclear. Ces derniers sont en sous-opacité car ils sont “cachés”.

Mais il reste un souci : jusqu'à la version 2.5, les sous-formats générés par le moteur de blog sont forcément des jpeg. Imaginez que vous envoyiez exemple.jpg et exemple.jpeg, si les masters sont bien différenciés, vous aurez forcément une collision parce que le nom du document hors extension est le même.

Pour moi, cette imprécision n'était pas acceptable car j'ai régulièrement eu des utilisateurs qui se plantaient à l'extension. Et je ne vais pas les en blâmer : mes clients humains étaient des chefs d'entreprises dont le métier n'est pas l'informatique, je devais donc m'adapter, ou en suer à gérer le “bug” par téléphone.

Forcément, quand j'ai créé le mien…

Pour mon service dAgence, je souhaitais avoir la plus grande plasticité possible pour générer les sous-formats à partir d'une image originale. Comme nous (Nicolas “Xylpho” Guilhou au design et moi au code) construisions une solution B2B destinée à des freelances et des agences web, il fallait avoir un service générique, exhaustif capable de répondre à leurs demandes en étant le plus souple possible.

Le problème de collision de nom de document hors extension était, croyez-moi, le moins pire de nos soucis : Vous ne pouvez pas imaginer de quoi est capable un client, surtout s'il est conseillé par un spécialiste design qui n'a jamais fait de css de sa vie.

Pour illustrer, voici les paramétrages de sous-formats d'images utilisés pour mon site corporate dascritch.com, actuellement toujours hébergé sur dAgence.

Capture du backoffice béta, sur la liste des sous-formats d'images générées

En clair, si j'envoie un capture.png, j'aurais forcément pour les besoins du backoffice, un sous-format favicon (qui tronque en 16×16 et exporte en png) et icone (qui réduit en 128×128, en jpeg). Sur cette portion capturée, on ne le voit pas très bien mais ces formats ne sont pas modifiables.

En frontal (le site accessible à tous, quoi), je crée et paramètre autant de sous-formats que je le souhaite. Ainsi, sur mon site, j'ai le dsn (qui ne modifie pas la taille, mais transcode jpeg à 80%, sans métas) et realisat, générée à partir des paramétrages suivants :

Comme le laisse deviner le titre de la dernière section que je n'ai pas inclus, on peut aussi y surimposer une image en filigrane ou en tampon.

Ce qui me rappelle un projet magnifique : Un client avait prévu que son site web soit disponible en au moins 7 langues, et que les images aient des versions avec un tampon nouveau !, un avec promo ! dans chacune des versions linguistiques. 14 filigranes, plus l'original multiplié par les 4 formats minimum designés, ça faisait un joli paquet.
Oui, le client voulait absolument que toutes ses images soient filigranées, au cas où un concurrent parse son catalogue pour remplir le sien, comme lui-même a dû le faire pendant des années.
Petit coquinou.

Alors je me suis gratté la tête

Donc, quand j'en étais à créer un gestionnaire de média, j'ai dû faire un choix sur la stratégie de nommage des sous-formats d'images. J'avais écarté l'idée de créer dans chaque répertoire un sous-répertoire par sous-formats, car c'était reculer pour mieux se planter. Je voulais rester dans l'idée de sous-formats dans le même répertoire que le document original. Il fallait trouver une solution en jouant sur les standards et pratiques courantes.
Et je me suis dit que malgré toutes les bêtises que mes clients humains aient pu faire, je n'avais jamais vu un élément sans extension se terminer par une virgule puis un mot.

Bingo.

Pour m'assurer que les navigateurs un peu problématiques de l'époque ne soient pas perdus (de mémoire, des navigateurs pour feature-phones comme Open-Wave), je leur envoie un type-mime d'image universellement supporté, mais sans support de chargement progressif. Donc forcément un png. Je demande donc au serveur http du service de fournir les documents avec le type-mime image/png sans se baser sur le contenu interne du document servi mais sur le nom de fichier (ce qu'il fait quand même… eh oui).

Paramétrages pour un serveur Apache :
<FilesMatch ,[A-Za-z0-9_\-]+$> ForceType image/png </FilesMatch>
Pour un serveur nginx :
location ,[A-Za-z0-9_\-]+$ { default_type image/png; }

Et voilà *.
Peu importe le type d'image généré, que cela soit un gif, png ou jpeg, votre serveur web déclarera dans les headers http un Content-Type: image/png, les navigateurs clients qui le récupèrent comme ressource <img /> ou composante css laissent à leur bibliothèque de gestion des images le soin de se dépatouiller avec. Et tous les navigateurs l'ont très bien supporté, même MSIE6.
(* En Français dans le texte)

Avant de tester ce dernier fait, petits rappels :

les directives apache ou nginx, moins il y en a, mieux c'est ;
les directives avec des expressions régulières dedans, c'est une chute de performance annoncée. Mais comme les méthodes magic en sont farcies, ici, au contraire, on peut faire gagner du temps au serveur ;
sur serveur apache, évitez autant que possible de mettre des directives en .htaccess : si elles ne sont pas destinées à bouger sans un redémarrage serveur, préférez les mettre dans votre arborescence /etc/apache2/…

Ainsi, si j'envoie dans le backoffice de mon site pro, une image appelée capture.png, mon serveur va construire dans un répertoire les documents :

capture.png
capture.png,demo
capture.png,dsn
capture.png,favicon
capture.png,icone
capture.png,realisat

Let's test !

Il s'agit du même test dynamique que pour le chapitre précédent : Si l'image “oui” s'affiche, c'est que le navigateur le supporte.

Format	Type/mime standard	support	forcé en image/png	text/xml	application/binary
xbm	image/x-xbitmap
xpm	image/x-pixmap
pbm	image/x-portable-bitmap
pgm	image/x-portable-graymap
ppm	image/x-portable-pixmap
bmp	image/x-ms-bmp
gif	image/gif
ico	image/vnd.microsoft.icon
jpeg/jfif	image/jpeg
jpeg2000	image/jp2
jpeg XR	image/vnd.ms-photo
tga	image/x-targa
png	image/png
mng/jng	video/x-mng
apng	image/png
svg	image/svg+xml
webp	image/x-webp

Quels que soient les navigateurs web, pour que la ressource d'une <img /> soit parfaitement interprétée, le seul besoin impérieux est que le fichier doit être correct. La seule exception où nous avons besoin d'un type-mime exact concerne le format svg.
La raison est évidente : la nature vectorielle du svg le fait passer par le moteur de rendu “normal” du navigateur, donc un arbre dom. À l'usage, une image svg n'a pas une consommation mémoire aussi indécente qu'une <iframe></>, puisque les navigateurs très récents ne chargent pas un interpréteur complet.
Pas fous.

Ceci dit, même si le format svg est celui dont la gestion des éléments est le plus aléatoire dans les navigateurs, les corrections avancent. Je ne serais pas surpris que le tableau fasse mentir le paragraphe qui le suit dans les mois qui viennent.

Vos retours sur le hack

Est-ce que mon hack est propre ou dégueulasse ? Survivra-t-il à l'épreuve du temps et de l'élégance ? Est-ce que l'Inspecteur Dirty Hacky doit dégainer et flinguer ?

Je serais curieux d'avoir votre retour. Positif, négatif, analyses… On pourrait peut-être en parler IRL à la prochaine soirée HTML Sur <Table>

Dans le prochain épisode, l'épineux problème du chargement progressif pour qu'il soit ni trop lent, ni trop rapide. Si. Si.

Ressources en ‹img /›

Da Scritch — 2014-04-29T08:37:00+02:00

Bon, coco, ton logo, je te l'exporte en quel format ? en bitmap ? dégradé ? paletté ? avec alpha-transparence ? sans animation ? ni support MSIE 7 ?
Webdev

Ce billet fait partie de la série en <img /> :

Histoires en <img />
Manuel en <img />
Ressources en <img />
Bricolages en <img />
Progressivement en <img />
Finesse en <img />
Propositions en <img /> / English version

On va aborder maintenant le support des formats d'images par les navigateurs, indépendamment de la balise <img /> puisqu'il concerne aussi les css. Si de nos jours, tu ignores un truc dans ce chapitre, c'est que t'as sûrement loupé ta vie de webmaster.
Aussi étonnant que celui puisse paraître, le W3C n'a jamais défini de format d'images que les navigateurs devaient supporter dans l'attribut src="".
Non : rien, nada, zilch, que dalle, même pas une recommandation.

Et en l'absence de gestion de fallback natif en cas de non-support par le navigateur client, il serait plus heureux de vérifier le support par l'entête Accept: envoyé par le navigateur durant le content negociation, mais cela suppose avoir la main sur le serveur hôte, savoir administrer celui-ci et s'embêter à générer des sous-images par type de formats. Vous pouvez vérifier si une image s'est bien chargée par un événement javascript comme moi mais ça sera débile.

Cette table rassemble les infos sur tous les formats d'images qui furent un jour susceptibles d'être gérés par un navigateur, avec en bonus un test. Pour les fans du TL;DR, cette table leur fera oublier qu'ils ont jamais cliqué Sommaire de ce billet

Format	Type	Couleurs	Transparence	Animé	Support*
* Je parle du support navigateur. Le support serveur peut varier énormément : je doute que Facebook supporte du SVG comme photo de profil. Il ne faut pas se voiler la face.
xbm	bitmap lossless	n&b	non	non	oublié
xpm	bitmap lossless	256	non	non	oublié
pbm	bitmap lossless	n&b	non	non	oublié
pgm	bitmap lossless	256	non	non	oublié
ppm	bitmap lossless	16M	non	non	oublié
bmp	bitmap lossless	16M	OUI	non	oublié
gif	bitmap lossless	256⚠	binaire	OUI	SÛR
ico	bitmap lossless	16M	OUI	non	répandu
jpeg/jfif	bitmap lossy ⚠	16M	non	non	SÛR
jpeg2000	bitmap lossy	16M	OUI	non	peu répandu
jpeg XR	bitmap lossy	281Bn	OUI	non	MSIE 9+
tga	bitmap lossless	16M	OUI	non	oublié
png	bitmap lossless [edit]	281Bn	OUI	non	SÛR
mng/jng	bitmap lossless	281Bn	OUI	OUI	oublié
apng	bitmap lossless	281Bn	OUI	OUI	Firefox
vml	vectoriel	css	oui	non	oublié
svg	vectoriel	css	OUI	oui ⚠	tous les modernes
webp	bitmap lossy ou lossless	16M	OUI	oui ⚠	Chrome, Safari

La famille xbm (X BitMap) et ses enfants xpm,…

On en a déjà parlé dans le premier chapitre de cette série. Tout comme les formats .pbm et affiliées, cette famille de formats ésotériques en texte et sans aucune compression avait surtout un intérêt pour le développement logiciel, mais strictement aucune pour la transmission réseau. Le support de ces formats fut retiré de la plupart des navigateurs.

Si ça charge, votre navigateur a du code antique. source FileFormat.info

Pour info, vous pouvez l'ouvrir avec un éditeur de texte : c'est un bête fichier source .c contenant une définition de tableau. Pang.

Le bmp : device-independent BitMaP format

C'est un antique format d'image principalement utilisé pour l'usage d'un interface graphique, comme pour la famille XBM. Et si je vous dit qu'il fut popularisé par Microsoft, n'en jetez plus par les fenêtres.

Testons… Oui, ça peut surprendre, le format est encore bien supporté.

Microsoft à l'époque de sa splendeur : 600ko pour 500×400 en 256 couleurs, les malades…
source victori.uploadbooth.com

Le format d'image accepte à la fois un mode paletté (256 couleurs et moins) et un mode true-color (au moins 16 millions de couleurs) pouvant accepter l'alpha-transparence (au moins 256 niveaux de transparence). L'image peut être compressée sans perte, mais uniquement en mode paletté et le support dépend des bibliothèques. La plupart des bmp sont donc non compressées et atteignent alors une taille délirante. C'est pour ça qu'il n'a quasiment jamais été utilisé sur le web. Même par Microsoft.

Pas fous.

Le gif : Graphic Interchange Format

Pour des raisons juridiques et de neutralité politique, je me refuse de prendre position entre les deux prononciations possibles de GIF, alors /ˈɡɪf/ ou /ˈdʒɪf/, vous choisissez à vos risques et périls : c'est vous qui lisez dans votre tête.

Le gif est un format d'image lossless paletté, qui ne peut accepter que 256 couleurs maximum (moins une en cas de transparence), même s'il existe un mode ésotérique true-color que je ne vous recommande pas. La compression d'image utilise l'algorithme LZW qui n'est devenu réellement libre d'usage qu'en 2003, puisqu'il était l'objet d'un brevet détenu par Unisys. C'est ce risque de taxation qui a mené par la plupart des acteurs du web à la recommandation d'utiliser le format PNG à sa place, nettement plus performant.

La première version de ce format, appelé GIF87 date de… 1987 et a été originellement conçu par CompuServe un service fournisseur de services BBS, c'est-à-dire un ancêtre de FAI à portail captif. Deux années plus tard est proposé l'extension GIF89a, qui permet d'inclure des animations, d'avoir une transparence binaire et même un affichage progressif par entrelacement. Ce format a fait pendant 15 longues années le bonheur des publicitaires qui ont commencé avec un site sur GeoCities avant qu'ils nous les brisent menues avec la daube Flash (hehehe).

Non mais arrêtez de cliquer cette image, c'est juste un exemple.

À noter que l'animation en gif comporte plein de subtilités comme un compteur de boucles, l'animation réduite d'une région et peut même permettre d'afficher plusieurs palettes, dépassant les 256 couleurs simultanées théoriques. Le regretté Microsoft GIF Animator permettait de jouer avec toutes les subtilités du format. Actuellement, les logiciels graphiques comme Photoshop ou Gimp jouent sur les empilements de calques mais ne proposent pas ces options avancées (mais certains artisans nous émerveillent quand même). Et ayons une pensée émue pour ces logiciels qui transforment des sections de vidéos en gif animés prêts à poster sur son tumblr.

Malgré son âge vénérable, gif reste le moyen le plus terriblement efficace pour une image animée qui ne soit pas une vidéo.

Le ico : format d'icône de Microsoft Windows

Le format ICO est arrivé avec MS-Windows 1.0 en 1985 pour stocker les curseurs de souris et les icônes du bureau. Il a subit de multiples révisions dont une ré-écriture sérieuse pour Windows 95, qui propose notamment une propriété très utile : la gestion de multiples dimensions. Microsoft a constamment fait évoluer son format d'image propriétaire. De simple encapsuleur du format BMP, il a accepté par la suite le bien plus performant format PNG.

Ce format d'image est apparu dans le web avec l'arrivée des favicon dans MSIE 5. Contrairement à une croyance maintes fois répandue, il était compliqué de faire apparaître cette image dans ce navigateur : le favicon n'apparaissait dans MSIE si et seulement si le site de la page était parmi les marques-pages (accessoirement, une bonne mesure anti-fishing). Cela a donné lieu à des quiproquos immenses dans la plupart des e-web-@gency qui ne comprenaient pas pourquoi le site du client n'affichait pas son logo contrairement à Wanadoo. Qu'est-ce qu'on a ri en repensant aux heures à expliquer ça au client.
Facepalm.
Ce comportement fut simplifié dans MSIE 7 car Firefox et Safari affichaient systématiquement les favicons.

Des favicons dans MSIE 7 en barre d'adresse, onglets et marques-pages.
source Microsoft, réenregistré en .ico pour test

Si supporter ce format était important pour le chargement des /favicon.ico des sites, il devint un héritage obsolète avec l'arrivée de la balise <link rel="shortcut icon" />. Car cette balise avait plein d'avantages :

sortir l'image de la racine du site et de son adresse fixe,
la rendre contextuelle à la page appelée (par exemple avoir des favicons différentes si vous êtes en vue publique, en accès adhérent ou en mode administration),
ne pas être liée à un format d'image spécifique, mais permettre gif, jpeg ou png (et souvent le png est le préféré).

Sauf qu'on a enterré le .ICO beaucoup trop vite ! Ce format d'image est le seul à pouvoir supporter de multiples résolutions en un seul document (si on excepte le mode miniature/preview du jpeg, qu'aucun navigateur ne gère), et à résoudre le problème actuel des résolutions possibles d'écrans. Il est même nettement plus élégant que la soupasse des balises possibles. Alors que Microsoft était connu pour conduire à l'inflation de la <head></> dans des proportions délirantes, il avait la réponse à un problème qui s'est posé par la suite avec <link rel="icon" sizes="" /> où l'attribut sizes="" sur certains sites va du 16×16 au 128×128 en passant par les ésotériques 57×57, 72×72 et 114×114 demandés par Apple ! Si on veut être complet, ça fait 8, donc 7 fois trop.

Ce format d'image est encore supporté par pas mal de navigateurs et peut marcher dans la balise <img >. Si vous développez le N^ième format d'image, reprenez-en l'idée des différentes résolutions stockées en un seul conteneur, bien plus facile à administrer.

Dans l'exemple ci-dessus, le document comporte 10 images, détaillées plus bas. Mais laquelle votre navigateur affiche-t-elle ? Firefox va afficher celle en 16×16 par 16M, qui est la dernière du document, tandis que Chrome va afficher celle avec la meilleure résolution. C'est dommage : .ICO marche bien, mais c'est le bordel pour savoir laquelle sera affichée si on n'y fait pas gaffe.

Décomposition du fichier précédent dans Gimp :
Les 10 images y sont superposées en calques (infos icotools) :

Calque	Largeur	Hauteur	Couleurs	Transparence
1	48	48	16	binaire
2	32	32	16	binaire
3	16	16	16	binaire
4	48	48	256	binaire
5	32	32	256	binaire
6	16	16	256	binaire
7	256	256	16M	alpha
8	48	48	16M	alpha
9	32	32	16M	alpha
10	16	16	16M	alpha

La famille Jpeg : Joint Photographic Expert Group

Comme son petit frère le MPEG, l'acronyme JPEG désigne non pas un format mais le comité qui l'a conçu. Il existe d'autres formats issus de leurs travaux, dont le JBIG2 dont j'ai déjà causé ici, l'Exif utilisé par les appareils photos, et plein d'autres. Pour le web, nous utilisons le format JFIF (Jpeg File Interchange Format) et c'est lui qui est le plus souvent improprement appelé Jpeg ; mais dans les faits, vous pouvez aussi balancer du Exif directement issu d'un appareil photo, ça passe quand même malgré les différences de description.

Son support dans les navigateur arriva en 1994 dans Netscape Navigator pour les besoins d'envoi d'images plus importantes qu'en GIF et sans avoir besoin d'une reconstruction parfaite. Comprenez : des photos.
Le jpeg vient du monde de la PAO et de la retouche photo. Il ne gère pas d'animation, mais peut supporter 16 millions de couleurs simultanées, ceci au prix d'une compression lossy, i.e. à perte des détails (Il existe un mode lossless, le jpeg-ls très rarement supporté par les navigateurs). La compression par cosinus discret consiste à diviser l'images en carrés appelés macroblocs, en général de 8×8, puis d'appliquer des coefficients sur des vaguelettes d'interférences. En gros et en fonction des marées.

Exemple de compression de plus en plus grossière en allant de la gauche à l'extrême-droite,
réalisé sans aucune allusion politique. source Wikipédia

Il y a (parmi les paramètres) 12 niveaux de taux de compression possibles appliquées sur l'ensemble de l'image, avec des particularismes spécifiques notamment chez Photoshop. certains éditeurs graphiques présentent en pourcentage de qualité. Il se peut qu'un fichier produit soit plus gros que celui à un pourcentage supérieur. Personnellement, j'utilise une qualité à 85% en sortie de Gimp pour mon blog. En dessous de 75%, les vaguelettes peuvent apparaître sur les aplats primaires, avec une nette dégradation des contours sur le rouge qui a alors du vague à l'âme.
J'ai récemment parlé d'une méthode pour optimiser le taux de compression par région sur une image globale et que cette astuce est parfaitement rétro-compatible, elle mérite donc votre intérêt si vous travaillez sur des sites à fort traffic.
[edit] voir commentaire sur l'implémentation libre MozJPEG

Parmi les modes moins connus du jpeg, il y a la possibilité d'enregistrer une image purement monochrome (pour les amatrices gourmandes, ça fait 256 nuances de grey…), et même des modélisations de couleurs qui ne sont pas en RGB traditionnel, non recommandées pour le web :

le CMYK (Cyan Magenta Yellow blacK ou en céfran CMJN, Cyan Magenta Jaune Noir), modèle standard pour l'imprimerie,
le YUV (Luminance/Chrominance, dont il existe de multiples variations) qui sert surtout en production télé ou cinéma.

Vous pouvez en tenter un, mais il n'est pas garanti que les navigateurs le supportent, ni que toutes les couleurs de l'espace RGB puissent être reproduites, de la même manière qu'on ne peut reproduire que difficilement les couleurs impossibles.

Le format a connu une évolution pour le web : tout comme l'entrelacement du GIF 89a, le mode jpeg progressif permet d'afficher l'image de plus en plus finement pendant le chargement de la ressource. Il se trouve (et je pouffe car d'autres me stipulaient le contraire) que ce mode n'a jamais été supporté par MSIE. Il est donc à éviter car il alourdit inutilement le document créé.

Le JPEG a eu aussi sa période de menaces de brevets et de patent-trolling : En 2002, la société Forgent/Asure a soutenu mordicus avocatusque qu'elle détenait des brevets sur le format d'image et jusqu'à l'expiration du brevet litigieux en 2006 menaça de procès plusieurs entreprises. Un format alternatif pour le web, le MNG/JNG, était disponible pendant la période d'incertitude mais mourrait déjà.

À l'aube du nouveau millénaire, une mise à jour du format et de l'algorithme fut proposée avec jpeg2000. Celui-ci propose de sérieuses mises à jour du format dont le support de la transparence. Il n'a pas été déployé dans tous les navigateurs puisqu'il y a une licence à payer, mais aussi parce que jpeg2000 est très complexe à implémenter et sujets à des bugs sur certains logiciels.

source Union Internationale des Télécommunications

Microsoft a par la suite proposé au groupe JPEG de normaliser son format propriétaire (Windows Media) HD-Photo développé en 2006. C'était leur joyeuse époque de noyautage des standards comme l'infâme scandale OOXML.
Polémique à part, le format JPEG-XR (pour extended range) propose notamment un nouvel algorithme de compression, une plus grande plage de couleurs (16 bits par canal, soit 65536 nuances par primitive chromatique, soit 281 billions de couleurs possibles) et d'autres extensions. Mais seul Internet Explorer versions 9 et suivantes supportent ce format en tant que navigateur. De nombreux brevets protègent et rentabilisent ce travail, et vu que ce format est ultra-propriétaire, il est très peu probable qu'il soit lu par les autres brouteurs avant une vingtaine d'années.

source Union Internationale des Télécommunications

Le png : Portable Network Graphics et ses enfants reniés

Le PNG a été conçu pour répondre au gif, ses limitations techniques (la transparence binaire et un nombre de couleurs trop limités) et juridiques (le brevet de compression LZW). C'est un format conteneur qui peut avoir plusieurs chapitres dont une description d'image bitmap. Son algorithme offre une compression sans pertes, supportant le palettage jusqu'à 256 couleurs, 16 millions voire 281 billions (2¹⁶ par canal primaire) de couleurs, une opacité par demi-tons et même une vraie alpha-transparence.
Cette dernière a été mal gérée par MSIE 6, qu'il repose en paix.

Le logo officiel de PNG. source libpng

Preuve que le PNG est un vrai format conteneur dans la lignée du défunt IFF, il était le format de sauvegarde favori du logiciel de dessin Macromedia Fireworks, qui y embarquait aussi les primitives vectorielles de tracé. Le bloc de données supplémentaire spécifique était ignoré par les navigateurs et n'affichait que la première image du bloc.

En 1996, une partie de l'équipe qui a créé PNG en proposa une évolution, le MNG (Multiple-image Network Graphic). Celle-ci devait notamment permettre les animations, proposer des nouveaux codecs, un mode loosy (le JNG, suite à des incertitudes juridiques sur le jpeg) et plein d'autres choses. Elle n'a jamais vraiment pris faute de supporters et surtout une mise en œuvre largement trop complexe. Le MNG fut abandonné en 2006.

source libmng testsuite

De cet échec, un autre format animé a émergé, APNG. En 2004, la Mozilla Foundation venait d'abandonner le format MNG devant la taille démesurée de la bibliothèque pour la décoder (les fous, c'était au début de leur support du SVG). Stuart Parmenter et Vladimir Vukićević avaient besoin de stocker les animations de l'interface graphique du navigateur Mozilla dans un format pratique et moins frustre que le gif. Il revirent au PNG en ajoutant un minimum pour assurer les animations et en assurant une rétro-compatibilité, dans la même idée que le PNG Fireworks.
Échaudés par l'abandon de MNG par Mozilla, apng ne fut jamais reconnu par le groupe PNG. Pourtant ce dérivé a été officiellement inclus dans des standards comme le DAB+. Va comprendre…
Même si Firefox est le seul navigateur qui en supporte complètement l'animation, un navigateur qui lit le png mais n'utilise pas les informations d'animation peut afficher la première image en fixe comme vous pouvez le tester ci-dessous :

Hommage à L'Ellipse aussi dite Auréole d'Étienne Robial. source littlesrv.ca

À noter que la page officielle de ce format propose plein de ressources pour créer des animations bitmap (apng mais aussi gif et webp)

[edit] : Il est possible de faire du PNG lossy.

Le vml : Vector Markup Language

Ce format vectoriel est purement propriétaire, proposé et uniquement supporté par Microsoft. Ce type de document fut introduit avec MSIE 5.0 mais ne trouva pas de supporters en dehors. Il fut retiré de MSIE 9+ par Microsoft et officiellement enterré.

En fait, je suis même pas sûr qu'il fusse un jour invoquable via <img />

Le svg : Scalable Vector Graphics

Réagissant à la nature fermée du format vml, en 1998, des constructeurs de navigateurs se réunirent au sein du W3C pour former le groupe de travail SVG et construire un format vectoriel ouvert et normalisé.
Le svg est un format purement vectoriel à la notation xml. Il permet les animations, mais son usage dans la balise <img /> ou via css interdit les interactions. Nous ne parlerons pas dans ce billet de l'inclusion en tant qu'<object></> ou embarqué dans le html.

Une partie de billard, qui pèse 1,5ko, animée en smil. source bogotobogo.com

En tant que format purement vectoriel, le svg n'est pas affecté par l'effet de zoom flou qu'on trouve en HiDPI comme les écrans Retina™, en imprimant le document ou en forçant une sous-résolution. Qui plus est, étant un format de document xml, étant stylé par css et ayant donc des blocs nommés id="", il est possible de n'afficher qu'une portion de l'image en indiquant une ancre dans son url, ce qui en fait un hack natif aussi intéressant que le sprite-tiling : le svg stacking.

SVG reste boudé à cause de son support très tardif dans MSIE ; en dessous de la version 9, point de salut sinon via les plugins. Si vous ne contrôlez pas le serveur, reste l'usage de hacks disgracieux comme les commentaires conditionnels qui feraient dégainer Dirty Hacky sans sommation. Autre problème, le svg est comme pour xbm un fichier au code source texte descriptif et le côté très verbeux du xml peut produire des fichiers lourds malgré une compression gunzip pour le format SVGZ. Enfin, il y a la maîtrise ardue pour les graphistes même si Adobe Illustrator propose un export plus que valable depuis une décennie, et le fait que l'image est forcément d'origine purement numérique à la base.

Au rayon on est jamais déçu quand on y regarde de plus près, Parmi les bugs amusants que j'ai relevé pendant l'écriture de ce billet chez Mozilla Paris, j'ai découvert que sur Firefox les images en svg animées en javascript pouvaient avoir des petits soucis d'affichage, à la différence de celles en animations css (j'ai pas trouvé d'exemples) et en smil :

Une horloge de 4ko. source bogotobogo.com

… tandis que Chrome n'anime plus un svg s'il a été dimensionné de force par un attribut width="" ou height="". Ne pas craquer.

Le SVG a d'autres astuces, notamment l'application de filtres de transformations de couleurs, ou la création de flous, c'est l'équivalent du html appliqué à du dessin vectoriel. Hélas la complexité du format fait que certains chapitres ne sont pas forcément implémentés partout, il peut avoir quelques manques ou des petits soucis. Il est fortement recommandé d'exporter un groupe restreint de spécifications a.k.a. SVG Tiny.

Le webp

le webp (pour web picture) est un nouveau format conteneur d'images proposé par Google. Il peut compresser les images avec ou sans pertes et gérer l'alpha-transparence. Sous le capot, nous retrouvons l'algo de compression VP8 repris du format vidéo WebM, plus exactement la section définissant les images clés d'animation (Intraframes).

Ce qui tombe bien parce que le WebM est disponible pratiquement sur tous les navigateurs récents, exceptés MSIE et Safari, leurs propriétaires militant pour la solution propriétaire MPEG qui a l'avantage de ne pas être disponible en logiciel libre (hors Europe). Cela va de soi.
Donc les navigateurs qui intègrent déjà une bibliothèque de décompression logicielle pour ce format vidéo doivent pouvoir prendre facilement en compte le format pictural. Mais dans l'immédiat, il est uniquement supporté par Chrome et Opera.

Une rose, en alpha-transparence loosy. source site officiel

Son intérêt est de proposer une compression lossy (avec pertes) bien plus efficace que le jpeg, ce dernier commence à accuser ses quasi 25 ans d'existence. Sur les chiffres purs, effectivement on y gagne mais sur le plan perceptif, les gros inconvénients des compresseurs vidéos de cette génération sautent aux yeux.

Hélas, sur les comparatifs aimablement fournis par l'équipe de Google, ils se gardent de faire des comparaisons honnêtes avec le format PNG et encore moins sur l'APNG, les supporters de apng l'ont fait. Soit c'est un oubli, soit une volonté de segmenter le marché ; cette dernière possibilité serait bien dommage. Or on a une compétition évidente entre navigateurs et codecs pour fusionner jpeg et apng, seulement IMHO ni jpeg-xr, ni webp ne semblent des solutions raisonnables : pas de fallback simple en cas de défaut de support et un écosystème trop restreint. Oui, il existe des techniques de support, mais objectivement overkill.

Eh mais attends... et si je mets une vidéo ?

Quitte à reprendre le raisonnement du webp, faisons l'exercice totalement stupide de mettre en source une vidéo ?

Est-ce que la première image va-t-elle être montrée en still ? Après tout, sur certaines set top box comme les Freebox, il est possible d'envoyer une image mpeg2 en fond d'écran. Voici les trois formats actuellement acceptables sur les navigateurs web :

mpeg 4
ogg theora
webm

Faute de temps, je vous laisse vous-même faire les tests. Je ne fais pas de pari… mais peut-être qu'un jour…

Prochaine vignette

Vous pensiez qu'on était au fond du bizarre ? Perdu ! <img /> a encore bien d'autres secrets…

Manuel en ‹img /›

Da Scritch — 2014-04-09T16:11:00+02:00

Comment est appelé, paramétré, configuré la balise <img /> dans le source html. Milles et une petites plaisanteries, hacks malheureux ou astuces qui furent standards à un moment.
Webdev

Ce billet fait partie de la série en <img /> :

Histoires en <img />
Manuel en <img />
Ressources en <img />
Bricolages en <img />
Progressivement en <img />
Finesse en <img />
Propositions en <img /> / English version

On va aborder la balise <img /> dans sa sémantique en analysant ses attributs passés, présents et peut-être futurs.
Pour les fans du TL;DR, cette table leur fera oublier qu'ils ont jamais remarqué le lien Sommaire de ce billet sous le résumé ^^

Attribut	type	usage	origine
width	entier, en pixels implicites	déprécié, à éviter	HTML 2
height	entier, en pixels implicites	déprécié, à éviter	HTML 2
longdesc	url html	à éviter	depuis HTML 4
lowsrc	url image	obsolète
ismap	bascule	obsolète	HTML 3.2
usemap	id		HTML 3.2
crossorigin	bascule	déconseillé	HTML 5
alt	texte	obligatoire
src	url image	obligatoire
srcset	scénario	en tests	brouillon

Oui, il n'y a pas tout, puisque ce billet n'a pas pour but d'être exhaustif, mais de farfouiller et d'annoter ce qui s'est fait. J'ai donc volontairement écarté les attributs purement “design” (align="", hspace="", vspace="", border="") relevant de la CSS.

Quand même, soyons sérieux.
Quant à srcset="", il mérite vraiment son chapitre à part ~~tellement que les charges sont lour~~ non je vais pas spoiler son affaire ;)

Pour illustrer les exemples, j'ai pris une carte des régions de France parce que quand j'ai commencé cette suite d'article, j'ignorais que Manuel Valls avait mis dans son programme gouvernemental la réforme de cette ressource Wikimédia...

width="" et height=""

Il fut une époque où les modems étaient tellement lents que l'image d'une page pouvait se charger après plus d'une minute. Il est encore une époque où des rigolos mettent des images distantes dans leurs e-mails en html, et qui par défaut ne sont plus chargées automatiquement. Pour éviter des sautes d'affichages à la lecture (aujourd'hui, nous dirions repaint), on indiquait la dimension de l'image attendue avec les attributs width="" et height="". Un espace blanc, élégamment cerné de noir et d'une icône d'image indiquait qu'une illustration allait arriver.

…peut-être…

…bientôt…

Le principal souci de ces attributs est que la transformation homothétique n'est pas forcément explicite (cela ne marche que si un seul des attributs est mis, et encore…). Et comme à l'époque, il était très rare de trouver des scripts qui transforment les tailles des images côté serveur. On avait donc un usage qui amenaient à de mauvaises pratiques : la sur-résolution.
Combien de fois avez-vous eu des clients qui envoyaient des images de 2000×1600 pixels, qui étaient “réduites” en front avec width="100" height="100" ? En plus de mélanger bêtement présentation et sémantique, ces attributs avaient aussi le souci de la mise à jour des ressources : Si l'image était mise à jour, il était pas rare que les dimensions dans les balises qui l'appelaient n'étaient plus bonnes, donnant un aspect distordu. Surtout qu'à l'époque, les algorithmes des navigateurs pour redimensionner par interpolation étaient assez… rudes… C'était vraiment pas beau.

Il y a 5 ans, nous avions encore ce rendu crisp souvent ignoble que je tente d'émuler. Les navigateurs modernes adoucissent les images en appliquant un flou plus ou moins heureux.

Oui, ces attributs avaient disparus pour de bonnes raisons, mais quelqu'un a dit Time And Relative Dimension In Space et elles sont revenues, entre autres pour la balise <svg></>, et aussi pour la sur-résolution.

D'une manière ironique, nous revenons à ces pratiques de sur-résolutions en css pour gérer les navigateurs aux rendus à haute-densité (high-DPI comme disent les pros, Retina™ comment disent les appeuleumaniaques), car l'autre solution c'est faire du javascript à foison pour découvrir via window.devicePixelRatio quelle est la différence de taille entre les pixels physiques et les pixels logiques. Oui, c'est à devenir fou.
Un exemple de méthode de sur-résolution est de prendre une image exportée en jpeg à un taux de compression plus agressif (genre 70%), mais deux fois plus grand que la dimension souhaitée, et de la réduire avec height="50%".
Scandaleux…? Je parlerai de srcset="" plus tard.

longdesc=""

longdesc="" doit renvoyer vers une page html qui comporte une description complète du document. Par exemple, si on prend la carte de France, quand elle est citée dans la Wikipédia, elle peut (ce n'est pas systématiquement le cas) comporter cet attribut avec un lien vers la page descriptive correspondante sur Wikimedia. En fait, selon une étude de 2007 du WHAT-WG sur la pertinence de cet attribut, il est noté que les sites Wikipedia et ceux basés sur son CMS MediaWiki sont les consommateurs quasi-exclusifs de cet attribut.

Pour la carte de France choisie en exemple, le code devrait être :
<img src="http://dascritch.net/…/.1404-Img-CarteDeFrance_m.png" longdesc="http://commons.wikimedia.org/wiki/File:France_fond_de_carte_27_r%C3%A9gions.png"…

Un lien devrait exister si l'image n'est pas déjà embarquée dans un lien

Étonnement, cet attribut devrait plus être utilisé comme métadonnée pour l'indexation et la gestion documentaire. Mais à relire le standard actuel, il y est plus décrit comme un élément d'accessibilité.

Et justement, en termes d'accessibilité, cet attribut s'est montré catastrophique. Dans une discussion du groupe de travail de feu-XHTML2, un des participants fait remarquer que le logiciel de lecture d'écran JAWS ouvre le contenu de longdesc dans une fenêtre à part, ce que les bloqueurs de pop-up bloquent !

À l'usage, cet attribut tombe dans tous les défauts des métadonnées séparées de leur contenu : sa maintenance est souvent oubliée donnant ainsi des informations erronées si elle n'est pas automatisée. Dans ce cas, MediaWiki fait un excellent boulot en proposant le versionning, les origines du documents, les url locales y faisant référence et un décodage des métadonnées embarquées dans l'image (Tiens, ça donne de super idées de plugin pour dotclear, ça…).
Et si on pourrait croire que cette balise est taillée pour la Wikipedia, c'est faux ! Dans l'esprit du ~~législate~~ normalisateur, l'idée qu'il avait était de proposer une description de l'image plus longue que la balise alt="". Par exemple, si votre image représente un camembert de données ou des graphes, le longdesc devrait pointer vers un document proposant le tableau originel de données.

L'usage recommandé est de l'oublier et de plutôt s'intéresser à l'attribut aria-describedby="". La valeur attendu par cette balise est l'id d'un élément de la page, très probablement son <figcaption> </> si vous avez utilisé cette structure. Comme ceci :
<figure> <img src="http://dascritch.net/…/.1404-Img-CarteDeFrance_m.png" aria-describedby="figdescription" alt="[…]" /> <figcaption id="figdescription">…

ÀMHA une telle structure est inutilement verbeuse si justement on utilise le balisage sémantique <figcaption> </>…

lowsrc="https://dascritch.net/post/2014/04/09/"

J'explique en détails le fonctionnement de cet attribut dans le chapitre consacré au chargement progressif.

lowsrc="" permet le chargement rapide, en attendant la grooooosse ressource. C'est une fonctionnalité tellement obsolète qu'on peut dire qu'elle est désuète voir qu'elle n'existe plus. Bon, certains ne sont pas encore au courant, mais de la part de sites comme W3Schools, vous vous attendiez à quoi ?

Ceci dit, si nous avons la possibilité d'utiliser le stylage en css pour mettre une image le temps de charger la ressource, il est difficile d'appliquer cette solution individuellement pour chaque balise. Oui, bien sûr qu'on peut avec style="background-image:url(…, mais vous ne ressortiriez pas vivant de cette pièce si je vous y surprend…

ismap=""

Cet attribut était une idée de bidouillage : celui de passer la zone cliquée sur une image, quand elle est embarquée dans un lien. Les paramètres sont passés alors en paramètres GET dans la cible du lien, et donc doivent être traités par le serveur. Je vous invite à voir ce que ça fait en dessous :

Cette magnifique carte de France par Rosss pour WikiCommons

Comme vous pouvez le voir en survolant à la souris ou en cliquant l'image, la cible du lien est alors complété par deux paramètres GET, séparés par une virgule et sans association. On a donc un lien http://cible?abcisse,ordonnée. Par exemple, si je clique (vaguement) sur Toulouse, j'ai un #attr_ismap?210,320. Si vous aviez prévu d'utiliser d'autres paramètres GET dans le lien, vous êtes marrons.

Ce système ne s'est pas montré très heureux à l'usage. Le simple fait que la gestion du point géométrique appuyé soit géré côté serveur en rendait sa maintenance très peu aisée ; l'attribut usemap="" s'est montré plus simple, car la définition des zones est alors remontée côté client.

usemap=""

Selon les standards d'accessibilité, ismap="" doit être remplacé par usemap="". Cet attribut a une particularité : il ne doit pas être utilisé dans une <img /> fille d'un <a href=""> ou d'un <button>. Oui, à l'inverse de ismap=""… Dans les faits, je m'en sers même pas.

La valeur de l'attribut est notée comme un adressage id (c'est-à-dire commençant par un #), mais est posée par un name="". Ce qui n'est absolument pas la même chose. L'élément pointé est une balise bloc <map name=""></> qui contient un ensemble de balises <area shape="" href="" /> décrivant des zones géométriques et les liens qui leur sont associés. Voici justement l'exemple pour l'exemple du dessous :


<map name="usemap_demo">

   <area shape="rect" coords="0,0,460,303" href="?nord#attr_usemap" title="nord">

   <area shape="rect" coords="300,303,460,420" href="?vantards#attr_usemap" title="vantards">

   <area shape="rect" coords="0,303,123,420" href="?inconnu#attr_usemap" title="inconnu">

</map>

<img usemap="#usemap_demo" />

Le lien est un vrai lien indépendant avec une url complète. La description de <map></> et des <area /> étant très complexe, je vous laisserai lire la doc idoine sur le sujet. De sa version d'origine (HTML 3.2) à la plus récente. À noter que les zones acceptent l'attribut title="", que les vieux qui en sont à l'informatique point'n'click non-digitale (donc à la souris) verront les informations en survolant l'image de démo ci-dessous :

À toi qui me lit, sache que oui, cet attribut m'a fait adorer Dreamweaver de Macromedia. Au nombre de fois que j'ai fais du détourage de zone avec cet outil, je peux t'assurer qu'il m'a sauvé au moins 3 après-midi. Et je le dis sans honte : En cette époque obscure où le style était dans les attributs, la mise en page en tables et les interactions dans des <a href="javascript:…, on n'avait pas mieux.
On était en 2000, et depuis j'ai appris à m'en méfier.

Au final, aucun de ces deux attributs ne furent pérennes. Les différents remplacements en javascript se sont montrés bien meilleurs et inclure du svg via notation xhtml ou plus tard par la balise <svg></> dans le html s'est montré largement plus pratique et prometteur.
Imagineriez-vous encore une carte à la google map qu'avec des liens cliquables ?

crossorigin=""

Si vous servez votre site en protocole https:// et que la source de votre image n'est pas sur le domaine, les mesures prophylactiques du navigateur lancera une alerte, soupçonnant votre site d'être injecté ou corrompu. Ou alors ignorera la source et donc n'affichera que le alt="". À moins que vous ayez déclaré en entête http (HSTS et CSP) que le site externe fait partie des ressources autorisées, vous pouvez encore le faire après coup

Sur le terme sécu, cela ne protège en rien d'une injection. Je trouve même cette balise comme contre-productive : il ne faut jamais faire de hot-link vers un site que vous ne maîtrisez pas. Quand je vois qu'un site à fort traffic a fait un lien direct vers une image, je remplace à la volée la ressource par un truc ignoble qui devrait faire fuir tout le monde. Et je vous encourage à en faire de même.

alt=""

L'attribut alt="" est strictement obligatoire pour la moindre <img />, mais pas mandatoire.

Cet attribut a pour charge de proposer un contenu alternatif (eh oui) si la ressource met du temps à être chargée, si elle est inutilisable ou si le client web ne peut afficher d'image. Ce dernier point fait qu'il est très utile voire primordial : les synthèses vocales, les tablettes brailles, la plupart des crawlers et les navigateurs en mode texte vont s'en servir. Il y a donc un réel intérêt à le renseigner, plutôt qu'entendre un image quand elle n'y est pas (thank you, captain obvious).

La manière d'écrire son contenu a longtemps été sujet à des discussions sans fins, et il est enfin proposé par le W3C des recommandations, claires pour la plupart des cas de figures, allant du logo contenu un texte, un diagramme ou une illustration qui accompagne un texte.

D'où ma question :
maintenant que nous maîtrisons les CSS pour ne plus appeler d'images à tort et à travers, que nous avons les webfonts ce qui permet de répondre aux demandes client de “design” les plus farfelues, et le svg pour aller encore plus loin... nous n'utilisons plus que alt="" pour du réel contenu, les images appelées représentent très rarement du texte écrasé. Bref, nous laissons le contenu vide.
De nos jours, alt="" est réellement important pour l'accessibilité, mais nous mettons de plus en plus souvent un contenu vide. Est-il temps de faire évoluer les navigateurs et de proposer qu'alt="" soit implicite ?

Je sais qu'il y aura toujours le problème de l'existant, mais n'est-il pas temps de commencer ?

src="https://dascritch.net/post/2014/04/09/"

src="" appelle la ressource. Évidemment, cette balise est obligatoire.

Celle-ci peut-être une URL, locale ou distante, ou alors une ressource interne, comme pour les e-mails ou dans certains cas des emoji (mais c'était une méthode propriétaire d'un monde révolu, oubliez-le). À noter que dans les URL possibles, il y a le mode data:[…] qui permet d'embarquer dans l'URL le contenu de la ressource. Honnêtement, je ne le recommande pas des masses.

De toutes les balises audiovisuelles, c'est la seule qui contrairement à ses collègues comme <audio></>, <video></> ou <object></>, ne supporte pas de gestion de dégradation élégante native, ou fallback, c'est-à-dire d'une solution de repli à part afficher le contenu de l'attribut alt="". Cela est dû à la nature auto-fermante de la balise, un peu comme <embed /> et raison principale pour laquelle je déconseille toujours d'utiliser cette dernière.

Il y a actuellement des propositions de normalisation, principalement pour une gestion native du High-DPI (ce qui est commercialement appelé un écran Retina™). Le problème est que le débat sur sa syntaxe n'arrive pas à obtenir à la fois un consensus rétro-compatible et ~~futureproof~~ à l'épreuve du temps. Personne n'est convaincu par les propositions actuelles. D'ailleurs, l'objet DOM ne propose pas de méthode de support de contenu, là ou <audio></> ou <video></> permettent de savoir si le navigateur supporte un codec particulier comme ogg vorbis ou h264. Ben non, impossible de le deviner avec <img></>, sinon en chargeant une image à un format, et de tester en javascript si elle a été chargée, affichée ou non.

C'est une contrainte importante à savoir si vous décidez de pointer une ressource dans un format qui n'est supporté que marginalement. Et j'en parlerai justement dans le prochain chapitre.

Après le ‹Html› sur table

Da Scritch — 2014-03-26T09:10:00+01:00

Pour ceux qui se sont désistés ou qui n'ont pas pu y venir, non pas un résumé des débats, mais de l'esprit qu'on voulait atteindre : Reparlons front code entre différents spécialistes.
Sortons

La soirée annoncée sur ce billet est passée, et a été une bonne surprise sur les échanges et nos conclusions.
D'abord, je dois remercier immensément l'espace de co-working Tau de m'avoir fait confiance pour cette première soirée. Je leur en suis infiniment reconnaissant.

Ensuite il faut que je remercie les autres participants (Alain, Antoine, Benoît, Flavien, Pascal, Postite). Des profils très divers allant du graphisme au développeur issu du jeu vidéo, c'était justement le but de cette soirée. Et finalement, il n'y a même pas eu de réticence à montrer du work in progress pour justement chercher une meilleure voie. Je trouve dommage que nous n'ayons pas eu de profil UX ou Product Owner.

Sur chaque page ou cas que nous avons abordé, on a eu des débats franchement intéressant, qui allaient de la gestion des polices ou des éléments de formulaires par les navigateurs, des standards à venir (pointer-events) à la pérennité de certains outils à la mode, à la question des différents outils d'assistance à la lecture pour les personnes déficientes. En fait, on s'est rendu compte qu'aucun d'entre nous n'a testé justement un de ces outils, donc cela devrait être intéressant de faire une session avec.

La durée de moins de deux heures, suivi d'un pot est un format intéressant car il évite la lassitude et permet à d'autres de partir ou d'arriver en cours de soirée.

Mais surtout, il y a eu un réel plaisir d'échanger sur nos recettes, nos connaissances des moteurs et des standards. C'était vraiment cette idée là, discuter de ce que l'on sert aux navigateurs et du rendu, chacun avec le regard de nos connaissances, afin de parfaire notre culture générale.

Ce qui reste à perfectionner

Forcément, c'était très loin d'être parfait. Et comme je suis un pessimiste, voici ce que je pense devoir travailler pour la prochaine :

Peut-être changer de nom, mais BYOC front ne motivera jamais les graphistes, alors que c'est l'idée et le principe
L'annoncer avec plus d'une semaine de distance. C'est clair, j'ai vraiment été trop court suite à des problèmes de communication
Utiliser un outil comme Doodle ou Framapad pour la liste des personnes qui viennent. Je pensais être le seul à être rebuté par Meetup ou EventBrite, et en fait… non. Créer un compte est un acte chiant à chaque fois
Prévoir éventuellement un sujet général (les big menus, le scroll parallax), en tout cas, le préparer un minimum
Demander à chacun d'avoir les URL prêtes, plutôt que laisser chercher pendant 10mn (hein, Alain)
Remettre l'addon qui génère les QR Code à la volée, pour les tests sur mobiles
Éviter les discussions qui partent de chaque côté, je dois recadrer un peu mieux
Mettre la spécialité de chacun sur le pull, en fait nous ne nous connaissons pas des masses ^^
Ne plus faire commencer les sessions à 19h, c'est trop tôt
Penser à reparamétrer son PC, l'overscan du rétro-projecteur mange trop sur les bords et on ne voyait pas forcément la barre d'URL
Écrire les critères de chaque sujet (back office ou front office ? contexte de commande ou pet-project ? durée de vie ?)
Prévoir une espèce de vote sur chaque sujet, un peu dans l'idée des critères de ma série Dirty Hacky, en ajoutant des critères de lisible, accessible et beau

L'organisation est minimale, car je ne veux pas que cela soit trop contraint, que chacun garde sa spontanéité pour que les échanges soient riches.

Je pense que ça vaut le coup de remettre ça, peut-être avant Sud Web.

‹Html› sur table

Da Scritch — 2014-03-19T09:43:00+01:00

Une soirée d'ateliers after-work pour tous les professionnels du web. Mardi 25 Mars, amène ton code, après on ira boire pour en parler. Inscriptions en commentaires. Parlons de ce qui nous uni, le html. C'est le printemps, faut que ça bourgeonne !
Sortons

TL;DR : Mardi 25 à 19h chez Tau, 20 places maxi, inscrivez-vous ou sinon, rendez-vous après 21h.

Il fut une époque pas si lointaine où l'ensemble des spécialistes web de Toulouse se rencontraient, échangeaient, devisaient et festoyaient lors de soirées. On y croisaient des développeurs, des responsables projets, des administrateurs, des designers, des intégrateurs, des référenceurs,… En clair, tout ce qui fait qu'on peut construire un site web efficace, solide et de qualité.

Malheureusement, ces réunions n'existent quasiment plus. On a plus que des réunions “sectorielles” comme Café créa, Apéro Agile, Code And Coffee, Apéro Ergo, ToulouseJS (prochaine édition le 27) ou happy few. En clair, nous ne discutons plus entre différents corps de métiers. Je trouvais dommage que nous n'ayons plus eu d'occasions de se rencontrer entre professionnels pluridisciplinaires du web. En ayant fait la remarque, on m'a dit Do it yourself.

Dont acte

Mardi 25 Mars prochain, je propose une rencontre en deux parties.

La première partie commencera à 19h chez Tau (un espace de coworking très bien noté). Elle consistera en une revue critique de code : Amenez le code que nous parlons tous en commun, le code front que nous délivrons tous, à savoir html, css ou javascript. Les places étant limitées, il faut s'inscrire, annoncez-vous dans les commentaires, avec une idée du code que vous pourriez amener. Vous pouvez amener une portion de code, une page. L'idée est d'avoir du front-code (html, css, javascript) dont vous doutez et que vous souhaitez montrer. L'idée est de partager les expertises de nous tous, comprendre les intentions, discuter des astuces, trouver des améliorations et repartir chacun avec de meilleures pratiques.

Le nombre est restreint non pas par volonté de faire un cercle fermé ou une ambiance élitiste, bien au contraire, mais pour la sécurité et le confort dans la salle de réunion qui nous est prêtée. D'un autre côté, cela devrait favoriser le dialogue et le faire d'une manière plus amicale.

Par exemple, ma tentative redesign du formulaire de commentaires de mon blog en float labels. Mais vu que je ne suis pas web-designer, et si je sais faire un html sémantiquement correct, est-ce un travail cohérent en terme d'accessibilité, de praticité, ou même d'aspect ?

Ne soyez pas si sûr de produire un travail parfait : Notre secteur évoluant à un rythme effréné, et nos métiers étant tellement spécialisés, nous devons continuellement nous remettre en cause.

Et à partir de 21h, nous irons manger et boire dans le quartier. Pas de numerus clausus si vous nous rejoignez à ce moment-là. L'idée est de boire pour se rappeler que nous parlons travail le soir par passion !

With a little help from my friends

Les sociétaires de l'espace de coworking Tau ont accédé à ma requête en acceptant que j'organise cette expérience chez eux. Ce sont aussi mes amis comme Alain, Arnaud, Flavien, Joël, Michel, Nicolas et d'autres professionnels qui m'ont encouragés à l'organiser, à recombler ce vide. Et j'espère aussi y voir les organisateurs du HTML5 Meetup, afin qu'ils en parlent.

Alors ne me faites pas mentir : j'espère que vous viendrez nombreux, et qu'après 21h, nous discuterons standards, normes et qualité, un verre à la main.

Attention, pour la partie critique entre 19h et 21h, il vaut mieux s'inscrire à l'avance.

Inscrits

Qui	Spécialités	Amène du code
Da Scritch	php, js	au cas où
Wiko	front, intégration	peut être
Inateno	js, html5
Enguerran	le rougail saucisses
Flavien	php, html, css
EQroeil	php, js, css
Postite	haxe, js, flash
Ajoute-moi !

Mercis pour les 25 ans du web

Da Scritch — 2014-03-12T23:54:00+01:00

Le World Wide Web, la façade la plus visible d'internet, a 25 ans. C'est allé très vite.
Ma vie est une sitcom

Merci à vous Sir Tim Berners-Lee.

Merci de m'avoir donné de nouvelles passions, de m'avoir instruit à n'importe quelle heure sur n'importe quel sujet, de m'avoir diverti, de m'avoir milles fois émerveillé.

Merci de d'avoir fait découvrir le monde, de m'avoir informé, d'avoir permis à des peuples de s'émanciper et de l'avoir fait savoir, d'avoir donné de nouvelles technologies, d'en avoir fait émerger d'autres et de les avoir partagées sans retenue.

Merci de m'avoir permis de me lancer dans plein de nouveau projets, de m'avoir permis de communiquer mes joies, mes peines, mes belles découvertes, de construire, de concevoir.

Merci de m'avoir donné l'occasion de devenir mon propre média par mon blog, d'avoir aidé d'autres personnes à ouvrir le leur. Merci de m'avoir aidé d'autres à consolider leur entreprise, de construire leur activité, de collaborer ensemble. Merci de m'avoir donné de nouveaux métiers.

Merci de m'avoir fait rencontrer plein de nouveaux amis, de m'avoir aidé à en retrouver d'anciens, de m'avoir enfin fait rencontrer l'amour véritable, de me laisser garder contact même une fois rompu.

Merci à toi, Sir Tim Berners-Lee, de nous avoir donné de nouvelles vies

mais surtout… Merci à vous tous.