#20452

Firefox now shows ads as sponsored address bar suggestions - Liens en vrac de sebsauvage

Ouais, j’avais constaté ça aussi : https://twitter.com/lehollandaisv/status/1426173502927867914

Heureusement, c’est pas reparu depuis.

Vivaldi sur Mobile est bien plus rapide que Firefox (sans les défauts de Chrome).
Mais sur desktop, je n’arrive pas.

Blink est juste une grosse daube. S’ils passaient sous Gecko, je switch direct.

https://sebsauvage.net/links/?tc_iWg

#20285

Firefox 91 s'améliore, mais la part de marché du navigateur continue de baisser

Lu dans les commentaires :

J'utilise toujours Firefox mais je n'arrive plus à le défendre.

Je suis un peu de cet avis aussi.
Firefox est devenu le moins pire de tous, et ici, « tous » signifie Chromium.

J’ai récemment tenté d’utiliser Vivaldi sur PC, mais j’ai fait machine arrière : il est plus lent à la navigation et les outils de dév sont bien moins développés que dans Firefox (où c’est réellement pensé pour le dév et pas pour faire semblant).

Y a quelques jours, Firefox m’a viré des favoris pour mettre des boutons sponsorisés (eBay). C’est une action intolérable. Qu’ils les ajoutent à la fin de la liste, pourquoi pas, mais pas à la place des miens. Malgré tout, ça reste une action moins pourrie que ce que fait Google Chrome…

Firefox ? Il n’est bon que parce que Chrome(ium) est mauvais. C’est tout.
C’est comme Android VS iOS : j’utilise Android et Google parce que iOS est pire (plus fermé, plus cher, moins de choix).

Quant à sa politique… Le libre c’est cool, mais ce n’est pas vendeur. Et puis quand ils font ça ça donne pas envie de les aider. Firefox reste un business, et un business mal géré qui plus est (Oui je sais : il faut distinguer Firefox.com de Firefox.org, mais les deux restent liés, dire le contraire serait absurde).

https://www.nextinpact.com/article/45359/firefox-91-sameliore-mais-part-marche-navigateur-continue-baisser

#19770

Google va limiter l’accès à ses API privées de synchronisation

Jolie excuse pour dire « si vous voulez profiter la synchronisation avec Google, faudra utiliser Chrome, et pas un autre navigateur basé sur Chromium, comme ça on pourra continuer à vous pister ».

M’enfin, c’est pas plus mal non plus en ce qui me concerne : en tant qu’utilisateur partiel de Vivaldi, je suis bien content qu’ils empêchent mon navigateur d’accéder aux pist… aux API Google.

https://www.nextinpact.com/lebrief/45469/google-va-limiter-lacces-a-ses-api-privees-synchronisation

#19597

What is the Value of Browser Diversity? - daverupert.com

C’est vrai tout ça : la mise au point de CSS3 et HTML5 s’est faite alors qu’il y avait de multiples moteurs CSS et plein de moteurs de rendu : KHTML, WebKit, Gecko, Presto, Trident…

On se souvient des heures passées à essayer de faire un truc précis sur une page et qui marche partout.

Mais on oublie les années passées par le W3 à faire une doc qui plaise à tous, et par les éditeurs de ces nav pour les implémenter.

L’avantage de cette difficulté énorme, c’est qu’on doit prendre son temps : mesurer chaque changement, chaque mise à jour déployée, bref, faire les choses bien et faire ce qu’il faut, pas forcément ce que les gens veulent ni le faire vite.

Aujourd’hui, on a 90% de Webkit/Blink et 10% de Gecko. Le reste, c’est tout mort.

Et Webkit/Blink, c’est Google : ils contrôlent le web, ils contrôlent des millions de sites, ses ressources (lib JS, fonts…), des framework, AMP, imposent ses règles en matière d’optimisation, de SEO… Bref, on ne peut pas faire un site sans se plier aux règle faites par Google (en tout cas pas si l’on souhaite toucher du monde).

Résultat ?

Si Google veut une fonctionnalité, elle le livre dans Blink et hop, en trois semaines t’as 90 % des navigateurs qui ont la fonctionnalité active et opérationnelle (rappel : avant ça prenait bien 5 ans). Et pareil pour retirer une fonction.

Alors les webdev sont content, les usagers sont content et le Google est content.

Qui n’est pas content ?

Ceux qui n’ont pas le réseau pour adéquat pour naviguer dans des pages de 20 Mo, ceux qui veulent un web décentralisé, indépendant, libre. Ceux qui veulent essayer de vivre du web sans se plier aux règles de Google en matière de SEO, de fonctionnalités.

Donc ouais, faire des sites compatibles avec toutes les techno des navigateurs, c’est dur. Mais ça oblige parfois à mettre de côté son égo et les trucs trop fancy/inutiles et se focaliser sur le contenu, les choses essentielles et surtout l’utilisateur.

https://daverupert.com/2020/09/the-value-of-browser-diversity/

#19518

Chrome, Opera, Firefox, Brave... Comment ces navigateurs génèrent-ils des revenus ?

Donc principalement via les moteurs de recherche par défaut et les vignettes pré-installées dans le speeddial (chez Opera et Vivaldi).
C'est pour ça qu'on se retrouve avec des vignettes de la Fnac ou d'Amazon quand on installe Vivaldi.

Étant donnée que c'est relativement passif et qu'on peut les virer facilement, je n'ai pas de problème avec ça.

Sauf pour Chrome et Edge, qui passent eux directement par la capture des données personnelles.

https://www.01net.com/actualites/chrome-opera-firefox-brave-comment-ces-navigateurs-generent-ils-des-revenus-1932060.html

#17565

Martijn Cuppens sur Twitter : "The div that looks different in every browser https://t.co/hXmxoLA8fW… "

Et merde, ce code CSS, pourtant pas tellement exotique, s’affiche de façon drastiquement différente dans chaque navigateur (Firefox, Chrome, IE, Edge, Safari).
(Dans le code, le CSS affecté sur body et html ne servent qu’à centrer le <div>, on peut le virer)

Pour le coup, si j’avais à dire lequel avait raison, je dirais soit Edge, soit Safari.

Si je prend un <div> et que je lui met une outline, elle se met autour. Si je met un outline-offset négatif, logiquement, la bordure « implose » sur le <div>.

C’est ce qui se passe avec Edge.

Safari met du vert au centre aussi, mais le laisse également au bord. IE ne supporte pas outline-offset.
Chrome affiche un truc chelou (#chromeIsTheNewIE). Et Firefox semble bien décaler le outline, mais on dirait qu’il fait le rendu comme deux blocs (afin d’avoir l’effet du "inset") : ce qu’il affiche semble être le résultat de sa mécanique interne différente des autres. Et ici, les deux blocs s’affichent pas au même endroit…

https://twitter.com/Martijn_Cuppens/status/1015169981368225793

#17456

Browser detection inside a WebExtension - <Glazblog/>

Si l’UA est spoofable très simplement, et que les tests basés sur les fonctionnalités supportées par les navigateurs évoluent très vite, voici une méthode plus sûre.

http://www.glazman.org/weblog/dotclear/index.php?post/2018/06/07/Browser-detection-inside-a-WebExtension

#17344

Let's Encrypt est-il en train de passer de sauveur à single point of failure (SPOF) ?

+1

J’y avais pensé aussi.

On peut faire la même remarque par exemple pour tout ce qui est Framasoft (leurs services en ligne là). C’est joli de dégoogliser Internet, mais si c’est pour mettre ses œufs dans un autre panier unique, c’est pas l’idéal non plus.

La solution, concernant Frama, ils l’ont : ce sont les C.H.A.T.O.N.S : un collectifs où chaque membre héberge une instance du service, de façon indépendante. Un peu à la manière de Mastodon.

Faire la même chose pour Let’s Encrypt semble pas mal, mais ça signifie aussi l’éventuelle naissance d’instances corrompues / vérolées / …

Ensuite, le HTTPS permet deux choses :
– chiffrer les communications entre le serveur et le navigateur
– authentifier le fait qu’un site est bien le site qu’il prétend être.

Dans mon cas (et je pense la majorité des cas), seule la première partie est intéressante. L’autre fonction est d’avantage utile pour les sites sensibles (banques, services gouvernementaux, etc.).

Or ceci, c’est déjà possible : n’importe qui pour produire un certificat HTTPS pour chiffrer son site. C’est juste que ce certificat ne sera pas signé et ne pourra pas servir pour authentifier le site. Le problème avec ça, c’est que les navigateurs lèvent une alerte pour cette raison…

https://www.nextinpact.com/news/105955-lets-encrypt-est-il-en-train-passer-sauveur-a-single-point-of-failure-spof.htm

#17085

Chrome is Not the Standard · Chris Krycho

Un article dont l’auteur aussi en raz-le-bol que les dév prennent Chrome comme le nouveau standard du web, ce qui à terme contribue à un nombre toujours plus grand de sites compatible avec Chrome/Webkit seul.
On revient en l’an 2001, où on avait IE6…

#ChromeIsTheNewIE

http://www.chriskrycho.com/2017/chrome-is-not-the-standard.html

#16867

LE NOUVEAU GOOGLE CHROME ? (Reportage Vivaldi) - YouTube

Vivaldi reste ma roue de secours de Firefox. J’aimais beaucoup Opera 12.x, et j’aime bien Vivaldi, notamment sa philosophie.

Par contre j’aurais deux questions quand-même :
– quel est leur business-model ?
– vont-ils faire une version pour Android :D ?

https://www.youtube.com/watch?v=LYxZcKVPYzQ&feature=youtu.be

#16753

Screen.width - Référence Web API | MDN

screen.width

Permet de trouver la largeur de l’écran, en « pixel CSS » (d’après les spec).
Sauf que Firefox tient compte du ratio de zoom (si vous avez un zoom de 2, ou un pixel-ratio de 2, alors la largeur affichée sera divisée par 2).

Webkit en revanche, ne tient pas compte de ça…

Les specs disent que un pixel c’est 1/96 pouce. Un pouce ne variant pas, je pense que si le pixel-ratio est de deux, alors la valeur affichée par le navigateur doit être divisée par deux aussi. Donc un écran 4K en 15" qui est affiché en fHD (comme c’est le cas sur certains ordinateurs portables) devrait retourner une valeur de 1920×1080, pour conserver le fait que 96 px en CSS corresponde à 1 inch.

C’est ensuite au script lui-même de prévoir ce cas là et de faire une multiplication avec le window.devicePixelRatio (qui contient le facteur de zoom de l’écran).

À priori, selon moi, c’est Firefox qui implémenterait correctement les spec (très étonnant… #ironie).

#ChromeIsTheNewIE

https://developer.mozilla.org/fr/docs/Web/API/Screen/width

#16242

position - CSS | MDN

Le positionnement « sticky » permet un effet sympa. C’est l’effet appliqué sur le sommaire, à droite sur cette page du MDN.

Ce mode donne un positionnement "relative" en temps normal et "fixed" dans certaines conditions, ces dernières étant définies avec les propriétés "top", "bottom", etc.

Si le défilement de la page force l’élément à sortir de la vue de la page (ou de la zone délimitée entre les "top", "bottom", etc.), alors le positionnement passe en "fixed" et le bloc reste visible.

Ça évite d’avoir à utiliser du JS.

À ce jour, seul Firefox le supporte.
Safari le prend si on met Webkit.
Chrome le prend en compte à partir de la version 56.
Edge, IE et Opera ne le prennent pas encore en compte.

On peut donc l’utiliser si l’effet recherché n’est pas bloquant.
Dans ce cas il suffit d’utiliser un fallback :

position: relative;
position: sticky;
top: 0;
https://developer.mozilla.org/fr/docs/Web/CSS/position