- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 29 Apr 2026 16:16:17 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-zoom] CSS Zoom and SVG`. <details><summary>The full IRC log of that discussion</summary> <kbabbitt> emilio: historical behavior for svg in webkit and blink has been to apply a transform to the viewbox<br> <kbabbitt> ... css zoom in firefox behaves as the regular css zoom property does<br> <kbabbitt> ... scales lines widths etc but not percentages<br> <kbabbitt> ... the CSS spec question in the issue about whether length properties are affected by zoom, I think the answer is yes<br> <kbabbitt> ... and I don't think that needs spec change<br> <kbabbitt> ... whether attributes are zoomed, answer should also be yes<br> <kbabbitt> ... ones that are mapped and not should be consistent<br> <kbabbitt> .. that leaves the question of whether getBBox and getCTM should be affected<br> <kbabbitt> ... I think the proposed resolutions are sensible<br> <kbabbitt> ... there's some compat discussion that I'm not familiar with<br> <kbabbitt> ... when implementing css zoom in firefox we got bug reports for things that were broken<br> <kbabbitt> ... props not scaled and such<br> <kbabbitt> ... don't recall any compat report that has survived so I think the behaviors here are somewhat compatible<br> <kbabbitt> astearns: questions before we dig into proposed resolutions?<br> <kbabbitt> ... first one is about length properties and emilio, you assert there isn't a spec change needed?<br> <kbabbitt> emilio: I don't think so, I don't think you need anything special for zoom to affect length property<br> <kbabbitt> astearns: ok, and philip said this is based on existing text<br> <kbabbitt> ... other questions are for the SVG spec, so perhaps we could just record our agreement with his initial proposal and let SVG take those on as proposed edits?<br> <kbabbitt> vinay: SVG group does meet regularly to resolve things<br> <kbabbitt> ... I'm one of the folks who just joined these meetings of SVG working group<br> <kbabbitt> ... curious why we need this zoom on internal elements of SVG instead of just using scale?<br> <kbabbitt> astearns: my naive understanding is that we have the zoom property and we should define the interaction between zoom applied to SVG and its internal attributes<br> <kbabbitt> ... and considerations<br> <kbabbitt> vinay: there's some challenges around it being a problem when we use SVG as a foreignObject via use attribute<br> <kbabbitt> ... we can discuss this futher in SVG WG<br> <kbabbitt> ... in case someone has data points I can take, please let me know<br> <kbabbitt> emilio: use is very weird but ... my understanding is that so long as the zoom value in the SVG subtree is not changed, as long as you have consistend zoom throughout SVG tree<br> <kbabbitt> ... it should be similar to scaling, right?<br> <kbabbitt> ... main difference with use elements is ... blink used to but I think we fixed it ... weird model where style of use elements comes from original element, that may be what causes issue?<br> <kbabbitt> ... would need to look at specific test cases that are problematic<br> <kbabbitt> vinay: same for me as well<br> <kbabbitt> ... last comment talks about it, scaling does it for position of element as well<br> <kbabbitt> ... zoom might be expected to work differently<br> <sgill> q+<br> <kbabbitt> ... this will be better suited to be discussed in SVG WG<br> <astearns> ack fantasai<br> <kbabbitt> ... where folks might know of more nuances around it<br> <astearns> ack sgill<br> <kbabbitt> sgill: was wondering with zooming and scaling ... how would these two things interact? for the CSS aspect of it, would it be enough to say that zoom only affects length and evertything else is handled by scaling?<br> <kbabbitt> emilio: don't think you want to mix scaling and zooming that way<br> <kbabbitt> ... depends on what you mean by scaling, but zoom effectively scales<br> <kbabbitt> ... cannot do graphic scaling, mix and matched with zoom scaling, beause then you get weird results<br> <kbabbitt> sgill: ok, wasn't sure what the interaction between these two things would be<br> <kbabbitt> emilio: as far as gecko behavior goes, we effectively just treat SVG attributes the same as SVG length properties<br> <kbabbitt> ... there are some SVG things that need special handling like ? and such that also need to be scaled by zoom<br> <ChrisL> q+<br> <kbabbitt> ... but it all seems to work out<br> <emilio> s/?/paths<br> <kbabbitt> ... d attribute and so on needs to be scaled by zoom<br> <astearns> ack ChrisL<br> <kbabbitt> ChrisL: agree that SVG group should be the one that solves this but I don;t think we're ready to. make that ask yet<br> <kbabbitt> ... need to be clear what we're asking, and what the back compat constraints are<br> <kbabbitt> ... don't feel we have that yet, would like to see a little more discussion before we start making SVG specific recommendations<br> <kbabbitt> ... CSS specific ones, I htink we're in a good place and we should fix our specs the way we're saying<br> <kbabbitt> astearns: I think that makes sense, wasn't suggesting we resolve on wanting these SVG spec changes, was more the recommendations on the original comment seem reasonable<br> <kbabbitt> ... ask the SVG WG to discuss and figure out the ramifications<br> <kbabbitt> ... in this group we're probably not the right people to discuss all the ramifications of these changes<br> <kbabbitt> ... while I agree this needs more discussion, I'm not sure it needs this group's time, a lot would be guesswork on our part<br> <kbabbitt> ... my suggestion is we leave this issue as a thing we'd like the SVG group to take up<br> <kbabbitt> ... figure out whether suggestions in original comment seem reasonable, they seem reasonable to us<br> <kbabbitt> vinay: would like to add 2 things, first is we have some use cases for this, that might influence SVG group to take steps to incorporate this in their spec<br> <kbabbitt> ... also if we agree on how we;re handling this in CSS, that influences SVG groups' handling a lot<br> <kbabbitt> astearns: we do have how we think zoom should affect the length properties<br> <kbabbitt> ... don't know if there's anything else about how CSS handles zoom that you;d like as input?<br> <kbabbitt> emilio: I think SVG 1 had a lot of weirder implications because use was more magic and styles could be copied around<br> <kbabbitt> ... SVG 2 makes this better with shadow trees, rest should fall out of that<br> <kbabbitt> astearns: any other comments on this issue?<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10490#issuecomment-4345513573 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 29 April 2026 16:16:18 UTC