#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

#16175

Brave, le navigateur qui respecte l’utilisateur | Franck Ridel

C’est bien, quelques projets de navigateurs qui on peu de succès.

Juste un peu bête que :
— ils soient tous basés sur Webkit/Blink/Chromium
— ils se ressemblent tous

Il n’y a qu’Opera et surtout Vivaldi qui sortent nettement du lot.

Le dernier serait d’ailleurs le nav vers qui j’irais si je n’étais pas sous Firefox.

http://franck-ridel.fr/2017/01/29/brave-le-navigateur-qui-respecte-lutilisateur/

#15771

The third browser war is over and it's a bloodshed - WEB2DAY 2016 - YouTube

Une autre conf de Daniel Glazman, sur l’état actuel des navigateurs (PDM, etc.).

La conclusion est très simple : l’IE et le Microsoft de la fin des années 90, c’est Chrome et Google aujourd’hui.
Google fait un navigateur pour Google, tant pis si c’est dégueulasse : de toute façon les autres seront obligé d‘implémenter les mêmes choses rester compatible. C’est ce qui se passe quand Firefox ou Opera implémentent le « -webkit- ».
https://www.youtube.com/watch?v=ceMLuRBn--M

#15649

Edge : Microsoft trolle Chrome sur sa consommation d'énergie

« on pourrait alors également s'interroger sur le degré de productivité offert par chacun des navigateurs »

Tout est résumé là dedans.
Ça rejoint ce que je disais déjà il y a deux ans, quand ils avaient fait la même remarque pour W8 et IE : http://lehollandaisvolant.net/?id=20140129215029
http://www.clubic.com/navigateur-internet/microsoft-edge/actualite-809778-edge-microsoft-demontre-faible-consommation-batterie.html