Decide what to do with zoom and pan

The zoomAndPan features from SVG 1 are not implemented in browsers as initially proposed. The section is still in SVG 2, however.

We either need commitments from implementers to add zoom & pan control, or need to significantly revise/remove this section.

If it hasn't been implemented, I would prefer dropping it. The idea is not a bad one, but it would look very different if it were proposed today (maybe more similar to meta viewport).

Agreed.

Agree that as written now it should be dropped. Will take some effort to remove from the spec so we'll mark it as 'at risk' for now.
Addressed in commit 7432043

There is support for the zoomAndPan property in Firefox though there's not much to the implementation given there's no native zooom and pan UI. The only use would be for some kind of zoom and pan add on or control to check the zoomAndPan state to see whether to disable itself.

Instead of zoomAndPan, could a script event for zoom level change be an alternative?

AFAIK, there is no way of listening to zoom level change(I am happy to be wrong). If developers are allowed to listen to zoom level change, then they can programmatically have detail control over svg.

AFAIK, there is no way of listening to zoom level change

SVG 1.1 has SVGZoomEvent.

https://www.w3.org/TR/SVG11/single-page.html#script-InterfaceSVGZoomEvent

It has already been removed from SVG2 despite the fact that zoomAndPan is officially still only "at risk".

I am looking at implementing zoom and pan in my Android library. And I am deciding whether to base it on the zoomAndPan feature or not. One of the problems with it, I think, is that it is a little under-specified. For instance:

It's not possible to separately control whether zoom or pan is enabled.
The behaviour when you pan to the edge of the SVG is not specified
There is no way to specify a minimum or maximum zoom.
There is little information in the spec about how zoom and pan affects functions such as getCTM().
zoomAndPan defaults to on. Which I don't think most people would prefer.

Perhaps there is some potential overlap here with the Maps for HTML Community Group efforts?
https://www.w3.org/community/maps4html/

Loading the equivalent standalone SVG into FF and Blink didn't seem to change the results significantly.

<svg xmlns="http://www.w3.org/2000/svg" width="400" height="400" zoomAndPan="magnify">
  <circle cx="200" cy="200" r="200" fill="red"/>
  <circle cx="200" cy="200" r="100" fill="gold"/>
  <script>
var svg = document.querySelector("svg");

svg.addEventListener("SVGZoom", function(evt) { console.log("event=",evt); });

svg.currentTranslate.x = -200.0;
svg.currentTranslate.y = -200.0;
svg.currentScale = 2.0;

console.log("zoomAndPan=",svg.zoomAndPan);
console.log("currentScale=",svg.currentScale);
console.log("currentTranslate=",svg.currentTranslate);
  </script>
</svg>

The only difference to my former results is that manipulating the currentScale and currentTranslate values in FF now updates their DOM values. But no scale or transform seems to happen in either browser.

@fsoder

(And only has panning "controls" in that case.)

What do you mean by "controls", @fsoder ? The scroll bars on the window? They don't seem to be tied in to the currentTranslate properties.

Altogether, I'm not seeing any user-facing zoom & pan controls in either Chrome or Firefox. Pretty sure WebKit is the same. And the value of the attribute (not present, magnify, or disable) doesn't affect the DOM side. So I think it's fair to say that the attribute isn't implemented in any meaningful way, other than by exposing the attribute value in the DOM. And without any user-initiated way to change the values, the event isn't particularly useful, so it's not much of a loss that the event isn't implemented.

But, the currentScale and currentTranslate DOM properties are implemented. So, I don't think we can drop them, although we could mark them as deprecated (recommend that authors don't use them).

We also need to clarify how they interact with other ways of setting & getting transformations on the root SVG: the transform property & attribute (which wasn't allowed on <svg> elements in SVG 1.1), the SVG view spec, viewBox, getCTM(), and so on.

We currently have a note:

The value of the ‘transform’ property does not affect currentScale or currentTranslate.

Which makes sense, because transform property on the outer applies to the box as a whole, and this properties are applying inside that box, more like a modification of the viewBox. So I would expect them to affect the getCTM() results of child contents, similar to how the viewBox does.

Last I checked, some browsers apply an SVG view transform as an external transform (on the outside box of the SVG) and some as an internal transform (to the viewBox-scaled graphics). I've previously argued that it should behave like a regular transform on the root element, but maybe it makes sense to slot it in with the currentScale and currentTranslate effects.

What do you mean by "controls", ... ? The scroll bars on the window? They don't seem to be tied in to the currentTranslate properties.

No, you can initiate panning by holding down the Shift-key and dragging. I refer to this as "controls" because it's pretty non-obvious that it's there. Panning perform like this is however reflected in currentTranslate and disabled by the disable value (or technically by not having the magnify value - I noticed that removing the attribute yields the "unknown" value which seems like a bug...).
The zoomAndPan attribute can also disable zoom (as performed by for instance Ctrl+'+' and Ctrl+'-'), but that is however not reflected in currentScale AFAIK.

you can initiate panning by holding down the Shift-key and dragging.

Interesting. OK, now that I know how, I can pan the SVG in Chrome, for SVG as a separate tab or SVG as an <object> embed. Works with zoomAndPan="magnify" and for no zoomAndPan attribute at all, disabled for zoomAndPan="disable". (Not seeing an unknown value — unless that's from zoomAndPan=""?)

The zoomAndPan attribute can also disable zoom (as performed by for instance Ctrl+'+' and Ctrl+'-')

Well, that is really buggy. The Chrome UI shows the current browser zoom level & lets me change it, but the rendering doesn't update from whatever zoom level I had set when I opened the SVG.

So, technically this is a (partial) implementation, but I'm not sure it's enough to save the feature. I don't suppose you have any way of measuring usage of the UI, now that there's no SVGZoom/SVGScroll event triggered by the user-initiated action?

(Not seeing an unknown value — unless that's from zoomAndPan=""?)

(I think this would only trigger at the equivalent of removeAttribute('zoomAndPan').)

There's no measurements for activation of the panning feature. The only relevant metrics I'm aware of is
https://chromestatus.com/metrics/feature/timeline/popularity/1102 which measures accesses to the SVGZoomAndPan.zoomAndPan property.

The SVG Working Group just discussed Decide what to do with zoom and pan, and agreed to the following:

RESOLUTION: remove zoomAndPan attribute and expectation for zoom and pan feature.

The full IRC log of that discussion

<krit> topic: Decide what to do with zoom and pan
<krit> GitHub: https://github.com//issues/56
<krit> AmeliaBR: zoom and pan is an attribute from SVG 1 that never got fully implemented by browsers
<krit> AmeliaBR: last implementation was the Adobe SVG Plugin
<krit> AmeliaBR: issue resurfaces last month when it was mentioned that there is interaction with other features
<krit> AmeliaBR: with some that are implemented on the DOM level and we got feedback from UAs what does and does not work
<krit> AmeliaBR: Blink does have some panning and zooming and it is buggy in the edge cases. Not sure if it counts as an implementation that needs preserving
<krit> AmeliaBR: unfortunately they don't have metrics
<krit> AmeliaBR: it works for standalone SVGs and embedded SVGs.
<krit> AmeliaBR: but it is not intecreted with zoomon
<krit> s/zoomon/zooming/
<krit> AmeliaBR: my proposal is to drop the attribtue
<krit> AmeliaBR: but keep the DOM properties but define them better in a way that interacts with other features like viewBox and the SVG view behaviour.
<krit> AmeliaBR: but it still needs work to figure out what the redefinition would look like
<krit> AmeliaBR: but that can be discussed separately
<krit> krit: what are the alternatives used today?
<krit> chris: manipulate the viewBox using script or apply transform using script
<krit> AmeliaBR: zoom and pan is about telling the browther to use its own zoom and pan with defaults and an attribute to disable that
<chris> it seems fine to me to drop the attr
<krit> AmeliaBR: since most browsers don't use zoom and pan features, ppl are not using the attribute to disable it. So if browsers would start implementing it it would break things to.
<krit> s/to/too/
<krit> myles: removing it makes sense to remove it
<krit> chris: Agree. It gives control over a not implemented feature.
<krit> AmeliaBR: I'd like to have an opt-in for a browser zoom and pan feature but it probably wouldn't work this way.
<krit> myles: If there is a new proposal we can have a clean cut
<krit> proposal: remove zoomAndPan attribute and expectation for zoom and pan feature.
<krit> RESOLUTION: remove zoomAndPan attribute and expectation for zoom and pan feature.
<krit> krit: 2nd part is the redefinition of the DOM features
<AmeliaBR> https://svgwg.org/svg2-draft/struct.html#__svg__SVGSVGElement__currentScale
<krit> AmeliaBR: there is a currentScale and currentRotate DOM properties on the SVGSVGelement
<krit> krit: for that we need to define in which cascade they apply?
<krit> AmeliaBR: yeah. They need to get redefined as something that is independent from the zoomAndPan attribute and how they interact with things like getCTM()
<krit> krit: Do we know in which order it applies to in combination with viewBox and transform attribute?
<krit> AmeliaBR: haven't looked into it.
<krit> krit: so there are more actions needed how the properties interact with other coordinate system manipulating attributes and functions like getCTM()
<krit> krit: should we open a new issue for that?
<krit> AmeliaBR: might make sense to have a new issue but we can leave it for now and I take an. action to start the edit and see how much work it is.
<krit> AmeliaBR: ok, so leave the issue open and AmeliaBR gets back to the group

OK. Tearing out zoomAndPan is pretty straightforward. Coming up with a sensible definition of how currentTranslate and currentScale interact with other things is turning out to be a mess; it's all tangled up with svgView transforms and regular transforms in the root element. We already have a tracking issue for that: #360. So I'll probably leave it vague, and push the other edits tomorrow.

PS, demo for the mess. Three ways to set a transform on the SVG root, most browsers treat each one differently, major browsers are different from each other: https://bronze-soup.glitch.me/

Remove zoomAndPan attribute

Remove zoomAndPan attribute (#724)

Navigation Menu

Repository navigation

Decide what to do with zoom and pan #56

7 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Decide what to do with zoom and pan #56

Description

Activity

progers commented on Mar 2, 2016

tabatkins commented on Mar 2, 2016

nikosandronikos commented on Apr 22, 2016

longsonr commented on Nov 1, 2016

Zhang-Junzhi commented on Oct 22, 2018

BigBadaboom commented on Jun 4, 2019

BigBadaboom commented on Jun 4, 2019

7 remaining items

BigBadaboom commented on Jun 13, 2019

AmeliaBR commented on Jun 19, 2019

fsoder commented on Jun 20, 2019

AmeliaBR commented on Jun 20, 2019

fsoder commented on Jun 20, 2019

css-meeting-bot commented on Jul 1, 2019

AmeliaBR commented on Jul 28, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions