- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 13 Jul 2015 08:30:43 +0200
- To: Dominic Cooney <dominicc@google.com>
- Cc: Olli Pettay <olli@pettay.fi>, WebApps WG <public-webapps@w3.org>
On Mon, Jul 13, 2015 at 1:10 AM, Dominic Cooney <dominicc@google.com> wrote: > Yes. I am trying to interpret this in the context of the esdiscuss thread > you linked. I'm not sure I understand the problem with private state, > actually. Private state is allocated for DOM wrappers in Chromium today > (like Gecko), including Custom Elements; it's not a problem. DOM wrapper > creation is controlled by the UA, which can arrange for allocating the > slots. Sure, but this assumes elements will be backed by something other than JavaScript forever. Or at the very least that custom elements will always be able to do less than builtin elements. > Is there a plan for author classes to be able to have private state or > something? Yes, as discussed in that es-discuss thread. > Thanks. I can understand how editing and Range.cloneContents would use > cloning. How is it relevant that Range is depended on by Selection? > Selection may delete things but it does not clone them. Editing operations operate on selections, but maybe I'm mistaken about that? Either way, you got the problem. >> That during cloning certain DOM operations cease to function, basically. > > This sounds interesting; it may even be useful for authors to be able to > assert that between two points they did not modify the DOM. Short of rewriting ranges and editing, that seems like the only viable alternative to prototype swizzling, provided you're okay with seeing upgrades as a distinct problem. -- https://annevankesteren.nl/
Received on Monday, 13 July 2015 06:31:21 UTC