[cssom-view][css-text][css-break] Clarify Element.getClientRects

[phistuck]

https://drafts.csswg.org/cssom-view-1/#dom-element-getclientrects
web-platform-tests/wpt#6264 (comment) added a test that verifies that source lines do not affect the result (well, the number of items in the returned list) of Element.getClientRects().

Originally, the issue from which the test originated is https://crbug.com/167261 -

<span>test
test</span>

Would return a list of two items, while -

<span>test test</span>

Would return a list of a single item.

@kojiishi argues that the specification does not mandate that the rendered lines are to be returned, but box fragments instead (which may translate to source lines, in the first case?).

Source lines are not very helpful to anything in a non-preformatted element. And if it is a preformatted element, the source line would show up as rendered lines.
So I believe the goal of Element.getClientRects is (and the specified goal should be) to disregard source lines.

[zcorpan]

Is this not defined by https://drafts.csswg.org/css-text/#line-break-transform ?

[kojiishi]

Line break transform mandates for rendering, but it doesn't look to prohibit UAs to split inline boxes to me, does it?

But source lines are not really a problem here. We split inline boxes for many reasons, such as bidi reordering. How UA generates inline boxes for line wrapping or forced breaks are not well defined yet, and that the number of DOMRects for Range.getClientRects vary by UA today, AFAIU.

If the number of DOMRects corresponds to the number of box fragments, and if that includes inline boxes, it looks like it's UA dependent, no?

[kojiishi]

BTW, as commented in crbug, our new engine will fix the source lines problem, but my point here is that I think splitting inline boxes is currently UA dependent, no?

[zcorpan]

cc @fantasai

[fantasai]

I don't see any reason why there would be fragmentation of an inline box due to a source line break; that seems really weird to me. Fragmentation is caused by needing to split up the box, e.g. due to splitting across lines or bidi reordering or block-in-inline splits... In some cases you might have adjacent fragments, due to bidi, but there shouldn't be adjacent fragments in the general case. Turning on box-decoration-break: clone would give non-interoperable, random results otherwise.

[kojiishi]

Let me clarify again, source lines is not a problem here. I just meant how inline box tree is split by various factors is not well-defined, and that the test is testing an undefined behavior.

[fantasai]

@kojiishi AFAIK fragmentation only occurs when breaking across fragmentainers like columns/pages/regions/line boxes, for bidi reordering as defined in https://www.w3.org/TR/css-writing-modes-4/#bidi-fragmentation, and when there is a block-in-inline split or multicol-spanner-in-block split.

GetClientRects() should return exactly one rect per fragment, as defined in these cases.

Which specs do you think need clarification here?