- From: Alex Russell <slightlyoff@google.com>
- Date: Tue, 13 Sep 2011 15:37:48 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
On Fri, Sep 9, 2011 at 2:01 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 9/9/11 3:04 PM, Garrett Smith wrote: >> >> OK, so in the case of Element, that would be web dom core, right? >> http://www.w3.org/TR/domcore/ > > Yes. But the point is that if the spec needs to worry about the constructor > no matter what, WebIDL's claiming that there is a constructor by default is > not very useful. In my opinion. That's vs. the current state, in which *most* spec authors simply fail to add constructors of any type and aren't bothered with questions of what they should look like, since the easiest thing to do is to simply screw over JS devs and leave the problem unaddressed. Forcing the issue *is progress*, not a reason not to do it. >>> Is this really such a hard concept to grasp? I'm getting the feeling >>> that people are really confused about what WebIDL itself can define and >>> what specs using WebIDL as their interface description language can >>> define... >>> >> "This document defines an interface definition language, Web IDL, that >> can be used to describe interfaces that are intended to be implemented >> in web browsers." >> >> So essentially, you want to describe in a general sense how interface >> objects work and leave the specifics of how they're implemented to the >> specifications in which define them. Did I get that right? > > That's how it works, yes.... In particular, WebIDL itself cannot say > anything about how any _particular_ interface behaves. > > -Boris >
Received on Tuesday, 13 September 2011 22:38:44 UTC