Closed longsonr closed 5 years ago
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.
Chrome actually does not expose the SVGZoomAndPan
interface, 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.prototype
is 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.
SVGUnitTypes
is different in that it has only constants, and it seems universally exposed. How about just dropping x implements SVGUnitTypes
everywhere?
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.
Context: I was pointed here by @fsoder in https://codereview.chromium.org/2415413002/
Here's a test for whether x implements SVGUnitTypes
is 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_UNITTYPE" 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 SVGUnitTypes
from Gecko? To me it doesn't seem to add anything if SVGUnitTypes
itself is exposed.
@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.
Feel free to add another bug in bugzilla to track that idea though.
And file a separate issue here too please.
The questions of NoInterfaceObject
and what implements
what are connected, so for the spec discussion I couldn't formulate an orthogonal or even follow-up issue. Concretely, my suggested fixes for SVGZoomAndPan
and SVGUnitTypes
would be:
SVGZoomAndPan
as a mixin interface, with NoInterfaceObject
and a bunch of interfaces implementing it.SVGUnitTypes
a normal interface by dropping NoInterfaceObject
and having nothing implement it.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.
Making SVGZoomAndPan [NoInterfaceObject] will mean that you can't use its constants directly
The constants would be on SVGSVGElement and SVGViewElement together with the zoomAndPan attribute itself, doesn't that suffice?
Dropping SVGUnitTypes means that you can only use its constants directly.
The suggestion is to keep it, so that the kind of code found in https://github.com/w3c/svgwg/issues/291#issuecomment-254442089 keeps working.
Leave SVGZoomAndPan as a mixin interface, with NoInterfaceObject and a bunch of interfaces implementing it.
This would be a breaking change from SVG 1.1 SE. How confident are you that it would have a negligible impact?
The multiple inheritance of SVG 1.1 was never possible to implement in JavaScript bindings, I assume that's why implementations took different paths. Per https://github.com/w3c/svgwg/issues/291#issuecomment-254204205 Chrome and Safari don't have a window.SVGZoomAndPan
, which is a good start.
A search for "SVGZoomAndPan" in httparchive:har.2016_09_15_chrome_requests_bodies finds only 64 results. None of the access anything on SVGZoomAndPan, AFAICT it's all one of two things:
Finding literally no real usage in httparchive is pretty unusual even for obscure things, so I'd say this is a safe change.
The changes as originally outlined have now landed in Firefox nightlies.
Landing Make SVGUnitTypes [NoInterfaceObject]
given that it is currently exposed everywhere doesn't seem like a good idea, even if it's what the spec currently says. See https://github.com/w3c/svgwg/issues/291#issuecomment-254442089 for pages in the wild that read the constants on SVGUnitTypes. @bzbarsky @heycam
@foolip That's not what's happened. Read the bugs carefully and what's actually been proposed here.
Yeah, that commit has a .... really terrible commit message that has no bearing on what the commit actually does. :( That's rather unfortunate. You have to read the actual IDL changes to have any idea what it actually does.
Oh, so AFACIT that commit doesn't change observable behavior, is that right?
@foolip
Sure it does, that's why this github issue exists.
Elements such as SVGMaskElement will not be SVGUnitType objects, although they will still allow access to the constants and members of that interface.
Oh, document.createElementNS('http://www.w3.org/2000/svg','mask') instanceof SVGUnitTypes
was true in Gecko before, fascinating. That returns false in Chrome/Safari and throws in Edge.
How did that actually work, is it implements X
itself that caused instanceof X
to be true? Are there any other odd cases like that left?
How did that actually work
Because Gecko implements https://heycam.github.io/webidl/#es-interface-hasinstance (as of today's draft; I wish we had something resembling stable links, because this part might get removed from the spec because no one except Gecko implements is).
But also, in IDL spec terms, the thing we are really after with the specific changes to SVGUnitTypes is separating out the concepts of "interfaces" and "mixins". We are trying to get to a point where things on the right-hand side of an "implements" statement are always [NoInterfaceObject] interfaces, at which point we can drop the ability to "implements" an interface and have explicit mixin syntax.
In other words, this part of the SVG spec's IDL blocks fixing https://www.w3.org/Bugs/Public/show_bug.cgi?id=26452
Or more precisely, the current IDL in the SVG spec doesn't block it, but breaks backwards compat. @longsonr's proposal keeps the desirable property of not conflating mixins and interfaces, but restores backwards compat.
@bzbarsky, I guess "If V is a platform object that implements the interface for which O is the interface prototype object, return true" is the relevant bit here? That's interesting, I had no idea that was ever intended to work, or indeed that it did work in Gecko.
In any case, the goal of "things on the right-hand side of an "implements" statement are always [NoInterfaceObject] interfaces" is clearly a good one, and before this issue I assumed that it was already so, or otherwise a mistake.
As for compat, I think https://github.com/w3c/svgwg/issues/291#issuecomment-254930687 has a good chance of working out. For Gecko, the SVG_UNITTYPE* constants would go away in a few places, but per https://github.com/w3c/svgwg/issues/291#issuecomment-254442089 it ought be quite low risk.
I don't have specific opinions on what the spec should say here, apart from the mixin business. Going to defer to @longsonr on that.
@foolip Oh, and yes, your quoted piece of the IDL spec is what affects instanceof behavior.
Happy to try having the constants only on SVGUnitTypes in a future release of Firefox provided other UAs are on board too.
No change would be required for Chrome and Safari. Who's the SVG contact for Edge to comment on this? @travisleithead, can you poke someone?
@atanassov or @boggydigital ?
LGTM
@boggydigital, to make it explicit, is the proposal in https://github.com/w3c/svgwg/issues/291#issuecomment-254930687 that LGTY, or what was originally proposed in this issue?
The latest one in https://github.com/w3c/svgwg/issues/291#issuecomment-254930687
OK, thanks @boggydigital!
@nikosandronikos, what does the "Needs WG input" label mean, is there anything more needed?
@foolip
"Needs WG input" means that something needs discussion, to decide what the spec should say. Which has been happening here nicely. (It makes me so glad for moving to GitHub: this is exactly how it is supposed to work!)
At this point, I think we can probably make a resolution on it at our call tomorrow (Thurs afternoon in North America). Are you able to prep a pull request of exactly what changes need to be made to the spec text?
I haven't edited this spec before, but it seemed simple enough: https://github.com/w3c/svgwg/issues/295
@longsonr As far as I can tell, you haven't commented on @foolip's suggestion regarding SVGZoomAndPan:
Leave SVGZoomAndPan as a mixin interface, with NoInterfaceObject and a bunch of interfaces implementing it.
My preference would be to accept @foolip's proposal for SVGUnitTypes and @longsonr's proposal for SVGZoomAndPan, but I'm happy to defer to the implementers on this one. I'd like to hear solid support for both aspects of the proposal before we resolve on it.
The reasons I've suggested keeping SVGZoomAndPan as-is in the spec:
I don't see the point in making the constants in SVGZoomAndPan inaccessible to javascript so I expect Firefox will stay as it now is in that regard.
SVGZoomAndPan is pretty much useless due to the current lack of browser support for user-controlled zoom and pan, which explains the lack of usage. You'd need to search demos from the Adobe SVG Viewer days to find practical uses for it.
I'm more concerned about consistency. Why have some shared constants only available from a static interface, and others only available from the implementing interfaces?
Regarding consistency, the only way to achieve that would be to have the constants everywhere, but that wouldn't be consistent with the rest of the platform, and apparently not needed for web compat. By making SVGUnitTypes a normal interface, that becomes the only wart.
Needless to say, if one weren't constrained at all by web compat, then none of these things would be numerical constants at all.
We talked about the issue on our call today. Since we've got 3 different implementers giving the OK for SVGUnitTypes to be an ordinary interface with no mixin, we're okay with that.
@shepazu is going to look in to getting the W3C permissions sorted for @foolip in order to merge that pull request. We may need to temporarily add you to the GitHub SVG team, but I don't think that means you have to be formally assigned as a Google rep on the WG. If it gets too complicated, one of the WG members can make the edits.
For SVGZoomAndPan, we hope to get consensus from you all before making a change (if any).
Things to consider (my personal opinion):
As much as I'd love to see proper browser implementations of user zoom & pan control for graphics, I suspect that when that comes it will be via a new functionality that works for all web content, not just SVG, and that is compatible with existing pinch-zoom implementations. (And hopefully, it will be via a mechanism that doesn't "disable" zoom, it only defines which container isolates the zoom.)
My take on exposing exposing SVGZoomAndPan as an interface is that I agree doing that will still have some level of inconsistency, but I think that's where authors will expect to find the constants, and that's the consistency that matters.
For SVGZoomAndPan, @fsoder said in https://codereview.chromium.org/2415413002/#msg22 that he'd prefer "nuke from orbit", so if there's any appetite for removing it entirely that might be worth a try. FWIW, there is a use counter for the zoomAndPan attribute in Chrome, and it's pretty low: https://www.chromestatus.com/metrics/feature/timeline/popularity/1102
In the meantime, exposing the interface would only increase the risk of eventual removal, and whatever authors may initially expect, in https://github.com/w3c/svgwg/issues/291#issuecomment-255047561 no content was found that actually tried to access the constants on the interface.
Re-opening, because PR #295 only resolved half the issue - we haven't resolved on whether SVGZoomAndPan will stay the same or not yet.
Does anyone have any outstanding issues on this, or can this be closed?
Teleconference minutes (reposting what Github-bot posted in the wrong issue):
The Working Group just discussed Values in SVGZoomAndPan and SVGUnitTypes should be accessible to javascript
.
For SVGUnitTypes, things appear to be the same as they were in https://github.com/w3c/svgwg/issues/291#issuecomment-254442089. I confirmed this in Chrome, Firefox and Safari, but Edge actually crashes when loading https://software.hixie.ch/utilities/js/live-dom-viewer/saved/4581. I think the spec is fine as-is there, and this is tested in https://wpt.fyi/svg/historical.html.
For SVGZoomAndPan, https://svgwg.org/svg2-draft/types.html#InterfaceSVGZoomAndPan has [NoInterfaceObject]
, which I also think is the right thing, since SVGZoomAndPan is the target of implements
statements: SVGSVGElement implements SVGZoomAndPan
and SVGViewElement implements SVGZoomAndPan
. Also tested in https://wpt.fyi/svg/historical.html.
I didn't report the issue, but I'm satisfied.
Thanks @foolip (I also reported the crashing site, so we can fix it.)
https://bugzilla.mozilla.org/show_bug.cgi?id=1435568 should make us align with Chrome for SVGUnitTypes i.e. individual elements won't implement SVGUnitTypes
The Working Group just discussed end of meeting :)
.
What's happening with ZoomAndPan. Is it to be removed altogether? Keeping it and making it [nointerfaceobject] makes no sense as far as I can see.
SVGZoomAndPan
, unlike SVGUnitTypes
, is still used as mixin (it is implemented by SVGSVGElement
).
So there is still access to the named constants through any <svg>
element instance.
Are we happy to close this one now?
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?
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
Then having this as SVGZoomAndPanValues
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.