Re: Minimum viable custom elements

> On Jan 14, 2015, at 6:45 AM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
> I've been trying to think of the smallest setup that adds value, can
> get broad agreement, and is therefore hopefully interoperable fast.
> 
> * ES6-style class syntax to declare the imperative constructor.
> * No subclassing of normal elements for now.
> * registerElement() to enable declarative syntax and createElement().
> * Parsing of declarative syntax invokes the registered constructor
> synchronously.

We support the proposals above.

> * Existing lifecycle callbacks plus those agreed (copying, adopting).

Could you give us pointers for a proposed definition of these two callbacks if there is any?

> Notably this does not address upgrading. I think we can defer
> upgrading as it can be implemented in script fairly easily. You await
> for the imperative constructors to load and DOMContentLoaded at which
> point you traverse the tree and invoke replace() on those elements you
> want to upgrade.

Of course, this doesn't quite work for custom elements used in shadow DOM if we assume shadow DOMs share the custom element registry with its document but this isn't a terribly interesting point in the world where neither feature is implemented across browsers because we can't agree on anything.

> It also does not address subclassing normal elements. Again, while
> that seems desirable the current ideas are not attractive long term
> solutions. Punting on it in order to ship a v1 available everywhere
> seems preferable.

I can't be enthusiastic enough to support this motion since that's more or less what I've been saying for the past six months or so.

- R. Niwa

Received on Wednesday, 14 January 2015 20:25:55 UTC