- From: Dimitri Glazkov <dglazkov@google.com>
- Date: Tue, 16 Apr 2013 14:33:31 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Boris Zbarsky <bzbarsky@mit.edu>, 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>, 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 6:59 AM, Anne van Kesteren <annevk@annevk.nl> wrote: > > 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. What if we use the newly-found power if readyCallback here? Suppose that HTMLAudioElement has a readyCallback that, among other things does: if (!this.parentNode) // aha! I am created imperatively this.setAttribute("controls"); Several HTML elements will need to use the callback to build their shadow trees and set internal state, like <textarea>, <input>, <details>, <fieldset>, etc. If we just build readyCallback into DOM, we have cake. :DG<
Received on Tuesday, 16 April 2013 21:33:59 UTC