> On Jan 12, 2015, at 5:16 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> 
> On Sun, Jan 11, 2015 at 9:13 PM, Domenic Denicola <d...@domenic.me> wrote:
>> However, I don't understand how to make it work for upgraded elements at all
> 
> Yes, upgrading is the problem. There's two strategies as far as I can
> tell to maintain a sane class design:
> 
> 1) There is no upgrading. We synchronously invoke the correct
> constructor. I've been trying to figure out the drawbacks, but I can't
> find the set of mutation events problems that relates to this. One
> obvious drawback is needing to have all the code in place so you might
> need a way to delay the parser (return of synchronous <script>
> loading).
> 
> 2) As you indicate, upgrading becomes replacing. This used to be the
> old model and got eventually killed through
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=21063 though there's no
> clear summary as to why that happened. Issues seem to be: mutation
> observer spam, dangling references, attributes, event listeners.

As we have repeatedly stated elsewhere in the mailing list, we support option 1
since authors and frameworks can trivially implement 2 or choose to set 
"prototype"
without us baking the feature into the platform.

- R. Niwa

Reply via email to