W3C home > Mailing lists > Public > public-css-archive@w3.org > November 2020

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Wed, 11 Nov 2020 17:49:23 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-725566976-1605116959-sysbot+gh@w3.org>
The CSS Working Group just discussed `[cssom-view] No way to access the viewport size without losing precision.`, and agreed to the following:

* `RESOLVED: No change`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [cssom-view] No way to access the viewport size without losing precision.<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/5260<br>
&lt;dael> emilio: window.innerheight and width are lengths. Bad because you want viewport width, esp for fractional widths. No work arounds.<br>
&lt;dael> emilio: I know there's history here and that some of OM prep remained as long intentionally but I don't think this was one.<br>
&lt;dael> emilio: I think we should be able to change<br>
&lt;dael> smfr: Sounds fraught with compat risk. Will people parse int on inner height?<br>
&lt;dael> emilio: This came from slight change to FF UI that added a half pixel to UI which reduced viewport. A bunch of sites broke. I think this fixes more, esp for uses that use zoom-like things to change viewport size.<br>
&lt;dael> emilio: You can always parse it. Right now people set .width to value of innerWidth and that leaves seams when on fractional dpi context<br>
&lt;Rossen_> q?<br>
&lt;dael> emilio: Agree there is risk<br>
&lt;dael> emilio: If people think this is not a bad idea I can try to change gecko and see if other engines will follow. If you're convinced it can't happen no point to try<br>
&lt;dael> smfr: Not convinced but when we tried with other metrics it was a problem. Other option is new APIs that return doubles. Happy for you to try and if it works I can try on WK. Needs extended in the wild tests<br>
&lt;dael> Rossen_: We tried something similar in I9 days. We exposed a bunch of OM and I believe this is one we changed because a lot of problems. I remember fighting with cnn.com which was fighting to try and readjust and avoid scrollbars.<br>
&lt;dael> Rossen_: At that time we could confuse such a large property so I'm not sure what would be there for small end of the web. I would not underestimate compat risk<br>
&lt;dael> emilio: But inner width and height don't depend on scrollbars. Not sure it can be the case. But sure.<br>
&lt;Rossen_> s/I9/IE9/<br>
&lt;dael> Rossen_: That's the feedback for now. If we proceed another point in issue from florian where we took a no change for media width and height. The issue is linked<br>
&lt;dael> Rossen_: We can follow that<br>
&lt;dael> emilio: That was very much the opposite<br>
&lt;dael> emilio: afaict the proposal in the other was rounding for MQ, right?<br>
&lt;dael> florian: afaict what this means in MQ stays what they are b/c make sense that way on OM stays because compat. End result is inconsitent. If we want consistant we have to break one<br>
&lt;dael> Rossen_: Do we favor the risk or the similar. It was the argument of sticking with compat<br>
&lt;dael> emilio: Fair. I think I'm still going to give it a shot. Nightly or beta to see if there's reckage. If there is I'll prop a new API. If that sounds good I don't need resolution<br>
&lt;dael> Rossen_: resolve no change, emilio experiments?<br>
&lt;dael> emilio: Agree no change for now. Spec shouldn't change w/o proof change is compat<br>
&lt;dael> florian: we're not saying it's the end of the story. I don't htink we should close, we should resolve you're investigating<br>
&lt;dael> Rossen_: Closing and resolving are different. If there's more information with strong suggestion in opposite we revisit<br>
&lt;dael> Rossen_: Obj to resolve no change?<br>
&lt;dael> RESOLVED: No change<br>

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

Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 November 2020 17:49:25 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:22 UTC