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

Re: Custom element design with ES6 classes and Element constructors

From: Yehuda Katz <wycats@gmail.com>
Date: Tue, 13 Jan 2015 13:07:21 -0800
Message-ID: <CAMFeDTX_OHSLr2dq4pqkkgJnqAewHcvSRgr8_uUZy3d2DxT+7g@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: Boris Zbarsky <bzbarsky@mit.edu>, "public-webapps@w3.org" <public-webapps@w3.org>
On Tue, Jan 13, 2015 at 9:50 AM, Domenic Denicola <d@domenic.me> wrote:

> From: Boris Zbarsky [mailto:bzbarsky@mit.edu]
> > Just to be clear, this still didn't allow you to upgrade a <my-img> to
> be a subclass of <img>, because that required a change in allocation, right?
> Agreed. That needs to be done with <img is="my-img">, IMO. (Assuming the
> upgrading design doesn't get switched to DOM mutation, of course.)

Can someone help outline for me exactly why DOM mutation is a problem here?
I can definitely see downsides, but DOM mutation is a fact of life when
scripts are involved on today's web, and it sidesteps a lot of the problems
that we encounter by trying to make in-place upgrading (upgrades without
changing the reference at all) work sanely.

I mean, qSA might not work the way someone might expect, but it also might
not work if you go `$("my-button").button()` using jQuery. What expectation
do we imagine someone has here that we think is missing if we use DOM
mutation (rather than object-model mutation) for upgrades.

-- Yehuda
Received on Tuesday, 13 January 2015 21:08:09 UTC

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