-
Notifications
You must be signed in to change notification settings - Fork 6
2024 Reference Targets for Cross Shadow Root IDREF associations
- GitHub issue: https://github.com/Igalia/webengineshackfest/issues/38
- Slides: https://notes.igalia.com/p/QGPBcdgGn#/
Alice: Discussion topics?
Keith: I'd like to say Web Component community groups has made this a top priority feature which they would like to have.
Luke: How feasible is it for this to fix the referencing out problem? Shadow roots for target... If a label is ALSO within a shadowroot, we need to reference in and out.
Alice: that was scoped out ot make the problem tractable. We can do it in a non-serializable way. We can't do it in a serializable way.
Dan: we are deliberately scoped to a few problems.
Luke: Implicit association should really work, the browser should be able to handle a label wrapping a shadow dom input.
Alice: I agree that this should work, but there is no attribute by definition... but we could say the there is an implicit for...? Is that how we want it to work? If we don't do that, how do you explain the reference target working when you can't do it for a specific attribute? Are there other types of implicit associates that we should write more spec text for?
To explain more -- when you are an actual attribute like aria-labelledby. if you have something that is "map all attributes", map every attribute that maps to my host.
Anne: it has to be about relationships.. if you assign the host to an element reflecting APIs that would also work.
If you do element.aria-describedby = shadowHost.
Nolan: to me, this is nice to have. as a component author, I don't have to add another idref. This isn't a question of the ARIA relatioship between the two elements. More like a parent child elements. More about other parent/child relationships like listbox/option. There is no ARIA attribute to declare that this listbox option is a child of this listbox container. We run into this with shadowdom, we only have display:contents which is gnarly. What about considering label input as related to that problem.
Anne: From my perspective, that is not quite the right idea. The way the for attribute looks, you click on the label and see what is that for attribute for. ... We have to find all these points that try to find an element for ID. With the for/label case, it's slightly different than parent child, because its explicit but there is a fallback. The is one problem, if the label element contains a shadow host and an input element -- what happens if it goes to the shadow? That is like exposing the shadow host to some extent. But you are opting in, so maybe that is ok.
Luke: Web developers are already use to auto values for attributes. Lots of time the missing attribute is "auto", there is no explicity value for "for", but I think its not hard for a web dev to think that the "auto" behavior will be to look for the first input. I think a dev would understand. I don't know in terms of other elements.... like the output element, which also has a "for" attribute.
Alice: We are ruling out any other implicit relationship.
anne: Form association... typically there are hairy html parser interactions... but the simple model is do you have an ancestor form element. That can be overwritten by an explicit form element. If you have a custom implementation of the form element maybe... we need ot think about whether form attribute has to be patched.
Alice: In the label, if it is implicity, it is going into a shadow dom descendant. For form its going out.
Anne: I don't know if the type of relationship matters for if we want to go into the shadow host or not. Conceptual, you could re implement a form element (not currently possible).
Alice: I'm think of a custom input in a regular form, without having to forward everything from element internals. Different from label for case, it's going in the direction the reference goes.
Anne: you can imagine the form id pointing to a custom form in the shadow dom.
Luke: (tries to explain)
Anne: (also tries to explain the same thing again -- Something about clicking on the form element --> finding form, and clicking label --> finding input)
Alice's example (requires new feature):
<form>
<custom-input>
#shadowRoot referencetarget=my-input
| <input id="my-input"> <!-- associated with <form> -->
</custom-input>
</form>Anne's example (works with this feature):
<custom-form id=custom>
#shadow referenceTarget=form
<form id=form>
<slot></slot>
</form>
<input id=one>
</custom-form>
<input id=two form=custom>Anne: this an example where you have an implicit relation. The input implicity finds the form hidden in a shadow.
Luke: if none of this was in the shadow dom... (something about sibling forms seems less relevant)
Anne: if label doesn't have a form element, go through children.
Alice: that direction makes sense to me. The reference is going into the shadow root. My example is the reference going out of the shadow root, that seems like the more comment case. custom input associated with a form.
Anne: I'm not sure how it ends up working with what we have. a seperate feature?
Alice: right. So we can justify label, but we can't justify form. In your example, the attribute is going in the correct direction, that is a less common case.
Anne: In that case, you just don't find the thing you are looking for
Alice: I think the developer need is strong for my case
anne: if we are adding this feature, we should make my case work
Alice: agreed
Anne: the other case requires a seperate feature
Alice: any other discussion topics? Dan, what work is left to do, what do you need?
Dan: We have a PR to land (reference from the explainer). Ben is prototyping in blink, it's nearing it's end. We are going to try to get in the hands of developers. That is next thing. We have sent out request for positions. That is it, no big open issues. Planning to ship in stages, phase 1 out the door, more issues to shake out in phase 2. Want other implementors.
Luke: idl attributes is out of scope. How does it play into existing behavoir of reflection. active-descendent element = host (scribe does not understand question)
Alice: doesn't work with those apis
Dan: (repeats question but I missed it) answer: Everything goes to the host.
Kieth: implicit invoker targets. if you had an unambigious invoke action, you could imit the target, similar case to label and forms.
Luke: related to popover. If you have a close action invoker in a dialog, that is an unabigious action, so it would close it. If you have invoker close in a shadow root that needs to reach out for the dialog? Trying to serialize the reference out with making the impicit assoication works. There are many implicit relationships.
Alice: Question for Anne, if we think ahead to the next feature, if the next feature was a version of this that allowed references in the other direction. What if we solved implicit references going out, or the sibling case if you have sibling shadow roots.
Luke: the only hesitation would be thinking about the name "reference target" is ambigious out the direction. The other feature needs a seperate attribute.
Alice: that is why we had reflection/delegation. What would that look like?
Luke: maybe we need to think now about what the naming now, because the current name is ambigious
Keith: maybe it would look more like paths... (I didn't catch???)
Annne: would be go to go for some of hte usecase. In the form case, it would be annoying to explicit name the form element, also do you want that to be the implicit target for everything in your shadow tree.
Luke: if you have a button in one shadow root and popover in another, if the button links to the popover. Reference target goes down, but not back out.
Alice: if there was no attribute that existed, would we want to do this?
Luke: just make an attribute. If there is a relationship just make a new attribute
Anne: then you impact all existing relationships.
Luke: what example are you talking about
Anne: the option example?
Luke: the input/form example is the same as popover. Implicit parent child, like options in an select, maybe input form is a bad example because it works both ways (implicit and explicit).
Nolan: you can refer to siblings or cousins using this proposal...
alice: there is another chunk of work to be done at some point in the future. The proposal will work up a lot of usecases. In terms of the next thing -- we have been doing this the AOM meetings -- but we have sort of stopped going to those AOMS. What about a forenightly meeting to discuss this? Luke raised his hands. Even trying to publize this meeting -- we need a channel!!! We have been emailing everyone on the AOM calendar invite.
Suggestion: w3c SLACK. w3cg discord. or whatwg matrix?
Decision: whatwg matrix (which is actually matrix.org)