Conditional rules

Back to the index.

CSS Conditional Rules specification.

The conditional rules module is mostly about the syntax for at-rules such as media queries, @font-face, and the like. However, it contains the @support rule which will likelye become more important over time.

This is the mobile table. See also the desktop table.

Last major update on 6 July 2016.

@supports

The first test is only about basic support and syntax: is @supports supported at all?

iOS iOS WebView And. 4 AWK WebView Chromium Chromium WebView UC 10 BlackBerry 10 Dolphin Opera Mini IE 11 Edge 13 Firefox
8 9 8 9 LG Cy HTC S34 Ub MM S44 Xia Op Go 30 33 39 45 51 11 17
@supports
Basic support 		No Yes No Yes No Yes Yes No Yes No Yes No Yes 
@supports (display: block) {
	// styles
}

The styles are applied if the CSS parser recognises display: block as a valid value.

Specific cases

Let’s review two specific cases. Both show the limits of what @supports can do. To me, these test cases prove that it’s best to use @supports only for detecting support for large modules such as flexbox, and not for individual values. That makes it quite a bit less useful.

iOS iOS WebView And. 4 AWK WebView Chromium Chromium WebView UC 10 BlackBerry 10 Dolphin Opera Mini IE 11 Edge 13 Firefox
8 9 8 9 LG Cy HTC S34 Ub MM S44 Xia Op Go 30 33 39 45 51 11 17
transition-property: nonsense
 - corr - corr - corr inc corr inc - corr - corr - inc

@supports (transition-property: nonsense). I’d say that the browser should return false, since there is no CSS property nonsense.

However, it seems they must accept any value for this particular property, since it might be a future property that this particular browser does not support in case you try @supports (transition-property: display, nonsense). I’m not entirely convinced by this argument (if a browser doesn’t support a property it can’t transition it), but it seems to be the official answer.

I assume that rejecting nonsense was the WebKit way of doing things that Blink inherited until it changed behaviour in Chromium 35.

Inc
Incorrect: browser says it supports nonsense.
Corr
Correct: browser says it does not support nonsense.
background-attachment
 - inc - inc - inc corr inc inc - inc - inc - corr

Then a more subtle case: @supports (background-attachment: fixed | local). The point here is that in practice most mobile browsers do not support it; see also the compatibility table. Still, when asked via @support they will say there is no problem. Is this an error? Or merely an expectation that we web developers have?

Inc
Incorrect: browser says it supports background-attachment while in practice it doesn’t.
Corr
Correct: browser says it supports background-attachment and does. (Bugs are ignored.)

Tested browsers

Mobile browser test array 3.1; July 2016

iOS 8
WebKit 600
Default browser on iPhone 4S with iOS 8.3
iOS 9
WebKit 601
Default browser on iPad 2 with iOS 9.3.2
iOS 8 WebView
WebKit 600
Chrome/iOS on iPhone 4S with iOS 8.3
iOS 9 WebView
WebKit 601
Chrome/iOS on iPad 2 with iOS 9.2.1
Android WebKit 4
WebKit 534
Default browser on Huawei C8813, Android 4.1.1
Default browser on Samsung Galaxy Note I, Android 4.1.2
Default browser on Sony Xperia S, Android 4.1.2
Default browser on LG L5, Android 4.1.2
Default browser on Wolfgang AT-AS45FW, Android 4.2.2 (see note below)
Default browser on HTC One X, Android 4.2.2
Android 4 WebView
WebKit 534
WebView on Samsung Galaxy Note I, Android 4.1.2
WebView on Sony Xperia S, Android 4.1.2
WebView on HTC One X, Android 4.2.2
WebView on Wolfgang AT-AS45FW, Android 4.2.2 (see note below)
All these WebViews were tested with the HTML5Test Android app.
Chromium LG 30
Blink; Chromium 30
Default browser on LG L70, Android 4.4.2
Chromium Cyanogen 33
Blink; Chromium 33
Default browser on Galaxy Nexus flashed with Cyanogenmod 11, Android 4.4.4
Chromium HTC 33
Blink; Chromium 33
Default browser on HTC M8, Android 6.0
Chromium Samsung 34
Blink; Chromium 34
Default browser on Samsung Galaxy S4, Android 5.0.1
Chromium Ubuntu 35
Blink; Chromium 35
Default browser on Ubuntu Phone 15.04
Chromium Micromax 39
Blink; Chromium 39
Default browser on Micromax Canvas Nitro 3 Android 5.1
Chromium Samsung 44
Blink; Chromium 38
Default browser on Samsung Galaxy S6, Android 5.1.1
Chromium Xiaomi 46
Blink; Chromium 46
Default browser on Xiaomi M2, Android 5.0.2
Chromium Opera 50
Blink; Chromium 50
34 on LG L5, Android 4.1.2
Chromium Google 51
Blink; Chromium 51
Default browser on Motorola Moto G, Android 5.1
This is Google’s regular Chrome. I test it only on devices where it is the default browser.
Chromium WebView 30
Blink; Chromium 30
WebView on LG L70, Android 4.4.2
All these WebViews were tested with the HTML5Test Android app.
Chromium WebView 33
Blink; Chromium 33
WebView on Galaxy Nexus flashed with Cyanogenmod 11, Android 4.4.4
Chromium WebView 39
Blink; Chromium 39
WebView on Micromax Canvas Nitro 3 Android 5.1
Chromium WebView 45
Blink; Chromium 45
WebView on HTC M8, Android 6.0
Chromium WebView 51
Blink; Chromium 48
WebView on Samsung Galaxy S6, Android 5.1.1
All these WebViews were tested with the HTML5Test Android app.
UC 10
WebKit 534
UC 10.10.5 on Samsung Galaxy S6, Android 5.1.1
BlackBerry 10
WebKit 537
Default browser on BlackBerry Z30 (BB OS 10.3.2)
Dolphin
Probably WebKit
Dolphin 11.5.7 with JetPack on Intex Agua Super, Android 5.1.
Independent full browser for Android, as long as you install both Dolphin and the Jetpack extension.
It claims to be a Chromium 33, but it lies.
Opera Mini 11
Presto
Proxy browser
11 on Intex Agua Super, Android 5.1. It is the default browser on this device; that’s why included this old version
Opera Mini 17
Presto
Proxy browser
15 on Samsung Galaxy S4, Android 5.0.1
IE11
Trident
Default browser on Nokia Lumia 820, Windows Phone 8.1 “Update”
This is a developer phone. That might matter.

Edge 13
Edge
Default browser on Nokia Lumia 830, Windows 10 Mobile
Firefox Android
Gecko 47
47 on Motorola Moto G, Android 5.1