Outline Color Property Invert Support

Hi everyone,

I’ve been looking at the invert value that can be used for CSS outline-color property. According to the documentation for this on MDN browser support is extremely poor. https://developer.mozilla.org/en-US/docs/Web/CSS/outline-color#Browser_compatibility

According to the spec this is due to the caveat :

Conformant UAs may ignore the ‘invert’ value on platforms that do not support color inversion of the pixels on the screen. If the UA does not support the ‘invert’ value then the initial value of the ’outline-color’ property is the value of the ‘color’ property, similar to the initial value of the ‘border-top-color’ property.

Does anyone know more about this? What would be limiting adoption on certain browsers, why they would not wish to implement the feature etc?

It seems like something incredibly useful to me.

‘invert’ requires reading the pixel values of arbitrary content under the outline. As this content might be from multiple different GPU layers, this can be an incredibly expensive operation, for relatively little benefit.

The CSS blending and compositing features, which would naively suffer the same problem, only blend/composite within a given stacking context (which is a proxy for GPU layers - we need a stacking context in order to create a GPU layer, to ensure that nothing else can get “between” the elements painted to a given layer). Thus it’s possible to blend/composite efficiently, but not to do inverted outlines efficiently.

Ah of course! I completely forgot about the possible layering inefficiency.

Thanks for clearing that up.

Spitballing here: it’d be nice if specs had links to rationales/discussions like these, even if it’s just non-normative links to messages on the mailing list / Discourse.

Edit: see https://github.com/stuartpb/wicg-best-practices/issues/2

One quick fix would be to change the wording in the spec:

Conformant UAs may ignore the ‘invert’ value on platforms that do not support color inversion of the pixels on the screen, or where calculating the color inversion is deemed as too expensive

Or, if there is some form of consensus among browsers that they can’t support this, deprecate it…

I don’t think there is total consensus about not supporting this, since IE does support it (and Presto did). However, the clarification you suggest is reasonable. I’ll slide it in into level 4.

invert was abandoned and not brought back likely because there are already ways to duplicate this behavior through compositing and styling. Though, in today’s world it would not be all that expensive to do this, but since nobody seems to care about it being gone, it hasn’t come back and is removed from just about every browser support. “outline” came out in a time when web page rendering was far simpler than it has become. It goes to the graveyard along with stuff like (but blink can be easily duplicated with providing you have something like @keyframes blinker { 0%{ opacity: 0% } 100%{ opacity: 100% } somewhere (in for example) and is done in pure CSS) HOWEVER, inverted border would require an extra element and/or special more complex manipulation to pull it off, which would probably be more trouble than it was worth for a simple border.

What should be done is for the rendering engine to internally convert this request to the equivalent supported methods required to do so, but like I said, nobody really is making noise about wanting it so it will likely stay in the graveyard–features like this are usually needed for accessibility and therefore placed in the operating system’s charge or at the very least, a browser extension.

So! In short there are a bunch of ways to mimic this, but most of them either are exotic, esoteric or time consuming in nature. And unless tons of people request it be brought back, you will have to kiss invert goodbye.