On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com wrote:
Wait, what do you mean by that is what custom elements provide for today..
The entire pattern of template-stamping depends on the fact that custom
elements aren't broken when cloning/importing.
There's no hook for
On Tue, Feb 24, 2015 at 12:14 AM, Anne van Kesteren ann...@annevk.nl
wrote:
On Mon, Feb 23, 2015 at 11:58 PM, Ryosuke Niwa rn...@apple.com wrote:
In that regard, perhaps what we need another option (although 4 might be
a developer friendly superset of this):
5) Don't do anything. Custom
Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=28092 to add more data
to the informative content around the normative statement that makes this
happen.
On Tue, Feb 24, 2015 at 7:39 AM, Dimitri Glazkov dglaz...@google.com
wrote:
On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren
On Tue, Feb 24, 2015 at 7:37 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Tue, Feb 24, 2015 at 4:35 PM, Dimitri Glazkov dglaz...@google.com
wrote:
Wait, what do you mean by that is what custom elements provide for
today..
The entire pattern of template-stamping depends on the fact
On 2/23/15 4:27 AM, Anne van Kesteren wrote:
1) If we run the constructor synchronously, even during cloning. If
the constructor did something unexpected, is that actually
problematic? It is not immediately clear to me what invariants we
might want to preserve. Possibly it's just that the code
On Feb 23, 2015, at 6:42 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/23/15 4:27 AM, Anne van Kesteren wrote:
1) If we run the constructor synchronously, even during cloning. If
the constructor did something unexpected, is that actually
problematic? It is not immediately clear to me
I've been continuing to explore synchronous constructors for custom
elements as they explain the parser best. After reading through
https://speakerdeck.com/vjeux/oscon-react-architecture I thought there
might be a performance concern, but Yehuda tells me that innerHTML
being faster than DOM
