[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.

[fantasai]

Can we resolve on what @SelenIT said? Seems like Firefox is implementing it correctly atm.

[css-meeting-bot]

The CSS Working Group just discussed [Cascade / Pseudo-elements / Values / Fragmentation] currentColor when fragments have differents colors, and agreed to the following:

• RESOLVED: Color inherits according to first line inheritance. currentColor keys off value of that fragment per fragment
• RESOLVED: Have font-relative units key off the font size per fragment

The full IRC log of that discussion

<dael> Topic: [Cascade / Pseudo-elements / Values / Fragmentation] currentColor when fragments have differents colors
<dael> github: https://github.com//issues/1510
<fantasai> https://jsfiddle.net/ehzknab5/2/
<dael> fantasai: Bunch of properties that can take currentColor. The rending in FF that's screenshotted is outdated. If you load newer FF all properties are correctly handled
<dael> fantasai: Seems to be what author expect. Impl by one browser. I'd like to resolve that's how it's done
<dael> astearns: Different opinions?
<dael> astearns: I'd rather not resolve on do what is says in the issue. Summary?
<dael> fantasai: Prop: color inherits according to first line inheritance. currentColor keys off value of that fragment per fragment
<dael> astearns: Concerns? Objections?
<dael> RESOLVED: Color inherits according to first line inheritance. currentColor keys off value of that fragment per fragment
<fantasai> https://github.com//issues/1510#issuecomment-689042237
<dael> fantasai: Related is for fonts which is comment from oriol ^
<dael> fantasai: If first and third line match it's impl by that rule
<dael> astearns: Second is do the same thing for font relative units?
<dael> fantasai: Yes, key of font size per element
<dael> astearns: Objections?
<fantasai> s/of/off/
<dael> RESOLVED: Have font-relative units key off the font size per fragment
<dael> myles: first letters are big. If you use em you get the big size for that element
<dael> fantasai: This is first-line. It's the inner most element. There are issues around that and I think they're filed. But it's a separate kind of mechanism then first-line
<dael> astearns: We're at time. Should we walk back resolution, myles?
<dael> myles: No, we can continue

[fantasai]

We added the following paragraph to css-cascade-5:

Certain CSS features can interfere with value processing on a per-fragment basis. See for example “CSS Pseudo-Elements 4 §2.1.3 Inheritance and the ::first-line Pseudo-element” which alters inheritance for fragments within the ::first-line pseudo-element. In such cases, where individual fragments are given different specified values, any values that resolve based on the computed value of other properties (such as currentcolor or em units) are resolved per box fragment. Subsequent value processing proceeds as normal in each fragment.

We also noticed that we now have no good answer to what APIs like ''getComputedStyle()'' should return. Based on Firefox’s handling of the testcase, we're recommending to spec the following:

APIs that assume a singular value per box (rather than per box fragment) must ignore the effects of non-tree-abiding pseudo-elements. (For example, ::first-line styles have no effect on the value returned by getComputedStyle().)

Agenda+ to confirm with the CSSWG.

[css-meeting-bot]

The CSS Working Group just discussed [Cascade / Pseudo-elements / Values / Fragmentation] currentColor when fragments have different colors, and agreed to the following:

• RESOLVED: The return value of gCS to match FF behavior that first-line is ignored in gCS

The full IRC log of that discussion

<dael> Topic: [Cascade / Pseudo-elements / Values / Fragmentation] currentColor when fragments have different colors
<dael> github: https://github.com//issues/1510
<fantasai> https://github.com//issues/1510#issuecomment-803203212
<emilio> grr, webex interface is confused about whether I'm muted because Linux is confused about what mic I'm using, fantastic :(
<dael> fantasai: We discussed what to do when an element is frag so it has different parentage. span split between first and 2nd line and there's a first-line pseudo. Decided on inheritance and a bunch. Resolved currentColor or em or resolved per fragment
<dael> fantasai: FF has impl this based on test cases in issue. Edited in
<dael> fantasai: Don't have answer when you call API like gCS on the element. Has one style per element. Proposal is define the API which assume single value per box must ignore effect of non-tree abiding elements
<Rossen_> q?
<dael> fantasai: Means span split across 2 lines pretends first-line pseudo is not there. You don't have to compute differently if have broken across lines. Seems to be what FF is doing
<dael> fantasai: Want to run past WG
<dael> Rossen_: Proposed behavior is similar to that of first-line for gCS?
<dael> fantasai: Talking about defining the case of first-line for gCS
<dael> Rossen_: Rephrase: if you have an inline item that has a spec line-height and you do gCS and that line item has a number of fragments, one if first and one in second. gCS will return the first. Perhaps line-height isn't good example. What returns used values
<dael> TabAtkins: Color
<dael> Rossen_: What would color return?
<dael> fantasai: Color it will ignore the first-line style. First line is blue, span on 2nd line and it's black. Span splits it returns black. Span on the first-line still returns black. That way browser doesn't have to take into effect if the span breaks. We ignore first-line styles
<dael> fantasai: Could say take style of first box fragment. That's another possibility
<dael> Rossen_: Okay, makes sense. Thank you
<dael> Rossen_: Any feedback?
<dael> Rossen_: If not we can call for objections
<dael> oriol: Concern is usually cascade is in element tree and this is in fragment tree. Given display:contents you can have elements w/o fragments in frag tree. not clear it's well defined. Might be outside of scope of the issue. It may need extra work in the future in another issue
<dael> Rossen_: Thanks oriol
<dael> fantasai: Either way we need an answer for what gCS returns
<dael> Rossen_: Prop here is have the same behavior as FF and as you described for color?
<dael> fantasai: Yep
<dael> fantasai: 2 things that could make sense. Returnt he styles ignoring first-line. Other is return style of first fragment. FF has impl first option so we propose that.
<dael> Rossen_: Impl PoV this is easier. User PoV these are equally wrong since you don't have per frag access. For consistency sake with current impl I'm in favor of that proposed behavior
<dael> Rossen_: Not hearing other proposals. Objections to resolve return value of gCS to match FF behavior that first-line is ignored in gCS
<dael> RESOLVED: The return value of gCS to match FF behavior that first-line is ignored in gCS
<dael> Rossen_: Anything else on this?
<dael> fantasai: Just need to fold in edit