- 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
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> <dael> Topic: [cssom-view] No way to access the viewport size without losing precision.<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5260<br> <dael> emilio: window.innerheight and width are lengths. Bad because you want viewport width, esp for fractional widths. No work arounds.<br> <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> <dael> emilio: I think we should be able to change<br> <dael> smfr: Sounds fraught with compat risk. Will people parse int on inner height?<br> <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> <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> <Rossen_> q?<br> <dael> emilio: Agree there is risk<br> <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> <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> <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> <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> <dael> emilio: But inner width and height don't depend on scrollbars. Not sure it can be the case. But sure.<br> <Rossen_> s/I9/IE9/<br> <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> <dael> Rossen_: We can follow that<br> <dael> emilio: That was very much the opposite<br> <dael> emilio: afaict the proposal in the other was rounding for MQ, right?<br> <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> <dael> Rossen_: Do we favor the risk or the similar. It was the argument of sticking with compat<br> <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> <dael> Rossen_: resolve no change, emilio experiments?<br> <dael> emilio: Agree no change for now. Spec shouldn't change w/o proof change is compat<br> <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> <dael> Rossen_: Closing and resolving are different. If there's more information with strong suggestion in opposite we revisit<br> <dael> Rossen_: Obj to resolve no change?<br> <dael> RESOLVED: No change<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-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