da scritch net works - Mot-clé - xml

Les joies de la communauté open-source

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

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

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

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

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

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

Arrive la ré-écriture de Firefox

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

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

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

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

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

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

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

Thank you a lot, Makyen !

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

Oh ! Une dernière chose !

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

Sniffeur d'ancre

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

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

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

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

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

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

Voilà pourquoi on met des ancres

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

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

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

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

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

Et ça donne ça :

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

Quitte à le faire pour Firefox…

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

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

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

Et c'est tout.

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

À venir

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

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

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

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.

Une image extraite du set d'icônes fournies dans Windows Vista. © Microsoft

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.

Json ou l'histoire d'une licence presque libre

Da Scritch — 2014-01-07T08:32:00+01:00

Une conférence en vidéo où en 20 minutes, je vais vous parler du JSON, de sa licence, de politique étrangère, d'activisme, d'humour, du Bien et du Mal. Et pourquoi un logiciel libre peut vous fliquer.
Sortons

La conférence a été enregistrée lors du Capitole du Libre édition 2013.
Le texte intégral est en-dessous

Le texte originel, in extenso

Je vais commencer ma conférence par un contrat entre vous et moi. Je vous en fait lecture, le fait que vous restez signifie que vous l'approuvez :

L'objet de ce contrat est la conférence intitulée « Json ou l'histoire d'une licence presque libre »
Cette conférence est une prestation unique dans le cadre de Capitole Du Libre édition 2013, adaptation en stand up comedy d'un billet publié sur le blog dascritch.net. Il est exécuté par moi, orateur, surnommé Dascritch, à votre attention, vous, auditeurs présents dans les locaux de l'N7 ce samedi ou regardant un enregistrement de cette performance. Ma prestation durera 20 minutes, énoncé de la licence inclus, et comportera des informations à peu près correctes.

J'ai le droit de me sentir offusqué si vous ne riez pas à une blague objectivement drôle ou que vous contestez des informations théoriquement instructives.
Vous avez le droit de reprendre cette conférence partiellement ou intégralement, uniquement si vous me créditez comme auteur et que vous n'en faites pas un usage commercial..

Étant donné que je ne suis pas juriste de formation, je ne puis vous garantir la totale exactitude technique de mes propos.
Étant donné qu'on est en fin d'après-midi, vous ne pouvez me garantir tout votre attention. Vous me promettez de ne pas interrompre ma performance autrement que des éclats de rires et des applaudissements sincères.

En cas de contestation de ce contrat, seul le Tribunal des Flagrants Délires de Toulouse est compétent sur le sujet. Le fait que vous restez dans l'assistance est une acceptation tacite de notre accord.

Fin du contrat. .....

Voilà, je viens de passer avec vous un contrat typique.
Ce contrat de licence, comme la plupart des contrats commerciaux, est grossièrement composé :

de Définitions : objet, parties( fournisseur, client ) , prestations
de Droits accordés et obligations entre les parties, de fournisseurs à clients et inversement
de Limites et interdictions entre les parties, jusqu'aux autorités juridiques compétentes en cas de conflit

Et quelque soit la prestation que vous faites, comme utiliser le système d'exploitation de votre ordinateur, vous avez forcément un contrat avec ces points.

Une licence engage ou dégage la personne qui construit, celle qui fourni le logiciel et celle qui l'utilise.
Par exemple, bien souvent, les licences libres dégagent le fournisseur de toute responsabilité en cas de soucis. C'est le fameux « this program is provided as is without any guarantee » qu'arbore fièrement toute licence libre.

Les licences peuvent être contaminantes. C'est crucial dans notre domaine qu'est l'informatique car on construit les logiciels avec des bibliothèques. Si vous utilisez une bibliothèque pour construire un logiciel, le contrat de cette bibliothèque peut dicter le contrat de votre logiciel. Ainsi, si je prends une bibliothèque en licence GPL, mon programme doit désormais être en licence GPL, et donc devient librement copiable.

Des licences, dans le logiciel libre, il y en a plein. Vraiment beaucoup. À tel point que régulièrement, tous les 4 ans, on a une polémique du genre « faut réduire le nombre de licences libres, créons en une nouvelle »

Par pitié, ne tentez jamais de créer un contrat. Juriste est un métier. Regardez plutôt dans l'existant et cherchez celle qui correspond au mieux à votre philosophie. C'est aussi pour ça que les distributions Linux ou BSD sont si utiles : elles ont fait le travail de lecture de chaque licence de chaque logiciel qu'elles distribuent.
Seulement, comme il est difficile de juger de toutes les licences, bien souvent, c'est l'avis de la FSF, la Free Software Foundation qui est suivie.

La licence qui nous intéresse, c'est la licence JSON, qui fut rédigée par Douglas Crockford en 2002, couvrant donc la spécification du format JSON et d'autres logiciels qu'il a créé. Elle fait 10 lignes. Regardons-là de plus près :

Première ligne, le copyright rend à César ce qu'il a écrit.
Ensuite, Il vous donne la permission de faire du logiciel et du format tout ce que vous voulez, le redistribuer, etc, au condition suivantes :
Toujours joindre le contrat de licence dans toute copie entière ou partielle.
Le dernier chapitre est digne de toute licence libre, ce qui veut dire qu'il ne garanti rien, il fourni tel que et tant pis pour toi.
Et cette ligne que j'ai mis en gras : « Ce format devra être utilisé pour faire le Bien, pas le Mal »

Or, que dit la Free Software Foundation de la licence JSON ? Pour eux, un logiciel n'est libre que s'il ne va vers la libre diffusion et la libre utilisation. « Ne pas faire le Mal » est une contrainte contre l'usage et la circulation. Et en plus, « le Mal » est parfaitement indéfinissable. Donc la licence Json n'est pas une licence libre.

On pourrait s'en foutre, mais malheureusement, JSON, c'est très utile. Dix années après, vous vous en servez quotidiennement dans votre smartphone ou dans le guide des programmes de votre box ADSL.

Pourquoi JSON est-il si utilisé ?
Disons que Capitole du Libre a un petit service en AJAX qui donne le détail de chaque conf.

Au début des années 2000, pour communiquer entre une page web et un serveur, ou entre serveurs, si on était dans une démarche de développeur correct, on utilisait du XML, une version stricte dérivée de la grammaire du HTML.

<?xml version="1.0" encoding="UTF-8"?>
<Conferences xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="http://xml.capitoledulibre.org/api/xml/1.0/conferences.xsd">
<Conference id="30">
<Titre>
Json ou l&quote;histoire d'une licence presque libre
</Titre>
<Cycle>
Grand Public
</Cycle>
<Orateurs>
<Orateur>
dascritch
</Orateur>
</Orateurs>
<Horaire debut="2013-11-23T16:00:00.00+02:00" fin="2013-11-23T16:20:00.00+02:00" />
<Conference>
</Conferences>

Le XML était super à la mode en 2000. Fallait que cela soit carré, fallait que tout soit défini par un document de définition, une DTD ou XSD, un contrat ! Il fallait que les XML passent au validateur pour pouvoir être interprété. Il fallait construire des XSL, ou une XSLT… Même la définition des dates est stricte.
Et pour accéder à une donnée, il fallait préciser si on appelait un attribut ou le contenu d'une balise, voire d'une sous-balise.
Un superbe rêve d'ingénieur, mais honnêtement pas vraiment facile à mettre en place du premier coup. Horriblement verbeux et lourd à décoder.

« XML est un pas de géant vers nulle part » (Erik Naggum, 10 octobre 2000)

Le JSON, c'est l'inverse.

{
"id" : 30,
"titre" : "Json ou l'histoire d'une licence presque libre",
"orateur" : [
"dascritch"
],
"cycle" : "Grand public",
"jour" : "samedi",
"debut" : "18:00",
"fin" : "18:20",
}

Douglas Crockford a pris une notation du javascript standard, et il a éliminé les variantes qu'il aime pas.
On prend un objet, on énumère chaque clé, et on stocke tel quel la chaîne ou le nombre. Peu importe si ce n'est pas le type de données attendues ou qu'il manque une clé : ça passe tel que, et on récupère un objet sans se poser la question « est-ce que tout y est ? ».
Pourquoi ?
Parce qu'on pense pas forcément à tout reporter dans une DTD/RDF/XSD/XLS/XSLT/etc... Dans le feu du code, on oublie forcément de déclarer ailleurs, et on peut avoir besoin d'étendre ses objets ou à en supprimer des composants, sus au code mort
!
Et côté code, peu importe que la valeur soit en attribut, en inner content, ou en balise fille : c'est trop complexe. Donne-moi un truc simple, et je me débrouille. Le job de vérifier les données, c'est à mon code à le faire. À l'écriture comme à la lecture, c'est très facile. Et pour les petits projets où on a besoin d'une petite quantité de données, sans se prendre la tête et vite mis en place, c'est l'idéal.

Tellement facile à mettre en place et tellement rapide à l'usage qu'on s'est servi du JSON pour autre chose que pour envoyer des objets en AJAX. Par exemple, on s'en sert pour écrire des fichiers de configurations.

Avant, on avait le format .INI . C'est un truc qui vient du monde MS-DOS, qui n'a jamais été normé, très ambigu et pas fait pour les objets complexes. Depuis 1981, tous les jours, un admin système égorge un chaton à comprendre un .INI . D'un coup, on s'est mis à faire du JSON pour configurer des serveurs (NGinx) ou des services comme des applications node.js (composer.json). C'était une libération.

Et puisqu'on était pas obligé de remplir tous les champs, le JSON rentrait parfaitement dans l'idée du NoSQL. Le NoSQL, entre autres, prône la fin des tableaux de données à définition fixes. Donc on s'est mis à stocker les données en JSON dans des bases NoSQL comme SQLite, CouchDB ou MongoDB. Croyez moi, c'est vachement plus cool que les tableaux à la Excel.
Là encore, c'était génial.

Et tout le monde a utilisé JSON, et pratiquement personne ne s'est dit qu'il pouvait avoir des ennuis avec cette licence.

Ben oui ! On est tous là pour faire le bien ! Nous sommes tous des bisounours, et free hugs pour tous,

même les linux qui gèrent des drones de combat de l'armée ! Eux qui vaillamment bombardent les chefs terroristes d'Al Qaeda, même si parfois ils font des dégâts collatéraux

« Le logiciel doit fait le Bien, pas le Mal ». Est-ce que vous voyez maintenant le problème ? "Bien" et "Mal" ne sont pas définis !

Or, le principe du logiciel libre, c'est d'être libre de toutes contraintes. De pouvoir utiliser, copier, redistribuer. Share the love ! Alors une licence mal écrite qui t'impose une contrainte d'usage, ben la FSF a dit non : non libre, pas libertarien. Et les distributions se rangent à l'avis de la FSF.
Résultat : dans la dernière Debian (7.3), et la dernière Ubuntu (la 13.10), des programmes sont amputés de leurs fonctions JSON, comme PHP.

JSON : C'était simple, ça l'est moins. Alors pourquoi Douglas Crockford a écrit cette ligne ?

En 2002, au moment où Douglas Crockford sort son format JSON, les Etats-Unis sont en guerre contre le terrorisme.

Et les discours du Président des USA répètent à l'envie qu'il s'agit d'une guerre Sainte, d'une lutte entre le Bien et le Mal :

Ne vous trompez pas : C'est le Bien contre le Mal.
(George W Bush, Président des USA, 25 Septembre 2001)

En fait, Doug Crockford fait une plaisanterie, il tourne en ridicule cette vision manichéenne qui est martelée par Washington depuis les années 1980.

Car quand Bush Junior parle du Bien contre le Mal, il fait référence à un discours célèbre de son père, Bush Senior, prononcée dix ans auparavant après la première Guerre du Golfe, celle où une coalition alliée s'est frottée à la dangereuse 4ème puissance armée du monde, l'Irak de Saddam Hussein.

Nous cherchons à discerner ce qui est bien ou mal, juste ou faux. Un nouvel ordre mondial.
(George Bush, Président des USA, Discours de l'État de la Nation au Congrès, 6 Mars 1991)

Et quand le père Bush dit qu'il cherche des repères entre le Bien et le Mal, c'est que lors de son mandat, il a vu l'URSS et le bloc de l'Est s'effondrer. Et quand George Bush dit ça, il fait référence à son précédent job. Quand il était vice-président de Ronald Reagan, lequel avait une expression favorite : « Empire of Evil ».

[ L'Empire du Mal ] prêche la supériorité de l'État, |…] Il est la racine du mal dans le monde moderne.
(Ronald Reagan, Président des USA, Discours à l'Association Nationale des Évangélistes, 8 Mars 1983)

Dans ce discours, Ronald Reagan emploie pour la première fois le terme « Empire of Evil ». Si, par la suite, « Empire of Evil » a désigné l'URSS, ici, il parle de l'État tout puissant contre l'individualisme et le Libre Arbitre.

Au même moment, dans la Silicon Valley, il y a une prise de conscience dans les milieux libertaires, celui des hackers. C'est à dire là où seront conçus la majorité des micro-ordinateurs familiaux. Si vous aviez eu un ordinateur familial à cette époque, même un Macintosh qui valait 6 mois de SMIC, la licence en interdisait tout usage par l'État ou l'armée.

Parce que depuis les années 70, les hackers de la Silicon Valley ont peur que l'état Fédéral ne se serve de l'outil informatique pour restreindre les libertés individuelles. Exactement ce que Ronald Reagan décrit comme « Empire of Evil ».

Or l'État, ce n'est pas que l'armée, c'est aussi l'aide sociale, les services de secours, l'éducation. Mais tout le problème, c'est qu'il est impossible d'imaginer comment des logiciels peuvent garantir ces libertés. Et il est moralement plus acceptable de pouvoir auditer les logiciels utilisés par un état plutôt que de le laisser acheter des boîtes noires propriétaires. Parce que c'est un moindre mal.

Alors plutôt qu'interdire vaguement dans une licence de restreindre les libertés individuelles, les fondateurs du logiciel libre préférèrent ne mettre aucune contrainte morale. Parce que c'est infaisable.
Voilà, maintenant, vous savez, une licence logicielle, si elle est libre, elle permet à qui s'en sert de l'utiliser pour vous fliquer. Mais si votre licence n'est pas totalement libre, c'est le bordel pour les utilisateurs.

Tout le problème de la licence JSON, c'est que c'est une putain de plaisanterie, qui se moque de la politique étrangère expliquée au citoyen américain comme s'il était un tout petit gosse. C'est 30 ans de politique étrangère américaine qui impacte directement le logiciel libre.

Ceci dit, une licence, c'est un contrat. Et un contrat, ça peut se négocier. C'est ce qui est arrivé à Douglas Crockford. Toujours pour cette putain de ligne. Pendant 8 ans, une très grande entreprise cotée en Bourse n'arrêtait pas de lui demander une dérogation sur la licence JSON. Crockford, qui n'a donné que les initiales de cette compagnie et qu'on ne connaît toujours pas, a cédé devant la gentillesse d'une demande d'un avocat.

C'est comme ça que Douglas Crockford a, je cite, accordé à IBM, à leurs clients, à leurs fournisseurs, à leurs sous-traitants et à leurs hommes de mains de pouvoir faire le mal avec ses logiciels qui sont sous sa licence JSON.

Quand je vous dit que cette licence est infernale.

Faites le bien, pas le mal :

Lisez vos licences
N'en créez pas une si nous n'êtes pas juristes
Un logiciel est libre par l'usage, ne le bloquez pas
Si la licence ne vous convient pas, négociez avec les auteurs
Une loi, c'est comme le code : pas d'approximations

Sources iconographiques : R.M. Thurber / Fox, VentureBeat, FSF, Wikimedia, Syracuse.com, Freedomslighthouse.net, Armchairgeneral.com, Ladyblitz.com, M. Radford / Fox, Audiolucistore @Flickr, Sesame Workshop, KnowYourMeme. Cette vidéo a été réalisée par TV-N7 et est hébergée par Toulibre. Je remercie tout le monde, bien sûr.

Venez me causer pérennité à Paris-Web

Da Scritch — 2013-09-11T07:12:00+02:00

Autopromo. En plus de ma conférence de Jeudi, je tiendrais un atelier le Samedi. Viendriez-vous ?
Sortons

Les inscriptions aux ateliers sont ouvertes depuis ce Lundi. L'occasion pour vous rappeler que j'y tiendrais un “atelier”, puisqu'il s'agira de retours d'expériences, d'idées pour faire qu'un service web tienne dix années et plus. On a des cas célèbres de projets qui n'avaient pas prévu de tenir autant comme Spip, Wordpress, OS Commerce, Dotclear (tiens, dix ans justement), Craigslist ou Wikipédia ; certains tiennent le choc, d'autres auraient mérité de meilleures pratiques dès le début.

Mon atelier Construire pour le futur sera le Samedi 12 Octobre à 15h30 à l'EGS Management School (Paris, XI^ème) uniquement sur inscription préalable. Et si vous venez pas, je ne vous en voudrais pas : à la même heure Rudy Rigot et Jérémie Patonnier parleront RD à côté, y'aura de l'ARIA dans les composants, du redesign dans le navigateur,…
Ça me fait bizarre d'être au milieu de gens aussi pointus.

Ce que vous avez manqué cet été

Voici quelques unes de mes précédentes bafouilles dont nous aborderons peut être quelques ratures :

Don't do Evil, Json

Da Scritch — 2013-08-27T07:57:00+02:00

Comment une licence un peu hypocrite s'amuse à démontrer les dangers des licences sur internet. Le problème, c'est que les avocats du Logiciel Libre n'osent se décider sur la définition. TL;DR c'est la faute à Bush père !
Webdev

C'est une petite phrase sibylline, écrite depuis des années dans une licence d'utilisation. Le genre de pavé de texte que les développeurs ne pensent à lire que trop rarement. Au milieu, Douglas Crockford, créateur des bibliothèques YUI, grand gourou du Javascript chez Yahoo! et auteur du format JSON y est explicite :

The Software shall be used for Good, not Evil.

Exactement le genre de petite “blague“ qui se découvre maintenant comme un souci majeur. Cela serait sans conséquence si le JSON n'était pas le format d'échange de données structurées préféré du web après le HTML. En 2002, alors que le XML était promis à un avenir roi, petit à petit, le format JSON est arrivé à devenir la notation d'objet la plus utilisée sur le web, ayant largement supplantée le XML par sa facilité de mise en œuvre.

L'objet JSON est maintenant un élément standard du langage Javascript, et on utilise très couramment cette notation pour faire des structures de données en NoSQL. Il a tellement supplanté le XML, que l'on ne parle plus depuis des années d'appels AJAX, mais XHR. Ce qui est complètement débile, puisqu'on y a toujours le XML dans l'abréviation, et toujours pas JSON.
Il est d'une simplicité de mise en place proverbiale face au XML (le vrai, le tatoué, celui dans les RFC), même s'il lui en manque quelques features comme la stabilité de l'encodage unicode (La norme EcmaScript autorise à la fois les formats UCS-4 et UTF-16, mais on a aucun entête BOM pour les distinguer, d'où l'usage alourdi de la notation C \0x), un mode d'échappée ou binaire comme le CDATA, les commentaires et le stylage XSLT ; mais cela allège de l'encombrement verbeux des noms de balises, des namespaces aux DTD incompréhensibles. En clair, une verbosité concise qui, à l'époque de MSIE6 accélérait très grandement son traitement dans un Javascript par rapport au XML.

Jsonny be Good

Cette phrase dans sa licence est une cause d'instabilité juridique jugée suffisamment grave pour que la Free Software Foundation considère la licence comme non-libre. La distribution Debian, très utilisée sur les serveurs a donc immédiatement retiré cette fonction litigieuse. Une situation similaire pour des raisons différentes était arrivée avec Firefox dans Debian, qui ne concernait que le nom et le logo, ce qui m'a fait découvrir toute la palette de gros mots de Glandium, à l'époque packageur Debian et colocataire du serveur de ce blog.

Les fonctions JSON (json_encode() et json_decode()) se retrouvent donc retirées de la version PHP 5.5.2 distribuée par Debian. D'autres distributions aussi pensent à ce retrait. Et si pour l'instant rien n'est décidé, il est probable que ces fonctions disparaissent de PostGreSQL ou mettent sérieusement sur la sellette tous les moteurs de bases NoSQL qui s'en servent. Pardon, tous les moteurs NoSQL. Eh oui.
Et cela pourri la vie à bien du monde, puisque la même phrase se retrouve dans d'autres bibliothèques, notamment JSMin.

Je ne sais pas ce que pourrait sortir un avocat, mais j'espère que la licence parle du logiciel, et pas du format lui-même, car sinon, on ne s'en sortirait plus par tous les morcellements envisageables. Or, à ma lecture, en Anglais Software signifie aussi bien un logiciel, un film, une musique, un roman qu'un texte juridique. Le hardware, c'est le marteau du juge, les menottes et les barreaux de prisons. Aux États-Unis, on ne rigole jamais sur le respect de la propriété intellectuelle…

Où l'on parle de politique, politique

Des licences plus ou moins libre y'en a un énorme paquet allant du freeware à la CC-0, un gigantesque paquet avec chacune ses particularismes. Il n'était pas vraiment besoin d'en créer une de plus. Crockford a juste mis une base (redistribution et crédit de l'auteur originel), ce qui en donne une base théoriquement libre; Puis il a ajouté cette clause. Et cette ligne qui vaut un feu rouge de la Free Software Foundation.

Alors pourquoi Douglas Crockford a-t-il fait ça ?
C'est une boutade, envers une phrase du président George W. Bush. Ou plus exactement une fixation puisque le terme evil est utilisé ad nauseam pour justifier les guerres en Afghanistan et en Irak :

« Make no mistake about it: This is good versus evil. These are evildoers. They have no justification for their actions. There's no religious justification, there's no political justification. The only motivation is evil. »
(25 Septembre 2001)

Seulement, il se trouve que Bush Junior, dans cette phrase, fait référence à un discours célèbre de son père, Bush Senior, prononcée dix ans auparavant lors de la première Guerre du Golfe, celle où une coalition alliée s'est frottée à la dangereuse 4^ème puissance armée du monde, l'Irak de Saddam Hussein.

« What we are looking at is good and evil, right and wrong. A new world order. »
(11 Septembre 1991)

JSON.parse('{"Good": undefined, "Evil": undefined}');

(oui, ça ne marche pas, c'est fait exprès)

Évidemment, les exceptions existent.
Comme toute licence logicielle libre, cette licence est générale, mais néanmoins négociable avec l'auteur. Ainsi, si vous comptez faire de l'argent avec mes écrits, la licence CC-BY-NC de mon blog vous en empêche, mais si vous me le demandez gentimment, je peux très bien vous y accorder des droits supplémentaires.
Crockford raconte ainsi dans une conférence (toujours noté dans ce billet) qu'il a finit par donner « la permission à IBM, ses clients, ses partenaires, et ses hommes de mains d'utiliser JSLint pour le mal. »
Sauf que le problème reste le cadre général de la licence : ce qui et le Bien et le Mal est toujours aussi impossible à définir depuis 1991 et ses 20 saisons de Law & Order (c'est même souvent le ressort du dernier quart de l'épisode).

En fait, Douglas reprenait une tradition oubliée. Dans les années 1980s, certains logiciels pour micro-ordinateurs familiaux précisaient explicitement dans leurs licences « L'usage de ce logiciel par l'Armée ou le Gouvernement des États-Unis est explicitement interdit ». Cette précision se retrouvait même sur les ordinateurs Apple jusque dans les années 1990s.

C'est une motion de défiance des développeurs baba-cools et libertaires de cette époque : ils craignaient que d'une manière ou d'une autre, leurs petits bouts de code puissent servir à fliquer, à espionner ou à contrôler les citoyens.

Comme quoi, ils avaient raison.

Mais en attendant, une fois de plus, Douglas Crockford nous fout dans une merde noire, et ayant déjà ferraillé avec l'individu, je peux vous assurer qu'il n'est pas prêt d'en démordre.

Restera à forker un standard qui est tellement strict que même ce simple hack pour y intégrer des commentaires, je ne suis pas sûr qu'il passe partout.

Un très vague aperçu de Sud Web

Da Scritch — 2013-07-31T07:45:00+02:00

Si vous regrettez de n'être pas venus cette année, voici les vidéos de rattrapage !
Webdev

Les conférences étaient filmées, comme pour les éditions précédentes. Elles sont disponibles à la consultation :

Le client, ce gentil méchant - Olivier de Villardi (conférence 20mn)
Conduite du changement, de l'artisanat à l'industrialisation - Agnès Haasser (conférence 20mn)
Sass et Compass ont embelli mon quotidien - Mehdi Kabab (conférence 20mn)
Getting Touchy: an introduction to Touch Events - Patrick Lauke (conférence 20mn)
Le développement c'est difficile - Rémi Parmentier (lightning talk 5mn)
Aubergine n'est pas une couleur - Alain Witkowski (lightning talk 5mn)
L'odyssée de l'espace insécable - Damien Alexandre (lightning talk 5mn)
Et si j'écrivais un livre ? - Corinne Schillinger (lightning talk 5mn)
Une quête de sens, conférence sur l'éthique animée par David Larlet (débat 1 heure)
Responsive News : l'actualité mobile à la BBC - Kaelig Deloumeau-Prigent (conférence 20mn)
Un peu de TLS ne fait pas de mal - Éric Daspet (lightning talk 5mn)
Le culte du cargo - Thomas Zilliox (lightning talk 5mn)
Les super-pouvoirs du nouveau venu - Mathieu Agopian (lightning talk 5mn)
Travailler sur ses 2 pieds - Pierre Martin (lightning talk 5mn)
La visualisation de données comme outil pour découvrir et partager des idées sur le web - Nicolas Belmonte (conférence 20mn)
Monitoring : une culture plus que des outils - Arnaud Limbourg (conférence 20mn)
Comment l'impression 3D va modifier le web et l'économie - Marc Lipskier (conférence 20mn)

Malheureusement pour vous, vous n'aurez pas gagné le plaisir des rencontres et des discussions. Vous avez loupé cette excellente ambiance de parlement anglais dans le palais des Papes en Avignon. Et surtout, le plaisir de défourailler (ici, avec Constant Barsalou, mon patron !)

Merci Brice Favre pour tes excellentes photos !

Alors, venez l'année prochaine !

Sud Web 2013, habemus principes

Da Scritch — 2013-05-22T13:57:00+02:00

Avignon est une ville superbe. Son Palais des Papes est magnifique. Et la salle de conférence en son sein a donné un cachet très particulier à SudWeb. Une ambiance de parlement Anglais.
Sortons

L'an dernier, j'ai eu la chance formidable d'y être orateur. Cette année, j'y suis allé sur mes propres deniers, car l'argent investi vaut très largement le skill acquis, le level up (comme disent les jeunes maintenant) conséquent.

Le ponpon, le Monsieur Plus ça reste l'immense Rudy Rigot déclamer le programme en alexandrins. Là, je crois que la barre a été mise vraiment très haut pour toutes les conférences techniques du circuit.

Il est vrai que les conférences étaient nettement moins techniques : Loïc “Chibani” Gerbaud (qui a sorti deux comptes-rendus très complets sur les conférences et les ateliers) m'a amené un bloc-note de secours car l'an dernier, je noircissais 3 pages par conférence. Là, cette année, on était moins dans le pointu et plus sur le retour d'expérience, mais du coup, cela donnait des regards très différents sur notre métier, des retours d'expériences enrichissants, voire des angles qui font changer notre point de vue.

Et puis, il y a les rencontres

Disons que vous avez des capacités et des connaissances techniques, mais quelques doutes. Ça nous arrive tous.

photographie de ma modestie par Thanh Nguyen (de O2Sources), lors de Sud Web 2012

Après quelques discussions, du partage, vous êtes devenus encore plus puissant

super-pouvoirs illustrés par @ookook

Rien à redire, participer à ce genre d'événements est une chance rare. Parce que les autres participants sont des professionnels passionnés. Vous pouvez consulter les slides, voir les vidéos, mais vous n'aurez jamais profité des rencontres.

Les conférences

Allant de thèmes variés, comme l'industrialisation d'un processus, la visualisation de données chez Twitter ou le responsive chez BBC News, chacun avait des éléments de sa spécialité, mais aussi des regards différents comme les imprimantes 3D, le bien-être comme le fait de travailler debout…

La fameuse quête mystère, agora sur notre secteur, qui a crevé de nombreux abcès. Il y a vraiment une prise de conscience qu'au-delà du respect des standards, nous devons amener un autre regard sur notre profession. Nous sommes des passionnés, nous devons néanmoins défendre, valoriser notre expertise.

Les ateliers

Mon gros regret est de n'avoir pu participer au fort ingénieux serious game mené par Antoine Vernois. Il y a tout simplement trop à voir en simultané. Je me suis en plus piqué au jeu de proposer mon propre atelier sur le coup. Et en plus, il y avait même un coin où ça jouait à cHTeMeLe, un jeu de barbu.

J'ai eu droit à un excellent (et particulièrement éprouvant) atelier de refactoring de code javascript particulièrement moisi. Un débat sur le commentaire décentralisé, qui montre qu'on est très loin d'avoir une solution simple et protégée. Et un autre sur la perception de sécurité des données personnelles, quoique totalement impromptu donc parfois décousu, il avait du potentiel.

Une satisfaction personnelle

J'en ai deux : La première, c'est que Constant Barsalou, qui m'a recruté pour le projet Simtie, est venu avec moi, et a pu comprendre mon monde. Je crois même qu'il l'a apprécié cette idée d'émulation pour porter vers le haut notre niveau d'exigence.

La deuxième, c'est que j'ai lancé un élaboratoire le jour-même, sous le titre provocateur Urgent recherche stagiaire, et que ce qu'il en sort risque de faire beaucoup parler dans la profession. Et en bien. Je vous en causerai la semaine prochaine.

Le logement

On va pas se mentir : les nuits furent COURTES.

Rien à redire, avec AirBnB, on est tombé sur un superbe appartement à 3 minutes du Palais, tenu par des logeurs qui nous ont même prévu un petit-dej. À deux pas des musées, dont c'était la Nocturne ce même week-end. Super bonus.

Comme du bonus

Outre le sac en toile de jute, les badges et la balle à envoyer sur les collègues, le bonheur, c'est de pouvoir acheter des ouvrage de références qu'on peut faire dédicacer aux auteurs. Et ça, c'est… Enfin, c'est SudWeb, quoi.

Un nouveau défi : écrire le web pour dix ans

Da Scritch — 2013-04-30T08:13:00+02:00

Bonjour, je suis à nouveau salarié. Et mon employeur doit être aussi fou que moi.
Ma vie est une sitcom

Voilà, c'est officiel : j'ai repris une activité de salarié, d'employé, d'ouvrier du code.

Notalus, c'est l'histoire d'une belle aventure familiale, d'une entreprise qui transforme vos paquets de papiers administratifs en superbes reliures. Ils ont des clients prestigieux et l'âge de la raison. Et ils font un double pari : proposer un nouveau service sur internet, et passer à un mode de gestion Agile.

Simtie est un projet de service web pour la gestion documentaire. À l'usage des petites structures, et dans l'idée de penser plus comme elles que de se bloquer à un mode de pensé qui ne conviendrait qu'à une minorité. Et ce projet doit tenir une décennie.
Notalus m'a proposé de devenir leur lead developer sur ce projet. De concevoir avec leur équipe d'une manière souple, solide, extensible et ingénieuse.

Le défi est beau.

J'ai tenté d'être mon patron

Être indépendant fut une très belle aventure, mais trop épuisante, éreintante.

Quand je me suis lancé en indépendant en 2007, je sortais de 7 années en tant que concepteur rédacteur en ~~publicité ~~multimédia~~~~. J'écrivais parfois sur la sécurité informatique, et je voulais me prouver que j'étais un développeur. J'avais juste oublié que dans « web-développeur freelance », le deuxième terme impliquait d'être un commercial. Un très bon commercial. Et là, je dois avouer que je n'ai pas su.

La difficulté à obtenir certains marchés parce que je ne suis pas un commercial, le comportement prédateur de certains “clients” parce qu'ils vous voient comme une variable d'ajustement à leurs mauvais calculs, les gestions de projets catastrophiques sur lesquels vous êtes appelé en pompier quand y'a plus grand-chose à sauver.
Tous ces problèmes furent plus fort que les très beaux projets réalisés comme la construction de dAgence, la collaboration avec Phonitive et bien d'autres encore…

Non, dAgence n'est pas abandonné. Il tourne, il y a des clients dessus, l'infrastructure est solide, et j'ai des plans d'améliorations. Donc ce travail n'est pas perdu. Il m'a permis d'expérimenter les WebForms2 dès 2007, les PDO, les surcharges, le MVC, les tests, l'extensibilité, les délégations de responsabilité sécurité, le SVG, les API, et d'autres avancées “HTML5” comme le mode strict, CSS3, etc…
Je ne peux que remercier mes partenaires, notamment Nicolas Guilhou et Kairn car ce projet est un très beau bébé.

Mais tout n'est pas perdu : Mon expérience sur plusieurs projets de web applications, dans différentes tailles et structures, semble séduire. Mon carnet d'adresse, et mes différente expériences, permettent d'imaginer des solutions différentes à des problématiques.

Tartine beurrée + sol ⇒ —

Évidemment, je souffre du syndrome Facebook. Suffit que mettre sur Facebook que vous êtes en couple pour que les filles gravitent autour de vous. Ben dans mon cas, depuis que j'ai annoncé à certains que j'entre dans une boîte, j'ai des offres d'emplois qui se réveillent. Des grosses agences Parisiennes ou Berlinoises, une de brillantes startups toulousaines qui vous disent ouvertement qu'il n'ont pas su vous appeler assez vite, et là, tout récemment, un superbe London calling.

Mais j'ai foi dans le projet Simtie. C'est un “classique” mais il y a réellement la volonté de le faire sous un angle moderne et neuf.

Et puis surtout, je reste un allumé exigeant, et complètement frappé. Et je ne suis pas sûr qu'au bout de 4 mois, même si je suis accompagné d"'un ex-collègue d'Index Multimédia, mes coworkers imaginent jusqu'où je suis capable d'aller en exigence technique.

Dirty Hacky I : Commentaires conditionnels

Da Scritch — 2013-04-08T21:00:00+02:00

Parce que tu crois qu'avec ta récidive, tu vas faire du sursis ?
Webdev

Ce billet fait partie de la série « Dirty Hacky ». Le but de cette série est un objet critique sur les astuces de web-développement, et n'a pas pour vocation d'être une recette définitive, mais d'attirer l'audience par la polémique technique.
BANG! BANG! BANG!

Commentaires conditionnels en HTML

Les commentaires conditionnels transforment l'usage d'une balise d'annotation en balise expressive. L'origine de ce hack du commentaire conditionnel est AFAIK une création de la IETeam, l'équipe de développement du navigateur MSIE. Son but est de servir selon des navigateurs un HTML différent dans le même document. Je n'ai pas souvenir qu'il aie été conçu en concertation avec les autres concepteurs de moteurs, mais au moins il a été très vite “accepté”. À l'origine, il devait faire la différence entre MSIE4 et les autres navigateurs (Netscape et Opera) pour proposer les fonctions avancées de Microsoft (eh oui !).
Actuellement, il sert plus à fournir des polyfill aux versions obsolètes de MSIE.

Si techniquement, le hack rempli parfaitement son office, philosophiquement, il n'est pas top : il rend difficile d'obtenir une hygiène XHTML pour le code destiné aux MSIE ciblés.

Il offre aussi un faux confort : on est dans un semblant de responsive, sauf qu'on utilise alors un browser targetting : on cible directement une marque précise de navigateurs, ce qui est déplorable. On cherche même pas à savoir si la fonction marche proprement (ou l'inverse), on se base sur le comportement d'une marque de navigateur. Ce qui veut dire qu'on avance empiriquement, sans se préoccuper que les mêmes tares s'appliquent à un autre navigateur, ou qu'il n'en soit pas affligé. Cela est déjà arrivé : MSIE 5.2 sur Macintosh était largement plus avancé que la version 5.5 sous Windows, merci à Tantek Çelik.

Pour vous montrer un exemple de commentaire conditionnel bordélique, je vais reprendre mon exemple du billet sur la dégradation élégante :

<audio controls="controls" [...] />   <object type="application/x-shockwave-flash" data="https://dascritch.net/post/2013/04/08//interface/player_mp3.swf">  <param name="src" value="/interface/player_mp3.swf" /> [...] </object> </audio>

La première déclaration de la balise <object></> est à destination de MSIE versions 9 et inférieures qui ne comprend les plugins qu'en terme d'index dans la base des registres de MS-Windows. Leur servir la déclaration standard ne mène à rien. La deuxième déclaration utilise elle le système standard, s'appuyant notamment sur le type-mime pour appeler le bon logiciel client. En terme de lisible, j'ai vu mieux.

Les commentaires conditionnels sont définitivement bannis à partir de IE10. La IEteam souhaite ainsi marquer le coup : ils veulent aller vers la modernité et les standards. Abandonner les commentaires conditionnels, c'est faire oublier l'image désastreuse laissée en héritage par leurs prédécesseurs. Imposer ce choix radical, c'est aussi inciter le monde du webdesign vers des pratiques plus génériques, notamment la detection feature ou utiliser les media target des css.

Origine	GOOD
Élégance	MOYENNE
Modernité	EN OBSOLESCENCE
Postérité	NO USE

Commentaires conditionnels en JScript

L'équivalent existe pour le javascript, pardon, le JScript by Microsoft™, et je le prouve :

/*@cc_on interprété que par MSIE @if (@_jscript_version == 10) Uniquement par MSIE10 @end @*/

Syntaxiquement, on est à la fois dans les commentaires expressifs, et proche des directives de compilations de certains langages. Personnellement, j'aime pas trop avoir du code expressif en commentaires.

Pourtant, j'adore les commentaires formatés. J'adore le JAVADOC, mes IDE dévorent le JAVADOC, mon code transpire du JAVADOC car il sert à aider à formater des commentaires non indispensables au code, tout en aidant fortement à sa compréhension. JAVADOC est un langage de mise en forme, comme le HTML et intervient comme un véritable ARN intron, l'imprécision n'y est pas dramatique.

Au contraire, je déteste les commentaires expressifs comme Doctrine et sa notation PHP, car ce dernier dicte la construction de la base de donnée en utilisant un autre métalangage. Doctrine utilise les commentaires comme directives d'interprétations. En plus, cette notation n'a qu'une implémentation incomplète par rapport à son implémentation YAML. C'est notamment le cas dans Symfony 2.1, et pourquoi je trouve l'ORM de CakePHP 2.3 plus cohérent car dans le PHP exon.

Logiquement, j'aurais plus préféré une variable globale, genre navigator.jscript_version, cela aurait donné une conditionnelle toute propre. Mais bon…

Si le commentaire conditionnel des JScript est toujours présent dans IE10, il faut quand même se faire une raison : la detection feature, c'est logiquement mieux. Et là, je suis surpris que la IEteam ne l'aie pas supprimé.

Origine	GOOD
Élégance	MOYENNE
Modernité	TOUJOURS
Postérité	VA SAVOIR ?

To be continued

Dans le prochain épisode : « Magouilles dans les CSS ».

En attendant, les pisses-froids des ligues de vertus et des droits de la défense peuvent hurler ↓ plus bas. Et non, InfestedGrunt, les commentaires ne sont pas conditionnels.

Touchalize en tournée Parisienne

Da Scritch — 2012-12-04T09:31:00+01:00

Ou comment faire parler de vous à LeWeb sans y être. uhuhuhu
Webdev

J'ai eu l'insigne honneur d'avoir été appelé par Phonitive pour participer au développement de leur nouveau produit, qu'ils présenteront tout à l'heure (vers 16h20 sur la grande scène).

J'ai été d'autant plus touché par cette collaboration, que Guillaume Lemoine, le patron de Phonitive, m'a connu dans un passé professionnel où l'essentiel de mon activité n'était pas le développement. C'était chez Index Multimédia.

Depuis, je suis devenu développeur web en indépendant. Il se trouvait que nous nous croisions régulièrement après coup. Et Guillaume a vu dAgence, a été séduit par certains aspects techniques, et avait besoin de quelqu'un pour travailler sur le backoffice de sa petite merveille.

Parlons un peu de Touchalize

L'idée motrice de Touchalize est de pouvoir interagir avec les vidéos.

Du déjà vu ? Pas vraiment : Prendre une campagne publicitaire, en faire un vrai truc viral en invitant les spectateurs à y participer. Changer la couleur d'un élément, que cela soit une carrosserie, un meuble, ou un vêtement. Inclure dans le décor une photo personnelle. Modifier un texte qui est dans la scène. Et que ceci puisse fonctionner aussi bien sur des téléphones portables et des tablettes que sur un pc de bureau. Car le web du loisir change d'appareil.

Image non-contractuelle, le modèle de la voiture peut varier

Mais qui dit publicité, dit analyse du retour du public. Quelles sont les vidéos les plus lues, vers quelle heure, quelles sont les éléments qui sont le plus changées, les couleurs préférées,…

C'est là que j'arrive

Guillaume a été assez ~~fou~~ ~~casse-cou~~ ~~téméraire~~ cool pour me demander de travailler sur des technologies très peu déployées. Voilà qui me changeait complètement, m'incitait à apprendre de nouveaux langages, de nouvelles API, d'aborder de nouvelles problématiques.
Être stimulé à apprendre. Je ne comprends pas qu'on puisse rester programmeur sur une seule technologie, qu'on aie pas envie de progresser. C'est pour ça que je galope aux Apéro Web, aux CodeAndCoffee, aux Journées Agiles, à l'AFUP, à ToulouseJS, au Capitole du Libre, au JUG, et au Global Day Code Retreat de ce samedi…
Et avoir un bagage pluri-disciplinaire, c'est à mon sens d'autant plus utile qu'il permet de mieux appréhender ce que l'on peut attendre de votre produit.

Travailler sur les données statistiques, ce n'est pas uniquement ressortir ses cours de Seconde, ou son savoir faire de militant Copé-Fillonniste pour présenter un beau total. C'est aussi travailler sur la récupération de données d'applications. Le moteur d'analyse est propre à Touchalize. De là, développer un thesaurus d'événements, collecter, récupérer les données. Et ensuite, showcaser du dataviz, comme disent les jeunes, en manipulant <canvas> et <svg>.

Et croyez-moi qu'à chaque étape, l'équipe sur Touchalize a eu droit à des obstacles qui nous font rire après coup, mais assez glaçant au départ.

Sur la grande scène, 16h20

Touchalize est présenté par Phonitive en compétition à LeWeb.

C'est un peu idiot. J'ai pas pensé à faire de captures du produit qui sera présenté tout à l'heure et de mon travail. À vraie dire, j'avais pas vraiment prévu d'écrire sur cette collaboration. Alors que j'ai eu du plaisir à bosser sur un projet qui, comme pour dAgence, n'a pas un cahier de charge figé, qui pouvait être modifié dans la minute, d'être redéfini de manière agile, afin d'aller à l'essentiel plutôt que se bloquer sur des détails. Et puis d'un coup, imaginer des fonctionnalités, et les installer par enthousiasme, pas par obligation.

Certains pensent que c'est l'esprit startup, je dirais plutôt que c'est essentiel d'avoir le bonheur de créer. Comme ça :

Bon, à vraie dire, quand Morgan Camilleri a pris cette photo, on est en fin de run, et tous un peu claqué. Guillaume qu'on voit au fond est en train de rire sur une blague écrite en octal, Djavan se cache derrière une tablette 3,5" et Laurent Fedou (à gauche) chante Carmina Burana façon reggae.

Je peux toujours faire croire que je suis à LeWeb, mais bon, ceux qui me connaissent débusqueront trop vite le fake.

Et maintenant, un petit secret :

How to braficoter du dataviz

Trouver les données essentielles, la bonne manière de présenter des données de manière anonymisées (pour moi, c'est extrêmement important), la bonne représentation graphique, le tout dans une interface cohérente et fonctionnelle… Je pensais que c'était évident, puisque je le fait très régulièrement.

Et puis, ce matin, j'ai vu les présentations très très créatives de Fox News.

Additionnez les pourcentages…

Et là, je me suis dit que j'avais encore beaucoup à apprendre…

En attendant Paris Web

Da Scritch — 2012-10-16T16:27:00+02:00

De la lecture, de la grosse lecture de qualité, de la lecture qui te fait gagner le respect poli de tes collègues.
Webdev

La semaine va être très lourde en skill (comme disent les jeunes) à prendre dans la conception web, puisqu'il y aura ze Paris-Web du Jeudi au Samedi. Du lourd, du costaud, du tatoué, du certifié qui montrent les normes de développement du web de demain. La claque annuelle qui fait juste pleurer de joie et oublier les heures noires de MSIE6.

On aura à peine le temps de souffler que la semaine prochaine, c'est l'Agile Tour Toulouse.

Seulement, il faut se préparer et prendre quelques piqûres de rappel avant d'entamer la descente des Champs-Élysées.

Envie d'optimiser ses variables javascript ?

Depuis que javascript n'est plus vraiment interprété à la volée, grâce aux compilateurs JIT, on a pris une accélération monumentale pour nos applications clients. Mais quelques bonnes pratiques peuvent encore leur donner un coup de boost. Luke Wagner explique d'une manière très clairement dans Optimizing JavaScript variable access la vie secrète des variables de vos scripts.

Attention, toutes les pratiques ne sont pas forcément les meilleures pour la relecture, l'évolutivité ou la maintenabilité, mais elles donnent un très bon aperçu sur comment fonctionne ce langage dans les navigateurs. Lecture utile.

Besoin de coder javascript comme un pro ?

Une vrai application full javascript ? Avec des libs et tout et tout ?

Designing Better JavaScript APIs est un excellent dossier du Smashing Magazine, assez costaud mais qui devrait vous aider à vous faire la voie vers les bonnes pratiques. Celles qui vous permettront de ne pas pleurer dans 5 ans.

Et faudra qu'un jour je parle des dangers de toutes ces ré-écritures du javascript. AltJS tente d'en faire à la fois une classification et un travail d'introduction, initiative à saluer pour la somme de travail.
Oui, à mon humble avis, il y a danger pour certaines méthodes.

Et si on se passait de javascript ?

Mon comparse Nicolas Guilhou s'est penché sur le très épineux problème du stylage des éléments GUI systèmes, et notamment des checkboxes. Peut-on le faire sans émuler cet élément de manière forcément erronée ? Tout au CSS bio garanti naturel, 0% Javascript ? Oui. Et il le fait avec brio : Styler les checkboxes sans monoculture… ou presque.

Certains états, notamment le indeterminate, ne peuvent être rendus proprement, mais pour une interface simple et qui en demande pas trop, ben...

« Alors, c’est qui le patron, hein ? »

C'est Xylpho le patron…

Dans les tripes

On enchaine sur du sacrément technique.

Pour bien exploiter un langage, avant de passer à un quelconque framework, il est recommandé d'en travailler les bases pour bien les connaître.

Enfin, ça, c'est ce que je recommande.

Alors si vous faites du html, du javascript, de la css, du xml client-side, du svg, etc… Pour être un tantinet sérieux (plutôt que se barder d'étiquettes ridicules genre “guru ninja-expert”), vous produirez du meilleur code si vous savez comment il est interprété. Comment marche un navigateur moderne, c'est un article très complet, costaud, et qui va vous occuper au moins une nuit blanche entière.

How Browsers Work: Behind the scenes of modern web browsers est un “tutoriel” vraiment impressionnant, mais qui vous fera comprendre pourquoi certaines règles css sont nettement plus rapides que d'autres, ce qui fait bouffer de la mémoire, etc. Vous verrez très différemment l'immense travail fourni par la Mozilla Foundation, Opera Software, les branches webkit et la IE Team.
Non, sans rire.

De la lecture pour vous chefs ?

Rappelez-leur qu'en informatique, c'est comme dans le Monde Réel : on ne peut violer les lois de la thermodynamique.
Vous me direz que cela n'a rien à voir. Oui. Mais pendant qu'il se perdront dans wikipédia, vous pourrez regarder tranquillement Paris Web en stream.

Les présentations des précédents Paris Web

Parce que si vous ne les aviez pas vues, elles sont toujours disponibles en ligne, et il me semble même que certaines vidéos sont déjà téléchargeables. À mettre bien évidemment dans votre pc professionnel dans un répertoire « porn ».

Et après… Avignon, Mai 2013 ?

Si je proposais de nouveaux sujets à Sud Web pour l'édition 2013 ? Et si vous aussi, vous proposiez des sujets pour avoir une chance de s'exprimer devant un auditoire de qualité, et faire les andouilles masquées dans la cité des Papes ?

Viendez !

Des trucs à moi qui peuvent toujours être d'actualité

Cette semaine,on m'a parlé d'une "pratique recommandée" de mettre les appels js en fin de body. Non, et non. Back to 2007, pour quelques javascripts de plus sachant que depuis, on a un event dom standardisé, onready.

Mon dossier emoji. Oui j'en suis très fier, mais oui, il est parfaitement d'actualité !

Pour une compression JPEG mieux gérée, sans rien changer aux logiciels clients. Bon, par contre, les brevets logiciels nous poseront quelques soucis.

HTML wars, la vengeance (se venge) ! C'est un peu comme si Romero avait filmé la seconde guerre du web, puis fait un remake. Mais avec Chrome dans le rôle-titre involontaire.

Et sinon, le truc ultime, c'est de faire venir les orateurs de Paris Web chez soi

Élie Sloïm profite d'un espace wifi entre deux trains.

Et à ce sujet, Temesis va sortir un bouquin référence sur « Les bonnes pratiques pour améliorer vos sites » qui s'appelerio ~~Qués~~ « Qualité web » du-dit Élie Sloïm et de Laurent Denis, Muriel de Dona et Fabrice Bonny, préfacé par Amélie Boucher et Stéphane Deschamps.
Tiens, marrant qu'il soit préfacé par un traducteur de comics. Ça doit être un homonyme...

J'ai rapidement feuilleté l'exemplaire d'un des auteurs. Ce sont 15 années d'expériences professionnelles, d'excellentes pratiques en sémantique, en accessibilité, en praticité et en expérience visiteur qui ne sont pas prêtes de tomber en obsolescence. Acheter ce livre vous fera de sacrées économies en SEOLOL.

Des emoji dans l'Unicode ▶ Présentation en live

Da Scritch — 2012-09-25T10:02:00+02:00

En sons et en diapos, le dossier résumé manière conférence Achille-Talonesque.
Webdev

Ce billet fait partie de la série des emoji dans l'Unicode et a été proposé comme sujet candidat à Sud-Web 2012 :

Bonus

Présentation en live

Si vous n'étiez pas présents mardi dernier, voici le sonore et les slides de ma présentation à l'Apéro Web Toulouse résumant mon dossier. Enjoy !

Appuyez sur « ▶ » juste sous la diapo. Si vous n'avez aucun sonore (Firefox avec bloqueur de Flash), il vous reste le podcast en manuel, et alors là, bonne chance ^^;

Cette présentation est hébergée chez Slideshare.

NB : Le sonore a été édité parce que l'arrivée des retardataires et les chaises qui se pètent sont légèrement hors-sujets. Je suis désolé du humm que vous entendrez par instants, il est difficile de conférencer et de gérer l'enregistrement en même temps. Les diapos comprennent deux modifs pour présenter les preuves matériels complémentaires.

Transcription

emoji :leçons pour le webdesign
dascritch.com
Jai deux grandes passions :
● La téléphonie Japonaise
● L'unicode(bon en fait, j'en ai dautres)
L'actu immédiate emoji
● entrée officielle dans unicode version 6.1
● disponibles dans l'iPhone, toutes locales
● disponibles dans certains Android (appli clavier installée par des opérateurs)
1999, Le monde : GSM (ou CDMA)
● Best seller : Nokia 3210
● Écran monochrome 72 × 28
● Sonnerie mono
● Navigation haut/bas
● SMS
● Si support wap (téléphones haut de gammes), 1200 bauds, à se configurer à la main
● Constance UI web mobile ? SRSLY ?
1999, Japon : Les feature phones
● Matériellement bloqués à un opérateur, protocoles propriétaires
● Écran couleur (au moins 120 par 80)
● Sonneries midi, voire samples
● croix directionnelle
● Accès data préconfiguré
● Liés à une adresse e-mail
● Pouvant aller sur le web (sort of)
Marché domestique
● 120 millions habitants
● pouvoir d'achat assez important
● renouvellement dune chaine hi-fi : 18 mois
● porté sur la nouveauté et les modes
● équipement faible en ordinateurs familiaux
● transports en communs longs
Internet sur 携帯電話 (1999)
● Préconfiguré
● Écran couleur affichant les kanji
● Web proprio à guidelines assez importantes dont usage <a accesskey="0…9"> donc interface constante
● API de paiement de service intégré, avec très faible marge opérateur
● Vision Japonaise : proposer un max de services
● 9600 bauds
Des fonctions très en avance
Appareil photo Japon : 2000 Europe : 2004
Lecteurs QR CodeJapon : 2004 Europe : 2011
NFC embarqué Japon : 2004 (Felica) Monde : 2011
TV broadcast pour mobiles Japon : 2006 (1Seg) Monde : (mouahaha)
Dragonne Japon : 1994 Europe : 2002 Apple : 2012
Les systèmes d'écritures
● 46 hiragana ひらがな
● 48 katakana カタカナ
● 1945 kanji 漢字
● 52 romanji (alphabet latin)
● une centaine de ponctuations
● à ceci, ils ont ajouté une centaine d'emoji (ils nen étaient plus à ça près en ROM)
C'est quoi un emoji ? Mot valise : emotion ji
Caractère semi-graphique intégré à la police texte
Rendu géré comme pour un texte
Pictographes : Pensez aux dingbats
Pourquoi ? (* ￣ m ￣ ) (^^;) (>_<)> m(_ _)m ⌒▽⌒ ） (#^.^#) (ToT)（● ´∀ ｀）ノ♡ ♡ o ｡ .(✿ฺ ｡ ✿ฺ)
Un moyen idéal d'unifier l'UI
● Menu internes du téléphone
● Illustrations dans les e-mails
● Portail de l'opérateur
● Sites édités par les tiers
Usage codifié par les guidelines opérateur
13. Un symbole texte / une image
● Pixel art
● Taille originelle entre 12×12 et 15×15 (maintenant vectorisée)
● en couleurs
● animée
Image préchargée en dur
● Économie de bande-passante (non négligeable quand on était à 9600 bauds)
● Plus grande réactivité du site
● Pas dimage absente/cassée
Des palettes d'emoji thématiques Aspect pouvant changer selon le modèle de téléphone Exemple: MVNO Disney Mobile
Design industriel © Copyright sauf que cela ne les a pas empêchés d'avoir des symboles très très proches
Petite démo Mitsubishi m420(2005, i-mode chez Bouygues)
Des procédures dappels... ... non standards (aspro anyone ?)
SAUF QUE avant l'unicode, ya plein de charsets JIS JIS X 0208 Shift_JIS ISO-2022 EUC-JP et chacun a placé ses emoji où ça lui plaisait...
Pourquoi faire simple ?
Unicode 6.1 cest de la magie : Apple, Google,les 3 opérateurs concurrents ont recasé les emoji dans un standard commun
Vous croyez que cela ne concerne que le Japon ? En fait,on refait les mêmes erreurs !
Avec l'arrivée des webfonts On voit des sites utiliser des polices qui remplacent une lettre par un symbole. Par exemple : J => téléphone
4 fois le même texte
Et en accessibilité ?Imaginez ceci lu par une synthèse vocale : J +33 5 34... K +33 7 99... L +33 5 72... MHRF
Répétez ce mantra :Une consonne est une consonne, un chiffre, un chiffre, une virgule, une virgule, point.
Utiliser des symboles :Petit retour dexpérience
Contexte : set-top box Univers défini par un constructeur
4 résolutions possibles : ● NTSC ● PAL ● 768p ● 1080i
(et les scopes 16:9 ou 4:3, letterbox, pan&scan)
Créer une interface player indépendante de la résolution se passer des images utiliser les caractères symboles problèmes d'adaptations gérés par la box BIG WIN !
sauf que...la box utilisait une très vieille version de la font
TL;DH
Un caractère est l(élément le moins accessible par rapport à une balise <img /> ou une extension xml
Il faut utiliser un symbole pour ce qu'il signifie pas ce qu'il évoque vaguement pour vous
Il ne faut jamais utiliser une police qui met des glyphes visuels à la place des symboles conventionnels
Avant d'utiliser une police dingbats vérifiez que le symbole n'est pas déjà officiellement présent en unicode
Si vous utilisez une police qui crée ses symboles vérifiez qu'ils sont bien définis dans le champ “usage privé” de l'unicode surtout pas en “expérimental” ou “non encore attribué”
Si vous utilisez un symbole relativement récent Il faut que lOS, les bibliothèques et logiciels acceptent des versions récentes de l'unicode
et qu'il aie une police avec ces glyphes (ou les fournir)
Si vous utilisez les variantes “enrichies”Il faut que le système de rendu accepte les polices couleurs Si vous êtes dev : Javascript/DOM Android/Java Attention au charset interne utilisé par votre langage :UCS-2, UTF-16, MUTF-8, CESU-8

Je fais des conférences sur tous les sujets pour animer vos baptêmes, mariages, bar mitzvah et assemblées générales d'actionnaires…

Des emoji dans l'Unicode ⑤ Leçons pour le webdesign

Da Scritch — 2012-09-18T10:45:00+02:00

Tout est affaire de diplomatie au Japon : de ne pas perdre la (type)face, et de ne pas la faire perdre à la partie adverse. C'est très policé…
Webdev

Ce billet fait partie de la série des emoji dans l'Unicode et a été proposé comme sujet candidat à Sud-Web 2012 :

Bonus

Présentation en live

Allez, dernier épisode. TL;DR ? Sautez directement aux conclusions et apprenez par cœur la leçon. J'en parle ce soir lors de l'Apéro Web chez Occi-tech. Et y'en a des choses à découvrir.

Dissymétrie des systèmes

Vous avez vu que trois opérateurs ne veut pas dire 3 mais bien 12 manières différentes d'appeler (quasiment) le même emoji. Tant que les téléphones ne marchaient que sur l'archipel et ne pouvaient changer de réseau, on faisait avec. Mais quand Apple a voulu vendre ses iPhone au pays des feature phones, les gaijin venus de Cupertino ont dû sentir des sueurs froides quand les opérateurs leur ont parlé d'emoji. Dans la pièce à côté, l'équipe commerciale venait enfin de convaincre leur partenaire qu'ils n'avaient pas besoin de créer une mascotte pour promouvoir l'iPhone.

Apple était obligé d'inclure les emoji sur ses iPhone pour pouvoir les vendre au Japon : Le public est archi-demandeur.
Ils furent donc inclus lors du lancement de l'iPhone au Japon, mais, pour des raisons à la fois de copyright et du manque de standardisation, uniquement accessible pour les clients SoftBank (l'opérateur nippon qui a eu l'exclu du bestiau).
Le système d'exploitation iOS étant censé uniforme pour l'ensemble des portables de la gamme, ces emoji étaient donc présents, mais inaccessible sur les autres locales. À moins de connaître la commande magique.

Mais comme en France, le tabou de l'opérateur exclusif venait de péter, Apple préparait déjà une distribution sans exclusivité nationale. Or, on l'a vu dans le tableau, chaque opérateur Japonais avait sa méthode d'appel incompatible. De son côté, Google commençait à proposer son système Android, directement concurrent d'Apple. Sauf qu'Android est thémable, ce qui permettait aux opérateurs/fabricants de créer des keitai très… très, quoi.

Les deux concurrents en venaient à la même conclusion : il était sage de ne froisser personne, et de faire des réunions de conciliation via le consortium unicode. C'est ainsi qu'Apple et Google ont travaillé de concert afin de standardiser les emoji.

C'est une spécificité du monde des affaires au Japon : on peut réunir 5 sociétés dans la même pièce qui ont tout pour s'étriper, et que personne n'en ressorte mécontent.

À moins que l'envie d'avoir un iPhone…

Unification (nan, ça n'est pas un cri de guerre de super-sentaï)

C'est ainsi qu'a commencé un travail de titan :

Autour de la table, tout le monde est d'accord, internet doit être unifié, l'unicode est l'avenir. Fini les charsets un peu bizarre genre Shift_JIS, les bricolages à plans alternatifs, les balises étranges et les attributs XML bizarroïdes référencés dans aucune DTD, les références à des éléments ROM embarqués propriétaires, etc…
HTML5 et unicode, purs et standards. Enfin.

Il a été vite convenu qu'aucun point d'appel propriétaire d'un opérateur ne sera standard. Surtout ceux qui utilisent des points CJK standardisés, et on libère les plans à usage interne. On repart de zéro, tout le monde perd la face, donc tout le monde est prêt à discuter. On raccroche aux symboles déjà existants si c'est possible. Pour les autres, il ne reste de la place qu'après U+10000, mais on est en 2012, donc cela pose beaucoup moins de problèmes qu'avant d'indexer les caractères au-delà de 2¹⁶.

Malgré tout, la tablée a dû convenir que certains glyphes ne pouvaient pas être dédoublonnés, à cause de l'usage. Par exemple, il existe déjà en unicode un symbole pour les établissement bancaires. Alors pourquoi ajouté les deux versions emoji ? Comme on l'a plusieurs fois dit, les Japonais sont friands de jeux de mots plus ou moins obtus. Le symbole des banques est en général symbolisés sur les keitai par les lettres BK (exemples : ). À l'usage, les Japonais ont utilisé cet emoji sur les e-mails/bbs/forums, mais pour une tout autre signification : « Baka ! » (« Débile ! »). Comme le symbole unicode des banques n'a pas forcément ces deux lettres, il était important de recréer ces symboles, U+26FB ⛻️.

Tableau de démonstration des variances caractères extrait du site du Consortium Unicode
26FA FE0E		TENT text style
26FA FE0F		TENT emoji style
26FD FE0E		FUEL PUMP text style
26FD FE0F		FUEL PUMP emoji style

Tous les négociateurs du Consortium Unicode durent phosphorer, trouver une astuce pour accepter des caractères en couleurs, et que cela soit applicable à n'importe quel glyphe indexé. Oui, parce que des emoji monochrome, c'est franchement trop tristounet. Le truc consiste à utiliser les indications de variantes après le caractère, comme une espèce d'accentuation. Une variante implicite pour la version monochrome qui sera plus pratique à utiliser pour tous (U+FE0E). Et une autre variante pour la version couleur (U+FE0F) qui pourrait être éventuellement être animée, pour ceux qui aiment les gros défis techniques.
Ainsi, le café ☕ U+2615 peut prendre des couleurs si on ajoute le caractère (invisible) ☕️ U+FE0F, ce qui donnerait le code html ☕️. Astuce qui ne pose pas de problèmes pour les systèmes ne le supportant pas.

Les opérateurs furent d'accord pour “libérer” le jeu des emoji, puisque certains sont des designs industriels protégés. Mais comme pratiquement tous les emoji ont été clonés entre opérateurs, ce n'était qu'acter ce qui se faisait déjà.

Nouveaux caractères surprises

Parmi les nouveaux groupes de caractères, on note l'arrivée de binettes d'animaux, principalement de chats et de chiens. Ben oui, on est dans le pays de la kawaii-attitude.
L'arrivée de nourriture, aussi, avec une très nette dominante asiatique (à partir de U+1F354). En Asie, ils sont peut-être plus obsédés que nous dans la représentation de la nourriture.
Autre arrivée, celle de bâtiments et enseignes, notamment les distributeurs bancaires, les hôpitaux, les hôtels et… les love hotels (si si ! U+1F3E9 🏩 qui va de pair avec l'archi-~~sexy~~ sexiste symbole de la femme avec des oreilles de bunny (U+1F46F 👯, celui-ci, j'attends son entrée dans un iPhone ou dans Windows), mais pas avant d'avoir mis tous les nouveaux cœurs dans l'e-mail à votre partenaire (U+1F493 💓 à U+1F49F 💟, plus les versions emoji).

Perso, je n'oublierai pas U+1F4BD 💽 avec une larme émue. Tandis que les propagateurs de memes auront découvert le symbole officiel du caca mignon. U+1F4A9 💩 « Pile of poo ».

Tous ces caractères font désormais partie de la sarabande unicode, version 6.1, environ vers U+1F300,
soit dans ce film, 1h24mn :

vidéo par Decode Unicode hébergée chez Vimeo

Des erreurs que nous faisons encore

Cet article, même si son écriture a commencé en Avril 2009, est toujours d'une actualité brûlante.

Depuis l'arrivée des webfonts universelles (n'oublions pas que MsIE6 avait déjà une fonction équivalente), plusieurs webdesigners ont crû intelligent d'utiliser une police dingbats.
Erreur ! On abandonne complètement la sémantique originelle des symboles et des lettres. J'avais déjà parlé de la sémantique de certains caractères séparateurs de mots ou de syllabes.

Vous allez p'têt pas m'croire, mais y'a écrit 4 fois la même chozeuh.

Si une police gothique peut être lue, c'est qu'un « F » dessine un « F ».

Imaginez un site qui utilise des « J » , des « P » et des « 5 » disséminés... mais qui symbolisent un téléphone, une enveloppe ou une carte bancaire stylisée avec une police dingbat très précise.
Vous êtes alors lié à la présence de cette police, car aucun fallback ne pourra convenir : Un tel comportement n'a évidemment rien de standard, et donc aucune autre police dingbats convenir pour votre petite fantaisie de présentation.

Répétez ce mantra :

Une consonne est une consonne,
un chiffre, un chiffre,
une virgule, une virgule,
point.

Dans le cas où le navigateur n'arrive pas à charger la webfont, c'est un peu incompréhensible. Si on prend un navigateur web de type lecteur braille pour les aveugles, c'est carrément une idée stupide comme le dit poliment Raphaël Goetter. Et ça l'est d'autant plus si justement les symboles que vous comptiez utiliser ont déjà leur rond de serviette numéroté sur les plans de table de l'Unicode.

C'est justement pour éviter le cas de figure des documents Ms-Word (au hasard) remplis de fioritures avec des polices dingbats, (sans parler de ce genre d'aberration) que le Consortium Unicode a prévu plein de ces caractères fantaisies. Il y en a même un chapitre complet sur le sujet, en PDF, qui précise bien que les implémentations n'ont jamais valu des poursuites d'Hermann Zapf, fondeur de la police dingbat la plus connue. Sur plusieurs plans, vous retrouverez toutes les étoiles, boulets (arf!), symboles “universels” pour ne pas avoir à substituer un caractère significatif. C'est même encore mieux puisqu'il n'y a plus à prévoir la disponibilité d'une telle “police”, et qu'en cas de lecture de ce type de texte par exemple par une synthèse vocale, ben ces symboles du coup prennent une réelle signification.

Si vous désignez une police et que vous créez des glyphes spécifiques (l'exemple avec Font Awesome), utilisez toujours les adressages « usages privés » pour les installer. Ne faites jamais de substitution ! Et au mieux, essayez de voir si la description de votre glyphe ne correspond pas déjà à une entité Unicode existante.

Il existe d'excellents outils pour surfer sur l'unicode, installés de base dans tous les bureaux.
Ici, kcharselect , fourni par KDE4. Classé par thèmes, descriptifs complets, codes, très utile.

La bonne pratique ? il est plus intelligent d'utiliser les fameux emoji qui pourraient être interprétés. La sécurité étant de trouver bien évidemment une webfont universelle (jusqu'à MsIE 6) qui comporte dans ses symboles, lesdits emoji. Oui, je sais, il n'y a que 5 ans, il était très difficile de trouver une police fantaisie qui vous plaise avec toutes les lettres accentuées et le symbole euro…
Une des propriétés les plus intéressantes des bibliothèques d'affichage de texte utilisant les plans Unicode, c'est qu'en cas d'absence d'un pan particulier de caractères dans une police d'affichage, celle-ci est substituée par une autre police comportant le glyphe manquant. C'est pour ça que si une police ne comporte pas les lettres accentuées françaises, votre système d'exploitation va tenter de la remplacer par la même lettre issue d'une des polices génériques. Il vous est sûrement arrivé de trouver un “é” en Arial en plein milieu d'une si belle police cursive (si si, regardez le tableau plus haut). La plupart du temps, pour un symbole peut fréquent du type dingbats, c'est ce qui arrive.
À noter que le kit de développement pour l'Europe de sites i-mode comportait un document en “.tte”, soit une extension des polices TrueType.

Autre exemple : retour d'expérience avec les glyphes symboles

Pour une application à destination des télévisions connectées, j'avais proposé de remplacer l'usage des images et (presque) des emoji. La raison était simple : la set-top-box était susceptible d'avoir au moins 4 résolutions différentes (du NTSC au 1080), sans compter les variations de ratio (16:9, 16:10, 4:3,…). Même si je ne suis nullement web-designer, j'avais prévu bien en amont d'utiliser des dimensions relatives.

J'avais donc proposé d'utiliser ◀◀ ▮▮ ▶ ⬛ ▶▶, des glyphes présents depuis près d'une décennie dans le thesaurus unicode. ce qui facilitait grandement les animations d'interactions qu'on allait pas tarder à me demander, mais surtout évitait un abscons labeur d'adaptation graphique pour des éléments de décor triviaux. Comme je l'ai dit, je suis un piètre web-designer.
Et avouez que ça a de la gueule :

◀◀ ▮▮ ▶ ⬛ ▶▶

Enfer et damnation, la box en question, pourtant conçue par un très grand du web et utilisant une police très présente sur les distributions Linux, ne disposait pas des susnommés caractères unicodes. Sa version de police embarquée datait de plus de 2 ans, alors que la box était sorti 2 mois plus tôt.
Elle y affichait en lieu et place les fallbacks, comme précédemment décrit : du ▯ là où on attendait des jolis symboles de magnétoscope.

P▯▯▯▯n de b▯▯▯▯l de m▯▯▯e, il a fallut remettre en cata des images, dans les au moins sets de 4 dimensions prévus.
Et les ratios.
Et les scopes.

N'oubliez pas

Ces règles devraient être enseignées au burin depuis l'arrivée de l'unicode :

Un caractère est l'élément le moins accessible, par rapport à une balise <img /> ou une extension xml
Il faut utiliser un symbole pour ce qu'il signifie, pas ce qu'il évoque vaguement pour vous
Il ne faut jamais utiliser une police qui substitue des symboles à la place des caractères attendus
Avant d'utiliser une police dingbats, vérifiez que le symbole n'est pas déjà disponible officiellement en unicode
Si vous utilisez une police qui crée ses symboles, vérifiez qu'ils sont bien définis dans les plans “usage privé” de l'unicode (principalement, U+E000 à U+F8FF), et pas en “réservé”, “expérimental” ou “non encore attribué”
Il faut que les cibles (OS, bibliothèques et logiciels) acceptent des versions récentes de l'unicode si vous utilisez un symbole relativement récent
Il faut que le système hôte client dispose de polices comportant les glyphes pour les nouveaux caractères (ou les fournir)
Il faut que le système de rendu accepte les polices couleurs (si vous utilisez les variantes “enrichies”)
Concernant le développement web : si vous faites des manipulations DOM, il faut que le javascript du navigateur manipule les chaînes de caractères en UTF-16 et pas en UCS-2. Ben oui, certains emoji sont placés largement au-delà de l'index U+10000. J'ai déjà un billet en écriture sur cette dernière surprise.
Concernant le développement mobile sous Android, gaffe si votre code manipule en interne les chaînes en MUTF-8, puisque cela modifie le comportement d'affichage pour les points unicodes U+10000 à U+10FFFF. Une région plus proche du UTF-16 (c'est le mode CESU-8, compromis bizarre entre mémoire et optimisation pour l'embarqué) que de l'UTF-8 que vous attendiez.

Dans le doute, restez aux bonnes vieilles balises images, sans oublier bien sûr de renseigner l'attribut alt="" car il risque d'être significatif

Merci de votre lecture

Il convient de re-remercier pour leur aide indispensable :

AperoWeb Toulouse et SudWeb pour m'avoir donner envie d'en faire une suite de billet, puis une conf
Paul Rouget car il a proposé d'utiliser des webfonts dingbats, ce qui m'a fait sursauter
Laurent et Rieko Nespouslous, amis précieux, qui sont repartis vivre au Japon
Frédéric Boilet pour qui Tōkyō est un jardin
mes contacts pros et du groupe Index au Japon, aux éditeurs Japonais avec qui j'ai eu l'honneur d'échanger et de travailler
Dominique Vérêt et Erwan Leverger pour leur travail visionnaire
Rafy, Sébastien et Claude Yoshizawa, car je désespère pas, grâce à eux, de pouvoir libérer des archives

Une grande partie du texte a été rédigé le 9 Février 2012 (!). Le plus dur, c'est parfois trouver les illustrations.

Mon blog n'a pas pour vocation de fournir un thesaurus, un dictionnaire ou un aide-mémoire sur les balises HTML, les astuces javascript ou les caractères Unicode. Mais j'estime qu'il était utile de faire ce travail.
…pour récolter vos visites (uhuhuhuhu).

Des emoji dans l'Unicode ④ Chacun a sa manière

Da Scritch — 2012-09-11T10:50:00+02:00

Pourquoi trois opérateurs ? Parce qu'on peut faire la même chose de 12 manières différentes. Bienvenue dans un univers purement propriétaire.
Webdev

Ce billet fait partie de la série des emoji dans l'Unicode et a été proposé comme sujet candidat à Sud-Web 2012 :

Bonus

Présentation en live

J'avais parlé de l'étonnante uniformité graphique et fonctionnelle de ces emoji entre les trois opérateurs mobiles Japonais. Pourtant, ces trois fournisseurs d'accès mobiles ont longtemps été strictement incompatibles entre eux. Un téléphone acheté chez KDDi n'avait aucune chance de fonctionner sur le réseau DoCoMo : les fréquences, les protocoles radio, les méthodes d'identifications, les API réseaux, les logiciels étaient strictement incompatibles entre les 3 opérateurs, jusqu'à la démocratisation de la 3G vers 2004. Et encore…

Quand les trois opérateurs commencèrent à intégrer un navigateur web mobile en 1999, lançant donc la mode des features phones propre à l'Empire du Keitai Levant, chacun créa sa norme totalement incompatible avec le voisin. Pour aggraver l'absence d'interopérabilité, chaque opérateur imposait de servir des pages mobiles avec un jeu de caractères (charset) totalement différent et incompatible de l'autre (JIS, ISO-2022, Shift-JIS, EUC et autres variantes…). Aller sur un site EZ-web avec un i-mode n'était même pas imaginable.

TL;DR ? OK, si tu me crois pas…

Bref, l'achat d'un téléphone était lié à l'opérateur. Avec une gamme foisonnante de modèles exclusifs à ce réseau, et de services eux-aussi exclusifs.

(comme ça manquait d'une illustration un peu positive vue la lourdeur du sujet, je vous ai mis la gamme Pantone™ officielle dispo via SoftBank, qui en plus mesure les radiations, ça devrait motiver les graphistes, heeeiiin…)

À la décharge de tout ce beau monde, l'Unicode n'avait pas encore de plan CJK stabilisé, donc la position des sinogrammes communs entre Chinois, Coréen et Japonais était extrêmement floue, peu propice à être gravée dans le silicium. Et à cette époque, dans l'embarqué, personne ne s'amusait à faire de la mise-à-jour logicielle d'une flottille complète.

Petit tour des trois opérateurs Nippons

Et vous verrez que ce n'est pas superflu pour comprendre quel sac de nœud cela a été d'intégrer les emoji dans l'unicode.

l'i-mode, par NTT DoCoMo

DoCoMo est la filiale mobile de l'opérateur historique NTT. Il a lancé le service web mobile i-mode en février 1999, introduisant le concept des feature-phone, téléphones intégrant un client e-mail et un client web propriétaire très simplifié, concept qui a été très rapidement repris par les autres opérateurs.

L'i-mode est un concept différent du tout XML à l'époque prônée par le WAP : on reprend le HTML et on en garde que ce dont on en a besoin pour un petit écran. D'où le nom cHTML, véhicule compact pour circulation peu fluide. Pour développer, n'importe quel navigateur web suffisait et les modifications minimes : avoir réduit la largeur de fenêtre, avoir appliqué un style pour la hauteur de police, avoir installé emoji.tte sur son ordinateur.
Un document avec une extension .tte est un fichier de définition supplémentaire de symboles qui complète toute police .ttf, un particularisme que je n'ai vu que dans le monde MS-Windows, et qui arrivait parfois à faire buguer des imprimantes, donc handle with care !

Le navigateur natif utilisé est NetFront, développé par Access Inc. À noter qu'il était disponible pour Linux jusqu'en 2006.

Le menu d'un feature-phone i-mode, capturé en 2006 par 5Myths.com
Notez les numéros de raccourcis accesskey pour les chapitres, et la première ligne, propre au téléphone, générés en emoji.

Point intéressant, et on va voir à quel point cela va encore compliquer les choses, DoCoMo va proposer sa norme aux autres opérateurs mobiles, via son i-mode Alliance. Bouygues Télécom proposera le service en France en Novembre 2002. Le contrat imposait aussi aux opérateurs franchisés d'appliquer le même type de marge (environ 13%) qu'au Japon, ce qui les changeaient des 50% pratiqués en wap.
Les trois principes de simplicité technique, d'uniformisation des UI et de reversement important vers les éditeurs de services ont permis une forte éclosion de sites mobiles comparés au wap. Cela a permis à de petits éditeurs de se lancer, chose qui était inimaginable en wap vu les difficultés techniques et les marges maigrichonnes. Malheureusement, le caractère à la fois de niche, l'exclusivité concédée à un seul opérateur par pays, certaines extensions propriétaires et la marge opérateur moins importante ont fait que la plupart des services hors-Japon se sont clos avant 2008.

En quoi l'i-mode pour gaijin est différent de la version native ? Tout simplement parce que les points d'appels des emoji, leurs index dans le jeu de caractères, sont différents entre le Japon et le reste du Monde.
La version originale n'avait été prévu que pour le marché Japonais, pour un jeu qui n'avait pas prévu les caractères accentués si appréciables dans nos langues de long-nez. Comme dit plus haut, ces emoji empiétaient dans ce qui allait devenir le plan CJK de l'Unicode, et de toutes façons, l'opérateur demandait d'utiliser un charset qui était plus prévu pour la langue Japonaise, ce qui en limitait l'exportation.

Deuxième effet Kiss Kool : les points d'appels démarqués des emoji entraînait une régionalisation des offres. Ce qui évitait de tenter les Japonais d'aller voir sur les sites étrangers. L'inverse était assuré par le fait que les mobiles exportés n'embarquaient pas de polices pour afficher kana et kanji Japonais.
Vous avez dit “DRM-isation” ?

Yahoo mobile ! (ex Vodafone Live!, ex J-Phone), par SoftBank

L'opérateur a changé plusieurs fois de nom : J-Phone, puis Vodafone KK après son rachat par Vodafone, puis SoftBank une fois re-repris par des investisseurs Nippons. Inutile de dire que ces changements à la fois d'actionnaire majoritaire, mais aussi de fins et de culture corporate ont fortement marqué l'opérateur et donc ses technos maisons.

Le logiciel de navigation embarqué semble avoir été développé en interne, et le nom J-Sky désigne à la fois le navigateur lui-même et l'écosystème des sites. Le langage employé, JHTML (J-Sky's HTML) est dérivé du XHTML. C'est donc un HTML avec un vocabulaire restreint, mais l'écriture stricte du XML ce qui demande un minimum de rigueur mais n'est pas insurmontable.

Les emoji étaient “balisés” par Ctrl+N et Ctrl+O. C'est une fonction standard de l'ASCII qui permet de jongler entre deux polices de caractères. Ceux qui ont fait de l'édition bilingue sur MS-DOS ou des pages semi-graphiques sur Minitel se souviendront avec émotion de cette bidouille. À noter qu'elle marchait aussi par e-mail (Le service e-mail mobile de cet opérateur est appelé sha-mail), mais que J-Phone a prévu par la suite dans son client embarqué l'appel via point unicode.

En 2001, les équipes de Vodafone s'intéressent fortement à la possibilité de créer un portail et un écosystème de service pour les différents opérateurs nationaux (Angleterre, Allemagne,…) ou leurs partenaires locaux (SFR pour la France). C'est ainsi que J-Phone est racheté par Vodafone en 2003, entraînant un rebranding de leur marque en Vodafone KK, et lançant le service Vodafone Live ! partiellement inspiré du J-Sky dans le reste du monde.

On peut noter que si J-Phone était nettement en pointe technologiquement, la période Vodafone lui a fait perdre de nombreux clients : Les décisions de conceptions d'interfaces et de services étaient menées par l'équipe Londonienne de Vodafone, qui réagissait avec un retard conséquent sur les attentes de la clientèle nippone et les offres des autres opérateurs nationaux. Une des plaintes les plus récurrentes était que l'interface de Vodafone Live! qui a remplacé l'environnement J-Phone était trop déconcertante pour les clients Japonais.

Le menu du portal captif Vodafone KK, capturé en 2004 par 3g.co.uk
Les Brits de Vodafone n'ont rien compris et ont fait supprimer les emoji accesskey (genre ), ils ont heureusement gardé ceux symbolisant les services.

Devant la catastrophe économique pour le groupe, et aussi une situation mondiale serrée, Vodafone a revendu à l'opérateur SoftBank ses activités mobiles au Japon, lesquelles ont été renommées SoftBank Mobile. L'opérateur était devenu entretemps le distributeur exclusif de l'iPhone au Japon mais n'arrivait pas à le faire décoller faute d'emoji.

EZ web par au/KDDi

KDDi (issu de la fusion d'opérateurs régionaux) commercialise ses offres mobiles sous la marque au. Oui, en minuscules, c'est pour ça que je l'ai mis en italiques. La signification est un subtil jeu de mots multiples à tiroir entre le Japonais et l'Anglais (en gros, l'idée de communauté, d'unité et d'accès), comme les Japonais en raffolent pour mieux vous perdre. Pour ne pas vous larguer dans la lecture, je noterais au/KDDi.

Les services web mobiles sont sous la marque EZweb (pour easy) et les e-mails sous la marque c-mail.

KDDi a créé son univers mobile captif lourdement sur le wap. Oui, ouïlle. Le navigateur référent a été OpenWave édité par la société homonyme. Un logiciel installé sur de nombreux téléphones wap en Europe, de sinistre mémoire pour les développeurs… Il faut dire que ce logiciel était aussi utilisé par les téléphones Motorola, Alcatel et Samsung pendant la première moitié de la décennie 2000, mais se montrait notoirement peu pratique : Interface brise-bonbons, lente, très lente, variations trop importantes de rendus parfois entre téléphones de la même gamme, application susceptible d'exploser en plein vol, devoir travailler avec était synonyme d'un long chemin parsemés d'embûches. Néanmoins, je ne peux juger de la version acclimatée au Japon par au/KDDi. La syntaxe étendue créée par l'opérateur s'appelle le HDML.

Le menu d'un feature-phone au, capturé en 2006 par 5Myths.com
Chaque ligne a son symbole numérique accesskey et une icône

Comme J-Phone, au/KDDi a très vite proposé une plage de caractère étendue pour ses emoji, afin qu'ils puissent être transmis par e-mail, et bien évidemment tous les points de chaque emoji est totalement différent par rapport aux deux concurrents.

Résumé des technos en place

Opérateur Maison mère	Nom commercial web mobile e-mail	Lancement commercial	Techno page web	Charset original	Appel emoji web	Plage unicode officieuse début	Plage unicode officieuse fin
DoCoMo NTT	i-mode i-mail	février 1999	cHTML	JIS, Shift_JIS	entitées XML, points unicode officieux		聆
i-mode Alliance sous licence dans différents pays	i-mode i-mail	2002~2004	cHTML	Windows-1252, ISO-Latin 15	plan de caractères étendus		
SoftBank Mobile SoftBank	J-Sky/Vodafone Live! sha-mail	décembre 1999	JHTML/XHTML	EUC-JP, ISO-2022-JP, Shift_JIS	page de caractère alternative		
au KDDi	EZ web EZweb@mail	novembre 1999	WAP2 étendu "HDML"	Shift_JIS	balise HDML <img icon="numéro" /> balise XHTML <img Localsrc="https://dascritch.net/post/2012/02/16/numéro" />		

Notes : concernant le charset, l'unicode, principalement en UTF-8, a fait son apparition courant 2004. Plus d'infos sur cette excellente page.

Exemples d'appels d'emoji

Mettez-vous à la place d'une passerelle e-mail. Déjà, vous souffrez le martyre.
Maintenant, imaginez que vous devez créer un service mobile accessible pour les trois opérateurs... Bien souvent, des entreprises (et pas des moindres) faisaient l'impasse sur un opérateur.

opérateur	mode	touche 1 (<a accesskey="1"…)	Thermes/Bains publics	Soleil	Happy smiley
i-mode DoCoMo	web (point unicode)	驪	列		秊
i-mode Alliance	web (point unicode)				
j-sky	plage ascii alternative	1B 24 46 3C 0F	1B 24 45 43 0F	1B 24 47 6A 0F	1B 24 47 77 0F
KDDi au	HDML	<IMG ICON=四角数字１>	<IMG ICON=温泉>	<IMG ICON=太陽>	<IMG ICON=顔１(うれしいカオ)>
KDDi au	XHTML	<img localsrc="https://dascritch.net/post/2012/02/16/四角数字１" />	<img localsrc="https://dascritch.net/post/2012/02/16/温泉" />	<img localsrc="https://dascritch.net/post/2012/02/16/太陽" />	<img localsrc="https://dascritch.net/post/2012/02/16/顔１(うれしいカオ)" />
KDDi au	e-mail Shift-JIS	EB FB	EB 95	EB 60	EB 49
KDDi au	point unicode				

(hurlez pas sur les trucs couleur rose bonbon, j'ai été assez gentil pour prendre ceux qui clignotent pas )

Oui, l'appel HDML est un peu bizarre, pour pas dire très peu orthodoxe pour du xml strict... sachant que chez KDDi-au, il y a 5 encodages, donc 5 points différents pour les envois par e-mail... ("EZmail" qu'ils disaient...)

Et là, vous vous demandez comment on a réussi à concilier tout ce beau monde pour unifier les emoji, les mettre aux mêmes points unicode… Je n'aurais qu'un mot : Négociations.

Ayant déjà conduit des négociations avec des entreprises Japonaises, je peux vous dire que la première vertu est la patience, la seconde, l'humilité afin de ne pas faire perdre la face à l'autre bout de la table. J'ose à peine imaginer toutes les difficultés du Unicode Consortium pour concilier les 3 opérateurs.

つづく , comme ils écrivent « à suivre »

Prochain épisode : Emoji “5”, designé par Apple" class="emoji"> Leçons pour le webdesign

Parce que oui, étonnement, même si vous n'avez que très peu de chances d'utiliser les emoji, ben y'a plein de choses à tirer de cette histoire.

À noter que ce dernier épisode ne devrait pas trop tarder, disons mardi prochain…? Ça tombe bien, je parlerai en live des emoji et des leçons à en tirer pour la conception d'interfaces web lors du prochain Apéro Web Toulouse. Ça sera chez nos amis d'Occi-tech. Nombre de places limitées, il faudra réserver.