W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

Re: Why can't we just use constructor instead of createdCallback?

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Fri, 10 Jan 2014 11:16:49 -0500
Message-ID: <52D01CF1.6060501@mit.edu>
To: Erik Arvidsson <arv@google.com>, Ryosuke Niwa <rniwa@apple.com>, Dominic Cooney <dominicc@google.com>
CC: WebApps WG <public-webapps@w3.org>, Jonas Sicking <jonas@sicking.cc>, "Edward O'Connor" <eoconnor@apple.com>, William Chen <wchen@mozilla.com>
On 1/10/14 11:10 AM, Erik Arvidsson wrote:
> My hope was that it would be rare to override Symbol.create for Elements
> so in most cases we would not need to call user code.

For spec purposes and parser implementation design purposes that doesn't 
matter.  If user code can be called, the algorithms involved have to 
handle user code being called at that point and potentially tearing the 
world down (or apart, or just rearranging it in macabre ways like user 
code tends to do)...

> After further discussing this with Dominic and others I've given up the
> hope that an object instance cannot be reached before the constructor
> has been called. This can happen due to navigating the DOM tree but also
> be manually calling `MyCustomElement[Symbol.create]()`. At this point I
> believe we should just resolve to best practice and that is to not use
> @@create directly and do not navigate the DOM tree in your constructors.

Yeah, agreed.

Received on Friday, 10 January 2014 16:17:22 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:21 UTC