[Bug 20567] Change [[Prototype]] for concept-node-adopt?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20567

--- Comment #67 from Bobby Holley (:bholley) <bobbyholley@gmail.com> ---
(In reply to Dominic Cooney from comment #66)
> Probably. There's no element death callback, so maybe being adopted away is
> like that?

By element death do you mean the destruction of the underlying element? That
only happens when (a) the node (or its ancestor) is detached from the document
or (b) the entire window is destroyed, right?

> > (4) In comment 51, Dmitri expresses his dismay with (3), and says that we
> > should make Web Components behave as much like the rest of the DOM as
> > possible.
> 
> FWIW I agree with Dimitri. I think it's weird if you can't adopt Custom
> Elements like any other kind of element.

I'm inclined to agree, from an author's perspective. But we also don't want to
offer people APIs that turn out to be perf/memory gotchas. So I think we should
design things so that this is safe to do.

> > (5) bholley provides Telemetry data indicating that prototype swizzling is
> > required in the general case to prevent unacceptably-large leaks.
> 
> I don't think this quite follows... I saw data about leak frequency, but not
> size.

Well, it's the size of a javascript global scope, which will vary between
implementations. But it's significant. Looking at the tabs I have open right
now, this would be (in Firefox nightly):
example.com: 200k
html5 spec: 6MB
gmail: 22MB
Wunderlist: 15MB
Google spreadsheets: 12MB

So if we leak, on average, 2 instances of example.com at any given time, it's
probably not such a big deal. But if we leak 2 instances of Wunderlist, it's a
really big deal, especially on mobile.

> Modulo the inline comments that's it. I wasn't able to come up with
> something better. I think developers on Chrome are happy their Custom
> Elements continue to work in other documents--even that is probably a rare
> case--

Yeah, authors don't generally care much about leaks. Users just blame the
browser. :-(


> Do you have any data to share about the size of the JavaScript state versus
> the DOM state?

in Gmail, Wunderlist, and example.com, the JS state dwarfs the DOM state by an
order of magnitude. It's about 5x for spreadsheets. It's the opposite story for
the HTML5 spec, though that always tends to be a bit of an outlier.

> > In the light of comment 56, I would wager that it is more likely than not
> > that swizzling will get specced for the DOM in general. If that does happen,
> > the options I can think of for Custom Elements are:
> > (A) Swizzle the prototypes. If a Custom Element with the same name been
> > registered the new scope, the prototype points to that. Otherwise, the
> > element loses its magic. This approach requires figuring out the semantics
> > of |detachedCallback|.
> 
> This is basically right. You're proposing a relatively specific solution
> here--that if the names are equal, then one definition should be substituted
> for another. There might be specific tweaks to a solution in this area that
> makes authors happier.

Totally. This is what I'm hoping you can figure out!

> > (B) Leave the prototype in the old scope for Custom Elements. This leaks,
> > and makes Custom Elements more special, but might be more friendly to web
> > developers.
> 
> It would be nice to not add more magic (although it's only magic if other
> nodes behavior changes... FWIW this matches most closely what Chrome does
> today.)

Right.

My big concern here is that what we do now for Web Components is going to
constrain us in the future. For regular HTML elements, web authors aren't
depending on the existence/non-existence of swizzling, because it differs
between browsers, and the prototype's global generally isn't all that
important. But if we let authors depend on no-swizzle for Web Components now,
we'll probably have to preserve that behavior forever, even if Blink ends up
aligning with Gecko and Trident and implementing swizzling for non Custom
Elements.

This is why I think we should implement behavior now that is at least
compatible with swizzling should we decide to do it. Hopefully we can engineer
something clever. If not, I think we should at least throw, so that we have the
flexibility to tackle the problem later without breaking the Web.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 17 January 2014 02:00:57 UTC