Re: Should interfaces with values really be [NoInterfaceObject]?

I think the logic for declaring them "No Interface Object" was that there
are never instances of these interfaces (they are all mix-ins implemented
by the different element interfaces), so there was no need to clutter up
the global namespace.

If it is a breaking change that is causing problems in implementations,
that would be a good argument for implementing them as global objects.  But
there are likely to be other propblems: the hierarchy of interfaces was
collapsed in many cases and names were changed.  If tests are detecting the
individual interface names, instead of the exposed methods and properties
on the element interfaces, this re-organization becomes a breaking change,
too.  In contrast, if they are all "No Interface Object" interfaces, then
the exact names and organization of the mix-in interfaces is safe to
change, because it's never exposed in the API.

Are you able to generate a full list of interfaces Firefox detects in test
cases?

~ABR

On 21 August 2016 at 15:07, Robert Longson <longsonr@gmail.com> wrote:

> SVG 2 has this webidl definition of SVGZoomAndPan
>
>
> [NoInterfaceObject]
> interface *SVGZoomAndPan* {
>
>   // Zoom and Pan Types
>   const unsigned short SVG_ZOOMANDPAN_UNKNOWN <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__SVG_ZOOMANDPAN_UNKNOWN> = 0;
>   const unsigned short SVG_ZOOMANDPAN_DISABLE <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__SVG_ZOOMANDPAN_DISABLE> = 1;
>   const unsigned short SVG_ZOOMANDPAN_MAGNIFY <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__SVG_ZOOMANDPAN_MAGNIFY> = 2;
>
>   attribute unsigned short zoomAndPan <https://www.w3.org/TR/SVG2/types.html#__svg__SVGZoomAndPan__zoomAndPan>;
> };
>
> Without the NoInterfaceObject one could write something like
>
>    if (element.zoomAndPan == SVGZoomAndPan.SVG_ZOOMANDPAN_DISABLE)
>
> While one now has to write it as
>
>    if (element.zoomAndPan == SVGSVGElement.SVG_ZOOMANDPAN_DISABLE)
>
> The same applies to SVGUnitTypes. Do we mind about keeping backwards
> compatibility with any existing usages like this. We found when making
> this change that our own unit tests fail on SVGUnitTypes usage for
> instance.
>
> Robert
>
>