W3C home > Mailing lists > Public > public-html@w3.org > July 2009

Re: Request to include missing HTML tag interface specs in html5.idl

From: Dimitry Golubovsky <golubovsky@gmail.com>
Date: Wed, 15 Jul 2009 16:06:53 -0400
Message-ID: <bcba51a0907151306i30083e4dx87f9a8f32496db80@mail.gmail.com>
To: Travis Leithead <travil@microsoft.com>
Cc: "public-html@w3.org" <public-html@w3.org>

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:




#define DOM_CLASSINFO_MAP_BEGIN_NO_CLASS_IF(_class, _interface)

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:


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

** 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

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:48 UTC