Is your CSS feature detection robust enough?

This is a story of lazy CSS feature detection and why simple syntax checks may not be robust enough to future-proof your CSS.

Back in January I wrote an article explaining how to use CSS conic gradients to create single element CSS pie charts with variable segment counts and values. At the time I was developing the examples in Chrome, which supported conical gradients behind the "Experimental web platform features" flag. To prevent the examples rending incorrectly in browsers that didn't support conical gradients, I opted to add my rules inside a @supports block:

@supports (background: conic-gradient(red, blue)) {
  /* Do conic-gradient magic */
}

Everything worked fine. If I toggled the feature flag on in Chrome I saw pie charts. If I toggled it off or used another browser, I saw fallback text.

Skip forward nine months. Chrome 69 is released and comes with conical gradient support! Once my version of Chrome got round to updating itself, I loaded my article to check that the examples were rendering as expected. They weren't...

Instead of multi-coloured pie charts, Chrome was rendering empty circles. It was obvious that the CSS feature test had worked; I was seeing the outer part of my pie chart and the unsupported text was hidden. I opened devtools and started digging into what was wrong.

The style inspector identified the background-image property contained an invalid value — something was wrong with the syntax of my conic-gradient statement. I started simplifying the gradient until I managed to get something to render.

The cause turned out to be the double-position colour stop syntax, which is used to create a hard colour stop between the segments:

background-image: conic-gradient(
  #d44 72deg,
  #fc3 0 234deg, /* Note the extra 0 to create a 'hard' stop */
  #ac0 0
);

Removing the extra colour stop position fixed the syntax error but resulted in linear colour interpolation between stops:

background-image: conic-gradient(
  #d44 72deg,
  #fc3 234deg, /* no 'hard' stop */
  #ac0 0
);

Working around the problem was simple enough. Adding extra colour stops restored the chart segments:

background-image: conic-gradient(
  #d44 72deg,
  #fc3 72deg, /* duplicate colour stop  */
  #fc3 234deg,
  #ac0 0
)

With the problem identified it was time to raise a bug — it was this process the indentified the true cause...

Although Chrome does support conical gradients, it doesn't support the double-position colour stop syntax. However, the newer colour stop syntax is implemented behind the "Experimental web platform features" flag. Enabling the feature flag fixed the examples.

While writing the examples for my articles I was working with experimental web platform features flag enabled and was unaware that these were two separate features. I incorrectly assumed that the double-position syntax would be implemented as part of conical gradients.

Ultimately, this was my mistake. I'd fallen into the trap of using support of one feature to infer support of another. In my defence, bundling multiple features that work together behind a single flag is always going to cause this sort of confusion. Also, I don't think I'm alone here. Many of the other conical gradient articles I've read also refer the newer colour stop syntax.

Take away

Be explicit when feature testing. Testing support with a simple syntax check may not be good enough:

@supports (background: conic-gradient(red, blue)) {
  /* Do conic-gradient magic */
}

If I had used this version, my examples would have behaved as expected:

@supports (background-image: conic-gradient(#d44 72deg, #fc3 0 234deg, #ac0 0)) {
  /* Do conic-gradient magic */
}