There are many ways to adjust your CSS code to a browser’s support for a specific CSS feature. If you want to check if a certain property is supported, you can write a feature query using the @supports at-rule, for example:

@supports (display: grid) {
  div {
    display: grid;
  }
}

If the browser supports display: grid, it will apply all the styles inside of the at-rule. Otherwise, it will just ignore the whole block.

If you want to check for support of a whole selector, you can use the @supports selector() function, which has surprisingly good browser support.

@supports selector(:nth-child(1 of .class)) {
	/* Do something… */
}

In case you want to learn more, Chris Coyier also wrote a nice piece about how to use @supports selector().

In a current project, however, I ran into a situation where I needed to test for support of the relatively new :where() selector. The tricky situation: both :where() and @supports selector() landed in browsers at about the same time, so if you want to check for support in an older browser, like Safari 13, you’re out of luck. Providing a sensible fallback for older browsers was one of the requirements, though, so I had to look for an alternative. And in the end, I decided to use JavaScript.

I found the solution in a post by Lea Verou. In 2011, she wrote about how to test for CSS selector support by creating a new <style> element with the selector we want to test for and then reading out the stylesheet to see if the rule actually exists. A really smart solution to detect support even in browsers <IE8.

But she also mentioned a much simpler solution: Using document.querySelector() in a try...catch statement. And since support for the Selectors API is very good these days, I settled on trying this. And it is indeed straightforward:

try {
    document.querySelector(selector)
} catch (error) {
    console.error(error)
}

First, we let the browser try to execute the document.querySelector() method with the selector we want to test. In case the selector is invalid, an exception is thrown and the code in the catch block is executed. In the example above, the error will then be output to the console.

We can now wrap this in a reusable function that returns true in case our selector is supported and false if is isn’t:

const isSelectorSupported = (selector) => {
    try {
        document.querySelector(selector)
        return true
    } catch (error) {
        return false
    }
}

Now, you can test for support of any selector and, for example, add a class to the element, if a browser “cuts the mustard.”

if (isSelectorSupported(":where(body)")) {
    document.documentElement.classList.add("supports-where")
}

I’d still recommend you use a CSS-only solution to check for support whenever possible. But for all other cases, this little helper function might prove very useful.

✍️✍️✍️ Edit #

Shortly after I shared this post on Twitter, I received two replies by Mehdi Merah and Bramus van Damme, who both suggested alternative methods of detecting support for a selector. First of all: thanks a lot! 🤗 Let's have a look at them.

Using CSS Custom Properties to check for selector support #

Mehdi mentioned that one could also use CSS Custom Properties to emulate @supports in JavaScript. A smart solution and one that can be combined with your existing rules. The idea is that you first define a custom property that basically acts as a boolean variable and then set it to a different value inside of the selector you want to test support for:

:root {
  --supports-selector-where: 0;
  
  @supports selector(:where(a)) {
    --supports-selector-where: 1;
  }
}

In our case, we can even reduce it further and only set the custom property using a selector with :where(). If the browser supports it, it will set the custom property to 1:

:where(:root) {
  --supports-selector-where: 1;
}

In JavaScript, we can now access the value of our custom property with getComputedStyle and getPropertyValue. And if the value is 1, we know that the selector is supported.

const rootStyles = getComputedStyle(document.documentElement)
const supportsSelectorWhere = rootStyles.getPropertyValue('--supports-selector-where').trim() == "1"

console.log(supportsSelectorWhere) // boolean -> true if supported

This technique can not only be used to detect support for selectors but for any other cases where you want to communicate a status from CSS back to JavaScript. Andy Bell wrote a brilliant little helper function that even lets you state which datatype you want to get back:

/**
 * Pass in an element and its CSS Custom Property that you want the value of.
 * Optionally, you can determine what datatype you get back.
 *
 * @param {String} propKey
 * @param {HTMLELement} element=document.documentElement
 * @param {String} castAs='string'
 * @returns {*}
 */
const getCSSCustomProp = (propKey, element = document.documentElement, castAs = 'string') => {
  let response = getComputedStyle(element).getPropertyValue(propKey);

  // Tidy up the string if there's something to work with
  if (response.length) {
    response = response.replace(/\'|"/g, '').trim();
  }

  // Convert the response into a whatever type we wanted
  switch (castAs) {
    case 'number':
    case 'int':
      return parseInt(response, 10);
    case 'float':
      return parseFloat(response, 10);
    case 'boolean':
    case 'bool':
      return response === 'true' || response === '1';
  }

  // Return the string response by default
  return response;
};

With this helper function, we can check for support for :where() with the custom property from before and one line of JS:

const isWhereSupported = getCSSCustomProp('--supports-selector-where', document.documentElement, 'boolean')

Using CSS.supports() #

Bramus suggested taking another route: the CSS.supports() method. This native JavaScript method with really good browser support accepts anything you may put inside a supports at-rule, so we can do this:

const supportsWhere = CSS.supports('selector(:where())');

if (supportsWhere) {
    document.documentElement.classList.add("supports-where");
}

And that’s it. Plain and simple.

Definitely my favorite solution because of good browser support and its simplicity – and something I probably wouldn’t have learned about if I hadn’t written and shared a blog post about my problem.

~