Admin bar length or Admin bar on two line

[korobochkin]

On some sites I see the bad admin bar.

And this without any external plugins stuff (Jetpack Statistic for example), except that buddy press notification counter.

The possible solutions, if screen too small:

1. Leave only icons (like on mobile screens).
2. Crop user name:
   • Hello, Kolya Korobochkin [avatar]
   • Hello, Kolya [avatar]
   • Hello [avatar]
   • [avatar]
3. Admin bar on two lines (maybe hard to do, because #wpadminbar have static height and position: fixed).
4. Add horizontal scroll without visible scrollbar (scrolling with mouse press and pull).

All options required JS and I'm sorry.

[morganestes]

Thanks for the ticket @korobochkin. Have you found that this happens at a consistent width with all plugins disabled, or does it depend on plugins that add menu items of different lengths?

[afercia]

There's no need for additional menu items to reproduce this, some languages have longer strings than the English ones, not to mention users may choose to display their (potentially very long) full name so there's just not enough space before the responsive media query kicks in.

Probably there's not a complete solution to this but maybe setting a max-width and using text-overflow: ellipsis; on the username link could help?
Not sure when this was introduced, setting version to 4.3.

[terminalpixel]

Patch to use flexbox within the admin bar

[terminalpixel]

I've created a fix for this that uses flexbox.

It is far from ideal but I think it is less buggy than the current issue. I cannot see a simple way to get a better result without either using JavaScript or reworking the admin bar html.

It should probably be tested with older browsers and plugins that make use of the admin bar.

[KZeni]

Also see #44438 as this other ticket with its own patch (and accompanying plugin to implement the fixed behavior in the meantime without needing a core file edit via ​https://wordpress.org/plugins/admin-bar-wrap-fix/) was created before noticing this ticket was already out there. The plugin made back in 2018 (still maintained) does fix things in the meantime for those that need it, but I do still think this should really be officially fixed so that a plugin like that is no longer needed (plugin as a patch a-la the plugin as a feature approach [can be phased out once WP itself officially adopts it], I guess.)

As @sabernhardt mentioned in the other ticket:

I think we'll want to take parts from each patch.

[sabernhardt]

#44438 was marked as a duplicate.

[KZeni]

While #44438 has been closed as being considered a duplicate & this being the ticket that preceded it. It did have a different means of addressing the issue (it uses flexbox still, but has some differentiation on other details.)

You can see the diff of the newer patch from the other ticket as a pull request (still open) on GitHub at ​https://github.com/WordPress/wordpress-develop/pull/352. Also, ​https://wordpress.org/plugins/admin-bar-wrap-fix/ effectively has that code as a standalone plugin for additional testing/development without editing the WP core.

Either way, one of the two (or a mixture of both) should be implemented to avoid this issue that's been part of WordPress for too long now.

[KZeni]

What's the best approach to decide the best code to move forward with for the final implementation?

Do we simply go with the newer patch (​https://github.com/WordPress/wordpress-develop/pull/352)? I mean, it's fully addressing things with how it is now that then doesn't need any further modifications, really. At that point, it's been more thoroughly tested in comparison per it being available as a plugin for years now (which people have submitted updates to as items were found) as well as being more recent so it's less likely to have out-of-date styling/approaches coming into play. That'd also make the implementation a bit more straightforward.

Also, should I close ​https://github.com/WordPress/wordpress-develop/pull/352/ in favor of re-creating a pull request under this ticket?

Open to thoughts for those more familiar/involved with the WordPress core & patch approval process than myself here.

[KZeni]

Updated implementation that was downloaded as a diff from ​https://github.com/WordPress/wordpress-develop/pull/352/

Trac ticket: https://core.trac.wordpress.org/ticket/28983 (has been open for some time without being really followed up on so hopefully this PR breathes some life back into this.)

The Trac ticket has a bunch of additional details regarding the issue being resolved here, screenshots, etc.

Code here is from version 1.0.3 of ​https://wordpress.org/plugins/admin-bar-wrap-fix/ (June 22, 2020; more recent releases haven't actually changed the CSS involved here) per that plugin ideally not being necessary to prevent issues that this resolves (with WordPress just preventing it from the start.) Somewhat of a "patch plugin" equivalent to a "feature plugin" WordPress has for forthcoming features, and it might be good to include it in the WP core at some point (if not now).

I have closed ​https://github.com/WordPress/wordpress-develop/pull/352/ per the ticket associated with that (https://core.trac.wordpress.org/ticket/44438) being seen as a duplicate of an older ticket (https://core.trac.wordpress.org/ticket/28983; what's referenced above), and so this is just migrating the PR over to the active trac ticket.

[KZeni]

Updated implementation that was downloaded as a diff from ​https://github.com/WordPress/wordpress-develop/pull/1082/ (migrated the change into a new PR that's now associated with this ticket)

[KZeni]

Okay, should be all set with the new diff and new PR on GitHub with the latest code all under this one active trac ticket (myself having been added as the owner as well).

It seems the next step is getting this pushed to a core code maintainer's/reviewer's hands so it can be officially implemented so stuff like ​https://wordpress.org/plugins/admin-bar-wrap-fix/ being used to prevent a problematic admin bar can be phased out.

@sabernhardt Can you assist with that in any way?

[sabernhardt]

Sorry I haven't looked closely at the patch yet to see whether it already meets this, but I should share my ideas for the direction of the ticket sooner rather than later.

For a core change, I think I'd prefer:

• preventing the links from dropping to the next line when there is no plugin-added content
• trying to accommodate an additional 2 or 3 small links well
• requiring a plugin to fix any problem caused by multiple and/or large plugin links

[KZeni]

@sabernhardt I guess I'm a bit lost when it comes to what "links" are being referred to in that bulleted list.

You can see in ​https://github.com/WordPress/wordpress-develop/pull/1082/files (and the most recent .diff file attached to the ticket; though the GitHub PR has some additional dev notes) that it's really just adding 2 code blocks to the src/wp-includes/css/admin-bar.css file that makes the admin bar take advantage of flexbox and ellipses-based text-overflow when applicable so the admin bar doesn't allow items to wrap onto a new line outside of the admin bar, if/when that happens due to any number of plugins potentially adding items to the admin bar (at that point, WordPress should be flexible in not having the admin bar break its layout at that point since it allows plugins to add items to the admin bar).

This update then doesn't rely on or otherwise involve any plugin and shouldn't conflict with any plugins that I'm aware of that any update to the admin bar's styling might have (while addressing an active issue due to the inflexibility of the admin bar as it is now [while being perfectly seamless for those not affected by this issue] & being straightforward enough that plugins that are changing the admin bar's styling should be able to accommodate reasonably quickly & easily in an update.)

I'm attaching some screenshots of the admin & frontend, with a fake plugin that adds 3 menu items. I also changed my user's display name & site title to be longer, so you can see on the frontend, that even without any extra menu items the menu wraps. These screenshots were taken on Mac/Firefox at 783px wide, which is the narrowest before the menu drops to icons-only.

I think the ​100px sizing introduced here is a bit too small for items to be clearly understood, so I also tried testing with only the code in the @media screen and (min-width: 782px) { … } media query.

| | Current (trunk) | With PR applied | With only media query |

|

| WP Dashboard (no plugins) | <img width="804" alt="before-be-no-plugin" src="​https://user-images.githubusercontent.com/541093/112508060-97078d80-8d65-11eb-95ee-4cc254864150.png"> | <img width="822" alt="pr-be-no-plugin" src="​https://user-images.githubusercontent.com/541093/112508042-94a53380-8d65-11eb-87c9-16bb0c90e2d8.png"> | <img width="807" alt="tweaked-be-no-plugin" src="​https://user-images.githubusercontent.com/541093/112508028-91aa4300-8d65-11eb-8513-970b8418f51c.png"> |
| WP Dashboard (with plugin-added items) | <img width="811" alt="before-be-plugin" src="​https://user-images.githubusercontent.com/541093/112508059-97078d80-8d65-11eb-8c22-0fb28197fc88.png"> | <img width="809" alt="pr-be-plugin" src="​https://user-images.githubusercontent.com/541093/112508039-940c9d00-8d65-11eb-8314-3356803097de.png"> | <img width="808" alt="tweaked-be-plugin" src="​https://user-images.githubusercontent.com/541093/112508027-91aa4300-8d65-11eb-8ef8-470504e3cc88.png"> |
| Frontend | <img width="816" alt="before-fe" src="​https://user-images.githubusercontent.com/541093/112508051-95d66080-8d65-11eb-9ae7-c3489cfd5b97.png"> | <img width="809" alt="pr-fe" src="​https://user-images.githubusercontent.com/541093/112508035-940c9d00-8d65-11eb-88e1-b12e560e468f.png"> | <img width="807" alt="tweaked-fe" src="​https://user-images.githubusercontent.com/541093/112508023-9111ac80-8d65-11eb-8f90-52a29f906b96.png"> |

[ryelle]

I've attached some screenshots on github (since it's easier to organize them there) - they don't embed nicely here, but ​you can click through here.

I'm also tagging this for design feedback - I think this is a good start, but could use some more thought about which items truncate, when should they truncate, etc.

That's some really nice testing there, thanks! Do you happen to have that fake plugin available for download so I can give it a shot? I can see that being helpful. 🙂

I can definitely see excluding the 2 other code blocks that aren't the primary @media screen and (min-width: 782px) { block.

Those 2 additions were from a user of the plugin having said they had used that made things nicer for them (as noted with the inline comments for the previous commit). However, I can see that there are negatives to what they've implemented in common situations & probably isn't the best option for everyone. Honestly, that code update might've been something subjective that was just a refinement (didn't address an active _issue_ or anything serious like that) for their specific site so I'm going to consider updating the PR (and my plugin-as-a-patch plugin) to exclude that.

At that point, if we just go with the code from the @media screen and (min-width: 782px) { block, does that actually just take care of it? Does anyone see it needing any adjustments after that point, or is it just a matter of testing at various sizes & with a varying number of items in the admin bar and acting accordingly (moving forward with official adoption if no issues remain)?

[KZeni]

Thanks again, @ryelle. I'll converse on ​the GitHub PR considering it appears this is syncing the conversation from there reasonably well (outside of the images/layout, possible edits then not getting synced, and a few other things where GitHub is the ideal reference.)

Alright, I've updated the PR since it really seems those other 2 code blocks were more problematic than they were helpful.

[KZeni]

Updated implementation that was downloaded from ​https://github.com/WordPress/wordpress-develop/pull/1082.diff (Removed styles that were more problematic than helpful after more thorough testing.)

Do you happen to have that fake plugin available for download so I can give it a shot?

Sure - it's just something I put together to test this, ​but you can find it here.

At that point, if we just go with the code from the @media screen and (min-width: 782px) { block, does that actually just take care of it?

I also noticed a few alignment issues: the "1" here is right at the edge, and the w in New is cut off. Also, the dropdown menu is much more narrow - it looks like it matches the width of the parent item, so I'm not sure what it would do with a long submenu item.

<img width="268" alt="Screen Shot 2021-03-25 at 12 16 54 PM" src="​https://user-images.githubusercontent.com/541093/112524734-8ad7fc00-8d76-11eb-9338-379f797f47b5.png">

That said, I'd like the design team to chime in too, in case they have some other specific suggestions.

[lukecarbis]

#38968 was marked as a duplicate.

[audrasjb]

#53166 was marked as a duplicate.

I am adding in the three images that @ryelle Kelly included above in relation to changes made by the PR.
This is so that we can get a quick overview of what the PR does.

PR applied no plugins included:
<img width="822" alt="PR-applied-1" src="​https://user-images.githubusercontent.com/5323259/117843898-86f92e00-b27f-11eb-805b-033c682f69cf.png">

PR applied plugins included:
<img width="809" alt="PR-applied-includes-plugins" src="​https://user-images.githubusercontent.com/5323259/117843985-9a0bfe00-b27f-11eb-9a97-54dc735b8c30.png">

PR applied frontend:
<img width="809" alt="PR-applied-Frontend" src="​https://user-images.githubusercontent.com/5323259/117844111-b6a83600-b27f-11eb-90a5-ab5ddb608d9a.png">

Adding a truncation seems like the way to go.

@ryelle It's kinda just relying on the browser's overflow:hidden; & text-overflow:ellipses; for that supplied content & element dimension (I'm guessing the browser considered the content that's there is smaller or effectively the same as an ellipses so it just shows the content). Also, the sizing is pretty much handled by the browser as well based on the content and display:flex;. At that point, I'm not really sure how we could refine specific elements like that having it rub up against another item (forcing it to have a gap between the items would leave less room for the content we care more about at that point when this really is just coming into play as a bunch of items are being shown in the menu [already a bit complicated at that point & possibly best to show the small bit of content in the menu item rather than nothing/spacing.])

@paaljoachim You can see I updated things per ​https://github.com/WordPress/wordpress-develop/pull/1082/commits/0fa39b689ab1e03892fe9166273e2993bf2b8c4e on 3/25 to help remove the unnecessary truncation when there's enough room to show the menu items & their content in the menu bar. As such, the screenshots you've included by pulling from earlier in that day, before those edits were made, are actually a bit out-of-date in terms of what it looks like with the current PR.

The concept of truncating very long words when it is needed feels like the way to go.

Updated PR to match version 1.2 of Admin Bar Wrap Fix plugin (plugin as a patch): ​https://wordpress.org/plugins/admin-bar-wrap-fix/

It now addresses mobile admin bar as it seems plugins are more likely to add items to the mobile admin bar than before (now causing the items to wrap and overlap the content area of the page [instead of offering a horizontal scroll as needed as this patch implements.])

[KZeni]

Now addresses mobile admin bar as it seems plugins are more likely to add items to the mobile admin bar than before.

I personally saw Yoast SEO, W3TC, Gravity Forms, and Monster Insights all having menu items on mobile. Definitely starts wrapping on mobile alongside the standard set of WordPress items (with it being reasonable for that set of items being present [or more/similar.])

[sabernhardt]

#53933 was marked as a duplicate.

Well... it's been more than a year now and this hasn't been formally addressed yet with WP 6.1 around the corner.

Maybe this is something that can be considered for WP 6.2.x? It doesn't need to exactly implement this solution (since this being plugin-ified has it not being as optimal as being natively implemented), but I'd like to see WP be able to handle the additional admin bar items that plugins may add better than it does now (wraps onto new line that then overlaps the content of the site, etc.)

[KZeni]

*Just in case it isn't obvious, my GitHub comment just now (see above) was saying it's been more than a year since the last message about this topic. Meanwhile, the fact of the matter is that this has been a shortcoming in WordPress that was reported about 8 years ago according to this ticket.

[seedsca]

Sorry for just sharing a link, but I wonder if we could/should implement something like this post suggests:
​https://dev.to/tmns/build-a-responsive-nav-bbc-smashing-magazine-style-57ln

I posted about this PR in the Core Editor Slack channel. As well as added a comment to the agenda for todays core editor meeting. ​https://make.wordpress.org/core/2022/11/07/editor-chat-agenda-9-november-2022/#respond

[KZeni]

@seedsca Interesting approach, but I'm not sure people would like to see some items being shown right in the menu while others are hidden behind a "More" menu (which often means they might as well not be there) simply due to the order in which they're showing in the menu & the current browser size. It might be helpful if plugins could opt into using the "More" menu (but we can't guarantee this will be used instead of adding directly to the menu bar so the issue may/will still persist with this change) or WordPress itself makes it so that plugins & things that try adding to the admin menu get added to the "More" menu at all times while the only things shown directly in the menu bar are the official WP menu items (but then that isn't the most flexible way to go about it even though it makes it much less likely [if not entirely] that there'll be a UI issue due to too many things trying to add items to the menu... some items a plugin/etc. might add really could make more sense to be shown directly in the menu bar rather than being presented in a sub-menu so it kinda introduces an issue while resolving another.)

As such, I do think the approach of truncating the text labels (even to the point of just showing their icon, if needed) is the best approach out of these (definitely mention if there's a different approach that I didn't consider that could work well). The icon should be sufficient in giving context for that menu item, it is similar to the mobile menu where they do just get reduced to being their icons, etc. while it then still tries to show as much of the text labels as possible so it's as helpful as it can be at a glance without ever having the items wrap to a new line. It's the one approach I've come across that resolves the issue without introducing another (while then also having it not totally rewrite how the menu bar is currently implemented/styled/etc. & just needs some CSS adjustments per what's been previously provided here [or similar.])

@paaljoachim Would making an adjustment to the admin bar be considered part of the Core Editor? Isn't there a Core UI, Design, Accessibility, etc. option that would be potentially more applicable here? I figured the core editor setup is more about the block/gutenberg editor while this is more about a core UI element of WordPress as a whole and an accessibility & visual issue that may occur in certain (not exactly uncommon) circumstances.

I'm glad to hear it's being brought up & discussed nonetheless, though!

My mistake.
I went ahead and added it to the Core slack channel as well.
​https://wordpress.slack.com/archives/C02RQBWTW/p1668002642964459

If you happen to be around and would like to attend the Core Dev chat. There is some more info here: ​https://make.wordpress.org/core/

[seedsca]

Good point @KZeni, regarding some plugin menu items being better shown than hidden under the more menu... Why not give the user the option of arranging, even hiding, them? I think this is really robust, since the problem isn't really about reducing the space as much as being able to manage it. Since all plugins can add a single icon there, we end up at the same place.

Just some thoughts and I realize I'm not contributing any code :)

[KZeni]

Replying to seedsca:

Good point @KZeni, regarding some plugin menu items being better shown than hidden under the more menu... Why not give the user the option of arranging, even hiding, them? I think this is really robust, since the problem isn't really about reducing the space as much as being able to manage it. Since all plugins can add a single icon there, we end up at the same place.

Just some thoughts and I realize I'm not contributing any code :)

I think what's there now for the admin bar generally works well. It just currently has a bug when given a specific use case which then has a reasonable fix (what's been proposed here of truncating the text labels so they all fit if/when needed).

I don't think we need to be completely overhauling the menu bar to suddenly become something users need to manage themselves (otherwise then still potentially having this same issue unless this same [or similar] thing we're considering here is still applied.) We need to fix this issue before we go about making it so these items can be manually managed (unless the menu bar really is being completely redone which then is a completely different conversation.)

@KZeni: Thank you for all the work on this! I just encountered this issue and it can disrupt the design on narrow viewports.

I hope this is merged into core soon!

@strarsis:

@KZeni: Thank you for all the work on this! I just encountered this issue and it can disrupt the design on narrow viewports.

I hope this is merged into core soon!

I definitely agree with it being implemented as part of the WordPress core. It’s been submitted to the WordPress github repo as a pull request & core trac ticket. Hopefully, it sees more attention/consideration to get officially adopted and/or it’s just fixed via other means (ex. a larger overhaul of the admin bar) at some point, but I can’t say when that might be as I’ve checked in on it every so often with it not really getting much traction for one reason or another. I suppose that situation validates this being a plugin as it’s been useful for years now due to the core issue still not being addressed (I’ll then look to update the plugin to make it auto-deactivate [or otherwise make it do nothing & show a notice of this fact] once the WordPress core addresses this formally by having it check the site’s current WP version to see if it’s needed or not so it should be safe to have this on sites [while it’d definitely be ideal to not need this plugin at some point in the future.])

@strarsis:

@KZeni: Thank you for all the work on this! I just encountered this issue and it can disrupt the design on narrow viewports.

I hope this is merged into core soon!

I definitely agree with it being implemented as part of the WordPress core. It’s been submitted to the WordPress github repo as a pull request & core trac ticket. Hopefully, it sees more attention/consideration to get officially adopted and/or it’s just fixed via other means (ex. a larger overhaul of the admin bar) at some point, but I can’t say when that might be as I’ve checked in on it every so often with it not really getting much traction for one reason or another. I suppose that situation validates this being a plugin as it’s been useful for years now due to the core issue still not being addressed (I’ll then look to update the plugin to make it auto-deactivate [or otherwise make it do nothing & show a notice of this fact] once the WordPress core addresses this formally by having it check the site’s current WP version to see if it’s needed or not so it should be safe to have this on sites [while it’d definitely be ideal to not need this plugin at some point in the future.])

I have just installed the plugin. Why hasn't it been applied yet in 6.x?

@ajtruckle Good question. It's been hanging out as a core ticket reporting this issue for 9 years now(!?) per https://core.trac.wordpress.org/ticket/28983 with me having implemented this fix with my ~feature-as-a-plugin~ fix-as-a-plugin about 2 or so years ago while then also reporting my fix with a proposed patched via the core tickets & also this GitHub repo. It was brought up by other a few times but never got the attention to loop it into an update.

I think the main thing is getting the attention for this to then be included as standard in the WP core, but I've been busy with other things lately while the plugin has met my own needs for this in the meantime so when the interest of others to get it included went away a few times over this period I ended up leaving it as-is.

That said, my fix appears to be just as valid today as it was back then (probably just making a few accommodations to address the merge block and/or any other aspect that might've changed that would've affected the proposed patch to make it more readily available to be merged into the core's upcoming version.) As such, anyone/everyone is more than welcome to take to the Making WordPress Slack, core trac ticket, etc. to help carry this along into being officially adopted.

Meanwhile, I do see discussions regarding Phase 3 of the WordPress roadmap (​https://wordpress.org/about/roadmap/) as having a redesigned site admin experience (with the full site editor & some select setups/plugins giving a glimpse of what that might be like) which may then just replace the admin bar which should then formally address that issue of the old admin bar with the new implementation. However, that might be a while off as that seems to be more in the discussion & prototyping stage with the implementation of this potentially being rather involved. So, again, I'd be happy if someone that has the time to push this fix into being officially adopted for the time being.

The only issue I have is on my iPhone. Clicking the toolbar icons does not display the menu. I have to tilt the phone round and then the menus display.

Sent from Outlook for iOS<​https://aka.ms/o0ukef>

From: Kurt Zenisek *@*.*>
Sent: Tuesday, July 18, 2023 10:27:02 PM
To: WordPress/wordpress-develop *@*.*>
Cc: ajtruckle *@*.*>; Mention *@*.*>
Subject: Re: [WordPress/wordpress-develop] Prevent Admin Bar Items From Wrapping if There's More Items Than the Available Adminbar Width (#1082)

@ajtruckle<​https://github.com/ajtruckle> Good question. It's been hanging out as a core ticket reporting this issue for 9 years now(!?) per https://core.trac.wordpress.org/ticket/28983 with me having implemented this fix with my feature-as-a-plugin fix-as-a-plugin about 2 or so years ago while then also reporting my fix with a proposed patched via the core tickets & also this GitHub repo. It was brought up by other a few times but never got the attention to loop it into an update.

I think the main thing is getting the attention for this to then be included as standard in the WP core, but I've been busy with other things lately while the plugin has met my own needs for this in the meantime so when the interest of others to get it included went away a few times over this period I ended up leaving it as-is.

That said, my fix appears to be just as valid today as it was back then (probably just making a few accommodations to address the merge block and/or any other aspect that might've changed that would've affected the proposed patch to make it more readily available to be merged into the core's upcoming version.) As such, anyone/everyone is more than welcome to take to the Making WordPress Slack, core trac ticket, etc. to help carry this along into being officially adopted.

Meanwhile, I do see discussions regarding Phase 3 of the WordPress roadmap (​https://wordpress.org/about/roadmap/) as having a redesigned site admin experience (with the full site editor & some select setups/plugins giving a glimpse of what that might be like) which may then just replace the admin bar which should then formally address that issue of the old admin bar with the new implementation. However, that might be a while off as that seems to be more in the discussion & prototyping stage with the implementation of this potentially being rather involved. So, again, I'd be happy if someone that has the time to push this fix into being officially adopted for the time being.

—
Reply to this email directly, view it on GitHub<​https://github.com/WordPress/wordpress-develop/pull/1082#issuecomment-1641013526>, or unsubscribe<​https://github.com/notifications/unsubscribe-auth/AB45RM45NB6LCAAGFZ7HECLXQ35SNANCNFSM4Y2PHZ3Q>.
You are receiving this because you were mentioned.Message ID: *@*.*>

@ajtruckle Ah, that’s unfortunately a mixture of a browser limitation & the want to keep this solution more simple than not.

I needed to introduce overflow-x to make it so the mobile menu items could be scrolled to view the additional items that would otherwise spill over, and that unfortunately brings overflow-y into the mix per the current browser behavior where it was then better to use overflow-y:hidden; rather than trying to show the dropdown which then has it be caught by the browser and forced to also show via scroll (as far as I know, there is no way to have browsers allow that horizontal scrolling via native scrolling while then also having that same element have items that extend outside of the scrollable area that also scroll with it.)

To avoid that, we’d probably need to introduce some JavaScript to handle things and/or restructure parts of the menu itself (ex. Do we have the drop downs cloned to be outside of the scrollable area while JS keeps them aligned with their menu item & toggles them accordingly to make it appear like one might expect given existing functionality? Do the items that go outside of the current viewport be placed in a “…” menu at the end with those other items moved to be offered inside of that via JS so there’s no scrolling & the drop downs can just show normally at that point? Do we look to resize the buttons/icons to specifically fit based on the current viewport & number of items needing to show in the admin bar? Do we just have the admin menu be presented as a simple button where it then toggles something like a full-screen overlay that’s specifically designed for a dynamic number of items on a mobile screen? There are probably other options, too.)

Meanwhile, this approach that’s much simpler than all of those options (no JavaScript or changing of the menu itself; just introduce a CSS approach that better utilizes more modern layout options given the existing overall style & content) still makes it where one can just navigate to the top-level admin bar item on mobile where that resulting page then offers what would otherwise be shown in the dropdown. So it does add one more page load, but it’s only on mobile and also keeps the overall proposed patch & implementation much simpler (still seems like an overall improvement compared to not having it even when that one particular & situational convenience is lost along the way.)

[sabernhardt]

#62288 was marked as a duplicate.