- From: Dimitry Golubovsky <golubovsky@gmail.com>
- Date: Wed, 15 Jul 2009 16:06:53 -0400
- To: Travis Leithead <travil@microsoft.com>
- Cc: "public-html@w3.org" <public-html@w3.org>
Travis, This is useful for better type approximation of interfaces (in languages where types are meaninglful, like Haskell* that I am working with). For Javascript, it does not make any difference, I agree. Just by googling for "interface HTMLSpanElement", it can be seen that tool maintainers work around that by mere reintroducing the missing interfaces manually. E. g. this page: https://developer.mozilla.org/en/Mozilla_DOM_Hacking_Guide says: ========================== #define DOM_CLASSINFO_MAP_BEGIN_NO_CLASS_IF(_class, _interface) _DOM_CLASSINFO_MAP_BEGIN(_class, &NS_GET_IID(_interface), PR_FALSE) This macro should be used for DOM classes that have no "leaf" interface. For example, there is no HTMLSpanElement in the W3C DOM specification. Therefore, the first interface in the prototype chain for the span element is HTMLElement. However we do want to be able to access HTMLSpanElement to modify it. This macro allows you to do that. ========================== Also see https://bugzilla.mozilla.org/show_bug.cgi?id=92071#c8 which outlined the same problem (back in 2001) and shows the same list of tags I mentioned. This page: http://msdn.microsoft.com/en-us/library/cc849009(VS.85).aspx shows similar thing that Microsoft does, to my understanding: defining an interface that W3C did not define, but someone would need it. So, perhaps here may be the solution. W3C might "officially" provide an IDL file with these interfaces separately from html5.idl. Web IDL** specification moves towards not requiring forward interface declarations thus enabling the compiler consume IDL fragments in any order (rather than the order currently enforced by #include directives). Whoever needs these interfaces, might incorporate the said file with their project. the rest would just ignore it. Basically I did the same in my project, only the file was generated by myself. Thank you. ------------------------------------------ * Haskell uses a library of "templates" to generate Javascript calls to DOM methods; these templates are generated automatically from IDL specifications; thus having a correct datatype for each interface is important. ** Per the editor's draft, http://dev.w3.org/2006/webapi/WebIDL On 7/15/09, Travis Leithead <travil@microsoft.com> wrote: > While this seems like a nice idea, would it require implementations to change the prototype inheritance model for said tags? And if so, it seems like a useless performance problem to have to traverse the prototype chain of a completely empty prototype just because of a convenience for automatic tools. I'd prefer not to introduce empty interfaces where no new real functionality is needed. -- Dimitry Golubovsky Anywhere on the Web
Received on Wednesday, 15 July 2009 20:07:33 UTC