- From: Botond Ballo via GitHub <sysbot+gh@w3.org>
- Date: Mon, 15 Jan 2024 00:47:36 +0000
- To: public-css-archive@w3.org
> > The Visual Viewport API has eroded that a bit, since sites can now react to visual viewport movements, but allowing sites to set the pinch-zoom scale could open the door to new user-hostile behaviours, such as trying to prevent the user from zooming in at all, or from viewing a certain part of the page zoomed in, etc. > > Isn't that already preventable effectively via the viewport meta tag (modulo the feature you mentioned earlier)? Or by transforming the content by an inverse of the visual viewport scale? Yeah, in that sense this proposal would just make it easier for sites to misbehave in ways they already technically could. --- Another consideration that has occurred to me is implementation complexity. In Firefox, the fact that the scroll position can be modified in both the content process (by web content) and the compositor process (by user input events), and these two pieces of state with independent sources of updates to them therefore need to be reconciled with each other, is a significant source of complexity and bugs. Making the zoom level writable in the content process would carry over that complexity to the zoom level as well, especially if there is an expectation that the modified value of `scale` is immediately reflected when reading back `scale`. (If the API is a `reset()` function whose semantics are that it resets the `scale` to 1 but "in the near future" rather than "immediately", such than an immediate readback of `scale` may not yet reflect the change, this concern would be largely addressed.) -- GitHub Notification of comment by theres-waldo Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9787#issuecomment-1891140561 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 15 January 2024 00:47:39 UTC