Proposal to rename rh-secondary-nav to rh-navigation-secondary

[zeroedin]

Recently there was a conversation about formalizing the section names of the footer component: site-specific-footer and universal-footer.

This brought up a conversation that was had offhand about how we speak about rh-navigation and rh-secondary-nav.

In terms of https://ux.redhat.com these are named navigation-primary and navigation-secondary however the tag name for rh-secondary-nav does not currently follow that standard.

https://ux.redhat.com/components/navigation-primary/
https://ux.redhat.com/components/navigation-secondary/

This also has an effect on how we generate links for the components demo page which does not currently match the component name on ux..

https://ux.redhat.com/components/secondary-nav/demo/ -vs- https://ux.redhat.com/components/navigation-secondary/demo/

The proposal would be to rename the rh-secondary-nav component to rh-navigation-secondary, then as we move forward and rebuild rh-navigation at some point these two would follow a similar naming convention.

Also, I wonder should rh-footer also follow such a convention: rh-{{tag-name}}-{{tag-sub-component}} So should rh-global-footer actually be rh-footer-global? Or vice versa should rh-navigation-secondary be rh-secondary-navigation to match the proposal from @heyMP in the screenshot above?

/cc @markcaron @coreyvickery @alypilkons-RH @bennypowers @heyMP

[bennypowers]

I'm for it. Our design and technical language should be aligned as much as possible to avoid confusion

With respect to navigation, I think any of these are acceptable, as long as they reflect the design language

<rh-navigation-primary>
<rh-navigation-secondary>

OR

<rh-nav-primary>
<rh-nav-secondary>

OR

<rh-navigation>
<rh-navigation-secondary>

OR 

<rh-nav>
<rh-nav-secondary>

We use a similar convention in our design tokens, moving left-to-right from the general to the specific., so color.blue.200 not blue.200.color and font-family.heading not heading.font-family

Regarding footer, we can always re-register they old tag name and log a deprecation warning in the constructor

@customElement('rh-global-footer')
class RhGlobalFooter extends RhFooterUniversal {
  constructor() {
    super();
    this.#logger.warn('rh-global-footer is deprecated. Use rh-footer-universal instead. https://red.ht/global-footer-deprec');
  }
}

[zeroedin]

Regarding footer, we can always re-register they old tag name and log a deprecation warning in the constructor

Oh I like that, didn't even occur to me to do that.

[heyMP]

The only thing we would have to be careful about is making sure the old tag name wasn't being used in our lightdom.css. But I do like that option.

[zeroedin]

Good call. Having to alias CSS rules as well is something to think about. Definitely done in rh-secondary-nav-lightdom.css

[zeroedin]

Did someone say CDN? I could have sworn i heard that somewhere 🙃

[bennypowers]

:is(rh-footer-universal, rh-global-footer) {
  ta: da;
}

[coreyvickery]

@bennypowers @zeroedin Was there a consensus reached about how names should change and where?

[zeroedin]

I don't believe one in writing, maybe in passing conversation.

<rh-navigation>
<rh-navigation-secondary>

This is my preference for the navigation components. That said the new sub nav sort of breaks this convention, <rh-subnav>. I think that might be ok as it's not quite like the other two and maybe doesn't need to be grouped logically with them as <rh-navigation-sub>.

@heyMP are you also planning to rename rh-global-footer to rh-footer-universal?

I'm ok to do secondary-nav whenever but I think the footer has a separate timeline or at least one that might involve a bit more navigating around it being implemented in more places.

[coreyvickery]

@zeroedin So there wouldn't be rh-navigation-primary, just rh-navigation?

I wonder if rh-sub-nav would become rh-navigation-tertiary one day.

[zeroedin]

I like it personally for its succinctness but doesn't mean I'm right either, just a preference.

I had thought rh-navigation-tertiary was ruled out but your guess is as good as mine.

[bennypowers]

I prefer tertiary to sub, but I think @dcaryll has reasons not to go that way

[markcaron]

Dan weighed in below. Here are my thoughts:

1. IMO, "tertiary" presumes the existence of a "secondary" type of navigation on the page. In the case of this sub navigation component, it wouldn't necessarily be used in that context, i.e. our docs. Our docs will have a main navigation (to the left) and then this sub navigation for any sub sections.
2. There's a succinctness to rh-sub-nav or rh-subnav which is more descriptive of its use case—for sub sections. Secondary Nav's use case was intended as a lockup with the Primary Nav for mini sites.
3. By calling it "sub nav" I feel it's more versatile.

If we went with rh-navigation-tertiary, then our current rh-secondary-nav does not aligning to the rh-navigation-secondary naming pattern proposed above either, so we'd have to rename it as well. I'm wondering if that alignment is something we can do down the road after some feedback from consumers?

My $0.02 anyway.

[dcaryll]

I’m okay with tertiary. I had just mentioned sometimes naming gets tough when you create a new pattern with higher priority or if someone is unsure if they can use a tertiary nav on its own.

On Tue, Jan 31, 2023 at 3:10 PM Benny Powers ***@***.***> wrote: I prefer tertiary to sub, but I think @dcaryll <https://github.com/dcaryll> has reasons not to go that way — Reply to this email directly, view it on GitHub <#695 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJRDU4R3UKAHF6QZZF53K3WVFWTDANCNFSM6AAAAAATV3VFCU> . You are receiving this because you were mentioned.Message ID: <RedHat-UX/red-hat-design-system/repo-discussions/695/comments/4833665@ github.com>

-- *Dan Caryll* Senior Manager, UX Design and Development Red Hat - NC 100 E Davie Street ***@***.*** M: 304-281-4098 <https://www.redhat.com/>