da scritch net works - Mot-clé - html - Commentaires

Json ou l'histoire d'une licence presque libre - DaScritch

DaScritch — Wed, 19 May 2021 15:45:20 +0200

La vidéo est accessible ici : https://web.archive.org/web/2017082...

Reconstruire son lecteur audio pour le web - David10

David10 — Tue, 09 Mar 2021 08:24:54 +0100

Super taf! Je suis en train de coder le player HTML5 natif pour l'améliorer,
malheureusement, je suis tombé sur un bug d'iOS... incompréhensible.

si quelqu'un sait pourquoi <audio> ne s'affiche pas bien sur iPhone, merci d'éclairer ma lanterne :)

Retravailler un lecteur web audio dans les petites largeurs - Da Scritch

Da Scritch — Fri, 07 Jun 2019 09:58:07 +0200

Hello Nab !

Oui, ce qui ressemble beaucoup au mode jog dial que je décris après, tel qu'on l'a sur des outils professionnels, et comme je le dis, c'est pas infaisable, mais peu pratique, surement très difficile à rendre accessible et prend une place assez importante qui n'entre pas dans l'idée d'un web component réutilisable en design liquide.

Mais rien n'empêche de reconcevoir cette idée avec un skin de mon player, qui se mettrait à ka place du rendu de base.

Retravailler un lecteur web audio dans les petites largeurs - Nab

Nab — Fri, 07 Jun 2019 09:36:28 +0200

Autre piste, l'app android libre MusicPiped offre une alternative assez intéressante à la ligne droite : une ligne radiale qui est très sympathique au doigt et a l'avantage de permettre un positionnement assez fin en mode portait. Sur un desktop, même si un peu moins pratique, ça devrait rester une solution correcte.
Screenshot : https://github.com/deep-gaurav/Musi...

Bon courage et merci :-)

Reconstruire son lecteur audio pour le web - Da Scritch

Da Scritch — Tue, 27 Nov 2018 08:43:45 +0100

Excellent article par Mozilla hacks
https://hacks.mozilla.org/2018/11/t...

Reconstruire son lecteur audio pour le web - nzo

nzo — Wed, 07 Nov 2018 10:07:22 +0100

Très bon article, j'apprécie bien le déroulé de l'argumentaire. Bonne continuation à vous !

C'est rafraîchissant de lire de bons articles complets et documentés !

Reconstruire son lecteur audio pour le web - Matthieu V

Matthieu V — Wed, 07 Nov 2018 08:29:28 +0100

Super post ! Tu apportes une très belle vision globale de ce que devrait être le développement Web !

Reconstruire son lecteur audio pour le web - Franck

Franck — Tue, 06 Nov 2018 19:24:30 +0100

C'est super intéressant ! Merci d'avoir pris le temps de détailler de cette façon toute la conception et le développement.

Firefox, l'invisible - jonjon

jonjon — Sat, 13 Jan 2018 13:46:40 +0100

Un sujet intéréssant, mais un article très fouillis et approximatif en plus d'être biaisé et inutilement centré sur Firefox.

Par exemple l'approche "Firefox a t'il une audience sous-estimée" devient "Firefox (et Brave et Safari) sont sous-estimés par les outils d'analyse de trafic" ce qui n'est plus du tout la même chose. Le cadre général de départ laisse penser qu'on parle des rapports d'audience publié par statcounter, akamai, net marketshare, etc. alors qu'il s'agit en fait de google analytics. Alors la question n'a plus lieu d'être puisque l'on sait que les outils d'analyse de trafic ne sont ni précis, ni fiables.
Pourquoi vouloir faire passer firefox comme une cible alors que ce phénomène touche tous les navigateurs et est bien connu des usagers d'opera par le passé car certains site web sniffait opera pour lui envoyer des pages défectueuses et ainsi faire croire à l'usager que son navigateur était buggé.

On se demande pourquoi firefox est présenté comme apportant une innovation en intégrant des fonctions de filtrage alors que mozilla a sciemment refusé pendant des années de répondre à cette demande de ses usagers en invoquant des motifs fallacieux tandis que cette fonction de blocage était intégrée dans de nombreux autres navigateurs comme opera, avant browser, maxthon, etc.

Pourquoi présenter le Do Not Track comme une avancée alors que c'est un échec cuisant puisque ce réglage est totalement ignoré par les pubs et pisteurs.

Le blocage des pubs serait illégal aux états-unis alors qu'aucun action en justice n'a encore été prise et tout semble indiquer que la raison est simplement parce que bloquer les pubs n'est pas illégal: https://papers.ssrn.com/sol3/papers... http://adage.com/article/digital/le...

C'est une chose de perpétuer le mythe qui dit que Chrome aurait gagné sa position dominante sur la base du mérite alors qu'en fait c'est le résultat du marketing agressif de google qui a profité de sa position dominante pour imposer son navigateur.

Utiliser le user-agent pour identifier un navigateur n'est pas fiable et cette entête est optionnelle: https://tools.ietf.org/html/rfc7231... https://en.wikipedia.org/wiki/Usage...

Le lien entre bloqueur de pub et une moindre détection par les outils d'analyse de trafic relève de la corrélation et non de la causalité. Par contre l'usage de noscript dans firefox va automatiquement rendre inopérant les outils d'analyse de visites qui reposent sur le javascript, comme google analytics. Ou encore les outils de filtrage de contenus comme ublock origin qui bloquent le pistage et accessoirement aussi les publicités vont aussi bloquer traqueurs et pistage puisque c'est leur rôle.

Bref cet article aurait gagné a être plus court, mieux documenté et rédigé de manière plus générale.

Sniffeur d'ancre - Da Scritch

Da Scritch — Mon, 04 Sep 2017 08:40:40 +0200

Le module est passé en WebExtension . Merci Makyen https://github.com/dascritch/anchor...

Billet repassant l'histoire en détails : Les joies de la communauté open-source

Firefox, l'invisible - Da Scritch

Da Scritch — Tue, 30 May 2017 10:31:29 +0200

Un excellent papier qui complète mon point de vue, sans se limiter aux conséquences pour un navigateur https://www.stavros.io/posts/scourg...

Firefox, l'invisible - Da Scritch

Da Scritch — Thu, 12 Jan 2017 16:59:00 +0100

Illustration de Mariko Kosaka

Firefox, l'invisible - gavrochelegnou

gavrochelegnou — Thu, 12 Jan 2017 15:41:42 +0100

Très bonne analyse.
Pour info une comparaison sur un site large public le 6 janvier (jour pris au hasard mais significatif) avec 12289 pages vues et 5147 visiteurs (source GA) :
GoogleAnalytics :

1.	Chrome	2 213	38,36 %
2.	Firefox	1 790	31,03 %
3.	Safari	953	16,52 %
4.	Internet Explorer	491	8,51 %
5.	Edge	129	2,24 %

Donc même si la gestion du cache peut influencer on a tout de même une remontée sensible de firefox.

Ressuscitez le bouton du milieu ! - Ohian

Ohian — Fri, 30 Dec 2016 03:22:52 +0100

C'est comme quand tu découvres une SUPEEER nouveauté qui te CHAAANGE la vie quand tu découvres une nouvelle fonction super pratique sur ton soft préféré!!!
Maintenant je ne ferai plus jamais clic droit + ouvrir gnagnagna
Merciiii \o/

Ressuscitez le bouton du milieu ! - Artusamak

Artusamak — Thu, 08 Dec 2016 00:20:57 +0100

Merci pour ce billet, je ne suis pas le seul à râler contre Google qui sont les pires je trouve.
Le clic droit est aussi mal traité (pour inspecter un élément, pour copier le lien à partager, etc).
Et le pire c'est que dans Google Sheets ils t'interdisent même d'utiliser le menu Edition > Copier / Coller, ils t'obligent à utiliser un raccourci clavier !!! C'est plutôt grave, non ?

Vive le clic du milieu libre !

Ressuscitez le bouton du milieu ! - Tim

Tim — Wed, 07 Dec 2016 00:53:07 +0100

Hello,

Non, à mon sens, tu n'es pas seul, et non, à mon sens toujours - sur ce sujet précis - tu n'es pas un vieux croûton qui râle que c'était mieux avant.

Je saisis l'opportunité d'aller - un peu - plus loin ici, suite à notre bref échange là:
https://twitter.com/tpillard/status...

Mes excuses, manquant de temps pour faire une réponse courte, j'en ai fait une longue, et un peu en vrac.

Mon tweet contenant le bout de code suivant:

```js

function onClick(evt) {
    var tab = evt.ctrlKey || evt.metaKey || evt.which === 2 || evt.button === 1;
    if (!tab) {
       evt.preventDefault();
       // ... Some JavaScript
   }
}

```

Pour être un peu plus exhaustif - A:

```html

<a href="https://dascritch.net/post/2016/12/06/https://dascritch.net/post/2016/12/..." title="Je suis un lien intercepté avec JavaScript, mais je m'ouvre quand même dans un nouvel onglet si je devine que c'est ce que tu veux" />

```

```js

function onClick(evt) {
    var tab = evt.ctrlKey || evt.metaKey || evt.which === 2 || evt.button === 1;
    if (!tab) {
        evt.preventDefault();
        // ... Some JavaScript
    }
}
document.querySelector('a').addEventListener(onClick, false);

```

Un gestionnaire d’évènement `click en JavaScript, sur un lien, mais que l'on peut ouvrir dans un nouvel onglet grâce à une combinaison de touches du clavier (CTRL + click / POMME(heu, META) + clic) ou boutons de la souris (bouton du milieu).
Bien qu'il soit imparfait - il y a des cas que ce bout de code va louper - ce bout de code en couvre, je pense, la majeure partie.
Il m'est arrivé d'utiliser un tel mécanisme au sein de divers sites et application webs tirant profit de JavaScript, en VanillaJS, jQuery, Backbone, React, whatever blah.

C'est d'ailleurs le même mécanisme qu'on retrouve dans React Router et probablement bien d'autres:
https://github.com/ReactTraining/re...

Sur Twitter, notre cher défenseur du bouton du milieu, pointe que cette solution:
- est peu standard (en fait il n'y a que evt.which qui ne soit pas standard, on doit pouvoir s'en passer)
- est un peu compliquée / intrusive / peu fiable
https://twitter.com/dascritch/statu...
Aussi, elle va un peu à l'encontre de la moralité donnée en fin de l'article:
> Moralité : Laissez le navigateur fonctionner, ne tentez pas de recréer la roue

En proposant une solution alternative - B:

```html

<a href="https://dascritch.net/post/2016/12/06/https://dascritch.net/post/2016/12/..." title="Je suis pas un lien intercepté avec JavaScript, mais je peux quand même exécuter du code quand tu me navigues" />

```

```js

function onHashChange(evt) {

    // ... Some JavaScript - evt.oldURL - evt.newURL

}

window.addEventListener('hashchange', onHashChange, false);

```

En vrai, je trouve que c'est une approche intéressante, et à priori moins intrusive et plus fiable que ma version du gestionnaire d’évènement `click`, mais je ne suis pas tout à fait convaincu:

- Ok, cela m'a étonné mais le support des navigateurs pour l'évenèment onhashchange est plutôt pas mal:
https://developer.mozilla.org/en-US...

- evt.target === window, c'est une approche globale, et non locale, bon courage pour savoir sur quel lien en particulier l'utilisateur vient de cliquer
document.querySelectorAll('a[href="https://dascritch.net/post/2016/12/06/'+ evt.newURL +'"]');

- ne fonctionne pour les liens "pushstate"?
Vous savez, ceux tout jolis (et universal-rendering/URL/etc friendly) sans `#` dedans là

Néanmoins, je tenterai, dans le futur, si j'ai un projet qui correspond.

Dans les deux cas, A et B, on a affaire à une approche, peut-être un peu naïve, de deux développeurs web, qui éssaient de concilier
le développement d'applications JavaScript, les principes du document web et les habitudes de navigation des internautes.
Et on est pas les seuls, on retrouve cette problématique dans la plupart des projets web, mais les outils à notre disposition sont pas toujours aussi aidant qu'on les aimeraient:

- MouseEvent.which n'est pas standard, et utilise le code `2` pour le bouton du milieu
https://developer.mozilla.org/en-US...

- MouseEvent.button, lui est standard, et utilise le code `1` pour le bouton du milieu
https://developer.mozilla.org/en-US...

- MouseEvent.buttons, lui est standard, et utilise le code `4` pour le bouton du milieu, et les valeurs sont combinées en une lorsque plusieurs boutons sont préssés en même temps
https://developer.mozilla.org/en-US...

- MouseEvent.[altKey, shiftKey, ctrlKey]
https://developer.mozilla.org/en-US...

- L'utilisation de l'évènement onhashchange présente les limitations données plus haut

Naïvement, je me dis que ce serait pas mal que le navigateur nous donne plus d'informations sur le comportement par défaut de l'évènement, les développeurs auraient moins à être créatifs pour résoudre ce genre de problématique?

Et encore, notre fervent défenseur du bouton du milieu et moi sommes de plutôt bon élèves, on utilise des liens,
et on pense à l'utilisateur qui n'a pas JavaScript d'activé; que ce soit pour le SEO, l'accessibilité, l'utilisabilité, les performances perçues, etc.

Tout ça pour dire que, à mon avis, non le bouton du milieu n'est pas un soucis de vieux routard du web, et dans la même veine,
on a par exemple le faux formulaire qui ne se soumet qu'au clic sur un bouton ou au blur d'un champ, alors qu'un "vrai" formulaire fonctionnerait très bien, même si la soumission ne fonctionne que grâce à JavaScript.

P.S un peu corporate: sur les nouvelles (oui, bientôt) interfaces web de gestion de VMs GANDI, le clic milieu sur les liens fonctionne, et si c'est pas le cas, vous savez sur qui taper sur Twitter.
Je vous promets pas que vous pourrez (tout de suite) acheter vos domaines, configurer vos DNS, créer des boîtes mails ou ajouter de la RAM à votre VM depuis l'interface web sans JavaScript d'activé.
En attendant, vous pouvez toujours me taper dessus sur Twitter.
Sinon, il y a le GANDI CLI: https://github.com/Gandi/gandi.cli

Chouette article, chouette #Nowwwel :)

RIP URL URI, IRI INRI W3C - Da Scritch

Da Scritch — Tue, 19 Jul 2016 07:44:25 +0200

L'histoire de l'URL, passionnant, forcément. https://eager.io/blog/the-history-o...

Le retour des boutons de partage - Da Scritch

Da Scritch — Sun, 01 Feb 2015 16:52:35 +0100

Théoriquement, ce sont des marques, mais rien ne vous empêche de les reprendre puisque vous vous en servez pour communiquer vers leurs sites.

Le retour des boutons de partage - fran6t

fran6t — Sun, 01 Feb 2015 11:10:37 +0100

Bravo, entierement d'accord avec l'ensemble du billet, c'est du bon sens. Une petite question les pictos peuvent-ils être repris ?

Ressources en ‹img /› - Da Scritch

Da Scritch — Mon, 05 Jan 2015 18:41:57 +0100

Petits ajouts :

1 - il existe un mode lossy en png, et qui se montre plutôt efficace dans certaines conditions, capable de garder un texte particulièrement net ! http://pngmini.com/lossypng.html L'astuce consiste à “oublier” les dernières passes de pixels, le logiciel interpole alors la définition manquante.

2 - MozJPEG 3.0 http://calendar.perfplanet.com/2014... est un encodeur jpeg complètement revu par la Mozilla Foundation, compatible avec tout décodeur. Il se trouve que les performances offertes sont particulièrement intéressantes et relance fortement l'intérêt sur ce format, face à JPEG 2000, JPEG XR et WebP dont le support reste anecdotique. C'est une astuce équivalente au mp3 variable bitrate, et au logiciel JpegMini dont j'avais parlé ici http://dascritch.net/post/2012/01/2... . Sauf que la licence est intégralement libre.

Bref, on a pas fini d'être surpris