da scritch net works - Mot-clé - regex

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

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

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

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

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

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

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

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

TL;DR Montre ton code !

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

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

Simple et basique

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

À améliorer

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

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

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

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

Brand new podcast

Da Scritch — 2014-09-30T07:20:00+02:00

Ça y est, les sonores @HalluFMR arrivent !
Radio

Oui, le Supplément Week-End est terminé, mais au même horaire, Ultimatom, Dusport et tous leurs comparses vous attendent pour leur émission Cross/Over. Toujours le Samedi de 12 à 14h, sur Radio <FMR>.

Et de mon côté, ce parano foutraque d'Eugène Lawn m'a demandé d'animer une petite rubrique dans son 17/19 du Mercredi, aka L'Hallucinarium. Occasion trop belle pour parler aux masses des enjeux du numérique, oui, mais attention : avec un ton pédant.

Je viens enfin de recevoir les sonores, pour 3 des 4 premières émissions. Profitez :

Rebecca purple (3/09)
Le dilemme Apple (10/09)
Loi de Lutte contre le terrorisme (17/09), sonore à venir
Les prix IgNobel (24/09)

Mes rubriques restent en licence Creative Commons, permettant par exemple à Jukast de proposer prochainement ma rubrique pour réveiller des gens au hasard sur Facebook.

Un petit poil de code

(et là, normalement, je largue tout le monde, mouahahaha)

Pour être définitivement honnête, il existe une multitude d'outils et de services en ligne qui gèrent très bien les podcast. Mais dans l'immédiat, je préfère en garder la gestion, et donc héberger les sonores et faire le code qui va avec.

Pour mes amis, Thomas, Olivier, etc... voici un petit script qui à partir du raw.wav me fait les deux fichiers nécessaires prêts-à-diffuser. Sachant que le format ogg vorbis est préféré au mp3 quand on reprend une archive en radio. J'ai déjà écrit sur les encodeurs Franhoffer, la connerie ambiante sur le MP3, sachant qu'on en retrouve beaucoup d'héritages dans la famille AAC, là où le ogg vorbis est prévu pour un bitrate variable et n'a pas été conçu par une équipe de sourds.

MP3 est le format le plus utilisé, mais non libre, Ogg Vorbis est mon format de préférence en html5 et passe sur pratiquement tous les navigateurs modernes, excepté Safari.

#!/bin/bash

NUMERO="4"
DDTMMTYY="24-09-14"
DDSMMSYY="24/09/2014"
SUJET="Les prix IgNobel"
YEAR="2014"
TRIGGER="AtHalluFMR"
EMISSION="Da Scritch @HalluFMR"
COPYRIGHT="DaScritch & co pour Radio FMR"
SITE="http://dascritch.net"
PADWAV="pad.wav"
oggenc -o "$NUMERO-$TRIGGER($DDTMMTYY).ogg" -t "$EMISSION: $SUJET ($DDSMMSYY)" -d "$DDSMMSYY" -N "$NUMERO" -a "$COPYRIGHT" -G "radio" -l "$SITE" -c "$SUJET" -q 6 $PADWAV
lame -b 128 --tt "$EMISSION ($DDSMMSYY)" --tn $NUMERO --ta "$COPYRIGHT" --tl "$SITE" --ty $YEAR --tg 20 $PADWAV "podcast/$NUMERO-$TRIGGER($DDTMMTYY).mp3" --tc "$SUJET"

Vous retrouverez sur github le snippet de template qui me sert à inclure les podcast dans mon thème dotclear, mais qui doit être accompagné d'une extension spécifique au langage de template.

Je l'ai écrit un peu trop vite, il manque notamment une regex pour automatiser le passage de DDTMMTYY à DDSMMSYY . Pardon, de (\d{2})\-(\d{2})\-(\d{2}) à $1/$2/20$3, et une sortie qui me donne le code HTML à mettre en entête de billet, j'irais nettement plus vite.

Mais là, ce soir, j'ai la flemme : y'a Castle à la tv.

Formulaire de contact ou mailto: ?

Da Scritch — 2014-08-19T09:40:00+02:00

Qu'aviez-vous prévu pour que les visiteurs de votre site puisse prendre contact avec vous ? Un formulaire Facebook ? Ou une pop-in d'assistante virtuelle à balconnet pigeonnant ?
Webdev

Source : Demco.fr

Durant mon activité de développeur indépendant (et en tant que salarié aussi), on m'a régulièrement demandé de mettre en place un formulaire de contact sur un site web. Ce que j'ai toujours fait sans rechigner.
Il faut que j'avoue qu'il n'y a rien de sorcier derrière : demander au visiteur de laisser un message, une adresse de contact, et envoyer le tout par e-mail.

Personnellement, si un formulaire de contact est du Porcinet — l'enfance de lard, bandes d'incultes — j'ai préféré utiliser la solution primitive d'un lien mailto: pour mon blog et mon site pro. Ce n'est pas par flemme, vous en comprendrez les raisons quand vous arriverez à la [TL;DR] conclusion.

Ce billet est mon hommage personnel à So-Use!, société toulousaine spécialisée dans l'UX, qui vient malheureusement de clore son activité.
Bonus :

(Firefox) Bug 1055950 - Form with mailto: action is wrongly escaping spaces chars

Ce que dit le standard

J'aimerais rappeler un point tellement important qu'il en est évident, mailto: est une URL normalisée dans la RFC 2368 et acceptée partout.

Merci ~~Capitaine Évidence~~ Captain Obvious !

Quand vous écrivez <a href="mailto:contact@example.com">, vous utilisez une notation URL raccourcie, qui s'écrit de manière développée comme suit : mailto:?to=contact@example.com

Oui, cela ressemble très fortement à une requête GET de formulaire. Étonnant, non ? Et justement, parmi les paramètres sur lesquels vous pouvez compter :

?subject=… permet d'ajouter un titre qui reste éditable par l'utilisateur,
?body=… permet de définir un template de corps de message,
?cc=… permet d'ajouter d'autres destinataires en copie carbone,

Ce sont les plus utiles dans votre affaire.

Pour votre info, vous en avez un exemple sur l'icône sociale Envoyer par e-mail,
posé plus haut sur cette page.

Alors certes, cette RFC comporte des limitations, notamment sur les caractères en 8 bits et l'unicode, mais dans les faits même ces exceptions sont implémentées partout.
Bien souvent, les demandes clients spécifiques pour un formulaire de contact venaient de l'ignorance de ces possibilités. Comme quoi, on ne relit jamais assez les standards.

Maintenant, comparons les deux possibilités :

Anatomie visuelle d'un formulaire de contact

Le formulaire, usage avancé

Le traitement côté serveur permet des petits bonus, notamment de stocker le message dans la base de données et d'être accessible directement en backoffice. De là, on peut le lier à une commande, à un ticket interne voire y accoler différents métriques comme le temps de réponse à la demande client ou le taux de satisfaction. Il peut aussi être ventilé sur plusieurs e-mails d'un coup, voire (ça, c'est ma fonction préférée sur mon application dagence) de constituer un digest quotidien afin de ne pas encombrer votre e-mail.
De telles fonctions sont aussi envisageables avec mailto: mais construire une passerelle de réception d'e-mail est autrement plus compliquée.

Si votre service web n'est pas un véritable intranet ou un backoffice industriel, vous pouvez le faire via un service tiers comme Formsite, le bien conçu Wufoo ou même un bête formulaire Google Drive.

Exemple de reporting de formulaires de contacts par Wufoo.
N'oubliez pas que ces services sont souvent basés hors Europe. Donc si les données récoltées sont exploitées commercialement à votre insu, vous en êtes juridiquement responsable, ce qui peut faire très mal.

Attention car si vous constituez une base de données à partir des e-mails, vous devez vous mettre en conformité en faisant une déclaration CNIL, en ajoutant des déclarations légales, un formulaire de rectification/désinscription sur votre site et bien sûr en ajoutant une checkbox à votre formulaire :

Je ne souhaite pas être démarché commercialement

Si vous devez le faire, c'est que votre site manipule suffisamment de données privées et vous l'avez normalement prévu.

Le formulaire, côté pragmatique

Maintenant, regardons à l'usage ce que donne un formulaire de contact :

D'abord, sur le champ e-mail, qu'est-ce qui vous assure que votre interlocuteur donne son e-mail réel ? ou qu'il n'a pas fait une faute de frappe ? Comparée à l'envoi standard d'un e-mail, ce champ est une saisie inutile.

L'espace <textarea> ne va-t-il pas frustrer votre interlocuteur ? Notamment sur les dimensions, puisqu'elles sont fixées par design. Ceci dit, depuis 4 ans, la question se pose moins puisque tous les navigateurs proposent de redimensionner à la volée un tel champ. Encore faut-il comprendre à quoi sert cette poignée, et ensuite que le graphiste n'aie pas supprimé cette fonctionnalité qui casse tout son design.

Le champ texte est simple. Il manque l'édition riche qui peut parfois être utile par exemple pour insérer un lien, et la possibilité de joindre des documents, notamment image, pdf ou vcard. C'est bête, mais vous imaginez mal combien une vcard est pratique en prospection commerciale.

À court terme, le formulaire va commencer à se faire repérer par des spammeurs, et vous commencerez à avoir des messages indésirables, et un bruit de fond non négligeable. Soit vous avez l'énergie et les moyens pour construire des services de filtrage sur votre serveur (je l'ai fait pour des clients de dagence et c'est vraiment épuisant), ou vous vous basez sur des services tiers genre Askimet avec les risques très importants de faux-positifs/faux-négatifs. Soit vous comptez sur l'installation économique d'un test de Turing, un captcha donc, qui sera tout sauf une incitation à vous laisser un message. Et encore, j'ai pas parlé des machines de Voight-Kampff…
Qui plus est, côté script serveur, il existe une multitude de possibilité d'attaques, de détournement du service d'envoi. Combien savent qu'il faut vraiment protéger la commande PHP sendmail() ? Et d'ailleurs pas qu'en PHP, car j'ai vu ce genre de vulnérabilité en Ruby.

Les gens aiment avoir une trace dans leur client e-mail ce qui est normal puisqu'un compte e-mail tient la trace de votre correspondance. Souvent nous profitons des systèmes de tris par discussion, par date, par mots-clés, par étiquettes. Un formulaire de contact est en dehors de cette correspondance. Sauf si le script côté serveur vous renvoie le message envoyé à votre adresse.
Mais ce genre de rappels est souvent exploité par des spammeurs. Oui, encore. Il faut dire que c'est facile : on automatise l'envoi d'un message, mais c'est le serveur exploité qui va se faire bannir et l'entreprise qui le loue va voir sa réputation descendre en flèche. Ce n'est pas un scénario de science-fiction, je l'ai vu chez un client moins de 3 mois après la mise en place du formulaire.

Au final, si vous ne prenez pas proprement en compte le risque de spam, votre site web pourrait être marqué comme spammeur par des serveurs d'e-mail, bloqué par des antivirus, se prendre une mauvaise réputation et vous ne recevrez plus du tout de demande de contacts.
Une fois qu'on se retrouve dans une telle situation, en général suite à une négligence qu'on a laissé traîner très longtemps, il en est difficile d'en sortir.

Le lien `mailto:`, côté pragmatique

On ne va pas reparler de la mécanique d'envoi d'un e-mail : en usage depuis 40 ans, le système est parfaitement maîtrisé, on peut donc lui faire confiance.

Hélas, depuis le début des années 1980s, l'e-mail est encombré de spams. Et depuis 15 ans, il existe des robots spiders qui ne font qu'une chose : récolter le plus d'adresses e-mail possibles pour spammer plus. La précaution élémentaire est de ne pas donner une adresse e-mail liée à une personne, mais de créer un compte ou un alias jetable.
Néanmoins, on peut se reposer tranquillement sur la cascade de filtres bayésien et autres qui seront en place entre votre interlocuteur, son FAI, votre FAI et dans votre client e-mail. Et avec l'avantage que tout est déjà configuré, fonctionnel et d'un coût quasi-nul.

Je répète : sauf pour un site personnel, n'exposez jamais en mailto: une adresse e-mail nominative. Une entreprise, collectivité ou association doit songer qu'une demande de contact peut être reprise par une toute autre personne qu'actuellement. Rien n'est immuable : comme tout corps vivant, ces entités morales sont destinées à changer pour rester en vie. Et au coût actuel d'un alias e-mail chez Gandi, pourquoi s'en priver ?

Un lien e-mail a un avantage énorme, difficilement quantifiable : contrairement à un formulaire web, il est forcément adapté au mieux suivant le type d'appareil qui accède à votre site : mobile, tablette braille, tout est forcément pris en compte au mieux.
Et avec les fonctionnalités manquantes, notamment texte enrichi ou ajout de pièces jointes, voire même une gestion automatisée de la signature électronique.

Le client de-mail natif sera forcément plus fonctionnel que n'importe quelle recréation en page web. Sauf si vous avez les moyens de payer des dizaines de spécialistes comme Google, Yahoo ou Microsoft.

Mais si votre visiteur n'a pas de compte e-mail sur cette machine, par exemple au travail, dans un web-café ou sur une machine qu'il ne peut juger de confiance, oui cela peut être frustrant.
Et il ne peut facilement employer une autre adresse e-mail, par exemple une adresse personnelle, un compte jetable ou celui d'une entreprise en cours de création, nous aurons le même souci.

Un lien vers une adresse e-mail demande le minimum de technologie, inutile d'avoir un script côté serveur. Le protocole mailto: marche vraiment partout. Et en cas d'absence, il peut même s'enregistrer par une application tierce, et d'ailleurs, gmail le fait.

Côté réception, un e-mail peut tout à fait entrer dans un flux de gestion, et un compte e-mail en Imap peut parfaitement être partagé entre plusieurs personnes. À vraie dire, je suis très surpris du nombre de gens qui utilisent quotidiennement un client e-mail comme Thunderbird ou Microsoft Outlook sans se rendre compte qu'ils pourraient se faciliter la vie en paramétrant un tri automatique et pallier à l'absence d'un outil de gestion documentaire tiers.
Là aussi, il vaut mieux se reposer sur l'existant, c'est nettement plus économique et fiable, même s'il faut passer deux heures à lire la documentation.

Message envoyé

Le formulaire de contact pose d'innombrables questions d'interface, de sécurité et d'utilisabilité. Celles-ci sont toutes répondues avec la solution la plus standard, la plus simple, le bête lien mailto:.

La seule utilité réelle du formulaire est l'absence d'e-mail direct, ce qui veut dire qu'il répond à une non-question.

Si vous devez vous poser la question, et que nous ne construisez pas une importante solution d'e-commerce, ne vous embêtez plus : les réponses les plus simples sont souvent les plus pertinentes.

Travaux d'été

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

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

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

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

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

Je refais mon site corporate

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

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

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

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

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

Mais pourquoi faire simple ?

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

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

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

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

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

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

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

Le faux calme

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

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

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

Ça va m'occuper.

Proposals about ‹img /›

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

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

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

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

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

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

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

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

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

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

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

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

A bright idea that might goes dark

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

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

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

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

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

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

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

Thinking about the current uses of images

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

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

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

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

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

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

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

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

What should the specifications have been

So typical : Life cycle of specifications

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

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

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

So why not using CSS ?

Source : Vancoosh, starring Frida

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

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

Proposal : srcset in css

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

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

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

And we can chain other scenarii :

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

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

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

Proposal : Using regex into css

Source : Halibustuff.com

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

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

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

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

Proposal : async="no"

CC0 author : Hans. Source : Pixabay.

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

Yep. I know.

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

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

In fine

Jumping water frog by agnatha3141

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

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

Just imagine :


article img {

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

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

}
 
.decor img {

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

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

}

Hard to be simplier…

And thank you for all the fish

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

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

Hope you so ;)

Propositions en ‹img /›

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

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

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

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

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

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

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

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

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

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

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

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

« Our kitty printer is running out of toner »
Tu m'étonnes.

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

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

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

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

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

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

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

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

Réfléchir aux usages actuels d'images

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

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

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

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

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

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

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

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

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

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

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

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

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

Et si plutôt on passait par les CSS ?

Source : Vancoosh, starring Frida

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

Cela demande beaucoup de nouveautés :

Proposition : srcset en css

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

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

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

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

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

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

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

Proposition : Intégrer les regex en css

Source : Halibustuff.com

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

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

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

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

Proposition : async="no"

CC0 Auteur : Hans. Source : Pixabay.

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

Ouais, je sais.

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

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

In fine

Jumping water frog par agnatha3141

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

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

Imaginez :


article img {

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

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

}
 
.decor img {

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

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

}

On ferait difficilement plus simple…

And thank you for all the fish

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

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

Sans rancune ;)

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.

« La BD de Soledad : La compile de l'année »

Da Scritch — 2013-10-21T13:30:00+02:00

Chronique dédiée à toutes celles qui me suivent : Soledad Bravi adapte en album ses chroniques dans Elle, et se fait chroniquer par un horrible mysogine. Une compilation annuelle qu'on retrouve Rue de Sèvres et ailleurs.
Lu

Notes de direct pour l'émission « Supplément Week-End » du Samedi 5 Octobre 2013.

Ce livre est la compilation des planches pré-publiées dans Elle, où l'auteur donne ses réflexions et ses tranches de vies. Il y a un trait simple, de l'humour et… non, en fait, il y a une vacuité.

Ami(e?)s audit[eurs|rices], ami(e?)s lect[eurs|rices], je dois peut être vous avouer quelque chose d'intime sur ma personne : Je pense, mais ce n'est bien sûr qu'une supposition, je pense que je ne suis pas dans la cible du public visé par l'éditeur.
Déjà, je lis rarement Elle. Je lis cette revue de temps à autres, tout comme je lis Le magazine de la Gynécologie : à pures fins de culture générale et de curiosité intellectuelle.

Mais revenons à l'album que je chronique présentement. Chaque planche se suffit à elle-même et répond à une question existentielle : « pourquoi avoir un petit sac », « êtes-vous prête pour les soldes », « c'est quoi une fille “bonne” », « pourquoi devenir un homme ». J'ai choisi de manière intentionnelle ces titres, car ils montrent bien ce que je pense être un gros problème dans notre société : le sexisme crétin d'une certaine presse. Aux mecs le bricolage, les grosses bagnoles et le sport. Aux meufs la mode, l'horoscope et les régimes avant l'été. Ça m’horripile d'autant plus que le groupe Lagardère a lancé [la semaine de cette émission] un spin-off pour nous, les hommes : Elle man. Non franchement, c'est quoi ce nom à la con ?

En fait, je comprends tout à fait qu'il y a cette littérature car il y a un lectorat, et pas qu'occasionnel. Le problème, c'est que nous manquons de mixité dans les métiers technologiques, qu'il y a inégalité des salaires à carrière identique entre hommes et femmes, que la position des femmes dans les postes de décision est trop rare et je ne parle pas des religions monothéistes qui les relèguent en dessous des hommes. D'ailleurs, y'a pas de femme curé dans not' bon pays.

Oui, Soledad, je sais, tu fus directrice artistique en agence de publicité, ton blog blogdesoledadbravi.com cartonne, tu as forgé une licence autour de ton nom et de ton trait schématique et épuré. Tant mieux.

Allez, j'avoue avoir ri sur la planche que tu consacres à Lourdes, la fille de Madonna, ou quand on arrive trop en avance à l'aéroport mais… je crois que je ne fais pas partie de la cible de ton lectorat. Et surtout celui de Elle : les fashionista qui consacrent une partie majoritaire de leur découvert bancaire aux achats de fringues et aux régimes avant l'été.
Je sais, ça fait mal. Alors traite-moi de sale misogyne frustré. Tu as du talent, mais je n'ai pas accroché, et ce n'est pas parce que je suis un mec.

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.

No comment

Da Scritch — 2012-08-22T14:59:00+02:00

/** et on ne peut pas s'en passer **/
Webdev

En milieu d'été, Antoine Vernois a publié un superbe article sur l'usage du commentaire dans le code : « Mythe : un code de qualité est largement commenté ».

Et il avait tout à fait raison.

Néanmoins, il manquait quelques éléments.
Dans le code source Unix originel, un commentaire a fait longtemps beaucoup glosé de lui, plus que du code qui l'entoure :

/* You are not expected to understand this */

La raison est historique, vestigiale, même : Le code en question date de 1975, intervient sur un élément relativement bas niveau, et à l'époque, on ne faisait pas de tests unitaire. Donc c'était à la fois une remarque pour dire que c'était un peu inutile de tenter à toucher ceci, surtout qu'il s'agissait d'un patch pour contrer un bug système.

Mais à cette époque, Unix tournait que sur d'immenses machines. Et il était possible d'en consulter le code source, contre une somme assez conséquente à verser aux Bell Labs. Vous imaginez la frustration des gens, non pas devant le côté frustre du patch en question, mais surtout devant ce commentaire qui a été vu à tord comme hautain.

Exemple récent dans un de mes javascripts :

for(var i= 1 ; i<4 ; i++,c+='-')
{
	// ça c'est uniquement pour que Closure perde pas les pédales
}

Le compilateur Google Closure va supprimer le commentaire, et le bloc accolade qui est en fait inutile. Seulement, si je reviens deux ans après dessus, je me serais posé la question pourquoi je n'ai pas écrit beaucoup plus simplement for(var i= 1 ; i<4 ; i++,c+='-');.

Ce type de commentaire est là pour que quand je revienne des heures, jours, mois, années après, je comprenne pourquoi j'ai commis une telle aberration.
La réponse ne sera jamais de faire long, prolixe, verbeux, pompeux. Elle m'économisera de nombreuses minutes.

Mais si seulement il y avait que ça...

Là où manquent les commentaires

Parce que les projets devenaient immenses et qu'on avait de multiples intervenant autour d'un code source, on vit se populariser dans les années 1980s l'idée du code auto-documenté. L'idée était louable : obliger à des convention d'écritures, à une rigueur de nommage, et ceci indépendamment des langages et des frameworks utilisés.

Hélas, l'enfer est pavé de bonnes intentions, et on a vu n'importe quoi arriver. À savoir, la suppression pure et simple de tout commentaire. J'ai vu du code pondu comme ça, et comment dire… Je me suis mis dans le cerveau de la poule qui trouve un couteau (cela n'a rien à voir avec Clara Morgane).

Je vous jure que sur un projet, j'ai perdu une demi-journée à cause d'un idiot qui a très mal compris le concept du code auto-documenté, et qu'il l'a appliqué d'une manière quasi intégriste.

« Code source » est la suite de « Identification des schémas ».
Ce ne sont pas des manuels, mais des polars de William Gibson, pape cyberpunk vénéré.

Actuellement, je suis super emmerdé quand je me retrouve face à des langages descriptifs qui n'acceptent pas les commentaires.
Si, cela existe. Exemple : le format JSON. À moins de space-encoder votre commentaire, point d'issue pour y mettre une information contextuelle.

Ou alors les méta-données du document source, mais même les éditeurs sous Mac n'ont pas ça.

Ça me fait penser qu'une interface “auto-documentée”, donc sans documentation, ben ça peut marcher. Néanmoins, il faut rester réaliste : au-delà d'une certaine échelle, c'est même pas envisageable. Songez aux utilisateurs qui n'ont forcément pas le code sous-jacent en tête : documentez toujours.

On peut commenter pour ne rien faire avancer

Tiens, dans le cadre d'un travail en équipe, faut-il que vos collègues qui ne travaillent pas la mécanique comprennent vos commentaires ? Bien sûr que non :

(NOTE : ce qui suit est une fiction)

@dascritch ton code, je comprends que dalle, tu fais chier
— nicolas (@xylpho) August 22, 2012

@xylpho Pourtant, c'est commenté. Tu dois pas comprendre mon niveau technique
— Xavier Mouton-Dubosc (@dascritch) August 22, 2012

@dascritch on fait surtout pas le même métier :)
— nicolas (@xylpho) August 22, 2012

Grâce à ce genre de commentaires, vous gagnez l'estime muette de vos collaborateurs qui en restent admirativement coïts devant tant ~~d'auto-suffisance~~ de sagesse. Les commentaires évitent les questions stupides.

C'est comme l'écriture d'un médecin : c'est illisible, cela entretient le mystère.

Ce qu'il y a dans mes commentaires

Le commentaire ? J'en mets.
J'use et j'abuse de JavaDoc, la notation qui permet aux IDE de comprendre ce que font vos fonctions. C'est un réflexe (quoique pas systématique), et il m'est bien utile.

Souvent, mes commentaires dans le code source comportent des indications techniques, des liens vers des url de référence, vers des rapports de bugs. Il comporte aussi extrêmement souvent du code mort, même en cas de versionnage. C'est un intron de l'ADN de mes productions, à l'importance non-dite. Voyez-y des ratures, du Tipp-Ex, des notes au crayon sur le tapuscrit d'un roman. Et des fois, il n'est pas inutile de prendre la place que rêvait Fermat.

Les commentaires dans un code source sont aussi utiles que les README d'un tgz, les messages de commits d'un projet sous Git, un rapport de bug.

Le commentaire du code source est une enluminure. Celui du code généré, une information qui n'intéressera que les mainteneurs du site.

Quoique…
Je viens de mettre un commentaire dans mon site corporate. On ne sait jamais, si un curieux de la profession y jette un œil…

Y'a-t-il un Sud Par Sud Ouest qui s'ignore ?

Da Scritch — 2012-05-02T09:46:00+02:00

Viendez à Toulouse ! Venez ouvrir toutes grandes vos esgourdes et goûtez le plaisir que nous avons à exercer nos métiers.
Sortons

SXSW (prononcez « South By South West ») est un festival incroyable qui a lieu à Austin, Texas. Les artistes et la technologie se rencontrent ensemble. Il y a donc des concerts, des performances, des projections, mais aussi des conférences techniques, des showcases technologiques. C'est un peu comme si un festival de musique s'était allié à un de cinéma indépendant et un d'art moderne plus un de salon industriel avec une part importante de bidouilleurs.
En fait, c'est exactement ça.

L'impact de SXSW est énorme.
La chaîne musicale européenne MTV2 y installe un studio permanent. Les journalistes aussi bien musicaux que technique y accourent. Les cinéastes projettent à un public très différent des festivals comme Tribeca ou Sundance. Les musiciens jouent dans une multitude de salles et de bars et signent parfois avec des labels indies.
Économiquement et culturellement, Austin est un poumon important pour le Texas, et la ville doit énormément à ce festival établi depuis maintenant 25 ans.

C'est exactement l'événement qui nous fait kiffer, et qui donne envie de créer, d'innover, de construire et de rencontrer.

Ça me manque de n'avoir pas un tel foisonnement pluridisciplinaire en France.

Pourtant

C'est exactement ce qui pourrait arriver à la fin de ce mois :

Le même week-end à Toulouse a lieue la seconde édition de Sud Web et la troisième du Toulouse Hacker Space Factory (THSF).

Or vous savez qu'on a couvert avec beaucoup de passion et de bonheur l'édition précédente du THSF, et que je suis très heureux de me retrouver orateur à cette édition de Sud Web.

En fait, ça serait vraiment dommage que vous ne participiez qu'à un seul événement. Faites coup double ! Avec un peu de chance, nous aurons très beau temps, et vous rencontrerez des gens formidables et stimulants.

Vendredi 25 et Samedi 26 : Sud Web

Où des orateurs parlent de cas concrets en rapport avec leur profession. C'est extrêmement intéressant car on ne parle pas de théories, mais de réels retours d'expériences. Et donc les avancées telles que le html5, les méthodes agiles, l'accessibilité voient leurs objectifs confrontés au quotidien. Sans langue de bois.

Ruez-vous pour vos places : il n'en reste pas beaucoup !

Vendredi 25 à Dimanche 27 : THSF

Des badges sociaux zombies, des androïdes à réparer, apprendre à hacker des caméras ou se créer un réseau WiFi mesh, transformer une Kinect pour jouer sur un grand mur, voir des concerts ou les musiciens jouent avec les éthers… Ouvert pour adultes et aussi pour enfants.

Lundi 28

Sera férié, et c'est encore l'occasion de discuter. Pour ceux qui n'auront rien à démonter dans l'immédiat ni un besoin impérieux de prendre un train, ça sera l'occasion de prolonger les rencontres par des boustifailles improvisées dans les jardins. Au hasard... qui sait ?

Il y a donc un week-end formidable à la fin de ce mois de Mai

Si justement vous cherchez votre voie, un job ou un partenaire, vous aurez bien plus de chance de trouver avec bonne humeur sous un riant soleil, qu'en poireautant sous de tristes néons. Plaisir d'apprendre, d'expérimenter et de rencontrer. SudWeb et THSF sont deux opportunités de relance d'activité.

Et ça, je le pense sincèrement.

PS : Je crois que je n'ai jamais mis autant de mots-clés sur un billet. Mais difficile d'en retirer un seul ;)

Me voici à Sud Web

Da Scritch — 2012-03-13T13:47:00+01:00

Et bang ! J'ai encore du mal à y croire. Mais fin Mai, je devrais aussi assurer le show.
Sortons

Me voici orateur à Sud Web, la plus grande conférence concernant les technologies du web au sud de Paris.
Un festival de rock stars du web jouant de vertigineux solos de normes, standards et bonnes pratiques , un événement officiellement soutenue par le W3C, un comedy-club de geeks ponctuées de blagues en regex.

C'est Vendredi 25 et Samedi 26 Mai, et vaut mieux s'inscrire à l'avance vu le line-up de folie pour ce festival technique.

C'est pas mes sujets qui manquent

Parmi la multitude de sujets que j'aborde régulièrement, j'aurais pu proposer les trous dans la gestion de formulaire dans l'API de ce que l'on appelle abusivement le HTML5, les évolutions des compressions lousy de formats d'images/son/vidéos, le bricolage d'un framework javascript pour braficoter du SVG, sucrer un site donne-t-il le diabète, le théâtre de la sécurité qu'est devenu la certification SSL malheureusement à la base du HTTPS, pourquoi un moteur de blog n'est pas une panacée ni l'avis d'un SEO, comment ruiner sa réputation avec un comportement de bot sur les réseaux sociaux, la taille des différentes espaces en Unicode …

Finalement, j'en ai ressorti 3.

Mon vieux problème de tables HTML4 au support incomplet toujours d'actualité, et qu'on complète dans un coin, un dossier sur les emoji en cours de publication qui a mûri pendant 10 ans.

C'est finalement ma gueulante sur les tests de recrutement qui a été retenu.

Mauvaise foi ?

Car j'y jouais le rôle de la personne qui se présente avec un niveau convenable pour un poste, mais qui tombe sur des tests totalement aberrants, datant d'une autre ère. Sauf que je n'ai pas tenu ma langue dans ma poche.

Cette expérience hallucinante, je l'ai vécue plus d'une fois en moins d'un an. J'en ai donc parlé sur mon blog, et pas avec des pincettes.

Avec un retour incroyable : celui d'un cabinet de recrutement et pas des moindres, Expectra qui fait amende honorable ! Au point que ce groupe s'est engagé dans une refonte de ses tests, et que ma participation a été demandée.

En fait, le plus difficile a été d'expliquer aux organisateurs de Sud Web que je ne souhaite surtout pas parler d'une technologie en particulier. La plupart des tests que j'ai passé concernaient PHP, une technologie server-side, mais qui ne constitue pas l'exclusivité du web : en langage de génération de page existe aussi Perl, ASP, Java, Ruby, NodeJS,… sans oublier les bases de données (MySQL, PgSQL, MSSQL, Oracle, NoSQL), l'administration serveur, l'encodage des données, la conformation et bien évidemment les technologies client-side comme CSS, javascript et HTML.

Je souhaite réellement passer au-delà d'un quelconque troll sur une technologie, et parler purement de la distance entre ces tests théoriques et le domaine réels qu'ils sont censés quantifier.

Refaire le monde

Le fait que ce sujet soit pris pour un lighting talk suivi d'un atelier est une opportunité unique : celle d'un débat de groupe sur l'évolution que l'on peut donner à ces tests, de méthodes de recrutement différents. Mais surtout, de ce que ces tests dévoilent sur l'organisation interne de l'entreprise recrutrice.

Sud Web me propose donc d'animer le Samedi une rencontre qui permettra de croiser le regard des recruteurs et des postulants sur des méthodes qui évoluent beaucoup trop lentement en regard des changements techniques incessants que nous voyons dans notre profession. Et aussi de la difficulté de conduire une campagne de recrutement et un deuxième tri (après celui du CV) sur des critères objectifs, à des coûts raisonnables et quantifiables pour des directions non-techniques (au hasard, les ressources humaines).

Bonus de fin de stage

Sachez que si vous venez à Toulouse, profitez pour y rester aussi le Dimanche, car ce même week-end aura lieu l'excellent THSF, organisé par le hackerspace Tetalab. J'en reparle cette semaine.

Note de service

La suite de la série sur les emoji est fort opportunément reportée à la semaine prochaine.

Validations complexes de HTML5 farcies au Javascript

Da Scritch — 2012-02-21T09:23:00+01:00

Aujourd'hui, notre billet culinaire va vous montrer un trou de définition des standards dans la gestion interactive d'erreurs. Retour d'expérience chez un client.
Webdev

Attention : Il est recommandé de lire ce billet sur sa page originale pour profiter des exemples.

Notice for non-french-speaking readers : This page was written after some messages. The pratical example of this miss is here, and a jsfiddle hosted example is documented in both languages.

Parmi les nombreuses et bienvenues nouveautés introduites par le HTML5, nombres d'entre elles concernent les formulaires. Je les testais depuis 2007 grâce à la bibliothèque WebForms2, aujourd'hui défunte.

Les nouveautés les plus intéressantes pour les concepteurs d'interfaces complexes concernent les contraintes de champs. Exemple, on peut décider qu'un champ <input /> doit être obligatoirement rempli par l'attribut required, et que le type de données est une adresse e-mail avec type="email". Cela donne ceci :

Si vous tentez de valider un champ vide avec un navigateur récent, celui-ci va vous envoyer paître. Idem si vous le faîtes avec une valeur qui n'est pas une adresse e-mail.

Legal Disclaimer : Bien évidemment, de telles possibilités ne vous dispense nullement de faire des tests de validation côté serveur. Ils sont pratiques car ils permettent d'éviter une étape de rafraîchissement d'écran, ce qui dans certains formulaires complexes, n'est franchement pas désirable.

Avantages en images

L'autre avantage est de standardiser le dialogue avec l'utilisateur sur les erreurs de saisies. Dans le sens que, selon le type de navigateur que vous utilisez, un message interactif apparaît. Sur les navigateurs conventionnels, vous aurez souvent une infobulle, mais le mécanisme peut être différent pour un téléphone portable, ou pour une tablette braille.

Pour les ~~connards~~ ignares qui se demandent pourquoi on en fait tant pour les handicapés, je leur rappelle qu'ils utilisent tous les jours une technologie assistive originellement prévue pour eux : la télécommande de télévision.
Une autre raison de toujours utiliser les fonctions au plus proche du navigateur sans trop les modifier, c'est tout simplement l'évolutivité. Qui peut prédire ce que les versions à vernir de votre navigateur, voire un simple plugin pourra faire ? Une assistance de validation étape par étape ? Ça sera vachement utile pour tous ceux qui ont dû mal à voir certaines choses…
Non, je ne vise aucun de mes utilisateurs en particulier.

Allez, je suis gentil pour ceux qui ont vraiment un navigateur Bontosaurus extinctus. Voici les rendus avec Firefox 10 et Chrome 17 :

Type d'erreur	Firefox 10	Chrome 17
Champ vide
Valeur non e-mail

Le message disparaît en cas de clic ou de changement de valeur, et le liseré rouge dans Firefox quand la valeur est correcte.

Pour en savoir plus, il se trouve que la semaine dernière, Geoffrey Crofte me fait de l'ombre sur le blog de l'officine Alsacréations en publiant un billet sur le sujet. Eh oui, c'est les élections pour Sud Web, tous les coups-bas sont permis.

Maintenant, on y va dans les messages persos

On peut connaître en Javascript soit au niveau d'un input si sa valeur est valide, soit sur l'ensemble d'un formulaire si celui-ci ne comporte que des valeurs valides. Pour ceci, on utilise la méthode .checkValidity() sur soit l'input, soit le formulaire.

Le texte du message peut être modifiable via Javascript. Il est recommandé à cet effet d'utiliser la méthode .setCustomValidity() sur l'input à impacter

Cela est très pratique car cela permet de tester plus précisément la validation, si un typage, une plage de valeurs ou une règle regex ne suffit pas avant de valider. Cela permet aussi de pouvoir tester les valeurs côté serveur et donc de remonter les éventuels messages d'erreurs qui demande des vérifications de cohérence en base, de collision de données, et bien d'autres. Évidemment, si la validation est confirmée, on en profite, toujours côté serveur, pour faire les opérations voulues, et on changera l'interface côté utilisateur.

Pour ceci, je reprends le formulaire plus haut :

Oui, pour cet exemple je feins d'ignorer la possibilité de laisser le navigateur valider par une regex, je vais le faire en Javascript.

Pour ceux qui ont vraiment un navigateur d'un autre âge (ou pour les dinos des temps futurs), voici ce que c'est sensé donner :

Type d'erreur	Firefox 10	Chrome 17
Erreur personnalisée

Et là, il manque un truc !

En fait, il manque la possibilité de revenir à la gestion interactive des erreurs. Le meilleur exemple, c'est que le message n'apparaît qu'en double cliquant sur le bouton de validation, et jamais sur le premier.
Dans mon implémentation qui m'a bloqué cette semaine, j'étais coincé sur un retour d'information après un XHR POST. Et là, pour utiliser un .preventDefault(), je crois qu'on est un peu trop loin…

Or si je ne préviens pas la suite d'exécution avec .preventDefault(), l'événement “submit” est immédiatement exécutée, peut importe si le formulaire a une entrée non valide.

J'ai tout tenté : lancé un trigger, continuer la suite des événements, cherché dans les docs du WHAT-WG, la description événementielle par ce même groupe, celles du W3, les différentes mailing-list.
Rien
Absolument rien ne me permet de faire revenir le navigateur en mode interactif.

Ce n'est donc pas un défaut d'implémentation de navigateur, mais bien un oubli dans le standard.

C'est dommage car pour y palier, j'ai dû créer mon propre gestionnaire d'affichage. Et quand il y a beaucoup d'éléments <input />, ben forcément ça se bouscule et ça s'empiètre, alors que les navigateurs le faisaient très bien en mode natif…

Donc il y a trois choses à faire :

convaincre la communauté des développeurs de navigateurs
trouver une place dans les standards
l'avoir implémenté dans les navigateurs

Inutile de vous dire que pour l'immédiat, va falloir réinventer la roue, ce que justement est censé éviter cette section du HTML5.

Message in a bottle

Ce message a été posté sur :

Les espacements unicodes

Da Scritch — 2011-05-09T09:55:00+02:00

Espace, frontière mal définie, mais aux multiples dimensions...
Webdev

Attention : la lecture de ce billet est probablement plus aisée sur sa page originale.

Suite à des échanges sur Twitter avec Mitternacht, et surtout la lecture d'un article proposant une presque bonne idée, je me suis proposé pour faire la liste des caractères spéciaux d'espacements disponibles en Unicode, dans l'idée d'en faire parler sur le génialissime Typographisme.net.

Tout partait d'un article qui tentait d'aller plus loin que le simple espace (que l'on note ␣ et dans les tables techniques par ␠ pour faire le gars qui s'y connaît devant les clients) et l'espace insécable à peu près connu de tous (là, vous utilisez ⍽ comme signe cabalistique qui finira de mystifier votre interlocuteur).

Il faut dire qu'on peut avoir un besoin plus que ponctuel pour un espace spécial. Par exemple, toute ponctuation à deux-traits en Français, c'est à dire autres que le point ou la virgule, doit être précédée d'un espace, si possible insécable, à l'exception des guillemets où ils l'entourent. (Faudrait déjà que je parle comment le gérer au quotidien dans ma psychanalyse du clavier)
Vous pourriez considérer comme plus lisible d'utiliser un espace moins long d'une demi-largeur, mais au comportement insécable, c'est-à-dire n'entrainant pas un retour à la ligne.

Le billet qui a entraîné l'écriture de celui-ci préconisait l'usage d'une balise HTML stylée : <span class="demiespace"> </span>.
Un usage du HTML qui ressemble plus à une contrainte et à un usage disgracieux de la sémantique. Ni franchement à faire, ni franchement pratique pour l'utilisateur lambda (songez à un copié-collé vers un éditeur).
Alors que l'Unicode dispose d'une incroyable palette de caractères ad hoc, parfois à l'absurde...

Car, il y a bien une chose très importante à savoir quand on touche du HTML aussi bien côté programmation, côté design que côté contenu, et avant même de connaître ses balises HTML par cœur ou les subtilités entre XHTML et HTML, c'est bien les caractères eux-mêmes !

Cela veut dire que si vos sites servent de l'Unicode (et qu'importe la variation d'encodage du charset, UTF-7, UTF-8 ou UCS-2, c'est à votre choix et à vos usages, voire UTF-32, UCS-4,...), tout va bien. Si vous êtes encore en jeux de caractères ISO-Latin ou pire, en Windows-1522, aux uniques exceptions de l'espace standard et du NBSP qui eux sont présents dans tous les jeux de caractères (“charsets”) 8 bits “simples”, il faudra utiliser les entités HTML (Je vais pas vous rappeler à quoi servent les entités HTML ?).

Hein⍽? Quoi⍽? vous avez déjà dégainé l'aspirine⍽?

Les entités HTML, c'est-à-dire la notation  , ne sont pas toutes reconnues, alors que le code-point numérique ou “entité décimale” ou encore entité XML a plus de chances de passer : La notation ´ faisant théoriquement appel directement à l'index numérique de la police de caractère elle-même.
Malheureusement, il se trouve que ça ne marche pas partout (Opera, du moins) et absolument pas garantie en dehors d'un charset Unicode.
Au moins, je vous aurais prévenu.

Il est très important aussi de noter que le support des caractères, voire des entités varie fortement selon l'encodage du document, mais aussi selon le système d'exploitation (très rare, mais Ms-Win XP est toujours là), les bibliothèques logicielles (si vous devez coder une regex, cela peut vous poser souci, ne parlons pas d'un Direct2D très vieux…), les logiciels eux-mêmes (MsIE6), les polices générales de votre OS qui ont été installées selon votre locale linguistique (principalement pour gérer une fallback), ou encore la police de caractère choisie pour l'affichage.

Fallbacks (solutions de replis)

Dans ce dernier cas, méfiez-vous car le navigateur web peut se retrouver à afficher en lieu et place, au “hasard” :

soit le caractère attendu, mais dans une autre police que prévue (et là, vous avez vraiment de la chance, ou votre ordi a tout simplement trop de polices systèmes),
soit un espace blanc plus ou moins de la bonne taille (dans le cas où vous tentez de faire afficher à MsIE un des espaces ci-dessous, ce qui N'est PAS le comportement attendu),
soit le code en clair de l'entité HTML si c'est ce que vous avez utilisé (ce qui est le comportement prévu en HTML en cas d'incompréhension),
soit ⬚, le placeholder indiquant un point Unicode non-affiché, donnant fort obligeamment le code point en 4 chiffres hexa dans un carré (du ㍑ quoi),
soit ▯, le placeholder d'un caractère inconnu,
soit �, le placeholder officiel d'un caractère invalide.

Ce qui n'arrangera pas la lisibilité de votre texte...

Le dernier point très important, c'est que les logiciels se réfèrent bien évidemment à la norme Unicode concernant la segmentation de texte pour ensuite appliquer les séparations que sont les espaces. Il est arrivé plus d'une fois de découvrir des petites surprises en lisant ce que l'industrie a prévu (dans ce PDF, chapitre 16.2).

Une table, des espaces… qui ont une largeur

Les boutons de tests permettent de vérifier le résultat sur ce paragraphe.

char	Nom usuel	T.R.	Entité	Point Unicode	Plan/Jeu	Codage UTF-8	Insécable	Compatible
	Em Quad	4		U+2001	Ponctuation	0xE2 0x80 0x81	Non	EMSP est recommandé
	EMSP: Espace Em	4	&emsp;	U+2003	Ponctuation	0xE2 0x80 0x83	Non	Tous
	Espace d'idéogramme	4		U+3000	Idéogrammes CJK	0xE3 0x80 0x80	Non	? ⚐
	Espace largeur de figure	3		U+2007	Ponctuation	0xE2 0x80 0x87	Oui	?
⠀	Espace braille	3	⠀	U+2800	Braille	0xE2 0xA0 0x80	Oui	? sauf ⓐⓁ
	En Quad	2		U+2000	Ponctuation	0xE2 0x80 0x80	Non	ENSP est recommandé
	ENSP: Espace En	2	&ensp;	U+2002	Ponctuation	0xE2 0x80 0x82	Non	Tous
	Espace Tiers d'Em	1⅓	&emsp13;	U+2004	Ponctuation	0xE2 0x80 0x84	Non	Tous, sauf ⓢⓐ
	Espace largeur de ponctuation	1⅓		U+2008	Ponctuation	0xE2 0x80 0x88	Non	?
	Espace standard	1		U+0020	ASCII	0x20	Non	Tous
	NBSP: Espace insécable	1		U+00A0	Latin-1	0xC2 0xA0	Oui	Tous. ✁
	Espace Quart d'Em	1	&emsp14;	U+2005	Ponctuation	0xE2 0x80 0x85	Non	Tous, sauf ⓢⓐ
	Espace Sixième d'Em	⅔		U+2006	Ponctuation	0xE2 0x80 0x86	Non	?
	Espace maigre	½		U+2009	Ponctuation	0xE2 0x80 0x89	Non	Tous sauf †
	NNBSP: Espace maigre insécable	½		U+202F	Ponctuation	0xE2 0x80 0x8F	Oui	? sauf ⓐⓁ† (eh bé google?) et Opera
	MMSP: Espace mathématique	½		U+205F	Ponctuation	0xE2 0x81 0x9F	Oui	? sauf ⓐⓁ
	Espace fin	¼		U+200A	Ponctuation	0xE2 0x80 0x8A	Non	?
᠎	MVS: Séparateur de voyelles Mongol	?	᠎	U+180E	Mongol	0xE1 0xA0 0x8E	Non	? ⚐

Texte de test

00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60

(Allez-y, vous pouvez éditer ce paragraphe : la suite n'est que du faux-texte pour essayer les espaces)... Ah non attention, premièrement, il faut toute la splendeur du aware et je ne cherche pas ici à mettre un point ! C'est pour ça que j'ai fait des films avec des replicants. Si je t'emmerde, tu me le dis, ce n'est pas un simple sport car en vérité, la vérité, il n'y a pas de vérité et finalement tout refaire depuis le début Je ne voudrais pas rentrer dans des choses trop dimensionnelles, mais, je sais que, grâce à ma propre vérité le cycle du cosmos dans la vie... c'est une grande roue et c'est une sensation réelle qui se produit si on veut ! Et j'ai toujours grandi parmi les chiens. Et là, vraiment, j'essaie de tout coeur de donner la plus belle réponse de la terre ! Après il faut s'intégrer tout ça dans les environnements et il faut se recréer... pour recréer... a better you et c'est une sensation réelle qui se produit si on veut ! Ça respire le meuble de Provence, hein ?

La suite du tableau

Pour votre culture générale, voici les caractères d'espacement de largeur… nulle ! Pourquoi et en quoi de telles entités pourraient vous être utiles ?

Comme pour le HTML, ce n'est pas parce que la taille est nulle que la signification est quelconque : ces caractères ont une réelle signification sémantique (en fait, j'ai surtout coupé le tableau en deux pour pouvoir lire le texte de test en essayant les espacements que vous aurez le plus de chance d'utiliser).
Par exemple, vous pourriez avoir à indiquer où dans un mot une césure peut se faire, c'est-à-dire entre les syllabes. Cela peut surprendre, mais oui, j'ai eu recours à ZWSP dans des cas très précis (placer par jeu un mot très très long dans un article, sans faire pêter la mise-en-forme par un dépassement de colonne). C'est là qu'on est content d'avoir été civilement présenté à ce type de “symboles”.

char	Nom usuel	Entité	Point Unicode	Plan/Jeu	Codage UTF-8	Insécable	Compatible
⁠	WJ: Séparateur de mots	⁠	U+2060	Ponctuation	0xE2 0x81 0xA0	Oui	? sauf ⓐ
	ZWSP: Espace nul		U+200B	Ponctuation	0xE2 0x80 0x8B	Non	?
‌	ZWNJ: Espace nul non-joint	&zwnj;	U+200C	Ponctuation	0xE2 0x80 0x8C	Oui	? ✁
‍	ZWJ: Espace nul joint	&zwj;	U+200D	Ponctuation	0xE2 0x80 0x8D	Oui	? ✁
͏	CGJ: Combo-jointeur de graphème	͏	U+034F	Combinaisons diatriques	0xCD 0x8F	Oui	? sauf ⓐ. ✁
	ZWNBSP: Espace nul insécable, BOM: Détrompeur d'encodage (mérite un billet)		U+FEFF	Mise en forme Arabe-B, Zone technique	0xEF 0xBB 0xBF	Oui	Tous mais déprécié

D'une manière assez amusante, en regex, aucun des caractères de ce deuxième tableau n'est un espace compris par le meta \s, (du moins pour mes libs) ; tout comme NBSP ce que je conçois, mais bizarrement aussi l'espace Braille en est exclu. Logique…? Néanmoins, le support Unicode dans les regex est censé apporter un jeu de propriétés étendues. J'avoue que j'ai eu la flemme de tester car là aussi, le support est très variable, mâme s'il s'agit d'un standard industriel.

Tests réalisés

J'ai conduit une batterie de tests assez limité, faute de temps. Le projet Doctype sur Google Code m'a été utile, et quelques relecteurs m'ont remonté des cas ésotériques. Pour pas trop agrandir la table, j'ai dû utiliser des symboles, désolé pour ceux qui ont une police système incomplète.

Firefox 4.0.1 sous Linux. ✁ indique un filtrage par copié-collé ⌈ ^+C , ^+V ⌋
Chrome 11 sous Linux
Ⓛ Links 2.3 en terminal X sous Linux
ⓐ Webkit sur Android 2.2, Samsung Galaxy S
ⓢ Safari 3, selon les références Google
† MsIE6, selon les références Google
⚐ Indique un affichage conditionné soit par la locale système, soit par les polices installées, en plus du support selon les logiciels.

Références

Le standard de l'Unicode Consortium, (une partie est traduite en Français, pas forcément up-to-date)
KCharSelect (outil système de l'environnement graphique KDE4 sur Unix/Linux/*BSD),
le projet Doctype sur Google Code,
Wikipedia anglophone,

Le texte du paragraphe de test généré par faux-texte.com. Total respect à JCVD, j'ai adoré ton film mais j'avais la flemme...

Commentaires et observations fortement bienvenus.

Les sites des codeurs sont les plus mals codés

Da Scritch — 2011-04-15T13:47:00+02:00

Oh mince... y'a un accroc dans mon plan.
Webdev

Contrairement à la dernière fois, cela s'appelle une transition à l'arrache.

Le serveur qui héberge mon blog est en fait co-loué avec une bande de comparses. Cela nous permet d'avoir du dédié à un prix très intéressant, et je remercie Zorel de s'occuper de la gestion administrative et technique. Zorel est aussi un fin négociateur, et il l'a obtenu un bon rabais auprès de notre salle blanche ~~suite à une nuit de beuv~~ pour un nouveau serveur. Je pensais qu'on restait dans la même Debian avec des numéros de versions anciens (mais avec les patches idoines de sécu), et donc on est parti faire des interviewes au TGS Ohanami innocemment ce week-end.

Ça fait le con en costard devant un cameraman en marcel alors que le codeur aurait mieux fait de vérifier avant la version de son nouveau serveur (photo : © Enflammée)

Ouch, les textes ont disparus !

Seulement, en début de semaine, il y a eu un hic au moment de changer effectivement de serveur : on est passé à PHP version 5.3. Le blog d'Enflammée était clean (comprenez que c'était un dotclear sans modifications) et donc est reparti sans un pet mais mon site perso s'est effondré. Il se trouve que dascritch.net était depuis un temps certain architecturé avec un dotclear 2.0 version béta (eh oui, c'est pas bien du tout) qui a été greffé de force dans du code qui date parfois de 2001… Tant que cela marchait (et vu que mon code possédait suffisamment de blindage, remis à jour), et comme j'avais vraiment d'autres priorités (entres autres, dAgence, écrit quasi de zéro), ça ne posait aucun problème. Et forcément, ça me pendant au nez. Le passage en PHP 5.3 a cassé bien des fonctions obsolètes (entres autres, les fonctions regex ereg, car oui, comme pour le javascript, les libs regex sont très différentes), ce qui a fait disparaitre les textes des billets (en fait, ils n'étaient plus affichés) et mis mon site en verrouillage par sécurité.

Il était franchement temps de remettre tout ça d'équerre.

Donc, je suis revenu au Dotclear vanilla (2.2.3), cette fois-ci intégrant les fonctions persos dans un plugin écrit dans les règles (qui reprend mes améliorations, notamment de sécurité). Ce qui permet de garder la souplesse des mises à jour, et aussi une unicité de gestion de l'aspect graphique. Mais cela m'a demandé deux jours, puisque je suis en pleine livraison entre deux clients, des demandes urgentes de devis, bref, j'ai pas franchement dormi ces deux dernières nuits.

Du coup, plein de modifications sont apparues au grand jour… qui étaient prêtes à être déployées ! Cela faisait aussi 4 ans (eh !) qu'en fait la version de mon blog vue à la maison n'utilisait plus la lib javascript mootools mais jquery (pour info, la version 1.0.3, chargée le 27 Octobre 2006... je sais, j'ai honte) Une partie du code tentait de gérer MsIE 5.5 (eh oui), et disposait d'un chargeur asynchrone maison de librairies javascript. Le truc plus vraiment nécessaire. La CSS avait aussi gagné un sacré nettoyage, pas forcément visible. Dans l'ensemble, pour moi, ça fait pas grand-chose de neuf. Pour vous, ça semblera nettement plus actuel que la précédente version dite “cssr07”. Mais je compte néanmoins retravailler “graphiquement” mon header.

Ça… on jette… ça… on jette…

La colonne à droite de navigation (sidebar) a aussi vécu un sacré nettoyage. Fini le double moteur de recherche (l'un envoyant les résultats Dotclear, l'autre ceux de Google). Fini aussi le lien vers Viadeo, je vous laisse deviner pourquoi. Le résumé de del.icio.us a provisoirement disparu. Il est toujours consultable sur le site d'origine Il risque de revenir, mais sous la forme d'une compilation mensuelle, tant que Yahoo le tue pas. Ce fut un crève-cœur car le développement de ce code m'avait permis de discuter avec Joshua Schachter, notamment de micro-formats embarqués dans le html dès.... 2004 !

Disparue aussi ma liste de liens. les raisons sont multiples :

elle n'était plus à jour depuis que le dernier plugin de Firefox capable d'exporter les bookmarks en format xml/XBel a disparu, lors de la sortie de Firefox 2.0. Le fichier master du site est toujours présent mais plus à jour depuis belle lurette.
impossible de s'occuper de gérer les liens morts et tout le reste, même DMOZ n'y arrivait pas manuellement
point de vue référencement, j'ai sacrément perdu en 6 mois, puisque cette rubrique me montrait comme un farmeur de liens...

Le plan d'adressage est en cours de simplification, puisque tout le rendu est un pur MVC de Dotclear, et pas un mix immonde entre deux blocs de librairies, dont un perso vraiment trop ancien. J'avais fait disparaitre la version mobile de mon site en 2009 (ça mérite un papier, car certaines choses y sont pleinement d'actu), je compte plutôt faire un style pour les téléphones et petites tablettes. Les vieux sites archivés vont rentrer dans Dotclear, quand j'aurais un peu de temps pour ça, ce qui justifiera la disparition de la recherche Google locale. Des pages statiques virent, notamment mon CV, intégralement chez LinkedIn.

L'aspect général du site ne bouge pas dans l'immédiat, mais ça viendra. Un premier jet concerne déjà les écrans mobiles.

Faut dire que je veux vous éviter le traumatisme de la perte de l'ancien style. Vous vous souveniez du look de mon blog entre 2003 et 2007 ?

Moralité : lire le titre.

Badges

Da Scritch — 2011-01-19T20:23:00+01:00

Je n'ai pas fait mon service militaire, donc ça ne peut que me rappeler mes années boy-scout, mais voici mes décorations HTML5 certifiées norme W3C.
Webdev

HTML5 est le mot hyper-hype en ce moment. Faut dire qu'on oublie qu'en plus de la sémantique HTML, il intègre aussi CSS3, ECMA script 5, DOM level 3 SVG, les micro-formats, etc... Et, il est important de le noter, on ne parle que des technologies côté navigateur (clients), pour les serveurs webs, je parle d'autres langues (Apache, PHP, Bash, expressions régulières, bases de données,...) .
Donc selon la classification du W3C accompagnant le nouveau logo du HTML5, voici mes compétences supposées dans la matière :

C'est totalement partial, il y a un manque très important qui me tient à coeur (le volet sécurité client, qui il est vrai n'est pas encore standardisé) et mon niveau varie fortement selon les compétences. Je dois reconnaitre qu'une expérience récente m'a rendu particulièrement humble. En plus d'être en indépendant, je développe dAgence, une application d'hébergement (avec Nicolas Guilhou et Kairn) dont le backoffice est conçu pour être totalement HTML5 depuis 2 ans à l'origine...

Pour ceux qui trouvent le logo W3C moche (des goûts, des #rrggbbaa), ils peuvent en ricaner en faisant d'excellentes parodies.

Pour la petite histoire, et ce que je ne raconte pas dans mon profil LinkedIn, mon premier badge de boyscout, c'était “cuisinier”. Là aussi, maintenant, j'ai de quoi être humble...

Oui, PHP est lent

Da Scritch — 2009-06-19T11:25:00+02:00

M'enfin, c'est quand même pas un développeur en ASPX.NET♯ qui va me contredire, non ?
Webdev

À ma demande, Marc Chouteau a écrit :

A la demande générale, voici un petit troll ;)

Il progresse, ce garçon, il apprend à générer un trafic conséquent via la polémique sur son blog... qui est motorisé en PHP.

Bon. comme promis, je te réponds :
PHP est intrinsèquement LENT.
Oui, car c'est un langage interprété à la base.
Néanmoins, il peut être précompilé au runtime. Et à partir de là, précompilé de manière permanente.

Ensuite, il a différentes astuces d'accélération. Certaines fonctions ou manières d'écrire entraîne des temps d'exécutions plus lents que d'autres. Un appel statique sera toujours plus rapide qu'une classe instanciée, mais c'est à toi de voir si tu acceptes un code spaghetti. Avoir de multiples inclusions est un facteur de ralentissement comme pour Javascript, car il est soumis aux mêmes problématiques. Certaines fonctions de débug (comme FirePHP) entraînent de très forts ralentissements, ce qui fait que malgré les services inestimables de cette bilbiothèque, il vaut mieux ne jamais le laisser sur un service en live. (de toutes façons, il ne faut JAMAIS le laisser car c'est un trou potentiel de par les informations qu'il divulgue)

Certaines bibliothèques extérieures, pourtant en binaire, peuvent ralentir sensiblement le service (comme GDlib, ou les libs OpenOffice), d'autres l'accélèrent grandement.

Et puis surtout il y a les méthodes de programmation. L'exécution déférée, la préparation de requêtes SQL (me fait gagner en vitesse et sécurité de manière prodigieuse), voire même préférer à de trop puissantes fonctions regex leurs équivalents précompilées.

Intrinsèquement, le PHP est lent, mais il suffit d'étudier certains aspects fondamentaux du développement d'un langage, de se plonger dans le code source et d'abandonner ses méthodes de script-kidding pour arriver à des gains monumentaux. Le simple fait d'avoir la compression gzip en sortie de flux (hint : gratuit sur PHP, activable dans les prefs), donne une impression de rapidité non négligeable.

Marc, comme je sais que tu abandonnes le Visual Basic™ pour tes sites web, voici un site qui est d'une lecture très utile : http://phpbench.com/. Ma liste de liens n'est pas très à jour, mais elle comporte quelques articles passionnants.

(Et hop.... j'ai même pas besoin de publier une chronique BD aujourd'hui)

Javascript, l'accent d'la regex

Da Scritch — 2007-09-06T11:28:00+02:00

“Javascript comme un dialecte”, acte II. Entre le professeur Louis De Funès : « mmmmh les expressions régulières, mmmmmhhh... vous allez en bouffer... mmmmmhhhh »
Webdev

Dans un précédent article, j'avais glosé des difficultés à écrire des javascripts au comportement cohérent sur l'ensemble des “principaux” navigateurs web dans la gestion des arbres DOM. Cette fois-ci, c'est un autre souci qui a été pointé cet été par Bojan Zdrnja, information qui aura sûrement échappé à la plupart des webdev... à leurs tords.
Relevant de nouvelles méthodes d'infecter d'innocentes machines par des virus, ce chercheur en sécurité du SANS a isolé un specimen de Javascript infectieux découvert par Daniel Kluge et mis sous son microscope afin de comprendre pourquoi il est si méchant. Malgré qu'il soit écrit dans un langage théoriquement “ouvert” (car interprété) et même en ayant son code source sous les yeux, il est difficile à disséquer, obfusquant son ADN source afin de protéger ses patrons maffieux. Rapidement, notre expert remarque que ce malicieux code Javascript ne peut s'exécuter que dans Internet Explorer. Pourquoi ? Ce n'est pas la grammaire, ni l'arbre DOM, ni une extension propriétaire de Microsoft qui est en cause, mais... les expressions régulières.

Pour “simplifier”, ces expressions rationnelles correspondent aux théories de Kurt Gödel [NB1], mais appliqués à un alphabet. C'est ÀMHA la meilleure explication jamais trouvée pour pondre le code le plus imbitable pondu histoire de faire criser les collègues de l'openspace [NB2]. Pourtant, je m'en sers pas mal, comme on peut le voir dans mes marques-pages, section PHP. La lecture d'un regex tient à la fois du bénédictin décryptage de langue morte digne de Champollion mais aussi d'une pointe de mystère religieux dans la contemplation de l'arc-en-ciel de votre éditeur à coloration syntaxique, aux motifs ressemblants à une rosace romane [NB3].
Objectivement, le regex est l'ultime solution thermonucléaire pour un question que vous ne vous êtes jamais posée.

Pouf ! Pouf ! Je reprends...

Où le Javascript, c'est comme une Tour de Babel...

Donc, dans cette publication « Raising the bar: dynamic JavaScript obfuscation », Daniel Kluge et Bojan Zdrnja mettent en évidence plusieurs bugs, ou plutôt des différences comportementales dans les regex selon les navigateurs ! Le comportement peut se tester sur cette page. Le premier nombre de la popup d'alerte est à surveiller : S'il indique une valeur de “94”, c'est que l'interprétation de regex est correcte dans votre navigateur.

Ainsi, le moteur JScript de MSIE retourne “98”, indépendamment de MSIE6 et MSIE7. Il considère qu'il peut faire précéder un nombre de plusieurs 0 sans que cela prête à conséquences... ou presque puisque JScript peut considérer qu'un nombre précédé de zéro non significatifs est en fait une chaîne de caractères. C'est le cas dans certaines versions du langage de macro d'Excel.
Safari (versions 2 et antérieures) retourne “93”. En fait, il voit mal le commutateur « /g », signifiant de répéter plusieurs fois l'opération. Ce qui est un bug (corrigé dans Safari 3) et qui fout potentiellement en l'air mon soit-disant script universel déblatéré ici. Ce bug est propre au moteur d'Apple puisqu'aucune des versions de Konqueror que j'ai sous la main (KHTML est la base utilisée par Apple pour son WebKit) ne retourne cette valeur erronée.

Mais c'est surtout un élément très important : Qu'un code supposé être universel peut subir des différences d'interprétation. Quelque chose à ne pas négliger quand il s'agit de “compresser/obfusquer” sa bibliothèque JS. Et une des raisons pour laquelle je déconseille cette pratique.

Contrairement à ce que l'on pourrait croire, les auteurs de ce virus jouent intentionnellement sur ce bug : La suite de leur infection ne fonctionne que sur MSIE, et les débuggueurs Javascripts travaillant plutôt avec un moteur Gecko (donc Firefox), toute personne qui tentera de comprendre leur code (pour justement le bloquer), aura encore plus de mal à le comprendre.

Là où on ne s'en sort plus, c'est quand on se souvient que les regex furent créés à une époque où les ordinateurs avaient rarement des caractères accentués. De cette vénérable histoire, ils ont gardé l'héritage curieux de travailler parfaitement avec les 128 premières caractères de l'alphabet informatique. Et après ? Point de salut : ISO-Latin (16 versions), MS-Dos page, Mac, et pire... Unicode (en UCS-2, UCS-4, UTF-7, UTF-8,...). Vous avez bien peu de chances d'être sûr de votre résultat... L'article Wikipédia a une section qui résume bien le problème [NB4].

L'autre souci, et non le moindre, c'est que les regex sont extrêmement pratiques, souvent utilisés dans le cas de projets compliqués (import/export de xml, analyse de texte,...) et avec une syntaxe... vague. Car de leur très longue histoire, ils ont hérités d'une généalogie très compliquée. Personne n'a jamais normalisé le langage regex, mais chacun y est allé de sa petite touche. Donc un programme, une fonction, voire une formule en regex est susceptibles de différences subtiles suivant où il tourne.
Tout dépend qui a fourni la bibliothèque et qui s'en sert : TCL, Python, Perl, Grep,... Ainsi Microsoft utilise des dialectes très différents ; sa notation dans JScript du navigateur MSIE diffère sensiblement de celle de ses serveurs ASP.NET ou de C#. Certains sites (comme celui-ci) s'emploient à proposer des codes universels. Personnellement, la plupart du temps, j'utilise l'éditeur de remplacement de kwrite pour écrire et tester mes regex, mais ça ne fonctionne pas toujours. Arg.

Transition PHP ? Prépare-toi à des nervousses breakdownes

Quand j'ai refait le design de mon site dascritch.net, comme vous le savez, j'en ai profité pour changer complètement le code (moteur blog, mais aussi présentation de fichiers, de liens, planet, et le reste...) mais aussi de serveur. Et c'est ainsi que je suis passé de PHP4.3 à PHP5. Mais là... surprise ! Entre les deux versions majeures de PHP, le moteur regex a changé... subtilement.

Ainsi, dans ma planet, pour classer les flux rss en fonction de la date de chaque billet, je décodais la balise date, écrite dans un format très spécifique (l'écriture d'une date dans un document RSS mérite un billet tellement que c'est le bazar).
Le code (basé sur magpieRSS) se présentait ainsi :

$regex_de_date = "/(\d{4})-(\d{2})-(\d{2})T(\d{2}):(\d{2})(:(\d{2}))?(?:([-+])(\d{2}):?(\d{2})|(Z))?/"; if ( preg_match( $regex_de_date, $date_str, $blocules ) ) { list( $annee, $mois, $jours, $heures, $minutes, $secondes) = array( $blocules[1], $blocules[2], $blocules[3], $blocules[4], $blocules[5], $blocules[6]);[...]}

Et ben, vous allez rire [NB5], mais entre PHP4 et PHP5, le singleton ([-+]) [NB6] est devenu “significatif”. Ce qui veut dire que dans mon tableau renvoyé par mon regex, les secondes n'étaient plus en $blocules[6] mais en $blocules[7] si mon code est interprété par PHP5.

Visiblement, cela me semble être un bug d'interprétation de la bibliothèque PCRE qui a été corrigé, mais ceux qui avaient été confrontés à lui s'étaient plus ou moins arrangé avec ce comportement irrationnel [NB7]. Et donc des milliers de scripts, de programmes, d'applicatifs, de sites métiers,... sont basés dessus et vont avoir un comportement “incohérent” lors de leur passage à une infrastructure PHP5. C'est justement pour éviter la fronde des développeurs que Microsoft a instauré la compatibilité des ~~bugs~~ features comme une religion sacro-sainte. Avec fanatisme, donc avec absurdité.

Pour en revenir avec la sale bête

Dernier élément intéressant de l'étude du SANS : la faille exploitée par le virus réside dans la méthode d'appel d'un logiciel tiers. Un problème qui a valu à Firefox deux version successives (les 2.0.0.5 et 2.0.0.6), en fait dû à une très mauvaise habitude de Microsoft Windows dans la gestion des URI. Ce qui ouvre la voie à de nouvelles méthodes d'attaques par document audio ou vidéo malformé. Ce que l'on appelle du “fuzzing”, c'est-à-dire qu'on fait ouvrir des documents mals foutus exprès à un logiciel pour voir s'il plante. Rien de neuf sous le soleil, Windows Media Player était déjà connu pour être sensible à ce genre d'attaques, alors que MS Word et MS Excel sont plutôt bien écrits et très très bien testés de ce côté-là. La nouveauté, c'est que la moindre de ces applications de “lecture” est potentiellement victime d'erreurs de programmations. Des petites failles où le script décrit plus haut pourrait se nicher. Ou tout simplement de très mauvaise méthodes de programmation comme dans le plugin Flash

À noter que l'équipe Firefox a justement développé un outil de fuzzing pour tester la solidité de leur moteur javascript. Présenté publiquement lors du même évènement (la Black Hat Convention à Las Vegas cet été), l'outil conçu à ces fins a été mis à la libre disposition de tous... les navigateurs. Et comme bien souvent l'interprétation d'un code source en Javascript est écrit en regex...

Une horreur de slash

Ce qui est grave, c'est que ce n'est plus une extension qui est attaquable, mais l'implémentation dans la syntaxe de base d'un autre langage supposé lui aussi être quasi-universel. Sauf que les deux erreurs pointées le sont sur des règles de base qui sont uniformes partout ailleurs, et dont l'interprétation fantaisiste étonne les rédacteurs de l'article du SANS.
Un tel oubli chez deux importants constructeurs de navigateur montre qu'il y a encore des choses très importantes à tester dans les moteurs Javascripts. Alors que, contrairement aux DOM, les regex sont décrits avec précision dans la norme ECMA 262. La norme dont tous les moteurs Javascripts se targuent d'être parfaitement compatibles.

Encore une pierre de plus dans le jardin de John Resig. Pas de quoi le démonter dans son inoxydable enthousiasme sur le Javascript, puisqu'il annonce l'arrivée les nouveaux moteurs ECMAScript. Enfin conformes ?

Notes de bas de pages.

↑Kurt Gödel : Malgré son patronyme, et le fait qu'Hitler aie changé la nationalité de ses compatriotes, tu noteras, chère Katell, que son nom se prononce avec une pointe d'accent Tchèque plutôt que Germanique. Ce que tu n'avais pas compris la première fois.
↑ : D'ailleurs, ce langage est tellement l33t que la doc web de la lib PCRE est sciemment présentée comme si elle sortait sur un vieux terminal texte avec la commande man. C'est vraiment du terrorisme social pour empêcher les petits jeunôts de se croire plus compétents que vous parce qu'ils sortent d'une formation quelconque... Hinhinhin...
↑ coloration syntaxique d'un regex : Très honnêtement, si vim ne me proposait pas la coloration syntaxique, jamais j'aurais compris que le code en perl proposé dans le roman « Le Cryptonomicon » pour décoder du cryptage Enigma était erroné suite à un oubli d'un “/” dans une règle de substitution. Pour les curieux, page 227 du tome II, « Le réseau Kinakuta » de la première édition Francophone chez Payot SF.
↑ référence Wikipédia : Pour ceux qui me liront plus tard, la version de l'article au moment de l'écriture de ce billet.
↑ « vous allez rire » : humour geek au 0xFE degré, forcément.
↑ ([-+]) : Ce bout de regex signifie qu'à cette position, il y a un caractère unique pouvant avoir la valeur “+” ou “-”. Et uniquement celles-ci. Si ça marche pas, la fonction regex est fausse, preg_match() retourne la valeur false et donc la partie suivante du script est ignorée. Ce bug me semble être lié à celui-ci
↑ « ceux qui [...] » : ou plus probablement, ces développeurs perçoivent les regex comme de la sorcellerie. Ils ont chacun dû bidouiller au pif un code pioché dans un “Grand Albert” quelconque, formule magique se trouvait être fonctionnelle, et faute d'expertise, n'ont même pas relevé un comportement incohérent. Après tout, les gens qui invoquent pour eux des regex en égorgeant un coq noir par une nuit de pleine lune autour de braises de VT100 n'ont pas d'explication à donner. D'ailleurs, la syntaxe des rituels sacrés regex n'accorde aucune facilité de commentaires, qui pourraient briser l'invocation. Généralement, on évite soigneusement de provoquer leur ire par une question qu'ils pourraient trouver offensante. D'abord ça brise la magie, et ensuite si le sorcier voudou vous jette un œil noir, ça pourrait vous faire partir en sucette votre config Apache... Ugh.

Javascript comme un dialecte

Da Scritch — 2007-07-05T10:23:00+00:00

Où il est question de la différence fondamentale entre le Bescherelle nouvelle édition et la collection complète des petits Littrés des langues régionales.
Webdev

J'ai lu hier un article du blog de John Resig, « Javascript as a language ». J'étais en plein dans des soucis de code Javacript sur la nouvelle version de dascritch.net, justement...

Alors oui, Javascript 2 amène des nouveautés alléchantes, notamment sur les boucles itératives, ou encore le JIT (la compilation à la volée) qui va permettre d'accélérer les applications web... mais JS2 n'est implémenté que dans Firefox...3.
Seulement, dans son article, John Resig ne parle que des fonctions de base de Javascript, en occultant ce qui fait (à la louche) 60% de son usage actuel : La manipulation d'un arbre DOM d'un document HTML pour le rendre “dynamique”, comme les applications AJAX (exemple ultime : Gmail) ou les XML enrichi (Firefox, Thunderbird,... ont leur interface en XML/XUL qui est programmée en javascript). Et c'est là que le bât blesse : là, rien n'est standard.

En fait, il y a tellement d'interprétations différentes du Javascript d'un arbre DOM qu'aujourd'hui je peux certifier ceci : Le Javascript est une collection de dialectes comme le fut à son époque de Basic. Et Microsoft dans les deux cas n'avait pas arrangé la situation.

John Resig est très actif dans l'intégration de Javascript 2 dans Mozilla (Firefox) et l'auteur de la bibliothèque Jquery.js ; il a beau être une pointure dans le domaine mais son enthousiasme ne peut nier la réalité, coder du Javascript reste un immonde foutoir. Firefox est le navigateur qui a le meilleur support Javascript et DOM, mais il est vrai que quand on a le créateur dans ses rangs, on peut difficilement être en-deça.
Safari ne peut en dire autant (quoique les bétas de la version 3 semblent enfin prometteurs), et à priori en codant dans KHTML, on est à 85% compatible à coup de sueurs froides.
Mais pour mettre à rude épreuve vos nerfs, MSIE est le pire de tous.

Par exemple, soit dans votre HTML une <balise title="" />, que vous associez en javascript à votre variable balise . Si vous appelez balise.title, vous vous attendez bien sûr que les navigateurs web répondent logiquement une chaîne de caractère vide.
Pourtant, si vous mettez if (balise.title=='') , la conditionnelle sera fausse dans MSIE. Car cet abruti vous dira que balise.title=='null' ! Au lieu de renvoyer une chaîne vide, cet incapable crée une chaîne non-vide pour dire qu'elle est vide. Résultat : pour faire proprement votre test, il faudra ruser avec le support de MSIE d'une fonction proprio, par exemple document.all :
if ((balise.title=='')||((balise.title=='null')&&(document.all)))
Je ne veux pas persifler, mais on a quand même fait mieux comme langage de programmation pour tester si une chaine de caractère est vide.

Maintenant, supposons que vous voulez récupérer le texte dans <balise>texte <em>embarqué</em></balise> sans le balisage. Vous avez la possibilité de récupérer comme suit (cliquez pour tester) :texte embarqué

fonction suffixiale javascript	résultat escompté	navigateurs supportés
`balise.innerHTML`	"texte <em>embarqué</em>"	Compatible chez tout le monde, mais hélas, comporte les balises HTML embarquées
`balise.innerText`	"texte embarqué"	MSIE, Konqueror, Safari, mais pas Firefox
`balise.outerHTML`	"<balise>texte <em>embarqué</em></balise>"	Exclusivement MSIE, avec tout le balisage dont on veux pas
`balise.textContent`	"texte embarqué"	Uniquement Firefox, mais Safari 3 va enfin le comprendre

Donc si vous voulez faire un code “efficace” marchant “à coup sûr”, il va falloir utiliser innerHTML, mais avec une regexp (« mmmmhhh les expressions régulières... mmmhhhh » comme dirait De Funès). Une soupe à la grimace genre ça (je garanti pas que ça marche... ah ben si, cliquez) : balise.innerHTML.replace(/<[^<>]+>/g,"")

Vous croyez en avoir fini ? Reste à trouver les versions de MSIE... car les comportements changent entre 5.5, 6, 6SP2 et 7 !
Si un if (document.all) permet de démasquer MSIE et sa bande, le User Agent sniffing ne marche pas sur des faux navigateurs (comme Avant Browser, PhaseOut ou Maxthon, une bonne liste ici). Impossible d'être exactement sûr de la version du moteur MSIE utilisée sans un commentaire conditionnel, genre  niché dans le HTML, rendant illusoire l'idée de dissocier le code de la structure comme on a pu le faire avec le style.

Pire que tout, MSIE 7 dans ses toutes premières bétas montrait des comportements très différents dans le Javascript et les manips DOM. Vous développez votre site aux petits oignons, mixant PHP5, sHTML, CSS, règles Apache, xHTML, DOM et Javascript. Votre site se charge, les Javascripts de votre page sont quasi complètement interprétées... jusqu'à ce qu'une fenêtre d'alerte arrive : « Internet Explorer ne peut afficher le site http://... ». Cliquer dessus efface votre page et mène à une page d'erreur.

Coup de poignard dans le dos, ajoutant l'insulte à l'injure, cette page indique vaguement que MSIE n'arrive pas à contacter le site, ce qui est totalement faux. La réponse de la base d'information MS est risible.
Cette manie d'afficher un message bloquant (pour débugger) et mensonger (sur votre travail) a été backporté dans les MSIE6 SP2. super agréable.

Un des exemples de comportement changeant radicalement, MSIE considère désormais que le SEUL endroit où l'on peut insérer dynamique une librairie javascript c'est dans le <HEAD> de votre HTML. C'est à la fois logique, mais pas trop. Ce souci sans aucune documentation existante m'a empêché d'avancer pendant un an, surtout sans MS-Windows sous la main.

Et là, j'ai encore un autre problème avec exactement les mes symptômes. Je peux délayer mes problèmes de programmation dans Dotclear2, mais que mon site ne soit pas lisible par 70% du marché alors que je cherche un emploi, ça non. Strictement impossible. Cela m'a tellement gâché la journée que je me suis passé les nerfs en ré-installant l'interphone. Si ça continue, je vais faire du ciment d'ici ce soir.

Pour en revenir à John Resig, il a presque raison. Mais hélas, en l'absence de standard DOM parfaitement appliqué, tout comme le CSS2 et les extensions Microsoft, on est actuellement dans la même situation que le Basic du début des années 1980s : la grammaire est identique pour tous, mais les mots varient suivant les dialectes.
Et rien que pour ça, j'en viens à regretter quand je faisais des pages WAP1.1, c'est dire !

Déplacer son blog

Da Scritch — 2005-04-24T23:45:00+00:00

Suite à mon passage à un hébergeur en coloc', comment j'ai changé l'URL de mon blog. En complément du un billet du “petit dotclear enchantier” dont le traitement est incomplet.
Webdev

Merci à la talentueuse rédactrice du “Petit Dotclear Enchantier” qui m'a donné la force de ce coming-out, ceci est la publication d'un mail initialement pour mes amis.

Mon problème : faire comprendre à Google et aux utilisateurs de rss que j'ai déplacé l'url de mon site de http://dascritch.ath.cx en http://dascritch.net, passant parla même de mon pc à côté de mon lit à un prestataire de service.

J'ai rouvert mon ancien site, avec un serveur apache à poil, sans interpréteur php (ni cgi-bin qui m'avait troué mon pc chez moi avec un LMZ, oui, me suis fait piraté mon pc comme un con à cause d'un vieux awstat oublié dans une arbo mal patchée... Comme quoi, Marc, ça arrive même aux “consciencieux”...)

Dans la racine de son répertoire web, .htaccess

<FilesMatch "[^rss.php]">
Redirect 301 / http://dascritch.net/
</FilesMatch>

un petit regex qui redirige définitivement (code 301*) toute requête vers le nouveau site. Sauf pour les fichiers "rss.php"

dans un répertoire dotclear vierge, fichier .htaccess

AddType text/xml .php

donnera automatiquement un "bon" mime-type de rss (çui là n'est pas le bon,mais ça semble convenir) en servant un fichier texte qui ne sera pas interprété). Et l'accompagnant, à la même url que l'ancien fil rss, le fichier invitant à une redirection :

<?xml version="1.0" encoding="UTF-8" ?>
<rdf:RDF
  xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
  xmlns:admin="http://webns.net/mvcb/"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns="http://purl.org/rss/1.0/">

<channel rdf:about="http://www.dascritch.net/blog.php/">
  <title>da scritch blog zone</title>
  <description><![CDATA[]]></description>
  <link>http://www.dascritch.net/blog.php/</link>
  <dc:language>fr</dc:language>
  <dc:creator></dc:creator>
  <dc:rights></dc:rights>
  <dc:date>2006-04-10T22:20:53+00:00</dc:date>
  <admin:generatorAgent rdf:resource="http://www.dotclear.net/" />

  <sy:updatePeriod>daily</sy:updatePeriod>
  <sy:updateFrequency>1</sy:updateFrequency>
  <sy:updateBase>2006-04-10T22:20:53+00:00</sy:updateBase>

  <items>
  <rdf:Seq>
    <rdf:li rdf:resource="http://www.dascritch.net/" />
  </rdf:Seq>
  </items>
</channel>

<item rdf:about="http://www.dascritch.net/">
  <title>L'URL DU SITE A CHANGÉ</title>
  <link>http://www.dascritch.net/</link>
  <dc:date>2006-04-11T22:20:53+00:00</dc:date>
  <dc:language>fr</dc:language>
  <dc:creator>Da Scritch</dc:creator>
  <dc:subject></dc:subject>
  <description>Rendez-vous désormais sur www.dascritch.net.
Et mettez à jours vos fils rss !</description>
  <content:encoded><![CDATA[<p><a href="http://dascritch.net/">Rendez-vous
désormais sur www.dascritch.net. Et mettez à jour vos fils rss !</a></p>
]]></content:encoded>
</item>
</rdf:RDF>

Une seule entrée, datée de dans un an (à indiquer trois fois, format ISO 8601 recommandé par le W3C) pour qu'il soit toujours en tête des classements chronologiques des aggrégateurs, indiquant bien quelle est la nouvelle adresse. Radical : En trois jours, les 9 agents qui n'avaient toujours pas changés d'adresse sont sur le nouveau site. (À ce sujet, ceux qui comme moi ont un aggrégateur en ligne, si on faisait comme les spidder, à savoir mettre une url dans le User Agent des requêtes ?)

Voilà, normalement, c'est blindé et ça devrait marcher. le site .ath.cx est sur un serveur en ip flottante. Essayez http://dascritch.ath.cx puis http://dascritch.ath.cx/dotclear/rss.php. pour les “vrais” utilisateurs du net sous unix, à essayer avec la commande curl -i http://adresse, ce qui donne l'entête http en prime.

* Le redirect standard (code 302) n'entraîne pas une màj de Google. À ce jour, Google est le seul à ne pas parser mon site, s'arrêtant à la racine et au robots.txt sans réelle explication... frustrant.

da scritch net works - Mot-clé - regex

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

TL;DR Montre ton code !

Simple et basique

À améliorer

Brand new podcast

Un petit poil de code

Formulaire de contact ou mailto: ?

Ce que dit le standard

Anatomie visuelle d'un formulaire de contact

Le formulaire, usage avancé

Le formulaire, côté pragmatique

Le lien mailto:, côté pragmatique

Message envoyé

Travaux d'été

Je refais mon site corporate

Mais pourquoi faire simple ?

Le faux calme

Proposals about ‹img /›

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

A bright idea that might goes dark

Thinking about the current uses of images

What should the specifications have been

So why not using CSS ?

Proposal : srcset in css

Proposal : Using regex into css

Proposal : async="no"

In fine

And thank you for all the fish

Propositions en ‹img /›

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

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

Réfléchir aux usages actuels d'images

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

Et si plutôt on passait par les CSS ?

Proposition : srcset en css

Proposition : Intégrer les regex en css

Proposition : async="no"

In fine

And thank you for all the fish

Bricolages en ‹img /›

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

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

Classique des CMS : Image source et sous-formats

L'écueil du nommage des sous-formats

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

Alors je me suis gratté la tête

Let's test !

Vos retours sur le hack

« La BD de Soledad : La compile de l'année »

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

J'ai tenté d'être mon patron

Tartine beurrée + sol ⇒ —

No comment

Là où manquent les commentaires

On peut commenter pour ne rien faire avancer

Ce qu'il y a dans mes commentaires

Y'a-t-il un Sud Par Sud Ouest qui s'ignore ?

Pourtant

Vendredi 25 et Samedi 26 : Sud Web

Vendredi 25 à Dimanche 27 : THSF

Lundi 28

Il y a donc un week-end formidable à la fin de ce mois de Mai

Me voici à Sud Web

C'est pas mes sujets qui manquent

Mauvaise foi ?

Refaire le monde

Bonus de fin de stage

Note de service

Validations complexes de HTML5 farcies au Javascript

Avantages en images

Maintenant, on y va dans les messages persos

Et là, il manque un truc !

Message in a bottle

Les espacements unicodes

Hein⍽? Quoi⍽? vous avez déjà dégainé l'aspirine⍽?

Fallbacks (solutions de replis)

Une table, des espaces… qui ont une largeur

Texte de test

La suite du tableau

Le lien `mailto:`, côté pragmatique