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

[csswg-drafts] Revisiting standardization of the `zoom` property (#5623)

From: Daniel Libby via GitHub <sysbot+gh@w3.org>
Date: Thu, 15 Oct 2020 08:33:13 +0000
To: public-css-archive@w3.org
Message-ID: <issues.opened-722120666-1602750792-sysbot+gh@w3.org>
dlibby- has just created a new issue for https://github.com/w3c/csswg-drafts:

== Revisiting standardization of the `zoom` property  ==
As far as I can tell the last time this was discussed in depth was back in [2015](https://lists.w3.org/Archives/Public/www-style/2015May/0282.html). At the time there appeared to be consensus that it would have been better had the property never existed, and there was not a strong preference for standardizing the current implementations. However, usage on the web appears to be non-zero and relatively steady &mdash; I'd like to open another discussion on whether there is a path towards standardization.

Here is [Chrome's UseCounter data](https://chromestatus.com/metrics/feature/timeline/popularity/3578) for the percentage of pageloads where a zoom value that is not 1 (or 100%) is applied to any element during the style cascade. As of the opening of this issue it stands around 1% of pageloads.

I'm thinking that this would start mainly as a documentation effort (@atanassov went through this exercise previously [here](https://cdn.rawgit.com/atanassov/css-zoom/master/Overview.html)) &mdash; given that IE and legacy Edge are on their way out, I'm cautiously optimistic that the WebKit and Blink implementations are similar enough that there will only be a handful of behavioral differences to reconcile, if any.

One item of particular note is that Gecko does not implement zoom (see https://bugzilla.mozilla.org/show_bug.cgi?id=390936). There are unique challenges given that authors have used a `-moz-transform: scale(n)` fallback in the absence of zoom. Additionally, I believe there were attempts to implement zoom in terms of transforms but that was not sufficient to alleviate compat concerns.

In terms of use cases, similar to how browsers have both pinch zoom and page zoom, this does seem like a useful primitive for web authors (and clearly there is some usage today). For full disclosure, there are Microsoft web properties that have expressed interest in using the zoom property as a low-cost solution for zooming in certain portions of webpages. They don't want to introduce overflow in the inline direction or redesign their implementation, and the zoom property has provided an almost trivial way to improve these scenarios for their users (they're experimenting with this in production today).

@chrishtr also pointed me to previous discussions related to defining an interaction model driven by maps scenarios (https://github.com/w3c/csswg-drafts/issues/5275). Perhaps that would be another lens through which to have discussions about the use case, but I don't think that would move the needle for the large number of pages that use a property that is currently implemented by more than one browser.



Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5623 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 15 October 2020 08:33:15 UTC

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