Open
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 (5)
Players (3)
Skins (16)
UI Components (21)
Sizes are marginal over the root entry point. ⚛️ @videojs/react — no changesPresets (7)
Media (4)
Skins (14)
UI Components (18)
Sizes are marginal over the root entry point. 🧩 @videojs/core — no changesEntries (6)
🏷️ @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. |
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