Bonjour, je m'addresse à vous car je crée un site dit 'responsive' (me semble-t-il) et j'ai remarqué quelque chose d'étrange sur https://mediag.com/blog/popular-screen-resolutions-designing-for-all/. En effet, ils disent que le viewport d'un iPhone 5 (par exemple) est 320 x 568. Lorsque je met @media screen and (min-width: 320px) dans mon CSS, tout va bien. Cependant, nous pouvons aussi constaté que le viewport d'un Samsung Galaxy Note 9 est 360 x 740. C'est 4x moins sa taille en px, cotrairement à l'iphone, dont le viewport est seulement 2x plus petit que sa taille en px. Je voudrais donc avoir une petite explication (même si je pense que c'est un truc avec la résolution) et je voudrais également savoir ce que je dois mettre dans mon css après le @media.
Tu m'avais déjà répondu quelque chose de similaire sur un sujet que j'ai posté il y a seulement quelque jours, et je ne comprend pas trop cette réponse. J'ai plus ou moins suivi cette vidéo: https://www.youtube.com/watch?v=kbLfWKGVsMQ. Il nous explique que nous devrions créer un CSS pour la plus petite résolution possible puis de faire pour chaque taille supérieure au fur et à mesure. Je trouve que c'est une bonne méthode, donc je la reproduis. Pourrais-tu m'expliquer ton point-de-vue avec plus de précision? Et quelle méthode utiliserais-tu?
EDIT:
Pour les personnes qui tomberaient ici pour trouver une réponse, je vous renvoie à ce cours gratuit d'Udactity. Il est selon moi complet.
En clair, tu ne peux pas avoir de contrôle sur la taille du viewport de tes utilisateurs. Il y a trop de variables possibles, entre toutes les tailles de smartphones, tablettes, PC existantes, avec la possibilité ou non que l'utilisateur n'ait pas son navigateur en plein écran… C'est peine perdue.
Donc ce qui compte, c'est ton design : si à partir de telle taille, l'affichage n'est plus bon, c'est qu'il faut changer à cette taille là.
Si tu réduis la taille, tu vas voir que les changements se produisent non pas à des tailles spécifiques, mais simplement au moment où, si on réduit davantage, ça ne tient plus dans la fenêtre ou ce n'est plus assez lisible. C'est comme ça que sont définis mes breakpoints, pas en fonction de tailles supposées standards.
Du reste, la philosophie du mobile-first est, pour moi, mal utilisée. On parle souvent de "coder d'abord pour mobile", mais le coeur de l'idée, c'est de DESIGNER d'abord pour mobile. Parce qu'effectivement, si on réfléchit l'affichage mobile à la fin, on se retrouve à essayer de faire tenir trop d'information dans un espace toujours plus petit. Alors que l'inverse marche beaucoup mieux.
Par contre, appliquer ça au code, c'est déjà plus problématique. L'affichage desktop est (très généralement) plus complexe sur desktop que sur mobile. Or, c'est beaucoup plus facile (et souvent plus efficace) de simplifier un markup complexe, que de complexifier un markup de simple.
Si on commence par coder ça pour le mobile : https://jsfiddle.net/tebd1m73/ c'est super simple à faire. Sauf que si derrière on veut ça pour du desktop : https://jsfiddle.net/tebd1m73/1/ hé bien il faut revenir modifier tout le html/css qu'on avait fait pour le mobile, parce qu'il faut le complexifier.
Alors qu'en faisant directement la version complexe, il aurait suffit d'ajouter quelques règles de CSS et rien de plus, sans avoir à revenir toucher au html. C'est un exemple simple et le code est loin d'être optimisé, mais c'est pour montrer le problème.
Du reste, dans le métier on se retrouve souvent avec des contraintes techniques de rétrocompatibilité (clients sous d'anciennes versions de navigateurs) ; or, ces problèmes apparaissent bien plus souvent sur desktop que mobile, parce que le patron renouvelle volontiers plus son iPhone que les PC de sa boite. Et si on a commencé à coder de façon "moderne" pour mobile (flexbox, grid, etc) et qu'on se retrouve ensuite à essayer de trouver des polyfills et des fallbacks pour que ça marche ailleurs, on se prend la tête pour rien.
Après, note bien que je fais une généralité, parfois l'affichage est très simple dans les deux cas.
- Edité par EmmanuelBeziat 12 avril 2019 à 13:12:07
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
En clair, tu ne peux pas avoir de contrôle sur la taille du viewport de tes utilisateurs. Il y a trop de variables possibles, entre toutes les tailles de smartphones, tablettes, PC existantes, avec la possibilité ou non que l'utilisateur n'ait pas son navigateur en plein écran… C'est peine perdue.
Donc ce qui compte, c'est ton design : si à partir de telle taille, l'affichage n'est plus bon, c'est qu'il faut changer à cette taille là.
Si tu réduis la taille, tu vas voir que les changements se produisent non pas à des tailles spécifiques, mais simplement au moment où, si on réduit davantage, ça ne tient plus dans la fenêtre ou ce n'est plus assez lisible. C'est comme ça que sont définis mes breakpoints, pas en fonction de tailles supposées standards.
Du reste, la philosophie du mobile-first est, pour moi, mal utilisée. On parle souvent de "coder d'abord pour mobile", mais le coeur de l'idée, c'est de DESIGNER d'abord pour mobile. Parce qu'effectivement, si on réfléchit l'affichage mobile à la fin, on se retrouve à essayer de faire tenir trop d'information dans un espace toujours plus petit. Alors que l'inverse marche beaucoup mieux.
Par contre, appliquer ça au code, c'est déjà plus problématique. L'affichage desktop est (très généralement) plus complexe sur desktop que sur mobile. Or, c'est beaucoup plus facile (et souvent plus efficace) de simplifier un markup complexe, que de complexifier un markup de simple.
Si on commence par coder ça pour le mobile : https://jsfiddle.net/tebd1m73/ c'est super simple à faire. Sauf que si derrière on veut ça pour du desktop : https://jsfiddle.net/tebd1m73/1/ hé bien il faut revenir modifier tout le html/css qu'on avait fait pour le mobile, parce qu'il faut le complexifier.
Alors qu'en faisant directement la version complexe, il aurait suffit d'ajouter quelques règles de CSS et rien de plus, sans avoir à revenir toucher au html. C'est un exemple simple et le code est loin d'être optimisé, mais c'est pour montrer le problème.
Du reste, dans le métier on se retrouve souvent avec des contraintes techniques de rétrocompatibilité (clients sous d'anciennes versions de navigateurs) ; or, ces problèmes apparaissent bien plus souvent sur desktop que mobile, parce que le patron renouvelle volontiers plus son iPhone que les PC de sa boite. Et si on a commencé à coder de façon "moderne" pour mobile (flexbox, grid, etc) et qu'on se retrouve ensuite à essayer de trouver des polyfills et des fallbacks pour que ça marche ailleurs, on se prend la tête pour rien.
Après, note bien que je fais une généralité, parfois l'affichage est très simple dans les deux cas.
- Edité par rhooManu il y a environ 1 heure
Je comprends désormais. Merci du temps que tu m'as accordé
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !
Il n'y a pas de mauvais navigateur, il n'y a que du mauvais code !