Thanks for giving this a shot. This is an interesting solution. After discussions with the team I think we'd want to evaluate other, more direct options.

Some options we discussed, some of which could be worth further exploration, others certainly not:

• always apply a/area behavior for all elements (obviously doesn't work because some need to be made focusable)
• add a DI token to configure for element types
• always apply a/area behavior for custom elements only
• always apply a/area behavior for custom elements with 'href' properties
• add an input(s) or marker attribute(s) to the directive that explicitly enables the a/area and/or behavior

Unfortunately, we don't have the capacity right now to take time determining the best path forward.

Hello @atscott
That is very disappointing, as this is a problem right now, as described in #28345.
This will also probably get worse with the upcoming Reference Target proposal, which is being worked on right now.

We are more than willing to put in the effort, if you give us a direction.

always apply a/area behavior for all elements (obviously doesn't work because some need to be made focusable)

add a DI token to configure for element types
How does this differ from our current proposal?

always apply a/area behavior for custom elements only
That seems to be risky, as there is no guarantee for this to properly work.

always apply a/area behavior for custom elements with 'href' properties
That seems reasonable and not that far off from our proposal. Although there is a possibility that this might conflict with custom element upgrade timing.

add an input(s) or marker attribute(s) to the directive that explicitly enables the a/area and/or behavior
That seems questionable from a developer experience perspective? Or what do you have in mind?

Does this in any way relate to what was said by @mgechev here? https://www.youtube.com/watch?v=CMZHUPSmZx4&t=624s

add a DI token to configure for element types

How does this differ from our current proposal?

Noted because we aren't entirely throwing this option out as a possibility.

always apply a/area behavior for custom elements with 'href' properties

That seems reasonable and not that far off from our proposal. Although there is a possibility that this might conflict with custom element upgrade timing

Would you be able to do some testing here? IIUC, the observedAttributes are available even before upgrade is called.

I will create a few test cases. 👍
Just to clarify; The approach would be something like 'href' in el.nativeElement or what did you have in mind?

The approach would be something like 'href' in el.nativeElement or what did you have in mind?

Looking for the element in the registry and reading its observed attributes would be more effective, right?

Yes, although that might need to be revisited when Scoped Custom Element Registries lands. Although from my understanding it would just be an additional call to get the declaration (e.g. customElements.get(...) ?? el.nativeElement.customElements?.get(...).

@atscott I have created #60290

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}