Hey everyone, I currently depend on the `zoom` CSS property since using `scale` in conjunction with perspective transforms results in a significant color washout in Chrome. My primary goal is to achieve pixel-perfect precision, and I'd be more than willing to transition away from `zoom` if this issue were resolved or if there is a viable alternative. It would be quite concerning if zoom was removed from Blink without an equivalent solution for this usecase.
Here are some examples (please download originals and compare locally): Original with `zoom: 3` and `transform: perspective(125px) rotateX(2deg)`: https://photos.app.goo.gl/GTPqE7kEotMPS7E36 With `transform: scale(3) perspective(125px) rotateX(2deg)`: https://photos.app.goo.gl/R4nruLLYKC9TEtyu5 For comparison, here is what it looks like with just `transform: scale(3)` and without the perspective transform which does not have this problem: https://photos.app.goo.gl/uwnhGEYobD448r2u6 You'll best see the difference near outlines, like the outlines for trees, mountains and streets look washed out in the version using `scale`. Similarly, fonts are not upscaled correctly with scale and a perspective transform either, compare https://photos.app.goo.gl/PFzzBbaJFLY4Sb7T6 (zoom) with https://photos.app.goo.gl/L82MfqmwRwpvqRHp8 (scale). In my example, the canvas and DOM elements all have `image-rendering: pixelated` applied to them. Thanks for considering this usecase. Christoph On Tuesday, April 18, 2023 at 6:39:38 AM UTC+9 Rick Byers wrote: > I'm supportive of aligning with the CSSWG and Firefox here. But this does > seem at least a little risky to me, so I think we need to carefully > consider the launch plan. > > First, you'll have a flag so we can kill-switch it if we see any > non-trivial breakage in practice, right? > WebView seems particularly risky, perhaps we should separate that out and > leave it enabled on WebView at least to start? > What about enterprise, likely to be higher risk / needing a mitigation > strategy? > From the HA analysis, were you able to get any upper bound on the fraction > of sites with significant (i.e. usability impacting) breakage? Eg. can we > spot check 100 pages that hit the counter to see if any look really broken? > Alternately the UKM analysis Yoav suggests could help. I've been planning > on figuring out how to do a UKM usage distribution analysis - this might > make a good candidate. > > Rick > > On Mon, Apr 17, 2023 at 4:55 PM Morten Stenshorne <mste...@chromium.org> > wrote: > >> Chris Harrelson <chri...@chromium.org> writes: >> >> > On Sun, Apr 16, 2023 at 11:45 PM Morten Stenshorne < >> mste...@chromium.org> wrote: >> > >> > Chris Harrelson <chri...@chromium.org> writes: >> > >> > > On Fri, Apr 14, 2023 at 5:09 PM PhistucK <phis...@gmail.com> wrote: >> > > >> > > Any alternatives? I thought there was a section in the intent >> templates for that... >> > > >> > > One alternative for the use case mentioned in my earlier email is to >> > > apply a CSS transform instead. This will magnify the subtree visually >> > > but not cause a zoom-style layout change. >> > >> > The fact that a CSS transform doesn't affect layout, whereas 'zoom' >> > does, means that we'll paginate (fragment) properly with 'zoom', but >> not >> > with transforms, since they are applied after fragmentation [1], >> causing >> > content to be sliced across fragmentainer boundaries, and the actual >> > page/column breaks (as far as layout is concerned) are shifted away >> from >> > the fragmentainer edges visually, and will appear in the middle of a >> > page/column, for instance. >> > >> > [1] https://www.w3.org/TR/css-break-3/#transforms (never mind the >> > example there; it's not too relevant for this discussion, but I can >> > provide one if you want) >> > >> > Agreed that this is a difference. If a developer wants the result to >> > flow through fragmentation, they'll have to use the second alternative >> > I suggested. >> > >> > But in terms of web compat, I don't think this situation is anything >> > to worry about (e.g. I didn't see any fragmentation when reviewing 25 >> > random sites linked to from chromestatus.com). >> >> But as soon as someone prints any of those sites, there'll be >> fragmentation. >> >> That said, I couldn't find anything bad on those sites, either. I was >> thinking that if it's actually okay to replace zoom with a scale >> transform, we really need authors to make such elements monolithic >> (because any break point inserted inside a transformed element will more >> likely than not end up in the middle of some page, rather than at an >> actual page boundary). So I changed the engine locally to treat zoom != >> 1 as monolithic. But that didn't make any of sites that I tried look any >> worse. >> >> > > Another alternative is for the developer to multiply the numbers in >> > > their CSS properties via calc + variables. >> > >> > That alternative should always work, but more cumbersome for the >> > authors, I suppose? >> > >> > Yes, a bit more cumbersome, but interoperable across all browser >> engines. >> > >> > >> > > On Sat, Apr 15, 2023 at 1:03 AM Chris Harrelson < >> chri...@chromium.org> wrote: >> > > >> > > Contact emails >> > > >> > > chri...@chromium.org >> > > >> > > Specification >> > > >> > > https://developer.mozilla.org/en-US/docs/Web/CSS/zoom >> > > >> > > Summary >> > > >> > > Removes support for the non-standard "zoom" CSS property. This CSS >> property causes computed lengths for an element to be multiplied by >> > > the specified zoom factor. >> > > >> > > Blink component >> > > >> > > Blink>CSS >> > > >> > > TAG review >> > > >> > > None >> > > >> > > TAG review status >> > > >> > > Not applicable >> > > >> > > Risks >> > > >> > > Interoperability and Compatibility >> > > >> > > This feature is only available in Webkit and Blink-based browsers, >> and has been present in Chrome since the beginning. Usage is a little above >> > > 0.5% of page loads: >> https://chromestatus.com/metrics/feature/timeline/popularity/3578 >> However, research shows that sites in HTTPArchive >> > > triggering the feature mostly don't even seem to use it, and those >> that do appear to always use it in a way that works fine without zoom >> applied >> > > - worst case, just a very minor change to the size of a tiny number >> of UI elements, but the UX is basically the same. See: >> > > >> https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit# >> > > >> > > Gecko: Shipped/Shipping (Firefox never supported the feature.) >> > > >> > > WebKit: No signal ( >> https://github.com/WebKit/standards-positions/issues/170) >> > > >> > > Web developers: Some web developers like the feature, in particular >> for the use case of zooming in content in a legible way with responsive >> > > design. See comments regarding that in this issue; >> https://github.com/w3c/csswg-drafts/issues/5623 >> > > >> > > Other signals: The CSSWG has decided to not specify this feature: >> https://github.com/w3c/csswg-drafts/issues/5623 >> > > >> > > Ergonomics >> > > >> > > See "other views" section. >> > > >> > > Activation >> > > >> > > N/A >> > > >> > > Security >> > > >> > > None >> > > >> > > WebView application risks >> > > >> > > Does this intent deprecate or change behavior of existing APIs, >> such that it has potentially high risk for Android WebView-based >> applications? >> > > >> > > Maybe. WebView-based apps might use this feature. >> > > >> > > Debuggability >> > > >> > > Sites should be able to see that zoom no longer applies to elements >> in devtools, though there is no warning planned. >> > > >> > > Will this feature be supported on all six Blink platforms (Windows, >> Mac, Linux, Chrome OS, Android, and Android WebView)? >> > > >> > > Yes >> > > >> > > Is this feature fully tested by web-platform-tests? >> > > >> > > No >> > > >> > > Flag name >> > > >> > > CSSZoom >> > > >> > > Requires code in //chrome? >> > > >> > > False >> > > >> > > Sample links >> > > >> > > https://output.jsbin.com/yimuwax >> > > >> > > Estimated milestones >> > > >> > > Shipping on desktop 114 >> > > DevTrial on desktop 114 >> > > >> > > Shipping on Android 114 >> > > DevTrial on Android 114 >> > > >> > > Shipping on WebView 114 >> > > >> > > Anticipated spec changes >> > > >> > > Open questions about a feature may be a source of future web compat >> or interop issues. Please list open issues (e.g. links to known github >> > > issues in the project for the feature specification) whose >> resolution may introduce web compat/interop risk (e.g., changing to naming >> or >> > > structure of the API in a non-backward-compatible way). >> > > >> > > None >> > > >> > > Link to entry on the Chrome Platform Status >> > > >> > > https://chromestatus.com/feature/6535859207143424 >> > > >> > > Links to previous Intent discussions >> > > >> > > This intent message was generated by Chrome Platform Status. >> > > >> > > -- >> > > You received this message because you are subscribed to the Google >> Groups "blink-dev" group. >> > > To unsubscribe from this group and stop receiving emails from it, >> send an email to blink-dev+...@chromium.org. >> > > To view this discussion on the web visit >> > > >> > >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw_2izF%2BTzHvALsKSxD_uLds%2BPAD7fLtvpX4Cwe7sTwU7g%40mail.gmail.com >> . >> > >> > > >> > > >> > > -- >> > > You received this message because you are subscribed to the Google >> Groups "blink-dev" group. >> > > To unsubscribe from this group and stop receiving emails from it, >> send an email to blink-dev+...@chromium.org. >> > > To view this discussion on the web visit >> > > >> > >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CABc02_%2Br8k-q-bKWGFKxgNbSy97UKGf7VUSMnrnURBJHor-x_w%40mail.gmail.com >> . >> > >> > >> > -- >> > Morten Stenshorne, Software developer, >> > Blink/Layout, Google, Oslo, Norway >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "blink-dev" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to blink-dev+...@chromium.org. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87pm83knwv.fsf%40bud.servebeer.com >> . >> > >> >> -- >> Morten Stenshorne, Software developer, >> Blink/Layout, Google, Oslo, Norway >> >> -- >> You received this message because you are subscribed to the Google Groups >> "blink-dev" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to blink-dev+...@chromium.org. >> > To view this discussion on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/87leiqkz3o.fsf%40bud.servebeer.com >> . >> > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/aff83eb4-4a28-469f-a06c-5dba3e5d7cfan%40chromium.org.
