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

--001a113ddd583a40dc053aa34add
Content-Type: text/plain; charset=UTF-8

SVG 1.1 did permit instances of these interfaces and existing UAs support
this (https://bugzilla.mozilla.org/show_bug.cgi?id=1241898#c6).

Currently Firefox does not have either SVGUnitTypes and SVGZoomAndPan as
[NoInterfaceObject].

Robert.

On 22 August 2016 at 06:35, Amelia Bellamy-Royds <
[email protected]> wrote:

> 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 <[email protected]> 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
>>
>>
>

--001a113ddd583a40dc053aa34add
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div><div>SVG 1.1 did permit instances of these interfaces=
 and existing UAs support this (<a href=3D"https://bugzilla.mozilla.org/sho=
w_bug.cgi?id=3D1241898#c6">https://bugzilla.mozilla.org/show_bug.cgi?id=3D1=
241898#c6</a>).<br><br></div>Currently Firefox does not have either SVGUnit=
Types and SVGZoomAndPan as [NoInterfaceObject].<br><br></div>Robert.<br></d=
iv><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 22 August 2=
016 at 06:35, Amelia Bellamy-Royds <span dir=3D"ltr">&lt;<a href=3D"mailto:=
[email protected]" target=3D"_blank">amelia.bellamy.royds@gmai=
l.com</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"l=
tr">I think the logic for declaring them &quot;No Interface Object&quot; wa=
s 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 c=
lutter up the global namespace. =C2=A0<div><br></div><div>If it is a breaki=
ng change that is causing problems in implementations, that would be a good=
 argument for implementing them as global objects.=C2=A0 But there are like=
ly to be other propblems: the hierarchy of interfaces was collapsed in many=
 cases and names were changed.=C2=A0 If tests are detecting the individual =
interface names, instead of the exposed methods and properties on the eleme=
nt interfaces, this re-organization becomes a breaking change, too.=C2=A0 I=
n contrast, if they are all &quot;No Interface Object&quot; interfaces, the=
n the exact names and organization of the mix-in interfaces is safe to chan=
ge, because it&#39;s never exposed in the API.</div><div><br></div><div>Are=
 you able to generate a full list of interfaces Firefox detects in test cas=
es?</div><span class=3D"HOEnZb"><font color=3D"#888888"><div><br></div><div=
>~ABR</div></font></span></div><div class=3D"HOEnZb"><div class=3D"h5"><div=
 class=3D"gmail_extra"><br><div class=3D"gmail_quote">On 21 August 2016 at =
15:07, Robert Longson <span dir=3D"ltr">&lt;<a href=3D"mailto:longsonr@gmai=
l.com" target=3D"_blank">[email protected]</a>&gt;</span> wrote:<br><block=
quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc=
 solid;padding-left:1ex"><div dir=3D"ltr"><pre>SVG 2 has this webidl defini=
tion of SVGZoomAndPan<br></pre><pre><br>[NoInterfaceObject]
interface <b>SVGZoomAndPan</b> {

  // Zoom and Pan Types
  const unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html#__s=
vg__SVGZoomAndPan__SVG_ZOOMANDPAN_UNKNOWN" target=3D"_blank">SVG_ZOOMANDPAN=
_UNKNOWN</a> =3D 0;
  const unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html#__s=
vg__SVGZoomAndPan__SVG_ZOOMANDPAN_DISABLE" target=3D"_blank">SVG_ZOOMANDPAN=
_DISABLE</a> =3D 1;
  const unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html#__s=
vg__SVGZoomAndPan__SVG_ZOOMANDPAN_MAGNIFY" target=3D"_blank">SVG_ZOOMANDPAN=
_MAGNIFY</a> =3D 2;

  attribute unsigned short <a href=3D"https://www.w3.org/TR/SVG2/types.html=
#__svg__SVGZoomAndPan__zoomAndPan" target=3D"_blank">zoomAndPan</a>;
};<br><br></pre><pre>Without the NoInterfaceObject one could write somethin=
g like<br><br>   if (element.zoomAndPan =3D=3D SVGZoomAndPan.SVG_ZOOMANDPAN=
_D<wbr>ISABLE)<br><br></pre><pre>While one now has to write it as <br><br> =
  if (element.zoomAndPan =3D=3D SVGSVGElement.SVG_ZOOMANDPAN_D<wbr>ISABLE)<=
br><br></pre><pre>The same applies to SVGUnitTypes. Do we mind about keepin=
g backwards<br>compatibility with any existing usages like this. We found w=
hen making<br>this change that our own unit tests fail on SVGUnitTypes usag=
e for<br>instance.<span><font color=3D"#888888"><br></font></span></pre><sp=
an><font color=3D"#888888"><pre>Robert<br></pre></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>

--001a113ddd583a40dc053aa34add--