spectrum-web-components

spectrum-web-components copied to clipboard

Code of conduct

• [X] I agree to follow this project's code of conduct.

Impacted component(s)

sp-top-nav-item

Expected behavior

<sp-top-nav-item> should be selected when the current URL matches its href and URL parameters are present.

Actual behavior

<sp-top-nav-item> isn’t selected when the current URL matches its href and URL parameters are present.

Screenshots

No response

What browsers are you seeing the problem in?

No response

How can we reproduce this issue?

Here is an example you could use to reproduce this: https://webcomponents.dev/edit/Oc72O4l9KswSNOTysGti

For an example in production, compare https://fonts.adobe.com/fonts (where “All fonts” is selected) with https://fonts.adobe.com/fonts?tag=holidays (where “All fonts” is not selected).

Sample code that illustrates the problem

No response

Logs taken while reproducing problem

No response

@bslaught thanks for the issue. I'm thinking through some questions here and wonder if you have any thoughts. Particularly, I'm thinking about how some instances of <sp-top-nav> could manage the "active" item via the consumption of URL params or URL hash; how would/should we allow users to determine what their active state is driven by?

• Should <sp-top-nav> accept no-hash or no-params attributes? Possibly ignore="hash | params | hash params", etc.
• Would this be better managed manually from above? This implied a no-auto-active style attribute or a breaking auto attribute that turns this capability on.
  • It's also possible that use of URL Params currently activates this mode implicitly in a way that could open a work around for you project, today.
  • Initial selection management might be overriding downward application of selection due to the default use of href in the manageItems method...
• Are there cases where this functionality should be managed on the item level, rather than across the entire navigation?

Sorry about the late response.

Something like no-hash or no-params makes sense to me.

I guess a similar case would be fragments, where I'm also able to reproduce the same issue. Apart from toggling by params and fragments, I can't think of any cases where a user would want to manage this manually, but I also wouldn't mind doing that if those cases exist.

I personally don't have a use case where this would need to be managed at the item level, but I could see how that would be possible.