Skip to content

[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

Closed
phistuck opened this issue Jun 21, 2017 · 9 comments
Closed

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

phistuck opened this issue Jun 21, 2017 · 9 comments
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-break-3 Current Work cssom-view-1

Comments

@phistuck
Copy link
Contributor

phistuck commented Jun 21, 2017

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
Copy link
Member

zcorpan commented Jun 21, 2017

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

@zcorpan zcorpan added css-text-3 Current Work cssom-view-1 css-break-3 Current Work labels Jun 21, 2017
@zcorpan zcorpan changed the title [cssom-view] Clarify Element.getClientRects [cssom-view][css-text][css-break] Clarify Element.getClientRects Jun 21, 2017
@kojiishi
Copy link
Contributor

kojiishi commented Jun 21, 2017

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
Copy link
Contributor

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
Copy link
Member

zcorpan commented Jun 21, 2017

cc @fantasai

@fantasai
Copy link
Collaborator

fantasai commented Mar 6, 2018

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.

@fantasai fantasai removed the css-text-3 Current Work label Mar 6, 2018
@kojiishi
Copy link
Contributor

kojiishi commented Mar 7, 2018

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
Copy link
Collaborator

fantasai commented Aug 20, 2018

@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?

@kojiishi
Copy link
Contributor

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.

@fantasai
Copy link
Collaborator

fantasai commented Oct 4, 2018

I suppose 7f6b964#diff-83c5030d93d2408c7cf139946d26016e might have helped :) Closing out.

@fantasai fantasai closed this as completed Oct 4, 2018
@fantasai fantasai added Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. and removed Help Wanted labels Oct 4, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Closed Accepted as Editorial Commenter Satisfied Commenter has indicated satisfaction with the resolution / edits. css-break-3 Current Work cssom-view-1
Projects
None yet
Development

No branches or pull requests

5 participants