W3C home > Mailing lists > Public > public-script-coord@w3.org > July to September 2014

Re: Exposing constructors of readonly interfaces to web authors

From: Robert O'Callahan <robert@ocallahan.org>
Date: Wed, 2 Jul 2014 10:05:04 +1200
Message-ID: <CAOp6jLYwuq+-0h0eH8B-awvh==eyz5SCoaC+5MUcihVEbrbW0g@mail.gmail.com>
To: Domenic Denicola <domenic@domenicdenicola.com>
Cc: Rik Cabanier <cabanier@gmail.com>, Dirk Schulze <dschulze@adobe.com>, Ian Hickson <ian@hixie.ch>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Jul 2, 2014 at 9:35 AM, Domenic Denicola <
domenic@domenicdenicola.com> wrote:

> From: rocallahan@gmail.com <rocallahan@gmail.com> on behalf of Robert
> O'Callahan <robert@ocallahan.org>
> > I'd like to push a little more against the requirement that every host
> object class have a corresponding WebIDL interface. That seems to require
> spec work and API maintenance for no author benefit, as well as making
> specs improperly  dependent on implementation details (that could
> legitimately vary across implementations).
>
> I'm having a hard time understanding this. From my understanding most
> (all?) implementations generate their bindings for their host object
> classes via WebIDL. And, WebIDL interfaces are always author-exposed, and
> never implementation details. So I must be missing something in what you're
> pushing back against.
>

Currently Gecko has an implementation of DOMQuadBounds with no
corresponding WebIDL interface. If I understand you correctly, you say that
because DOMQuadBounds has its own implementation, it must have its own
WebIDL interface in the spec.

Rob
-- 
Jtehsauts  tshaei dS,o n" Wohfy  Mdaon  yhoaus  eanuttehrotraiitny  eovni
le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o  Whhei csha iids  teoa
stiheer :p atroa lsyazye,d  'mYaonu,r  "sGients  uapr,e  tfaokreg iyvoeunr,
'm aotr  atnod  sgaoy ,h o'mGee.t"  uTph eann dt hwea lmka'n?  gBoutt  uIp
waanndt  wyeonut  thoo mken.o w
Received on Tuesday, 1 July 2014 22:05:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:22 UTC