Intent to Prototype and Ship: Standardized CSS zoom

825 views
Skip to first unread message

Yotam Hacohen

unread,
Feb 2, 2024, 2:18:38 PMFeb 2
to blin...@chromium.org

Contact emails

yo...@google.com

Explainer

None

Specification

https://github.com/w3c/csswg-drafts/pull/9699

Design docs

https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

Summary

Aligns the existing implementation of the previously non-standard CSS zoom property to align with the new standard. This changes various JS APIs to align with the spec (see design doc), change zoom to apply to iframes, and change it to apply to all inherit all length properties (currently it only changes inherited font-size)


Blink component

Blink>Paint

TAG review

None

TAG review status

Pending

Risks


Interoperability and Compatibility

There is web compatibility risk for these changes. However, previous research indicates broken content due to unexpected changes of the JS APIs is very unlikely, since: * The changes to the JS API simply change the coordinate space of the responses, not the syntax or what APIs are available. * Most pages found during the research didn't appear to use CSS zoom at all and the ones that did only relied on the visual effect, not JS APIs. It's possible some pages will be broken by the changes to inherited properties other than font-size, or applying zoom to sub-frames, but based on previous research, those are very likely to be minor visual changes that don't break fundamental user interaction with the site. None of the sites reviewed contained iframes underneath a zoomed ancestor. We will use direct outreach to avoid any broken features in Office 365 or the Gmail native mobile app



Gecko: No signal Filed a standard position request: https://github.com/mozilla/standards-positions/issues/977

WebKit: No signal Filed a standard position request: https://github.com/WebKit/standards-positions/issues/311

Web developers: Positive (https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit#heading=h.6sz4u73bikbd) Research collected as part of the previous attempt to remove CSS zoom demonstrated several use cases.

Other signals:

WebView application risks

See Interoperability and Compatibility above 



Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Is this feature fully tested by web-platform-tests?

Yes

All JS APIs affected by zoom are tested with the following wpt tests: https://wpt.fyi/results/css/cssom-view/offsetTop-offsetLeft-with-zoom.html?label=master&label=experimental&aligned&q=cssom-view%2FoffsetTop-offsetLeft-with-zoom.html https://wpt.fyi/results/css/cssom-view/client-props-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getBoundingClientRect-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getClientRects-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/scroll-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/intersection-observer/zoom-scaled-target.html?label=experimental&label=master&aligned


Flag name on chrome://flags

StandardizedBrowserZoom

Finch feature name

StandardizedBrowserZoom

Requires code in //chrome?

False

Sample links

https://jsbin.com/wasafateko/edit?html,css,js,output

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198254868529152

This intent message was generated by Chrome Platform Status.

Domenic Denicola

unread,
Feb 4, 2024, 10:34:53 PMFeb 4
to Yotam Hacohen, blin...@chromium.org
It's always exciting to move such an old feature from nonstandard to standardized!

On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via blink-dev <blin...@chromium.org> wrote:

Contact emails

yo...@google.com

Explainer

None

FWIW, I think the contents of https://github.com/w3c/csswg-drafts/pull/9699 and https://drafts.csswg.org/css-viewport/#zoom-property are probably a good enough explainer. It might be a good idea to update ChromeStatus to link to them.
 


Specification

https://github.com/w3c/csswg-drafts/pull/9699

Design docs

https://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

Summary

Aligns the existing implementation of the previously non-standard CSS zoom property to align with the new standard. This changes various JS APIs to align with the spec (see design doc), change zoom to apply to iframes, and change it to apply to all inherit all length properties (currently it only changes inherited font-size)


Blink component

Blink>Paint

TAG review

None

TAG review status

Pending

Probably this fits under the first exception here.
 


Risks


Interoperability and Compatibility

There is web compatibility risk for these changes. However, previous research indicates broken content due to unexpected changes of the JS APIs is very unlikely, since: * The changes to the JS API simply change the coordinate space of the responses, not the syntax or what APIs are available. * Most pages found during the research didn't appear to use CSS zoom at all and the ones that did only relied on the visual effect, not JS APIs. It's possible some pages will be broken by the changes to inherited properties other than font-size, or applying zoom to sub-frames, but based on previous research, those are very likely to be minor visual changes that don't break fundamental user interaction with the site. None of the sites reviewed contained iframes underneath a zoomed ancestor. We will use direct outreach to avoid any broken features in Office 365 or the Gmail native mobile app


Can you give more quantitative details on this previous research? E.g. when you say "most pages", is that 3/5 pages? 99/100?

Regarding the direct outreach targets you mentioned, are they already fixed, or do they need more time to update?

What is your rollout plan for this change---straight to 100% with a killswitch, or a gradual rollout, or...?
Are the non-JS aspects of the API also tested?
 

Flag name on chrome://flags

StandardizedBrowserZoom

Finch feature name

StandardizedBrowserZoom

Requires code in //chrome?

False

Sample links

https://jsbin.com/wasafateko/edit?html,css,js,output

Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5198254868529152

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/CAAOtuiYKjC9Gt%2BgXwWNT_hJneBMa053RizCX5Xj5p_07CVLXkA%40mail.gmail.com.

Gregg Tavares

unread,
Feb 5, 2024, 1:34:03 PMFeb 5
to Yotam Hacohen, blin...@chromium.org
The link to the specification: https://github.com/w3c/csswg-drafts/pull/9699 list behaviors and then says

> Web compat analysis: the above is what is already implemented in WebKit and Chromium browsers....

But one of the behaviors listed is 

> devicePixelRatio is affected by zoom inherited from an ancestor frame

devicePixelRatio never changes in WebKit. 


--

Yotam Hacohen

unread,
Feb 8, 2024, 8:55:21 PMFeb 8
to blink-dev, Domenic Denicola, blin...@chromium.org, Yotam Hacohen
Hey Dominic and thanks for the input!

On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic Denicola wrote:
It's always exciting to move such an old feature from nonstandard to standardized!

On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via blink-dev <blin...@chromium.org> wrote:
Contact emailsyo...@google.com

ExplainerNone

FWIW, I think the contents of https://github.com/w3c/csswg-drafts/pull/9699 and https://drafts.csswg.org/css-viewport/#zoom-property are probably a good enough explainer. It might be a good idea to update ChromeStatus to link to them.


Summary

Aligns the existing implementation of the previously non-standard CSS zoom property to align with the new standard. This changes various JS APIs to align with the spec (see design doc), change zoom to apply to iframes, and change it to apply to all inherit all length properties (currently it only changes inherited font-size)


Blink componentBlink>Paint

TAG reviewNone

TAG review statusPending
Probably this fits under the first exception here.
 


Risks

Interoperability and Compatibility

There is web compatibility risk for these changes. However, previous research indicates broken content due to unexpected changes of the JS APIs is very unlikely, since: * The changes to the JS API simply change the coordinate space of the responses, not the syntax or what APIs are available. * Most pages found during the research didn't appear to use CSS zoom at all and the ones that did only relied on the visual effect, not JS APIs. It's possible some pages will be broken by the changes to inherited properties other than font-size, or applying zoom to sub-frames, but based on previous research, those are very likely to be minor visual changes that don't break fundamental user interaction with the site. None of the sites reviewed contained iframes underneath a zoomed ancestor. We will use direct outreach to avoid any broken features in Office 365 or the Gmail native mobile app


Can you give more quantitative details on this previous research? E.g. when you say "most pages", is that 3/5 pages? 99/100?
  Sampling pages from the doc, I couldn't find even one example of a page that uses zoom in a way that will change it's behavior (i.e. - calling GetBoundingClientRect or GetBoundingRects on an element with CSS zoom). I also compared those sites visually side by side on a stable version of chrome and a local version with the planned changes in effect, and couldn't see any change.  

Regarding the direct outreach targets you mentioned, are they already fixed, or do they need more time to update?
We have reached out to the relevant people.  

What is your rollout plan for this change---straight to 100% with a killswitch, or a gradual rollout, or...?
Our plan is to go straight to 100% with a killswitch.  



Gecko: No signal Filed a standard position request: https://github.com/mozilla/standards-positions/issues/977

WebKit: No signal Filed a standard position request: https://github.com/WebKit/standards-positions/issues/311

Web developers: Positive (https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit#heading=h.6sz4u73bikbd) Research collected as part of the previous attempt to remove CSS zoom demonstrated several use cases.

Other signals:

WebView application risks

See Interoperability and Compatibility above 



Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No

Is this feature fully tested by web-platform-tests?Yes

All JS APIs affected by zoom are tested with the following wpt tests: https://wpt.fyi/results/css/cssom-view/offsetTop-offsetLeft-with-zoom.html?label=master&label=experimental&aligned&q=cssom-view%2FoffsetTop-offsetLeft-with-zoom.html https://wpt.fyi/results/css/cssom-view/client-props-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getBoundingClientRect-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getClientRects-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/scroll-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/intersection-observer/zoom-scaled-target.html?label=experimental&label=master&aligned


Are the non-JS aspects of the API also tested?
Yes, the tests also test the cpp code that is affected. 
 

Flag name on chrome://flagsStandardizedBrowserZoom

Finch feature nameStandardizedBrowserZoom

Requires code in //chrome?False

Sample linkshttps://jsbin.com/wasafateko/edit?html,css,js,output


Estimated milestones

No milestones specified


Link to entry on the Chrome Platform Statushttps://chromestatus.com/feature/5198254868529152


This intent message was generated by Chrome Platform Status.

Yotam Hacohen

unread,
Feb 8, 2024, 8:58:23 PMFeb 8
to blink-dev, Gregg Tavares, blin...@chromium.org, Yotam Hacohen
Hey Gregg. Thanks for the input!
devicePixelRatio indeed never changes in webkit. It is just mentioned as functions that are already implemented in webkit with in a way that is aligned with the new spec, but there is no change to the webkit code. 

Domenic Denicola

unread,
Feb 8, 2024, 9:46:00 PMFeb 8
to Yotam Hacohen, blink-dev, Domenic Denicola
On Fri, Feb 9, 2024 at 10:55 AM Yotam Hacohen <yo...@google.com> wrote:
Hey Dominic and thanks for the input!

On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic Denicola wrote:
It's always exciting to move such an old feature from nonstandard to standardized!

On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via blink-dev <blin...@chromium.org> wrote:
Contact emailsyo...@google.com

ExplainerNone

FWIW, I think the contents of https://github.com/w3c/csswg-drafts/pull/9699 and https://drafts.csswg.org/css-viewport/#zoom-property are probably a good enough explainer. It might be a good idea to update ChromeStatus to link to them.
Added those. Thanks! 
 


Specificationhttps://github.com/w3c/csswg-drafts/pull/9699

Design docshttps://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

Summary

Aligns the existing implementation of the previously non-standard CSS zoom property to align with the new standard. This changes various JS APIs to align with the spec (see design doc), change zoom to apply to iframes, and change it to apply to all inherit all length properties (currently it only changes inherited font-size)


Blink componentBlink>Paint

TAG reviewNone

TAG review statusPending

Probably this fits under the first exception here.
 


Risks

Interoperability and Compatibility

There is web compatibility risk for these changes. However, previous research indicates broken content due to unexpected changes of the JS APIs is very unlikely, since: * The changes to the JS API simply change the coordinate space of the responses, not the syntax or what APIs are available. * Most pages found during the research didn't appear to use CSS zoom at all and the ones that did only relied on the visual effect, not JS APIs. It's possible some pages will be broken by the changes to inherited properties other than font-size, or applying zoom to sub-frames, but based on previous research, those are very likely to be minor visual changes that don't break fundamental user interaction with the site. None of the sites reviewed contained iframes underneath a zoomed ancestor. We will use direct outreach to avoid any broken features in Office 365 or the Gmail native mobile app


Can you give more quantitative details on this previous research? E.g. when you say "most pages", is that 3/5 pages? 99/100?
  Sampling pages from the doc, I couldn't find even one example of a page that uses zoom in a way that will change it's behavior (i.e. - calling GetBoundingClientRect or GetBoundingRects on an element with CSS zoom). I also compared those sites visually side by side on a stable version of chrome and a local version with the planned changes in effect, and couldn't see any change.  

This sounds like a good sign, but I'd still appreciate some numbers. So it's zero out of how many?

 

Regarding the direct outreach targets you mentioned, are they already fixed, or do they need more time to update?
We have reached out to the relevant people.  

So, you have contacted them, but they still need more time to update? Do you have an estimate for when they will be updated?


What is your rollout plan for this change---straight to 100% with a killswitch, or a gradual rollout, or...?
Our plan is to go straight to 100% with a killswitch.  



Gecko: No signal Filed a standard position request: https://github.com/mozilla/standards-positions/issues/977

WebKit: No signal Filed a standard position request: https://github.com/WebKit/standards-positions/issues/311

Web developers: Positive (https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit#heading=h.6sz4u73bikbd) Research collected as part of the previous attempt to remove CSS zoom demonstrated several use cases.

Other signals:

WebView application risks

See Interoperability and Compatibility above 



Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No

Is this feature fully tested by web-platform-tests?Yes

All JS APIs affected by zoom are tested with the following wpt tests: https://wpt.fyi/results/css/cssom-view/offsetTop-offsetLeft-with-zoom.html?label=master&label=experimental&aligned&q=cssom-view%2FoffsetTop-offsetLeft-with-zoom.html https://wpt.fyi/results/css/cssom-view/client-props-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getBoundingClientRect-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getClientRects-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/scroll-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/intersection-observer/zoom-scaled-target.html?label=experimental&label=master&aligned


Are the non-JS aspects of the API also tested?
Yes, the tests also test the cpp code that is affected. 

My question was about the visual aspects. Are there any, for example, reftests, which show that zoom has a visual effect?

Yotam Hacohen

unread,
Feb 9, 2024, 2:24:13 PMFeb 9
to blink-dev, Domenic Denicola, blink-dev, Yotam Hacohen
On Thursday, February 8, 2024 at 6:46:00 PM UTC-8 Domenic Denicola wrote:
On Fri, Feb 9, 2024 at 10:55 AM Yotam Hacohen <yo...@google.com> wrote:
Hey Dominic and thanks for the input!

On Sunday, February 4, 2024 at 7:34:53 PM UTC-8 Domenic Denicola wrote:
It's always exciting to move such an old feature from nonstandard to standardized!

On Sat, Feb 3, 2024 at 4:18 AM 'Yotam Hacohen' via blink-dev <blin...@chromium.org> wrote:
Contact emailsyo...@google.com

ExplainerNone

FWIW, I think the contents of https://github.com/w3c/csswg-drafts/pull/9699 and https://drafts.csswg.org/css-viewport/#zoom-property are probably a good enough explainer. It might be a good idea to update ChromeStatus to link to them.
Added those. Thanks! 
 


Specificationhttps://github.com/w3c/csswg-drafts/pull/9699

Design docshttps://docs.google.com/document/d/1AcnDShjT-kEuRaMchZPm5uaIgNZ4OiYtM4JI9qiV8Po/edit

Summary

Aligns the existing implementation of the previously non-standard CSS zoom property to align with the new standard. This changes various JS APIs to align with the spec (see design doc), change zoom to apply to iframes, and change it to apply to all inherit all length properties (currently it only changes inherited font-size)


Blink componentBlink>Paint

TAG reviewNone

TAG review statusPending

Probably this fits under the first exception here.
 


Risks

Interoperability and Compatibility

There is web compatibility risk for these changes. However, previous research indicates broken content due to unexpected changes of the JS APIs is very unlikely, since: * The changes to the JS API simply change the coordinate space of the responses, not the syntax or what APIs are available. * Most pages found during the research didn't appear to use CSS zoom at all and the ones that did only relied on the visual effect, not JS APIs. It's possible some pages will be broken by the changes to inherited properties other than font-size, or applying zoom to sub-frames, but based on previous research, those are very likely to be minor visual changes that don't break fundamental user interaction with the site. None of the sites reviewed contained iframes underneath a zoomed ancestor. We will use direct outreach to avoid any broken features in Office 365 or the Gmail native mobile app


Can you give more quantitative details on this previous research? E.g. when you say "most pages", is that 3/5 pages? 99/100?
  Sampling pages from the doc, I couldn't find even one example of a page that uses zoom in a way that will change it's behavior (i.e. - calling GetBoundingClientRect or GetBoundingRects on an element with CSS zoom). I also compared those sites visually side by side on a stable version of chrome and a local version with the planned changes in effect, and couldn't see any change.  

This sounds like a good sign, but I'd still appreciate some numbers. So it's zero out of how many?

 

Regarding the direct outreach targets you mentioned, are they already fixed, or do they need more time to update?
We have reached out to the relevant people.  

So, you have contacted them, but they still need more time to update? Do you have an estimate for when they will be updated?
We already got a response from the gmail team, and everything is ok there, we even have a jsfiddle example that shows that the visual aspect doesn't change for them. Still waiting for a response from the Office 365, if we don't get a response in the next week we will reach out again for a better defined timeline.  


What is your rollout plan for this change---straight to 100% with a killswitch, or a gradual rollout, or...?
Our plan is to go straight to 100% with a killswitch.  



Gecko: No signal Filed a standard position request: https://github.com/mozilla/standards-positions/issues/977

WebKit: No signal Filed a standard position request: https://github.com/WebKit/standards-positions/issues/311

Web developers: Positive (https://docs.google.com/document/d/1cmbXpjAcXAht2ufi7bNKy-rbVNveqaf0UzeYg_DIMNA/edit#heading=h.6sz4u73bikbd) Research collected as part of the previous attempt to remove CSS zoom demonstrated several use cases.

Other signals:

WebView application risks

See Interoperability and Compatibility above 



Debuggability

None


Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?No

Is this feature fully tested by web-platform-tests?Yes

All JS APIs affected by zoom are tested with the following wpt tests: https://wpt.fyi/results/css/cssom-view/offsetTop-offsetLeft-with-zoom.html?label=master&label=experimental&aligned&q=cssom-view%2FoffsetTop-offsetLeft-with-zoom.html https://wpt.fyi/results/css/cssom-view/client-props-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getBoundingClientRect-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/getClientRects-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/css/cssom-view/scroll-zoom.html?label=master&label=experimental&aligned https://wpt.fyi/results/intersection-observer/zoom-scaled-target.html?label=experimental&label=master&aligned


Are the non-JS aspects of the API also tested?
Yes, the tests also test the cpp code that is affected. 

My question was about the visual aspects. Are there any, for example, reftests, which show that zoom has a visual effect?
Yes, there are reftests for zoom in the wpt folder. The behavior of many aspects of the zoom are not changed (Especially the visual effect of CSS zoom on most elements, excluding iframes) and those tests stay the same. We will also add reftests for iframes with CSS zoom withe the patch adding those changes to iframes. 

Daniel Bratell

unread,
Feb 14, 2024, 11:53:45 AMFeb 14
to Yotam Hacohen, blink-dev, Domenic Denicola

Philip Jägenstedt

unread,
Feb 14, 2024, 12:00:42 PMFeb 14
to Daniel Bratell, Yotam Hacohen, blink-dev, Domenic Denicola

Yoav Weiss (@Shopify)

unread,
Feb 14, 2024, 12:11:58 PMFeb 14
to Philip Jägenstedt, Daniel Bratell, Yotam Hacohen, blink-dev, Domenic Denicola

Yoav Weiss (@Shopify)

unread,
Feb 14, 2024, 12:13:51 PMFeb 14
to Philip Jägenstedt, Daniel Bratell, Yotam Hacohen, blink-dev, Domenic Denicola
Just wanted to say that it's exciting to see this standardized after all these years. Given the manual inspection, it seems like shipping this to 100% with a killswitch is (hopefully) safe enough!

Daniel Bratell

unread,
Feb 15, 2024, 5:18:06 AMFeb 15
to Yoav Weiss (@Shopify), Philip Jägenstedt, Yotam Hacohen, blink-dev, Domenic Denicola

Same for me. A proprietary long term CSS property is now fully standardized and will be interoperable. This is a win for the web, and thank you for all who worked to make it happen!

/Daniel

Noam Helfman

unread,
Feb 26, 2024, 10:01:58 AMFeb 26
to blink-dev, Daniel Bratell, Yotam Hacohen, blink-dev, dom...@chromium.org, yoav...@chromium.org, Philip Jägenstedt
Great to see work is being done to get this standardized!

However, I think it should not be shipped yet.

We have done some basic testing of this feature with Excel Online and it breaks lots of critical user scenarios related to our zoom feature. This will impact many millions of users and regress a major feature.

We will need to spend time to investigate if there is a simple workaround that we can use to address this regression.

Few questions:
1. What is the expected timeline to ship this?
2. Is there an option to programatically determine if the feature is enabled? (e.g. would CSS.supports("zoom") return true? )
3. Will there be an option to enable/disable it (e.g. release with OT)?

Please do not ship this until we can confirm we have a workaround or the API is adapted in a way that does not regress existing behavior.

Thanks,
Noam

Mike Taylor

unread,
Feb 26, 2024, 1:37:04 PMFeb 26
to Noam Helfman, blink-dev, Daniel Bratell, Yotam Hacohen, dom...@chromium.org, yoav...@chromium.org, Philip Jägenstedt

Thanks for the feedback Noam - would you mind filing a bug at crbug.com/new that contains some steps to reproduce the breakage, and possibly some affected codepaths and report back here? Agree that breaking Excel is not a great outcome.

Yoav Weiss (@Shopify)

unread,
Feb 27, 2024, 3:41:01 PMFeb 27
to Mike Taylor, Yotam Hacohen, Noam Helfman, blink-dev, Daniel Bratell, Yotam Hacohen, dom...@chromium.org, Philip Jägenstedt
On Mon, Feb 26, 2024 at 7:36 PM Mike Taylor <mike...@chromium.org> wrote:

Thanks for the feedback Noam - would you mind filing a bug at crbug.com/new that contains some steps to reproduce the breakage, and possibly some affected codepaths and report back here? Agree that breaking Excel is not a great outcome.

That's an understatement..

On 2/26/24 10:01 AM, Noam Helfman wrote:
Great to see work is being done to get this standardized!

However, I think it should not be shipped yet.

We have done some basic testing of this feature with Excel Online and it breaks lots of critical user scenarios related to our zoom feature. This will impact many millions of users and regress a major feature.

We will need to spend time to investigate if there is a simple workaround that we can use to address this regression.

Few questions:
1. What is the expected timeline to ship this?
Good question. +Yotam Hacohen may be able to say more. For now, I see that the feature is still not enabled by default
2. Is there an option to programatically determine if the feature is enabled? (e.g. would CSS.supports("zoom") return true? )
3. Will there be an option to enable/disable it (e.g. release with OT)?
It might be a good idea to have an OT that turns this feature off, even if it's only for Excel. (although if we missed this breakage, I wonder what other breakage we may have missed) 

Ilan Tchernowitz

unread,
Mar 3, 2024, 10:21:56 AMMar 3
to blink-dev, Yoav Weiss (@Shopify), Noam Helfman, blink-dev, Daniel Bratell, Yotam Hacohen, dom...@chromium.org, Philip Jägenstedt, Mike Taylor, Yotam Hacohen
Hi, 

Per request - created a chromium bug on this issue.

Thanks

Reply all
Reply to author
Forward
0 new messages