Ordre et nombre des media queries

vortex3 a écrit :
Bonjour,

Je suis en train de finaliser une nouvelle maquette, et je m'intéresse à l'optimisation de mes CSS.

1/ L'ordre de mes medias queries
Je les ai toutes écrites du plus grand au plus petit.
1366px ou plus
de 1024 à 1365px
de 800 à 1023px
etc...
Peut-on faire mieux (éxécution plus rapide) autrement ?

2/ Nombre de règles CSS par media queries
Est-il mieux de mettre 10 règles de CSS (c'est ce que je fais) derrière une seule media query ou faire 2 media queries avec 5 règles de CSS ?

3/ Nombre de points de rupture
Ouais, je suis vieux, de la génération pixel-perfect, et je n'aime pas ce qui est imprécis. J'ai créé ma maquette avec 5 points de rupture, mais sur certaines résolutions, il y a des marges qui ne sont pas jolies, alors je crois que je vais en rajouter 2 points de rupture supplémentaires. Mais cela ne gêne rien ni personne, n'est-ce pas ?

Mes questions sont assez génériques, j'espère alors que vos réponses pourront intéresser d'autres que moi. Merci à ceux qui répondront.

Bonjour,
Pour mes CSS, je privilégie les REM dans la définition horizontale de mes "blocs", en indiquant pour chacun d'eux la coordonnée mini et maxi pour éviter qu'un bloc plus large ne prenne le dessus sur un bloc inférieur par effet de cascade.
Pour le nombre de réglés à l'intérieur d'un bloc, l'idée est plutôt de chercher dans un premier temps tout ce qui est commun aux différents blocs et le placer à l'extérieur, dans la partie commune.
Si un bloc est de couleur X dans tous les cas, par exemple, il est inutile de déclarer cet attribut dans chaque niveau.
Pour le raisonnement "mobile first" qui prévaut aujourd'hui, je ne m'embarrasse pas de ce genre de considération. Pour un bloc donné, j'ai un contenu à afficher, point. C'est ce contenu qui doit apparaître avec un affichage propre à ce bloc. Que l'on commence par la résolution la plus élevée ou l'inverse importe peu si l'on considère chaque bloc vertical comme une entité à part entière. La définition de ce bloc se fait en se basant sur un écran "logique" sur lequel on aurait posé deux taquets verticaux.
Ces principes ne sont pas forcément ceux prescrits par la faculté, mais pour l'instant ils ne m'ont pas trop mal réussi, avec des feuilles CSS de taille maîtrisée...

Olivier C a écrit :
Bonjour,
En fait il fallait faire l'inverse. Pour comprendre le pourquoi renseignez-vous sur la philosophie mobile first.

OK, facile à changer.

Olivier C a écrit :
Je ne comprends pas cette limitation du nombre de règles par déclaration @media... Mais quoi qu'il en soit : plutôt que j'écrire mes média à la fin de ma feuille de style ou dans une feuille dédiée - comme il était d'usage au début de l'histoire du responsive - j'ajoute mes media queries pour chaque "module" si besoin. Un module étant pour moi une portion de code CSS définissant une seule chose pour mon style (un accordéon, un menu onglet). Cette manière de faire rend bien plus simple la maintenance du code... surtout quand on en est à plus de 3600 lignes (et encore : écrit en Stylus, donc un code bien plus compact que le Css).

Je pose cette question puisqu'habituellement, une règle CSS est courte. Souvent juste une ligne.
Alors qu'avec une media query, j'ouvre ({) et je ferme (}) 15 lignes plus bas.

Pour les modules, je comprend le raisonnement. J'ai 5 modules sur ma page (barre de nav, sidebar...) mais je préfère avoir une approche globale pour toute la page. Si j'avais 10 modules, je penserais peut-etre différemment.

Pour le reste, mes queries sont déjà en rem. J'ai mis des px pour cette discussion parce que ça m'a semblé plus parlant.

Pour le nombre de points de rupture, ce qui m'embete sont les images latérales dans mes articles. Sur un ordinateur, mes articles sont dans un module de 668 px de large, avec des images de 430 px parfois en float left ou en float right. Avec la marge, j'ai une colonne de texte de 216 px. Si l'écran diminue, je dois réduire l'image, ou la centrer. C'est ce que je fais, et c'est pas difficile, mais quand je redimensionne ma fenetre, je passe par des moments où le rendu n'est pas joli.

Merci pour ces réponses.

Bonjour,

l'approche mobile first va un peu plus loin que d'utiliser min- ou max-width dans ses MQ
C'est aussi à l'étape du design se demander ce que l'on va afficher comme contenus, fonctionnalités, services sur chaque "page". Et si on a la surface d'un mobile en tête, on ne fait pas les mêmes choix qu'en pensant à son 27" Retina !
Mais si on donne à un inté 3 PSD mobile, tablette, desktop bien figés en largeur là il n'y a pas réellement d'optimal. C'est pas super important, le temps sera mieux occupé à s'intéresser à d'autres sujets.

Nombre de règles dans une MQ, nombre de MQ différentes les navigateurs s'en balancent : ils analysent (parsent) les CSS au fur et à mesure de leur réception et prédigèrent ça dans un format tambouille interne (CSSOM si je dis pas de bêtises, OM = Object Model).
À moins d'atteindre les limites d'IE6 ou IE8 (souvenirs ), il faut des extrêmes en termes de nombre d'éléments HTML (2.000, 20.000 ?) ou de dizaines de milliers de propriétés CSS avant de discerner un ralentissement.
Une vilaine animation pas accélérée donnera un ressenti de lenteur bien plus fort AMHA.
Nombre de MQ : j'en ai compté 400 sur un site un peu connu intégré par une consoeur (elysee.fr par @Kreestal) et c'était tout à fait fluide. J'ai bien tiqué en découvrant des @media toutes les 20 lignes de CSS mais non c'était fluide. Et de mémoire Paul Irish avait testé ça et 400 ça laissait encore pas mal de marge.

Un sujet qui peut faire la différence, c'est la manière de faire cohabiter les instructions s'appliquant à un même élément dans différentes MQ : est-ce qu'en résolution intermédiaire, elles écrasent celles desktop encore actives (parce que définies en dehors de toute MQ) ou bien est-ce qu'on repart d'une page blanche ou presque puis même chose en mobile.
Devoir redéfinir 3 fois la même chose c'est pas efficace mais devoir écraser systématiquement ça ne l'est pas non plus. Mais séparer la moitié des propriétés - communes - de la moitié de celles spécifiques, ça n'améliore pas la lisibilité et multiplie les occurences des mêmes sélecteurs (s'ils sont courts ça gêne pas trop)
Tout dépend des différences de layout, couleurs, positionnement, effets de survol de chaque site, des habitudes de travail, etc

Ca dépend quand même avec quoi on surfe.
Je fais encore des tests avec un ordinateur de 2008, avec Mozilla à jour, je ne peux plus consulter lefigaro.fr avec, ça bugue sans arrêt.
Et sur mon ordi de travail, de 2014 (oui, je vais changer bientôt), je tombe régulièrement sur des sites qui sont très lents à l'affichage, c'est ce que je veux éviter. Mais j'ai bien vu sur des gros sites américains, des fichiers CSS de 350 ko. Il faut penser que je suis un petit webmaster hébergé en mutualisé. Alors je dois rechercher des solutions légères, OK avec mon hébergement, et OK avec mes lecteurs qui peuvent être pauvres et avoir des bécanes pourries.

Bonjour !

vortex3 a écrit :
Ca dépend quand même avec quoi on surfe.
Je fais encore des tests avec un ordinateur de 2008, avec Mozilla à jour, je ne peux plus consulter lefigaro.fr avec, ça bugue sans arrêt.

Vous m'étonnez, j'ai un vieil ordinateur avec Mozilla à jour et le figaro.fr, ça va...
D'un autre côté, il est vrai que j'utilise NoScript avec Firefox pour naviguer... Quand j'ai l'impression de manquer quelque chose, j'enlève des restrictions.

vortex3 a écrit :
... OK avec mes lecteurs qui peuvent être pauvres et avoir des bécanes pourries.

C'est vrai que je ne suis pas bien riche mais ma bécane n'est pas pourrie, elle est vieille...