[Cascade / Pseudo-elements / Values / Fragmentation] currentColor when fragments have differents colors

[Loirooriol]

CSS Color says

The keyword currentcolor represents value of the color property on the same element.

But what if different fragments of that element have different colors? This is possible with ::first-line.

Example: https://jsfiddle.net/ehzknab5/2/

<div><span>Lorem ipsum<br />dolor amet.</span></div>
<div><span>Lorem ipsum.</span></div>

div {
  color: red;
}
div::first-line {
  color: green;
}
br {
  line-height: 0;
}
span {
  box-decoration-break: clone;
  -webkit-box-decoration-break: clone;
  line-height: 50px;
  background-image: linear-gradient(currentcolor, currentcolor);
  background-color: currentColor;
  background-size: 100% 75%;
  background-repeat: no-repeat;
  border: 5px solid currentColor;
  outline: 5px solid currentColor;
  box-shadow: 111px 0 5px currentColor;
  text-shadow: 222px 0 2px currentColor;
  filter: drop-shadow(333px 0 0 currentColor);
}

Firefox:

Chrome:

Edge:

[SelenIT]

As an author, I would expect these fragments to have different currentColor values, so the colors of the font and decorations/effects of each fragment always meet (according to the principle of least surprise). The same behavior I'd expect from the "text runs" with differently styled parts that display:contents may result in. So I'd expect both 1st and 3rd lines of the example to be all green, and the 2nd line all red.

This would require implementing all the effects for inline elements on a per-fragment basis, but it seems the most reasonable approach for it anyway (although I admit that there might be some performance and compatibility considerations).

[svgeesus]

This would be a new feature, so should be developed in CSS Color 4.

[AmeliaBR]

FYI: Some of the differences you're seeing in browsers may be related to how they handle inheritance of currentColor values in general, not specific to the particular inheritance issues of elements broken into separately styled fragments.

Most browsers still follow the original draft of CSS Colors 3, and convert currentColor to a specific color value before inheritance.

Chrome, however, inherits currentColor as its own value, only converting it to a specific color at final used value time. This is how the latest drafts of CSS Colors 3 & 4 define it, to be consistent with how it was defined in SVG 1.

Which makes it much harder to distinguish from the test how the browsers are interpretting the inheritance rules for the two fragments within the <span>. But regardless, the rules for currentColor and fragments should be consistent with any other property that depends on inheritance, such as font-size with a percent value. So the best place to define that would probably be in the pseudoelements and/or cascade specs, not in Colors.

[svgeesus]

Most browsers still follow the original draft of CSS Colors 3, and convert currentColor to a specific color value before inheritance.

Color 3 has an erratum about that, there is a test which has two passing implementations, Blink and Gecko.

Today we requested CR for CSS Color 3, rolling in those errata, with a view to it becoming an Edited Recommendation. I expect WebKit and Edge to align with the correct behaviour soon.

[svgeesus]

OK so @Loirooriol did the change (in second edition CSS Color 3, and also in CSS Color 4) about inheritance and currentColor fix this issue, or is more work needed?

[Loirooriol]

I think it's still not completely clear what should happen when different fragments have different colors. But as Amelia said this is not specific of colors, I can create a similar example using lengths with em units, and then changing the font-size in some fragment but not others: https://jsfiddle.net/9p0Lfczm/ (again, no interoperability).

So probably CSS Color is fine, and this should be explained in Cascade / Pseudo-elements / Values / Fragmentation.