| 18:46 | <bkardell> | hey so, I was meeting with developer friends online and we got to talking about shadow dom and a number of conversations came up for which I couldn't recall some of the rationale for answers we came up with so I began digging back in history and I think I wound up with just different questions... |
| 18:47 | <bkardell> | Is the reason that we shaped a lot of the characteristics of shadow dom the way we did (you can't remove them, we throw rather than replace or something if you try to do it again) bound up in the original talks from circa 2011 where the proposals had mutple shadow roots |
| 18:48 | <bkardell> | or is there a real good reason why you can't specifically say 'yes, I really do intend to replace any shadow root that might exist with this one instead' |
| 18:52 | <bkardell> | I realize that seems to beg for a use case at some level since it seems like you could just replace the _contents_ of a shadow root, so for context it was bound up in reasoning and discussion about all sorts of aspects about 'native' shadow roots and what things would throw and why and them trying to come up with some way around challenges |
| 21:02 | <howdoi> | the portal is not associated with a predecessor browser context, when would this happen? |
| 22:28 | <howdoi> | var portal = e.adoptPredecessor(); |
| 22:28 | <howdoi> | document.body.appendChild(portal); |
| 22:28 | <howdoi> | But now, I am able not able to do any actions on the appended child....am I missing something? |
| 22:29 | <howdoi> | also, we can't invoke `e.adoptPredecessor();` twice in `onportalactivate` ? |