La relation REM vers PX : comment écrire des requêtes multimédias plus accessibles

Nous sommes des développeurs. Nous souhaitons développer les mises en page les plus réactives. Nous souhaitons nous adapter à différents appareils, résolutions et paramètres utilisateur. Nous souhaitons utiliser des unités cohérentes dans toutes les feuilles de style. Nous voulons faire le moins de mathématiques possible.

Quand voulons-nous cela ? MAINTENANT !
Que devons-nous savoir ? Plein de trucs !
Comment faisons-nous cela ? Avec une fonction SASS personnalisée !

En utilisant une fonction SASS, nous pouvons accueillir davantage d'utilisateurs en comprenant et en tenant compte des paramètres de leur système et de leur navigateur. J'expliquerai comment les valeurs rem sont liées aux valeurs de pixels et ce qui pourrait affecter la relation entre elles. 1rem commence presque toujours par 16px, mais il existe des moyens pour un utilisateur de modifier cela. Cette fonction SASS que nous écrirons plus tard est très utile car elle peut s'appliquer à un projet plus vaste et peut être introduite progressivement dans vos projets existants.

Arrière-plan

Ce qui m'a amené à m'intéresser à ce sujet, c'est l'article There's No Such Thing as a Desktop Screen, de Hajime Yamasaki Vukelic, dans lequel son point de vue sur le responsive design est que « la réactivité ne consiste pas à un simple ensemble de largeurs d'écran arbitraires.... la réactivité est une question de robustesse : jusqu'à quel point pouvez-vous étirer ou presser la page avant qu'elle ne commence à s'effondrer ». Hajime raconte comment son père navigue sur le Web à une échelle essentiellement régulière de 400 %. Bien que cela puisse sembler un cas limite, il est important de connaître les différentes manières dont un utilisateur peut redimensionner son affichage et comment les styles que nous écrivons sont affectés par ces modifications des paramètres.

Affichage mis à l'échelle

Commençons le plus petit possible en comprenant exactement ce qu'est un pixel. En ce qui concerne un développeur, il existe deux types de pixels : il y a les pixels de l'appareil qui sont la quantité de points de lumière sur un écran donné et il y a les pixels CSS qui sont une unité de mesure. Les pixels de l'appareil ne sont généralement pas égaux aux pixels CSS. Il est important de comprendre la différence entre les deux afin de pouvoir déterminer quels paramètres affectent chaque valeur.

Il existe plusieurs façons pour un utilisateur de modifier la taille du contenu sur son écran, comme le père de Hajime. Les façons les plus courantes dont un utilisateur peut faire évoluer son affichage :

• changer la résolution d'affichage (paramètre système)
• zoomer sur l'onglet du navigateur (sur Mac en appuyant sur ⌘ et +, windows Ctrl et +)
• augmenter la taille de la police dans les paramètres du navigateur.

Les première et deuxième options, modifier la résolution d'affichage et zoomer dans le navigateur, font essentiellement la même chose. Les deux méthodes mettront à l'échelle les pixels CSS afin que chaque pixel CSS occupe plus de pixels sur l'appareil. Dans ce cas, notre mise en page évolue proportionnellement. 1rem sera toujours égal à 16px mais chaque pixel CSS occupe plus de pixels sur l'appareil. Pour tester cela, vous pouvez zoomer sur l'onglet du navigateur jusqu'à déclencher la mise en page « mobile ». Ce paramètre est rapide à tester et ne devrait généralement pas poser trop de problèmes.

Changer la taille de la police du navigateur entraînera le plus de changements. Par défaut, le paramètre du navigateur est « moyen », ce qui dans Chrome signifie que 1rem est de 16 px. Lorsque l'utilisateur augmente la taille de la police, la valeur de 1rem augmentera mais aucune autre valeur ne sera mise à l'échelle. 1rem équivaudra à plus de pixels CSS et occupera donc plus de pixels de l'appareil. Sur Chrome, avec la taille de police définie sur « très grande », 1rem équivaudra à 24px. La taille des pixels CSS reste la même, c'est la taille de la police racine qui a changé. Toute valeur faisant référence à la taille de police racine sera affectée.

Dans votre code, si vous avez un mélange de valeurs de pixel et de rem, vous pourriez commencer à avoir des problèmes de mise en page car les valeurs de rem évolueront mais les valeurs de pixel resteront les mêmes. L'image ci-dessus montre comment un exemple simple de la façon dont la mise en page peut changer radicalement lorsque le texte est défini en valeurs rem tandis que la largeur maximale, la largeur de colonne et les remplissages sont définis avec des valeurs de pixels. Une mise en page réactive doit être adaptée à la taille de la police racine.

Le problème avec les requêtes multimédias

C'est généralement ainsi que nous rédigeons une requête média :

@media (min-width: 1000px) {
    ...declarations here
}

Comme nous essayons d'être réactifs et adaptables à tous les paramètres des utilisateurs, nous souhaitons utiliser des unités relatives partout où nous le pouvons. Utilisons une valeur rem au lieu de pixels dans la requête multimédia :

@media (min-width: 62.5rem) {
    ...declarations here
}

Avec les paramètres par défaut du navigateur, 1000px équivaudra à 62,5rem
1rem = 16px
1000px / 16px/rem = 62,5rem
Cela ressemble à des calculs que je dois faire chaque fois que je veux écrire une unité relative. Nous avons dit dès le début que nous ne voulions pas avoir à faire de mathématiques.

Il existe une solution courante que nous avons tous vue : 1rem = 10px. Cela se fait généralement lors de la configuration du passe-partout d’un projet. Vous écrasez la taille de la police racine sur l'élément racine en ciblant le sélecteur html :

html {
    font-size: 62.5% 
    // this is math 
    // but it only needs to be done once for the whole project 
    // so I'll let it slide
}

Now any time we want to convert a pixel value from the design to a rem value in our code we just have to carry the decimal one place.
1rem = 10px
To get a value of 1000px, we use 100rem. This still involves math but is fairly minor.

Now, when using a rem value, we can safely assume that 1rem will be 10px.
Right?
Yes?
Example?
No need. We know it is true. We have used rem for widths, heights, paddings, margins, translates or any other declaration without any issue. But…will there be any issue using it in the condition for a media query?

@media (min-width: 100rem) {
    // does is trigger at 1000px as expected?
    ...declarations here
}

Open the example in a new window and play with the width of the viewport. When the “desktop” media query triggers then the background will turn blue.

What is happening?

The values for a media query are calculated before any other rules are set, so the ruleset we applied to the html element in the start of our project will not be applied in the condition of the media query. According to this media query, 1rem is still equal to 16px. We expected 100rem to be 1000px but it ended up being 1600px.

If you change the browser font size to “very large” and refresh the example, you will notice that 1rem = 15px and the 100rem media query won’t trigger until 2400px. If your monitor isn’t wide enough to see that change happen, zoom out on the browser with ⌘/Ctrl and + .

The condition for the media query is not scaling consistently with the browser’s desired font size.

• Font size “Medium”:
  • 1rem = 10px
  • Media query: 100rem = 1600px
  • rem to px ratio: 0.0625
• Font size “Very Large”:
  • 1rem = 15px
  • Media query: 100rem = 2400px
  • rem to px ratio: 0.0416666667

For content and layouts to scale consistently, we need the rem to px ratio to always remain the same.

REMPX()

This has taken a long time to get to even suggesting a solution to a problem that we maybe didn’t know we had.

Let’s create a custom SASS function that will allow us to write our code in pixel values and be rendered as rem values. I came across this function on a legacy project at work but I believe it was heavily inspired by this quick article: Convert pixel values to rem, Sass style, by Bhargav Shah. Since this article was written, CSS introduced its own rem() function which calculates the remainder of a fraction so instead we’ll name our function rempx().

$html-font-size: 16px;

@function stripUnit($value) {
    @return $value / ($value * 0 + 1);
}

@function rempx($pxValue) {
    @return #{stripUnit($pxValue) / stripUnit($html-font-size)}rem;
}

//implementation:
.image {
  height: rempx(300px);
}

Open the example in a new window and play with the width of the viewport and change the browser font size (refresh the page after you update the font size).

Notice how after we change the browser font size to “very large” (after a page a refresh), the 1rem square becomes larger and you can see that 1rem is equal to 24px.

When used in the condition of a media query, a rempx value will scale accordingly with the browsers font size. With the font size set to “very large”, the desktop layout rempx(1000px) will trigger at the viewport width of 1500px. The scaling of the content and layout behave the same way as when we zoom in on the browser.

A huge benefit of writing all your units with the rempx() function is you can write pixel values from the designs and then it renders it as a rem value in the browser. This function is very easy to introduce to a project or include in the boilerplate of your future projects.

Wrapping up

This function can be written once and used everywhere.
We can take the pixel values from the design and generate a scalable rem value.
Our media query triggers relative to the root font size.
All our layout and content scales consistently.
No math necessary.
Better user experience across a wider range of user settings.
Better user existence overall.
Better developer existence overall.
This function improves our existence.

Further reading

There’s No Such Thing as a Desktop Screen Hajime Yamasaki Vukelic

Zoom, zoom, and zoom: the three types of browser (and CSS!) magnification, Miriam Suzanne

Convert pixel values to rem, Sass style, Bhargav Shah

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!