Repository navigation
Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript #291
Description
Please:
The SVG 2 specification
Makes it impossible to write var x = ZoomAndPan.SVG_ZOOMANDPAN_UNKNOWN as ZoomAndPan is [NoInterfaceObject].
Similarly with SVGUnitTypes.
This is not what either Chrome or Firefox do (both support accessing the ZoomAndPan interface values directly). In fact Firefox has tests that contain SVGUnitTypes so it's certainly likely that there's also usage of this in the wild.
I propose changing the ZoomAndPan interface to
interface SVGZoomAndPan {
};
SVGZoomAndPan implements SVGZoomAndPanValues;
Then having this as SVGZoomAndPanValues
[NoInterfaceObject]
interface SVGZoomAndPanValues {
// Zoom and Pan Types
const unsigned short SVG_ZOOMANDPAN_UNKNOWN = 0;
const unsigned short SVG_ZOOMANDPAN_DISABLE = 1;
const unsigned short SVG_ZOOMANDPAN_MAGNIFY = 2;
[SetterThrows]
attribute unsigned short zoomAndPan;
};
And all existing users of ZoomAndPan i.e. SVGSVGElement and SVGViewElement would then implement SVGZoomAndPanValues
This would mean that an SVGSVGElement would not be an SVGZoomAndPan but you would be able to access its contents.
Similarly for SVGUnitTypes.
See https://bugzilla.mozilla.org/show_bug.cgi?id=1241899 and https://bugzilla.mozilla.org/show_bug.cgi?id=1241898 for the Firefox implementation which is landing now. This will align Firefox with Chrome's implementation.
Activity
nikosandronikos commentedon Oct 17, 2016
That seems reasonable to me - and has the approval of some other WG members I see.
For posterity, the reason for the extra [NoInterfaceObject] SVGZoomAndPanValues interface, is due to a desire to separate mixins and regular interfaces.
foolip commentedon Oct 17, 2016
Chrome actually does not expose the
SVGZoomAndPaninterface, Chrome 28 was the last version to do so. Safari 10 does also not have it, but I can confirm that Edge 14 and Firefox 51 do.SVGZoomAndPan.prototypeis undefined both Edge and Firefox, does WebIDL say something to make it so? I can't find it, but it may be in there somewhere.SVGUnitTypesis different in that it has only constants, and it seems universally exposed. How about just droppingx implements SVGUnitTypeseverywhere?longsonr commentedon Oct 17, 2016
We'd have x implements SVGUnitTypeValue which would be a [NoInterfaceObject] and contain the constants. SVGUnitTypes would then contain nothing but also implement SVGUnitTypeValues. https://bugzilla.mozilla.org/show_bug.cgi?id=1241898 has more details.
foolip commentedon Oct 18, 2016
Context: I was pointed here by @fsoder in https://codereview.chromium.org/2415413002/
Here's a test for whether
x implements SVGUnitTypesis already supported:https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4581
Edge 14 and Firefox 51 have the constants everywhere. Chrome 55 and Safari 10 don't have them.
A search for "SVG_UNIT_TYPE_" in httparchive:har.2016_09_15_chrome_requests_bodies finds
66 results. 64 of them are from api-maps.yandex.ru and the other two are https://boxy-svg.com/api/frontend/modules.js and http://www.javascripture.com/javascripture.js. All of the are using the SVGUnitTypes object, and so don't depend on
x implements SVGUnitTypes.@longsonr, given the lack of interop and seemingly low usage in the wild, would you be willing to drop
x implements SVGUnitTypesfrom Gecko? To me it doesn't seem to add anything ifSVGUnitTypesitself is exposed.longsonr commentedon Oct 18, 2016
@foolip I think we'll land https://bugzilla.mozilla.org/show_bug.cgi?id=1241898 as is and then think about removing the implements later. I.e. one step at a time. Feel free to add another bug in bugzilla to track that idea though.
nikosandronikos commentedon Oct 18, 2016
And file a separate issue here too please.
foolip commentedon Oct 19, 2016
The questions of
NoInterfaceObjectand whatimplementswhat are connected, so for the spec discussion I couldn't formulate an orthogonal or even follow-up issue. Concretely, my suggested fixes forSVGZoomAndPanandSVGUnitTypeswould be:SVGZoomAndPanas a mixin interface, withNoInterfaceObjectand a bunch of interfaces implementing it.SVGUnitTypesa normal interface by droppingNoInterfaceObjectand having nothing implement it.longsonr commentedon Oct 19, 2016
Making SVGZoomAndPan [NoInterfaceObject] will mean that you can't use its constants directly
Dropping SVGUnitTypes means that you can only use its constants directly.
That would seem to be massively confusing and inconsistent to me.
foolip commentedon Oct 19, 2016
The constants would be on SVGSVGElement and SVGViewElement together with the zoomAndPan attribute itself, doesn't that suffice?
The suggestion is to keep it, so that the kind of code found in #291 (comment) keeps working.
nikosandronikos commentedon Oct 20, 2016
This would be a breaking change from SVG 1.1 SE. How confident are you that it would have a negligible impact?
45 remaining items
longsonr commentedon May 5, 2018
I still think that making people write SVGUnitTypes.SVG_UNIT_TYPE_USERSPACEONUSE yet then saying you can't write SVGZoomAndPan.SVG_ZOOMANDPAN_DISABLE, you must write SVGSVGElement.SVG_ZOOMANDPAN_DISABLE is strangely inconsistent. At the moment Firefox allows SVGZoomAndPan.SVG_ZOOMANDPAN_DISABLE to try to avoid this confusion but also SVGSVGElement.SVG_ZOOMANDPAN_DISABLE to avoid breaking anyone who might write things the spec way.
Should SVGZoomAndPan be removed altogether though? Is it useful/functional anywhere?
dstorey commentedon May 5, 2018
I'm actually not even sure it should be a mixin. According to WebIDL:
As It is only included on SVGSVGElement, the WebIDL advice is to make it a partial. But as they're both in SVG, they should probably just be added to SVGSVGElement directly (assuming we want to keep them)
longsonr commentedon May 5, 2018
@dstorey SVGZoomAndPan is not just on SVGSVGElement, it's on SVGViewElement too.
dstorey commentedon May 5, 2018
Oh yes, I was confused by the comment above. I spotted that after commenting when scrolling up. Ignore the previous comment :D
dstorey commentedon May 5, 2018
As far as is if it is useful. The docs I've found for Edge say "The zoomAndPan attribute is not supported, except for the default magnify operation". A quick look at the code, I saw a comment that says zoomAndPan isn't implemented, so it looks like we have a very barebones implementation that doesn't do anything.
Which makes sense, as disabling zooming sounds like an accessibility issue and we don't respect that in the viewport meta either.
boggydigital commentedon Jun 11, 2018
Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone
css-meeting-bot commentedon Jul 1, 2019
The SVG Working Group just discussed
Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript, and agreed to the following:RESOLUTION: Change SVGUnitTypes interface from NoInterface to an actual interface to match UA implementation behaviorThe full IRC log of that discussion
<krit> topic: Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript<krit> GitHub: https://github.com//issues/291
<AmeliaBR> s/AmeliaBR: ok/krit: ok/
<krit> AmeliaBR: This isn't really about zoom and pan but DOM enumerations.
<krit> AmeliaBR: But one example is for zoomAndPan which is no longer relevant with the last resolution
<krit> AmeliaBR: but the question still remains for SVGUniteTypes
<krit> s/SVGUniteTypes/SVGUnitTypes/
<krit> AmeliaBR: Should the interface that defines the constants should also be available as class that can be referenced. This would be consistent with other SVG DOM definitions.
<krit> myles: for implementations that do not implement zoomAndPan.. do they implement the DOM representation?
<krit> AmeliaBR: yes, they implement the DOM but not the functionality.
<krit> myles: how much JS is there that uses the APIs and what happens if we remove these properties
<AmeliaBR> https://chromestatus.com/metrics/feature/timeline/popularity/1102
<krit> AmeliaBR: 2 questions: Can we safely remove the properties and how much harm would it take.
<krit> AmeliaBR: there are use counters
<krit> myles: if we remove it those would turn to exceptions and the world breaks down
<krit> AmeliaBR: if the usage of the IDL property comes form enumerating on an element, there is no risk of deleting it
<krit> AmeliaBR: no idea why anyone would access the value of the attribute in any meaningful way since it has no functionality
<krit> myles: in other groups one UA is volunteering to go first. WebKit would likely not do it on this one. Can we ask Erik
<krit> Eric?
<myles> Willingers
<krit> krit: Try to involve him in the discussion. He is still around on github
<krit> AmeliaBR: I will followup with him.
<krit> ... back to this issue
<krit> krit: anything else than SVGUnitTypes and zoomAndPan?
<krit> AmeliaBR: I think SVGUnitTypes might be the only other one where the interface is not accessible (NoInterface object)
<AmeliaBR> https://www.w3.org/TR/2016/CR-SVG2-20160915/types.html#InterfaceSVGUnitTypes
<krit> AmeliaBR: this is userSpaceOnUse vs objetBoundingBox
<krit> AmeliaBR: currently the constants are the same across all of these... as defined in the spec, SVGUnitTypes isn't exposed. In Blink it is exposed.
<krit> AmeliaBR: have to check what all the other browsers do
<krit> AmeliaBR: SVGUnitTypes.<constant> so it is its own interface.
<krit> AmeliaBR: we should make the browsers match.
<krit> krit: do we know if it is in other browsers as well?
<krit> AmeliaBR: I know it is in Firefox, not sure about WebKit
<myles> interface SVGUnitTypes
<krit> AmeliaBR: so we get consistent browser behavior
<krit> AmeliaBR: it is also not implemented as a mixin
<krit> proposal: Change SVGUnit
<myles> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/svg/SVGUnitTypes.idl
<krit> proposal: Change SVGUnitTypes interface from NoInterface to an actual interface to match UA implementation behavior
<krit> RESOLUTION: Change SVGUnitTypes interface from NoInterface to an actual interface to match UA implementation behavior
<myles> https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/svg/SVGZoomAndPan.idl
<myles> NoInterfaceObject
<krit> krit: so constant are not accessible for ZoomAndPan
<krit> krit: lets get back to SVGZoomAndPan after AmeliaBR talked to Eric
<AmeliaBR> github-got, end topic
AmeliaBR commentedon Jul 14, 2019
Oops. Looks like our resolution above was redundant. The change to SVGUnitTypes already went through in #415, the issue was staying open because of SVGZoomAndPan.
But since the decision in #56 was to drop the zoom and pan attribute & its IDL reflection, the constants will be dropped too, so this issue can be closed.