Intent to deprecate and remove hidden zoom values

[bs...@google.com]

Primary eng email

bs...@chromium.org, taba...@chromium.org

Summary

The CSS "zoom" property is not in the CSS standard but Blink supports it anyway.

There are three special values which are inconsistently documented: "reset," "normal," and "document." At the moment "zoom:normal" is equivalent to "zoom:1"; "zoom:reset" and "zoom:document" are similar to "zoom:1" but they disable page zoom as well (so the element remains the same size as you zoom in and out).

I propose changing "reset" to be the same as "normal" (equivalent to zoom:1) and removing support for "document."

Motivation

• Disabling page zoom is user-hostile behavior and we shouldn't include a way to achieve it.
  
• Stops zoom:reset from being a weird exception and reduces complexity.
• I broke zoom:reset and zoom:document recently and restoring their current behavior is a pain.
• I can't find any mention that "document" is a valid value for zoom anywhere, so it's a good candidate to remove.

Alternative implementation suggestion for web developers

Stop wanting to disable page zoom.

Compatibility Risk

Page zoom will start working on some websites where it didn't before.

If a website was using zoom:document to override a zoom:x != 1 value in a cascade then the zoom:x will start applying where it didn't before.

Current Browser Support:

Edge/IE: Only supports zoom:normal (with the same behavior as Blink).

Firefox: Does not support the zoom property at all.

Public Tracking Bug

The bug about me breaking zoom:reset is crbug.com/642613 and it has some discussion of this. I can file a separate tracking bug if it seems necessary.

[Chris Harrelson]

Hi,

Three questions:

1. Do you have any data on how often these to-be-deprecated variants are used?

2. In the compatibility section, I assume WebKit / Safari has the same behavior as Blink?

3. Has there been any discussion with other vendors to check agreement?

--
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+unsubscribe@chromium.org.

[bs...@google.com]

1. No direct data. I looked at https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/zoom which shows usage of zoom:normal, but that's the value I'm not modifying. I assume the other variants have less usage than that.

2. I don't have an OSX device on hand to make sure, but I assume the same thing.

3. I haven't had any discussion. I'm only changing the variants that are Blink-specific.

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Rick Byers]

On Fri, Sep 9, 2016 at 3:12 PM, bsep via blink-dev <blin...@chromium.org> wrote:

1. No direct data. I looked at https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/zoom which shows usage of zoom:normal, but that's the value I'm not modifying. I assume the other variants have less usage than that.

I think we'll need UseCounter data before making a decision here.  There's a lot of Chrome-only content out there.

 

2. I don't have an OSX device on hand to make sure, but I assume the same thing.

http://browserstack.com is your friend

 

3. I haven't had any discussion. I'm only changing the variants that are Blink-specific.

Well blink+WebKit, which sometimes means mobile websites have come to depend on the behavior.  So we can't assume the risk is near zero.

[bs...@google.com]

If removing zoom:document is actually controversial I don't mind just leaving it and also making it work the same as zoom:normal. The important part of this is removing the ability to disable page zoom.

[Chris Harrelson]

None of it is controversial, we just need to be careful not to break too many sites.

It would be probably be great to get rid of CSS zoom entirely for example, but we don't have data to support the web-compatibility of that change right now.

Chris

[bs...@google.com]

I added a UseCounter for these, so here's an update on this with more data:

zoom:reset is at 0.0004% of page loads. Based on that number it seems like it'd be better to just remove it, rather than deprecate it like I originally proposed.

zoom:document on the other hand is very close to not existing (<0.0001%) so I think we should definitely remove it.

By the way, the essential characteristic of these two (disabling page zoom) doesn't affect mobile platforms because of how pinch-to-zoom works. I tested on mobile safari and they work like zoom:normal does (i.e. a no-op).

[PhistucK]

Which Chrome version has those use counters?

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[bs...@google.com]

This is active on Dev and Canary. I'm not sure if that affects the numbers. It looks like zoom:reset has increased to 0.0013% since I made the above post, but that still seems very low to me.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[PhistucK]

It affects those numbers, as the population of those channels is significantly smaller than beta or stable. The use counter data is usually taken from beta or (preferably) stable before making deprecation or removal decisions.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

[Rick Byers]

Yeah the denominator on chromestatus.com is ALL Chrome page loads, so you can't use chromestatus to analyze UseCounters which haven't yet reached stable.  Improving this is tracked here.

In the interim, here's an internal link you can use.  It looks like these counters only recently hit dev channel so you can't read too much into the data yet (eg. if they were popular on mobile sites we wouldn't see that at all until they make it to beta).  But already zoom:reset is way too high at 0.15% of page views on dev channel.  zoom:document is looking promising (0.0006%).

So I'd support deprecating zoom:document in M55 and removing it in M56 (in case usage spikes in beta, on mobile, etc.). 

Understanding the compat risk of changing zoom:reset looks harder (presumably some popular library is doing this).  I assume Safari matches blink's behavior (making mobile-specific sites at greater compat risk), right?  But the fact that Edge doesn't have it suggests the compat impact is likely to be pretty low despite the high usage numbers.  If you want to proceed with trying to break it then I'd suggest analyzing a few sites relying on it (I can help you find them if desired) to see how they'd be impacted in practice (if at all).  If a small spot-check reveals no real impact, then I'd support giving it a shot.

[Rick Byers]

Note that +Rossen (CSSWG chair, Edge rendering lead) has a proposed spec for zoom.  As expected it appears to match the Edge implementation (no 'reset' or 'document').  Perhaps he has data on why 'reset' is not needed for web compat despite apparently high usage in blink.

[bs...@google.com]

Again, making zoom:reset behave like zoom:normal would have no effect on mobile, the two behave identically with pinch-to-zoom (unless I missed something).

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[bs...@google.com]

Here's an example of what would change for a website if we deprecated zoom:reset. I managed to find one site that is using zoom:reset in the wild: foodviva.com

The "Food Gallery" sidebar div has zoom:reset applied, which makes it out-of-proportion to the rest of the site if you zoom the page in or out:

If I disable zoom:reset with the inspector the div is now in proportion with the rest of the page:

Arguably this is an improvement. Certainly in my opinion this behavior looks better and is less user-hostile. This is at 25% zoom so it's much more dramatic than what someone would normally see.

I double-checked this site on mobile Safari, the behavior doesn't happen when using pinch-zoom:

[Emil A Eklund]

On Thu, Sep 29, 2016 at 1:46 PM, bsep via blink-dev <blin...@chromium.org> wrote:

Here's an example of what would change for a website if we deprecated zoom:reset. I managed to find one site that is using zoom:reset in the wild: foodviva.com

The "Food Gallery" sidebar div has zoom:reset applied, which makes it out-of-proportion to the rest of the site if you zoom the page in or out:

If I disable zoom:reset with the inspector the div is now in proportion with the rest of the page:

Arguably this is an improvement. Certainly in my opinion this behavior looks better and is less user-hostile. This is at 25% zoom so it's much more dramatic than what someone would normally see.

That's a little misleading as the most common use of zoom is to zoom *in*. When zooming in the zoom:reset on the sidebar div means it is not zoomed and the main content gets the majority of the space. With your proposed change both would zoom triggering further overflow.

Regardless, 0.15% is *massive*. 

[bs...@google.com]

Sorry, I used zoom-out because if the content is large the sidebar gets out of the way so the behavior isn't visible any more. Just for reference here's the zoomed-in behavior:

With zoom:reset:

Without zoom:reset:

Still an improvement IMO. I would really like to see a non-broken-looking use of this, but I haven't been able to find any other site that uses it so far.

If you look at the internal histogram for dev directly it still only says 0.01% for zoom:reset. Where is the order-of-magnitude difference coming from?

I still think we shouldn't support this feature regardless of the numbers, but it sounds like I'm alone in that thought.

[Rick Byers]

I agree that case looks as if zoom:reset usage is a bug, not an intended behavior.

It's really surprising that >1/1000 page views would be using this somewhere.  It's just really scary to break anything we know is used that often, even if we think it's a bad feature.  If we had reason to believe that the vast majority of these 0.15% of page views would be like the one you showed (improved or neutral as a result of the change) then I'd say we should give it a try.

How on earth can something so unhelpful and obscure be used on 0.15% of page views?  Maybe there's one popular site (facebook, gmail?) that happens to be using it?  Or maybe there's some shared library that gets used a lot all over the web?  Again, some data (eg. from HTTP Archive) could help clear up the uncertainty here and give us more confidence in breaking behavior.

[Bret Sepulveda]

I found foodviva.com because it was the only result on nerdydata.com. It claims to give results from the "top 100,000 websites" (whatever that means), but I would assume if something hyper-popular was using it it would have shown up that way. A test search shows that it is indeed indexing facebook, yahoo, qq, etc.

My gut says that the 0.15% is erroneous and the 0.01% is more accurate, but I can't explain the discrepancy.

I will try HTTP Archive and see what I find.

[Chris Harrelson]

The Use Counter in question (CssZoomReset) applies whenever zoom:reset appears in a style sheet, right? That doesn't necessarily mean that it applies to any elements on the page.

[Rick Byers]

Have you checked chromium code?  If the NTP or settings page or something was using it that might skew the numbers.

I didn't know of nerdydata.com, thanks!

[Chris Harrelson]

On Sat, Oct 1, 2016 at 5:10 AM, Rick Byers <rby...@chromium.org> wrote:

Have you checked chromium code?  If the NTP or settings page or something was using it that might skew the numbers.

On that subject, I observed that use counters are affected by not only the NTP but internal chrome:// pages like bookmarks. That greatly affected the UseCounter for -webkit-canvas when I was removing it. Should we exclude such pages, and also

exclude the NTP?

 

--
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+unsubscribe@chromium.org.

[PhistucK]

I really think they should be excluded. Internal usage should not affect deprecations or removals of web platform APIs.

In fact, I would expect the intent author to search the code base and fix those cases even before the intent is announced. Including the change lists in the intent will then show that there are alternatives (and how complex they are) to the to-be-deprecated-or-removed API.

☆PhistucK

[Rossen Atanassov]

@Rick The original motivation of my spec was to ideally deprecate the property. The reason why ‘reset’ and ‘document’ weren’t documented is simply because I was documenting what IE/Edge supports - ‘normal’ and <int>.

 

FWIW, our stats[1] show zoom: <int>; usage as 25% (basically zoom:1); as well as ‘reset’ and ‘document’ being very low (0.002%). I’d have to check on the freshness of the current stats but that’s not too far off from what I saw in the past when I wrote the spec.

 

My position on this is that we should still aim to eliminate the property if possible.

 

Cheers,

Rossen

 

[1] https://developer.microsoft.com/en-us/microsoft-edge/platform/usage/css/zoom

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

 

[Rick Byers]

Agreed.  I'm in the process of overhauling UseCounter metrics.  I'll include omitting internal pages from the new histogram.  There are some open questions on the details though (Eg. what about file://, chrome-extension://, etc) so I'd appreciate comments on the bug.

[Rick Byers]

Thanks Rossen.

That gives further evidence to the argument that our high usage metrics for zoom:reset are anomalous somehow.  If we can get some data to back this up, then I'd support matching Edge's behavior.

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

 

 

[PhistucK]

At the risk of sounding drastic and extreme, what about eliminating this entire property?

zoom: 1; was used to give "layout" to elements in old Internet Explorer (7 and below, if I recall correctly) and does basically nothing if no other zoom value were given for a parent element, right?

Only zoom: reset; and zoom: document; had different behavior even when there are no other zoom values, but this intent intends to eliminate them, so we are only left with zoom: normal; (which is zoom: 1;) and zoom: x; where x is not 1.

Since transform: scale(x); does the same as zoom: x; (right?), the only functionality loss is for elements that do not render CSS transformations (elements that are display: inline; and maybe a few others).

All of those cases can be use-counted to make sure there are unused... Anyone volunteers? :)

Upper limit for popular sites (not necessarily CSS declarations) -

https://nerdydata.com/search?regex=true&query=%7B%5B%5Cs%5Cr%5Cn%5D*%5Cbzoom%5B:%5Cs%5Cr%5Cn%5D%2B%5B2-9dnr%5D%5B2-9a-z%5D*

(The "dnr" part of the regular expression is funny, DNR is "do not resuscitate"!)

Upper limit for non only popular websites (not necessarily CSS declarations) -

https://nerdydata.com/search?regex=true&query=%7B%5B%5Cs%5Cr%5Cn%5D*%5Cbzoom%5B:%5Cs%5Cr%5Cn%5D%2B%5B2-9dnr%5D%5B2-9a-z%5D*&table=deepweb

☆PhistucK

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

 

 

[Rossen Atanassov]

@PhistucK, this was/is my exact proposal J

 

From: PhistucK [mailto:phis...@gmail.com]
Sent: Monday, October 3, 2016 10:44 AM
To: Rossen Atanassov <Rossen.A...@microsoft.com>
Cc: Chris Harrelson <chri...@chromium.org>; Rick Byers <rby...@chromium.org>; eae <e...@chromium.org>; blink-dev <blin...@chromium.org>; Bret Sepulveda <bs...@google.com>
Subject: Re: [blink-dev] Intent to deprecate and remove hidden zoom values

 

At the risk of sounding drastic and extreme, what about eliminating this entire property?

 

☆PhistucK

 

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

 

 

[Bret Sepulveda]

I didn't see any examples of zoom:reset being used on chrome:// pages, but I there are two layout tests: fast/css/zoom-font-size.html and fast/css-generated-content/table-with-scrollbar-corner.html, I have no idea if that would contribute to its usage data.

I found 78 examples of websites from HTTP Archive, thank you for that link. I didn't go through all of them, but a lot of those I sampled seemed to be vestigial CSS rules that didn't actually apply to any elements (25 of them are using exactly the same CSS file, and another 10 are using one CSS file mirrored to their domains). Here are the interesting examples I found:

happiestminds.com seems to be trying to use it to keep the scrolling banner a fixed size so you can't see the hidden parts of the banner. It doesn't really work though, even with zoom:reset on, since you can expand the window and it doesn't update the banner right away. Zooming in and out looks kinda broken as-is and disabling zoom:reset doesn't really help. But at least it's the correct size without zoom:reset.

ruinergame.com is using it as a blanket "disallow page zoom" by putting it on <html>. Even if you disable zoom:reset you still can't zoom the page, so it must be using some other trick too (one that works on Edge and Firefox, since those browsers also cannot zoom it).

asiancorrespondent.com is using zoom:reset in an @media block to only disallow zooming out. If you disable zoom:reset it looks fine zoomed out, so I don't really understand why.

patycantu.com is the only non-broken-looking usage I could find. There's a block of ads at the bottom of the page (I get an ad for "US Patriot Tactical" and "2016 Mazda 3", but I assume it's targeted). The rest of the page is at zoom:90% but the mazda ad has zoom:reset applied so that it fits correctly in the allotted space. Disabling zoom:reset make it take up slightly more space and thus get clipped. If you open the site in Edge and make the window too small you can see the same behavior, for reasons I don't quite understand.

Note that this means I was wrong about deprecating zoom:reset not affecting mobile safari, since it can override a parent element's zoom value (which was probably the intended use of it all along). But hardly anyone is using it that way.

 

☆PhistucK

 

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

 

 

 

[Rick Byers]

Bret, thanks for the detailed analysis and sorry for the delay on this thread - I just realized it was waiting for a response.

I looked at a couple of those pages also and I'm convinced by your analysis.  I support trying to match Edge.  Of course we should keep our eyes out for reports of breakage and reconsider if we hit anything substantial.

LGTM1 to deprecate for at least one milestone then remove.

Please file a separate OWP-Launch bug and chromestatus entry to track.

On Tue, Oct 4, 2016 at 6:10 PM, 'Bret Sepulveda' via blink-dev <blin...@chromium.org> wrote:

I didn't see any examples of zoom:reset being used on chrome:// pages, but I there are two layout tests: fast/css/zoom-font-size.html and fast/css-generated-content/table-with-scrollbar-corner.html, I have no idea if that would contribute to its usage data.

I found 78 examples of websites from HTTP Archive, thank you for that link. I didn't go through all of them, but a lot of those I sampled seemed to be vestigial CSS rules that didn't actually apply to any elements (25 of them are using exactly the same CSS file, and another 10 are using one CSS file mirrored to their domains). Here are the interesting examples I found:

happiestminds.com seems to be trying to use it to keep the scrolling banner a fixed size so you can't see the hidden parts of the banner. It doesn't really work though, even with zoom:reset on, since you can expand the window and it doesn't update the banner right away. Zooming in and out looks kinda broken as-is and disabling zoom:reset doesn't really help. But at least it's the correct size without zoom:reset.

ruinergame.com is using it as a blanket "disallow page zoom" by putting it on <html>. Even if you disable zoom:reset you still can't zoom the page, so it must be using some other trick too (one that works on Edge and Firefox, since those browsers also cannot zoom it).

asiancorrespondent.com is using zoom:reset in an @media block to only disallow zooming out. If you disable zoom:reset it looks fine zoomed out, so I don't really understand why.

patycantu.com is the only non-broken-looking usage I could find. There's a block of ads at the bottom of the page (I get an ad for "US Patriot Tactical" and "2016 Mazda 3", but I assume it's targeted). The rest of the page is at zoom:90% but the mazda ad has zoom:reset applied so that it fits correctly in the allotted space. Disabling zoom:reset make it take up slightly more space and thus get clipped. If you open the site in Edge and make the window too small you can see the same behavior, for reasons I don't quite understand.

Note that this means I was wrong about deprecating zoom:reset not affecting mobile safari, since it can override a parent element's zoom value (which was probably the intended use of it all along). But hardly anyone is using it that way.

[Chris Harrelson]

LGTM2

On Wed, Nov 9, 2016 at 6:56 AM, Rick Byers <rby...@chromium.org> wrote:

Bret, thanks for the detailed analysis and sorry for the delay on this thread - I just realized it was waiting for a response.

I looked at a couple of those pages also and I'm convinced by your analysis.  I support trying to match Edge.  Of course we should keep our eyes out for reports of breakage and reconsider if we hit anything substantial.

LGTM1 to deprecate for at least one milestone then remove.

Please file a separate OWP-Launch bug and chromestatus entry to track.

On Tue, Oct 4, 2016 at 6:10 PM, 'Bret Sepulveda' via blink-dev <blin...@chromium.org> wrote:

I didn't see any examples of zoom:reset being used on chrome:// pages, but I there are two layout tests: fast/css/zoom-font-size.html and fast/css-generated-content/table-with-scrollbar-corner.html, I have no idea if that would contribute to its usage data.

I found 78 examples of websites from HTTP Archive, thank you for that link. I didn't go through all of them, but a lot of those I sampled seemed to be vestigial CSS rules that didn't actually apply to any elements (25 of them are using exactly the same CSS file, and another 10 are using one CSS file mirrored to their domains). Here are the interesting examples I found:

happiestminds.com seems to be trying to use it to keep the scrolling banner a fixed size so you can't see the hidden parts of the banner. It doesn't really work though, even with zoom:reset on, since you can expand the window and it doesn't update the banner right away. Zooming in and out looks kinda broken as-is and disabling zoom:reset doesn't really help. But at least it's the correct size without zoom:reset.

ruinergame.com is using it as a blanket "disallow page zoom" by putting it on <html>. Even if you disable zoom:reset you still can't zoom the page, so it must be using some other trick too (one that works on Edge and Firefox, since those browsers also cannot zoom it).

asiancorrespondent.com is using zoom:reset in an @media block to only disallow zooming out. If you disable zoom:reset it looks fine zoomed out, so I don't really understand why.

patycantu.com is the only non-broken-looking usage I could find. There's a block of ads at the bottom of the page (I get an ad for "US Patriot Tactical" and "2016 Mazda 3", but I assume it's targeted). The rest of the page is at zoom:90% but the mazda ad has zoom:reset applied so that it fits correctly in the allotted space. Disabling zoom:reset make it take up slightly more space and thus get clipped. If you open the site in Edge and make the window too small you can see the same behavior, for reasons I don't quite understand.

Note that this means I was wrong about deprecating zoom:reset not affecting mobile safari, since it can override a parent element's zoom value (which was probably the intended use of it all along). But hardly anyone is using it that way.

[Philip Jägenstedt]

LGTM3

LGTM2

 

☆PhistucK

 

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

 

 

--
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.

[Philip Jägenstedt]

(I added this manually to https://bit.ly/blinkintents too. Missing colon.)

[Bret Sepulveda]

Thanks everyone. I filed an OWP launch bug and a chromestatus entry.

One question: is the preferred method of deprecation to add a console warning on use?

LGTM3

LGTM2

 

☆PhistucK

 

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

 

 

 

--
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+unsubscribe@chromium.org.

[Philip Jägenstedt]

Yes, add a use counter and then trigger the deprecation message in Deprecation.cpp, there are helpers to get consistent messages there.

LGTM3

LGTM2

 

☆PhistucK

 

 

☆PhistucK

 

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

 

 

 

--
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.

[PhistucK]

Why is the status, "No active development"? Are you not deprecating and removing it?

☆PhistucK

[pacheco...@gmail.com]