diff --git a/README.md b/README.md index d5dccde..58e5f03 100644 --- a/README.md +++ b/README.md @@ -1,2 +1,164 @@ -# declarative-custom-elements -Explainer draft for specifying an approach to Declarative Custom Elements +In reference to https://github.com/WICG/aom/issues/192 + +```html + + + #shadow-root + + + + + #shadow-root + + +``` + +## Reflection: as a oposite of delegation +I'd much prefer that we work out a reflection process that was similar to the delegation API as it would make both +processes "declarative". In that way you _might_ see something like this horrid pseudo code: + +```html + + #shadow-root reflects="role aria-activedescendant" + + +``` + +## Roles: +Role feels a bit like it should be on individual elements with in a shadow root, but if those roles are relative to the containing +element or application how do you make them available there? Reflection above shows one path, but you might also say one elemnt +holds numerous "roles" and delegates them to its shadow DOM children. In that way you _might_ see something like this horrid pseudo code: + +```html + + + #shadow-root delegates="role" + + + +``` + +## IDL attributes: +Being able to set aria references in the JS space is nice, but it does inherently contain you to a single document tree, as noted +by the OP, or force you to surface element references as part of the API of your shadow root containing elements, which would be seen +as a leaky API. In maybe ways this is what work arounds do today. In SWC we assume out focuasable elements have a `focusElement` +property and when we need to reach into them to label them our `` element knows that that property might exist +and checks for it when deciding how best to label an element. In this case we'd need to do similar: + +```html + + + #shadow-root + + +``` + +In this was it would be great to pair IDL attributes with combinations of the delagate and reflect patterns that we've seen above. +With these in concert is will be possible for the developer of to manage internally the mapping of aria attribute +content across the DOM tree that it has ownership of without needing to leak references to its descendents into the parent tree. +With this being so, you might wonder what even is the benefit of IDL references at all. To understand this this it is important to +clarify the assumption that the demos above live in a single root DOM tree, hopefully something like `document`. If all these things +like in document then you'll always be able to make the ID ref not matter what you might do with the content in question. However, +if you are contained in any parent elements, and any of those elements apply some form of CSS clip/layering and others apply their +own shadow roots, then without the presence of something like https://open-ui.org/components/popup.research.explainer you might +find yourself throwing any overlaid contents to the end of the `document` to ensure that the entirety of that content is visible and +that it is above all other content. That is to say that while "open" the DOM might actual end up looking like: + +```html + + + #shadow-root + + #shadow-root + + + + + + + #shadow-root +
    + + #shadow-root +
  • List item
    • +     +
+ + +``` + +For the above code to work, you will have needed to make and applied an IDL reference before the content was reparented in order for +the accessibility tree to continue to be made approapriately. At this distance, interceeding shadow roots, the ID ref would not be +possible, and the imperative JS connection would be required. + +This does, however, raise the question of how one might make this relationship hold in a context where Declarative Shadow DOM was +leveraged for the delivery of the content. Being reparenting isn't possible without JS, it is possible that we may be able to +avoid addressing this context, but it is the sort of question that we should be sure to keep on our mind as we continue to expand +the feature surface of the browser in imparative ways. \ No newline at end of file