Re: Monkeypatching document.createElement() is wrong
On Tue, 12 Feb 2013 12:24:59 +0100, Anne van Kesteren ann...@annevk.nl wrote: If the goal of custom elements is to expose the guts of what happens https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element is the wrong solution. Currently new Image() and createElement(img) are equivalent and no additional magic is required. Same for new Audio() and createElement(audio). Not quite, actually. new Audio() sets the content attribute preload=auto. -- Simon Pieters Opera Software
Re: Monkeypatching document.createElement() is wrong
On Mon, Mar 18, 2013 at 9:56 AM, Simon Pieters sim...@opera.com wrote: Not quite, actually. new Audio() sets the content attribute preload=auto. I see. We could also do that for createElement(audio) of course, depending on how we decide this actually works. -- http://annevankesteren.nl/
Re: Monkeypatching document.createElement() is wrong
+others who have been involved in the design phase of the Google proposal So there are several viable points in the design space here. I'll try to outline them quickly: 1. An internal lifecycle driver for element + shadow creation. In this strategy, an element's constructor either calls createShadow()/finalizeInitialization() methods directly, or calls the superclass constructor to ensure that they are invoked. 2. External lifecycle driver. In this design, it's up to whoever new's up an Element to ensure that it's fully formed before injecting it into the DOM. The current design codifies the second. Regarding Audio() and Image(), it's possible to model them as having internal already called flags on their shadow creation methods that prevent double initialization by createElement(). But I agree that it's messier and muddies the de-sugaring story. Dimitri? Dominic? On Tuesday, February 12, 2013, Anne van Kesteren wrote: If the goal of custom elements is to expose the guts of what happens https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element is the wrong solution. Currently new Image() and createElement(img) are equivalent and no additional magic is required. Same for new Audio() and createElement(audio). What we want is that var x = document.createElement(name) maps to / is identical to var x = new name's-corresponding-object and nothing else. -- http://annevankesteren.nl/
Re: Monkeypatching document.createElement() is wrong
On Tue, Feb 12, 2013 at 3:24 AM, Anne van Kesteren ann...@annevk.nl wrote: If the goal of custom elements is to expose the guts of what happens https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#monkeypatch-create-element is the wrong solution. Currently new Image() and createElement(img) are equivalent and no additional magic is required. Same for new Audio() and createElement(audio). What we want is that var x = document.createElement(name) maps to / is identical to var x = new name's-corresponding-object and nothing else. ... and that's exactly how custom elements are being spec'd. See how constructor is generated: https://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/custom/index.html#dfn-custom-element-constructor-generation By the wrongness, do you mean the running shadow tree instantiation and element finalization steps? If so, they are workarounds for our inability to define an author-defined constructor. There's a nice thread that tries to enable this and eliminate these extra steps, but from what I understand, there's a monkey wrench thrown by inability of current JS engines to accommodate the proposed design: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg250 :DG
Re: Monkeypatching document.createElement() is wrong
On Tue, Feb 12, 2013 at 5:06 PM, Dimitri Glazkov dglaz...@chromium.org wrote: By the wrongness, do you mean the running shadow tree instantiation and element finalization steps? If so, they are workarounds for our inability to define an author-defined constructor. Yes. There's a nice thread that tries to enable this and eliminate these extra steps, but from what I understand, there's a monkey wrench thrown by inability of current JS engines to accommodate the proposed design: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg250 Given all the other plumbing that's required to get web components working and ES6 requires said design to work, I'd think that waiting a little longer to do the right thing is acceptable. -- http://annevankesteren.nl/
Re: Monkeypatching document.createElement() is wrong
On Tue, Feb 12, 2013 at 9:13 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 12, 2013 at 5:06 PM, Dimitri Glazkov dglaz...@chromium.org wrote: By the wrongness, do you mean the running shadow tree instantiation and element finalization steps? If so, they are workarounds for our inability to define an author-defined constructor. Yes. There's a nice thread that tries to enable this and eliminate these extra steps, but from what I understand, there's a monkey wrench thrown by inability of current JS engines to accommodate the proposed design: http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg250 Given all the other plumbing that's required to get web components working and ES6 requires said design to work, I'd think that waiting a little longer to do the right thing is acceptable. Waiting a little bit longer is a fine phrase, except it neither sets the timeline nor priorities. If it's weeks, not months, I agree. Otherwise, I would rather consider workable solutions. We've been waiting for XBL2 for a little bit now :) :DG
