[cssom-view] Needs more details for `offsetWidth` and `offsetHeight`

[kojiishi]

The offsetWidth spec:

1. Says "the first CSS layout box" but great if we can define what the "first" means more clearly.
2. Isn't as clear what to do when the width or height is zero as the getBoundingClientRect spec is.

From a few quick testing for an inline box:

• When the inline box is line-fragmented, all 3 impls include all fragments.
• When the inline box contains an in-flow block-level box, Gecko includes it and also inline boxes after the block-level box, while Blink/WebKit ignore them. Blink may try to change this though.
• WebKit includes width of boxes whose height is zero, while Blink/Gecko does not.

[fantasai]

• It should probably be the principal CSS layout box, not the “first” one.
• If all 3 impls include all fragments, then we should update the spec to do so.
• I have no opinion on whether the block-level box should be included, but the fragments after it should be if we're doing any fragments beyond the first at all.

[css-meeting-bot]

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

The full IRC log of that discussion

<dael> Topic: [cssom-view] Needs more details for offsetWidth and offsetHeight
<dael> github: https://github.com//issues/6588
<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
<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
<Rossen_> q?
<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
<dael> fantasai: Handful of small things
<dael> Rossen_: Clarifying question on point about fragmented boxes. Do variable width boxes aggregate the offsetHight differently?
<dbaron> q+ to mention splitting of inline boxes due to bidi reordering
<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?
<dael> fantasai: That's a little beyond what I can answer
<Rossen_> q?
<dael> Rossen_: I think fragmentation case will be difficult
<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
<dael> Rossen_: Good point
<Rossen_> ack dbaron
<Zakim> dbaron, you wanted to mention splitting of inline boxes due to bidi reordering
<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
<dael> Rossen_: Resolve on the easy ones?
<dael> Rossen_: The offsetWidth and Height should be computed out of the principle css box
<dael> Rossen_: Start there?
<dael> fantasai: Sure
<dael> Rossen_: Obj?
<fantasai> s/principle/principal/
<dael> RESOLVED: The offsetWidth and offsetHeight should be computed out of the principle css box
<fantasai> s/principle/principal/
<dael> Rossen_: Fragmentation makes it complicate. For inline case considering all fragments makes sense. Should resolve on that
<dael> Rossen_: Objections?
<dael> RESOLVED: It should include all fragments
<dbaron> I think the hard part of fragmentation is when the inline's containing block is fragmented...
<dael> Rossen_: For the block-level boxes is the previous resolution enough and as we come up with specific cases we can add?
<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.
<dael> fantasai: So do we also consider the block box that's doing the splitting?
<dael> fantasai: As if it's wrapped in a fragment of this element
<dael> fantasai: Or do we ignore
<dael> Rossen_: I don't know. Does anybody?
<TabAtkins> ¯\_(ツ)_/¯
<dael> Rossen_: Perhaps we leave this as an open question and continue on this in issue
<dael> dbaron: Weakly lean toward not including. Very weakly
<dael> fantasai: That's where I'm at. Ask impl if there's an easier way and if there is go with that?
<dael> Rossen_: Let's continue in GH and not force a resolution. we have enough conversation that will go in the issue
<dbaron> s/if there's an easier way/if one way is easier/

[chrishtr]

Agenda+ to propose including the block box that does the splitting: "include the block box doing the splitting, as if it's wrapped in an inline".

The argument in favor of this is that this is how getBoundingClientRect behaves. Example.

[css-meeting-bot]

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

• RESOLVED: When an inline box is split by a block box, offsetWidth and offsetHeight will include dimensions of block box

The full IRC log of that discussion

<dael> Topic: [cssom-view] Needs more details for offsetWidth and offsetHeight
<dael> github: https://github.com//issues/6588
<dael> chrishtr: Discussed Oct 6 and resolved that they should be computed out of principle css box
<dael> chrishtr: If you have an inline split into mult frag with a child that's block shoudl the balance of the block be included
<dael> chrishtr: No strong opinion in discussion. Weak opinion not to, but impl difficulty should be a factor
<dael> chrishtr: Enginers have been trying to simplify code and have found that including it would be simplier to impl and give same answer as getBoundingClientRect. Suggest include block box in the bounds
<dael> astearns: Make sense.
<dael> astearns: Prop: When an inline box is split by a block box, offsetWidth and Height will include dimensions of block box
<dael> astearns: Obj?
<dael> RESOLVED: When an inline box is split by a block box, offsetWidth and offsetHeight will include dimensions of block box

[dholbert]

So to clarify... on the points-of-difference from the initial comment here, I think the resolution is in favor of doing this:

• When the inline box contains an in-flow block-level box, Gecko includes it and also inline boxes after the block-level box, while Blink/WebKit ignore them. Blink may try to change this though.

....and maybe also this:

• WebKit includes width of boxes whose height is zero, while Blink/Gecko does not.

Is that right?

[chrishtr]

Yes. It would be to include the Gecko behavior of your first quoted bullet, and the WebKit behavior of the second.

[dholbert]

Testcase for the first bullet-point (inline box containing an in-flow block-level box):
https://jsfiddle.net/dholbert/dbj3gfsL/

@chrishtr could you (or someone) post a testcase to demonstrate the currently-WebKit-specific behavior that we're aligning with for my second quoted bullet point? I'm not sure I fully understand the scenario there. (I came up with a few examples of what I thought it was discussing, but I couldn't find one where WebKit includes the width where other browsers do not.)