- From: Garrett Smith <dhtmlkitchen@gmail.com>
- Date: Fri, 9 Sep 2011 11:45:52 -0700
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Alex Russell <slightlyoff@google.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On 9/9/11, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 9/9/11 4:24 AM, Alex Russell wrote: >>> Specification writers need to write the actual behaviour for these >>> constructors whether they are implicitly declared or not. >> >> The default behavior would simply be to generate objects of those >> types without side effects. > > What if there are not normally objects of those types? Or more than one > kind of object of those types? > > For example, what should |new Element()| do if the specification doesn't > define it? Yes, I already asked. There's no sane behavior, because you have no idea what tag > name to give it. > Possibly HTMLUnknownElement, though I can't see a reason for why anybody would want such shortcut behavior from `new Element`. Factories are justified in DOM core by their trait of extensibility: "...DOM APIs to be implemented as a thin veneer on top of legacy applications with their own data structures, or on top of newer applications with different class hierarchies. This also means that ordinary constructors (in the Java or C++ sense) cannot be used to create DOM objects, since the underlying objects to be constructed may have little relationship to the DOM interfaces..." -http://www.w3.org/TR/DOM-Level-3-Core/core.html#ID-249F15BA > You can find some examples where the behavior is "clear"... But even in > the |new HTMLDivElement| case, what would define what the ownerDocument > of the new element is? WebIDL itself certainly can't make such a > definition. The fact that an ownerDocument even exists is specific to > the HTMLDivElement interface, and whatever spec defines that interface > would need to explicitly address that. > The global object's window's document -- window.document, e.g. in newer browsers: new Image().ownerDocument == window.document <aside title="[[Construct]] is Not Always Available"> >> In any case, it repairs the mental model of the mappings between JS >> and DOM where in JS, functions can *always* be invoked via "new", > Only functions which implement [[Construct]] can be invoked using `new`. ECMA-262 specification explicitly states that the built-in functions don't implement [[Construct]]. Try a `new parseInt` for example. It might work in some Moz engines, but it can be expected to throw -- and throw it will in IE. </aside> Not sure how that matters, just correcting the facts. The properties of an in a document in a version of a browser may be unique to that environment. A different way of thinking instead of categorizing objects by their tagName is to consider which interfaces those objects support. IOW, not "is it constructed by [x]", but "can it do [x]". -- Garrett
Received on Friday, 9 September 2011 18:46:20 UTC