Apple introduit une propriété CSS privée pour ajouter l’effet Liquid Glass au contenu web

(alastair.is)

4 points par GN⁺ 2025-09-16 | 5 commentaires | Partager sur WhatsApp

Apple a ajouté la propriété CSS privée -apple-visual-effect utilisable dans iOS 26
Cette propriété permet d’appliquer au contenu web de nouveaux effets de design comme Liquid Glass et les matériaux de flou standard
Cette fonctionnalité n’est pas activée par défaut dans le navigateur Safari ni dans WKWebView
Pour l’utiliser dans WKWebView, il faut activer un réglage privé appelé useSystemAppearance, mais le modifier rend l’approbation sur l’App Store difficile
La fonctionnalité semble surtout utilisée en interne par Apple, et les développeurs ordinaires ne peuvent pas l’exploiter pour l’instant

Vue d’ensemble

L’auteur consulte souvent par curiosité le ChangeLog GitHub de WebKit pour anticiper les prochaines mises à jour d’iOS
Juste après la WWDC, il a repéré dans WebKit une pull request intitulée “[Materials] Rename 'hosted blur' materials to reference 'glass'”
Mis en avant à la WWDC 2025, Liquid Glass constitue le plus grand changement d’interface utilisateur (UI) depuis iOS 7
Jusqu’ici, cette évolution du design concernait uniquement l’UI native, mais cette PR laisse entrevoir un lien avec les vues web

La propriété CSS privée d’Apple

La PR révèle qu’Apple a introduit une propriété CSS privée appelée -apple-visual-effect
Grâce à cette propriété, il devient possible dans iOS 26 d’appliquer l’effet Liquid Glass (par exemple -apple-system-glass-material)
Il est aussi possible, sur toutes les versions, d’utiliser des matériaux de flou standard (-apple-system-blur-material-thin, etc.)
Ces matériaux sont également mentionnés dans le guide de design officiel

Possibilités d’utilisation concrètes

Même en modifiant le CSS dans Safari pour essayer de l’appliquer, cela ne fonctionne pas sur le web
Dans les apps basées sur WKWebView, la fonctionnalité est désactivée par défaut
Il faut définir useSystemAppearance de WKPreferences sur true pour que cela fonctionne, mais ce réglage est lui-même privé, donc inutilisable par la voie officielle

En activant officieusement cette valeur via un hack puis en appliquant le CSS suivant, on peut voir l’effet

.toolbar {  
  border-radius: 50%;  
  -apple-visual-effect: -apple-system-glass-material;  
  height: 75px;  
  width: 450px;  
}

Exemple CSS et application conditionnelle

Apple a créé cet effet sous forme de propriété CSS afin de permettre de définir simplement différentes règles selon la disponibilité du support

Par exemple, on peut utiliser une requête @supports pour n’appliquer -apple-visual-effect que sur les appareils compatibles

.toolbar {  
  border-radius: 50%;  
  height: 75px;  
  width: 450px;  
  background: rgba(204, 204, 204, 0.7);  
}  

@supports (-apple-visual-effect: -apple-system-glass-material) {  
  background: transparent;  
  -apple-visual-effect: -apple-system-glass-material  
}

Portée et limites

Il s’agit d’une fonctionnalité inutilisable par les développeurs ordinaires en dehors d’Apple
Mais elle donne un indice sur la raison pour laquelle les webviews intégrées aux apps ont parfois mauvaise réputation
Lorsqu’une webview est intégrée de manière fluide et transparente, l’utilisateur ne remarque même pas sa présence, ce qui réduit les occasions où les problèmes deviennent visibles
Le fait qu’Apple ait développé cela suggère indirectement qu’elle l’utilise réellement dans ses propres services ou applications
Il est possible que vous fassiez déjà l’expérience, sans le savoir, d’interfaces basées sur des webviews au quotidien

5 commentaires

ahwjdekf 2025-09-18

Il faut ignorer ce genre d’absurdité et veiller à ce que personne ne l’utilise.

coremaker 2025-09-17

J’ai applaudi quand Apple a tué Flash, parce que les intérêts convergeaient,
mais il est ironique que ce choix actuel donne l’impression d’ignorer l’écosystème existant.

Le retour d’IE ?

spp00 2025-09-18

Depuis l’époque d’IE, du point de vue des développeurs frontend, le navigateur qui occupait la position d’IE n’était pas Chrome mais Safari. À cause de Safari, les développeurs frontend doivent acheter des Mac coûteux. Chrome et Firefox fonctionnent, mais il arrive que seul Safari ne fonctionne pas ou affiche les choses de façon étrange.

GN⁺ 2025-09-16

Avis Hacker News

Le fait de réserver certaines fonctionnalités de l’OS uniquement à ses propres apps est clairement une pratique anticoncurrentielle. Utiliser une position dominante sur les marchés du téléphone et du système d’exploitation pour employer, sur le marché des apps, des fonctionnalités refusées aux concurrents en est un exemple évident.
- Au départ, j’avais envie d’en vouloir à Apple, mais en fait non. Il suffit de lire la documentation WinAPI pour voir un nombre énorme de paramètres marqués « reserved ». Les développeurs d’OS créent souvent des fonctionnalités destinées à un usage interne uniquement. Ici, comme il s’agit juste d’une amélioration d’interface, je ne pense pas qu’il y avait une nécessité absolue de la garder privée, mais Apple l’a probablement laissée privée parce qu’ils ne veulent pas avoir à la maintenir durablement.
- Est-ce qu’on dit vraiment que toutes les propriétés CSS non standard sont « anticoncurrentielles » ? Je me demande alors si la propriété de Google « -webkit-tap-highlight-color » devrait être critiquée de la même manière. La logique reviendrait à interdire la pratique même de créer des propriétés CSS propriétaires, ce qui me paraît excessif.
- Je ne suis pas certain que, juridiquement, ce soit vraiment un « acte manifestement anticoncurrentiel ». Aux États-Unis, ce sont le Sherman Act et le Clayton Act qui s’appliquent. Comme cela ne figure pas dans la liste des infractions « per se », on appliquerait probablement la « rule of reason ». Dans ce cadre, il faut montrer que le comportement nuit directement à la concurrence, sans effets positifs notables ni alternative moins restrictive. Il serait difficile de prouver quel dommage concret cette propriété CSS cause à la concurrence, et comme rien n’empêche quelqu’un d’implémenter lui-même un CSS « liquid glass », cela me semble difficile à faire valoir.
- Je me demande ce que vous en pensez dans des cas bien plus restrictifs, comme le matériel informatique. Par exemple, sur les consoles de jeux vidéo, tout le code doit être signé et chiffré, et aucun tiers ne peut distribuer de logiciel sans l’autorisation du fabricant.
- Si on considère que rendre le texte de l’interface difficile à lire constitue un avantage concurrentiel, alors oui, pourquoi pas.
J’aime bien la « grande théorie d’Alastair sur les webviews intégrées aux apps » : si les webviews embarquées ont si mauvaise réputation, c’est surtout parce qu’une webview vraiment bien intégrée passe inaperçue pour l’utilisateur.
- Il y a une énorme différence entre quelqu’un qui a déjà réellement implémenté une webview et quelqu’un à qui on a dit qu’il suffisait d’emballer une webapp dans une app native. La plupart des gens sont dans le second cas.
- C’est probablement pour ça que cette fonctionnalité a été introduite. En général, une façon peu coûteuse de vérifier si une app utilise un toolkit UI tiers consiste à changer le thème système et voir si l’app suit correctement les changements de thème, de couleurs ou d’échelle. Même certaines apps fournies par Apple ne reflètent pas correctement le thème, donc ils ont sans doute fini par créer une propriété CSS privée. À l’inverse, certains autres fournisseurs d’OS suppriment carrément les contrôles de thème pour éviter d’avoir à gérer plusieurs toolkits inachevés.
- Si quelqu’un peut citer ne serait-ce qu’un seul exemple d’app basée sur une webview parfaitement intégrée, je l’admettrai. L’utilisateur moyen ne le remarquerait peut-être pas, mais si cela existait vraiment, cela aurait forcément déjà été mentionné au moins une fois sur Hacker News. On l’aurait déjà vu revenir à chaque débat sur les webviews comme contre-exemple du style : « Oui mais l’app Foo est faite en webview, et elle marche parfaitement. »
- Ça me fait penser à : « Les perruques ont toujours l’air fausses. Je n’en ai jamais vu une seule qui paraissait vraie. »
On dit que « cette fonctionnalité a forcément été créée parce qu’Apple en a besoin », mais personne ne sait où elle est utilisée. Si je devais deviner, je dirais les réglages iCloud dans l’app Réglages, ou les pages de compte dans App Store/Music/TV (tap sur l’icône de profil en haut à droite). Ces pages sont souvent des webviews cachées qui essaient d’avoir l’air natives. L’indice, c’est qu’un appui long affiche parfois un aperçu de page web sur les liens ``. Le guide utilisateur dans l’app Tips est aussi un candidat plausible. Ce sont les premiers endroits que j’irais vérifier.
C’est intéressant qu’on suppose qu’« Apple l’utilisera quelque part », alors qu’en pratique nous n’avons pas réussi à identifier où. Nous croisons probablement des webviews en permanence dans iOS sans même nous en rendre compte.
- Je soupçonne souvent l’app Réglages, surtout la partie compte ou iCloud, d’être une webview. Il y a de petits indices, comme certaines icônes qui semblent apparaître avec un léger retard au chargement.
- L’app App Store semble aussi utiliser énormément de webviews.
- D’après ce que je sais, Mail et Calendar en utilisent pas mal également.
- Je pense qu’ils vont aussi l’utiliser sur Apple.com, comme ils l’avaient fait avec backdrop-filter pour les effets de flou de fond sur iOS.
- Apple Music semble aussi s’appuyer assez largement sur des webviews.
Belle trouvaille. La nouvelle interface « verre » d’Apple est très critiquée, mais moi je l’aime bien. J’ai l’impression que l’OS retrouve enfin une vraie personnalité au lieu d’être simplement terne et uniforme. Les zones cliquables sont aussi plus faciles à repérer, et on distingue mieux visuellement les boutons du texte ordinaire. Je trouve que c’est un changement bienvenu. Ce n’est pas seulement de la « nostalgie », c’est aussi un changement réellement pratique. J’ai installé iOS 26 Beta en avance pour tester des sites, et même s’il y a quelques soucis, la direction générale — donner plus de caractère à l’OS — me paraît bonne. Je pense que les utilisateurs ordinaires aimeront aussi.
- J’aime bien l’effet verre et l’esthétique, mais dans plusieurs apps, sur le plan fonctionnel, c’est devenu moins pratique qu’avant. Des boutons autrefois faciles d’accès sont maintenant cachés derrière des menus et plus difficiles à trouver.
- À mon avis, le grand public n’aimera pas vraiment ce changement, au sens large. Les gens qui pensent qu’« un système d’exploitation devrait avoir de la personnalité » sont une minorité de passionnés de tech. La majorité voit surtout l’OS comme un simple moyen de faire quelque chose, donc ce type de changement visuel n’a souvent pas beaucoup d’intérêt au-delà de la curiosité. Ce qui me gêne le plus dans le design liquid glass, c’est la nouvelle barre d’onglets inférieure. Apple Music est le pire cas. Il faut maintenant un clic de plus pour accéder à l’interface Search, et même après avoir cliqué dans la Search Box, il faut encore une action séparée pour faire apparaître le clavier. En plus, des animations complexes et lentes ont été ajoutées à chaque interaction. Par exemple, quand on passe de Home à Library, l’onglet gonfle comme une bulle au-dessus de la barre puis glisse en scintillant ; c’est distrayant sans être utile. Des réglages d’accessibilité comme Reduce Transparency ou Reduce Motion ne s’appliquent pas à ces animations. En réalité, plusieurs apps par défaut d’Apple oublient récemment d’appliquer ces options, ou les gèrent mal. Par exemple, avec Reduce Motion activé, certaines animations, comme l’ouverture d’un album, sont simplifiées, mais les gestes de balayage vers la gauche ou d’autres actions restent encore beaucoup trop animés. Même chose dans Apple Podcasts et iMessage. Quant à Reduce Transparency, dans certaines apps cela remplace simplement la transparence par des fonds entièrement noirs (#000000). On voit ce genre de cas partout dans iOS. Et à quelques jours de la sortie, il reste encore des endroits — comme les menus déroulants ou les boutons de clavier inactifs — où les options d’accessibilité ne sont pas prises en compte.
- Dire que « la taille des cibles cliquables est visible et que les boutons sont clairement distincts du texte » n’est pas, en réalité, une barre très haute.
- Personnellement, je suis plutôt dans le camp du « ce design est vraiment affreux ». Je ne comprends pas ce qu’Apple a voulu faire.
Il est possible qu’Apple ne veuille simplement pas encore que qui que ce soit utilise cette fonctionnalité. Vu l’annonce du nouvel OS, beaucoup de développeurs seraient probablement tentés de l’adopter immédiatement ; Apple veut peut-être d’abord verrouiller son propre usage interne avant de l’exposer. Il y a aussi pas mal d’accusations gratuites dans ce fil. On ne sait pas encore qui a raison.
L’idée que « c’est forcément pour l’utiliser chez Apple » n’est pas toujours vraie. Dans les vrais logiciels, il y a énormément de code ou de fonctionnalités qui ne servent finalement jamais. Au fil des changements de direction, on peut très bien ajouter une propriété CSS à l’étape 2, puis la supprimer complètement à l’étape 4.
J’espère sincèrement que le liquid jelly ne deviendra pas une tendance.
- Qu’on aime ou non le liquid glass, le changement de paradigme qui fait passer le chrome de l’UI de « quelque chose qui entoure le contenu de l’app » à « quelque chose qui recouvre le contenu » est tourné vers l’avenir. Cela va bien avec l’AR, et permet aussi de mieux séparer UI et contenu selon les tailles d’écran. L’implémentation actuelle a ses qualités et ses défauts, mais cette approche va probablement se généraliser. Le modèle d’UI en overlay n’a d’ailleurs pas besoin d’être transparent : il peut aussi être opaque tout en restant flottant.
- Les plus jeunes sont nostalgiques de l’esthétique Aero/Glass. Comme c’est Apple qui l’introduit, cela risque fort de devenir une tendance. Dans toute l’industrie, il y a cette ambiance où tout le monde finit par copier ce qu’Apple fait.
- Personnellement, j’aimerais surtout qu’ils retirent l’effet de rebond/gigue. Ça tremble et oscille beaucoup trop, au point que cela ressemble davantage à une sorte de blob gélatineux qu’à du verre.
- Moi aussi, j’espère que ça ne prendra pas, mais honnêtement, je pense que si Apple le fait, tout le monde finira par suivre.
- C’est déjà en train de devenir une tendance.
On dit qu’il faut activer un réglage useSystemAppearance dans WKPreferences, mais comme c’est privé, une app ne pourrait pas être approuvée sur l’App Store. Je me demande si c’est vrai. Je ne connais pas très bien le développement iOS, mais je me souviens avoir vu une vidéo où quelqu’un décompilait une app qui animait des widgets d’écran d’accueil en utilisant diverses API internes.
- Ce genre de chose ne passe pas la revue de l’App Store.
- Tu parles de cette vidéo ?
C’est la mode la plus moche que j’aie vue depuis les coins arrondis et les gros paddings. J’espère qu’elle disparaîtra au plus vite.

addons 2025-09-17

Arrêtez vos conneries et occupez-vous déjà correctement de la compatibilité de Safari.