- From: yuzhehan <notifications@github.com>
- Date: Tue, 10 Mar 2020 15:54:12 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/pull/866/review/372375462@github.com>
yuzhe-han commented on this pull request. > -[To find a slot] for a given slotable *slotable* and an optional open flag (unset unless stated otherwise), run these steps: + 1. Adopt node into parent’s node document. + + 2. If child is null, then append node to parent’s children. + + 3. Otherwise, insert node into parent’s children before child’s index. + + 4. [Update Step] If parent is a shadow host, its shadow's `slotAssignment` is not "manual" and node is a slotable, then assign a slot for node. + + 5. [New Step] If parent's root is a shadow root, shadow's `slotAssignment` is "manual", and parent is a slot, throw exception. bicknellr@, Yes, it's intended, but not sure if the spec wording is correct. Or if it needs to throw an exception vs no-op. To me, fallback content makes it confusing when working in slot assignment manual mode. Slot assignment should be absolute and final in manual mode. See comment from TPAC: https://github.com/whatwg/html/issues/3534#issuecomment-537802687 In that case, when developers call slot.assign([]), the slot should be cleared and have no content. But if we allow failback content, then content can still appear inside the slot even thou developer specifically want to clear it out. This is my reasoning for update the spec. Let me know if you think I'm overlooking something. thanks -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webcomponents/pull/866#discussion_r390657167
Received on Tuesday, 10 March 2020 22:54:25 UTC