Forem: Riley McMaster

The REM to PX relation: how to write more accessible media queries

Riley McMaster — Mon, 26 Aug 2024 15:45:29 +0000

We are developers. We want to develop the most responsive layouts. We want to accommodate different devices, resolutions and user settings. We want to use consistent units across all stylesheets. We want to do as little math as possible.

When do we want this? NOW!
What do we need to know? Lots of stuff!
How do we do this? With a custom SASS function!

By using a SASS function, we can accommodate more users by understanding and accounting for their system and browser-level settings. I will go over how rem values relate to pixel values and what might affect the relation between them. 1rem almost always starts off as 16px but there are ways a user can change that. This SASS function we’ll write later is very helpful because it can apply to a larger project and it can be introduced incrementally into your existing projects.

Background

What got me looking into this topic was the article There’s No Such Thing as a Desktop Screen, Hajime Yamasaki Vukelic, where his take on responsive design is that “responsiveness is not about a simple set of arbitrary screen widths.... responsiveness is about robustness: how much can you stretch or squeeze the page before it starts falling apart”. Hajime talks about how his father is browsing the web at essentially 400% regular scale. While this may seem like an edge case, it’s important to know the different ways a user may scale their display and how the styles we’re writing are affected by these changes in settings.

Scaled display

Let’s start as small as possible with understanding exactly what a pixel is. As far as a developer is concerned, there are two types of pixels: there are device pixels which are the amount of dots of light on a given screen and there are CSS pixels which are a unit of measurement. Device pixels usually do not equal CSS pixels. It’s important to understand the difference between the two so we can figure which settings affect each value.

There are several ways that a user can change the size of the content on their screen like Hajime’s father. The most common ways that a user could scale their display:

changing the display resolution (system setting)
zooming in on the browser tab (on Mac pressing ⌘ and +, windows Ctrl and +)
increasing the font size in the browser’s settings.

The first and second options, changing the display resolution and zooming in the browser, essentially do the same thing. Both methods will scale the CSS pixels so that each CSS pixel takes up more device pixels. In this case, our layout all scales proportionally. 1rem will still equal 16px but each CSS pixel takes up more device pixels. To test this, you can zoom in on the browser tab until you trigger the “mobile” layout. This setting is quick to test and generally shouldn’t cause much issue.

Changing the browser font size will cause the most change. By default, the browser’s setting is “medium” which in Chrome means 1rem is 16px. When the user increases the font size, the value of 1rem will increase but no other values will scale. 1rem will equal more CSS pixels and therefore take up more device pixels. On Chrome, with the font size set to “very large”, 1rem will equal 24px. The size of the CSS pixels remain the same, it is the root font size that has changed. Any value that references the root font size will be affected.

In your code, If you have a mix of pixel and rem values then you might start to have layout issues since the rem values will scale but the pixel values will stay the same. The image above shows how a simple example of how drastically the layout can change when the text is set in rem values while the max-width, column width and paddings are set with pixel values. A responsive layout should scale accordingly with the root font size.

The problem with media queries

This is generally how we write a media query:



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

Since we’re trying to be responsive and adaptable to all of the users’ settings, we want to use relative units all everywhere that we can. Let’s use a rem value instead of pixels in the media query:



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

With the default browser settings, 1000px will equal 62.5rem
1rem = 16px
1000px / 16px/rem = 62.5rem
That looks like math I have to do every time I want to write a relative unit. We said right at the start that we don’t want to have to do math.

There is a common fix that we’ve all seen where we make 1rem = 10px. This is generally done while setting up the boilerplate of a project. You overwrite the root font size on the root element by targeting the html selector:



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.

Why Did You Render - React & WordPress

Riley McMaster — Thu, 01 Feb 2024 19:46:30 +0000

When using React components in a WordPress project, I want to be able to diagnose what is causing components to re-render unnecessarily.

On a project recently, I ran into a problem where a React component was re-rendering unexpectedly. It was causing a quick layout shift and I was finding it really difficult to troubleshoot what was the cause. I came across the package why-did-you-render and the docs didn't have any tips on how to get it set up on a WordPress project. Below are the steps that my backend dev @davekellam and I took to get the package working with WordPress. We compile assets in our WordPress projects with Webpack and Babel.

We had to add a couple of dependencies and update the .babelrc file.

Dev dependencies to add to project:

@babel/preset-react
@welldone-software/why-did-you-render

.babelrc (add this line underneath @babel/preset-env):

{
  "presets": [
    "@babel/preset-env",
    "@babel/preset-react", // added this line
    "@wordpress/default" 
  ]
}

Since we don't have access to an .env file, we had to add this next line in order to access the environment via the global mainScript. This will prevent the script from loading in production if we have forgotten to remove the dependency.
scripts.php:

'environment' => esc_attr( wp_get_environment_type() ),

In the top level .js file, in this case mine is called frontend.js, (need global mainscript, the code below will be placed above the individual component imports):

/* global mainScript */
import React from 'react'
import whyDidYouRender from '@welldone-software/why-did-you-render';

if (mainScript.environment === 'local') {
    whyDidYouRender(React, {
        trackAllPureComponents: true,
    });
}

in a component file, with ComponentName replaced with the actual name of the component:

ComponentName.whyDidYouRender = true

WDYR wants to only display a message if a component re-renders with the same props. If your component isn't getting re-rendered unnecessarily then you might not get an error message and it might seem like the package is not doing anything. Using this next code snippet instead will display any prop changes that happen. The result is a bit verbose but a simple test to make sure that the package is working.

ComponentName.whyDidYouRender = { logOnDifferentValues: true }

I am still encountering an issue of loading the package in the production environment. The package's docs have an example for how to conditionally import the package but I was unable to find a workaround in WordPress. The best course of action I can find is to either remove the dependency before the site is deployed or install the package when debugging and remove it before merging your branch.

More information about the use-cases for WDYR and an example on how to use it:
https://blog.logrocket.com/debugging-react-performance-issues-with-why-did-you-render/

VoiceOver quick start

Riley McMaster — Fri, 03 Nov 2023 14:04:40 +0000

VoiceOver is a screen reader that comes installed on all Apple computers. This article will serve as a quick introduction to some of the basic commands to help you get started using a screen reader on any website. VoiceOver will work in any browser but does work best in Safari.

The VoiceOver command keys will be used for almost every command going forward. I will refer to the command as VO which can be either of these:

caps lock
option + command

Start VoiceOver - command + F5
Select use VoiceOver

It might start reading off all the elements on a webpage without taking a break and this can be a little overwhelming.

Stop VoiceOver from auto reading - press the control key.
Start reading again - VO + a
I wouldn't suggest auto reading for a first-time screen reader user. For now, let's take it one element at a time.

In the case that the whole browser is selected (you will see an outline around the whole app):
Interact with the item (the browser in this instance) - VO + shift + down
Stop interacting with an item - VO + shift + up
This can also be thought of like navigating levels of a directory.

If the tabs or address bar are selected, you will use
VO + up or VO + down until the content of the webpage is selected.

Once the web content is selected,
navigate between elements on the page:
VO + left arrow
VO + right arrow

Open Rotor: VO + u
This tool is really interesting because it organizes the content of the website in a completely different way than what sighted users are used to seeing. Rotor breaks down the content into several different categories: links, headings, form controls and landmarks.

You can navigate between the Rotor sections with the arrow keys.

Since starting to test the sites that I'm developing with a screen reader, I've found:

"read more" or other vague text in buttons are not helpful. Give buttons like this descriptive aria-labels
images declared in the content property of pseudo-elements will be read, even though there's no alt or title.
it's important to connect your labels to your inputs using id and for
use html table elements instead of creating a table visually with divs

It is worth exploring how to use screen readers and other assistive technologies in order to become a more empathetic developer. VoiceOver is a great tool that is readily available to all Mac users. While VoiceOver comes with its own tutorial, I found it a bit long and slow but it is definitely worth doing when you have the time.

To see the whole list of commands:
Apple - VoiceOver commands

CSS: complex grid layout

Riley McMaster — Tue, 12 Sep 2023 13:23:41 +0000

At Plank, we build many of our projects with Wordpress. Making menus in the CMS is pretty user friendly but when it comes to more complex menu structures, it can be difficult for us as the frontend developer to style when all we are given is nested lists upon nested lists.

To solve this problem, I came up with this grid layout recently and wanted to share how it is done. I’ll also discuss a big struggle I had to overcome for this to work properly, be flexible and easy to tweak.

The markup:

In this example, we are working with one unordered list with several children. The first child is a call to action and the rest are links. Wordpress allows us to add classes to the individual links (as well as a description to support the call to action), so I added a class and a description to the call to action list__item--cta.

I decided to go with grid over flex in this case because the call to action will take the whole vertical height of the menu while the rest of the links were tiled towards the right side of the screen.

.list {
   display: grid;
   // need to name the start and end of the 
   // first column so it can be referenced by the CTA
   // declare 4 columns, 
   // first spot for CTA then repeat 3 for the links
   grid-template-columns: [cta-start] minmax(200px, auto) [cta-end] repeat(3, minmax(50px, 1fr));
   grid-auto-rows: min-content;
}
.list__item--cta {
    grid-row: 1 / 4;
    grid-column: cta-start / cta-end;
    height: 100%;   
}

Since we did not define the amount of rows on the parent, the --cta child is telling the parent grid how many rows there will be with the property grid-row: 1 / 4;. The value is spanning from the first line (start of the first row) to the fourth line (end of the third row). In this example we have 7 links, so we need 3 rows and 3 columns (in practice I used a bit of JavaScript to adjust the number of rows and columns based on the number of links).

I made the description of the call to action contenteditable to show where I went wrong. Edit the text and see how the grid falls apart

The gap between the rows shouldn't start stretching out like that. So what is there to do?

The Fix

Grid will fill its rows before columns by default. We need three rows for the amount of links we have. But what if we create one extra row that starts at a height of 0 and its only job is to expand to take the extra height of the CTA description? In this case, we update the grid-row property on --cta to create an extra row:

.list__item--cta {
   grid-row: 1 / 5;
}

Remember that when setting the grid-row property, the last line in the grid will always be one more than the number of rows.

The cta is now adding a fourth row that won't be filled up by the other links, the last row only exists as a buffer. If the CTA doesn't need that space, the row will have a height of zero.

Now we can add as much text as we want to the cta description and the other links will be completely unaffected!

The final result:

Done!

Using the reduced motion media query in a project

Riley McMaster — Mon, 24 Jul 2023 13:14:31 +0000

The CSS media query prefers-reduced-motion is a rule that checks the user's accessibility setting for "reduced motion" in their system preferences. It is not browser, website or session dependent but a setting on the user's computer itself. This media query allows us as developers to update any styles based on the user's preference for animation.

The intent of this media query is to create a comfortable experience for all users. Animations can cause discomfort and even pain for neurodivergent users which can include people with vestibular disorders and users who are prone to inattention due to ADHD, bipolar disorder, depression or anxiety disorders. Other users may wish to turn on "reduced motion" to minimize distractions or reduce cognitive load.

The problem is that not all sites accommodate the user's wishes and stop animations if they have selected "reduced motion".

When a user chooses "reduced motion" it does not necessarily mean that they wish to have no motion at all. Some animations are extremely helpful for the user experience in providing visual feedback: a loading spinner that doesn't spin can make the user think the site is frozen, a button changing scale as you click it can emphasize that it has been clicked. Reducing motion is most beneficial when dealing with big parallax effects, scroll hijacking and animations that cover lots of screen space as these are most likely to cause issues for motion-sensitive users.

A developer's initial instinct to using the prefers-reduced-motion media query might be to stop animations on an individual selector basis:

  @media screen and (prefers-reduced-motion) {
    animation: none;
    transition: none;
  }

This will likely cause issues because the animations can get stuck at their initial value (ie. opacity: 0 and the position is off screen).

We want a more global solution that will make it easier to develop for users who want less motion. We also need for the animations to play so that the elements end up at their desired end point, while not noticing the in-between states of the animation. We can use the animation and transition duration property to force the animations to run at a speed so fast that it is imperceivable.

In the root level of our CSS, we call the reduced-motion media query and target a specific class that will 'turn off' the animations for those elements.

A more global and adaptable solution:

@media only screen and (prefers-reduced-motion) {
  .reduce-motion,
  .reduce-motion::before,
  .reduce-motion::after {
    animation-delay: 0s !important;
    animation-duration: 0.001ms !important;
    animation-iteration-count: 1 !important; 
    transition-duration: .0001ms !important;
    transition-delay: 0s !important;
  }
}

As we are developing, we can add the class reduce-motion to any elements that we think are not necessary to the user experience or could cause discomfort to the motion-sensitive users.

While we try to use the !important property as little as possible, it is a valuable use of it here since the point is to be a global override of any animation and transition properties further down the style-sheet.

This isn't necessarily a perfect solution but it is important to have these conversations about how different people experience the web. In order to build more inclusive sites, we need to listen to issues people have and address them with any tools that we have available to us.

Sources that helped inform this article: