- From: Mason Freed <notifications@github.com>
- Date: Mon, 12 Apr 2021 15:49:07 -0700
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Monday, 12 April 2021 22:49:20 UTC
@mfreed7 commented on this pull request. > <li> - <p>For each <a>slottable</a> <a for=tree>child</a> of <var>host</var>, <var>slottable</var>, in + <p>Otherwise, for each <a>slottable</a> <a for=tree>child</a> of <var>host</var>, <var>slottable</var>, in Hmm, I thought we were leaving these as-is. I.e. while that slot is located in a "named" mode shadow root, then "named" mode takes precedence. But nothing, other than re-assigning a node to another slot, removes anything from manually assigned nodes. I.e. `.assign()` is the only thing with the power to add/remove from manually assigned nodes. And no amount of node movement or slot movement can cause assignments to get cleared. I kind of feel like that's the easiest mental model for developers to have, rather than having to remember never to put a manually assigned slot into the wrong shadow root. It seems like a common pattern might be: ```javascript shadow.appendChild(slot); slot.assign([a,b,c]); shadow.slotAssignment = 'named'; ``` WDYT? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/whatwg/dom/pull/966#discussion_r612002939
Received on Monday, 12 April 2021 22:49:20 UTC