- From: [ Cassondra ] <notifications@github.com>
- Date: Wed, 05 Aug 2020 05:43:45 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/889/669170918@github.com>
> The following may be much better (if the selector were supported) for a use case in which the functionality works as intended: > connectedCallback() { > const el = this.shadowRoot.querySelector('::slotted(.foo) .bar + .baz') > > requestAnimationFrame(function loop(t) { > // does not re-run the selector every time: > el.style.transform = `rotateY(${10 * Math.sin(t * 0.001)}deg)` > requestAnimationFrame(loop) > }) > } I'm just not sure that referencing slotted content inside the ShadowRoot is possible or makes logical sense if we consider the main benefit of web components: scope. The ShadowRoot does not know what it's slotted content looks like, only that it has slots. The slots point to the light DOM. If you want to capture the light DOM on a component, you use: `this.querySelector(".foo")`. If you want to make sure `.foo` is assigned to a slot, you query for: `this.querySelector("[slot].foo")` or even `this.querySelector("[slot=bar].foo")` if you want to make sure it's in a specific slot. There is no need for the `::slotted` selector inside the querySelector. `::slotted` in CSS was a means for the component to be able to influence the light DOM styles directly nested inside the slot (and only directly, top-level items) and it does it very weakly. Most light DOM styles will overwrite anything the component tries to apply to a `::slotted` style unless that component uses `!important` to beat it. tldr; Scope is the primary discussion here imo. A component is tightly scoped to see it's own template and it's top-level nodes assigned to a slot, no deeper and no higher. That scope is a powerful tool that can be leveraged. -- 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/issues/889#issuecomment-669170918
Received on Wednesday, 5 August 2020 12:43:58 UTC