Re: Defining a constructor for Element and friends

On 1/7/15 9:51 AM, Anne van Kesteren wrote:
> That is what I meant. Otherwise in order to support new Element()
> you'd have to support an ever growing set of more specific objects as
> well and layering is out of the window.

Do you mean layering of implementations or specifications?  For 
specifications, here's one way this could work with reasonable layering. 
  DOM provides the following bits:

1)  A registry mapping (namespace, localname) pairs to abstract 
operations that allocate an object.

2)  Abstract operations that can be used by specifications built on top 
of DOM to register abstract operations in this registry.

3)  An abstract operation that takes a list of internal slot names and 
returns an object which has those internal slots, plus the internal 
slots all elements have, plus probably the ordinary object internal 
slots from ES6, depending on whether Web IDL assumes these are ordinary 
objects.  I thought ES6 had this sort of abstract operation already, but 
I don't see anything like it; in any case the only issue here is that 
this requires implementations of DOM and specifications built on top of 
it to agree internally on what "internal slot" means for elements, I agree.

Specifications that define elements on top of DOM provide the following 
bits:

4)  An abstract operation that creates an uninitialized version of their 
element, via calling the thing defined in #3.

5)  Registration of the abstract operation defined in #4 with the 
registry defined in #1, whether that happens at global-setup time or 
when the element definition is encountered or whatever.

An implementation that wants to just implement core DOM but not things 
built on on top of it can skip all of this machinery.  An implementation 
that wants to support DOM but not everything on top of it (e.g. support 
MathML but not HTML or something) just supports the bits it wants and 
the registry ends up not having stuff in it that it has in other 
implementations.  Seems ok to me.

Now some questions:

* Did I cover your concern about "have to support an ever growing set of 
more specific objects"?  If not, can you explain what the concern is?

* Without a mechanism like the above, how would one go about supporting 
document.createElement(NS) as it exists on the web.

> However, that does indeed seem like a lot of work and it's not clear
> whether that actually pays off in the end :-(

That's hard to say without knowing what the desired payoff is.

-Boris

Received on Wednesday, 7 January 2015 15:33:23 UTC