Re: [csswg-drafts] [cssom-view] Needs more details for `offsetWidth` and `offsetHeight` (#6588)

The CSS Working Group just discussed `[cssom-view] Needs more details for offsetWidth and offsetHeight`, and agreed to the following:

* `RESOLVED: The offsetWidth and offsetHeight should be computed out of the principle css box`
* `RESOLVED: It should include all fragments`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [cssom-view] Needs more details for offsetWidth and offsetHeight<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/6588<br>
&lt;dael> fantasai: koji posted the spec for offsetWidth and Height is not very clear. Says first layout box but that's not clearly defined. Also not clear on 0 values<br>
&lt;dael> fantasai: prop is it should say take principle css layout box. Given impl include fragments we should spec that. If box fragmenets we consider all<br>
&lt;Rossen_> q?<br>
&lt;dael> fantasai: Difference in impl if an inline box is split by block level. Gecko includes both inline fragments and block-level box. Block and WK ignore the block-level box. Definitely should include fragements before and after<br>
&lt;dael> fantasai: Handful of small things<br>
&lt;dael> Rossen_: Clarifying question on point about fragmented boxes. Do variable width boxes aggregate the offsetHight differently?<br>
&lt;dbaron> q+ to mention splitting of inline boxes due to bidi reordering<br>
&lt;dael> Rossen_: If I read the last point about if block-level box should be included. Assuming we do include the fragments after and assuming they are not in the same width fragmentainer, does that have any effect?<br>
&lt;dael> fantasai: That's a little beyond what I can answer<br>
&lt;Rossen_> q?<br>
&lt;dael> Rossen_: I think fragmentation case will be difficult<br>
&lt;dael> dbaron: I wanted to mention another case. Inline boxes can be split due to bidi reordering. Should be handled like linebreaking, but worth explicitly mentioning so it's tested<br>
&lt;dael> Rossen_: Good point<br>
&lt;Rossen_> ack dbaron<br>
&lt;Zakim> dbaron, you wanted to mention splitting of inline boxes due to bidi reordering<br>
&lt;dael> fantasai: Most of this is straight forward. One big question is do we include the block-level box that induces the split or do we only include the fragments in the inline<br>
&lt;dael> Rossen_: Resolve on the easy ones?<br>
&lt;dael> Rossen_: The offsetWidth and Height should be computed out of the principle css box<br>
&lt;dael> Rossen_: Start there?<br>
&lt;dael> fantasai: Sure<br>
&lt;dael> Rossen_: Obj?<br>
&lt;fantasai> s/principle/principal/<br>
&lt;dael> RESOLVED: The offsetWidth and offsetHeight should be computed out of the principle css box<br>
&lt;fantasai> s/principle/principal/<br>
&lt;dael> Rossen_: Fragmentation makes it complicate. For inline case considering all fragments makes sense. Should resolve on that<br>
&lt;dael> Rossen_: Objections?<br>
&lt;dael> RESOLVED: It should include all fragments<br>
&lt;dbaron> I think the hard part of fragmentation is when the inline's containing block is fragmented...<br>
&lt;dael> Rossen_: For the block-level boxes is the previous resolution enough and as we come up with specific cases we can add?<br>
&lt;dael> fantasai: I think it's a very different fragmentation case. Even in a single column if there's an inline box and there's a block box that causes the inline box to split we should handle the inline fragments before and after.<br>
&lt;dael> fantasai: So do we also consider the block box that's doing the splitting?<br>
&lt;dael> fantasai: As if it's wrapped in a fragment of this element<br>
&lt;dael> fantasai: Or do we ignore<br>
&lt;dael> Rossen_: I don't know. Does anybody?<br>
&lt;TabAtkins> ¯\_(ツ)_/¯<br>
&lt;dael> Rossen_: Perhaps we leave this as an open question and continue on this in issue<br>
&lt;dael> dbaron: Weakly lean toward not including. Very weakly<br>
&lt;dael> fantasai: That's where I'm at. Ask impl if there's an easier way and if there is go with that?<br>
&lt;dael> Rossen_: Let's continue in GH and not force a resolution. we have enough conversation that will go in the issue<br>
&lt;dbaron> s/if there's an easier way/if one way is easier/<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6588#issuecomment-937333640 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 7 October 2021 00:00:11 UTC