Video.js: videojs 6.0 megathread

[gkatsev]

Just opening this up with some thoughts of what could go into a videojs 6.0 and to get everyone's opinions on what stuff should go into it.

• make sourceOrder a default. This will make it so that we're playing back items based on source order regardless of the tech order. Currently, this option is set to false to maintain the older behavior of finding the best source based on the best tech.
• use the new fangled (yet to exist) fully _accessible_ volume control
• allow users to ask the player which plugins have been loaded on it
• better plugin support -- this has yet to be determined what it will be but popcornjs's plugins are pretty nice
• drop old browser support like IE8 and IE9.

More to come, stay tuned.

[misteroneill]

Semi-related: Is there a policy (like a SLA) for how long the videojs org will "officially" support the previous version with patches?

[gkatsev]

Nope but we can probably come up with something. It'll probably be useful because of the IE8 support since we could tell people to use the 5.x release for older browser support.

[OwenEdwards]

At a minimum, I'd like to get accessibility fixes in V6 for:

2729 Handling keyboard focus when the big play button is activated

2156 Handling keyboard accessibility when the Control Bar is hidden

It'd be nice to add:

2343 (needs reworking) Support for description text tracks

2746 Accessiblity of the Captions Settings dialog

And then the accessible volume control widget, and any accessibility improvements to the menus which break the DOM.

I'm working on most of these, but I'll certainly need some help & advice.

[gkatsev]

@OwenEdwards sounds good. Hopefully, most of these can even just go into vjs 5.x and don't need breaking a major version bump.

[dmlap]

Does an API that lists plugins require a major version bump? Seems additive to me.

[misteroneill]

@dmlap It does if you're trying to know which plugins have been invoked on a player (vs. what plugins are on the Player.prototype). I think the only way that could be achieved today is to wrap the function that gets added to the Player.prototype in something that tracks that, but that'd be a breaking change because the value of Player.prototype.foo would not be the same as what you passed to .plugin().

I can see how a plugin system could be implemented piecemeal without requiring a major version bump. It's dead simple to continue supporting the current .plugin() form, but doing something like allowing a different set of parameters to be compatible with a more robust plugin system seems like it'd be do-able in a minor release.

That might be worth exploring.

[hartman]

On 'better plugin' support, I would like to remark, that it would be really good if there could be a good encouragement in the plugin design, for authors to separate UI and functionality. This is something that I have noticed while building a player; like half the plugins I need to fork, because their UI ideas do not map 1 to 1 to how i want the UI to expose that very same functionality.

[gkatsev]

@hartman that sounds like a great idea. It's something that I've already done in the brightcove playlist plugin. The core playlist functionality lives in brightcove/videojs-playlist and the UI lives in brightcove/videojs-playlist-ui.

[gkatsev]

@incompl do you have any thoughts?

[misteroneill]

@hartman :+1: all the way on that suggestion!

[incompl]

Might be cool to move away from storing so much state in the dom (specifically, the player's class list). Maybe some kind of shared & plugin-specific data methods. Rough idea but curious if it resonates with anyone.

[misteroneill]

Resonates with me for sure, but what form that takes, I don't know. It could be something offered by video.js proper, but I think it should be more of a "recommended practice" perhaps? Something to think about.

[gkatsev]

One of the reasons why the classlist is so big is that when you add stuff to it you can then use class selectors to target the player without requiring javascript so I don't think we should necessarily discourage that usage. However, having some kind of shared plugin store that can be queried would be good because then you don't need to rely on having the player's classlist being the source of truth for various boolean properties.

[Naouak]

Will there be any plan to try to downsize a bit the code ?

I saw several times some parts that seems a bit large for what they do (last exemple I saw was error display that is using a modal class that is only used by error display).

Imwould also love to get an easy way to not get some components in the minimified version of the player.

[misteroneill]

@Naouak There are a number of places that code could probably be removed. For example, there is still IE8-specific code lurking around that could be removed. I could see there being a good place for discussion of some components being moved to plugins, making video.js more modular. This would be especially true if the plugin architecture became more well-thought-out.

The ModalDialog component is currently only used in the ErrorDisplay, but there are plans to make other components into sub-classes of it (for example, TextTrackSettings) and it is also used in several plugins - both open-source and elsewhere.

[gkatsev]

Also, the ModalDialog is available for plugins and users to use if they want.

[gkatsev]

Make the play toggle turn into a replay button on ended. https://github.com/videojs/video.js/issues/3284

[gkatsev]

One thing that we're thinking about is deprecating Flash. What this would mean is that the Flash tech would log a warning for some time and at some point in the future, we'll move it into a separate project/tech with less maintenance.

[misteroneill]

Per discussion in #3520, it sounds like moving Flash out of the core is a big piece of what 6.0.0 should be.

Also, I'd like to re-iterate that I think we all agree that we need a more robust (but still relatively lightweight) plugin architecture. I don't want to outline what form that takes, but I think this would be a worthwhile approach:

• 6.0.0 deprecates plugin() when invoked with a string and a function (the current paradigm).
• 6.0.0 (or a minor thereof, up for debate) introduces the first iteration of the new plugin architecture; either through a new method (registerPlugin()?) or by supporting a new set of argument(s) to plugin() (such as, an object: plugin({name: 'foo', ...})).
• 7.0.0 removes the old-style usage of plugin().

[brandonocasey]

I think we should think about merging all of the common track logic. currently TextTrack has a lot of duplicated code all over the place that could be merged in with AudiTrack and VideoTrack code with some small backwards incompatible changes: (see my branch)

• giving TextTrackList an addTrack/removeTrack function
• having player.js return an empty text track list even if the tech is not yet initialized
• remove handleTextTrack* functions and use the patterns from video/audio track
• remove proxyNativeTextTrack and use the patten from video/audio track
• move removeOldTracks into the Psudo ProxyNativeTracks in the constructor

[misteroneill]

Maybe renaming "remote" text tracks? My understanding is that "remote" tracks come with an element (and therefore can be removed). Not sure why they're "remote" - maybe that they can have a source?

[brandonocasey]

I think we should call them elementTextTracks or something like that yeah

[hartman]

How about that "TextButton" component discussed in #3691 ?

[gkatsev]

Btw, I made a github project to catalog things that we are more likely to do. It's still not set in stone but let us know if you have any thoughts about it.

[gkatsev]

I think this has served its purpose. Please check out all the work we've been doing in master lately and the blog posts on blog.videojs.com.