Let it be dark in javascript

Au début on se dit qu’il faut questionner le choix utilisateur avec une mediaQuery:

 (window.matchMedia && window.matchMedia('(prefers-color-scheme: dark)').matches)

Reste que si l’on est dans un contexte incertain, développement d’un add-on dans mon cas, se résoudre à cette simple requête est une mauvaise stratégies car le site sur lequel on vient se pluger lui peut ne pas adapter son style aux choix utilisateur (dark mode ou non).

Sur Firefox qui est mon browser de dev, je ne comprenais pas pourquoi j’obtenais « rgba(0, 0, 0, 0) » avec la ligne suivante sur des pages où le fond est blanc mais le système est en dark mode:

window.getComputedStyle(document.body,null).getPropertyValue('background-color');

A vrai dire, mon erreur était de comprendre cette ligne comme parlant de la couleur noire (0,0,0) alors que le dernier 0 indique en rgba que le fond est transparent, or le fond d’écran d’une page web est blanc. La proprieté (‘background’) retourne d’ailleurs ‘none’. Chrome et safari retournent une valeur rgb qui est plus simple à comprendre.

Au final, je pense être pas mal avec ce bloc:

var dark = false;
let bs = window.getComputedStyle(document.body,null);
let baco = bs.getPropertyValue('background-color');
  if(bs.getPropertyValue('background') == 'none') {
  if(!(/rgba.*,\s?0\)$/.test(baco))) {
    dark = true;
  }
} else {
  let sacos = baco.split(/,/);
  let moy = 128;
  if((sacos != null) && (sacos.length > 2)) {
    moy = (parseInt(sacos[0].replace(/\D+/g,''))+parseInt(sacos[1].replace(/\D/g,''))+parseInt(sacos[2].replace(/\D/g,''))) / 3;
  }
 
  if((moy < 128) && !(/rgba.*,\s?0\)$/.test(baco))) {
    dark = true;
  }
}

Au final, j’aime bien mon petit calcul pour essayer d’évaluer si la couleur est plutôt sombre ou claire.


Let it be dark in javascript

Linkedin’s code tag

Mon user script puis mon prototype d’add-on avait de manière récurrente des problèmes avec Linkedin.

Après moultes débugs, j’ai fini par comprendre qu’ils font en fait un usage très spécial de la balise <code>

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/code

Pour linkedin, code se retrouve être une balise cachée dans laquelle ils embarquent des données.

Mon content script évitait déjà les balises script et autres styles mais de la à penser que le contenu des balises code doivent être ignorés, il faut vraiment avoir l’esprit tordu.

Avant ou après le rachat par MSFT ?

https://stackoverflow.com/questions/42530879/why-does-lindkedin-use-hidden-code-tags-in-their-updated-website


Linkedin’s code tag

DOMParser()

Je travaille sur un addon pour différents browser donc avec du code oecuménique si possible. J’ai une liste d’ouvrages dont les noms contiennent des caractères accentués. Initialement la liste était dans la source (mauvaise idée) puis, après des déboires sur l’encodage de ces accents (JSON est explicitement encodé dans un certain charset, charset mentionné dans les headers, donc problème en local) (notoirement avec Safari), je suis passé à un fichier .xml inclus. Tout allait bien en utilisant un DOMParser() qui est la solution typique dans ce cas. (ceux qui font du innerHTML peuvent sortir). Reste qu’ensuite, sur ma route vers les bas-fonds, je suis tombé sur un problème avec Edge, en fin de tests de plates-formes.

Toujours est-il qu’Edge refuse mon script back (background/serviceworker) car selon lui « Uncaught (in promise) ReferenceError: DOMParser is not defined ». Edge est bien le seul à soulever une difficulté sur ce point. Sur mon chemin de croix vers une solution, je vois que certains, dans d’autres contextes inapplicables ici, utilisent new window.DOMParser(), on conséquence je finis par croire/comprendre que DOMParser() n’est pas disponible dans mon contexte de script d’arrière plan, un peu de la même manière qu’il n’est pas disponible pour un node.js, mode headless en quelque sorte.

https://stackoverflow.com/questions/68964543/chrome-extension-domparser-is-not-defined-with-manifest-v3

Bref, pas sympa. J’aurais sans doute dû passer par la nouvelle API offscreen mais bon, quelques regexps plus tard, j’étais sorti d’affaire car ma structure n’était pas compliquée. JSON/CSV/XML, la question ?

Dans le même ordre d’idée, les workers manifestV3 de Google Chrome ne supportent pas « URL.createObjectURL » ?


DOMParser()

Dirty MSWord

Je déteste MSWord mais il a une sorte de magie à l’usage: Alors que la structure de ses formats récents est un encapsulage d’XML dans une archive, il trouve le moyen de produire des documents HTML non valides: pas de xhtml signifie qu’il trouve le moyen de faire faire du sale avec du propre ce qui est absolument remarquable du point de vue informatique. Bref, tagsoup !

Microsoft: plus d’avocats que de programmeurs (comme le dit l’adage des temps anciens)


Dirty MSWord

ManfestV3, notes dans la jungle

Je suis lancé dans l’écriture d’un add-on browser pour aller plus loin qu’un user-script (monkey).

Vu le climat actuel, je suis parti sur une web-extension, format manifestV3, histoire de partir sur de bonnes bases, ce malgré des documentations parfois obscures. Mon browser de test est bien évidemment Firefox, qui a introduit très récemment (v109) le support de ce nouveau format (donc les ESR doivent patienter).

Le projet fait que l’adaptation du développement aux navigateurs de types Chromium/Chrome/Edge se fait sans trop de problème de compatibilité, réduisant au final le travail à changer une ligne dans le manifest.json, remplacer « scripts »:[« scripts/back.js »] par « service_worker »: « scripts/back.js » pour avoir quelque chose qui tourne ce qui est très gratifiant. C’est pas très stable mais cela fonctionne.

Reste Safari que j’aime bien, mais pour lequel le développement et ses outils (Xcode) est bien différent à finaliser (xcrun safari-web-extension-converter). Quelle ne fut ma surprise quand j’ai constaté qu’avec la version actuelle, 16.3, il faut partir d’un manifest type Firefox et non celui des cousins de Safari mentionnés plus haut.


ManfestV3, notes dans la jungle

Dans un browser, ça a l’apparence du web mais ce n’est pas du web

Faites une requête avec le mot « emprise » dans un moteur de recherche type google. Vous obtenez des résultats. C’est sur le web et dans un browser. Mon test pour dire que c’est du web est que c’est modifiable/remixable: par exemple:

document.evaluate('//text()[contains(.,"emprise")]',document.body,null,XPathResult.ORDERED_NODE_SNAPSHOT_TYPE);

Cela retourne des résultats avec lesquels ont peut jouer (console JS/DOM, user scripts, ..etc)

Par contre, si je vais sur docs.google.com, que je crée un document dans lequel je tape juste le mot « emprise », même en faisant attention à la case du texte, je n’obtiens rien avec le test précédent, mis à part un script de données qui contient ce même mot. En clair, il ne trouve pas de nodes textuelles contenant le mot en question. Et pour cause, l’affichage est en fait une balise canvas donc hors du DOM qui est l’essence du web/html. Autant mettre un binaire qui pointerai vers une VM. Ici le web n’est qu’un transport et le browser un simple réceptacle.

Ensuite le site en question trouve malin d’intercepter tous les événements clavier. Tout y passe sauf bien sûr ceux qui sont interceptés auparavant par le browser. Bref, on ne peux pas jouer ici. Ce n’est pas du web, désolé. Mauvais karma.


Dans un browser, ça a l’apparence du web mais ce n’est pas du web

URL Safari Oddities

Ma seconde machine est un mac sur lequel j’utilise Safari. Lors d’un partage d’URL, je constate que lorsque je copie l’adresse d’un site avec un accent dans le chemin, il embarque

https://jadetognet3.wixsite.com/cap-eana/je-découvre-mon-école-1

Alors que Chrome et Firefox utilisent

https://jadetognet3.wixsite.com/cap-eana/je-d%C3%A9couvre-mon-%C3%A9cole-1

C’est un biais de ces dernières années d’afficher dans la barre d’adresse l’URL déséchapée et de copier l’URL réelle. Safari a tort ce qui pose des problèmes lors de la réutilisation de l’URL (par exemple document traitement de texte) même si Pages.app s’en accommode fort bien.

Cela me semble l’occasion de s’amuser un peu avec Automator.app avec pour objectif de mettre un lien avec l’URL bien échappée et le libellé du lien bien normalisé donc deux expressions d’une même adresse.

Je crée donc un workflow qui accepte en entrée des URLs depuis Safari.app, puis j’utilise le module « Get current web page from Safari » (qui envoie l’URL brute échappée), puis le module « Run shell Script » dans lequel je sélectionne perl et « pass input as arguments ». Reste à copie ce script:

#!/usr/bin/perl
use URI::Escape;
$str = $ARGV[0];
$tito = uri_unescape($str);
print `echo "<meta charset="utf8"><a href="\&quot;$str\&quot;">$tito</a> " | textutil -stdin -format html -convert rtf -stdout | pbcopy`;

Le gros hook dans ce script est de bien inclure le meta charset dans le bout de html passé à textutil puis pbcopy (j’ai perdu pas mal de temps avec des problèmes d’encodage).

Plus qu’a créer un raccourci clavier dans les préférences d’accessibilité et le tour est joué. Cependant, sous Monterey, Automator.app est en cours de déprécation. Je passe conduire sur Shortcuts.app avec quelques hooks en raison de bugs de leur part ou d’incompréhensions de ma part. Reste que la solution suivante est fonctionnelle:

Je mets ici le script:

use URI::Escape;
$loco = $ARGV[0];
open(J,'<',$loco);
$str = <J>; 
chomp($str);
close(J);
print($str);
$tito = uri_unescape($str);
print `echo "<meta charset='utf8'><a href='$str'>$tito</a>" | textutil -stdin -format html -convert rtf -stdout | pbcopy`;
Cheers


URL Safari Oddities