Pour ou contre les medias queries en CSS (vs Javascript) ?
Je trouve personnellement que l'emploie des media queries dans le CSS pose deux problèmes très gênants.
Et ces problèmes peuvent facilement être évités en se servant de Javascript pour "signaler" le respect ou le non respect des media queries qui nous intéressent.
Ex (classe "XXL" pour l'élément BODY):
Code:
1
2
3
4
5
6
7
8
|
window.matchMedia("all and (min-width: 30cm)").addListener(function(mq) {
if (mq.matches) {
document.body.className += " XXL ";
} else {
document.body.className = document.body.className.replace(" XXL ", "");
}
}); |
1. Le premier problème avec les media queries intra CSS est la redondance et/ou le regroupement "contre inuitif".
Par exemple si, avant usage des media queries, vous avez du CSS pour mettre en page des arbres d’éléments comme suit :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
|
SECTION.post {...}
SECTION.post H1 {...}
SECTION.post > DIV {...}
...
SECTION.contact {...}
SECTION.contact LABEL {...}
SECTION.contact > TABLE {...}
... |
Vous aboutiriez probablement lorsque les media queries seront rajouté à du CSS avec de la redondance (problème de maintenance) :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
SECTION.post {...}
SECTION.post H1 {...}
SECTION.post > DIV {...}
@media all and (min-width: 30cm) {
SECTION.post > DIV {...}
}
...
SECTION.contact {...}
SECTION.contact LABEL {...}
SECTION.contact > TABLE {...}
@media all and (min-width: 30cm) { /* Question: est-je bien mis 30cm partout ?! */
SECTION.contact > TABLE {...}
}
... |
(*) LESS/SASS/... peuvent éliminer une partie de ce problème et un minificateur optimisé pour regrouper les déclarations @media identiques ensemble éliminera l'autre
et/ou à du CSS avec du regroupement "contre intuitif" (problème de lisibilité) :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
|
SECTION.post {...}
SECTION.post H1 {...}
SECTION.post > DIV {...}
...
SECTION.contact {...}
SECTION.contact LABEL {...}
SECTION.contact > TABLE {...}
...
@media all and (min-width: 30cm) {
/* Question: quelle était la mise en page de ces éléments là ?! */
SECTION.post > DIV {...}
SECTION.contact > TABLE {...}
} |
Ma conclusion
Il est beaucoup plus facile de pouvoir écrire (grâce à par ex. classe "XXL" pour l'élément BODY) :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
SECTION.post {...}
SECTION.post H1 {...}
SECTION.post > DIV {...}
BODY.XXL SECTION.post > DIV {...}
...
SECTION.contact {...}
SECTION.contact LABEL {...}
SECTION.contact > TABLE {...}
BODY.XXL SECTION.contact > TABLE {...}
... |
2. Le problème du rapport entre les mesures de taille et la résolution.
Si je considère qu'une largueur de 30cm pour un écran, correspond à un écran XXL (manifestement en comparaison avec un écran de smartphone ou de tablette), est-ce que les exemples du points 1 me permettent de réellement spécifier des règles pour ces écrans ?
Non, car dans ces exemples, je travaille avec des centimètre virtuels. Un écran de 8 cm de large avec une résolution de 384DPI y sera considéré comme XXL (de 32 cm pour être précis).
En fait vous devez tenir comme de la résolution (exprimée en DPI par exemple) dans les mesures que vous souhaitez employés.
Code:
1
2
3
4
5
6
7
8
9
|
@media all and (min-width: 30cm) and (max-resolution: 96DPI) /* Avec une résolution d'exactement 96DPI, ça fait 30 vrais centimètres */
, all and (min-width: 60cm) and (max-resolution: 192DPI) /* Avec une résolution d'exactement 192DPI, ça fait 30 vrais centimètres */
, all and (min-width: 90cm) and (max-resolution: 288DPI) /* Avec une résolution d'exactement 288DPI, ça fait 30 vrais centimètres */
, all and (min-width: 120cm) and (max-resolution: 384DPI) /* Avec une résolution d'exactement 384DPI, ça fait 30 vrais centimètres */
{
...
} |
Ici encore LESS/SASS pourraient vous venir en aide mais même là, le résultat reste lourd.
Dans le CSS final toutes ces combinaisons alourdiront le document tout en ne couvrant que les cas que vous aurez prévu (QUID du 480DPI, etc.)
Ma conclusion
Avec Javascript et quelques boucles vous automatiserez facilement toutes les combinaisons à faire.
(inconvénient) Ce qui peut rebuter un utilisateur à utiliser Javascript pour tout ça :
- La séparation des responsabilité. C'est en Javascript que vous mettez des mesures relatives à votre mise en page.
- La crainte du client qui a désactivé Javascript.
- Une connaissance personnelle insuffisante de javascript.
1. Un petit fichier .js à part, c'est peut-être bien une exception valable à la règle.
2. Est-ce qu'on parle du même gars ? Le gars qui n'a rien appris et tourne encore sur IE8 ? Si oui, laissez tomber les media queries, vos shim ne tourneront pas non plus.
3. Moteur de recherche et/ou apprentissage sont les clés du succès.
