Tracking for a Major version of Video.js

[gkatsev]

trafficstars

Check out the VHS story This issue is to track things that should happen whenever we plan or decide it's time to make a major version of Video.js. There's no timeline right now.

• [x] Remove IE11 support: Change browsers in babel-preset-env and drop any special code for ie 11
  • #7701
  • #7708
  • #7853
• [x] Assume native Promise support, remove workarounds
  • #7715
• [x] Convert #7067 to always throw as something is wrong if you got there.
  • #7719
• [x] Remove deprecation and drop support for setting attributes as properties #2176
  • #7857
• [x] align playbackRate button with other buttons to make click open the menu only see #7121
  • #7779
• [ ] Update menus on change, rather than recreating a whole new menu (performance). Adding a text track can take >100ms because we have to dispose the menu and recreate.
  • Chapters: #7604
• [x] Remove mentions of flash and the swf, techOrder etc
  • #7852
• [x] Remove manualCleanup from addRemoteTextTrack
  • #7588
• [x] update default exit fullscreen translation key https://github.com/videojs/video.js/pull/7183
  • #7856
• [x] Export all of the Video.js helpers (from utils) on the Video.js object. Video.js is a library and it has a lot of useful and well tested functions that we often need in other projects. I think this currently means that we duplicate the code in places and we should instead just export all utils.
  • #7717
  • #7761
• [x] remove firstplay event
  • #7707
• [x] Remove hardcoded node_modules in video-js.scss https://github.com/videojs/video.js/pull/7867
• [x] turn retryOnError by default and remove the option https://github.com/videojs/video.js/pull/7868

---

• [ ] when seeking, set playbackrate to zero instead of pausing and playing, consider hiding events from player in these cases
• [ ] Fix evented one https://github.com/videojs/video.js/issues/5962
• [ ] redo controls on mobile
  • double tap to seek forward/multiple taps will do multiple jumps, this can probably be as a new feature/opt-in
  • rethink how mobile controls work from the ground-up, don't worry to match it to desktop
• [ ] figure out plugins
  • Video.js should probably be a peer dependency
  • plugins probably shouldn't register themselves automatically and probably get Video.js via DI
• [ ] Use keys like PLAY_BUTTON for translation and import a en.json by default, to allow flexibility to change translations without further changing the key
• [ ] Review text and translations generally
• [ ] Icons - are fonts still the best way to go now? Would inline SVG be more flexible?
• [ ] Standard styling options for buttons - icon only, icon and text and text only.
• [ ] Use CSS variables - could be easier for a plugin to follow player style
• [ ] Normalise ID3 cue data (cue.value.data can be at least two types string, or a Uint8Array depending on browser)
  • W3C is taking up related standardization that could impact this.
• [ ] Settings menu - rather than having multiple menu buttons in the control bar

[mister-ben]

Some thoughts

• Use keys like PLAY_BUTTON for translation and import a en.json by default, to allow flexibility to change translations without further changing the key
• Review text and translations generally
• Icons - are fonts still the best way to go now? Would inline SVG be more flexible?
• Standard styling options for buttons - icon only, icon and text and text only.
• Use CSS variables - could be easier for a plugin to follow player style
• Normalise ID3 cue data (cue.value.data can be at least two types string, or a Uint8Array depending on browser)
• Settings menu - rather than having multiple menu buttons in the control bar

[gkatsev]

For ID3 cues, the Media and Entertainment Interest Group at the W3C is working on updating DataCue and normalizing ID3 and emsg from DASH, I think we probably want to hold off updating ours but also give input to them.

[rtritto]

• Remove hardcoded node_modules in video-js.scss #7208
• Replace npm with yarn (berry version) to:
  • Reduce package size and installation time
  • Increase consistency (use default Plug'n'Play checks for a missing dependency)
  • Have faster project booting time
• Add option to show and lock volume controls (e.g. on mobile doesn't work on hover, to volume icon, needed to show volume controls)

[heff]

when seeking, set playbackrate to zero instead of pausing and playing, consider hiding events from player in these cases

Interesting idea, is there somewhere I can read up on the background? Wondering if there's any downsides.

[gkatsev]

@heff I think that setting the playback rate to zero is closer to what should actually be happening when seeking. Since pausing and playing is kind of a workaround to the fact that if you scrub and stop moving the mouse, it'll start playing from that place, which isn't what we want. Plus, a lot of folks currently get confused when they get extra play/pause events from seeking.

[vladislavSp]

@gkatsev support IOS15?

[mister-ben]

@gkatsev support IOS15?

If you're referring to Fairplay playback, that's a bug in iOS that should be resolved in 15.1.

[vladislavSp]

@mister-ben 15.0.1 (current version) or 15.1?

[gkatsev]

@vladislavSp in 15.1

[misteroneill]

A few items here are not complete, but we may push them out. They are:

• Update menus on change, rather than recreating a whole new menu (performance). Adding a text track can take >100ms because we have to dispose the menu and recreate.
  • We have one related PR here (in main not next), but there may be more to do. I don't think this specifically has to be in a major release, though.
• Remove hardcoded node_modules in video-js.scss
  • Didn't seem like a high enough priority, but if someone wants to take it on in the next week or so, that would be great!
• turn retryOnError by default and remove the option
  • I think this one was missed.

[gkatsev]

Created PRs for the sass path (#7867) and the retryOnError (#7868).

The menus thing likely can happen as a fix/feat. I think it was here to consider whether we wanted to rethink how menus get reloaded altogether? I remember a discussion around it, though, can't find the issue that was created from it atm.

[misteroneill]

The menus thing likely can happen as a fix/feat. I think it was here to consider whether we wanted to rethink how menus get reloaded altogether? I remember a discussion around it, though, can't find the issue that was created from it atm.

Yeah, definitely. I scrolled down here to say just that.

The only remaining tasks for Video.js 8 are:

• https://github.com/videojs/video.js/pull/7865
• Update VHS component libraries' package.json dependencies and peer dependencies to require "video.js": "^7 || ^8" (unless they will actually require just "^8")
• VHS 3.0
• Update [peer] dependencies in package.json for all other Video.js projects