Underline nav: Should it have default paddings around?

[maximedegreve]

Problem

While prototyping a few layouts I've noticed a consistent problem with our Underline Nav React implementation

ActionMenu positioning

When there is a more menu it often goes off screen. This might be fixed by.

Truncation

Items are being truncated too early.

Padding

There is a missing prop to remove the extra padding on the left of this component as it would provide better alignment with the content below when not used in the navigation.

Reproduce

• Go internally to our Primer Recipes marketplace example.
• Scroll to the middle of the page and click more

[joshblack]

Thanks for making this issue @maximedegreve!

Just wanted to leave a note that I believe the "ActionMenu positioning" section has a corresponding issue over at: https://github.com/primer/react/issues/4059

[siddharthkp]

@broccolinisoup 👋 Assigning to you and me (FR) to do the initial triage.

[siddharthkp]

There is a missing prop to remove the extra padding on the left of this component as it would provide better alignment with the content below when not used in the navigation.

Ideally, there shouldn't be any padding around the component by default? It should be left to the user to align 🤔

[siddharthkp]

@broccolinisoup, this is the winning combination for consistently reproducing early truncation:

const children = ['Trending this week', 'Recently added']

https://github.com/primer/react/assets/1863771/14d46250-7197-4a72-800d-75b6f9b88fba

[broccolinisoup]

Hi folks 👋 @maximedegreve @siddharthkp

Regarding the early truncation, it was an accessibility improvement that we made sure there is at least two elements in the overflow menu if we are going to display a menu - see the PR that we introduced this behaviour https://github.com/primer/react/pull/2471 We can maybe look into other variants like condense or something we can squeeze the items to fit both into the narrow viewport. Just throwing ideas.

Regarding the padding, it was on the design specs. We can remove it if it is not valid anymore or not needed in general.

[siddharthkp]

Regarding the early truncation, it was an accessibility improvement that we made sure there is at least two elements in the overflow menu if we are going to display a menu - see the PR that we introduced this behaviour https://github.com/primer/react/pull/2471

That's very interesting, thanks!

[siddharthkp]

Armağan: Regarding the padding, it was on the design specs. We can remove it if it is not valid anymore or not needed in general.

Maxime: There is a missing prop to remove the extra padding on the left of this component as it would provide better alignment with the content below when not used in the navigation.

I think it's always a risk when we bake in some padding around the edges of the component. I don't think we should add a prop to remove noPadding. the sx prop (or a className) should be used instead.

I'd leave it up to you and Maxime to decide if we should remove it from the default. (If we decide to remove it, we should add it back to the instances where it's already used)

[broccolinisoup]

I think it's always a risk when we bake in some padding around the edges of the component. I don't think we should add a prop to remove noPadding. the sx prop (or a className) should be used instead.

I'd leave it up to you and Maxime to decide if we should remove it from the default. (If we decide to remove it, we should add it back to the instances where it's already used)

Sounds like a good plan - @maximedegreve let me know how you want to go forward with that 🙌

[maximedegreve]

My understanding is that for the UnderlineNav, most of the time you wouldn't want padding when it's added in the content area. The only exception I'm aware of right now is the UnderlineNav in the navigation, but that's something that's rarely changed.

I'm not up to speed with previous React decisions, but I thought that the sx prop is discouraged where possible.

I think this conversation goes hand in hand with the work @mperrotti is doing on our tabs. For example, in security, we use a different style of tabs that doesn't have this padding.

[broccolinisoup]

I did a quick lookup on the current use cases of UnderlineNav to see how many of the cases reset the padding and there are only few of them. https://musical-adventure-wlr3n3k.pages.github.io/?name=%22UnderlineNav%22&attribute=sx That doesn't mean that they should retain their padding but I just thought it might be a good place to reference before making that final decision. @maximedegreve

[broccolinisoup]

I am taking this to work in progress and remove from the inbox since we are having the conversation 🙌

[broccolinisoup]

I updated the title to reflect the paddings discussions we are having since the originally reported issue is an accessibility criteria. @maximedegreve let me know if there is anything I can do on this issue.

[siddharthkp]

:wave: @maximedegreve and @broccolinisoup did we decide on removing or keeping padding by default?

[maximedegreve]

@siddharthkp No decision but I would keep the existing behaviour for ease but incorporate a prop that allows overriding it instead of using sx.