Re: [csswg-drafts] [cssom-view] No way to access the viewport size without losing precision. (#5260)

The CSS Working Group just discussed `[cssom-view] No way to access the viewport size without losing precision.`, and agreed to the following:

* `RESOLVED: add .width and .height as doubles to the layout viewport interface`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> emilio: we've discussed in the past, making innerWidth and innerHeight not round is not compatible, it breaks things<br>
&lt;TabAtkins> emilio: but we recently decided to add an object to the Window that represents the layout viewport (mainly for segments stuff)<br>
&lt;TabAtkins> emilio: But it sounds like a good place to expose the full double-precision viewport dimensions<br>
&lt;TabAtkins> emilio: So they'll do the same as innerHeight/Width, but without the weird rounding<br>
&lt;flackr> +1<br>
&lt;TabAtkins> emilio: Proposal is to add ... unsure if we decided it to be window.viewport or window.layoutViewport, but whatever, add .width and .height<br>
&lt;TabAtkins> astearns: Idle thought that maybe this should have a slightly different name to indicate it shouldn't be rounded, but nm, that sounds awful<br>
&lt;TabAtkins> emilio: Before we had this new object, best proposal i could come up with was .innerWidthDouble or .innerWidthUnrounded<br>
&lt;TabAtkins> emilio: but those are bad<br>
&lt;TabAtkins> emilio: MDN and the spec could have a note about the difference<br>
&lt;TabAtkins> flackr: Another bad alternative would be to have a gBCR() api on one of these objects, those also return doubles<br>
&lt;TabAtkins> emilio: Right, but top and left would be 0 always<br>
&lt;TabAtkins> flackr: You *could* imagine them being the scroll position...<br>
&lt;TabAtkins> astearns: that sounds worse<br>
&lt;TabAtkins> emilio: There's other issues to expose the other layout viewport things (small/big/etc)<br>
&lt;TabAtkins> emilio: But I think .width and .height should do the right thing.<br>
&lt;TabAtkins> emilio: And consider other names for the small/large viewport sizes<br>
&lt;TabAtkins> astearns: Anyone remember if it's .viewport or .layoutViewport?<br>
&lt;TabAtkins> emilio: I think we punted on the name in the preivous call<br>
&lt;TabAtkins> astearns: So proposal is to add .width and .height as doubles to the layout viewport interface<br>
&lt;TabAtkins> RESOLVED: add .width and .height as doubles to the layout viewport interface<br>
&lt;emilio> TabAtkins: when we have these box sizes, I'm always confused about whether they have scrollbars or not, do we need variants to account for that?<br>
&lt;TabAtkins> emilio: I think right now the way to do that is document.scrollingElement.scrollWidth, or clientWidth<br>
&lt;TabAtkins> emilio: Which I agree isn't great<br>
&lt;TabAtkins> emilio: I'm also not sure if those round or not off the top of my head<br>
&lt;TabAtkins> emilio: but gBCR() gets around it<br>
&lt;TabAtkins> emilio: we shoudl have a separate issue<br>
&lt;TabAtkins> TabAtkins: agreed<br>
</details>


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


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

Received on Wednesday, 17 July 2024 16:59:44 UTC