Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
✅ Deploy Preview for vjs10-site ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
📦 Bundle Size Report🎨 @videojs/html — no changesPresets (7)
Media (8)
Players (3)
Skins (29)
UI Components (25)
Sizes are marginal over the root entry point. ⚛️ @videojs/react — no changesPresets (7)
Media (7)
Skins (26)
UI Components (20)
Sizes are marginal over the root entry point. 🧩 @videojs/core — no changesEntries (9)
🏷️ @videojs/element — no changesEntries (2)
📦 @videojs/store — no changesEntries (3)
🔧 @videojs/utils — no changesEntries (10)
📦 @videojs/spf — no changesEntries (3)
ℹ️ How to interpretAll sizes are standalone totals (minified + brotli).
Run |
mihar-22
requested changes
Apr 1, 2026
Member
mihar-22
left a comment
mihar-22
left a comment
There was a problem hiding this comment.
Blockers
- "Flyout" and "panel" aren't established terminology. The component library ecosystem (Base UI, Radix) uses "submenu" - the distinction is how submenus render (cascading vs non-cascading), not a different component category. Introducing unfamiliar vocabulary adds friction for anyone coming from or working simultaneously with these libraries.
modeprop creates a polymorphic composition tree. The valid set of children depends on a runtime prop. Panel parts are no-ops in flyout mode, SubMenu parts are no-ops in panel mode. TypeScript can't catch this, and there's no runtime error either. It'd be cleaner if the composition itself determined the behavior rather than a prop changing which children are valid.- Cascading (flyout) submenus may not be the right starting point for the player. The player operates in a constrained popover - cascading submenus that open as separate positioned popups don't fit well here. In-place transitions within a single container are what YouTube, Plyr, and most video player settings UIs use. It might make more sense to ground the design in non-cascading submenus rather than starting cascading first with a mode escape hatch for panels.
- Panel navigation model feels premature.
PanelNavigationState,createCarouselTransition(), panel stack, rapid-navigation cancellation, 4 panel-specific parts - there's a lot of machinery here - Panel parts overlap with SubMenu semantics.
Panelis effectively aSubMenuContentrendered in-place,PanelTriggeris a SubMenuTrigger,PanelBackis a SubMenuTrigger in its open state. The hierarchy is the same - the difference is rendering strategy (in-place vs cascading). Base UI's NavigationMenu handles this distinction compositionally (Portal presence vs inline Viewport) rather than with parallel parts. Worth considering the same approach here.
Suggested direction
Non-cascading submenus as the default, using the existing SubMenu parts. Content acts as the viewport/transition container. SubMenuTrigger handles both forward and back navigation via visual state (data-open). Cascading (flyout) support can be additive later via Portal composition.
Transitions
Transitions and sizing are CSS-driven via custom properties and data attributes on Content:
--menu-width/--menu-height- measured dimensions of the active submenu, enabling smooth container resize transitions--available-height- from popover positioning, for scroll containment on long listsdata-open- transition direction for slide animations
React
<Menu.Root>
<Menu.Trigger>Settings</Menu.Trigger>
<Menu.Content>
<Menu.SubMenu>
<Menu.SubMenuTrigger>Quality</Menu.SubMenuTrigger>
<Menu.SubMenuContent>
<Menu.RadioGroup value={quality} onValueChange={setQuality} label="Quality">
<Menu.RadioItem value="auto">Auto</Menu.RadioItem>
<Menu.RadioItem value="1080p">1080p</Menu.RadioItem>
<Menu.RadioItem value="720p">720p</Menu.RadioItem>
</Menu.RadioGroup>
</Menu.SubMenuContent>
</Menu.SubMenu>
<Menu.SubMenu>
<Menu.SubMenuTrigger>Speed</Menu.SubMenuTrigger>
<Menu.SubMenuContent>
<Menu.RadioGroup value={speed} onValueChange={setSpeed} label="Speed">
<Menu.RadioItem value="0.5">0.5x</Menu.RadioItem>
<Menu.RadioItem value="1">Normal</Menu.RadioItem>
<Menu.RadioItem value="2">2x</Menu.RadioItem>
</Menu.RadioGroup>
</Menu.SubMenuContent>
</Menu.SubMenu>
</Menu.Content>
</Menu.Root>HTML
<button commandfor="settings-menu">Settings</button>
<media-menu id="settings-menu">
<media-menu-item commandfor="quality-menu">Quality</media-menu-item>
<media-menu id="quality-menu">
<media-menu-radio-group label="Quality">
<media-menu-radio-item value="auto">Auto</media-menu-radio-item>
<media-menu-radio-item value="1080p">1080p</media-menu-radio-item>
<media-menu-radio-item value="720p">720p</media-menu-radio-item>
</media-menu-radio-group>
</media-menu>
<media-menu-item commandfor="speed-menu">Speed</media-menu-item>
<media-menu id="speed-menu">
<media-menu-radio-group label="Speed">
<media-menu-radio-item value="0.5">0.5x</media-menu-radio-item>
<media-menu-radio-item value="1">Normal</media-menu-radio-item>
<media-menu-radio-item value="2">2x</media-menu-radio-item>
</media-menu-radio-group>
</media-menu>
</media-menu>Doc structure
We simplified design doc conventions in #1173. Recommendations:
- Rename
index.mdtomenus.mdas the single design doc - anatomy, API surface, keyboard, accessibility - Decisions around cascading vs non-cascading handling can live in
menus.mddirectly - Drop
decisions.md- add decisions as they're debated during review and implementation - Drop
architecture.md- this is an implementation plan, save for that phase - Drop
parts.md- redundant with the API surface already inmenus.md, add per-part detail inline if needed
Out of scope
- Cascading (flyout) submenus - the player doesn't need them right now. Can be added later via Portal composition if a use case appears.
- Context menus - needs its own design, starting with what we'd actually use them for in the player.
Collaborator
Author
Happy to change naming but flyout menu is a common design term outside of Base UI circles, such as the W3C - their example refers to navigation but the principle is the same. Maybe "panel" (or pane) isn't so obvious but to me
Sure, we could have completely different components paths for each type.
Yep, fully aware of the constraints of course and that's why I built Plyr the way I did but we may also want to consider offering some variance in design, otherwise skins all start looking very similar. Happy to go down that path though and add some more options later.
Yep, I think some of it will come out in the wash as I build it. Not aiming to get a 100% waterfall implementation documented here. Just the general direction.
Will take a look.
Sure, this all changed after your recent PR so I'll update. Its current state was based on the previous standards we had in place.
Context menus (as in right click) aren't covered in this design doc. |
sampotts
force-pushed
the
feat/menu-ui-component
branch
from
f2943dc to
e7622f8
Compare
mihar-22
previously approved these changes
Apr 21, 2026
sampotts
force-pushed
the
feat/menu-ui-component
branch
from
e7622f8 to
53ba9ea
Compare
4 tasks
mihar-22
approved these changes
May 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #1066
Closes #1381
Note
Low Risk
Docs-only change that adds a new UI design document and a spellcheck dictionary update; no runtime behavior or API surface is modified.
Overview
Adds a new draft design spec
internal/design/ui/menus.mddescribing the proposed headless, compoundMenuAPI for React and HTML (including nested submenus, keyboard/ARIA behavior, transition/CSS variable contract, and layered core/DOM/UI architecture).Updates
cspell.jsonto includevidstackin the spellchecker dictionary.Reviewed by Cursor Bugbot for commit 53ba9ea. Bugbot is set up for automated code reviews on this repo. Configure here.