ActiveDescendentController

[bennypowers]

Description of the requested feature

The [RovingTabindexController]() helps component authors to implement the RTI pattern for compound elements like select menu / dropdown, tabs, accordion, etc. We have identified the need to implement the alternative active descendant pattern in the case of typeahead select.

In shadow DOM scenarios, this pattern will require some quite complicated workarounds to the cross-root aria problem.

Impacted component(s)

• pf-select with typeaheadmulti variant

Some previous work laid some conceptual foundations and guardrails. See for example https://github.com/patternfly/patternfly-elements/blob/75c54410a6a2ac033a2d81ba3cac1f5a64c3e6ec/elements/pf-select/pf-select.ts#L336-L344

It seems like the ActiveDescendentController will need to either copy the slotted options into the shadowroot, or require the input and buttons to be in the light dom.

At large, the ActiveDescendentController should be able to be used as a "drop-in" replacement for RTIC. I put "drop in" in quote marks, though, because clearly some additional work may be required.

Related issues

• 2145

• 2049

CC @adamjohnson for initial review of approach sketched here CC @Arathy-s as well, with thanks for taking an interest in this project

[adamjohnson]

Any controller that helps simplify developers' lives is going to be a win.

That said, I have a few questions / thoughts:

Feasibility and Complexity

1. Current Complexities of Cross-root ARIA:

• Given the intricate nature of cross-root ARIA, do you think implementing this controller is premature? We need to evaluate if the benefits outweigh the complexities at this stage (ala "lift and shift" and lightdom implementations).

2. Future Maintenance and Business Priorities:

• When cross-root ARIA matures, will this implementation need significant rework? If yes, we should consider if this aligns with our long-term business priorities.
  • Could we potentially use the development time more effectively on building other components?

Developer Demand and Alternatives

3. Demand and Use Cases:

• Is there substantial demand from developers for this controller? Do we adequately understand their needs and pain points?
• Are there common scenarios where the native <datalist> element could suffice? If the majority of use cases can be addressed by native elements, the need for this custom controller might be reduced.
  • If this is the case, perhaps we make a dedicated <datalist> component or pattern.

Looking forward to everyone's input. 👍

[bennypowers]

premature? ... "lift and shift"

It's not ideal, no, but there is precedent in other design systems.

When cross-root ARIA matures, will this implementation need significant rework?

Yes, but... if we do this right, then we will not have to change any public apis at that point.

Could we potentially use the development time more effectively on building other components?

The back log is long, true, but...

Is there substantial demand from developers for this controller? Do we adequately understand their needs and pain points?

Yes, combobox is one of my most commonly requested features, and I just don't think we can do it without active descendent

native <datalist> element could suffice?

Interesting suggestion, how might that work? Would we still be able to implement reference targets as a solution to x-root aria once it lands, without having to change public apis? What about styling, could we include rich content (like items with description, icons, etc) in list items?

---

• Stage 0 (now): we can't do combobox b/c of cross-root aria
• Stage 1: We implement an ActiveDescendentController which works by copying nodes into the shadow root
• Stage 2 (after reference target lands): we refactor the internal guts of ActiveDescendentController to no longer copy nodes, but use reference targets instead

[adamjohnson]

Yes, combobox is one of my most commonly requested features, and I just don't think we can do it without active descendent

Good to know. 👍

native <datalist> element could suffice? ... Would we still be able to...

AFAICT, we still can't add additional HTML inside an <option> (icons, descriptions), so using <datalist> sounds like it's not going to work in this instance.

Your Stage 0-2 roadmap sounds like the way forward.