Chrome behavior is almost certainly a bug. What would happen if the span was both on the first and second line due to wrapping? Chrome uses two different sets of values for the same span, which doesn't look the spirit of the css-cascade spec to me:

FireFox and Edge behavior is not what you think it is, though. All values of the span inherit from the div element (try alert(getComputedStyle(document.querySelector('span')).color)).

What actually happens is that Edge has the concept of "render styles" (first-line, selection, etc...) that apply on text runs during linebox building (a text run being a run of text that shares the same formatting and does not break to the next line).

Drawing backgrounds at the text run level would be ugly since some letters might be bigger or use a different font, so that is the only thing that is being drawn at the ::first-line level.

<div>
    <div::first-line line-backround has-own-style />
    <span inherits-from="div">
        <::text-run inherits-from="::first-line, span">ABC...</...>
        <::text-run inherits-from="span">STU...</...>

The ::text-run inherits its style from the first-line of its block container, the div... but only inheritable properties, not background!.

We have a similar behavior for the "high-contrast backplate" we draw when users enable a high-contrast theme on Windows, though we also draw it on inline elements to override local inline backgrounds; then there is the case of selections which are drawn only at the text run level; but that means those text backgrounds are not one rectangle but the unions of a lot of rectangles while the spec mandates the ::first-line background to behave like an inline which encompasses its text children and draws one background).

Btw here I added some image on the line and here is what the render is in Firefox:

You can see the background of the line being drawn under the backround of the span.

All values of the span inherit from the div element (try alert(getComputedStyle(document.querySelector('span')).color)).

Yes, I noticed that. It must be like this because the span might generate multiple boxes, some not in the first line. So in general the span inherits from the div, but the part of the span in the first line inherits from div::first-line.

Chrome behavior is almost certainly a bug. What would happen if the span was both on the first and second line due to wrapping? Chrome uses two different sets of values for the same span, which doesn't look the spirit of the css-cascade spec to me

Well, Firefox and Edge do the same for color:

And it's OK, because being able to do this is the only point in having ::first-line pseudo-elements, isn't it? The problem is that Chrome does it for border, and Firefox and Edge don't do it for background.

If it's not supposed to be like this, the spec needs to be clarified.

Nah you didn't get it :) The color of the span inherits from the div, always. The fact Chrome does not do that is a violation of css-cascade. The existence of pseudo elements doesn't change the style of normal elements. The style of elements is computed before layout.

The reason the text is red is that the color of the text is not the color of the span (if you execute the line of javascript I provided, you will be able to confirm that color is blue) but, insead, it is the color of the text run; the text run is not an element and is created based on styling information during layout; its style thus may depend on the ::first-line style, but that is a totally different thing than to say the span inherits from ::first-line.

I should never do, for no property. Neither color, nor background, nor border. At least that is my understanding of it.

Thanks for the clarifications. Now I will try to be more precise.

Suppose we have

<div>
  <span>ABCDEFGHIJKLMNOPQR<br />STUVWXYZ</span>
</div>

If I understand properly, I think you say it becomes somewhat like this:

<div>
  <span>
    <div::first-line>ABCDEFGHIJKLMNOPQR<br /></div::first-line>
    STUVWXYZ
  </span>
</div>

(not sure where to put the <br />, but that's not relevant)

Then I agree that using inherit on the span just makes it inherit from the div, but that can be overridden by div::first-line on the text run in the first line.

However, it doesn't seem to be the case. Try

div {
  color: red;
}
span {
  color: green;
}
div::first-line {
  color: blue;
}

All Firefox, Edge and Chrome paint the text with green color, even the text run in the first line. This means the span is farther inward than div::first-line, so the latter cannot override the former.

Moreover, Finding the First Formatted Line says

A user agent must act as if the fictional start tags of a ::first-line pseudo-element were nested just inside the innermost enclosing block-level element.

The span is not block-level, so I think the tree should instead become like this:

<div>
  <div::first-line>
    <span::fragment-1>ABCDEFGHIJKLMNOPQR<br /></span::fragment-1>
  </div::first-line>
  <span::fragment-2>STUVWXYZ</span::fragment-2>
</div>

And then, according to Inheritance and the ::first-line Pseudo-element,

the portion of a child element that occurs on the first line only inherits properties applicable to the ::first-line pseudo-element from the ::first-line pseudo-element.

Now this portion in the first line is not only a text run, but a fragment of the span. So that fragment span::part-1 should inherit from div::first-line. The other fragments of the span shouldn't.

Maybe I'm being obtuse, but I don't find the spec much clear, and implementations don't match, so I think the spec should be clarified.

Nope, I didn't say the first-line pseudo element is moved inside the span; technically we do no even have any ::first-line box in our browser (the only caveat being the background which is drawn as part of a special logic).

What I said is that in Edge/Firefox only the text runs' styles are computed based on the style of the ::first-line pseudo-element of the parent block. I meant to say that "only the style of elements that are generated during layout can depend on the style of pseudo-elements, and the span is not such a thing".

I hadn't considered however the possibility of saying the span had fragments, which themselves are layout constructs and could inherit from the first-line pseudo at run-time... In that case I can see how you would expect background to inherit. Looking at our code, this is what we actually do, so I guess our behavior needs some more explanation than just "only layout constructs can have weird styles"...

The correct explaination is that in Edge (and apparently Firefox too) we have this concept of render style which applies to text only, and which is the mechanism we use to transfer ::first-line styles vs other styles. That is why background does not inherit from the ::first-line even though it can be defined on the ::first-line: because it is not a text property (we do have a character-level background for selections etc, but this is another, internal-only property).

The fact Chrome inherits the border is a bug though. Like the spec mentions, only properties that apply on the first line are supposed to propagate to the layout-generated boxes. Maybe to match Edge and Firefox we should update the spec and create the concept of "text styles" and specify that only "text styles properties" inherit from ::first-line to its content.

Thanks, this clarifies the problem.

My interpretation of ::first-line was based on the examples in The ::first-line pseudo-element. But if browsers implement ::first-line using other machanisms which are not equivalent, they should either change to reflect the spec or standardize the other behavior.

Where should the "text styles" be specced? css-pseudo, css-cascade, css-text? I guess the editor of the appropriate spec should be notified about this problem.

I think we would want someone from Chrome to tell their opinion on this issue. I had a quick look and I don't see this concept at all in Webkit/Blink so maybe we should just say all properties applicable to ::firstline (except background?) should inherit and file the relevant bugs in browsers.

Another interesting test case is https://jsfiddle.net/bdxbptz4/ (currentColor is still resolved during computation in Edge which may explain our behaviour here).

cc @tabatkins @kojiishi

I have been thinking and inheritance from ::first-line for non-inherited properties is so problematic.

Suppose someone has this code, without any explicit ::first-line.

<div>
  <span>ABCDEFGHIJKLMNOPQR<br />STUVWXYZ</span>
</div>

div {
  background: linear-gradient(to right, cyan, yellow 75%, red);
  width: 300px;
}
span {
  background: inherit;
  -webkit-box-decoration-break: clone;
  box-decoration-break: clone;
  border: 1px solid blue;
  line-height: 1.5em;
}

Then I think most people would expect this

However, if the fragment of the span in the first line inherits the default background: transparent from div::first-line, then it should be

This seems undesirable, and I see three ways to fix it:

1. In a hacky way, like Chrome currently does. Chrome seems to enable the ::first-line pseudo-element only when it has some valid declaration, whether it applies or not. If ::first-line is enabled, inheritance is from ::first-line, otherwise it's from the parent element.

   Changing the inheritance like this seems problematic. I just checked and asynchronously adding a new stylesheet with some ::first-line declaration does not immediately trigger a background repaint.

2. Say that inheritance is always from the parent element for non-inherited properties of the children of ::first-line, even for properties which apply to ::first-line. (For inherited properties which apply to ::first-line, inheritance is from ::first-line).

   This is what Firefox and Edge seem to do, and even Chrome for some properties like text-decoration.

3. Say that inheritance is from ::first-line for properties that apply to ::first-line, but that the inherit keyword in a child always retrieves the computed value of the parent element, even if the inherited value comes from a pseudo-element.

Currently I don't see any approach to avoid this problem in the specs, I think the csswg should choose some and update the specs.

Sound like we have a good call to resolution here. Let's wait another week to allow @tabatkins to come back from vacation, but then we should just add the Agenda+ tag and resolve on call.

@fantasai Thanks for the label, but precisely ::first-line is not defined in selectors-4. The labels should be css-cascade-4, css-pseudo-4 and, if any, selectors-3. But now I see selectors-3 is very old so I will remove selectors from the title.

@tabatkins I think you came back from vacation, what do you think about this issue?

@FremyCompany It seems @tabatkins does not see the notifications. If you still think this needs Agenda+, maybe you can add it yourself?

By the way, about what you noticed in #1097 (comment), it gets more interesting with CSS variables.

For example, Firefox allows different inline boxes of the same element to have different paddings and margins. https://jsfiddle.net/bdxbptz4/1/

div::first-line { --padd: 0 30px }
span { padding: var(--padd) }

Of course, this does not work with display or float. Chrome does not allow this with padding, but still does with things like color, border, letter-spacing, text-decoration, etc. Edge seems like Chrome except border.

The css variables one is a good point. It is never mentioned anywhere they should work on ::first-line but I guess authors would expect so. How that then affects inheritance is a totally undefined territory. Added Agenda+ so we can discuss this on the call this week or next week.

It's... not undefined? Text nodes can inherit from the ::first-line pseudo, but you can't specify a variable for them (they only get values from inheritance, and variables are resolved before inheriting). Nothing else inherits from a pseudo-element.

That was my expectation as well but actually it looks like not only text nodes inherit from ::first-line, but apparently any inline as well. We have special code to make this work.

You probably have a better idea of what the spec says than me, what do you think is the behavior you expect for http://wptest.center/#/sjfma2 ?

div { 
	width: 75px; 
	--text-color: green;
}
div::first-line {
	--text-color: red;
	color: var(--text-color);
}
span {
	color: inherit;
	background: currentColor;
	outline: 3px solid var(--text-color);
}

Three browsers yield three different results here:

Edge, Chrome, Firefox

PS: To understand Edge's behavior you might want to know we have known issue where element::pseudo { property: var(--x) } also leaks as element { property: var(--x) } as well. That is why the second line of text is green in Edge. You can disregard that bug in the analysis.

My reading of this is that if Edge fixed the others (unrelated) bugs we have, we would behave as Chrome in this case. My reading of the spec is that the spec says we should behave as Firefox. if --text-color:red applies on ::first-line (it obviously does) then --text-color of the span should be taken from the first line like color does.

The proposed resolution here was to say that only properties that applies on ::first-line and inherit by default should be transferred, which would still include custom properties like Firefox is doing.

The reason it doesn't work that way in Edge is that custom properties are not part of the Render Styles, but there is no such "render-style" concept in CSS right now. Chrome is obviously inheriting anything from ::first-line, except for some reason custom properties, so that is not consistent.

To understand Edge's behavior you might want to know we have known issue

Then just add div { color: black !important }.

Edge, Chrome, Firefox

Ahaha that's a good workaround indeed :)

The currentColor difference from Chrome comes from the fact we still resolve currentColor at computation time, which means that once we reapply the styles later on for ::first-line fragments currentColor has already been flattened to "black"; if we didn't have this other bug we would match Chrome here, like I mentioned earlier.

At first sight, Firefox seems the most flexible and useful. But ::first-line is enough problematic by itself to add CSS variables into the mix.

I was testing, and setting display: none via a CSS variable in ::first-line can create a shrink-to-fit block (bug 8858465), but then, removing the variable and readding it with JS, does hide the element. It's also easy to produce a crash (bug 1356601). Things like this happen because ::first-line depends on the box tree, the box tree depends on the display values, and display depends on ::first-line via CSS variables.

So I think it would be better to say CSS variables do not apply to ::first-line, and fragments inside ::first-line inherit CSS variables through the element tree, ignoring ::first-line.

Alternatively, CSS variables could have two values: one inherited through the element tree, and other taking ::first-line into account. Properties which affect the box tree (display, float, position, content, ...) would see the value inherited through the element tree. This would allow to construct the box tree with the ::first-line. Properties which don't affect the box tree would see the value inherited taking ::first-line into account. Dynamically updating a properties which affects the box tree would still read the value inherited through the element tree, otherwise it's nonsense.

But this approach can be problematic, e.g. if a new feature allows an old property to affect the box tree. And given the great amount of bugs related to ::first-line despite being an old pseudo-element, I'm reticent to think this can end up working properly. For implementators, it's probably not worth the effort.

So despite CSS variables applying to ::first-line in all major implementations, I think this should change.

The way this work in Edge, only render styles should be affectable by the ::first-line cascading pass. Render styles can cause layout differences but should never cause box or layer differences. If we were to allow to reset all properties this could indeed be total chaos.

I don't disagree the simplest option is to make sure custom properties never propagate from ::first-line to the elements that are considered in it. That is a complete protection that seems fail-proof; relying on a careful distinction between property sets is less bug-proof.

So, that would leave us with ::first-line being used, if needed, as inheriting source for properties that both inherit by default, are not custom properties, and also apply to ::first-line. I don't see a good reason not to allow to redefine a custom property on ::first-line for usage directly in ::first-line itself.

I haven't read the entire (long!) thread, but I'd note one special Gecko (Firefox) behavior: for ::first-line (specifically -- not other pseudos), properties that don't inherit by default ('Inherited: no') have different inheritance behavior: explicit inherit values on such properties don't inherit from a ::first-line pseudo-element. This is different from the behavior of inherited properties. This behavior comes from bug 395623 and bug 460664, and is apparently based on an old proposal from Ian Hickson.

@dbaron Thanks, this matches observations and I think makes more sense than what the spec says. You are right this thread has become so long, so I will try to summarize it.

TL;DR

Inheritance from ::first-line is not interoperable. Points that should be taken into account:

• Reasonable behavior: If an author doesn't use ::first-line, inheritance should be as if that pseudo-element had never existed.
• The problem is basically with non-inherited properties set to the inherit keyword, which would inherit the initial value from ::first-line instead of from the parent element.
  Possible solutions: (1) non-inherited properties don't inherit from ::first-line; or (2) inherit retrieves the value from parent element even if inheritance is from pseudo-element; or (3) ::first-line only changes inheritance when used in the stylesheet. Details in [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment)
• Inherited properties can inherit from ::first-line without that problem. But CSS variables should be somehow restricted, otherwise ::first-line could alter the value of a variable that is used in a property which affects the box tree, which can affect ::first-line.
  Possible solution: don't allow CSS variables to be inherited from ::first-line. Details in [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment), [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment), [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment)
• Currently the spec says that inheritance from ::first-line is determined by whether the property applies to ::first-line. Probably non-inherited properties should be excluded. Maybe non-applying inherited properties could be included.
• color is inherited from ::first-line, this affects the currentColor. Should other properties (which possibly don't apply to and/or don't inherit from ::first-line) reflect that change? Unlike CSS Variables, this seems harmless.
• Important testcase. Details in [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment), [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment), [css-cascade][css-pseudo] How does 'inherit' keyword behave in a child of ::first-line? #1097 (comment)

The CSS Working Group just discussed How does 'inherit' keyword behave in a child of ::first-line?.

I wanted to note there is a TLDR just above but if I have to summarize even more, the proposed resolution for next week is:

Inheriting properties of inline fragments that are contained in a ::first-line only inherit from the ::first-line if those properties (1) do apply to ::first-line, (2) do inherit by default, and (3) are not custom properties.

Rationale is:

• If the property should not apply on ::first-line, it should not inherit from it. Example: border-width
• If the property does not inherit by default, like background, inheriting from ::first-line would be inconsistent because ::first-line is not always created; inherited properties do not have this problem because if they are not defined in ::first-line, they inherit from the parent containing block so only explictly author-defined declaration can change things
• Inheriting custom properties, even though they fit both previous conditions, would result in intractable problems. For instance, if the span is display:var(--my-display) and --my-display changes in the first-line, the element could disappear or become a block, and stop to be part of the first line. Just disallowing custom properties to inherit solves that problem. We could also create rules but I'd rather keep it simple.

The CSS Working Group just discussed How does 'inherit' keyword behave in a child of ::first-line?.

@astearns Why did you remove the Agenda+ tag? Didn't you say that the CSSWG would resolve this week?

Still waiting on a response from @dbaron or others here

I'm fine with @FremyCompany's proposed resolution above:

Inheriting properties of inline fragments that are contained in a ::first-line only inherit from the ::first-line if those properties (1) do apply to ::first-line, (2) do inherit by default, and (3) are not custom properties.

I would note one issue, though. It's not clear to me that condition (1) is even needed. In most cases, an "Applies to:" line doesn't affect computed values, but I've always had the understanding that pseudo-element restrictions worked differently, and a property that doesn't apply to that pseudo-element doesn't change their computed values. I'm not sure if there's a spec that backs up that interpretation, though. And I don't think it hurts to include condition (1), except that it makes that interpretation of how application to pseudo-elements works a little bit more of a stretch since it wouldn't be needed if that interpretation were correct.

I would note one issue, though. It's not clear to me that condition (1) is even needed

I think the important point is that there can be some property which potentially affects the box tree and which inherits by default. This property shouldn't be inherited from ::first-line, because ::first-line depends on the box tree.

With condition (1) this is easy to solve: simply don't include that property in the list of properties that apply to ::first-line.

Without (1), maybe try not to create such a property (make it non-inheritable by default), or otherwise exclude it specifically just like custom properties in (3). This approach seems harder to maintain (in fact, are custom properties the only existing case of such a property? I'm not entirely sure.)

My point was that condition (1) might not be needed because it's already implied by something (that should be) elsewhere in the spec that's more general, not because the concept isn't needed. And that explicitly including it might add confusion about the general point.

The CSS Working Group just discussed How does 'inherit' keyword behave in a child of ::first-line?, and agreed to the following resolutions:

• RESOLVED: Take hte behavior described in the issue and work witht o to make sure it works for compat.

@FremyCompany @Loirooriol Edited in the changes. Specifically excluded writing-mode, direction, and text-orientation as the first two were noted to be problematic in the CSSWG discussion, and all three are dependencies of the physical-logical cascade. Lmk if this seems acceptable. We can add more properties to the exclusion list as needed.

(Technically, I think we could have text-orientation apply to ::first-letter while excluding it from inheritance, which is where it actually causes a problem, but I figured keeping the two lists consistent would be better.)

any other properties defined to apply to ''::first-line''
by their respective specifications

shouldn't that be "any other property" (singular)?

User agents may apply other properties as well (...)

Why still may? Wasn't the purpose of this to standardize a behavior? I have a feeling the list noted above should be exhaustive already (and if it is not, that's worth investigating and fixing).

(...)

Other than that, sounds to be what was resolved last time, and LGTM.

That said, I don't have insights into how this particular bit is currently implemented in Blink and Gecko so I can't provide more value than an informed opinion ;)

Yes, the edit seems according to the resolution and LGTM. What I don't really like is that inheriting from ::first-line means that we have inheritance in the fragment tree, but usually inheritance is in the element tree. So interaction between display: contents and ::first-line is not clear. But that's #1310

shouldn't that be "any other property" (singular)?

Could go either way, I think.

Why still may? Wasn't the purpose of this to standardize a behavior?

Afaict this issue is about standardizing the behavior of what inherits and how, and not about standardizing which properties apply to ::first-line; and there was no serious discussion or conclusion on exactly which properties apply to ::first-line or don't. It's one of the reasons why we didn't want to make the inheritance behavior depend on that.