This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"Otherwise, if PROTOTYPE does not inherit from the HTMLElement interface, throw a TypeMismatchError exception." In the text above, PROTOTYPE is some random object. It makes no sense to talk about it inheriting from a WebIDL interface; the "inherit" concept linked to in WebIDL there is largely a syntactic construct. Presumably what you actually want to check here is that the prototype chain of PROTOTYPE includes HTMLElement.prototype. Note that even if this is true at register() call time it can stop being true later, but that's life.
PROTOTYPE is not some random object. It's defined to be an interface prototype object (, and WebIDL defines what "inherit" means in respect to interface prototype objects. I think it would be terrible to just invent new things in this spec, instead of relying on WebIDL. If WebIDL needs to firm out how this syntactic construct translates to ECMAScript better, then that's what we need to do.
> It's defined to be an interface prototype object Ah... where does it say that? Is that the "Otherwise, if PROTOTYPE does not inherit from the HTMLElement interface, throw a TypeMismatchError exception." bit? > and WebIDL defines what "inherit" means in respect to interface prototype > objects. No, it doesn't. It defines what it means for an interface to inherit from another interface, which is not the same thing. > If WebIDL needs to firm out how this syntactic construct translates to > ECMAScript better, then that's what we need to do. That's fine, but that needs to happen then. Sweeping the issue under the rug won't make it happen. Again, this is not a theoretical issue. The one implementation of this spec I've looked at certainly allowed any object that had HTMLElement.prototype on its proto chain as the prototype here, so either it can in fact be a random object or this implementation was wrong and the spec was not clear enough.
(In reply to comment #2) > > and WebIDL defines what "inherit" means in respect to interface prototype > > objects. > > No, it doesn't. It defines what it means for an interface to inherit from > another interface, which is not the same thing. Boris is right about this. Interfaces inherit from other interfaces; ECMAScript objects can implement interfaces. Interface prototype objects don't implement any interfaces. > > If WebIDL needs to firm out how this syntactic construct translates to > > ECMAScript better, then that's what we need to do. > > That's fine, but that needs to happen then. Sweeping the issue under the > rug won't make it happen. > > Again, this is not a theoretical issue. The one implementation of this spec > I've looked at certainly allowed any object that had HTMLElement.prototype > on its proto chain as the prototype here, so either it can in fact be a > random object or this implementation was wrong and the spec was not clear > enough. I can't tell what spec this bug is about, so I don't know if this suggestion is exactly what you want, but maybe wording like this could work: Otherwise, if PROTOTYPE is not an interface prototype object for an IDL interface that inherits from HTMLElement, throw a TypeMismatchError exception.
(In reply to comment #3) > (In reply to comment #2) > > > and WebIDL defines what "inherit" means in respect to interface prototype > > > objects. > > > > No, it doesn't. It defines what it means for an interface to inherit from > > another interface, which is not the same thing. > > Boris is right about this. Interfaces inherit from other interfaces; > ECMAScript objects can implement interfaces. Interface prototype objects > don't implement any interfaces. This makes sense. I am still trying to wrap my head around this whol WebIDL thing. It's a big tool :)
Help me out here. I think there a clear path of walking back from an interface object toward the interface. In other words, can we say that an interface object with a corresponding interface prototype object _defines_ an interface? WebIDL is not very concerned with this particular direction, since it's designed to describe some defined interfaces. But I need it in order to claim that once a user feeds an interface object/interface prototype object into document.register, the user effectively defined an interface.
https://dvcs.w3.org/hg/webcomponents/rev/9fa1bfdb51d9 I fixed the bug itself, by the way: http://parkour.mtv/webcomponents/spec/custom/index.html#dfn-document-register This aligns document.register with the interface hook what Anne added http://dom.spec.whatwg.org/#concept-element-interface I'll rework createElement/NS to work with this next. Please let me know if I goofed up somewhere.
In WebIDL terms, implementating of an interface is completely divorced from prototype objects. It's just a property of an object, or not. I suppose having a prototype object plus an interface object "define" an interface can work, but then you have to define what inheritance means for such interfaces and their interaction with WebIDL interfaces. The first two links in comment 6 go to an HTTP 500 error and something inside your firewall respectively, so I can't help you out in terms of whether what you wrote makes sense....
(In reply to comment #7) > I fixed the bug itself, by the way: > http://parkour.mtv/webcomponents/spec/custom/index.html#dfn-document-register https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-document-register
Ah, thanks. Are the steps in step 4 done in order? If so, seems like this so far throws on all non-HTML namespaces right? Just making sure that's intended.
(In reply to comment #9) > Ah, thanks. > > Are the steps in step 4 done in order? If so, seems like this so far throws > on all non-HTML namespaces right? Just making sure that's intended. Step 4.3 needs "Otherwise" in front, fixing. The key thing is that I am moving all of the namespace machinery to registration, rather than instantiation. Big refactor change to align the rest of the bits in a minute.
(In reply to comment #10) > (In reply to comment #9) > > Ah, thanks. > > > > Are the steps in step 4 done in order? If so, seems like this so far throws > > on all non-HTML namespaces right? Just making sure that's intended. > > Step 4.3 needs "Otherwise" in front, fixing. https://dvcs.w3.org/hg/webcomponents/rev/ebbacfd65fde > The key thing is that I am moving all of the namespace machinery to > registration, rather than instantiation. Big refactor change to align the > rest of the bits in a minute. This is now done. Using Anne's element interface hook, createElement/createElementNS monkeypatches are much simpler now, and document.register is the one that ensures proper name/namespace. https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element