Comments (20)
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/
from svgwg.
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).
from svgwg.
Agreed.
from svgwg.
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
from svgwg.
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.
from svgwg.
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.
from svgwg.
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".
from svgwg.
Perhaps there is some potential overlap here with the Maps for HTML Community Group efforts?
Yes, zoom & pan is definitely necessary for map viewers. And I'm trying to focus those efforts on reusable ideas which can be shared with other web platform features. And all your points are definitely relevant, to that discussion, too.
That's really a separate question from the very broken zoomAndPan attribute, but reopening this issue anyway because we need to follow up on at risk versus completely removed.
from svgwg.
We removed what little ZoomEvent processing we had already https://bugzilla.mozilla.org/show_bug.cgi?id=1314388 doesn't seem like anyone noticed.
from svgwg.
Hmm... I just ran some tests and browser support is better than I was expecting based on previous comments.
https://jsfiddle.net/b0dp64fh/4/
As it turns out, IE11 is the champion in this competition!
Firefox
❌ The properties (currentScale
and currentTranslate
) are there, but manipulating them does nothing. No matter what zoomAndPan
is set to.
Chrome
✔️ Manipulating the properties works.
❌ The SVGZoom
event is not fired.
❌ Seems to ignore the zoomAndPan
attribute.
IE11
✔️ Manipulating the properties works.
✔️ The SVGZoom
event is correctly fired.
❌ Seems to ignore the zoomAndPan
attribute.
Edge
〰️ Manipulating currentScale
works, but currentTranslate
isn't quite correct.
✔️ The SVGZoom
event is correctly fired.
❌ Seems to ignore the zoomAndPan
attribute.
Safari
〰️ Manipulating currentTranslate
works, but currentScale
seems to be ignored.
❌ The SVGZoom
event is not fired.
❌ Seems to ignore the zoomAndPan
attribute.
from svgwg.
currentScale/currentTranslate only work in standalone SVG documents in Firefox so they won't work in a fiddle.
from svgwg.
As an aficionado of full page SVG web applications I am fond of zoom-pan.
Hopefully this context of use will not be overlooked.
from svgwg.
Chrome/Blink will only check the value of the zoomAndPan
attribute (or similar mechanisms) for standalone SVG documents. (And only has panning "controls" in that case.) So additionally testing with the same content embedded in an <iframe>
might give an additional axis to the test.
from svgwg.
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.
from svgwg.
(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.
from svgwg.
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.
from svgwg.
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?
from svgwg.
(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.
from svgwg.
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
from svgwg.
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/
from svgwg.
Related Issues (20)
- Why most of SVG 2 properties are not presentational? HOT 4
- [SVG2] Broken references in Scalable Vector Graphics (SVG) 2
- [svg-animations] Broken references in SVG Animations
- Fetch integration
- [svg-stroke] Collision with svg2 [=stroke=]
- [SVG 2] SVG is missing declaration to center embedded content around arbitrary point HOT 2
- What is the purpose of BackgroundImage filter input in SVG 2?
- small error in Object bounding box units definition HOT 1
- Sizing properties section should link to a more recent references
- Should SVG's `<script>` element support the `fetchpriority` attribute analogous to HTML's `<script>` element? HOT 2
- Should support async and defer attributes on script elements
- Specification of the behaviour of `inline-size: 0`
- No way to construct a TimeEvent, so its initTimeEvent method is fully useless
- The IDL of SVGSVGElement.getElementById does not allow null
- Should SVG's `<image>` element support the `fetchpriority` attribute analogous to HTML's `<img>` element? HOT 1
- Decimal point not allowed according to Path Data ENBF HOT 3
- Enable lazy loading for URLs on use href HOT 1
- Does SVG support Custom elements? HOT 1
- Error about drawto_command in SVG 2.0 path EBNF HOT 2
- What should happen when trying to insert empty strings or separators into SVGStringList
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from svgwg.