Re: [csswg-drafts] [cssom-view] Let offsetWidth / offsetHeight report actual size? (#4541)

> I haven't tested across multicols, but I think interop is spotty there anyway, so I'm not sure how useful such a test would be, considering we already see the break in these tests.

Here's how I view it: If we go with chrome's behavior, how this behaves in multicol or paged scenario is not interesting, because it is sufficiently well defined: as you go with the first piece of element, and it's not terribly interesting to know what happens to the other ones, since they're not considered.

If we are inclined to go with the firefox behavior, it becomes essential: as soon as you say you have to take into account all the pieces, you have to say what that means, and it is not trivial in all cases. Testing gives part of the answer here, as browsers that have this behavior must already have some answer to that question, but that does not necessarily mean it's the right answer.

Maybe I'm missing something, but I see 3 different kinds of situation where this question is interesting, and may lead to different answers:
1. the inline-broken-by-a-block situation: there are multiple pieces, but they're all adjacent to each other
2. the multicol situation (also true for something like regions): there are multiple pieces, and they're not (necessarily) adjacent to each other, but they're all in the same coordinate space
3. the paged media situation: there are multiple pieces, and not only are they not (necessarily) adjacent to each other, they're not even in the same coordinate space

Some answers to "how do you account for multiple pieces" work in all of these situations, some don't. Some are more useful than others.

a. **measure the first one only** (Chrome behavior):<br>This gives an easy and well defined answer in all situations. Whether that answer is useful is questionable.
  
b. **use the maximum inline size, and the sum of the block sizes**:<br>Would give the expected answer in the inline-broken-by-a-block situation, and a similarly easy to compute answer in all other situations. Whether the answer in the other situations is useful or not is debatable, and probably depends on what you're trying to do.

c. **measure the size of the bounding box of all fragments**:<br>Would give the same answer as (b) in the inline-broken-by-a-block situation, but a different one in the multicol and regions situations. Whether that answer is more useful, and probably depends on what you're trying to do. Notably, this approach does not have a well defined answer in the paginated scenario, as the bounding box of things that are on different pages isn't knowable unless you know where the pages are placed relative to each other, which isn't defined.

d. **measure the size of the bounding box of all the pieces that fit in the first thing-that-establishes-a-coordinate-space (i.e. the first page), ignore the rest**:<br>Same as (c) as long as you don't paginate, closer to (a) (well defined but of questionable usefulness) if you do.

e. ???

My inclination would be to go for a (and to use the same logic for getBoundingClientRect() and any other similar API), and to introduce additional fragment/box aware APIs, for two reasons:
(1) This gives a well defined answer in all cases
(2) Because it gives a fairly unhelpful answer in many situations, It is quickly apparent to authors that if you want a correct answer to your problem, you have to be aware that fragmentation is a thing, use the API that give you access to that, and make a reasoned decision about how you want to handle them based on what you're trying to achieve.

(b) and (d) also satisfy the first criteria, but because they appear to work in more situations (inline-broken-by-a-block for b and d, as well as multicol / regions for d) but not all situations, they trick authors into thinking they got the right tool for the job, while giving broken results in less commonly tested situations, which I think signals a bad and fragile API.

Interestingly, prince, which supports javascript and pagination, does not support offsetWidth/offsetHeight/getBoundingClientRect(), but does have an API that lets you iterate through boxes/fragments/pieces (called `getPrinceBoxes()`).

----

(note: I'm using the word "piece" here, to walk around the fact that it is poorly defined whether we're talking about boxes or fragments here, as mentioned in https://github.com/w3c/csswg-drafts/issues/4541#issuecomment-600759060)



-- 
GitHub Notification of comment by frivoal
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4541#issuecomment-600961655 using your GitHub account

Received on Thursday, 19 March 2020 02:59:03 UTC