[Résolu] Problème taille de texte minuscule sur mobile

Bonjour,

Je développe une plate-forme de jeux spécialement conçue pour être accessibles avec les lecteurs d'écran depuis plus de 13 ans.

Depuis quelques mois, dans le cadre d'une nouvelle version, j'aimerais améliorer un peu l'interface utilisateurs pour les personnes malvoyantes et bien voyantes.
Il ne s'agit pas d'une révolution, loin de là, ça va rester quoi qu'il arrive assez austère, et volontairement extrêmement simpliste. Mais s'il y a des choses que je peux améliorer sans trop de difficulté, c'est toujours bénéfique.

Malheureusement je suis tombé sur un problème que je n'arrive absolument pas à comprendre et à corriger.

IL y a quelques utilisateurs malvoyants qui m'ont fait les retours suivants lorsqu'ils ont essayé d'aller sur le site en bêta et de jouer sur leur smartphone iPhone ou Android:

* Le texte est minuscule et totalement illisible. ON peut parfois s'en sortir en zoomant beaucoup, mais c'est pénible.
* La taille du texte est différente entre le site web en général, et la page du jeu spécifiquement. C'est écrit encore plus petit sur la page du jeu, et donc c'est encore pire.
* Sur la page du jeu, les boutons sont parfois inopérants et on a beaucoup de difficulté à cliquer dessus. Je n'ai pas pu vraiment déterminer si c'était lié à leur taille, ou s'il y a un autre bug. La particularité étrange est que tout fonctionne correctement lorsque le lecteur d'écran (VoiceOver ou Talkback) est actif. Pas de problème non plus pour ceux qui jouent avec un clavier externe en blutooth sans toucher l'écran.

Ceux qui ont testé sur PC Windows n'ont pas l'air d'avoir eu de grosse difficulté, pas plus qu'une personne ayant testé sur une tablette Android.
JE n'ai pas eu de retours sur Mac ou iPad.

Mon code CSS n'a rien d'extraordinaire.

* Les tailles de police sont toutes exprimées en em et rem, sauf :root qui spécifie font-size: 112.5% que j'ai mis pour tester. Ce qui est censé être déjà assez gros d'après ce que j'ai pu lire (habituellement c'est plutôt 62.5 ou 87.5% qui sont conseillés)
* J'évite en général de fixer des tailles pour les éléments, même relatives, en espérant que le navigateur soit assez malin pour faire quelque chose un minimum présentable (c'est peut-être là que je me trompe).
* La page du jeu est subdivisée en diverses zones définies avec grid layout, c'est ce qui me paraissait le plus simple.

JE suis un peu emprunté pour vous coller du code directement ici, car je ne sais pas trop quelle partie du code pose problème. Est-ce que c'est vraiment du CSS ? Il y a peut-être un souci dans le HTML aussi ?
Je ne vais tout de même pas vous balancer 1000 lignes de HTML/CSS sans avoir ciblé un peu d'abord, d'autant que l'essentiel est généré dynamiquement en JavaScript (je vous rappelle que c'est un jeu !)

J'ai tenté de lancer une analyse avec Lighthouse dans les dev tools de chrome en mode mobile, et j'avoue que je ne comprends pas grand chose aux résultat qu'il me donne.

* Il m'avertit effectivement que la plupart des éléments sont trop petits pour être cliquables (plus de 60% des éléments), mais outre la taille minimale conseillée, il ne me dit pas vraiment comment y remédier.
* Il me dit que la taille de la fenêtre est de +960px alors qu'il s'attend à une taille de ~400px, ça doit être l'explication des textes et des boutons minuscules, mais là aussi, je ne comprends pas trop ce que je dois faire, et d'où il sort ce 960px alors que je n'ai jamais défini de taille fixe nulle part (je vous ai dit, j'évite ça soigneusement, peut-être un peu trop)
* Il m'a conseillé d'ajouter une balise <meta name="viewport" content="width=device-width, initial-scale=1" />, je l'ai fait, ça n'a pas l'air de changer grand chose à part faire disparaître quelqeus erreurs, et je ne comprends pas trop ce que ça fait. En tout cas ça ne règle pas mon problème de taille de texte.

Comment régler ce problème de taille de texte beaucoup trop petite ? Que dois-je faire ?
Pourquoi la taille de texte est différente entre le jeu et le reste du site web alors que c'est la même base en CSS ?

Si au-delà de ce problème de taille de texte vous avez des conseils utiles pas trop compliqués à mettre en place pour améliorer facilement l'apparance visuelle, je suis preneur.

Pour tester, ça se passe ici.
La page d'accueil de la nouvelle version: http://dev.qcsalon.net/fr/
Lien direct vers la page du jeu nouvelle version: http://dev.qcsalon.net/fr/game

Trois comptes à accès limité sont disponibles pour tester:
Demo1: Demo1Pwd
Demo2: Demo2Pwd
Demo3: Demo3Pwd

Merci beaucoup pour votre aide.
Modifié par QuentinC (13 Apr 2024 - 19:34)

Hello,

a écrit :
Par contre, sur Iphone, le menu en haut de page n'est pas visible quand on clique dessus (la page se grise et on ne voit pas apparaitre le menu).

Arf, je croyais l'avoir réglé, celui-là...
IL doit y avoir encore un petit bug de récupération des coordonnées du clic côté JavaScript.

a écrit :
Mon conseil : laisse la taille par défaut de 1 rem. Idéalement, ne spécifie pas de taille de caractères du tout sauf cas exceptionnel (certains boutons par exemple). L'utilisateur a toujours la possibilité d'augmenter lui-même la taille des caractères s'il en a besoin.

D'accord. Du coup je vais aller changer le 112.5% en 1rem.

J'avais lu quelque part que c'était conseillé de mettre une taille sur :root ou html, car la taille par défaut est complètement inadaptée.
Du coup c'est du vent ?
C'était un vieux truc pour contenter IE qui n'a plus de sens aujourd'hui ?

a écrit :
Par contre il faut tester le site si l'utilisateur augmente la taille des caractères. En théorie, il faut que la mise en page tienne au moins jusqu'à 2 fois la taille normale des caractères.

Vu qu'il n'y a pas de taille fixe nulle part, ça ne devrait pas poser de problème, même si on agrandit 10 fois, si ?
ON devra juste scroller plus mais voilà.

Normalement, pour le jeu, chacune des zones importantes de la grille sont censées être scrollables.

a écrit :
Il y a en effet beaucoup de détails à améliorer. Il va falloir les régler un par un : un travail de fourmi. Je commence déjà à chercher, mais il y en a pour des semaines de boulot.

Je sais bien que je ne règlerai jamais tout, et ce n'est pas le but. Je n'ai pas l'intention de faire du super design, ça va rester essentiellement textuel. Il faudrait revoir le fonctionnement même du coeur du système pour changer ça.
Le but, c'est de corriger ce qui est le plus problématique, et le plus facile à faire.

a écrit :
Cette ligne est absolument indispensable pour que la taille des caractères s'adapte comme il faut sur les téléphones. Ça n'a peut-être pas réglé tous tes problèmes de taille des caractères, mais ça a dû en régler certains. Ceci dit, je n'ai pas trouvé où il restait des problèmes de taille de caractère.

Ah ? Donc tu ne constates aucune différence entre la page du jeu quand on est effectivement entré sur la plate-forme, et la page d'accueil par exemple ?
Et la taille des textes n'est pas totalement déconnante ni dans un cas ni dans l'autre ?

Note que pour voir le problème, il faut s'identifier sur le site avec le même login/pass en plus du mot de passe général apache. Les deux identifications sont en fait totalement décorrellées.


Merci.
Bonne soirée.

Bonjour,

QuentinC a écrit :
J'avais lu quelque part que c'était conseillé de mettre une taille sur :root ou html, car la taille par défaut est complètement inadaptée.
Du coup c'est du vent ?
C'était un vieux truc pour contenter IE qui n'a plus de sens aujourd'hui ?

C'est du vent en 2024 selon moi. En ce qui me concerne, je ne spécifie pas du tout de taille de caractères pour le corps des textes. Par contre, pour les boutons, les menus, les titres, ...  là, évidemment, ça peut avoir du sens.

QuentinC a écrit :
Vu qu'il n'y a pas de taille fixe nulle part, ça ne devrait pas poser de problème, même si on agrandit 10 fois, si ?

Ça a l'air de bien se passer en effet si l'utilisateur grossit le texte.

QuentinC a écrit :
Ah ? Donc tu ne constates aucune différence entre la page du jeu quand on est effectivement entré sur la plate-forme, et la page d'accueil par exemple ?
Et la taille des textes n'est pas totalement déconnante ni dans un cas ni dans l'autre ?

Pour l'instant, sur iphone, je n'ai pas pu cliquer sur le menu, donc je n'ai pu tout voir. Mais sur les pages que j'ai pu voir, il n'y avait pas de problème de taille de caractère.

Fais marcher ton menu déjà.

Amicalement,
Modifié par parsimonhi (15 Apr 2024 - 01:04)

a écrit :
Pour l'instant, sur iphone, je n'ai pas pu cliquer sur le menu, donc je n'ai pu tout voir. Mais sur les pages que j'ai pu voir, il n'y avait pas de problème de taille de caractère.

Globalement pour le site ça a l'air d'aller, c'est déjà ça.

Mais donc tu n'as pas encore vu le plus important.

En attendant que je trouve une solution pour le menu, tu peux y aller directement avec ce lien: http://dev.qcsalon.net/fr/game
ON peut aussi cliquer sur le deuxième lien dans la section liens rapides.

Merci.

Bonjour,

A propos des PWA :

QuentinC a écrit :
Notez toutefois que vous ne pourrez pas profiter totalement de cette nouveauté à partir d'iOS 17.4 si vous vous situez dans l'union européenne.
Dans ce cas, l'ajout à l'écran d'accueil aura le même effet qu'auparavant, c'est-à-dire l'ouverture d'un simple signet, avec les éléments natifs et les restrictions normales de Safari.
La faute est à mettre sur le compte de stupidités politico-légales imposées par l'UE.

Finalement la firme à la pomme est revenue sur sa décision : elle garantira l'accès aux PWA à partir des autres navigateurs, mais en ouvrant l'application dans le sien (Safari donc).

Bonjour,

a écrit :
Finalement la firme à la pomme est revenue sur sa décision : elle garantira l'accès aux PWA à partir des autres navigateurs, mais en ouvrant l'application dans le sien (Safari donc).

J'étais au courant. Je n'ai même pas pris la peine de mettre à jour la news parce que cette version a été retirée quelques jours après sa mise en place, précisément pour le problème pour lequel je suis venu chercher de l'aide ici.

Merci.

Bonjour,

QuentinC a écrit :
En attendant que je trouve une solution pour le menu, tu peux y aller directement avec ce lien: http://dev.qcsalon.net/fr/game

J'ai testé sur iphone et les caractères apparaissent trop petits.

J'ai téléchargé la page (via menu "Fichier" + "Enregistrer la page sous" de Chrome). J'ai bidouillé ton code et je suis arrivé à faire apparaitre les caractères à une taille lisible en effectuant les modifications suivantes :
1) suppression des lignes ci-dessous dans le code html :

<meta name="viewport" content="minimal-ui">
<meta name="apple-mobile-web-app-capable" content="yes">

2) suppression de la ligne suivante dans le fichier normalize.css

-webkit-text-size-adjust: 100%;

Je suppose que tu avais ajouté ces lignes pour essayer de régler le problème des caractères trop petits. Elles perturbent plus qu'elles ne règlent les problèmes.

Par contre la ligne suivante est fondamentale et doit être conservée :

<meta name="viewport" content="width=device-width, initial-scale=1">

Il se peut que les modifications que j'ai proposées ne suffisent pas sur le site en ligne. À tester !

EDIT: il semble que la ligne suivante pourrait être finalement conservée :

<meta name="apple-mobile-web-app-capable" content="yes">

Amicalement,
Modifié par parsimonhi (15 Apr 2024 - 19:07)

a écrit :
Je suppose que tu avais ajouté ces lignes pour essayer de régler le problème des caractères trop petits. Elles perturbent plus qu'elles ne règlent les problèmes.

En fait, pas vraiment.

<meta name="viewport" content="minimal-ui">
Ca c'est censé masquer la barre d'adresse et les boutons de base du navigateur, offrant un espace supplémentaire.
Une fois qu'on est sur la page du jeu, on n'en a plus besoin normalement, notamment si on atterrit directement sur cette page grâce à un favori ou un raccourci.

Mais quelque chose vient de me faire tilt en le relisant. Peut-être que ça entre en conflit avec
<meta name="viewport" content="width=device-width, initial-scale=1" />
vu que la clé name="viewport" est la même ?

<meta name="apple-mobile-web-app-capable" content="yes">
J'avais lu quelque part que cette balise était nécessaire pour indiquer à Apple que
1 - on peut ajouter un raccourci sur l'écran d'accueil
2 - on peut l'ajouter en tant que PWA
Mais ça fait déjà un bon bout de temps, c'est peut-être obsolète, et pour les PWA, le manifeste suffit peut-être aujourd'hui.

-webkit-text-size-adjust: 100%;
Ca je n'ai aucune idée de ce que ça fait vraiment, comme pas mal de choses qui se trouvent dans normalize.css, et la doc n'est pas hyper claire sur les déclarations propriétaires. C'est un truc que j'ai pompé sur npm.
J'ai cru bon de le faire pour avoir moins de tracas en CSS, mais c'est peut-être là que j'ai tout faux. Ca n'a peut-être plus d'intérêt en 2024, maintenant que IE est définitivement mort.
Est-ce que c'est bien ou pas ces projets de normalisation CSS ? Est-ce que je ferais mieux de m'en débarrasser totalement en fait ?

J'ai commenté ces trois éléments pour voir ce que ça donne, comme tu l'as suggéré.
J'ai aussi changé le font-size: 112.5% en 1rem comme conseillé plus tôt.

Est-ce que c'est mieux ? OU bien au final ça ne change rien ?

Merci.

Bonjour,

QuentinC a écrit :
Est-ce que c'est bien ou pas ces projets de normalisation CSS ? Est-ce que je ferais mieux de m'en débarrasser totalement en fait ?

Tout ce que je peux te dire, c'est que je n'ai jamais utilisé ce genre de truc, et j'ai survécu.

QuentinC a écrit :
J'ai commenté ces trois éléments pour voir ce que ça donne, comme tu l'as suggéré.
J'ai aussi changé le font-size: 112.5% en 1rem comme conseillé plus tôt.

Est-ce que c'est mieux ? OU bien au final ça ne change rien ?

Le problème de taille des caractères semble réglé (sur mon Iphone).

Amicalement,

Bonjour,

Sur mon android, navigateur Samsung, Les textes sont aussi bien lisibles.
Reste un défaut d'affichage sur la dernière ligne, l'input texte et le bouton envoyer sont coupés et ce qui se trouve sous le "baseline" n'est pas visibles :

En agrandissant la taille du dernier row à 2 ou 2.2em au lieu de 1.8em

#app.desktop1 {
  grid-gap: 0.25em 0.5em;
  grid-template-columns: 2fr 1fr;
  grid-template-rows: 1fr 4.2em 2.2em;
  grid-template-areas:
"history game   " 
"actions actions" 
"chat    chat   ";
}

C'est mieux

a écrit :

Sur mon android, navigateur Samsung, Les textes sont aussi bien lisibles.
Reste un défaut d'affichage sur la dernière ligne, l'input texte et le bouton envoyer sont coupés et ce qui se trouve sous le "baseline" n'est pas visibles :

En agrandissant la taille du dernier row à 2 ou 2.2em au lieu de 1.8em
C'est mieux

J'ai fait la correction.

IL semble donc que le problème principal avec la taille des textes soit maintenant résolu, sur iOS comme sur Android.

Il me reste à corriger le bug des menus sur iPhone, ce n'est pas encore fait. Sur mon iPhone 12, lorsque VoiceOver est actif, j'ai l'impression que les coordonnées calculées par JavaScript ne sont pas déconnantes. Évidemment je ne peux pas tester sans VoiceOver. Si nécessaire, je posterai le code ce soir.

Est-ce que ces menus fonctionnent sur Android ?
JE n'ai pas de téléphone Android.

Est-ce que vous voyez d'autres choses qui sont améliorables / corrigeables facilement ?

Merci beaucoup pour vos réponses.

Bonjour,

QuentinC a écrit :
Est-ce que ces menus fonctionnent sur Android ?

Depuis mon mobile android et le navigateur Samsung, pour moi c'est oui
Les différents liens sont peut-être un peu trop serrer, il est facile de taper sur le mauvais lien. soit j'ai de gros doigts ou je suis trop enthousiaste maladroit Mais en y prenant garde , pas de soucis, je ne pense pas que cela soit un véritable probléme , On peut facilement zoomer sur la page.

Cordialement,

Bonsoir,

Pour le menu qui ne marche pas sur iPhone, je crois que j'ai trouvé.
Est-ce que quelqu'un pourrait confirmer que le menu s'affiche bien sur iPhone maintenant ? et à une position raisonnablement correcte ?

Merci.

Pour ceux qui aiment les détails, voici le code qui s'exécute au clic, avant modification.

1. Je récupère l'élément qui a le focus, c'est l'élément sur lequel on vient de cliquer (le lien "Menu")
2. JE calcule où afficher le menu, soit en-dessous de l'élément cliqué, soit au-dessus au cas où l'afficher en-dessous le ferait sortir de la fenêtre
3. Je place le menu à la position calculée

let menu = $1(e.target.getAttribute('data-popup-menu'));
let initial = menu.$1('[aria-current]') || menu.$('a')[0];
let overlay = create('div', { class: 'overlay' });
lastFocus = document.activeElement;
let eX = e.x || e.clientX || e.pageX, eY = e.y || e.clientY || e.pageY;
let lfr = (lastFocus && lastFocus.getBoundingClientRect()) || { x: eX, y: eY, left: eX, right: eX, top: eY, bottom: eY, width: 0, height: 0 };
let winWidth = window.innerWidth, winHeight = window.innerHeight;
menu.removeAttribute('hidden');
let mr = menu.getBoundingClientRect();
let mX = Math.max(0, Math.min(lfr.x, winWidth - mr.width));
let mY1 = lfr.bottom +10, mY2 = lfr.top - mr.height -10;
let mY = mY1+mr.height>winHeight? mY2 : mY1;
menu.style.position = 'absolute';
menu.style.left = mX + 'px';
menu.style.top = mY + 'px';
menu.style.zIndex = 100;
initial.focus();

Vous avez trouvé où était le bug ?

Il se situe à l'étape 1, récupérer l'élément qui a le focus. Sur Windows, que ce soit avec Chrome, Firefox ou Edge, cliquer sur le lien lui donne le focus.
C'est donc le bon élément qui est récupéré, et le calcul se déroule comme je l'ai prévu.

Selon vos dires, pas de problème non plus sur Android.

Sur iPhone, c'est là que ça devient intéressant. Testé avec DevBrow (parce que tester avec Safari c'est ultra casse-pieds pour recharger les scripts).

Si VoiceOver est actif, le lien qui ouvre le menu a le focus au moment du clic, et donc, ça fonctionne.
VoiceOver donne en réalité le focus au lien au moment où on tombe dessus avec le doigt ou bien quand on l'atteint à l'aide des balayages gauche/droite normaux (c'est semble-t-il son fonctionnement habituel pour les éléments focusables, sauf dans certains cas).

Mais ! Si VoiceOver n'est pas actif, alors, le focus n'est pas donné à l'élément au moment du clic (ou peut-être pas encore). Avec un peu d'adresse et de chance j'ai réussi à le tester.
Dans ce cas document.activeElement == document.body par défaut, et le calcul fait du coup forcément afficher le menu hors de la fenêtre.

La correction est simple une fois qu'on a pigé:

let lfr = (lastFocus && lastFocus != document.body && lastFocus.getBoundingClientRect()) || { x: eX, y: eY, left: eX, right: eX, top: eY, bottom: eY, width: 0, height: 0 };

Donc ça va s'afficher un peu différemment qu'ailleurs quand même, puisque ça sera invariablement 10px en-dessous ou en-dessus du point du clic. La valeur de 10px est complètement arbitraire, je peux la changer si nécessaire.

Il faut toujours qu'Apple décide de faire autrement que les autres !

Donc voilà, maintenant ce menu devrait fonctionner correctement.

Si vous voyez d'autres petites choses que je pourrais facilement améliorer, n'hésitez pas.

Merci !
Modifié par QuentinC (18 Apr 2024 - 22:56)

Bonjour,

QuentinC a écrit :
Est-ce que quelqu'un pourrait confirmer que le menu s'affiche bien sur iPhone maintenant ? et à une position raisonnablement correcte ?

Ça s'affiche sur mon iphone et c'est utilisable.

QuentinC a écrit :
Pour ceux qui aiment les détails, voici le code qui s'exécute au clic, avant modification.

Ça me semble bien compliqué. Tout ça était-il nécessaire ?

QuentinC a écrit :
Mais ! Si VoiceOver n'est pas actif, alors, le focus n'est pas donné à l'élément au moment du clic

Subtile ! Bien joué.

QuentinC a écrit :
Il faut toujours qu'Apple décide de faire autrement que les autres !

Ça dépend de qui fait les choses en premier. Variante 1 : ce sont les autres qui décident de ne pas faire comme Apple. Variante 2 : les autres doivent faire autrement quand on ne les laisse pas copier Apple.

Amicalement,

Bonsoir,

a écrit :
Ça s'affiche sur mon iphone et c'est utilisable.

Super ! Merci.

a écrit :
Ça me semble bien compliqué. Tout ça était-il nécessaire ?

Peut-être pas, mais je ne vois pas comment je pourrais faire apparaître le menu au bon endroit sinon, sachant que le code ci-dessus est utilisé pour plusieurs menus différents:

* Le menu intitulé "Menu" avec les différentes rubriques générales du site
* Le menu "Connexion" qui prend le pseudo du joueur connecté et qui permet d'accéder au jeu, aux paramètres et de se déconnecter
* LE menu langue qui, comme son nom l'indique, permet de changer de langue
* Le menu disposition en bas de la page de jeu, qui permet de changer la disposition des différentes zones (historique, menus/grille du jeu, actions)

LE top serait naturellement que je n'aie rien à calculer et que ça apparaisse d'office au bon endroit.
C'est sûrement faisable quand on est bon en CSS, mais forcément, dans ma situation particulière, j'ai beaucoup plus de facilité en JavaScript.

Bonjour.

Je m'ajoute dans la conversation. Je suis en train de faire une nouvelle version de mon site internet, et j'ai eu le même problème de taille de caractères.

Un problème majeur pour moi a d'abord été que la fonction DEVICE-WIDTH est obsolète et VA DISPARAITRE des navigateurs d'ici quelques temps.

Lire :
https://developer.mozilla.org/en-US/docs/Web/CSS/@media/device-width

Donc, tout change dans la façon de voir les choses (et de prévoir des tailles qui s'adaptent selon les écrans). Mon ancien site utilise cette technique du device-width mais je crains que ça fasse tout détraquer une fois que les navigateurs auront supprimé la fonction.

Apparemment, d'ailleurs, ça fait des années qu'il n'est plus conseillé d'utiliser la méthode du device-width car il y avait déjà des résultats hallucinants selon l'appareil électronique utilisé.

Je ne sais pas quoi penser de cette obsolescence indiquée, car cette méthode était vraiment très utile.
Modifié par AlexInSi (22 Apr 2024 - 15:19)

Bonjour,

@AlexInSi:

Il est déconseillé de l'utiliser dans les media query, mais rien ne dit qu'il ne faut plus non plus l'utiliser dans la balise meta viewport.
Pour moi en tout cas, c'est pas très clair si c'est la même chose ou pas du tout.

Autre chose, si on est un peu pragmatique: si ça fait plusieurs années que c'est indiqué comme déprécié mais que c'est toujours supporté, il y a peut-être des chances que ce soit finalement jamais réellement retiré.
Si c'est toujours utilisé parce qu'il n'y a pas d'autre alternative pratique, ils n'ont pas trop d'intérêt à le supprimer et ainsi rendre des milliers de sites inutilisables.
Donc il y a certainement encore le temps de voir venir avant que ça ne fonctionne plus...

Ce qui serait intéressant, c'est de savoir pourquoi ça a été déclaré obsolète. Quelles sont les raisons profondes ? Pourquoi c'est mal de l'utiliser ?
A partir de là on peut comprendre quel est le risque et décider de l'assumer ou pas.


Au passage, un petit coucou à <font>, <center> et autres balises tirées tout droit des années 90 qui, étonnament, marchent toujours... attention ne me faites pas dire ce que je n'ai pas dit, je n'ai pas dit qu'il fallait continuer à les utiliser, car dans ce cas-là on connaît depuis longtemps de bien meilleures alternatives, meilleures en tout point.

@all:

Pendant qu'on parle de media query, je me suis rendu compte que ma CSS mobile.css n'était en fait jamais utilisé, et que c'était systématiquement desktop.css qui était prise en compte:

<link rel="stylesheet" media="only screen and (max-width: 40em)" href="/styles/mobile.css" />
<link rel="stylesheet" media="only screen and (min-width: 40.01em)" href="/styles/desktop.css" />

En réalité, après un test empyrique, même mon iPhone 12 mini a une taille de 64em, et ce n'est pas très différent de la taille trouvée sur mon PC portable (ça tourne aussi entre 60 et 70em).
Du coup comment on fait pour viser les petits écrans comme ceux des téléphones spécifiquement ?
Modifié par QuentinC (23 Apr 2024 - 06:31)

Bonsoir,

Vu que la discussion sur device-width est partie sur un autre topic, je marque celui-ci comme résolu.

Merci à tous pour votre aide.

QuentinC a écrit :
Vu que la discussion sur device-width est partie sur un autre topic, je marque celui-ci comme résolu.

Elle avait même démarrée sur ce topic