@supports and vendor prefixes

After having added a bookmark to yesterday’s article about drop caps, I obviously also inspected the bookmarked page, which happens to be the wonderful “Experimental Layout Lab of Jen Simmons”, in the Web Developer Console. While doing that, I had a TIL moment.

When it comes to @supports, you can test for a property and their vendor-prefixed companions in one go, without invalidating the whole thing:

@supports (hyphens: auto) or (-ms-hyphens: auto) {
	/* stuff in here is picked up by all modern browsers,
	   even those that do not implement "-ms-hyphens" */
}

The above detection works in e.g. Chrome and Firefox, even though they both know nothing of -ms-hyphens.

This is interesting, so these “or” combinations in feature detections are apparently forgiving, similar to the forgiving selector parsing in :is and :where. Compare this to a regular list of (top-level) comma-separated selectors: If it contains unknown/invalid segments, the whole list is ignored. Let’s look at the following example.

::-moz-selection,
::-ms-selection,
::selection {
	/* stuff in here is only picked up by browsers
	   that implement all three of the above */
}

It is safe to assume no browser exists that has implemented both the -moz- and -ms- prefixed variant of ::selection, so this selector can never be true. Your only way to style text selection is to split up the selector list, and by doing so, repeating the code for each prefix^[1].

Okay, enough, I’m deviating from the actual topic.

What was it about?

Let me recap by paraphrasing myself:

A browser does not invalidate an @supports rule when it contains a vendor prefix unknown to said browser.

I’ve created an example that showcases how it works the fact that it does work.

---

Footnotes

1. Luckily, vendor-prefixed versions of ::selection are no longer needed these days^[2]. ↩︎
2. For accessibility reasons, it is best not to style text selection in the first place ^{[citation needed]}. ↩︎