Re: Defining exotic objects in IDL, HTML, or both?

In general, I'm happy to answer any "why did we did this instead of this"
questions. I would, however, caution that any attempts to significantly
re-engineer what we have would be incredibly costly.

This is an area where it is extremely difficult to achieve interop, and
getting Blink, Gecko, and Trident to coalesce on the current proposal was a
long process that we should not try to repeat. Especially since engines
(and the relevant module owners) have changed, I want to hold organizations
to their commitment-to-implement and do not want to re-open discussion or
suggest that this commitment has expired (especially because Gecko took the
risk of shipping the new behavior and demonstrating that it is
web-compatible).

>From that perspective, the observables defined in the web-platform-test are
basically fixed. The model in the prose is potentially more malleable, but
there are so many edge-case observables that fall out of it that changing
that model carries the risk that an implementor will reassess feasibility
and change their mind.

That all being said, I'm happy to discuss any of the pieces of what we came
up with in detail with whoever's interested. I can do this synchronously
too if that's better for anyone.

Cheers,
bholley

On Fri, Oct 16, 2015 at 9:19 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> On 10/16/15 11:57 AM, Domenic Denicola wrote:
>
>> What I was trying to point out was that by speccing a sufficiently
>> powerful proxy object we could stay entirely within ES semantics
>>
>
> While true, if I recall correctly abarth had objections to that
> specification approach because of the difficulty of proving that Blink's
> implementation is black-box indistinguishable from it.  So you probably
> want to consult with whoever is responsible for this stuff in Blink right
> now before going down this road.
>
> It sounded like you were proposing speccing a world where multiple
>> different objects get minted and then we override the definition of ===,
>> but I guess you were just talking about implementation strategies, and were
>> not making a spec proposal.
>>
>
> I believe the intent of the current etherpad is to describe constraints in
> more or less those terms (which most closely match how Blink implements
> this stuff right now), but in a way that can map to different
> implementation strategies.  Again, the choice of specification language was
> largely to placate the Blink implementors into maybe even considering
> implementing the resulting spec.
>
> -Boris
>