On 2/5/13 11:01 PM, Erik Arvidsson wrote:
On Tue, Feb 5, 2013 at 5:28 PM, Boris Zbarsky <bzbar...@mit.edu> wrote:
So in particular this allows creation of "uninitialized" instances in some
sense, yes?
Depends how much logic is put in the constructor vs @@create. For DOM
Elements I think we want to put *all* the logic in create.
OK, I can live with that as long as the only arguments are things like
for Image. We'll have to be pretty careful about how we define our
Element subclass constructors in the future, though...
And there are knock-on effects on all other objects in WebIDL. See below.
This won't work right given how HTMLButtonElement is currently defined in
WebIDL. Need to fix that at the very least.
Yes, but for document.register I think we can get away without
changing this.
No, you can't. You really need to get WebIDL fixed here.
We might need to add no op call methods to these
functions
They already have [[Call]]. What they don't have is a custom
[[Construct]]. Which means that they end up invoking the [[Construct]]
defined in ES5 section 13.2.2, which in step 8 calls the [[Call]] and if
that returns an object (which the WebIDL [[Call]] does) throws away the
object that [[construct]] just created and returns the object [[Call]]
returned.
And you can't no-op the [[Call]] because web pages, afaik, use things like:
var myImage = Image();
and
var xhr = XMLHttpRequest();
just like they use Date() and Object() and Array(). The above is
supported for DOM constructors in at least Gecko and Presto, though
apparently not Chrome or Safari; I don't have IE to test right now. But
the point is that right now those constructors are not particularly
weird in Gecko and Presto, and I'm not entirely happy making them _more_
weird.
Maybe the fact that Chrome and Safari don't support this means that we
can in fact redefine the [[Construct]] to create the right sort of
object and then invoke [[Call]] which will actually initialize the
object. But that brings us back to being able to create
partially-initialized objects for all IDL interfaces, not just elements....
Perhaps we need to define an IDL annotation for interfaces that opt in
to this split between [[Call]] and [[Construct]] and then have elements
opt in to it?
but that seems like the right thing to do anyway. The WebIDL
interface constructors are already strange as they are
Not in Gecko and Presto as far as I can tell... Certainly not any
stranger than Date or Array.
and I doubt anyone would object to making them less strange.
I have no problem with less strange, but you're proposing more strange.
Again, as far as I can tell.
What happens if the same function is registered for several different tag
names, in terms of what happens with the [[Construct]]?
I vote for throwing. We could allow the tag name to be used as an
alias but I don't really understand the use case you have in mind
here.
I don't have a use case. What I have is an edge case that I can see
implementations doing random non-interoperable crap for if we don't
define it.
Throwing sounds fine to me.
Define, please. How does one determine this, in a rendering engine
implementation? I certainly have no way to tell, in Gecko, when I'm
"entering script", offhand....
I was told this is needed for mutation observers that are queued up
during parse. I'll let Dimitri or Rafael chime in with details.
Ah, OK. Defining this stuff to happen at end of microtask or whatever
it is that normally triggers mutation observers makes a lot more sense
than "before entering script". ;)
Thanks,
Boris
