- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 15 Apr 2013 14:59:52 +0100
- To: Boris Zbarsky <bzbarsky@mit.edu>
- Cc: Rick Waldron <waldron.rick@gmail.com>, Daniel Buchner <daniel@mozilla.com>, Scott Miles <sjmiles@google.com>, Allen Wirfs-Brock <allen@wirfs-brock.com>, John J Barton <johnjbarton@johnjbarton.com>, Dimitri Glazkov <dglazkov@google.com>, Rafael Weinstein <rafaelw@google.com>, public-webapps <public-webapps@w3.org>, Blake Kaplan <mrbkap@mozilla.com>, William Chen <wchen@mozilla.com>, Jonas Sicking <jonas@sicking.cc>, Steve Orvell <sorvell@google.com>, Dave Herman <dherman@mozilla.com>
On Mon, Apr 15, 2013 at 1:55 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 4/14/13 4:57 PM, Rick Waldron wrote:
>> Of course, but we'd also eat scraps from the trash if that was the only
>> edible food left on earth. document.createElement() is and has always
>> been "the wrong way"—the numbers shown in those graphs are grossly
>> skewed by a complete lack of any real alternative.
>
> Amen. I strongly support making all *Element constructors actually work.
> The hard part is dealing with the cases when lots of elements share the same
> interface...
I think we should go for one interface per element here. "abstract
classes" not being constructable seems fine. Node/CharacterData are
similar to that. This would mean HTMLH1Element, ..., of which
compatibility impact has not been measured.
The other problem we need to solve is that document.createElement(<x>)
currently gives different results from new <x's interface>. E.g. new
Audio() sets an attribute, document.createElement("audio") does not. I
think we should settle for document.createElement("audio") also
creating an attribute here.
And the last problem (I think) is determining the document object. I
think we should follow http://dom.spec.whatwg.org/#dom-document new
Document() and friends for that.
--
http://annevankesteren.nl/
Received on Monday, 15 April 2013 14:00:20 UTC