Improvements to MobileMenuToggle #2162
lorenzolewis
started this conversation in
Feature Requests
Replies: 1 comment
-
Linking #977 for reference and some existing discussions |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
What version of
starlight
are you using?0.25.3
What is your idea?
Render
<MobileMenuToggle>
on every page, regardless of template used.As this template doesn't have a sidebar, the "sidebar" implementation on mobile could be adjusted to show the social icons, theme toggle, and i18n toggle. The mock I did of this by just rendering an empty sidebar doesn't look correct imo (below, first image) and I would propose adjusting the styling to be more like the second image below (with any design and UX input much appreciated:
Selfishly, this would also allow the usage of component overrides to be less complicated. A use case I have in starlight-utils is to show a group of navigation links in the top header. This naturally breaks down on narrow viewports (see lorenzolewis/starlight-utils#72) and the optimal solution in my mind would be to place the links on a narrow viewport inside the mobile menu. However, I cannot (easily) do this without needing to touch a good chunk of internal Starlight logic and CSS because that whole object simply doesn't exist on pages using
template: splash
.Why is this feature necessary?
It's always felt odd to me that when using
template: splash
the mobile "hamburger" button doesn't get rendered on smaller viewports. You could argue that its larger purpose is to show the sidebar of which there is none on the splash template. However, that menu shows more such as social links, language dropdown, and theme selection when fully packed.I would venture a guess that the
splash
template is most used out in the wild on landing pages. And on those pages I would argue that showing a site's social links, additional languages, and ability to switch theme should be there. After all, why should there be any difference in which site-wide features are available to a user just because the site author has opted for a more stylized page?Do you have examples of this feature in other projects?
No response
Participation
Beta Was this translation helpful? Give feedback.
All reactions