- From: Lea Verou <notifications@github.com>
- Date: Fri, 25 Oct 2024 09:57:46 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/961/2438338881@github.com>
@Westbrook As a meta comment, I think we may have run into the classic big WC use case bifurcation, where some folks are talking about templating use cases and others about packaging up independent bits of functionality for broader reuse, and these use cases have _vastly_ different characteristics so people are coming to these discussions with completely different contexts. For example, wth most of my context being the latter, moving elements in and out of shadow roots is something I have never considered, since most components I work on are used more broadly than the pages that include them, and are managed by different people. That different context might also explain this question: > Isn't requiring a new syntax to associate things accessibly just because they are inside a shadow root worse DX? I could be wrong, but reading between the lines, it seems like to you this is mainly about overcoming a hurdle in how you define your ARIA attributes; since it's the same person/team writing the mappings for the light DOM _and_ the component, the encapsulation is just a roadblock, they'd rather reference the shadow DOM element directly if they could. If that is correct, perhaps the real solution these use cases need is a general way to reduce encapsulation. For the second set of use cases though, this is defining a way for the root element to specify which of its shadow DOM descendants certain things should be delegated to, and is largely independent of how exactly the mapping happened in the first place. E.g. if in the future we add an attribute that relates one element to another via a relative selector, the delegation should still work the same. So to me, it seems entirely separate than the idref mechanisms currently used, the actual design goal is to design a good syntax for **delegation**. It doesn't help illustrate what @plinss and I are saying that in your code examples, elements already have ids, so it begs the question, why not just use the ids? However, what Peter and I were saying, is that ideally, you shouldn't _need_ to assign ids if you don't need to for another purpose. But regardless of the syntax we go with, I would fully expect more specific mappings to override more general mappings, rather than just resolving them based on order. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2438338881 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/961/2438338881@github.com>
Received on Friday, 25 October 2024 16:57:50 UTC