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

Re: Minimum viable custom elements

From: Steve Faulkner <faulkner.steve@gmail.com>
Date: Thu, 12 Feb 2015 10:33:34 +0000
Message-ID: <CA+ri+VmtnigSMVq6YjtHu7iEQUgUHe=BRn+d7gOtU-ANzZRHjQ@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebApps WG <public-webapps@w3.org>
this turned up today:
A possible solution for web component subclasses

needs people who actually understand this stuff to critique ;-)



HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>

On 14 January 2015 at 14:45, 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.
> * Existing lifecycle callbacks plus those agreed (copying, adopting).
> 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. Ideally at some point we find a declarative solution
> for this, perhaps something like "HTML modules", but shipping a v1 of
> custom elements in multiple browsers should not have to wait for that.
> 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.
> --
> https://annevankesteren.nl/
Received on Thursday, 12 February 2015 10:34:43 UTC

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