web-dev-qa-db-fra.com

Passer aux requêtes multimédias basées sur Em

Maintenant que le WebKit bug de zoom de page a été corrigé , quelles sont les principales raisons d'utiliser les requêtes multimédias basées sur em plutôt que les requêtes multimédias basées sur pixels?

Prime

J'ajoute une prime à ma question parce que tant de proéminents CSS frameworksetwebdéveloppeurs utiliser des requêtes multimédias basées sur des em que je suis convaincu qu'il doit y avoir de bonnes raisons de le faire.

Le seul avantage dont je suis conscient est que si un utilisateur modifie la taille de police par défaut dans son navigateur, le contenu presser d'une manière similaire au problème résolu par le correctif de zoom de page . Existe-t-il des données pour montrer que les gens modifient réellement la taille par défaut plutôt que de zoomer?

Remarque

Pour rendre ma question plus ciblée, j'ai supprimé deux éléments périphériques. Le message d'origine ajoutera de la perspective au grand --- de @ nwalton réponse , qui répondait aux trois points sur lesquels j'ai posé des questions.

cssresponsive-designmedia-queries
62
cantera

  1. Dans les navigateurs modernes, il ne devrait pas y avoir de différence entre les requêtes multimédias basées sur les em et les pixels si le navigateur gère correctement le zoom. En fait, j'ai eu des problèmes avec les requêtes multimédias basées sur les em dans un projet, car dans l'une des requêtes multimédias, la taille de la police de base a changé, puis toutes les autres requêtes multimédias ont été gâchées. C'est peut-être juste une erreur stupide, mais vous voyez l'idée. J'irais avec des pixels.  Voir la mise à jour ci-dessous. Bien que le zoom n'ait pas d'effet sur les navigateurs modernes, la taille de police de base le fait toujours.

  2. Le plus gros problème que je vois que vous pourriez rencontrer avec la technique 62,5% et rem est si vous rencontrez des navigateurs qui ne le comprennent pas. Si cela vous inquiète, vous pouvez ajouter une solution de rechange pour les navigateurs moins performants et définir rem pour les navigateurs modernes.

    html { font-size: 62.5%; }
body { font-size: 14px; font-size: 1.4rem; }
h1   { font-size: 24px; font-size: 2.4rem; }

  3. S'il y a une différence dans la rapidité avec laquelle les navigateurs traitent px vs em, ce n'est pas visible. Les navigateurs calculent le CSS vraiment, vraiment très vite (beaucoup plus vite que JS). Il ne vaut donc probablement pas la peine de s'inquiéter.

Avantages, inconvénients et utilisations des mesures

px

J'ai utilisé px pour les requêtes multimédias dans le passé parce qu'elles sont très fiables et, comme vous le dites, elles zooment très bien. Mise à jour: Cependant, si un utilisateur modifie sa feuille de style par défaut, vos requêtes média seront désactivées.

  • Indépendant de la cascade CSS
  • Mesure principalement non relative (dépend uniquement de la façon dont le navigateur mesure les pixels de la police)
  • Zoomable dans tous les navigateurs modernes

em

Les Ems sont géniaux pour faire des grilles et des mesures flexibles. Par exemple, si une largeur de conteneur est spécifiée en ems, je peux redimensionner proportionnellement le conteneur et son contenu dans mes requêtes multimédias avec une seule déclaration.

  • Répond à la cascade CSS
  • Par rapport à la taille de la police du conteneur
  • Zoomable dans tous les navigateurs modernes

Dans cet exemple, le redimensionnement de la police redimensionne également son conteneur proportionnellement.

h1.title {
  font-size: 2em;
  width: 20em;
  background-color: #baff1e;
}

@media (min-width: 400px) {
  h1 {
    font-size: 2.5em
  }
}

rem

Je n'ai pas vraiment utilisé rem, mais je peux comprendre pourquoi beaucoup de gens l'aiment. Vous avez le pouvoir d'une unité relative, mais vous n'avez pas à faire face aux choses folles qui peuvent se produire lorsque vous lancez la cascade CSS.

Le dimensionnement des éléments en fonction de la taille de police de base du navigateur semble être la chose à faire aux normes Web, car vous autorisez alors les navigateurs dont la taille de police de base optimale peut ne pas être de 16 pixels. En pratique, cependant, cela fonctionne en quelque sorte dans l'autre sens. D'après ce que j'ai vu, les navigateurs utilisent 16px comme taille de police de base, car c'est ce à quoi tout le monde s'attend, et définissez la taille réelle de cette mesure CSS de manière décente dans le navigateur.

  • Indépendant de la cascade CSS
  • Par rapport à la taille de police de base
  • Zoomable dans tous les navigateurs modernes

Une note sur la technique à 62,5%

Cela existe depuis un certain temps, et pour l'instant je ne connais aucune raison de ne pas l'utiliser. Il y avait un article de 2007 sur A List Apart où ils ont fait quelques tests et ont constaté que les tailles de police s'affichaient de manière plus fiable sur les navigateurs lorsque la police de base était déclarée à 100% et le texte a été dimensionné en em. Mais je serais surpris si l'une des contraintes de navigateur répertoriées était vraiment pertinente. J'ai toujours du mal à définir la taille de la police de base sur 10px, mais ce n'est probablement qu'une préférence personnelle.

Mise à jour

Après avoir fait quelques tests, j'inverse ma pratique d'utilisation des pixels pour les requêtes multimédias. Je recommande maintenant em:

  1. Les utilisateurs modifient leur taille de police de base. Un thread sur le réseau de support de Mozilla, "Comment puis-je augmenter la taille de police par défaut du navigateur?" a plus de 5 000 vues. Et n fil similaire a plus de 15 000. ne autre étude a trouvé un pourcentage d'utilisateurs (0,3%) qui avaient une taille de police par défaut inférieure ou supérieure à "moyenne". La fréquence à laquelle les utilisateurs changent, cela ne semble pas pertinent (voir ne précédente réponse SO) ). Si certaines personnes le font, cela vaut probablement la peine de les soutenir.

  2. Les Ems sont probablement plus à l'épreuve du temps. Ils fonctionneront pour tout appareil dont la taille de police par défaut optimale est pas 16px (ainsi que ceux qui le sont).

  3. Ce qui m'a le plus convaincu, c'est de le voir en action. Voici une démonstration du codepen. Notez que le zoom du navigateur ne fait probablement aucune différence (j'ai testé dans Chrome). Mais si vous allez réellement dans les paramètres de votre navigateur et changez la taille de police par défaut de "moyenne" à autre chose, les largeurs sont bien différentes. À mon avis, c'est inacceptable.

56
nwalton

Je n'ai pas encore trouvé de données spécifiques sur les utilisateurs qui modifient la taille de leur police de base, mais j'ai vérifié quelques sites Web conçus par des personnes qui devraient savoir ce qu'ils font. Je cherchais spécifiquement s'ils utilisaient px ou em pour spécifier leurs requêtes multimédias. Bien que cela ne réponde pas entièrement à la question, je pense que cela ajoute une dimension intéressante à la discussion.

Quelques acteurs majeurs

Cette liste n'est en aucun cas exhaustive ou mesurée de quelque manière que ce soit, sauf qu'elle comprend les noms d'individus ou de groupes qui me semblent être à la pointe du développement Web, ou qui ont contribué d'une manière ou d'une autre à la pratique du design réactif.

Une chose intéressante à noter est que la dernière entrée, Nicholas Gallagher, est la personne qui a ajouté la ligne de requête multimédia au HTML5 Boilerplate CSS . Dans ce code, il utilise em, bien que sur son site personnel les requêtes média soient définies dans px. J'ai cherché une discussion sur cet engagement, mais je n'en ai trouvé aucun.

Quelques-uns de leurs sites

Encore une fois, une liste dispersée, mais elle contient quelques sites que je considère intéressants. La plupart d'entre eux ont été construits en totalité ou en partie par des personnes de la liste précédente.

Une note intéressante avec HTML5 Boilerplate, le CSS du projet principal utilise em tandis que la version mobile du projet utilise px.

Méga-sites

Il était en fait vraiment surprenant de constater que peu de les sites les plus populaires sur le Web ont des requêtes médiatiques. Voici quelques-uns qui utilisent des requêtes multimédias.

Conclusion

Non concluant.

Il semble que les gens utilisent les deux méthodes avec succès, et il ne semble pas y avoir d'accord sur les meilleures pratiques.

J'ai en quelque sorte l'impression que certains des concepteurs les plus progressistes se déplacent vers em, mais je n'ai pas de données pour cela autre que cela "semble" que cela pourrait être le cas. Il pourrait également être vrai que certains des sites répertoriés ci-dessus sont plus anciens que d'autres et n'ont pas été mis à jour depuis que les gens ont commencé à passer aux requêtes multimédias basées sur les em. Il est difficile d'obtenir vraiment suffisamment de données pour tirer une bonne conclusion à cet égard.

Cependant, le fait que certains des plus grands sites du monde utilisent px me dit que cette approche doit pourrait encore être techniquement solide. S'il y avait eu des problèmes majeurs avec cela, je suis sûr que les plus gros sites en auraient entendu parler par leurs utilisateurs ou par leurs tests, et seraient passés à quelque chose de plus techniquement viable pour servir leur public.

31
nwalton

Il y a une raison principale pour laquelle utiliser les requêtes multimédias basées sur EM et c'est
respecter le paramètre de taille de police des utilisateurs (de base)
sans casser votre mise en page!

Vous ne devriez vraiment jamais définir les tailles de police en pixels (ni la largeur/hauteur de vos éléments) !!!
Laissez l'utilisateur décider de la taille de police qu'il souhaite consulter sur votre site.

C'est donc une question d'accessibilité.

Si vous utilisez des valeurs en pixels, vous devez assumer une certaine taille de police (de base), qui est "normalement" 16 pixels. Mais pas toujours, et c'est le point. Donc, si un utilisateur a choisi une taille de police plus petite ou plus grande (de base), votre mise en page s'effondrera.

Ou sur les systèmes de bureau, si l'utilisateur utilise la fonction de zoom du navigateur, il obtiendra une barre de défilement horizontale (ce qui n'est généralement pas souhaité).

Tout cela peut être évité en utilisant des unités relatives comme EMs. Et ils n'ont aucun inconvénient.

Il convient également de mentionner qu'en réalité, le paramètre de taille de police de base, ainsi que la fonctionnalité de zoom des navigateurs mobiles (sur les appareils tactiles comme les tablettes et les téléphones portables) fonctionnent différemment de leurs homologues de bureau. Pour les versions de navigateur mobile, le paramètre de taille de police ne joue pas un rôle aussi important que pour les navigateurs de bureau. Mais encore une fois, vous ne faites rien de mal en utilisant des requêtes multimédias basées sur EM. Et à mon humble avis, c'est aussi "à l'épreuve du futur" que possible.

Et vous pouvez également utiliser facilement la "technique des 62,5%".
N'oubliez pas que la nouvelle taille de police "root em" dépend de la taille de police de l'élément racine (de la page) et qu'il s'agit de l'élément html, et non de l'élément body.

Utilisez la "technique 62,5%" sans briser l'accessibilité:

html {
    font-size: 62.5%; /* with the standard base font size of 16px this will be equal to 10px */
}

body {
    font-size: 160%; /* 160% of 10px ~ 16px, understood by all browsers */
    font-size: 1.6rem; /* 1.6 * 10px ~ 16px, understood by all major browsers and IE9+ */
}

Vous pouvez donc utiliser rem comme si c'était là où px (divisé par 10),
mais sans nuire aux paramètres de l'utilisateur!

Quelle que soit la taille de police de base choisie par l'utilisateur, le rapport de police restera toujours intact.
Et aussi votre mise en page! ;-)

Une dernière remarque:
Utilisez toujours min|max-width requêtes multimédias et jamais device-width! La raison en bref est que vous mettez en page et définissez vos points d'arrêt en fonction de votre contenu et jamais en fonction de la résolution des appareils!

Ainsi, en utilisant des unités relatives (comme EMs) pour votre mise en page et vos tailles de police, votre design est vraiment "réactif". En utilisant des unités absolues (comme PX), ce n'est pas le cas!

21
Netsurfer