- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 21 Jul 2023 19:00:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``Revisiting standardization of the `zoom` property ``, and agreed to the following: * `RESOLVED: add "zoom" as a real interoperable thing` * `RESOLVED: Add the zoom property to the device adaptation / viewport spec` <details><summary>The full IRC log of that discussion</summary> <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...<br> <myles> chrishtr: reaching out to microsoft office and google docs<br> <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<br> <myles> chrishtr: Microsoft says it's possible to migrate away, but it's a lot of work<br> <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)<br> <Rossen_> One clarification about Microsoft Excel position - besides the work the main objection and concern is driven by undesirable perfromance degradation<br> <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<br> <myles> chrishtr: It just happens as a natural course of things<br> <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<br> <flackr> q+<br> <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<br> <myles> chrishtr: There are some that get a little worse, but not that bad. Gmail and Excel were the ones that were most problematic<br> <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<br> <emilio> q+<br> <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<br> <myles> into supporting this, because responsive design that exists already makes that easy to do<br> <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)<br> <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<br> <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<br> <myles> astearns: the fixes you'd apply are just around the JS APIs that give you layout results?<br> <myles> chrishtr: Exactly. yes<br> <myles> chrishtr: I didn't find anything wrong with the way it works visually<br> <astearns> ack flackr<br> <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?<br> <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<br> <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<br> <myles> chrishtr: I did verify 2 days ago that it does multiply and does more zooming on top<br> <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<br> <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<br> <myles> flackr: I know I saw a case where this wasn't true, but maybe it was with frames?<br> <myles> Rossen_: Yes, or maybe auto or percentage<br> <myles> chrishtr: I think it makes sense not to multiply percentage widths. That has better responsive design results.<br> <myles> chrishtr: My evidence: That's what browser zoom does and people seem to like it<br> <astearns> ack emilio<br> <Rossen_> ack emilio<br> <myles> emilio: you mentioned not all engines support browser zoom like this. In gecko, this is a different CSS to device pixel ratio<br> <myles> emilio: I have a couple questions, but they are more implementation related<br> <TabAtkins> i was also going to ask about calc()<br> <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<br> <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().<br> <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?<br> <myles> iank_: for lengths, if you've got a simple calc (Apx + B%) it will scale A but not B<br> <myles> iank_: And it can be more complex too<br> <myles> chrishtr: Right. emilio, you mentioned the gecko implementation is to make all CSS values bigger...<br> <myles> emilio: not quite<br> <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<br> <myles> emilio: That's the browser zoom, not the zoom property<br> <myles> iank_: in gecko's behavior, it applies to the whole page - it can't apply to a subtree<br> <myles> emilio: which makes sense - it doesn't make sense to change the meaning of a CSS pixel in the middle of an element<br> <myles> chrishtr: AFAICT what you just described is equivalent to having set zoom: on the HTML element<br> <myles> chrishtr: and then changing the width of the viewport to be divided accordingly<br> <myles> chrishtr: So you get text to flow around<br> <myles> fantasai: Well, gecko's browser zoom won't affect any JS APIs<br> <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<br> <myles> emilio: That's not a special case - the viewport is a fixed amount of device pixels wide. This just picks a different value<br> <myles> chrishtr: The visual behavior users see, and the JS APIs, are exactly the same for both browsers<br> <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<br> <florian> q?<br> <myles> iank_: I think this is why everything gets unzoomed on the way out. Using offsets<br> <myles> iank_: that makes those cases nonexistent<br> <florian> q+<br> <myles> emilio: That only works if the zoom is applied to the root element<br> <myles> chrishtr: Right. As applied to the root element, i think the behavior is the same<br> <astearns> ack fantasai<br> <myles> iank_: There are some subtle inconsistencies. Firefox can make up fractional pixels on the viewport.<br> <myles> emilio: Sure, possibly<br> <myles> fantasai: What's the computed value of zoom if you have nested zooms?<br> <myles> chrishtr: The zoom of yourself (unmultiplied)<br> <astearns> ack florian<br> <smfr> q+<br> <flackr> Yes it was frames where i saw zoom not included: https://jsbin.com/jibiwev/edit?html,output<br> <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?<br> <SebastianZ> Big +1 to florian.<br> <myles> florian: You have similar questions. Transforms give you zooming - it's the same question but harder<br> <astearns> ack smfr<br> <myles> smfr: One difference between layout affecting transforms and zoom is interactions with minimum font size. chrishtr, what's the interaction there?<br> <myles> chrishtr: zoom is conditionally applied on top, and will make the fonts as large or small as the developer wants<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to step up to the original question<br> <myles> fantasai: to zoom out a lot, the original question is "do we want to standardize this property"<br> <hober> q+<br> <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<br> <astearns> ack hober<br> <myles> hober: to speak directly to what elika said: you said "want"<br> <myles> hober: i don't "want" to but we probably have to for compat reasons. We probably do have to write somethign down<br> <chrishtr> q?<br> <chrishtr> q+<br> <myles> astearns: If we have to write something down, is this something that gecko would be willing to implement?<br> <florian> q+<br> <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<br> <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"?<br> <myles> emilio: yes<br> <fantasai> s/not/Firefox/<br> <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<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to react to hober<br> <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<br> <myles> dbaron: If you're gecko and you implement zoom you'll probably fix some sites and break other sites<br> <astearns> ack chrishtr<br> <myles> chrishtr: i sympathize with the "what to do" and the work to fix this problem. Make the web more interoperable in this way<br> <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<br> <myles> chrishtr: I have a suggestion in the issue but i'm certain i didn't get it all right<br> <myles> chrishtr: If you think i'm wrong, please tell me<br> <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.<br> <astearns> ack florian<br> <emilio> q+<br> <chrishtr> q<br> <chrishtr> qq+<br> <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<br> <astearns> ack chrishtr<br> <Zakim> chrishtr, you wanted to react to florian<br> <dholbert> q+<br> <myles> florian: If we decide layout-affecting-transforms are the way forward, we can spend more time on that<br> <emilio> q- later<br> <astearns> ack fantasai<br> <florian> s/it doesn't make a different/it does make a difference/<br> <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<br> <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.<br> <myles> astearns: <agrees><br> <myles> fantasai: <agrees again><br> <myles> fantasai: Another question: it seems like we have 2 implementations that can't remove it<br> <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<br> <fantasai> s/want/need/<br> <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?<br> <astearns> ack dholbert<br> <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)<br> <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)<br> <myles> chrishtr: that might work. A new name that does the same thing ... I bet office and gmail would immediately adopt it<br> <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<br> <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<br> <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<br> <myles> iank_: The idea is sites will slowly move away from zoom over time<br> <myles> iank_: Authors would migrate from zoom to content-zoom<br> <fantasai> +1 iank_<br> <flackr> Crazy thought, can gecko ship zoom and remove -moz-transform at the same time?<br> <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<br> <myles> hober: it would be interesting to have an experiment of disabling -moz-transform at the same time.<br> <myles> emilio: yeah.<br> <myles> fantasai: you can do that with @supports<br> <astearns> q?<br> <myles> emilio: If we implement zoom then we have to disable -moz-transform. I'm pretty sure of that<br> <myles> emilio: the main issue of zoom is it literally changes the meaning of a CSS pixel<br> <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<br> <flackr> q+<br> <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.<br> <emilio> ack emilio<br> <astearns> ack emilio<br> <astearns> ack flackr<br> <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.<br> <myles> flackr: This is part of working it out and figuring out what standardizing it means<br> <astearns> ack fantasai<br> <Zakim> fantasai, you wanted to zoom out again<br> <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?<br> <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<br> <myles> astearns: If ladybird wants to render gmail and office 365, they have to do zoom<br> <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<br> <fremy> we are not gonna standardize -moz-transform, emilio ;)<br> <myles> emilio: a new browser could, in theory, implement -moz-transform<br> <myles> emilio: what is the objective of this property? to be web compatible? I dunno<br> <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<br> <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<br> <myles> astearns: Proposed resolution: we specify zoom.<br> <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<br> <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<br> <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<br> <myles> fantasai: Deprecation means it works but authors are encouraged not to use it<br> <myles> fantasai: We can deprecate things<br> <flackr> layout affecting scale transform is very similar to zoom - it's possible they end up being the same<br> <myles> astearns: Any other opinions to specify it as deprecated?<br> <bemathwi> q+<br> <myles> chrishtr: a bunch of developers say they want it. shouldn't be deprecated<br> <SebastianZ> q+<br> <hober> qq+<br> <astearns> ack hober<br> <Zakim> hober, you wanted to react to fantasai<br> <astearns> ack bemathwi<br> <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<br> <myles> hober: "reasonable behavior" is too high a bar to hold the web to<br> <myles> bemathwi: as far as the voting as speccing for deprecated, microsoft would like to see it specced, but not as deprecated.<br> <astearns> ack SebastianZ<br> <dholbert> q+<br> <dholbert> q-<br> <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<br> <astearns> ack dholbert<br> <myles> dholbert: yes. If we spec'ed it as deprecated, we would do it because we'd spec a replacement that's better<br> <myles> dholbert: Does that address Microsoft's concerns?<br> <myles> bemathwi: If there is a simple replacement, that would be OK<br> <myles> bemathwi: We'd have to have a sufficient or better replacement for it<br> <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.<br> <myles> astearns: Proposed resolution: Add zoom to a specification<br> <myles> chrishtr: which one?<br> <myles> astearns: Proposed resolution as a real interoperable thing<br> <myles> RESOLVED: add "zoom" as a real interoperable thing<br> <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<br> <myles> florian: device adaption might be the right place, ....<br> <myles> fantasai: we renamed it to viewport and removed everything that isn't viewport<br> <myles> fantasai: we haven't published it yet so it technically has both names right now<br> <myles> florian: OK<br> <flackr> q+<br> <astearns> ack dbaron<br> <astearns> ack flackr<br> <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<br> <myles> fantasai: Please keep it that way<br> <myles> dbaron: Not a strong opinion<br> <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<br> <iank_> place it in CSS2 - it was from that era :P<br> <myles> fantasai: They have to be different anyway. Scale can be similar, but rotate & others are quite different<br> <myles> fantasai: What zoom is doing now and what actual layout-affecting transforms do are quite different<br> <myles> florian: even if we worked on layout-affecting-transforms, we could move zoom there when we get there.<br> <myles> astearns: It can move later. People don't have opinions about the viewport spec, so let's propose that for resolution<br> <SebastianZ> q+<br> <myles> RESOLVED: Add the zoom property to the device adaptation / viewport spec<br> <myles> fantasai: Can we add chrishtr as an editor of that spec?<br> <florian> s/might be the right place, ..../might have been the right place, if it wasn't such a mess/<br> <myles> fantasai: you've dug into this issue a lot and would be a good issue a lot<br> <myles> chrishtr: <grimaces> sure, happy to<br> <fremy> q+<br> <astearns> ack fremy<br> <astearns> ack SebastianZ<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5623#issuecomment-1646125737 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 21 July 2023 19:00:47 UTC