Safari 12.1 : mode sombre sur le web, retrait de Do Not Track, remplissage automatique…

Stéphane Moussie |

iOS 12.2 et macOS 10.14.4, qui sont actuellement en bêta, vont introduire une mise à jour de Safari apportant plusieurs nouveautés significatives. Détaillées sur cette page pour les développeurs et déjà aperçues pour certaines d’entre elles dans les Technology Preview, voici celles qu’il faut retenir.

Mode sombre pour les sites web (macOS)

Côté utilisateur, le changement le plus visible est l’élargissement du mode sombre aux sites web. Quand vous activez le mode sombre de macOS, les sites web troquent leur fond blanc pour un fond noir… pour ceux qui ont prévu cette possibilité.

Contrairement à des extensions, Safari 12.1 ne force pas un affichage sombre pour tous les sites web, il ne fait qu’activer le thème foncé des sites qui en ont. La fonctionnalité étant très récente, peu de sites la prennent en charge. Vous pouvez l’essayer sur NSHipster, métro[zen]dodo ou bien le blog de Kevin Chen.

mode clair / mode sombre

iOS n’ayant pas de mode sombre, cette nouveauté ne fonctionne évidemment pas dessus, mais cela devrait changer avec iOS 13.

Demandes de notifications moins intrusives (macOS)

À peine vous ouvrez un site web que celui-ci vous demande si vous voulez recevoir ses notifications. Ce cas ne se présente plus avec la nouvelle version de Safari sur Mac. Désormais, il faut que vous interagissiez avec le site pour que celui-ci puisse vous demander si vous autorisez ses notifications.

Nous n’avons pas trouvé quelle interaction précise déclenche l’envoi de la demande (clic ? défilement ?), elles ont toutes l’air bloquées sur la bêta. On rappelle au passage que vous pouvez bloquer toutes les demandes dans les options de Safari (Préférences > Sites web > Notifications > décocher la case Autoriser les sites web à demander s’ils peuvent envoyer des notifications).

Remplissage automatique (macOS et iOS)

Deux nouveautés pour le remplissage automatique des formulaires web. La première, c’est la validation automatique du formulaire une fois que les informations de connexion sont remplies. Il faut noter que 1Password a récemment pris le chemin inverse. Le gestionnaire de mots de passe ne valide plus automatiquement le formulaire par mesure de sécurité, notamment.

La deuxième, c’est le remplissage automatique déclenché à l’aide de Touch ID sur les Mac équipés. C’est donc synonyme de sécurité supplémentaire pour le remplissage de ces données.

Avertissement de connexion à un site non sécurisé (macOS et iOS)

Comme Chrome, Safari indique maintenant dans la barre d’adresse que le site est « non sécurisé » quand celui-ci ne gère pas le protocole HTTPS qui chiffre la connexion entre le client et le serveur. 

Retrait de Do Not Track et renforcement de l’Intelligent Tracking Prevention (macOS et iOS)

L’option « demander aux sites web de ne pas me suivre » n’est plus disponible dans Safari. Apple justifie son retrait par son obsolescence et, comble de l’ironie, par le fait qu’elle peut servir de variable pour identifier les internautes durant leur navigation (fingerprinting).

L’option « demander aux sites web de ne pas me suivre » a disparu.

Cochée, cette option envoyait la requête Do Not Track aux sites web pour leur demander de ne pas pister l’internaute durant sa navigation. La fonction n’a jamais eu l’effet escompté. Sa prise en compte dépend du bon vouloir des éditeurs, or la quasi-totalité d’entre eux ne l’ont pas adoptée.

Pourquoi est-elle considérée comme « obsolète » par Apple ? Parce que le groupe du W3C chargé de Do Not Track est fermé depuis mi-janvier, comme le confirme l’email d’un de ses membres.

Ça ne signifie pas que Safari ne fait plus rien pour lutter contre le pistage. Depuis iOS 11 et macOS High Sierra, le navigateur intègre l’Intelligent Tracking Prevention, une technologie qui empêche activement les sites de tracer les internautes. Cette protection est renforcée avec Safari iOS 12.1 (limitation du tracking à long terme avec les cookies de tierce partie et vérification des caches partitionnées).

Diverses nouveautés pour les développeurs

Safari 12.1 ouvre également de nouvelles possibilités aux développeurs web comme iOS/macOS. Il y a des ajouts dans les outils de développement, la CSS, les extensions Safari et d’autres API. On peut noter la prise en charge du codec VP8 de Google… dans le cadre de WebRTC seulement.

Safari 12.1 sera également disponible sur macOS High Sierra et Sierra.


avatar Vanton | 

Franchement je comprends pas cette mode du mode sombre en ce moment... Tout le monde s'en empare.
Perso ça me défonce les yeux de lire sur fond noir...
C'est juste pour faire "joli" ou bien il y a un vrai intérêt ?

avatar TimeMachine | 

@Vanton

Même chose. Alors qu’on dit que c’est sensé reposer nos yeux, j’ai eu le sentiment contraire sur macOS. Du coup je suis de retour sur le mode normal. J’espère que iOS 13 ne forcera pas le mode sombre.

avatar reborn | 

@Vanton

Moi j’apprécie, dès que possible j’utilise le mode lecture en mode foncé sur Safari.

avatar Vanton | 

@reborn

Mais parce que tu préfères esthétiquement ? Ou parce que tu trouves ça plus confortable ?

Chez moi ça a tendance à faire de la rémanence et ça me dérange beaucoup...

avatar reborn | 

@Vanton

Je trouve ça plus confortable que le blanc

avatar ForzaDesmo | 

@reborn

Idem, pour moi qui est photosensible (yeux clairs) c'est un plus ce mode sombre. Le mode nuit aussi est vraiment bénéfique pour moi (même si il faut en sortir parfois pour raison colorimétrique).

avatar Rodri31 | 

@Vanton

Justement c’est censé reposer les yeux surtout dans le noir c’est vraiment bizarre que ça te fasse mal aux yeux. Moi c’est quand je repasse au blanc ça me tue la rétine.

avatar SyMich | 

C'est amusant de se rappeler qu'en 1984 quand le Mac a introduit un affichage avec des textes noirs sur fond blanc, alors que tous les autres (PC, Apple II, Amiga, Amstrad, ...) écrivaient en blanc (ou vert ou ambre) sur fond noir, on soutenait que c'était beaucoup plus confortable...

avatar Michaeel | 

@Vanton

Même dans le noir ? De jour j’ai exactement le même avis que toi, lire sur fond noir est très désagréable, mais dans l’obscurité c’est très pertinent.

avatar Vanton | 

@Michaël.

Je suis rarement dans l'obscurité totale. J'ai toujours au minimum une lampe de chevet allumée.

avatar anonx | 

@Vanton

Oled = noir parfait = mode sombre

avatar Vanton | 

@anonx

Un peu simpliste...

avatar Paul_M | 

@anonx

Les macs n'ayant pas d'écrans OLED...

avatar anonx | 

@Paul_M

... pour le moment.

avatar Paul_M | 

@Vanton

Pareil, jamais compris l'intérêt. Même dans le noir ça améliore pas mon confort, et puis surtout je passe pas mon temps à utiliser mon ordi dans le noir quoi. A la limite mon téléphone des fois je le consulte dans la nuit, dehors ou chez moi, donc ça aurait vaguement un sens, mais quand j'utilise mon ordi j'allume la lumière.
Cela dit si ça plait aux autres c'est bien qu'Apple le propose en option.

avatar Vanton | 

@Paul_M

Oui si ça reste une option je m'en fous... Mais j'ai peur que ça finisse par être la norme...

avatar cecile_aelita | 

+1
moi non plus je n'en vois pas l'interet... a la limite pour l'autonomie sur les ecran OLED. mais pour le confort je prefere une interface claire

avatar Bigdidou | 

@Vanton

« Perso ça me défonce les yeux de lire sur fond noir...

Et bien moi, c’est l’inverse.
Donc moi, je comprends très bien le mode sombre, et je dois pas être le seul vu le succès qu’il rencontre.
Et chose formidable, il vient compléter le mode clair que tu peux garder
Donc, vraiment, tout va bien.

avatar Pascal R. | 

Ce serait bien que MacGeneration propose un mode sombre sur l’ensemble de ses sites pour tous ou dans le cadre de son offre Club MacG…

avatar Anthony Nelzin-Santos | 
@Pascal R. : le site du Club iGen prend déjà en charge ce mécanisme, et proposera d'autres thèmes de couleur. Patience !
avatar joso (non vérifié) | 

C’est génial ! Je vais l’adopter également très pratique pour soulager les yeux

avatar Rodri31 | 

Depuis la mise à jour iOS 11 et macOS high sierra, on ne peut plus choisir « pour ce site uniquement ». C’est soit tout les cookies ou rien du tout c’est chiant...

avatar irep | 

En mode sombre, il peut être plus confortable de diminuer un peu la luminosité de l'écran. Un texte trop blanc peut en effet donner une impression très désagréable.
De plus, un éclairage plus tamisé dans la pièce apporte un confort supplémentaire. Jamais le noir complet en tout cas.
De jour comme de nuit et quelque soit le mode, j'allume toujours une ou deux lampes de bureau placées si possible derrière l'écran et dirigées vers le mur devant moi. J'évite d'être face à une fenêtre. Plutôt à 45º si je n'ai pas d'autre choix.

avatar bigVince | 

Et toujours pas de drivers NVIDIA pour le mbp 2014 sous Mojave... pas la moindre explication officielle non plus... c’est scandaleux!

avatar cedricp | 

Est-ce que Safari est plus rapide ?
Sur MacBook Pro 2018 c'est très lent ! J'utilise donc Google Chrome mais je préférerais repasser à Safari

avatar Sucrier | 

On fait comment pour configurer un mode sombre sur son site ?

avatar Anthony Nelzin-Santos | 
@Sucrier : ça demande un peu de CSS, je l'ai expliqué ici : https://metrozendodo.fr/mode-sombre/
avatar Philbee | 

Je remarque surtout que, depuis la 12.0.3, on ne peut plus lancer la lecture d'une vidéo via un code javascript (obligation de cliquer sur un bouton "lecture" et donc de faire apparaitre les immondes commandes du player). Chrome et Firefox n'ont pas de telles restrictions !
La paranoïa sécuritaire (à géométrie variable...) de COOK cache manifestement un problème de compétence.

avatar jackhal | 

Mais comment font donc YouTube, Dailymotion, Vimeo et les autres milliers ou millions de sites qui ont des contrôles complètement personnalisés pour piloter l'élément video ?

Pour le reste, bravo pour ton message très dans l'air du temps : le problème de compétences est de ton côté, mais tu vas rejeter la faute sur d'autres quand même, et d'ailleurs ça remonte jusqu'à Cook et sa "paranoïa sécuritaire" (et à géométrie variable, donc injuste).

Le voilà, le problème : les élites te martyrisent. Les élites paranos qui s'amusent à faire planter le code des programmeurs du peuple par sadisme, folie et mépris de classe.

Ça peut plus durer, putain, trouve-toi un rond-point, fais quelque chose !

avatar Philbee | 

Je ne parlais évidemment pas de customisation du player video mais bien de lire un vidéo via une fonction javascript (ex : function playVideo(){var video = document.getElementById('video');video.play(); )} en l'associant à d'autres event qu'un click sur le bouton lecture (customisé ou non) du player.
Capice ?

avatar jackhal | 

J'ai surtout l'impression que tu viens de découvrir un truc qui est en place depuis High Sierra, soit plus de deux ans : https://webkit.org/blog/7734/auto-play-policy-changes-for-macos/

Et pour Chrome : https://www.macg.co/logiciels/2017/09/chrome-va-mettre-le-hola-sur-les-videos-en-lecture-automatique-99743

Fais gaffe à ce que tu crois qui fonctionne "sans restriction" ailleurs : c'est peut-être que ton navigateur a levé ses restrictions parce qu'il estime que tu as "montré ton intérêt" pour le site que tu développes (forcément !), mais ça ne sera pas le cas pour un nouveau visiteur.

P.S. : "Je ne parlais évidemment pas de customisation du player video"
dans ton premier message : "(obligation de cliquer sur un bouton "lecture" et donc de faire apparaitre les immondes commandes du player)"
=> bien sûr que si, tu parlais de customisation.

avatar Philbee | 

Non, car cela marchait avant la version 12.0.3 de safari et que cela n'a rien à voir avec l'autoplay (si tu sais ce que signifie le mot EVENT...)
De plus, l'idée de supprimer les boutons du player (que je trouve encombrants et disgracieux) n'a pas grand rapport avec une quelconque customisation du player.

avatar jackhal | 

Sur quel(s) event(s) tu lançais la lecture et pour lesquels ça fonctionnait avant, et plus depuis Safari 12.0.3 ?

avatar Philbee | 

Déclenchement - par un click sur un lien situé sur la page principale d'un site - d'une vidéo à l'intérieur d'une iframe lors de son chargement (onload)...je précise que cela ne fonctionne qu'en local et plus online.

P.S : désolé pour les nombreux edit du message mais je suis en plein boulot.

avatar jackhal | 

Bah chez moi ça marche aussi online.
Tiens, mon test à mettre dans deux fichiers
https://pastebin.com/BTkf7vVw

Je le met sur PasteBin parce que dans les commentaires de MacG, ça va sans doute foirer.
Il y a deux Play : un hors de l'iFrame (à gauche), un dedans. J'ai vu grand sur mon 27" mais si tu es sur un portable, réduire la hauteur de l'iFrame ne serait pas un mal.

P.S. : ce genre de trucs "ça marche en local mais pas online", c'est souvent lié au CORS. Tu devrais avoir des infos dans la console.

avatar Philbee | 

Si c'était lié au CORS cela ne marcherait pas sur Firefox (qui est une vraie calamité pour ça).
Je ne l'avais pas précisé quand tu as lu mon message la première fois mais la lecture de la vidéo est lié au chargement de l'iframe (event ONLOAD). Ce qui n'est pas le cas de ton exemple. Réessayes et tu verras en principe que cela ne marche pas (j'ai testé mon code sur plusieurs config et demandé à d'autres collègues qui n'ont pas trouvé de solutions à ce problème).

avatar jackhal | 

Ouais mais peut-être que tes collègues n'ont pas mon niveau ^_^

Bref ! Tu as deux solutions : une propre mais complexe, et une quick & dirty.

La propre consiste à mettre en place un squelette HTML dans ton iframe avec dès le début un élément video. Quand l'utilisateur clique, tu changes le src de la vidéo (que tu peux déjà avoir mis en attribut des liens, par exemple), lance le play, puis tu as tout le temps que tu veux pour charger le reste de la page en async, réinstaller les éventuels events, etc.
Je te le concède, c'est un peu élaboré.

La crade mais qui fonctionne consiste à faire un chargement synchro dans le onclick, remplacer le HTML de l'iframe, puis faire le play, le tout en restant dans l'event click.

Voilà le code :
https://pastebin.com/hz0ELcRQ

avatar Philbee | 

Tout d'abord je te remercie sincèrement pour ton aide :-)
Je ne sais pas pour la première méthode mais la seconde marche vraisemblablement à cause notamment du request.statut.
J'avais pensé à un timer mais je regrette qu'il faille compliquer les choses du fait de décisions arbitraires d'Apple.
Encore merci car ton code m'a donné pas mal d'idées ;-)

avatar jackhal | 

De rien :-)

Le request.status n'est là que pour vérifier que le chargement a fonctionné, à toi de traiter dans le else d'éventuels problèmes de chargement (404, 500...)

Ça marche parce que le code de lecture est dans l'event click. Si tu passes le code sur le onload de l'iframe, c'est considéré (à juste titre) comme un autre event détaché de l'event click, et le play n'est plus activable. Avec un timer tu aurais eu le même problème : quand le code aurait été exécuté, il l'aurait été dans un contexte détaché du click, et play n'aurait rien fait.

Si les choses deviennent complexes, c'est parce qu'Apple réagit aux abus, et notamment aux régies de pub qui sont prêtes à tout... y compris lancer automatiquement des pubs vidéo avec du son, d'où ce qui est à l'origine de ton problème.

C'est marrant, en écrivant ça je mes suis souvenu de la période où les navigateurs n'avaient pas de restrictions particulières sur les vidéos, et où les régies se sont mises à balancer de la pub avec vidéo et son. J'avais complètement oublié, mais c'était devenu très pénible pour ceux qui n'avaient pas de bloqueur de pub.

avatar Sucrier | 

Merci anthony je vais regarder ton lien

avatar MachuPicchu | 

C’est bien beau tout ça, mais il y a beaucoup de problèmes à résoudre avec Safari : entre Reddit qui est extrêmement lent au niveau de l’affichage et du défilement, et les vidéos Netflix qui bug quand on a précédemment regardé une vidéo YouTube , il est difficile de ne pas passer par un autre navigateur.

avatar itimik | 

on en parlait là au moment de la bêta : https://www.macg.co/os-x/2018/10/safari-tp-les-sites-web-peuvent-basculer-en-mode-sombre-en-fonction-de-macos-mojave-104045
au plus simple :

body, html, #main
{background:white; color:black;}
@media (prefers-color-scheme: dark)
{
body, html, #main
{background:black;color:white;}
}
@media (prefers-color-scheme: light)
{
body, html, #main
{background:white;color:black;}
}

avatar sas13 | 

Comme l'a déjà dit Symich, en 1984, la plupart des logiciels étaient en mode sombre (souvenirs de Appleworks! sur apple IIc), et que le basculement à l'écriture noire sur fond blanc est apparue alors comme un progrès lors de l'apparition du Machintosh......

avatar Vivid (non vérifié) | 

mode sombre; ce sont les contrastes trop prononcés qu'il faut éviter.. rien d'autres

CONNEXION UTILISATEUR