(not confirmed yet as I don't have the feature turned on)

I just noticed that on Firefox it's green just by chance, they don't implement it correctly neither.

The behaviour that I see in canary, and also in stable looks correct.  I see all green text for the example given (green text for first and subsequent lines).

I have created my own example at https://jsfiddle.net/zu97h64r/3/.  Screenshot attached.  It has 3 different versions with nesting the text:

1/ div > text
2/ div > p > text
3/ div > span > text

It looks to me that all are behaving as per spec "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."

1/ Innermost enclosing block-level element is div.  Fictional tag sequence:

<div><div::first-line>first line</div::first-line>rest of text</div>

Expect first line to be red, other text blue.  Result: Correct

2/ Innermost enclosing block-level element is p.  Fictional tag sequence:

<div><p><div::first-line><p::first-line>first line</p::first-line></div::first-line>rest of text</p></div>

Expect first line to be red, other text pink.  Result: Correct.
Note that firefox is different here and has all text pink.  I believe that firefox is incorrect.  The spec spells out this exact example of div with nested p.  The div::first-line styling should apply to first line of text in p unless overridden by p::first-line.  I have also verified that chrome does use p::first-line to override div::first-line if provided.

3/ Innermost enclosing block-level element is div.  Fictional tag sequence:

<div><div::first-line></div::first-line><span>first line rest of text</span></div>

Expect first line to be green, other text also green.  Result: Correct

Deleted: first-line.png 90.3 KB

	first-line.png 90.3 KB View Download

Sorry, in my previous comments, I wasn't considering the span with display:contents.  I needed to turn that flag on at chrome://flags for  #enable-experimental-web-platform-features.  I have now updated my jsfiddle.  I now see red for first line, green for subsequent lines for display:contents.  I believe that this is still operating as specified.

https://jsfiddle.net/zu97h64r/4/

4/ div > span (display:contents) > text

Innermost enclosing block-level element is div.  Fictional tag sequence:

<div><div::first-line>first line rest of text</div::first-line></div>

My reading of the spec for display:contents https://drafts.csswg.org/css-display/#the-display-properties is that the span tag is replaced by its contents "element replaced by contents in box tree".  So when the fictional tag sequence is generated, the span is not included.

So it makes sense to me that the first line of text becomes red since the div::first-line applies to it.  I'm not so sure about subsequent lines.  They are showing as green, which implies that the styling of the span is still applying to them, even though the span tag is removed.  This seems reasonable. 

Expect first line to be red, other text green.  Result: Correct

Yes, the span is not included. But display:contents does not affect inheritance, so despite the fact that the span generates no box, the color is still inherited by the inner text.

For example, here the span alters the color despite display:contents

  div { color: red }
  span { display: contents; color: green }
  <div><span>I am green. Correct</span></div>

And non-block-level elements are inside ::first-line

  div::first-line { color: red }
  span { color: green }
  <div><span>I am green. Correct</span></div>

So here the span, which is non-block-level, should be inside the ::first-line, and still be able to alter the color despite display:contents

  div::first-line { color: red }
  span { display: contents; color: green }
  <div><span>I should be green, but I am red. Incorrect</span></div>

Maybe this example is more obvious:

  div::first-line { color: red }
  i, b { color: green }
  b { display: contents }
  <div><i>Foo</i><b>Bar</b><i>Baz</i></div>

All Foo, Bar and Baz are inline content in the first line, but only Foo and Baz are green. Bar is red!

In fact the title of this issue is inaccurate. It's more that styles of elements with display:contents are ignored inside ::first-line.

Just compare these:

  span { display: contents; color: green; }
  <div><span>I am green. Correct</span></div>

  div::first-line { --hello: world } /* Some random property to enable ::first-line */
  span { display: contents; color: green; }
  <div><span>I should be green but I am not. Incorrect</span></div>

I'm not sure I understand the spec well enough to make a call whether this is correct or not. ecobos@/tabatkins@, could you PTAL?

I made a clicky version of the above examples here https://jsfiddle.net/x4ee21x2/1/

Can someone tell me how I can edit the title of the issue, or edit it for me?

It should be something like "Styles of elements with display:contents are ignored inside ::first-line".

Changed the title. I believe this is a Blink bug fwiw, thought I might not be the best at spec-reading.

The first-line code is overly complicated IMO, but I'll take a look, thanks for reporting this Oriol :)

FWIW doing the obvious thing with ::first-line fixes this, as expected. I expect that <https://codereview.chromium.org/2787123007/patch/1/10002> will break a bunch of other stuff though.

I can't say I understand everything firstLineStyleForCachedUncachedType is trying to do TBH, hopefully that'll help me figure out what that code is trying to acomplish.

PS: It's just a quick try to see what may be affected by it, so sorry for it being on top of other pre-existing patch.

See https://bugzilla.mozilla.org/show_bug.cgi?id=1305951 for a related Gecko bug where they always ignore the first-line style for display: contents elements.

I had locally a patch that made us align with this, but this is also incorrect. I'll need a bit more time to think about it.

I believe the way to fix properly this is moving ::first-line handling to use the content tree, which might be quite a rewrite.

I can work on it, but I can't promise I'll be able to prioritize it given the complexity involved with it and that this is also broken in other browsers.

oof, that's annoying. Let me know if you get to it, otherwise I'll just put it on our backlog of stuff to do.

As per comment #14 removing Needs-Triage-M59 label

Thanks.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/deecb9f7221a5d9797cee690b9a886dd7acc3d31

commit deecb9f7221a5d9797cee690b9a886dd7acc3d31
Author: Rune Lillesveen <futhark@chromium.org>
Date: Thu Nov 30 01:10:42 2017

Test display:contents overriding ::first-line.

Bug:  706316 
Change-Id: I91f0da5d21eb8a68e05dca84caf5e99305cd3fa6
Reviewed-on: https://chromium-review.googlesource.com/798410
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Darren Shen <shend@chromium.org>
Cr-Commit-Position: refs/heads/master@{#520364}
[modify] https://crrev.com/deecb9f7221a5d9797cee690b9a886dd7acc3d31/third_party/WebKit/LayoutTests/TestExpectations
[add] https://crrev.com/deecb9f7221a5d9797cee690b9a886dd7acc3d31/third_party/WebKit/LayoutTests/external/wpt/css/css-display/display-contents-first-line-002.html

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fc5c3629044888b8d723cc11424879bb883d8d3e

commit fc5c3629044888b8d723cc11424879bb883d8d3e
Author: Rune Lillesveen <futhark@chromium.org>
Date: Tue Dec 05 12:13:10 2017

Wrap text child of display:contents in anonymous if necessary.

A text node gets its style from its flat tree parent. The problem is
that our layout code expects the LayoutObject parent to have the same
inherited styles as the text node. That is not the case if a text node
has display:contents ancestors and the display:contents parent does not
have the same inherited styles as the closest ancestor generating a box.

Example:

  <div>
    <div style="display:contents;font-size:50px">Text</div>
  </div>

We're solving this by inserting an anonymous inline between the
LayoutText and its parent LayoutObject. We do not try to merge inline
wrappers for subsequent text nodes, so for:

  <div style="display:contents:color:pink">A<!-- -->B</div>

we create one wrapper for each of A and B, even though one would
suffice.

We attach and detach these wrappers on-demand, so if, for instance, the
inherited computed styles of the display:contents change so that it
matches the computed styles of the LayoutObject parent, we detach the
wrapper as it's no longer needed.

We also currently detach the wrapper when the computed style of the
display:contents and hence the computed style of the wrapper changes. We
could have optimized this through more checking and SetStyle on the
anonymous wrapper.

Bug:  717460 ,  706316 ,  709808 ,  713019 
Change-Id: Ia53b9fe2c0a6067c4600dab49cdf43f23b95b8fa
Tests: see removed lines from TestExpectations.
Reviewed-on: https://chromium-review.googlesource.com/806158
Commit-Queue: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Robert Hogan <robhogan@gmail.com>
Reviewed-by: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#521673}
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/LayoutTests/TestExpectations
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/dom/LayoutTreeBuilder.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/dom/LayoutTreeBuilder.h
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/dom/Text.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/layout/LayoutBlock.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/layout/LayoutInline.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/layout/LayoutObjectTest.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/style/ComputedStyle.cpp
[modify] https://crrev.com/fc5c3629044888b8d723cc11424879bb883d8d3e/third_party/WebKit/Source/core/style/ComputedStyle.h