Implement Internet Explorer zoom property for css
Categories
(Core :: CSS Parsing and Computation, enhancement)
Tracking
()
People
(Reporter: martijn.martijn, Assigned: emilio)
References
(Depends on 8 open bugs, Blocks 2 open bugs, )
Details
(6 keywords, Whiteboard: [needs-wpt-?])
User Story
Would be good for GeckoView.
Attachments
(2 files)
Reporter | ||
Comment 3•18 years ago
|
||
Comment 4•18 years ago
|
||
Reporter | ||
Comment 5•18 years ago
|
||
Comment 6•18 years ago
|
||
Updated•18 years ago
|
Comment 7•17 years ago
|
||
Reporter | ||
Comment 8•16 years ago
|
||
Comment 10•15 years ago
|
||
Comment 11•14 years ago
|
||
Comment hidden (obsolete) |
Comment 13•14 years ago
|
||
Comment 14•13 years ago
|
||
Comment 15•13 years ago
|
||
Comment 16•13 years ago
|
||
Comment 17•13 years ago
|
||
Comment 18•13 years ago
|
||
Comment 19•12 years ago
|
||
Comment 20•12 years ago
|
||
Comment 21•12 years ago
|
||
Comment 22•12 years ago
|
||
Comment 23•12 years ago
|
||
Comment 24•12 years ago
|
||
Comment 25•12 years ago
|
||
Comment 26•12 years ago
|
||
Comment 27•12 years ago
|
||
Comment 28•12 years ago
|
||
Comment 29•11 years ago
|
||
Comment 30•11 years ago
|
||
Comment 31•10 years ago
|
||
Comment 32•10 years ago
|
||
Comment 33•10 years ago
|
||
Comment 34•10 years ago
|
||
Comment 35•10 years ago
|
||
Comment 36•10 years ago
|
||
Comment 39•10 years ago
|
||
Comment 40•10 years ago
|
||
Comment 41•10 years ago
|
||
Comment 42•10 years ago
|
||
Comment 43•10 years ago
|
||
Comment 44•10 years ago
|
||
Comment 45•9 years ago
|
||
Comment 46•9 years ago
|
||
Comment 47•9 years ago
|
||
Comment 48•9 years ago
|
||
Updated•9 years ago
|
Comment 49•9 years ago
|
||
Updated•9 years ago
|
Comment 50•9 years ago
|
||
Comment 53•8 years ago
|
||
Comment 54•8 years ago
|
||
Reporter | ||
Updated•8 years ago
|
Comment 55•8 years ago
|
||
Updated•8 years ago
|
Comment 56•8 years ago
|
||
Updated•8 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Updated•7 years ago
|
Comment 57•7 years ago
|
||
Comment 58•7 years ago
|
||
Updated•7 years ago
|
Comment 59•7 years ago
|
||
Comment 60•7 years ago
|
||
Comment 61•7 years ago
|
||
Updated•7 years ago
|
Comment 63•6 years ago
|
||
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Updated•6 years ago
|
Comment 65•6 years ago
|
||
See bug 1547409. Migrating webcompat priority whiteboard tags to project flags.
Assignee | ||
Comment 66•6 years ago
|
||
Note that this is not even so trivial, since some pages like the one in https://webcompat.com/issues/31557 (which right now work on release) use something like zoom
and -moz-transform
in the same rule.
Comment 67•6 years ago
|
||
Indeed, we might even have to detect if a site is using zoom, and disable moz-transform and other moz-specific hacks to some degree to achieve compat (assuming we cannot just remove moz-transform due to unrelated compat issues).
Updated•6 years ago
|
Comment 68•6 years ago
|
||
For testing reference, the few web platform tests I see using CSS zoom all seem to pass in Firefox, so further tests would appear to be needed. Thankfully I do see a fair number Blink web tests, as well as Blink and WebKit LayoutTests.
Updated•6 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Comment 69•5 years ago
|
||
A very good reason in my opinion is that it makes the implementation of some accessibility components a breeze.
As seen here (using Chrome or I.E 10+):
lviamerica.com
And discussed here:
https://css-tricks.com/forums/topic/emulating-browser-zoom-with-css-for-accessibility/
Updated•5 years ago
|
Updated•5 years ago
|
Updated•4 years ago
|
Comment 72•4 years ago
•
|
||
See the recent discussions about it
astearns: PROPOSED RESOLUTION: avoid specifying zoom as it stands, but we will if we have to, and a new proposal about a better zoom property would be a good use of time
https://github.com/w3c/csswg-drafts/issues/5623#issuecomment-712455201
And I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1142663
Comment 73•4 years ago
|
||
Note that as-is the resolution doesn't resolve our webcompat issue. It leaves us at the same place. Except if Blink team is willing to move forward with https://bugs.chromium.org/p/chromium/issues/detail?id=1142663
Updated•4 years ago
|
Updated•4 years ago
|
Updated•4 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 75•3 years ago
|
||
Hi,
I am only here to point out another user of 'document.body.style.zoom'. This website uses zoom to make text larger. Disregard the obvious bug within the work around of quoting '-moz-transform'. I will report that bug to the website.
- Navigate to https://medicare.highmark.com/view-plans?planType=Medicare%20Advantage
- Enter any zip code. I used 15106
- Click on the Text Resize Icon
Within zoomMe within https://medicare.highmark.com/etc.clientlibs/sxeaem/clientlibs/clientlib-base.min.js,
function zoomMe(zoomFactor) {
if (typeof zoomFactor === 'string' && zoomFactor.includes('%')) {
zoomFactor.replace('%', '');
zoomFactor = zoomFactor / 100;
}
document.body.style.zoom = zoomFactor
if (navigator.userAgent.includes('Firefox/')) {
document.body.style[-moz-transform] = 'scale(' + zoomFactor + ')';
}
}
Should I report to webcompat?
Comment hidden (advocacy) |
Comment 77•3 years ago
|
||
Hi Monkey,
(In reply to monkeyboyted from comment #75)
if (navigator.userAgent.includes('Firefox/')) { document.body.style[-moz-transform] = 'scale(' + zoomFactor + ')'; }
}
The bug is an easy fix and it is a site mistake. You did a correct analysis.
They probably do not need to use at all zoom. and probably could just use transform, which is supported by all browsers. You should contact them and you can tell me if you have been successful.
Should I report to webcompat?
You could on https://webcompat.com/issues/new
but you already did the job of diagnosing and maybe contacting. :) Thanks for this!
Comment 78•3 years ago
|
||
noise |
"Bug 390936 (csszoom) Opened 15 years ago. Updated 3 minutes ago".
This is an achievement of some sort. I'll comment again at the 20 year mark.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 79•3 years ago
|
||
(In reply to Karl Dubost💡 :karlcow from comment #77)
Hi Monkey,
(In reply to monkeyboyted from comment #75)
if (navigator.userAgent.includes('Firefox/')) { document.body.style[-moz-transform] = 'scale(' + zoomFactor + ')'; }
}
The bug is an easy fix and it is a site mistake. You did a correct analysis.
They probably do not need to use at all zoom. and probably could just use transform, which is supported by all browsers. You should contact them and you can tell me if you have been successful.Should I report to webcompat?
You could on https://webcompat.com/issues/new
but you already did the job of diagnosing and maybe contacting. :) Thanks for this!
Highmark released a fix but they left the browser specific check. Yes, the organization uses transform property
function zoomMe(zoomFactor) {
if (typeof zoomFactor === 'string' && zoomFactor.includes('%')) {
zoomFactor.replace('%', '');
zoomFactor = zoomFactor / 100;
}
document.body.style.zoom = zoomFactor
if (navigator.userAgent.includes('Firefox/')) {
document.body.style['transform'] = 'scale(' + zoomFactor + ')';
}
}
Comment 80•3 years ago
|
||
I hope to Firefox Implement Internet Explorer zoom property for css to 15 years ago.
This is an achievement of some sort. I'll comment again up to 16-30 year mark.
Credit to describe browser compatibility - https://developer.mozilla.org/en-US/docs/Web/CSS/zoom
Comment 81•3 years ago
|
||
To all those who say "transform" should be used: it's not the same behavior and therefore doesn't work in many scenarios. For me, the difference was that "zoom" multiplies, then rounds various sizes (like borders), whereas "transform" rounds then multiplies, which makes it impossible to have a border width of 0.3px and zoomed in 10x to make it similar to border width of 3px, for example. OK leaving aside the standard, why not just copy the implementation as it's done in WebKit as a stopgap measure?
Assignee | ||
Comment 82•3 years ago
|
||
Because the WebKit implementation is bogus, and reverse-engineering it without a clear spec is not going to create anything sane out of it. Also, because implementing this property will cause pages that right now work in Firefox (via -moz-transform, etc) to stop working, zoom doubly, etc.
For many of the use cases that zoom has if not all, you can use calc() and e.g. custom properties even though it might be a bit more effort.
Comment 83•2 years ago
|
||
Hi,
I am joining the discussion because I just discovered that the css property zoom is not supported by Firefox.
I developed a game on BGA in which one you could click a zoom button to open you player board in a larger dialog.
The player board is made up of many elements with relative and complexe positioning, this is why I choose to use the zoom property.
Please, let me show it on Chrome
https://imgur.com/a/J72tLMm
Zoom property is compatible with responsiveness.
(even if here it clearly needs a little fix on my side)
https://imgur.com/a/JuqdQdX
So on Firefox, the dialog is not zooming at all
https://imgur.com/a/L2zfXOA
Using -moz-transform is not completing doing the job
https://imgur.com/a/SifehrT
I hope I could use a wrapper element to force width with same aspect ratio but I am pretty I will have trouble to get it responsive.
The use case is not the same and I think this should be a standard.
Comment 84•2 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #82)
Because the WebKit implementation is bogus, and reverse-engineering it without a clear spec is not going to create anything sane out of it. Also, because implementing this property will cause pages that right now work in Firefox (via -moz-transform, etc) to stop working, zoom doubly, etc.
For many of the use cases that zoom has if not all, you can use calc() and e.g. custom properties even though it might be a bit more effort.
I understand that implementing the zoom property can break those sites that don't expect it to work in Firefox. But why not implement it as -moz-zoom? The new code will be able to use this, and compatibility with the old one will remain.
Updated•2 years ago
|
Comment 85•2 years ago
|
||
Firefox should support zoom. I expect to see Firefox support a feature that every other browser supports -- regardless of standards track.
https://developer.mozilla.org/en-US/docs/Web/CSS/zoom#browser_compatibility
This has been a bone of contention for 15 years. Enough is enough. Developers want it. Purists are against it for abstract purist reasons.
mozilla.org states:
"The non-standard zoom CSS property can be used to control the magnification level of an element. transform: scale() should be used instead of this property, if possible. However, unlike CSS Transforms, zoom affects the layout size of the element."
https://developer.mozilla.org/en-US/docs/Web/CSS/zoom
I think it’s not appropriate for you to recommend transform:scale
– it’s a different functionality, different behavior.
There are known issues with transform:scale
, to do with position and flow, with no easy workarounds. Particularly, subsequent element don't get repositioned to accomodate the transformed element. As your zoom
article states:
"...unlike CSS Transforms, zoom affects the layout size of the element."
These aren't bugs, they are by design: transform isn't supposed to keep elements in the flow. Zoom is. transform:scale simply doesn't provide the same functionality as zoom.
There are no simple workarounds to make transform:scale act like zoom. Positioning can be sort of fixed with transform:origin 00
, but no easy fix for the flow issue. In 2022, developers shouldn't need workarounds anyway.
Comment 86•2 years ago
|
||
I see this come up most often in the context of users reporting the Zoom controls are missing when using Excel online in Firefox:
Comment 87•2 years ago
|
||
I've manually analyzed 10 pages for CSS zoom, see https://docs.google.com/spreadsheets/d/1i7ErFvsRg9nwOfHTfeP7csPozjGZd0XKB-GXk1uhs4E/edit?usp=sharing
- 1 page has a minor visual difference and would be fixed by supporting zoom.
- 1 page would break by supporting zoom, unless we also unship -moz-transform (or make only one of them apply when both are specified on the same element).
- No impact for the other 8
(Same finding as in comment #67)
I did not test mobile, only desktop Firefox and desktop Chrome.
What is the feasibility of making -moz-transform have no effect if zoom is also specified?
Comment 88•2 years ago
|
||
(In reply to Simon Pieters [:zcorpan] from comment #87)
What is the feasibility of making -moz-transform have no effect if zoom is also specified?
If the scale factor in zoom
and -moz-transform: scale()
is the same, it would make sense to assume that the author only expected one to apply. Since this bug is for compatibility, it makes sense to prefer zoom
in that situation and apply only zoom
.
scale()
takes either one or two parameters, so if there are two parameters with different values, i.e., asymmetric scaling, then the author may have wanted a different behavior in Firefox and maybe zoom should be ignored in that case. ?
Assignee | ||
Comment 89•2 years ago
|
||
(In reply to Simon Pieters [:zcorpan] from comment #87)
What is the feasibility of making -moz-transform have no effect if zoom is also specified?
Depends on what you mean with "have no effect", but I think the short answer either way is "rather tricky and/or quirky".
Do you mean not parse it? Parse it and support it in the OM, but somehow not honor it? Both are tricky in different ways. Maybe something else?
For "not parse it", generally the question is "what would trigger it". Say we see zoom
, then -moz-transform
, do we then ignore all -moz-transforms
? With what granularity (for the whole page? For the same declaration block, ...)? What if we see -moz-transform
and then zoom
? Fixing that up to ignore the -moz-transform
at parse-time is not really possible.
For the "not applying it in some cases" (basically comment 88), some context: -moz-transform
right now is just a parse-time alias of transform
. If we do something like comment 88, then the "easy" way would be to ignore transform
as well. But I doubt that'd fly because I think zoom: 1; transform: scale(1);
could be something potentially appearing on the wild, plus it's another compat hack that we wouldn't be able to get rid of and it affects standard transform
. But if we decide to ignore -moz-transform
but not transform
, then it's even trickier because we'd need to either:
- Store both separately (they would no longer become aliases). Questions of what happens if you set
-moz-transform: <something>
thentransform: <something else>
(which can trivially happen as a result of CSSOM or what not) arise. - Make
-moz-transform
a shorthand oftransform
, that sets a magic bit that says "this transform list came from-moz-transform
". This bit wouldn't be reflected in serialization or anything else, and we'd use that to "ignore" transforms. That makesdiv.style.transform = div.style.transform
potentially change behavior which is kind of hilarious, but might be the "less bad" option.
Ignoring those transforms at runtime is still not trivial, because transforms have other side effects other than applying the scale and so on (e.g., it also creates a fixed-position containing block for descendants etc). So it'd be rather hacky internally.
I do wonder what amount of breakage other than zoom
would we find if we just unshipped -moz-transform
tho, perhaps trying to unship it on nightly for a while and see if we see any non-zoom-related breakage could be a path forward? Then we could eventually disable -moz-transform
and implement zoom
in one go.
Though that said, zoom
is still a huge mess as implemented in other browsers. e.g., it affects some CSSOM APIs like getComputedStyle
, but not others like getBoundingClientRect
, IIRC, and it's not even clear how it would really interact with others, or if that can ever be fixed... So I'd still be opposed to ship zoom without a spec for it that defines what works and what doesn't.
Comment 90•2 years ago
|
||
Thanks. Yeah, I agree "not parse it" is not viable. To make some sort of sense, it'd need to no longer be an alias to transform but its own property that is sometimes ignored (if zoom
or transform
is also specified on the same element).
Unshipping -moz-transform completely would indeed be cleaner, but I haven't checked what the breakage would be. This could probably be queried from httparchive with the tables in httparchive.experimental_parsed_css
, looking for rules that include -moz-transform
but not transform
or -webkit-transform
, and manually checking a handful. Testing on Nightly could also work but we might not get any bugs reported for only Nightly.
(Keeping my needsinfo to do this analysis.)
Comment hidden (admin-reviewed) |
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Updated•2 years ago
|
Comment 95•2 years ago
|
||
For your information, I did a review of the previous issue listed in the SeeAlso.
https://github.com/WebKit/standards-positions/issues/170#issuecomment-1530867635
Assignee | ||
Comment 96•1 years ago
|
||
Assigning to myself reflect the current state of things where:
- There's acknowledgement from the CSS Working Group that zoom is useful.
- It's unclear if it's implementable by Firefox or not due to the compat constraints.
- If turns out to be not implementable for us the working group would probably standardize it under some different name that all browsers could implement (tbd).
- So the main work items are prototyping it, see if/how terrible it is compat wise, see if we can move with Blink towards something saner (specially wrt getBoundingClientRect() and other CSSOM APIs), and depending on the outcome go back to the working group.
See https://github.com/w3c/csswg-drafts/issues/5623 for details and recent (last month) CSSWG discussions.
Comment 97•1 years ago
|
||
(I accidentally cleared my ni? -- see https://bugzilla.mozilla.org/show_bug.cgi?id=390936#c90)
Comment 98•1 years ago
|
||
I just want to give a little information on why I couldn't get transform
to support the use case I needed. I'm working on an email service, and the UI needs to scale wide emails down to fit on small screens. This is the code I have to do this:
const { width, height } = htmlContainer.getBoundingClientRect();
const { width: containerWidth } =
htmlContainer.parentElement.getBoundingClientRect();
const scale = containerWidth / width;
const rightMargin = width - width * scale;
const bottomMargin = height - height * scale;
if (scale < 1) {
htmlContainerStyles = `transform-origin: 0 0; transform: scale(${scale}); margin-right: -${rightMargin}px; margin-bottom: -${bottomMargin}px;`;
htmlContainerScaled = true;
} else {
htmlContainerStyles = '';
}
I'm using a scale
transform, and reducing the element width and height with matching negative margins that are calculated from the scale factor.
This works really well for email without images or email where the images are immediately loaded from cache, but when an image loads and changes the height of the htmlContainer
element, bottomMargin
is no longer accurate and I get extra white space in the bottom of the element. Since I can't listen for load
events for images (they don't bubble), I don't really have any solution here. Unfortunately, this means I have to use zoom
, and Firefox users won't benefit from this feature.
I hope it helps to share a use case that isn't covered by transform
.
Assignee | ||
Comment 99•1 years ago
|
||
Might be missing something, but why can't you use a ResizeObserver
observing htmlContainer
for that? Seems like that would be the obvious way to watch for changes to its size in a more general way. I guess there's the tricky bit of having to un-scale before measuring again, which is a bit subtle, but it should pretty much just work, unless I'm missing something.
Comment 100•1 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #99)
Might be missing something, but why can't you use a
ResizeObserver
observinghtmlContainer
for that? Seems like that would be the obvious way to watch for changes to its size in a more general way. I guess there's the tricky bit of having to un-scale before measuring again, which is a bit subtle, but it should pretty much just work, unless I'm missing something.
Actually, it does work, but unscaling and rescaling causes the page to scroll higher. So, if you're at the bottom of the email and an image loads, you end up getting scrolled part way up the email. That's better than nothing though, so I'm going to wrap that in an if (navigator.userAgent.includes('Firefox'))
. Thanks. :)
(I know I could save the scrollTop
and reset it after rescaling, but this is such an edge case, I think it's fine.)
Assignee | ||
Comment 101•1 years ago
|
||
(In reply to Hunter Perrin from comment #100)
Actually, it does work, but unscaling and rescaling causes the page to scroll higher. So, if you're at the bottom of the email and an image loads, you end up getting scrolled part way up the email. That's better than nothing though, so I'm going to wrap that in an
if (navigator.userAgent.includes('Firefox'))
. Thanks. :)
Sweet, but probably wrap it on a !CSS.supports("zoom: 2")
or something along those lines, please. Otherwise you're causing the kind of problem that I fear would prevent us from shipping zoom
to begin with :)
Assignee | ||
Comment 102•1 years ago
|
||
(And actually I guess you need the ResizeObserver
everywhere so that you deal with viewport / user zoom changes or what not, but that's probably more edge-case-y...)
Comment 103•1 years ago
|
||
PLEASE DO NOT UNDER ANY CIRCUMSTANCES CLOSE THIS ISSUE.
Instead, please push for making "zoom" an official standard to Google (Chrome, Edge, Android) and Apple (Safari, iOS) and anyone responsible.
Zoom is the only mechanism that:
- In Chrome/Edge can modify the "CSS reference pixel" size successfully (well, almost: apart from canvas, which doesn't scale the same way as other elements).
- Can be set with JavaScript (the scaling feature of browsers can't be modified with JavaScript).
- Can be set to an arbitrary percentage value (like 103%) (the scaling feature of browsers doesn't offer such flexibility, nor do the "device emulation" tools in F12).
My use case is that I want to set the browser size to physical size of iPhone (i.e. ~0.1 meters width) and maintain the iPhone's logical width of ~390 points in width). This can only be achieved by modifying the size of "CSS reference pixel".
What doesn't work:
- There are no extensions that would do this successfully (I tried a few and all didn't behave correctly).
- There are no tools in "device emulation".
- transform: scale(x) doesn't work the same as zoom.
What works:
- The native mechanism of browsers (but it doesn't offer arbitrary percentage, just 100%, 110%, 125% etc. and it has no per-element scaling like with "zoom").
- Zoom (except for canvas, which doesn't scale correctly in Chrome/Edge).
Please do not touch the "zoom" feature described here https://developer.mozilla.org/en-US/docs/Web/CSS/zoom (because it sounds like it could be removed) and please un-deprecate it. Or please implement an alternative mechanism (e.g. add to CSS "css-pixel-ratio: 1.04" instead of "zoom: 104%", which would do the trick or at least implement "any custom scaling like 103%" for browsers Chrome/Edge/Firefox/Safari).
Comment 104•1 year ago
|
||
(In reply to Simon Pieters [:zcorpan] from comment #90)
Unshipping -moz-transform completely would indeed be cleaner, but I haven't checked what the breakage would be. This could probably be queried from httparchive with the tables in
httparchive.experimental_parsed_css
, looking for rules that include-moz-transform
but nottransform
or-webkit-transform
, and manually checking a handful. Testing on Nightly could also work but we might not get any bugs reported for only Nightly.
Here are such pages, but also checking that zoom
is absent:
https://docs.google.com/spreadsheets/d/1sFB38_--yCEJQaeT58NtnFG_pkQl9dMAYRVJdJgHhMQ/edit?usp=sharing
I think the best next step for the compat analysis is to implement zoom
and remove -moz-transform
and then manually checking the top pages in the list, comparing before/after, to see if anything is obviously broken by removing -moz-transform
.
Comment 105•1 year ago
|
||
(In reply to Simon Pieters [:zcorpan] from comment #104)
https://docs.google.com/spreadsheets/d/1sFB38_--yCEJQaeT58NtnFG_pkQl9dMAYRVJdJgHhMQ/edit?usp=sharing
I think the best next step for the compat analysis is to implement
zoom
and remove-moz-transform
and then manually checking the top pages in the list, comparing before/after, to see if anything is obviously broken by removing-moz-transform
.
I've now looked at the first 100 with zoom
enabled and -moz-transform
disabled. Nothing is obviously broken by not supporting -moz-transform
for these pages, which is encouraging. There were 2 sites that have some issues with how zoom
is implemented (rows 42 and 56).
- https://www.ufs.ac.za/ Uses both zoom and -moz-transform for .SpotText. The size is correct, but the positioning is a bit off in Firefox Nightly compared to stable Firefox/Chrome.
- https://www.superhry.cz/ Uses both zoom and -moz-transform for .iconsA. The icons are implemented with a sprite and then set background-position to get the correct icon shown. In Firefox Nightly zoom doesn't affect intrinsic sizes for CSS background images, which breaks this page.
Adding ni? for me to look at pages using zoom
generally to try to find any other issues.
Comment 106•1 year ago
|
||
In the comment above, for https://www.ufs.ac.za/ the positioning is off because it overrides left
and bottom
in @-moz-document url-prefix()
(hack to target Gecko). Not much we can do about it except file a webcompat bug.
Checking the "red" pages in https://github.com/WebKit/standards-positions/issues/170#issuecomment-1530867635 in Firefox Nightly with zoom
enabled and -moz-transform
disabled (comparing with stable Firefox with default prefs).
- https://www.seedr.cc/ looks ok
- https://bonk.io/ uses
zoom
without fallback (e.g. in "quick play mode selection" window), so now renders as intended. 🎉 - http://ask8ball.net/ header now looks as intended. 🎉
- https://salah.com/ uses
zoom
without fallback (text size), so now renders as intended. 🎉 - https://mori-m-foundation.or.jp/english/ius2/gpci2/ with an Android UA string via devtools uses
zoom
on the root element, so now renders as intended. 🎉 - https://game.granbluefantasy.jp/ mobile via devtools uses
zoom
on the root element, so now renders as intended. 🎉
Checking the first 20 pages in "Adoption of the feature on top sites" in https://chromestatus.com/metrics/feature/timeline/popularity/3578 (no comment for pages where there's no impact):
- https://2ez.bet/ uses
zoom: 0.95
onbody
, so now renders as intended. 🎉 - https://apostasesportiva.vip/ uses
zoom
and-moz-transform
on.flag_small
but expects background image intrinsic size to be affected byzoom
so is now broken 🔴
Conclusions:
- Supporting
zoom
and not supporting-moz-transform
is clearly a net improvement in terms of web compat. - No issues found from dropping
-moz-transform
support. zoom
needs to affect background image size.- Still unknown if
zoom
needs to affectfont-size
(whenfont-size
is not specified) and natural dimensions ofimg
(whenwidth
/height
are not specified), but probably safer to match Chromium/WebKit.
Assignee | ||
Comment 108•10 months ago
|
||
See intent to ship thread:
https://groups.google.com/a/mozilla.org/g/dev-platform/c/2xo3_A8as4E
Comment 109•10 months ago
|
||
What’s the target version for shipping: 125?
Assignee | ||
Comment 110•10 months ago
|
||
No, 126 most likely.
Comment 111•10 months ago
|
||
Comment 112•10 months ago
|
||
bugherder |
Comment 113•10 months ago
|
||
:emilio could you consider nominating this for a release note? (Process info)
Assignee | ||
Comment 114•10 months ago
|
||
Release Note Request (optional, but appreciated)
[Why is this notable]: Long-standing web compatibility fix
[Affects Firefox for Android]: yes
[Suggested wording]: The CSS zoom property has been enabled by default, following lots of web compatibility work, and standardization work in the CSSWG.
[Links (documentation, blog post, etc)]: https://drafts.csswg.org/css-viewport/#zoom-property
Comment 115•10 months ago
|
||
Thanks, added to the Fx126 nightly release notes, please allow 30 minutes for the site to update.
Keeping the relnote-firefox flag as ? to keep it on the radar for inclusion in the final Fx126 release notes.
Comment 116•10 months ago
|
||
I just noticed that <h1 style="zoom: 10">Ten</h1>
doesn’t work while <p style="zoom: 10">Ten</p>
works just fine in Beta 126.0b2 and Nightly 127.0a1. Both Chrome and Safari zoom text in both cases. It seems like a bug in the implementation.
Assignee | ||
Comment 117•10 months ago
|
||
(In reply to Vadim Makeev from comment #116)
I just noticed that
<h1 style="zoom: 10">Ten</h1>
doesn’t work while<p style="zoom: 10">Ten</p>
works just fine in Beta 126.0b2 and Nightly 127.0a1. Both Chrome and Safari zoom text in both cases. It seems like a bug in the implementation.
This is tracked in bug 1892676 now, but the nice thing to do would've been to file a separate bug, a lot of people do not pay too much attention to closed bugs :)
Updated•9 months ago
|
Comment 118•9 months ago
|
||
Related issues and pull requests
Updated•9 months ago
|
Updated•5 months ago
|
Description
•