Westbrook Johnson

While this can effect _all_ events, for sure, for initial render bound events (like `context-request`) would it be useful to submit an addition to [the Context Protocol](https://github.com/webcomponents-cg/community-protocols/blob/main/proposals/context.md) that included the...

Not squatting is a good call! I'm just looking to make sure this (and any of the other learnings this implementation has had) get brought back to the protocol. 🙏🏼

Can you catch up to main so we don't have there merge conflicts?

Does this align with https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md wherein an element author has more finite control over the elements receiving the aria values?

@aleventhal how do you see this intersecting with the planned work around https://github.com/WICG/webcomponents/blob/gh-pages/proposals/reference-target-explainer.md We're getting close to a testable implementation via https://chromium-review.googlesource.com/c/chromium/src/+/5615615 and https://chromium-review.googlesource.com/c/chromium/src/+/5739315 thanks to @behowell and @dandclark

In that case, I'm pretty sure that I'm misunderstanding your use case. Would you be able to share a more concrete example?

In that case, is it better for the author for the browser to ignore the combination of `role="none" aria-label="..."` on the assumption that they pass the value down for themselves...

In that `aria-label` and `aria-description`, et al. are not reference attributes, they won't be applied via Reference Target in the currently discussed form. If `role="none"`, I don't see much harm...

I’m all for moving to 100% esm, but I’m not envious of anyone willing to take on that work.

Related, the use of built and bundled files in the published versions of Shoelace (e.g. `chunk.KLASTODS.js` et al) make even knowing that unused code has been included in the build...