- From: Ryosuke Niwa <rniwa@apple.com>
- Date: Mon, 13 Jul 2015 13:29:56 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Dominic Cooney <dominicc@google.com>, Olli Pettay <olli@pettay.fi>, WebApps WG <public-webapps@w3.org>
> On Jul 12, 2015, at 11:30 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > > 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. Editing operations use cloning heavily. As counter-intuitive as it sounds, deleting a range of text also involves cloning elements in some cases. - R. Niwa
Received on Monday, 13 July 2015 20:30:28 UTC