- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Mon, 19 Oct 2020 21:33:51 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `zoom!`. <details><summary>The full IRC log of that discussion</summary> <myles> Topic: zoom!<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/5623<br> <myles> dlibby: Last time this was discussed as 5 years ago. The zoom property came from IE. It was picked up by webkit / blink.<br> <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<br> <myles> dlibby: There have been attempts to implement in terms of transform / transform-origin. It fixed some content, but didn't fix everything<br> <myles> dlibby: We should try to standardize this. What appetite is there for documenting existing bugs / odd behavior vs trying to fix them.<br> <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.<br> <myles> dlibby: Others' thoughts?<br> <myles> emilio: I made my comment in the issue. I would not be a fan of standardizing the current behavior. It's extremely wrong.<br> <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<br> <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.<br> <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<br> <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.<br> <emilio> q+<br> <astearns> ack emilio<br> <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<br> <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<br> <myles> emilio: You don't want double-scaling which sucks<br> <myles> florian: Is moz-transform cleaner?<br> <myles> emilio: -moz-transform is an alias to transform.<br> <dlibby> q+<br> <myles> fantasai: Would Chrome be able to remove zoom and add -moz-transform as an alias of transform?<br> <astearns> ack dlibby<br> <fremy> q+<br> <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.<br> <myles> dlibby: I don't know if there's precedence, thought. I'd have to consult with others. The idea is interesting.<br> <myles> florian: There is precedence for setting in stone things with odd names with vendors in them. Maybe not -moz- specifically though.<br> <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.<br> <astearns> ack fremy<br> <fantasai> s/it can't/legacy zoom can't/<br> <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.<br> <myles> florian: It is layout-affecting transforms.<br> <myles> fremy: You can't achieve that with transform<br> <jensimmons> q+<br> <myles> florian: The way that zoom affects layout is weird. Can we remove the weird one, or do we have to spec it<br> <myles> fremy: Can we redefine how zoom works that's sane?<br> <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.<br> <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/<br> <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<br> <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<br> <myles> astearns: right.<br> <astearns> ack jensimmons<br> <heycam> q+<br> <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<br> <myles> "let's make something incredibyl complicated" but that feels like the right direction.<br> <myles> jensimmons: zoom is unspecified and has total lack of interop.<br> <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.<br> <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"<br> <astearns> ack heycam<br> <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.<br> <emilio> q+<br> <smfr> q+<br> <jensimmons> btw, I made this demo while listening to see what's different between zoom & transform scale: https://codepen.io/jensimmons/pen/gOMMJMz<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <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.<br> <myles> dlibby: There were a few other use cases that were less compelling.<br> <myles> dlibby: This one is the most compelling to me.<br> <astearns> ack emilio<br> <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.<br> <astearns> ack smfr<br> <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<br> <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.<br> <myles> emilio: Control-plus in gecko affects the CSS px scale. and viewport.<br> <myles> myles: We also have that zoom<br> <myles> smfr: That's what we have, it changes the size of css px<br> <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.<br> <myles> astearns: dbaron posted a link where we wanted to make layout-affecting transforms before<br> <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<br> <myles> dlibby: Good discussion. Thanks.<br> <myles> dlibby: This is a clear path forward that ideally does not specifying the current behavior.<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-712455201 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 October 2020 21:33:54 UTC