CSS - Media Queries

A good rule is to decrease the brightness and contrast of images a bit so that it looks comfortable to the eyes when it’s against a dark background. A super bright image on a super dark background can be jarring and dimming the image reduces some of that heavy contrast.

[…]

The CSS filter() function is more than capable of handling this for us:

The browser will use this information in tandem with the user’s browser or device settings to determine what colors to use for everything from background and foregrounds to form controls and scrollbars. The primary use for <meta name="color-scheme"> is to indicate compatibility with—and order of preference for—light and dark color modes.

— Standard metadata names - HTML: HyperText Markup Language | MDN

When this meta tag is added, the browser takes the user’s color scheme preferences into consideration when rendering UA-controlled elements of the page (like a <button>). It renders colors for the root background, form controls, and spell-check features (as well as any other UA-controlled styles) based on the user’s preference.

[…]

Although themes are manually styled for the most part (which overrides the UA styles), informing the browser about the supported themes helps to avoid even the slightest chance of a potential FOIT situation. This is true for those occasions where HTML has rendered but CSS is still waiting to load.

— A Complete Guide to Dark Mode on the Web | CSS-Tricks

Two years ago, I wrote about prefers-reduced-motion, a media query introduced into Safari 10.1 to help people with vestibular and seizure disorders use the web. The article provided some background about the media query, why it was needed, and how to work with it to avoid creating disability-triggering visual effects.

The article was informed by other people’s excellent work, namely Orde Saunders’ post about user queries, and Val Head’s article on web animation motion sensitivity.

We’re now four months into 2019, and it makes me happy to report that we have support for the feature in all major desktop browsers! Safari was first, with Firefox being a close second. Chrome was a little late to the party, but introduced it as of version 74.

[…]

Reduce isn’t necessarily remove

We may not need to throw the baby out with the bathwater when it comes to using animation. Remember, it’s prefers-reduced-motion, not prefers-no-motion.

[…]

If the meaning of a component is diminished by removing its animation altogether, we could slow down and simplify the component’s animation to the point where the concept can be communicated without potentially being an accessibility trigger.

I’ve just converted my Sass code to use this, and I can safely say it’s pretty excellent.

include-media is a Sass library for writing CSS media queries in an easy and maintainable way, using a natural and simplistic syntax.

[…]

Why another library?

I spent quite some time experimenting with different libraries and mixins available out there, but eventually all of them failed to do everything I needed in an elegant way. Some of them wouldn’t let me mix set breakpoints with case-specific values, others wouldn’t properly handle the CSS OR operator and most of them had a syntax that I found complicated and unnatural.

include-media was the result of that experience and it includes all the features I wish I had found before, whilst maintaining a simplistic and natural syntax.

I wrote an article on CSS-Tricks about this experience, where I explain in detail the problems I found with each of the solutions I experimented with. I also wrote on David Walsh’s blog about the implementation details of include-media.

Example usage:

Want to see a really interesting use of media queries? Open Lynn Fisher’s site in a desktop browser and resize the window, or watch this (crappy and choppy) video I took of myself doing that:

WebKit now supports the prefers-reduced-motion media feature, part of CSS Media Queries Level 5, User Preferences. The feature can be used in a CSS @media block or through the window.matchMedia() interface in JavaScript. Web designers and developers can use this feature to serve alternate animations that avoid motion sickness triggers experienced by some site visitors.

To explain who this media feature is for, and how it’s intended to work, we’ll cover some background. Skip directly to the code samples or prefers-reduced-motion demo if you wish.

While it’s still true that You Can’t Detect A Touchscreen, the Interaction Media Features media queries can come in handy in edge cases. Still, don’t assume too much about a device, as both the link above and the source for this emphasize.

Thanks to the W3C CSS Working Group and the CSS community, we have a cleaner solution.

On the Media Queries Level 4 Working Draft, there is a spec for Interaction Media Features that includes three definitions:

• Pointing Device Quality
• Hover Capability
• Rare Interaction Capabilities

These provide the capability to query a document based on the presence and accuracy of the user’s pointing device and whether it has the ability to hover over elements.

Let’s take a closer look at each one:

Pointing Device Quality: The pointer Feature

The pointer media feature is used to query about the presence and accuracy of a pointing device such as a mouse. If a device has multiple input mechanisms, the pointer media feature must reflect the characteristics of the “primary” input mechanism, as determined by the user agent.” - W3C

The key word here is “accuracy” of the pointing device.

• A mouse or a drawing stylus is very accurate and defines the value of fine.
• A finger or a Kinect peripheral isn’t, and takes the value of coarse.

Therefore, we can adapt our UI elements to the user’s pointer capabilities. This is useful for making hit areas larger, if the user’s main input mechanism is a finger.

An example use case for this query is to size the click area of a checkbox or radio.

Hover Capability: The hover Feature

The hover media feature is used to query the user’s ability to hover over elements on the page. If a device has multiple input mechanisms, the hover media feature must reflect the characteristics of the “primary” input mechanism, as determined by the user agent.” - W3C

It’s important to notice that it only evaluates the primary input mechanism. If the primary input mechanism is not able to hover, but the secondary input can, then the query will resolve to none:

For example, a touchscreen where a long press is treated as hovering would match hover: none.” - W3C

• A touch screen device, where the primary pointer system is the finger and can’t hover, will take the value of none.
• A device where the primary input is a mouse and can easily hover parts of the page takes the value of hover.

A good use of this query is a drop-down menu.

Rare Interaction Capabilities: The any-pointer and any-hover Features

On devices that are both touch and have a mouse or a stylus, like the Microsoft Surface, the hover and pointer media query will evaluate the primary input mechanism only.

As Andrea Giammarc pointed out, his Dell XPS 13” touch takes the value of fine, even though it does have a touch screen because the primary input mechanism is a mouse.

[…]

If we want a device like that to take the value of coarse or hover, we can use the Rare Interaction Capabilities.

The any-pointer and any-hover media features are identical to the pointer and hover media features, but they correspond to the union of capabilities of all the pointing devices available to the user. More than one of their values can match, if different pointing devices have different characteristics. They must only match none if all of the pointing devices would match none for the corresponding query, or there are no pointing devices at all.” - W3C

Browser Support Isn’t Bad at All!

Even though this is a working draft, it has pretty good support.

My simple test proved successful on Chrome, Chrome for Android, Safari, Edge, Opera, Samsung browser, and Android Browser, but it didn’t work on [Firefox], Opera Mini or IE.

[…]

I think we are ready to use this feature, and as [Firefox] adds support for it and IE dies once and for all, we will have full support.

Sites all too often inundate their audiences with automatically playing, battery-draining, resource-hogging animations. The need for people being able to take back control of animations might be more prevalent than you may initially think.

[…]

Remember: we’re all just temporarily-abled. Feeling a little dizzy might not seem like that big a deal, but that moment of nausea might be a critical one: losing balance and falling down, a migraine during an interview, nausea-triggered vomiting while working a food service job, passing out while operating a car UI, etc.

So what can we do about it?

Enter a new Media Query

Safari 10.1 introduces the Reduced Motion Media Query. It is a non-vendor-prefixed declaration that allows developers to “create styles that avoid large areas of motion for users that specify a preference for reduced motion in System Preferences.”

The syntax is pretty straightforward:

Safari will parse this code and apply it to your site, letting you provide an alternative experience for users who have the Reduced Motion option enabled. Think of this new Media Query like @supports: describe the initial appearance, then modify the styles based on capability.