[css-inline][css-text][css-pseudo] Define more details of the "first formatted line"

[kojiishi]

Discussing on wpt tests for text-box-trim with @fantasai raised questions about the first formatted line.

Currently, the ::first-line pseudo-element and the text-indent property use this definition.

This test@jsbin indicates that browsers use different criteria for the "first formatted line".

Test		Gecko	WebKit	Blink
Content in a nested div	text-indent	Yes	Yes	Yes
	::first-line	No	Yes	Yes
An empty div before content	text-indent	No	No	No
	::first-line	No	No	No
An empty div before nested content	text-indent	Yes	Yes	Yes
	::first-line	No	No	No
An empty div with an empty line before nested content	text-indent	Yes	Yes	Yes
	::first-line	No	No	No
An empty anonymous block with an empty line before nested content	text-indent	Yes	Yes	Yes
	::first-line	No	Yes	No

Can we define the desired behavior for these cases?

@fantasai @nt1m @vitorroriz @Clqsin45 @bfgeek @lilles @jfkthame

[fantasai]

Note that for text-indent, the property is inherited, and the value applying to a given line is the value specified by its containing block. The spec's reference to "first formatted line" is to say that, among the lines to which it applies, first-line behavior only applies to lines that are also the first formatted line of an element (not an anonymous block).

For ::first-line and nested content (testcase) this seems like a very clear Gecko bug. The specs have been very clear about this since CSS2 and there were tests although it seems Gecko never passed them.

For ::first-line and "empty anonymous block before nested content"; that anonymous block isn't empty (or else it wouldn't exist); but since it contains only an empty unstyled inline, the phantom line box clause applies. See CSS2 and CSS Inline Layout L3.

I think the specs are clear here, but lmk if anything seems wrong.

[kojiishi]

(Sorry I misunderstood parts of your reply, so rewriting)

I think my question is primarily on what an empty block should do.

According to your changes to wpt and your reply, text-box-trim-half-leading-block-box-003.html should propagate:

<div class="div-parent">
  <span>    </span>
  <div>Testline1</div>

because it has an anonymous block, but the block has an empty line, and the existence of the anonymous block box doesn't matter? WebKit propagates, while Blink/Gecko don't.

In text-box-trim-half-leading-block-box-001.html:

<div class="div-parent">
  <div></div>
  <div>Testline1</div>

It has a block without an empty line. In this case, the block box matters even without a line, it should block the propagation?

Added another test:

<div class="div-parent">
  <div><span></span></div>
  <div>Testline1</div>

All browsers treat this the same as <div></div> (blocks the first line). Should this propagate or block?

If the answer is "propagate", I think the spec means "an empty block should block the propagation, but if it has an empty line, it should propagate". If the answer is "block", I think the spec means "an anonymous block should be ignored for this purpose".

[Loirooriol]

Firefox not propagating ::first-line to nested blocks is https://bugzilla.mozilla.org/show_bug.cgi?id=317081

[bfgeek]

Blink I think currently has issues with ::first-line propagating into elements which establish independent formatting contexts, when arguably it shouldn't, when I last read the spec here somewhat questionable.

E.g.
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13169

[Loirooriol]

@bfgeek CSS2 didn't prevent propagating ::first-line to nested blocks with overflow: hidden, so it should be the same for display: flow-root.

That said, Firefox never propagating it can mean that it's web-compatible to change the behavior, it may make more sense indeed to only propagate within the same BFC, and this would be consistent with not propagating it to table captions (see #1192).

[kojiishi]

Blink I think currently has issues with ::first-line propagating into elements which establish independent formatting contexts, when arguably it shouldn't, when I last read the spec here somewhat questionable.

E.g. https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13169

Thank you, this is another interesting incompatibility, WebKit blocks the propagation. So two questions we found so far?

1. Should an empty block (anonymous/non-anonymous, with/without an empty line) propagate or block?
2. Should it propagate into a different BFC or not?

[kojiishi]

2. Should it propagate into a different BFC or not?

#8842 looks related with this.

[fantasai]

Chatting with @jensimmons, she pointed out we need to make sure that out-of-flow elements (including floats) are ignored.

[kojiishi]

The question 2 (BFC) is split into #11038.