- From: Westbrook Johnson <notifications@github.com>
- Date: Fri, 25 Oct 2024 07:36:26 -0700
- To: w3ctag/design-reviews <design-reviews@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3ctag/design-reviews/issues/961/2437991692@github.com>
## As for DX In that the current DX for associating things accessibly is ID references: ```html <label for="input">Label</label> <input id="input"> ``` Isn't requiring a new syntax to associate things accessibly just because they are inside a shadow root _worse_ DX? ```html <label for="input">Label</label> <my-input> <template shadowrootmode="open"> <!-- because I'm in a shadow root, my ID is no longe enough 😢 --> <input id="input" defaultReferenceTarget> </template> </my-input> ``` As opposed to only needing to address the transport layer via: ```html <label for="input">Label</label> <my-input> <template shadowrootmode="open" shadowrootreferencetarget="target"> <!-- same DOM in or out of the shadows 🥳 --> <input id="input"> </template> </my-input> ``` For the work I've been a part of, the ability to factor components in and out of shadow roots without needing to change much, if any, of the DOM structure and attributes feels like a big win for maintainability of the work developers are doing here. ## Mixed attributes A further issue with the consumption of multiple DOM internal attributes is their unexpected collision. While I'm not sure the current answer to which wins here: ```html <template shadowrootmode="open" shadowrootreferencetarget="target" shadowrootreferencetargetmap="for: other"> <button id="target"></button> <button id="other"></button> </template> ``` Or here: ```html <template shadowrootmode="open" shadowrootreferencetargetmap="for: other" shadowrootreferencetarget="target" > <button id="target"></button> <button id="other"></button> </template> ``` IIUC the order doesn't matter because you set a default and then override specific values with the map. These values are all in the same place, parsing can happen in one place, groking can happen in one place, etc. However, traditionally attribute relations resolve first in DOM order, e.g. the label focuses input "one" when clicked: ```html <label for="input">Label</label> <input value="one" id="input" /> <input value="two" id="input" /> ``` So if you rely on attributes across the DOM, which wins? ```html <template shadowrootmode="open"> <button defaultReferenceTarget></button> <button referenceTargetForAttributes="for"></button> </template> ``` `defaultReferenceTarget` comes first, do we expect the parse to now scan the fully available structure to see if something supersedes it? If not would the relationships be different with: ```html <template shadowrootmode="open"> <button referenceTargetForAttributes="for"></button> <button defaultReferenceTarget></button> </template> ``` Needing to parse the whole tree to clarify the accessible relationship seems like it would change the default performance aspects of doing so. That would get worse as the shadow tree grew, and at the same time as the shadow tree grew it would be much more likely that these two attributes are far apart in that tree making it more difficult to keep (or to acquire) their relationship in your mind at dev time. This pushing of the accessible relationship transport layer could make it surprising and less clear what is happening when these relationships cross between DOM trees raising the likelihood of an accessibility feature lowering the accessibility of the features built with it. -- Reply to this email directly or view it on GitHub: https://github.com/w3ctag/design-reviews/issues/961#issuecomment-2437991692 You are receiving this because you are subscribed to this thread. Message ID: <w3ctag/design-reviews/issues/961/2437991692@github.com>
Received on Friday, 25 October 2024 14:36:30 UTC