Add '... implement SVGUnitTypes' to a bunch of SVG*Elements

Add '... implement SVGUnitTypes' to a bunch of SVG*Elements

Per the SVG2, Filter Effects and CSS Masking specifications,

 SVGClipPathElement
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGClipPathElement)
 SVGFilterElement,
  (https://drafts.fxtf.org/filters/#InterfaceSVGFilterElement)
 SVGGradientElement,
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGGradientElement)
 SVGMaskElement and
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGMaskElement)
 SVGPatternElement
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGPatternElement)

should implement SVGUnitTypes. Matches Gecko and Edge.

BUG=651796

[fs, 2016-10-14 11:49:25]

The CQ bit was checked by fs@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-14 11:49:36]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[fs, 2016-10-14 11:53:32]

Description was changed from

==========
Make SVG{Filter,Gradient,Mask,Pattern}Element implement SVGUnitTypes

Per the SVG2, Filter Effects and CSS Masking specifications.

 https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGGradientElement
 https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGPatternElement
 https://drafts.fxtf.org/filters/#InterfaceSVGFilterElement
 https://drafts.fxtf.org/css-masking-1/#InterfaceSVGMaskElement

Matches Gecko and Edge.

BUG=651796
==========

to

==========
Add '... implement SVGUnitTypes' to a bunch of SVG*Element

Per the SVG2, Filter Effects and CSS Masking specifications,

 SVGClipPathElement
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGClipPathElement)
 SVGFilterElement,
  (https://drafts.fxtf.org/filters/#InterfaceSVGFilterElement)
 SVGGradientElement,
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGGradientElement)
 SVGMaskElement and
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGMaskElement)
 SVGPatternElement
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGPatternElement)

should implement SVGUnitTypes. Matches Gecko and Edge.

BUG=651796
==========

[fs, 2016-10-14 11:54:08]

Description was changed from

==========
Add '... implement SVGUnitTypes' to a bunch of SVG*Element

Per the SVG2, Filter Effects and CSS Masking specifications,

 SVGClipPathElement
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGClipPathElement)
 SVGFilterElement,
  (https://drafts.fxtf.org/filters/#InterfaceSVGFilterElement)
 SVGGradientElement,
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGGradientElement)
 SVGMaskElement and
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGMaskElement)
 SVGPatternElement
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGPatternElement)

should implement SVGUnitTypes. Matches Gecko and Edge.

BUG=651796
==========

to

==========
Add '... implement SVGUnitTypes' to a bunch of SVG*Elements

Per the SVG2, Filter Effects and CSS Masking specifications,

 SVGClipPathElement
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGClipPathElement)
 SVGFilterElement,
  (https://drafts.fxtf.org/filters/#InterfaceSVGFilterElement)
 SVGGradientElement,
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGGradientElement)
 SVGMaskElement and
  (https://drafts.fxtf.org/css-masking-1/#InterfaceSVGMaskElement)
 SVGPatternElement
  (https://svgwg.org/svg2-draft/pservers.html#InterfaceSVGPatternElement)

should implement SVGUnitTypes. Matches Gecko and Edge.

BUG=651796
==========

[commit-bot: I haz the power, 2016-10-14 13:22:26]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-14 13:22:26]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[fs, 2016-10-17 06:48:13]

The CQ bit was checked by fs@opera.com to run a CQ dry run

[commit-bot: I haz the power, 2016-10-17 06:48:28]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-10-17 08:25:01]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-10-17 08:25:02]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[fs, 2016-10-17 10:53:54]

fs@opera.com changed reviewers:
+ foolip@chromium.org, pdr@chromium.org

[foolip, 2016-10-17 12:06:46]

Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do that
separately?

[foolip, 2016-10-17 12:09:54]

https://codereview.chromium.org/2415413002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/svg/SVGClipPathElement.h (right):

https://codereview.chromium.org/2415413002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/svg/SVGClipPathElement.h:41: kSvgUnitTypeUnknown
= SVGUnitTypes::kSvgUnitTypeUnknown,
If the enum is moved from SVGUnitTypes.h to the most-derived common ancestor
(SVGElement?) would this become simpler and could SVGUnitTypes.h/cpp be closer
to empty?

[fs, 2016-10-17 12:31:11]

On 2016/10/17 at 12:06:46, foolip wrote:
> Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do that
separately?

As I noted in the bug Gecko (and Edge) still have SVGUnitTypes exposed, and
presumably that may be non-trivial to remove. Also
https://github.com/w3c/svgwg/issues/291.

[fs, 2016-10-17 12:40:21]

https://codereview.chromium.org/2415413002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/svg/SVGClipPathElement.h (right):

https://codereview.chromium.org/2415413002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/svg/SVGClipPathElement.h:41: kSvgUnitTypeUnknown
= SVGUnitTypes::kSvgUnitTypeUnknown,
On 2016/10/17 at 12:09:54, foolip wrote:
> If the enum is moved from SVGUnitTypes.h to the most-derived common ancestor
(SVGElement?) would this become simpler and could SVGUnitTypes.h/cpp be closer
to empty?

That ought to do it from a scoping perspective, yes (and so would an C++ mixin
too I guess.) Not sure if that in an of itself would help make
SVGUnitTypes.cpp/h emptier though (the bindings generated for SVGUnitTypes still
reference the class, although I don't see that it actually does anything with
it.)

[foolip, 2016-10-17 13:19:20]

On 2016/10/17 12:31:11, fs wrote:
> On 2016/10/17 at 12:06:46, foolip wrote:
> > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do that
> separately?
> 
> As I noted in the bug Gecko (and Edge) still have SVGUnitTypes exposed, and
> presumably that may be non-trivial to remove. Also
> https://github.com/w3c/svgwg/issues/291.

Commented there, would like to hear pdr@'s thoughts too. Since we already have
SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems not very
useful.

[fs, 2016-10-17 13:39:05]

On 2016/10/17 at 13:19:20, foolip wrote:
> On 2016/10/17 12:31:11, fs wrote:
> > On 2016/10/17 at 12:06:46, foolip wrote:
> > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do that
> > separately?
> > 
> > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes exposed, and
> > presumably that may be non-trivial to remove. Also
> > https://github.com/w3c/svgwg/issues/291.
> 
> Commented there, would like to hear pdr@'s thoughts too. Since we already have
SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems not very
useful.

I think this is all a bit confused because of how the IDL was structured in SVG
1.1 (multiple inheritance, likely assuming these constants would appear as if
'implements' had been used. Hard to tell really.)

[foolip, 2016-10-17 13:58:12]

On 2016/10/17 13:39:05, fs wrote:
> On 2016/10/17 at 13:19:20, foolip wrote:
> > On 2016/10/17 12:31:11, fs wrote:
> > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do that
> > > separately?
> > > 
> > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes exposed,
and
> > > presumably that may be non-trivial to remove. Also
> > > https://github.com/w3c/svgwg/issues/291.
> > 
> > Commented there, would like to hear pdr@'s thoughts too. Since we already
have
> SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems not very
> useful.
> 
> I think this is all a bit confused because of how the IDL was structured in
SVG
> 1.1 (multiple inheritance, likely assuming these constants would appear as if
> 'implements' had been used. Hard to tell really.)

Yep, a bit of a mess it is. What do you think would be the best outcome?

[fs, 2016-10-17 14:25:06]

On 2016/10/17 at 13:58:12, foolip wrote:
> On 2016/10/17 13:39:05, fs wrote:
> > On 2016/10/17 at 13:19:20, foolip wrote:
> > > On 2016/10/17 12:31:11, fs wrote:
> > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do
that
> > > > separately?
> > > > 
> > > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes exposed,
and
> > > > presumably that may be non-trivial to remove. Also
> > > > https://github.com/w3c/svgwg/issues/291.
> > > 
> > > Commented there, would like to hear pdr@'s thoughts too. Since we already
have
> > SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems not very
> > useful.
> > 
> > I think this is all a bit confused because of how the IDL was structured in
SVG
> > 1.1 (multiple inheritance, likely assuming these constants would appear as
if
> > 'implements' had been used. Hard to tell really.)
> 
> Yep, a bit of a mess it is. What do you think would be the best outcome?

If wishing I think I'd just go with what we have now (SVGUnitTypes exposed; no
implements.)

[foolip, 2016-10-17 14:34:25]

On 2016/10/17 14:25:06, fs wrote:
> On 2016/10/17 at 13:58:12, foolip wrote:
> > On 2016/10/17 13:39:05, fs wrote:
> > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do
> that
> > > > > separately?
> > > > > 
> > > > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes
exposed,
> and
> > > > > presumably that may be non-trivial to remove. Also
> > > > > https://github.com/w3c/svgwg/issues/291.
> > > > 
> > > > Commented there, would like to hear pdr@'s thoughts too. Since we
already
> have
> > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems not
very
> > > useful.
> > > 
> > > I think this is all a bit confused because of how the IDL was structured
in
> SVG
> > > 1.1 (multiple inheritance, likely assuming these constants would appear as
> if
> > > 'implements' had been used. Hard to tell really.)
> > 
> > Yep, a bit of a mess it is. What do you think would be the best outcome?
> 
> If wishing I think I'd just go with what we have now (SVGUnitTypes exposed; no
> implements.)

I agree. And for SVGZoomAndPan?

[fs, 2016-10-17 14:42:00]

On 2016/10/17 at 14:34:25, foolip wrote:
> On 2016/10/17 14:25:06, fs wrote:
> > On 2016/10/17 at 13:58:12, foolip wrote:
> > > On 2016/10/17 13:39:05, fs wrote:
> > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to do
> > that
> > > > > > separately?
> > > > > > 
> > > > > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes
exposed,
> > and
> > > > > > presumably that may be non-trivial to remove. Also
> > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > 
> > > > > Commented there, would like to hear pdr@'s thoughts too. Since we
already
> > have
> > > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems not
very
> > > > useful.
> > > > 
> > > > I think this is all a bit confused because of how the IDL was structured
in
> > SVG
> > > > 1.1 (multiple inheritance, likely assuming these constants would appear
as
> > if
> > > > 'implements' had been used. Hard to tell really.)
> > > 
> > > Yep, a bit of a mess it is. What do you think would be the best outcome?
> > 
> > If wishing I think I'd just go with what we have now (SVGUnitTypes exposed;
no
> > implements.)
> 
> I agree. And for SVGZoomAndPan?

Well, "nuke from orbit" would be my preference I think =) [1]. If not that, then
"keep as is".

[1] We have a use counter for the attribute in the interface
(https://www.chromestatus.com/metrics/feature/timeline/popularity/1102), but
nothing to indicate use of the constants.

[foolip, 2016-10-17 15:00:31]

On 2016/10/17 14:42:00, fs wrote:
> On 2016/10/17 at 14:34:25, foolip wrote:
> > On 2016/10/17 14:25:06, fs wrote:
> > > On 2016/10/17 at 13:58:12, foolip wrote:
> > > > On 2016/10/17 13:39:05, fs wrote:
> > > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend to
do
> > > that
> > > > > > > separately?
> > > > > > > 
> > > > > > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes
> exposed,
> > > and
> > > > > > > presumably that may be non-trivial to remove. Also
> > > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > > 
> > > > > > Commented there, would like to hear pdr@'s thoughts too. Since we
> already
> > > have
> > > > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems
not
> very
> > > > > useful.
> > > > > 
> > > > > I think this is all a bit confused because of how the IDL was
structured
> in
> > > SVG
> > > > > 1.1 (multiple inheritance, likely assuming these constants would
appear
> as
> > > if
> > > > > 'implements' had been used. Hard to tell really.)
> > > > 
> > > > Yep, a bit of a mess it is. What do you think would be the best outcome?
> > > 
> > > If wishing I think I'd just go with what we have now (SVGUnitTypes
exposed;
> no
> > > implements.)
> > 
> > I agree. And for SVGZoomAndPan?
> 
> Well, "nuke from orbit" would be my preference I think =) [1]. If not that,
then
> "keep as is".
> 
> [1] We have a use counter for the attribute in the interface
> (https://www.chromestatus.com/metrics/feature/timeline/popularity/1102), but
> nothing to indicate use of the constants.

It's a pretty safe bet that usage of the constants is no higher than use of the
zoomAndPan attribute itself. Does this thing have no utility at all for
developers, would removing it make anybody sad?

[fs, 2016-10-17 15:17:10]

On 2016/10/17 at 15:00:31, foolip wrote:
> On 2016/10/17 14:42:00, fs wrote:
> > On 2016/10/17 at 14:34:25, foolip wrote:
> > > On 2016/10/17 14:25:06, fs wrote:
> > > > On 2016/10/17 at 13:58:12, foolip wrote:
> > > > > On 2016/10/17 13:39:05, fs wrote:
> > > > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend
to do
> > > > that
> > > > > > > > separately?
> > > > > > > > 
> > > > > > > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes
> > exposed,
> > > > and
> > > > > > > > presumably that may be non-trivial to remove. Also
> > > > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > > > 
> > > > > > > Commented there, would like to hear pdr@'s thoughts too. Since we
> > already
> > > > have
> > > > > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes` seems
not
> > very
> > > > > > useful.
> > > > > > 
> > > > > > I think this is all a bit confused because of how the IDL was
structured
> > in
> > > > SVG
> > > > > > 1.1 (multiple inheritance, likely assuming these constants would
appear
> > as
> > > > if
> > > > > > 'implements' had been used. Hard to tell really.)
> > > > > 
> > > > > Yep, a bit of a mess it is. What do you think would be the best
outcome?
> > > > 
> > > > If wishing I think I'd just go with what we have now (SVGUnitTypes
exposed;
> > no
> > > > implements.)
> > > 
> > > I agree. And for SVGZoomAndPan?
> > 
> > Well, "nuke from orbit" would be my preference I think =) [1]. If not that,
then
> > "keep as is".
> > 
> > [1] We have a use counter for the attribute in the interface
> > (https://www.chromestatus.com/metrics/feature/timeline/popularity/1102), but
> > nothing to indicate use of the constants.
> 
> It's a pretty safe bet that usage of the constants is no higher than use of
the zoomAndPan attribute itself. Does this thing have no utility at all for
developers, would removing it make anybody sad?

The main (only) utility of ZoomAndPan is to prevent UA panning. So the only use
of the interface (attribute) would be to be able to toggle that at runtime.
Something that arguably could be achieved as easy (if not easier) by the just
setting the attribute ('zoomAndPan'.) So removing the interface would prevent
that particular way of enabling/disabling UA panning. (Also, IIRC, UA panning
only works on standalone documents.)

[foolip, 2016-10-18 08:10:25]

On 2016/10/17 15:17:10, fs wrote:
> On 2016/10/17 at 15:00:31, foolip wrote:
> > On 2016/10/17 14:42:00, fs wrote:
> > > On 2016/10/17 at 14:34:25, foolip wrote:
> > > > On 2016/10/17 14:25:06, fs wrote:
> > > > > On 2016/10/17 at 13:58:12, foolip wrote:
> > > > > > On 2016/10/17 13:39:05, fs wrote:
> > > > > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you intend
> to do
> > > > > that
> > > > > > > > > separately?
> > > > > > > > > 
> > > > > > > > > As I noted in the bug Gecko (and Edge) still have SVGUnitTypes
> > > exposed,
> > > > > and
> > > > > > > > > presumably that may be non-trivial to remove. Also
> > > > > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > > > > 
> > > > > > > > Commented there, would like to hear pdr@'s thoughts too. Since
we
> > > already
> > > > > have
> > > > > > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes`
seems
> not
> > > very
> > > > > > > useful.
> > > > > > > 
> > > > > > > I think this is all a bit confused because of how the IDL was
> structured
> > > in
> > > > > SVG
> > > > > > > 1.1 (multiple inheritance, likely assuming these constants would
> appear
> > > as
> > > > > if
> > > > > > > 'implements' had been used. Hard to tell really.)
> > > > > > 
> > > > > > Yep, a bit of a mess it is. What do you think would be the best
> outcome?
> > > > > 
> > > > > If wishing I think I'd just go with what we have now (SVGUnitTypes
> exposed;
> > > no
> > > > > implements.)
> > > > 
> > > > I agree. And for SVGZoomAndPan?
> > > 
> > > Well, "nuke from orbit" would be my preference I think =) [1]. If not
that,
> then
> > > "keep as is".
> > > 
> > > [1] We have a use counter for the attribute in the interface
> > > (https://www.chromestatus.com/metrics/feature/timeline/popularity/1102),
but
> > > nothing to indicate use of the constants.
> > 
> > It's a pretty safe bet that usage of the constants is no higher than use of
> the zoomAndPan attribute itself. Does this thing have no utility at all for
> developers, would removing it make anybody sad?
> 
> The main (only) utility of ZoomAndPan is to prevent UA panning. So the only
use
> of the interface (attribute) would be to be able to toggle that at runtime.
> Something that arguably could be achieved as easy (if not easier) by the just
> setting the attribute ('zoomAndPan'.) So removing the interface would prevent
> that particular way of enabling/disabling UA panning. (Also, IIRC, UA panning
> only works on standalone documents.)

Oh, so there's a zoomAndPan content attribute with the values "disable" and
"magnifiy", and there's a one-way reflection to this unsigned short IDL
attribute. Per https://github.com/w3c/svgwg/issues/56 the whole thing is at
risk, so figuring out if there's a path to removal would be nice.

Will comment more on https://github.com/w3c/svgwg/issues/291 regarding
SVGUnitTypes.

[fs, 2016-10-18 08:28:53]

On 2016/10/18 at 08:10:25, foolip wrote:
> On 2016/10/17 15:17:10, fs wrote:
> > On 2016/10/17 at 15:00:31, foolip wrote:
> > > On 2016/10/17 14:42:00, fs wrote:
> > > > On 2016/10/17 at 14:34:25, foolip wrote:
> > > > > On 2016/10/17 14:25:06, fs wrote:
> > > > > > On 2016/10/17 at 13:58:12, foolip wrote:
> > > > > > > On 2016/10/17 13:39:05, fs wrote:
> > > > > > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you
intend
> > to do
> > > > > > that
> > > > > > > > > > separately?
> > > > > > > > > > 
> > > > > > > > > > As I noted in the bug Gecko (and Edge) still have
SVGUnitTypes
> > > > exposed,
> > > > > > and
> > > > > > > > > > presumably that may be non-trivial to remove. Also
> > > > > > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > > > > > 
> > > > > > > > > Commented there, would like to hear pdr@'s thoughts too. Since
we
> > > > already
> > > > > > have
> > > > > > > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes`
seems
> > not
> > > > very
> > > > > > > > useful.
> > > > > > > > 
> > > > > > > > I think this is all a bit confused because of how the IDL was
> > structured
> > > > in
> > > > > > SVG
> > > > > > > > 1.1 (multiple inheritance, likely assuming these constants would
> > appear
> > > > as
> > > > > > if
> > > > > > > > 'implements' had been used. Hard to tell really.)
> > > > > > > 
> > > > > > > Yep, a bit of a mess it is. What do you think would be the best
> > outcome?
> > > > > > 
> > > > > > If wishing I think I'd just go with what we have now (SVGUnitTypes
> > exposed;
> > > > no
> > > > > > implements.)
> > > > > 
> > > > > I agree. And for SVGZoomAndPan?
> > > > 
> > > > Well, "nuke from orbit" would be my preference I think =) [1]. If not
that,
> > then
> > > > "keep as is".
> > > > 
> > > > [1] We have a use counter for the attribute in the interface
> > > > (https://www.chromestatus.com/metrics/feature/timeline/popularity/1102),
but
> > > > nothing to indicate use of the constants.
> > > 
> > > It's a pretty safe bet that usage of the constants is no higher than use
of
> > the zoomAndPan attribute itself. Does this thing have no utility at all for
> > developers, would removing it make anybody sad?
> > 
> > The main (only) utility of ZoomAndPan is to prevent UA panning. So the only
use
> > of the interface (attribute) would be to be able to toggle that at runtime.
> > Something that arguably could be achieved as easy (if not easier) by the
just
> > setting the attribute ('zoomAndPan'.) So removing the interface would
prevent
> > that particular way of enabling/disabling UA panning. (Also, IIRC, UA
panning
> > only works on standalone documents.)
> 
> Oh, so there's a zoomAndPan content attribute with the values "disable" and
"magnifiy", and there's a one-way reflection to this unsigned short IDL
attribute. Per https://github.com/w3c/svgwg/issues/56 the whole thing is at
risk, so figuring out if there's a path to removal would be nice.

Removing only the DOM bits ought to be reasonably straightforward and safe I
think (I don't think I've ever seen anything use the IDL attribute - granted
there's a low number of users per the use counters. Usage of the content
attribute I believe might be more common.) From a removal PoV, the only
technical issue I see is with the reflection on SVGViewSpec - but we have that
scheduled for removal (in 56?) IIRC.

[foolip, 2016-10-18 08:43:12]

On 2016/10/18 08:28:53, fs wrote:
> On 2016/10/18 at 08:10:25, foolip wrote:
> > On 2016/10/17 15:17:10, fs wrote:
> > > On 2016/10/17 at 15:00:31, foolip wrote:
> > > > On 2016/10/17 14:42:00, fs wrote:
> > > > > On 2016/10/17 at 14:34:25, foolip wrote:
> > > > > > On 2016/10/17 14:25:06, fs wrote:
> > > > > > > On 2016/10/17 at 13:58:12, foolip wrote:
> > > > > > > > On 2016/10/17 13:39:05, fs wrote:
> > > > > > > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > > > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you
> intend
> > > to do
> > > > > > > that
> > > > > > > > > > > separately?
> > > > > > > > > > > 
> > > > > > > > > > > As I noted in the bug Gecko (and Edge) still have
> SVGUnitTypes
> > > > > exposed,
> > > > > > > and
> > > > > > > > > > > presumably that may be non-trivial to remove. Also
> > > > > > > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > > > > > > 
> > > > > > > > > > Commented there, would like to hear pdr@'s thoughts too.
Since
> we
> > > > > already
> > > > > > > have
> > > > > > > > > SVGUnitTypes exposed, also having `x implements SVGUnitTypes`
> seems
> > > not
> > > > > very
> > > > > > > > > useful.
> > > > > > > > > 
> > > > > > > > > I think this is all a bit confused because of how the IDL was
> > > structured
> > > > > in
> > > > > > > SVG
> > > > > > > > > 1.1 (multiple inheritance, likely assuming these constants
would
> > > appear
> > > > > as
> > > > > > > if
> > > > > > > > > 'implements' had been used. Hard to tell really.)
> > > > > > > > 
> > > > > > > > Yep, a bit of a mess it is. What do you think would be the best
> > > outcome?
> > > > > > > 
> > > > > > > If wishing I think I'd just go with what we have now (SVGUnitTypes
> > > exposed;
> > > > > no
> > > > > > > implements.)
> > > > > > 
> > > > > > I agree. And for SVGZoomAndPan?
> > > > > 
> > > > > Well, "nuke from orbit" would be my preference I think =) [1]. If not
> that,
> > > then
> > > > > "keep as is".
> > > > > 
> > > > > [1] We have a use counter for the attribute in the interface
> > > > >
(https://www.chromestatus.com/metrics/feature/timeline/popularity/1102),
> but
> > > > > nothing to indicate use of the constants.
> > > > 
> > > > It's a pretty safe bet that usage of the constants is no higher than use
> of
> > > the zoomAndPan attribute itself. Does this thing have no utility at all
for
> > > developers, would removing it make anybody sad?
> > > 
> > > The main (only) utility of ZoomAndPan is to prevent UA panning. So the
only
> use
> > > of the interface (attribute) would be to be able to toggle that at
runtime.
> > > Something that arguably could be achieved as easy (if not easier) by the
> just
> > > setting the attribute ('zoomAndPan'.) So removing the interface would
> prevent
> > > that particular way of enabling/disabling UA panning. (Also, IIRC, UA
> panning
> > > only works on standalone documents.)
> > 
> > Oh, so there's a zoomAndPan content attribute with the values "disable" and
> "magnifiy", and there's a one-way reflection to this unsigned short IDL
> attribute. Per https://github.com/w3c/svgwg/issues/56 the whole thing is at
> risk, so figuring out if there's a path to removal would be nice.
> 
> Removing only the DOM bits ought to be reasonably straightforward and safe I
> think (I don't think I've ever seen anything use the IDL attribute - granted
> there's a low number of users per the use counters. Usage of the content
> attribute I believe might be more common.) From a removal PoV, the only
> technical issue I see is with the reflection on SVGViewSpec - but we have that
> scheduled for removal (in 56?) IIRC.

Yep:
    case UseCounter::V8SVGSVGElement_UseCurrentView_AttributeGetter:
      return willBeRemoved("SVGSVGElement.useCurrentView", M56,
                           "4511711998509056");

    case UseCounter::V8SVGSVGElement_CurrentView_AttributeGetter:
      return willBeRemoved("SVGSVGElement.currentView", M56,
                           "4511711998509056");

    case UseCounter::V8SVGViewElement_ViewTarget_AttributeGetter:
      return willBeRemoved("SVGViewElement.viewTarget", M56,
                           "5665473114931200");

For the fate of zoomAndPan, I guess a close look at its interoperability would
be a start. If it already does something semi-useful interoperably, then unless
usage is super low, just leaving the interoperable intersection might be the
least amount of work for everyone.

[fs, 2016-10-18 08:59:48]

On 2016/10/18 at 08:43:12, foolip wrote:
> On 2016/10/18 08:28:53, fs wrote:
> > On 2016/10/18 at 08:10:25, foolip wrote:
> > > On 2016/10/17 15:17:10, fs wrote:
> > > > On 2016/10/17 at 15:00:31, foolip wrote:
> > > > > On 2016/10/17 14:42:00, fs wrote:
> > > > > > On 2016/10/17 at 14:34:25, foolip wrote:
> > > > > > > On 2016/10/17 14:25:06, fs wrote:
> > > > > > > > On 2016/10/17 at 13:58:12, foolip wrote:
> > > > > > > > > On 2016/10/17 13:39:05, fs wrote:
> > > > > > > > > > On 2016/10/17 at 13:19:20, foolip wrote:
> > > > > > > > > > > On 2016/10/17 12:31:11, fs wrote:
> > > > > > > > > > > > On 2016/10/17 at 12:06:46, foolip wrote:
> > > > > > > > > > > > > Also add NoInterfaceObject to SVGUnitTypes, or do you
> > intend
> > > > to do
> > > > > > > > that
> > > > > > > > > > > > separately?
> > > > > > > > > > > > 
> > > > > > > > > > > > As I noted in the bug Gecko (and Edge) still have
> > SVGUnitTypes
> > > > > > exposed,
> > > > > > > > and
> > > > > > > > > > > > presumably that may be non-trivial to remove. Also
> > > > > > > > > > > > https://github.com/w3c/svgwg/issues/291.
> > > > > > > > > > > 
> > > > > > > > > > > Commented there, would like to hear pdr@'s thoughts too.
Since
> > we
> > > > > > already
> > > > > > > > have
> > > > > > > > > > SVGUnitTypes exposed, also having `x implements
SVGUnitTypes`
> > seems
> > > > not
> > > > > > very
> > > > > > > > > > useful.
> > > > > > > > > > 
> > > > > > > > > > I think this is all a bit confused because of how the IDL
was
> > > > structured
> > > > > > in
> > > > > > > > SVG
> > > > > > > > > > 1.1 (multiple inheritance, likely assuming these constants
would
> > > > appear
> > > > > > as
> > > > > > > > if
> > > > > > > > > > 'implements' had been used. Hard to tell really.)
> > > > > > > > > 
> > > > > > > > > Yep, a bit of a mess it is. What do you think would be the
best
> > > > outcome?
> > > > > > > > 
> > > > > > > > If wishing I think I'd just go with what we have now
(SVGUnitTypes
> > > > exposed;
> > > > > > no
> > > > > > > > implements.)
> > > > > > > 
> > > > > > > I agree. And for SVGZoomAndPan?
> > > > > > 
> > > > > > Well, "nuke from orbit" would be my preference I think =) [1]. If
not
> > that,
> > > > then
> > > > > > "keep as is".
> > > > > > 
> > > > > > [1] We have a use counter for the attribute in the interface
> > > > > >
(https://www.chromestatus.com/metrics/feature/timeline/popularity/1102),
> > but
> > > > > > nothing to indicate use of the constants.
> > > > > 
> > > > > It's a pretty safe bet that usage of the constants is no higher than
use
> > of
> > > > the zoomAndPan attribute itself. Does this thing have no utility at all
for
> > > > developers, would removing it make anybody sad?
> > > > 
> > > > The main (only) utility of ZoomAndPan is to prevent UA panning. So the
only
> > use
> > > > of the interface (attribute) would be to be able to toggle that at
runtime.
> > > > Something that arguably could be achieved as easy (if not easier) by the
> > just
> > > > setting the attribute ('zoomAndPan'.) So removing the interface would
> > prevent
> > > > that particular way of enabling/disabling UA panning. (Also, IIRC, UA
> > panning
> > > > only works on standalone documents.)
> > > 
> > > Oh, so there's a zoomAndPan content attribute with the values "disable"
and
> > "magnifiy", and there's a one-way reflection to this unsigned short IDL
> > attribute. Per https://github.com/w3c/svgwg/issues/56 the whole thing is at
> > risk, so figuring out if there's a path to removal would be nice.
> > 
> > Removing only the DOM bits ought to be reasonably straightforward and safe I
> > think (I don't think I've ever seen anything use the IDL attribute - granted
> > there's a low number of users per the use counters. Usage of the content
> > attribute I believe might be more common.) From a removal PoV, the only
> > technical issue I see is with the reflection on SVGViewSpec - but we have
that
> > scheduled for removal (in 56?) IIRC.
> 
> Yep:
>     case UseCounter::V8SVGSVGElement_UseCurrentView_AttributeGetter:
>       return willBeRemoved("SVGSVGElement.useCurrentView", M56,
>                            "4511711998509056");
> 
>     case UseCounter::V8SVGSVGElement_CurrentView_AttributeGetter:
>       return willBeRemoved("SVGSVGElement.currentView", M56,
>                            "4511711998509056");
> 
>     case UseCounter::V8SVGViewElement_ViewTarget_AttributeGetter:
>       return willBeRemoved("SVGViewElement.viewTarget", M56,
>                            "5665473114931200");
> 
> For the fate of zoomAndPan, I guess a close look at its interoperability would
be a start. If it already does something semi-useful interoperably, then unless
usage is super low, just leaving the interoperable intersection might be the
least amount of work for everyone.

The most difficult part of that is probably to figure out how to trigger UA
zoom/pan (if even possible...) =)