You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some custom elements use tools like html`` template tag functions, or JSX, or etc, internally to make declarative modification to their internal shadow DOM.
But when it comes to modifying things on the host element, the element has to contain code like
if (this.authenticating) this.classList.add('authenticating')
else this.classList.remove('authenticating')
(ignore that this modifies the external state, and that the :--state feature will be better for this)
It might be convenient if instead the element implementation could achieve this declaratively, within the same markup that it already has.
So, similar to how CSS has a :host selector to target the host from the ShadowRoot, the DOM could have a <host> element to manipulate a ShadowRoot's host from markup.
With this feature, the custom element implementation could remove the above imperative code, and write something like the following (assume some JSX implementation takes care of the reactive updates):
@reactiveauthenticating=falseconstructor(){super()this.attachShadow({mode: 'open'}).append(<hostclass={this.authenticating ? "authenticating" : ""}><div>This content was already defined before.</div></host>)// later something changes the value of this.authenticating}
The <host> element would mirror any attributes to this instance's attributes. I'm not sure about attributeChangedCallback. Maybe it is skipped for such updates?
The <host> renders as if with a permanent display: contents CSS property, and it must be a direct child of the ShadowRoot (or else it does nothing, or perhaps an error is thrown), and there can be only one (or else it uses the first one, or perhaps an error is thrown).
I'm not sure if it is worth it. I thought I'd jot this idea down when it occurred to me.
The text was updated successfully, but these errors were encountered:
Maybe the :--state feature will satisfy the use cases. Plus in the case where I thought I could benefit from this, I was setting a class on the host element just so that I could style it with :host in the CSS.
But in hind-site, I can achieve the same thing with an internal <div> in the ShadowRoot, and I can even set the :host style to display: contents to render the ShadowRoot's content in place of the host, without affecting the public interface. I can even assign that div as part="root" to give users styling access.
I'll just close this, as the alternative to the situation I had is better because it keeps the outside clean (and :--state will be nice for the purpose of the outside user styling the host).
Some custom elements use tools like
html``
template tag functions, or JSX, or etc, internally to make declarative modification to their internal shadow DOM.But when it comes to modifying things on the host element, the element has to contain code like
(ignore that this modifies the external state, and that the
:--state
feature will be better for this)It might be convenient if instead the element implementation could achieve this declaratively, within the same markup that it already has.
So, similar to how CSS has a
:host
selector to target the host from the ShadowRoot, the DOM could have a<host>
element to manipulate a ShadowRoot's host from markup.With this feature, the custom element implementation could remove the above imperative code, and write something like the following (assume some JSX implementation takes care of the reactive updates):
The
<host>
element would mirror any attributes tothis
instance's attributes. I'm not sure aboutattributeChangedCallback
. Maybe it is skipped for such updates?The
<host>
renders as if with a permanentdisplay: contents
CSS property, and it must be a direct child of the ShadowRoot (or else it does nothing, or perhaps an error is thrown), and there can be only one (or else it uses the first one, or perhaps an error is thrown).I'm not sure if it is worth it. I thought I'd jot this idea down when it occurred to me.
The text was updated successfully, but these errors were encountered: