Revisiting standardization of the zoom property
#5623
Comments
|
There are a lot of issues with Blink's / WebKit's implementation of zoom, including their behavior with stuff like getBoundingClientRect(), etc, last time I looked at it. zoom also has some very weird effects like affecting the intrinsic sizing of images and such even when no Here's a super-trivial test-case:
This is just like, the beginning of the issues with zoom, I've seen a lot of bugs go by the Chromium's bug tracker related to it, and the Blink / WebKit implementation is extremely hacky (IMO). So unless this gets very very very well defined (and my guess is that doing that is going to be very hard because WebKit's implementation is very ad-hoc and patchy in a lot of places), I'd be opposed to do this. cc @karlcow |
For reference that's https://bugzilla.mozilla.org/show_bug.cgi?id=1589766. The main idea behind that was to keep sites that used stuff like: basically keep working. My gut feeling is that to implement Another quirk that you don't learn until you try that is that |
|
Thanks for those pointers! Sounds like there are two core objections:
I did go through crbug to see I could pull out a signal of the breadth of issues and tagged the ones that I found (searched "css zoom" and skimmed the titles, so probably not exhaustive): I did a similar exercise in WebKit's bugzilla but did not discover anything unique (though again I could have missed something). Certainly the In any case, I think this is worth having a broader discussion to get consensus on next steps, so tagging for TPAC. |
|
The CSS Working Group just discussed The full IRC log of that discussion<myles> Topic: zoom!<astearns> github: https://github.com//issues/5623 <myles> dlibby: Last time this was discussed as 5 years ago. The zoom property came from IE. It was picked up by webkit / blink. <myles> dlibby: it's a bit hacky tbh in the way it's implemented. multiplies the used values by a factor. Comes with a factor of bugs. Gecko doesn't implement it, so they've been running into compat issues <myles> dlibby: There have been attempts to implement in terms of transform / transform-origin. It fixed some content, but didn't fix everything <myles> dlibby: We should try to standardize this. What appetite is there for documenting existing bugs / odd behavior vs trying to fix them. <myles> dlibby: Broader context: From MS, there are a few properties that have been looking at zoom as a low-cost way of zooming in on a webkit. They use it and get good results, and haven't had to rearchitect their app / change their layout structure. <myles> dlibby: Others' thoughts? <myles> emilio: I made my comment in the issue. I would not be a fan of standardizing the current behavior. It's extremely wrong. <myles> emilio: There's a bunch of quirks that exist for compat. I only found out by chance. Like zoom affecting intrinsic sizing of some elements but not others, or zoom:0 = zoom:1, because why not. It feels to me like the property is really odd b/c it's a property that affects the computed style of pretty much all lengths, including font size, which is terrible. Ot <myles> emilio: It's one of the biggest compat issues we have to fix. But we might break more content than we fix. If it was me, I would try to remove it from Chromium. But that's not a big [missed]. That may require Chromium implementing -moz-transform, which isn't great. it's a mess. I would be skeptical standardizing this as-is right now. <myles> astearns: I don't think there would be much utility in documenting the existing weirdness in CSS-space. I would be much more interested if someone had a solution they wanted to have implementations move toward. Something that was interoperable and didn't have quirks <myles> florian: I agree the current thing is messy, but it's used. If you want to write a browser that works with the web, you need this thing. That's what the usage data tells us. If's being used, it should be known how it works. <emilio> q+ <astearns> ack emilio <myles> florian: I am not sure it's only being used for its primary purpose. Maybe it's used *for* its quirks. Maybe it depends on its quirks. I believe they no longer care strongly about this, but Bloomberg could have used transforms, but font-rendering was different than that, and this is a quirk, and they were desired by Bloomberg. If we can't get rid of it, we should write down what it is <myles> emilio: I would argue that you don't necessarily need to implement zoom to render the web. There's content that either depends on .... I think it would be interesting to disable the property in Chrome and see what breaks and what works in Firefox. The 2 solutions are prefixed -moz-transform + no zoom, or zoom + no prefix -moz-transform <myles> emilio: You don't want double-scaling which sucks <myles> florian: Is moz-transform cleaner? <myles> emilio: -moz-transform is an alias to transform. <dlibby> q+ <myles> fantasai: Would Chrome be able to remove zoom and add -moz-transform as an alias of transform? <astearns> ack dlibby <fremy> q+ <myles> dlibby: That might be worth exploring. The behavior is not identical between a scale transform and a zoom. To pursue something that would provide similar functionality sounds like there might be some interest in doing something like that from the group? Or at least no clear opposition? But that's an interesting experiment in Chromium - understanding the impact of turning off zoom. <myles> dlibby: I don't know if there's precedence, thought. I'd have to consult with others. The idea is interesting. <myles> florian: There is precedence for setting in stone things with odd names with vendors in them. Maybe not -moz- specifically though. <myles> fantasai: It would be better for the web if we did that because it's one less quirky weird unspecified thing that needs to be embedded in the platform, if it's just an alias. If we can have a zoom feature that does what people want, it would be a good way forward. If it can't be removed, we have to spec it. <astearns> ack fremy <fantasai> s/it can't/legacy zoom can't/ <myles> fremy: one question: The zoom property can, if you have grid + some elements, the zoom property, zoom:200%, it not only scales the element but also changes the size of the tracks. <myles> florian: It is layout-affecting transforms. <myles> fremy: You can't achieve that with transform <jensimmons> q+ <myles> florian: The way that zoom affects layout is weird. Can we remove the weird one, or do we have to spec it <myles> fremy: Can we redefine how zoom works that's sane? <myles> fremy: Can we look at this? What is the minimum amount of things that makes zoom useful and sane, but are more powerful than transforms. <fantasai> s/The way that zoom/Layout-affecting zoom is useful and we should have a feature that does that. However, the way that legacy zoom/ <myles> fremy: If you don't know what all the tricks are, it's scary to implement, but if we all agree on something similar and that works, it's a safer bet than something nobody understands <myles> florian: If we could do this, that would be good. I believe we had looked and concluded we couldn't change it. It's strange, but the sites we looked at relied on its weirdness <myles> astearns: right. <astearns> ack jensimmons <heycam> q+ <myles> jensimmons: For a long time I've thought one of the thigns that was not exciting about transforms and motion-path is none of them affect sizing / calculation, especially for calculating flow. If you make something bigger or move it over, it doesn't affect anything around it. It's an interesting space. Zoom is one of the qualities we might want to look at about making transforms affect sizing and layout. I hate when the answer to a small problem is <myles> "let's make something incredibyl complicated" but that feels like the right direction. <myles> jensimmons: zoom is unspecified and has total lack of interop. <dbaron> I think we had a working group resolution to pursue layout-affecting transforms. :-/ I remember an extensive discussion of it in a meeting -- and I remember SteveZ was there. <myles> jensimmons: It was trying to do everything in one property. We should break it down and say "actually what we really want is have layout-affecting transformations" or "maybe there should be alternative ways that fonts should be rendered" <astearns> ack heycam <myles> heycam: To follow-on from jensimmons, I'm curious dlibby what the specific things that these authors are trying to get out of it, and why regular transforms were not sufficient. <emilio> q+ <smfr> q+ <jensimmons> btw, I made this demo while listening to see what's different between zoom & transform scale: https://codepen.io/jensimmons/pen/gOMMJMz <astearns> zakim, close queue <Zakim> ok, astearns, the speaker queue is closed <myles> dlibby: One of the compelling use cases was outlook web access to zoom in the reading pane for your emails. These emails were coming in with arbitrary styles / content / sizing, so enabling jsut that section, but no horizontal overflow, zoom gave them a low-cost way of doing it. "hey it could work" it keeps the layout constrained in the inline direction. They've been happy with results in Safari and Chrome and Edge so far. That's the main use case. <myles> dlibby: There were a few other use cases that were less compelling. <myles> dlibby: This one is the most compelling to me. <astearns> ack emilio <myles> emilio: If you're zooming arbitrary content, zoom doesn't work. Percentages don't get scaled. Which is one of the quirks of the zoom property. I guess for email it kinda works because most emails are fixed sizes, but that's a very specific use case to justify adding this with the existing quirks. <astearns> ack smfr <dbaron> https://lists.w3.org/Archives/Member/w3c-css-wg/2007OctDec/0267.html at least recorded an action to post a proposal for layout-affecting transforms <myles> smfr: Safari's command-plus zooming behavior is built on top of the zoom property. Makes images and text bigger while reflowing. Transforms aren't what you want. <myles> emilio: Control-plus in gecko affects the CSS px scale. and viewport. <myles> myles: We also have that zoom <myles> smfr: That's what we have, it changes the size of css px <myles> emilio: command-plus is interoperable, it just changes the size of a CSS px. But it's complicated / messy, maybe it's a mix of the two. <myles> astearns: dbaron posted a link where we wanted to make layout-affecting transforms before <myles> 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 <myles> dlibby: Good discussion. Thanks. <myles> dlibby: This is a clear path forward that ideally does not specifying the current behavior. |
|
Based on TPAC discusssion, closing this issue out as there is no support in the WG for specifying |
|
@dlibby- I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1142663 feel free to modify or rephrase it. |
Is there a gh issue or other place to comment on? We're relying on both zoom and scale in our implementation of a browser-based design product, and would be happy to document our use case there if that's of any help. The Chromium bug @karlcow posted appears to be more specific, and the MapML initiative somewhat orthogonal. |
|
@maltenuhn you are welcome to do it here. |
|
Vivliostyle is also relying on zoom, to solve the issue Minimum font size setting in Chrome causes ruby font size problem. I admit that using See the following test sample, testing Result screenshot on Chrome: On Chrome, with the default setting of minimum font size, ruby is displayed typographically correctly only when zoom is used. (And on Firefox, only This zoom usage should never be recommended for normal web pages. However, for typographic apps (for print, in particular) running in browsers, Chrome's zoom property is still needed to workaround Chrome's limitations. |
|
That seems like a Chrome bug that should be reported to them. In fact, I'd argue that the fact that zoom can be used to bypass the minimum font size in Chrome is a bug. Firefox fixed the interaction between min font size and ruby in https://bugzilla.mozilla.org/show_bug.cgi?id=1165538. |
|
@emilio Thanks for the suggestion, I reported https://bugs.chromium.org/p/chromium/issues/detail?id=1195041 |
|
Why is there so much opposition to this? I think it's a really good way of implementing high accessibility userstyles, although it is established that other userstyle features such as |
|
@sndst00m The way zoom currently works is probably now required for web compatibility - we can’t improve the way it works without breaking pages that rely on its current behavior. And its current behavior is too weird and inconsistent to standardize and recommend for implementation. But there is no opposition to creating a new layout-affecting transform. It would just likely be a really big thing to get to. @dlibby- have you had a chance to open a new issue for this? |
|
Okay, thanks for suggesting the new property and letting 1% of the internet stay "weird" 😄 |
|
FWIW Gmail uses zoom on mobile emails to force parts of them to be responsive, removing it without having a transform-effecting-layout would not be ideal. |
|
I think a plausible path forward is incremental changes to the Webkit and Chromium implementation of |
To me, this behavior makes sense. It seems that values are returned in transformed coordinate system, where |
|
Zoom is very useful when showing documents. Transform doesn't work well. Yes current implementation is hacky - that's because it's not standardized. This conversation is a catch 22. This property is not standardized, so the implementations are hacky, so we cannot standardize. |
|
Was an issue defined for a standardised layout (flow-affecting) transform property? |
|
Reopening to discuss #5623 (comment) further. (Please reopen in the future when adding new actionable comments.) |
We can break the catch 22 by creating a entirely new specification from the core functional requirement Then adding the current behaviors that are both: Think of the second step as a sort of progressive enhancement. |
|
@zm-cttae I for one would be perfectly happy with a new property, which works "like" The most important aspect in my use case is the "automatic" scaling of all measurements, such as |
|
Let's note also that transform origin and perspective origin will need their coord offsets scaled too :) |
|
Here are some additional thoughts based on my research into zoom, as part of my effort to potentially deprecate and remove CSS zoom from Chromium. The research involved reading the Mozilla issue, relevant Chromium issues, comments on this issue (i.e. #5623) analyzing a number of sites, and conversations with Gmail engineers. Compat risks:
It may not be feasible to get all of these fixed. Use cases I found that were compelling to me:
Chromium Implementation notes
Chromium Implementation known issues that should be fixed
SummaryIn general, I found that CSS zoom's superpower is a reliable way to make text, and the elements around it, zoom in or out, while retaining responsive design accessibility principles such as reflow within the content and to adjacent or wrapping content elements, and ensuring content is always readable. You can polyfill it by injecting custom variables into the entire document or with CSS pre-processors, but that may not be feasible for imported external content. I think the visual implementation of zoom in Chromium works very well, and is consistent across all elements. Evidence includes:
The only significant problems with CSS zoom that I'm aware of are the inconsistent/illogical JS API behavior. (@emilio mentioned other complications that I'm not seeing, so I might be missing something?) My recommendation
(+) The equivalent feature in Google Sheets / Docs uses custom code that modifies element styles to multiply their sizes by the desired zoom factor. (++) Imperfect prototype version with transforms - note the background color is wrong in some areas. (+++) |
I'm not totally sure what the weird effects are. @emilio could you clarify? |
|
For what it's worth, #1487 is open for having layout-affecting transforms. |
A rabbit hole of an issue that could bikeshed us here! |
|
The CSS Working Group just discussed
The full IRC log of that discussion<myles> chrishtr: following the previous resolution to not standardize css zoom, but instead try to remove it from chrome and webkit, chrishtr sent the intent to remove, gathered feedback, and got use-cases. Use-counter, chromestatus...<myles> chrishtr: reaching out to microsoft office and google docs <myles> chrishtr: the results are: it is, in fact, used if you go the menu in excel, and change the zoom, it uses the zoom css property on a parent element on all of the things in the spreadsheet. The equivalent thing in google sheets changes the inline styles of the elments to make them bigger by a specified factor <myles> chrishtr: Microsoft says it's possible to migrate away, but it's a lot of work <myles> chrishtr: gmail has another case where html emails are not usually responsive. If an email has a width of x pixels that's wider than the width of your phone, the options are for the webview to show horizontal scrollbars, or make content smaller. The horizontal scrollbars is a bad, so making the content smaller is better (you can see the whole conversation in a single vertical swipe) <Rossen_> One clarification about Microsoft Excel position - besides the work the main objection and concern is driven by undesirable perfromance degradation <myles> chrishtr: They render it, measure it, then apply zoom to shrink it down. Zoom works better than transform. Zoom already has responsive design concepts - all it's doing is multiplying CSS numbers by something, and letting the usual block flow (flexbox, etc.) work. Adjacent elements outside the zoom but next to it will do the right thing. Inside it, relative sizing generally works <myles> chrishtr: It just happens as a natural course of things <myles> chrishtr: A third use case on gmail desktop - you can create templated emails. There's a wizard that allows you to choose which template you want. On the right it shows a preview. The preview has external HTML that displays it, and they shrink it down to fit on the screen. That probably could be done with transform, but it's hard to get right. But it's trivial with CSS zoom because it naturally fits existing responsive design concepts of the web <flackr> q+ <myles> chrishtr: The chrome use counter is high in general which is concerning. In other sites, there aren't many where removing zoom substantially messes up the site <myles> chrishtr: There are some that get a little worse, but not that bad. Gmail and Excel were the ones that were most problematic <myles> chrishtr: I found examples of an a11y widget within the page where you press a button to make content bigger, and they don't use iframes, but instead use inline html <emilio> q+ <myles> chrishtr: For implementation notes, some of the comments earlier in the issue said that emilio mentioned it would be complicated. The implementation in chromium isn't very complicated. I could be wrong though. At the used style time, it multiplies all the non-percentage lengths by a number. Also, this is how browser zoom is implemented on desktop with command-plus and command-minus. That works well for arbitrary pages which haven't put any thought <myles> into supporting this, because responsive design that exists already makes that easy to do <myles> chrishtr: as far as i can tell even if you just put it on the root and it propagates to sub elements (e.g. gmail preview thing) <myles> chrishtr: All the JS APIs is pretty weird. getBoundginClientRects() is goofy - the values are divided for no good reason. It's so that there can be a round-trip in/out of the style sheet. BUT i have no evidence that any sites actually care about these javascript APIs. Sites really just want the visual output to be bigger or smaller so people can see it, rather than running JS to inspect it <myles> chrishtr: We should standardize this feature. It acheives compelling use cases. A11y of external content that naturally fits within existing responsive design features of the web. If you use transform, there are tricks and it's difficult to get right in non-simple situations <myles> astearns: the fixes you'd apply are just around the JS APIs that give you layout results? <myles> chrishtr: Exactly. yes <myles> chrishtr: I didn't find anything wrong with the way it works visually <astearns> ack flackr <myles> flackr: Multi-layout applications lay out, calculate the zoom, then apply it. That sounds like overflow. Do we need overflow:zoom that automatically does this? <myles> flackr: The zoom property doesn't accumulate the ancestor zoom; it gets clobbered. So how does this interact with browser zoom? It's supposed to stack <myles> chrishtr: For the first, it could be useful to explore. "Fit this content within its container, and enforce it by zooming it so it fits" Gmail probably wants it. This has probably been considered before <myles> chrishtr: I did verify 2 days ago that it does multiply and does more zooming on top <myles> Rossen_: That is correct. Let's say you have a couple of containers that are all 100px wide by specified width, and you apply zoom:2 on both of them. ..... <loses steam> I am with chrishtr on this - the values should multiply <myles> Rossen_: In your example, if the browser sets zoom:200 and there is a widget that is internally zooming, the contents of the widget will be 2x what it would be if the browser's zoom didn't exist <myles> flackr: I know I saw a case where this wasn't true, but maybe it was with frames? <myles> Rossen_: Yes, or maybe auto or percentage <myles> chrishtr: I think it makes sense not to multiply percentage widths. That has better responsive design results. <myles> chrishtr: My evidence: That's what browser zoom does and people seem to like it <astearns> ack emilio <Rossen_> ack emilio <myles> emilio: you mentioned not all engines support browser zoom like this. In gecko, this is a different CSS to device pixel ratio <myles> emilio: I have a couple questions, but they are more implementation related <TabAtkins> i was also going to ask about calc() <myles> emilio: I'm not sure how you fix the JS APIs. Depending on what you want, if you want the zoomed or unzoomed value, you want the stuff to round-trip, so from the point of view of the elemtn you're querying, you want the zoomed thing, but from the point of view of stuff outside of that, you want the unzoomed thing. I don't know how to fix that. I don't see how can you accumulate those use cases <myles> emilio: i had another question about calc() like if you have mixed lengths and percentages... my understanding is that zoom works at computed value time, not used value type. So it interacts with getComputedStyle(). <myles> emilio: i think that's weird for inheritance. But I'd need to think more about it. If you inherit an explicit width, but you also have zoom:2, do you get 2x the width? Probably "no" but maybe? <myles> iank_: for lengths, if you've got a simple calc (Apx + B%) it will scale A but not B <myles> iank_: And it can be more complex too <myles> chrishtr: Right. emilio, you mentioned the gecko implementation is to make all CSS values bigger... <myles> emilio: not quite <myles> emilio: the behavior is similar to what the zoom property does, but basically when you convert CSS pixels to device pixels - after resolving percentages - that scales different depending on the browser zoom value <myles> emilio: That's the browser zoom, not the zoom property <myles> iank_: in gecko's behavior, it applies to the whole page - it can't apply to a subtree <myles> emilio: which makes sense - it doesn't make sense to change the meaning of a CSS pixel in the middle of an element <myles> chrishtr: AFAICT what you just described is equivalent to having set zoom: on the HTML element <myles> chrishtr: and then changing the width of the viewport to be divided accordingly <myles> chrishtr: So you get text to flow around <myles> fantasai: Well, gecko's browser zoom won't affect any JS APIs <myles> chrishtr: Browser zoom in chromium also doesn't affect APIs except the client width of the viewport is reduced by the appropriate amount. Which is probably the case in gecko because otherwise text will overflow <myles> emilio: That's not a special case - the viewport is a fixed amount of device pixels wide. This just picks a different value <myles> chrishtr: The visual behavior users see, and the JS APIs, are exactly the same for both browsers <myles> emilio: Didn't you mention that the browser internal zoom cannot behave like CSS zoom exactly. Because if you divide by zoom, getBoundingClientRect would be affected <florian> q? <myles> iank_: I think this is why everything gets unzoomed on the way out. Using offsets <myles> iank_: that makes those cases nonexistent <florian> q+ <myles> emilio: That only works if the zoom is applied to the root element <myles> chrishtr: Right. As applied to the root element, i think the behavior is the same <astearns> ack fantasai <myles> iank_: There are some subtle inconsistencies. Firefox can make up fractional pixels on the viewport. <myles> emilio: Sure, possibly <myles> fantasai: What's the computed value of zoom if you have nested zooms? <myles> chrishtr: The zoom of yourself (unmultiplied) <astearns> ack florian <smfr> q+ <flackr> Yes it was frames where i saw zoom not included: https://jsbin.com/jibiwev/edit?html,output <myles> florian: it seems all the level of intricate details are very very specific to zoom only and a while back we had also discussed having layout-affecting-transforms. If we had those we would need to solve the same issue in a more generic way. If we had layout-affecting-transforms we would have zoom-only. Are we going to work on the more generic issue? <SebastianZ> Big +1 to florian. <myles> florian: You have similar questions. Transforms give you zooming - it's the same question but harder <astearns> ack smfr <myles> smfr: One difference between layout affecting transforms and zoom is interactions with minimum font size. chrishtr, what's the interaction there? <myles> chrishtr: zoom is conditionally applied on top, and will make the fonts as large or small as the developer wants <astearns> ack fantasai <Zakim> fantasai, you wanted to step up to the original question <myles> fantasai: to zoom out a lot, the original question is "do we want to standardize this property" <hober> q+ <myles> fantasai: if the answer is no, we don't have to worry about of this. If the answer is yes, we have to have issues for all of these <astearns> ack hober <myles> hober: to speak directly to what elika said: you said "want" <myles> hober: i don't "want" to but we probably have to for compat reasons. We probably do have to write somethign down <chrishtr> q? <chrishtr> q+ <myles> astearns: If we have to write something down, is this something that gecko would be willing to implement? <florian> q+ <myles> emilio: if we need to standardize it, then sure... zoom is one of hte biggest compat things, but it's also a compat thing even if we implemented it. WE'd need to think about existing content that is nonzoomed in firefox but zoomed everywhere else. not super convinced that implementing zoom would be a compat win for us. But who knows <myles> fantasai: Are you saying the compat situation is "if you are chrome or blink you have to implement zoom and if you are not you can't"? <myles> emilio: yes <fantasai> s/not/Firefox/ <myles> emilio: There are sites that use prefix transforms for gecko and zoom for everything else. if gecko were to just implement zoom then we'd break a bunch of sites. If we ijmplemented zoom and ship prefixed transforms, we'd break less sites, but probably not 0 sites <astearns> ack dbaron <Zakim> dbaron, you wanted to react to hober <myles> emilio: if you're webkit and ship zoom, then you'll break sites... if you are webkit and ship zoom and ship prefixed transforms then you'll break websites too... its a bad situation <myles> dbaron: If you're gecko and you implement zoom you'll probably fix some sites and break other sites <astearns> ack chrishtr <myles> chrishtr: i sympathize with the "what to do" and the work to fix this problem. Make the web more interoperable in this way <myles> chrishtr: on behalf of chromium we can do whatever we can to help as much as we can. If we standardize this, then i think first we should make the thing that has the .... define what we think the JS APIs should be, chrome can make the change, demonstrate that it's not going to break sites (which i don't think it will) and that at least that aspect is de-risked <myles> chrishtr: I have a suggestion in the issue but i'm certain i didn't get it all right <myles> chrishtr: If you think i'm wrong, please tell me <myles> chrishtr: I found that sites that were originally broken in firefox on the web compat website were fixed over time. But in Excel, I know the zooming feature just isn't supported on Firefox. <astearns> ack florian <emilio> q+ <chrishtr> q <chrishtr> qq+ <myles> florian: re "want" vs "need"... it doesn't make a different. If "need" then that affects the answers to the detailed questions ... if it's just for compat then we don't need really good solutions, we just need compat solutions <astearns> ack chrishtr <Zakim> chrishtr, you wanted to react to florian <dholbert> q+ <myles> florian: If we decide layout-affecting-transforms are the way forward, we can spend more time on that <emilio> q- later <astearns> ack fantasai <florian> s/it doesn't make a different/it does make a difference/ <myles> chrishtr: Some developers think zoom is super useful. The developers i spoke to from Microsoft and google thought that zoom did exactly what they wanted with 1 line of code, which was great from their perspective <myles> fantasai: If we expect people to imeplment it based on our specs, then we need to do a good job. It will/is a part of the core web platform. We can't half-ass it. <myles> astearns: <agrees> <myles> fantasai: <agrees again> <myles> fantasai: Another question: it seems like we have 2 implementations that can't remove it <myles> fantasai: we can shove it in an appendix for compatibility and deprecate it (and list patent considerations) but it raises the question about if there's a new layout engine (servo?) that wants to consume web content. If they want to implement it, there should be a spec. They shouldn't have to reverse engineer it from chrome and webkit <fantasai> s/want/need/ <myles> chrishtr: I wasn't around for the layout/transforms discussions in the past, and i don't know what additional use cases there are. What are the use cases for those that zoom does not satisfy? <astearns> ack dholbert <myles> dholbert: it seems webkit and blink can't unship/change zoom. Gecko may not be able to ship zoom under any situation due to compat (sites specifying both zoom and -moz-transform) <myles> dholbert: we might want to address the valid use cases for Microsoft Office with a new property with a new name that won't have compat fallout. If there's a new great version of zoom that gecko can't implement, gecko will be stuck (without breaking web content that depends on us not implementing anything) <myles> chrishtr: that might work. A new name that does the same thing ... I bet office and gmail would immediately adopt it <myles> astearns: we could have a new name like zoom-content, and UAs can alias either zoom: or -moz-transform to it. Then nobody has to change anything <myles> dholbert: if we consider zoom as a legacy -webkit- prefixed property, as not truly part of CSS, we could explain it as part of a new thing. The new thing can be similar without legacy burdens and implementable everywhere <myles> chrishtr: I don't think that this plan would solve the interop problem with gecko. As long as you have a thing that's exposed, people can use it and it will never go away <myles> iank_: The idea is sites will slowly move away from zoom over time <myles> iank_: Authors would migrate from zoom to content-zoom <fantasai> +1 iank_ <flackr> Crazy thought, can gecko ship zoom and remove -moz-transform at the same time? <myles> astearns: I like the idea of this escape hatch. Why don't we keep this as a separate issue until we get data from gecko about the compat situation they would be in <myles> hober: it would be interesting to have an experiment of disabling -moz-transform at the same time. <myles> emilio: yeah. <myles> fantasai: you can do that with @supports <astearns> q? <myles> emilio: If we implement zoom then we have to disable -moz-transform. I'm pretty sure of that <myles> emilio: the main issue of zoom is it literally changes the meaning of a CSS pixel <myles> emilio: the way the JS APIs behave may be the most reasonable, but i don't think it's reasonable. You have 2 elements and if one is in zoomed subtree then you cannot reason about its position <flackr> q+ <myles> emilio: Copying a position from one to the other means you can't just copy the zoom but the effective zoom. it's not great. <emilio> ack emilio <astearns> ack emilio <astearns> ack flackr <myles> flackr: i was playing with it and in the zoomed space all of the JS APIs behave as if your pixels are larger. This is similar to what you get with transform. The main difference is getBoundingClientRect() would be changed by a transform, but isn't changed by zoom, which is odd. <myles> flackr: This is part of working it out and figuring out what standardizing it means <astearns> ack fantasai <Zakim> fantasai, you wanted to zoom out again <myles> fantasai: Zooming out again, do we need to spec this? We have 2 implementations, they can't remove it. We might need to add a 3rd, we're not sure. Should we be speccing this? If we add it to a spec, we can work out all these details. We can make a new name. Or aliases. But, regardless, we have an old thing that needs spec. Do we spec it or not? <myles> hober: the additional information i'd love to know, which no one in this room can provide, is - ultimately the reason we spec things is it's possible to enter the browser engine market. I'd love to know from Andreas who is writing a new browser engine "do you find that you need to do something here?" If the answer is "yes", then we should spec EVEN IF firefox can never implement <myles> astearns: If ladybird wants to render gmail and office 365, they have to do zoom <myles> emilio: if they want zooming on their spreadsheets. A bunch of websites would be broken if you have either -moz-transform or zoom. -moz-transform- is a trivial alias so it's trivial to implement <fremy> we are not gonna standardize -moz-transform, emilio ;) <myles> emilio: a new browser could, in theory, implement -moz-transform <myles> emilio: what is the objective of this property? to be web compatible? I dunno <myles> emilio: I wouldn't be opposed to putting the zoom details in a spec and try to make the behavior be reasonable. At one point when i was testing stuff there were disagreements about how blink and webkit did some zoom stuff <myles> astearns: if we're going to take a resolution to specify zoom, then we need an action too to create lots of issues about what that specification is going to take <myles> astearns: Proposed resolution: we specify zoom. <myles> fantasai: If we don't like it, we can spec it into an appendix and say it's deprecated. If we like it, we can un-deprecate it <myles> florian: The future of this property could become an alias of something we invent in the future. This would encourage people to use the new thing and decrease compat pressure on gecko <myles> astearns: I would be opposed to immediately deprecating the thing. The only path forward is to specify it. If we end up with engines that are not able to implement, then we go with the deprecation or replacement strategy <myles> fantasai: Deprecation means it works but authors are encouraged not to use it <myles> fantasai: We can deprecate things <flackr> layout affecting scale transform is very similar to zoom - it's possible they end up being the same <myles> astearns: Any other opinions to specify it as deprecated? <bemathwi> q+ <myles> chrishtr: a bunch of developers say they want it. shouldn't be deprecated <SebastianZ> q+ <hober> qq+ <astearns> ack hober <Zakim> hober, you wanted to react to fantasai <astearns> ack bemathwi <myles> emilio: Except for use cases where you don't care how it interacts with other things, then sure. But it has as ton of quirks <myles> hober: "reasonable behavior" is too high a bar to hold the web to <myles> bemathwi: as far as the voting as speccing for deprecated, microsoft would like to see it specced, but not as deprecated. <astearns> ack SebastianZ <dholbert> q+ <dholbert> q- <myles> SebastianZ: the use cases are there. We want to specify zoom as deprecated because there are quirks. Then, follow-on with layout-affecting transforms which would generally be the replacement for the zoom property <astearns> ack dholbert <myles> dholbert: yes. If we spec'ed it as deprecated, we would do it because we'd spec a replacement that's better <myles> dholbert: Does that address Microsoft's concerns? <myles> bemathwi: If there is a simple replacement, that would be OK <myles> bemathwi: We'd have to have a sufficient or better replacement for it <myles> astearns: Proposal: Let's specify it as deprecated or replacing becomes a new issue. We resolve today that we are specifying zoom and doing our best to remove as many of the quirky bits as we can as we specify it. All the quirky bits become issues, all the things about the JS APIs become issues. We resolve we are specifying zoom as a real part of the web platform and see how it goes. <myles> astearns: Proposed resolution: Add zoom to a specification <myles> chrishtr: which one? <myles> astearns: Proposed resolution as a real interoperable thing <myles> RESOLVED: add "zoom" as a real interoperable thing <myles> fantasai: Tab and I think it should go in the viewport / device adaptation spec. Not the transforms spec. It's a very different model than what this is doing. That would be like gluing 2 different specs that have nothing to do with each other <myles> florian: device adaption might be the right place, .... <myles> fantasai: we renamed it to viewport and removed everything that isn't viewport <myles> fantasai: we haven't published it yet so it technically has both names right now <myles> florian: OK <flackr> q+ <astearns> ack dbaron <astearns> ack flackr <myles> dbaron: Another possibility: Zoom has a lot of interactions with stuff in CSSOM views spec. Though it doesn't have properties in it right now <myles> fantasai: Please keep it that way <myles> dbaron: Not a strong opinion <myles> flackr: I'm not super familiar with the layout transform thing people are talking about. if there was a chance they could be the same thing, shouldn't they go in the same spec <iank_> place it in CSS2 - it was from that era :P <myles> fantasai: They have to be different anyway. Scale can be similar, but rotate & others are quite different <myles> fantasai: What zoom is doing now and what actual layout-affecting transforms do are quite different <myles> florian: even if we worked on layout-affecting-transforms, we could move zoom there when we get there. <myles> astearns: It can move later. People don't have opinions about the viewport spec, so let's propose that for resolution <SebastianZ> q+ <myles> RESOLVED: Add the zoom property to the device adaptation / viewport spec <myles> fantasai: Can we add chrishtr as an editor of that spec? <florian> s/might be the right place, ..../might have been the right place, if it wasn't such a mess/ <myles> fantasai: you've dug into this issue a lot and would be a good issue a lot <myles> chrishtr: <grimaces> sure, happy to <fremy> q+ <astearns> ack fremy <astearns> ack SebastianZ |
|
I discovered the odd quirk of zoom not inheriting that I was thinking of after the fact. Descendant frames reset the zoom rather than getting the zoomed layout from the iframe element, e.g. https://jsbin.com/jibiwev/4/edit?html,output Both of the frames in this example have the same zoom on their contents despite the top one being within a |
|
Reposted to Wikimedia Phabricator here - ⚓ T342528 RfC on use cases of standardized zoom CSS property in Wikimedia wikis |
|
FWIW I have an implementation in Firefox in bug 1854441, but I filed #9397 and #9398 on things that make no sense to me. |
|
I'd like to add the following use-case of morphing from one view to the next: https://codepen.io/Schepp/pen/LYNZzWY If not with |
|
Does anyone know what ended up happening? Is the |
Zoom is now standardized (with some changes from how it's currently implemented in Chromium and WebKit). No browsers ship the standard yet (two are working on it). |
As far as I can tell the last time this was discussed in depth was back in 2015. At the time there appeared to be consensus that it would have been better had the property never existed, and there was not a strong preference for standardizing the current implementations. However, usage on the web appears to be non-zero and relatively steady — I'd like to open another discussion on whether there is a path towards standardization.
Here is Chrome's UseCounter data for the percentage of pageloads where a zoom value that is not 1 (or 100%) is applied to any element during the style cascade. As of the opening of this issue it stands around 1% of pageloads.
I'm thinking that this would start mainly as a documentation effort (@atanassov went through this exercise previously here) — given that IE and legacy Edge are on their way out, I'm cautiously optimistic that the WebKit and Blink implementations are similar enough that there will only be a handful of behavioral differences to reconcile, if any.
One item of particular note is that Gecko does not implement zoom (see https://bugzilla.mozilla.org/show_bug.cgi?id=390936). There are unique challenges given that authors have used a
-moz-transform: scale(n)fallback in the absence of zoom. Additionally, I believe there were attempts to implement zoom in terms of transforms but that was not sufficient to alleviate compat concerns.In terms of use cases, similar to how browsers have both pinch zoom and page zoom, this does seem like a useful primitive for web authors (and clearly there is some usage today). For full disclosure, there are Microsoft web properties that have expressed interest in using the zoom property as a low-cost solution for zooming in certain portions of webpages. They don't want to introduce overflow in the inline direction or redesign their implementation, and the zoom property has provided an almost trivial way to improve these scenarios for their users (they're experimenting with this in production today).
@chrishtr also pointed me to previous discussions related to defining an interaction model driven by maps scenarios (#5275). Perhaps that would be another lens through which to have discussions about the use case, but I don't think that would move the needle for the large number of pages that use a property that is currently implemented by more than one browser.
The text was updated successfully, but these errors were encountered: