-
Notifications
You must be signed in to change notification settings - Fork 715
[cssom-view][css-text][css-break] Clarify Element.getClientRects #1545
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Is this not defined by https://drafts.csswg.org/css-text/#line-break-transform ? |
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? |
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? |
cc @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. |
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. |
@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? |
The current spec looks fine to me, I think the spec evolved since last time I read, or I misunderstood before. Thanks for checking and sorry for the noise. |
I suppose 7f6b964#diff-83c5030d93d2408c7cf139946d26016e might have helped :) Closing out. |
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 -
Would return a list of two items, while -
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.The text was updated successfully, but these errors were encountered: