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

The CSS Working Group just discussed `[cssom-view] Let offsetWidth / offsetHeight report actual size?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [cssom-view] Let offsetWidth / offsetHeight report actual size?<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/4541<br>
&lt;dael> TabAtkins: I'm confused on this issue. Thanks for digging up issues fantasai . According to the eample script and I verified Chrome. FF it repots offset of A is 40x40 but that's the div child. Chrome doesn't. It has 2 boxes surrounding hte div and b/c whitespace is collapsed the boxes are 0x0.<br>
&lt;dael> TabAtkins: Haven't done spec diving to see if it allows A to report div as size. I think Chrome and Wk is correct here and we close no change<br>
&lt;dael> AmeliaBR: Do you have link to spec that says block inside inline isn't counted as part of inline dimensions<br>
&lt;dael> TabAtkins: Yu return size of first layout box. A element starts with inline that has whtiespace only<br>
&lt;dael> AmeliaBR: Entire A includes div but there's a 0 width<br>
&lt;dael> TabAtkins: Not quite. In box tree div is not child of A. A produces 2 siblings but they're children of A parent.<br>
&lt;astearns> spec link: https://drafts.csswg.org/cssom-view-1/#extensions-to-the-htmlelement-interface<br>
&lt;dael> dbaron: I think there are multi explinations for difference and worth checking which. Possible it's due to FF treating block as inside the inline. Another poss if difference if there's a box generated for that little piece or not<br>
&lt;dael> TabAtkins: Yeah, and couldn't tell that without diving more<br>
&lt;dael> dbaron: Could check if there's a difference if you put the letter in there<br>
&lt;dael> TabAtkins: Yeah.<br>
&lt;dael> TabAtkins: Letter in there still considers div part of A but the height is a little higher<br>
&lt;dael> TabAtkins: FF makes height a littler higher. In Chrome it's still 0x0. Appears consistent. Chrome generates the empty box, FF considers it a part<br>
&lt;dael> dbaron: Not sure how it's higher b/c not sure what box it's dealing with<br>
&lt;dael> astearns: Seems like nice to be consistent here<br>
&lt;dael> dbaron: Nevermind.<br>
&lt;TabAtkins> With &lt;a>foo&lt;div>&lt;/div>&lt;/a>, you get a "foo" with the box below it, so the height grows in Firefox.<br>
&lt;dael> dbaron: Code for getOffsetRect does go through all fragments<br>
&lt;dael> TabAtkins: Rather then get first?<br>
&lt;dael> dbaron: Yeah. At least Geck code goes through all<br>
&lt;dael> TabAtkins: Sounds like Chrome doesn't<br>
&lt;dael> dbaron: Maybe diff is do you go through all fragments<br>
&lt;dael> AmeliaBR: Ran quick test using issue example + character before div and that way we can tell if it's about collapsing whitespace and in that case if there's a character FF gives width of div when giving offset of A element. It's not the first inline, but entire thing. Chrome gives size of first inline<br>
&lt;dael> dbaron: Another test is letter before and after div<br>
&lt;TabAtkins> before and after: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/7825 Chrome still reports the height of just one line, so it's not iterating all the fragments<br>
&lt;dael> florian: Another thing confusing is Chrome behavior which is simple about first. For FF with most all frag are next to in this case. But it's not clear all fragments will be next to each other. If it's multi-col they're not adjacent.<br>
&lt;dael> dbaron: I think ti's smallest rect that encloses all<br>
&lt;dael> florian: So multi-col you get unrelated stuff, but when printing?<br>
&lt;dael> dbaron: API doesn't work in printing. DOn't have access<br>
&lt;dael> iank_: I think we had this convo with client height in multi-col. Two things you can do, union of all clients or stack them all. Impl stack. CSS Regions make it funky. Need to be consistent.<br>
&lt;dael> emilio: Chrome does take height in getBoundingClientRect<br>
&lt;dael> TabAtkins: It should b/c div height influences boundary. But this is just client rect<br>
&lt;dael> florian: Not working in printing, saying when we print there is no script so it's not there? B/c that's not true. THing that renders to PDF runs scripts so you can ask this question in an engine that's fragmenting to multiple pieces not next ot each other. Easy for Chrome example, not sure what it does if try and stick together<br>
&lt;dael> astearns: Top of hour. I think way forward is write test cases and then come to agreement what success for those cases should be and get that into spec<br>
&lt;florian> s/THing/UAs/<br>
&lt;dael> astearns: Sound okay to everyone?<br>
&lt;dael> florian: I would suggest including something like Prince in test cases to get an engine that prints and runs scripts<br>
&lt;TabAtkins> As far as I can tell, the test cases are all consistently showing that Chrome returns the dimensions of the first fragment, and Firefox gives a bounding rect of all the fragments (including the blocks splitting the inline).<br>
&lt;dael> astearns: Fair enough.<br>
</details>


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

Received on Wednesday, 18 March 2020 17:01:20 UTC