[css-ui-3] Remove outline-color: invert

[chrishtr]

It's only implemented in Edge, and the effect can be achieved by other means. It should be removed from the spec.

https://drafts.csswg.org/css-ui-3/#outline-color

https://bugs.chromium.org/p/chromium/issues/detail?id=620391

[FremyCompany]

What other means?

Without proof, this seems like an invalid statement. How would you go about achieving this on an inline element that breaks into fragments (like a link in a document often does)?

[chrishtr]

Sorry, I was too hasty in my bug. I agree that there are some use cases. Nevertheless I think
the implementation cost is too high for the value. FWIW Tab and Shane tended to agree with me.

[FremyCompany]

I see your point. We would need to remove it before going to REC because that needs two implementations anyway. I think a fair first step would be to "mark it as risk". It can always be brought back in a future level if we have to remove it before going to REC.

[frivoal]

I understand that the invert option is difficult to implement performantly in many modern browser architectures. However:

• Not only Edge, but also Presto (Opera <= 12.x) supports it, so we are not blocked from going to REC
• the spec already make a special allowance for Browsers for which pixel level color inversion is not practical: use currentColor as the initial value instead, and ignore (i.e. reject at parse time) the invert value.

So, browsers who do not want to implement that value are not forced to do so in order to claim compliance, and the spec can go to REC with this value in it. It seems to me we don't actually have a problem.

Now, I agree that Presto isn't particularly relevant these days, and I am only raising it as something we can use to reach REC if we keep the value, not as a proof that this is useful.

I think the original justification for the value is still valid (“ensure the focus border is visible, regardless of color background.”), and so long as at least one current browser (plus Presto, for REC purposes) supports it, I'd rather keep it in the spec. If everybody except historical browsers removed it, we could probably re-consider, but for now, it looks harmless.

If you think that would help, I would be fine with rephrasing the criteria that allows browsers to opt out of supporting this value (“on platforms that do not support color inversion of the pixels”) to make it a bit looser / clearer so that browsers that could theoretically do it but for which it would be highly inconvenient / costly to do so are included.

[frivoal]

@chrishtr: in light of comment #423 (comment), are you comfortable with the spec staying as it is? Do you want a clarifying note / rephrasing? Do you still think a normative change is needed?

[chrishtr]

I'd prefer to at least mark it as at risk, as Chrome does not intend to implement it at this time.

[tabatkins]

While the justification for invert is valid, the cost seems outsized, as Chrome and Firefox are both arguing. We can't do everything that's useful if it ends up slowing things down too much. :/ Given that Edge is the only relevant browser that has implemented it, and the lack of support means people aren't using it commonly enough (/ hackily enough) to really trigger the bad compositing/readback perf that we're afraid of yet, I think we should just drop it.

[frivoal]

If microsoft wants to drop it from their implementation, I will have no qualms about dropping it from the spec as well. If they don't, I don't really see what harm it does to others: the spec gives implementer an opt out, and we have enough implementations for TR progression purposes.

[frivoal]

I'd prefer to at least mark it as at risk, as Chrome does not intend to implement it at this time.

I don't mind doing so, but I don't see the benefit. At risk doesn't mean "not sure this is a good idea", it means "might drop if we don't have sufficient implementations to move along TR". We do have two implementations. Even if one isn't particularly relevant in terms of market share or market traction, it is as far as I know valid for demonstrating implementabilty.

Ironically, process wise, I believe we would need to take the draft out of CR and to CR again to add the "at risk" mark, which would cause more delays than doing nothing.

I don't mind adding "at risk" (since I don't think it makes a difference) if we end up publishing a new CR for some other reason, but process churn just for that reason seams overkill.

[frivoal]

Sorry for the late update. The CSSWG resolved a while back to reject the proposal to drop this from the spec (to be revisited if Edge decided to drop the feature)
https://lists.w3.org/Archives/Public/www-style/2016Nov/0079.html

@chrishtr I'd appreciate if you could look at the meeting minutes linked to above, and let us know if you accept this conclusion