This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The spec draft says: partial interface Document { Function register(DOMString name, optional Options options); } dictionary Options { object? prototype; DocumentFragment? template; LifecycleCallbacks? lifecycle; } dictionary LifecycleCallbacks { void created(); } There are a bunch of issues here: 1) There need to be semicolons between the toplevel things. 2) Putting a generic name like "Options" in a flat namespace is a bit weird. It needs a name that's less likely to be confusing to people and less likely to cause collisions. 3) "optional" is not valid on dictionary arguments. They're always optional, so adding it gives you a parse error. 4) LifecycleCallbacks is presumably meant to be a callback interface, not a dictionary right? But did you really want to use a callback interface here, not a callback function? 5) There seems to be some confusion in the prose that follows because it only talks about what to do if "prototype" is missing, say, not what to do if it's null. Strictly speaking, the current spec says to throw if it's null, but then it makes no sense to declare it nullable in the dictionary. 6) Nothing says what should happen if "template" is missing. 7) Nothing says what should happen if "callbacks" are missing. In any case, something like this might be more what you meant: callback ElementConstructor = Element(); partial interface Document { ElementConstructor register(DOMString name, ElementRegistrationOptions options); }; dictionary ElementRegistrationOptions { object? prototype = null; DocumentFragment? template = null; LifecycleCallbacks? lifecycle = null; }; callback interface LifecycleCallbacks { void created(); }; and then you don't have to worry about missing optional things, only null ones.
> 3) "optional" is not valid on dictionary arguments. They're always optional, > so adding it gives you a parse error. Sorry, that part is a lie. It's omitting the "optional" that's not OK. The rest is still true, I believe. ;)
(In reply to comment #0) Thank you for looking this over! > The spec draft says: > > partial interface Document { > Function register(DOMString name, optional Options options); > } > dictionary Options { > object? prototype; > DocumentFragment? template; > LifecycleCallbacks? lifecycle; > } > dictionary LifecycleCallbacks { > void created(); > } > > There are a bunch of issues here: > > 1) There need to be semicolons between the toplevel things. http://dvcs.w3.org/hg/webcomponents/rev/7a51557797a9 > 2) Putting a generic name like "Options" in a flat namespace is a bit weird. > It > needs a name that's less likely to be confusing to people and less likely > to > cause collisions. http://dvcs.w3.org/hg/webcomponents/rev/80d7af3a9111 > 3) "optional" is not valid on dictionary arguments. They're always > optional, so > adding it gives you a parse error. Good thing I saw your next comment :P > 4) LifecycleCallbacks is presumably meant to be a callback interface, not a > dictionary right? But did you really want to use a callback interface > here, > not a callback function? Oh yes! Callback interface is a better fit. http://dvcs.w3.org/hg/webcomponents/rev/cb0d68b7de41 As for being the function -- there will be more callbacks in this dictionary: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18748 http://www.w3.org/TR/components-intro/#appendix-a-interfaces (Note, this document is out of date, I haven't gotten to catching it up with the rest of the specifications yet). > 5) There seems to be some confusion in the prose that follows because it only > talks about what to do if "prototype" is missing, say, not what to do if > it's null. Strictly speaking, the current spec says to throw if it's > null, > but then it makes no sense to declare it nullable in the dictionary. http://dvcs.w3.org/hg/webcomponents/rev/3fa09764a196 > 6) Nothing says what should happen if "template" is missing. http://dvcs.w3.org/hg/webcomponents/rev/6a0c8a13f13d > 7) Nothing says what should happen if "callbacks" are missing. With the null/missing treatment unified, the steps now make sense. > In any case, something like this might be more what you meant: > > callback ElementConstructor = Element(); > partial interface Document { > ElementConstructor register(DOMString name, > ElementRegistrationOptions options); > }; > dictionary ElementRegistrationOptions { > object? prototype = null; > DocumentFragment? template = null; > LifecycleCallbacks? lifecycle = null; > }; > callback interface LifecycleCallbacks { > void created(); > }; > > and then you don't have to worry about missing optional things, only null > ones. Did I get them all? :) Not sure whether I should just use function ElementConstructor syntax yet. Sent mail to the list.
*** Bug 20242 has been marked as a duplicate of this bug. ***
> Did I get them all? :) Looks like it, yes. I wouldn't worry too much about the exact type of ElementConstructor for the moment, while WebIDL gets sorted out around there.
(In reply to comment #4) > > Did I get them all? :) > > Looks like it, yes. I wouldn't worry too much about the exact type of > ElementConstructor for the moment, while WebIDL gets sorted out around there. Cool! Filed bug 20329 so I don't forget.
The use of "prototype" as an identifier in the ElementRegistrationOptions dictionary is also invalid because it's a reserved identifier. http://www.w3.org/TR/WebIDL/#idl-names
That seems like a WebIDL bug to me, at first glance...
(In reply to comment #6) > The use of "prototype" as an identifier in the ElementRegistrationOptions > dictionary is also invalid because it's a reserved identifier. > > http://www.w3.org/TR/WebIDL/#idl-names Filed bug 20346 to track this. First reaction same as Boris' --> unless the object is a Function, seems like .prototype should be allowed.