Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript

[longsonr]

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.

[dstorey]

I'm actually not even sure it should be a mixin. According to WebIDL:

Interface mixins allow the sharing of attributes, constants, and operations across multiple interfaces. If you’re only planning to extend a single interface, you might consider using a partial interface instead. https://heycam.github.io/webidl/#using-mixins-and-partials

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]

@dstorey SVGZoomAndPan is not just on SVGSVGElement, it's on SVGViewElement too.

[dstorey]

Oh yes, I was confused by the comment above. I spotted that after commenting when scrolling up. Ignore the previous comment :D

[dstorey]

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]

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

[css-meeting-bot]

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 behavior

The full IRC log of that discussion

<krit> topic: Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript
<krit> GitHub: https://github.com/w3c/svgwg/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]

Oops. Looks like our resolution above was redundant. The change to SVGUnitTypes already went through in https://github.com/w3c/svgwg/pull/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.