Je ne pense pas abandonner son support malgré tout.
1/ Ce serait privé les autres utilisateurs (majoritaires) du respect de leurs préférences
2/ Le contenu reste accessible malgré tout même si dégradé par rapport à ce qui est prévu
3/ On fait des sites qui existeront encore demain. Ce bug sera peut être (pas?) résolu à l'avenir. ]]> text/html https://www.nicolas-hoffmann.net/source/1693-Les-media-queries-et-les-preferences-utilisateurs.html#comment158787 David Thu, 21 Dec 2017 10:23:54 +0100

Oui ton explication est très claire! J'avais également une optique relativement similaire en tête (essayer d'harmoniser au maximum les breakpoints principalement par grand type de layouts/contenus d'un site + placer des breakpoints sur certains composants centraux).

Dans tous les cas un grand merci pour ton partage d'expérience et pour le temps que tu prends pour nous répondre et nous faire des articles de qualité ;-) ]]> text/html https://www.nicolas-hoffmann.net/source/1693-Les-media-queries-et-les-preferences-utilisateurs.html#comment158758 Loïc Sun, 19 Jun 2016 12:57:46 +0000

En pratique, je procède un peu différemment : pour éviter que les CSS n'enflent trop avec 10000 breakpoints, j'essaie d'harmoniser. Si un contenu nécessite un breakpoint à 800px et un autre à 780, je vais essayer de voir pour les mettre sur le même breakpoint (si c'est possible bien sûr).

Après, je pars plutôt sur le côté responsive non pas des pages, mais plutôt des composants : responsiver la navigation, tel module, etc.

En concevant de manière suffisamment élastique (vivent les unités relatives comme les %) et robuste (en faisant des modules qui se stretchent bien), on arrive à limiter le nombre de breakpoints.

Après, avec un peu de pratique, tu arrives à voir rapidement où vont être tes breakpoints majeurs (en général, apparition du burger icon, quand la nav desktop n'est plus possible, etc. même si ce n'est pas forcément une règle absolue). Sur des templates plus compliqués comme celui que je suis en train de faire, j'ai 5 breakpoints majeurs au lieu des 2 ou 3 habituels.

Avant, j'avais tendance à fixer les breakpoints au dernier moment avant que les contenus ne soient étriqués, maintenant, j'aurais tendance à prévoir un peu de marge, j'aime bien que les contenus respirent, et ça tolère plus facilement des changements imprévus.

Voilà, j'espère que cela répond à ta question ? Sinon, n'hésite pas. ]]> text/html https://www.nicolas-hoffmann.net/source/1693-Les-media-queries-et-les-preferences-utilisateurs.html#comment158754 Nico Fri, 03 Jun 2016 19:59:27 +0000

Comme tu l'indiques, "travailler le responsive uniquement d’après les contenus" est désormais une bonne pratique reconnue.
J'ai en revanche une petite question qui me traîne dans la tête depuis un bon moment déjà...

La réalisation d'un site complet comporte très souvent différentes pages qui peuvent avoir un layout complètement différent : une page au format sidebar 1/3 + contenu 2/3, une page avec 2 colonnes égales, une page "full frame", etc.

Si l'on travaille le responsive des pages d'après leurs contenus, est-ce qu'il ne serait pas logique que chaque page possède ses propres breakpoints pour qu'elles puissent s'afficher parfaitement en toutes circonstances ?

A l'heure actuelle je n'ai pas trouvé de ressources qui évoquaient cette problématique car j'ai l'impression que tout le monde définit ses points de rupture de manière globale pour un site. Idem pour les frameworks UI: quand on utilise une grille CSS ou un framework comme Bootstrap & co, les breakpoints sont globaux pour l'ensemble du site.

J'aimerais vraiment avoir ton avis sur ce sujet ;-) ]]> text/html https://www.nicolas-hoffmann.net/source/1693-Les-media-queries-et-les-preferences-utilisateurs.html#comment158753 Loïc Fri, 03 Jun 2016 12:22:58 +0000