![]() This can be a big problem for html-based widgets that are dropped into other frameworks that add styles directly to native elements (*ahem* Foundation). Using divs previously gave us a large degree of safety from external styles clobbering our own styles. Addtionally, after ( ), we switched our Button elements to use the actual HTML button tag instead of divs. The tab-order mentioned previously was an eye sore in our accessiblity support, and we’re all happy to have that fixed in 5.0. In IE8 (because yeah, we still support that) we fall back to `display:table`, which works surprisingly well.Īccessibility has been a ( ), with ( ) helping push the industry forward and defining what accessbility means for a player. In 5.0 we were finally able to take advantage of ( ), which improves on the flexibility of the previous version while also maintaining the right tab order. This however led to a very awkward tab order for anyone navigating the controls with the tab key. In 4.0 we used CSS floats to allow a new button to be appended to the control bar and flow into space. One of our biggest challenges with the layout of the controls is keeping the control bar flexible and able to accomodate any new buttons that a plugin author might want to add. For 5.0 we’ve both simplified the default layout and added more flexibility than ever before. And still works today!) Over those years we’ve seen some very creative customizations and learned a lot about what users are hoping to do with player design when they’re able to use native web techologies. Video.js has had an all-CSS skin (including for Flash) since it was created in 2010 (the ( ) was *literally* all CSS, no images, fonts, or svgs. Besides, Chrome and Firefox are going to be in the thousands soon for their releases, and we want some of that fun. In all seriousness, we plan on being quicker with releases, both breaking and non, in order to make incremental upgrades less painful and, well, quicker. ![]() Working with the codebase is fun again (not like it wasn’t before, Judgy McJudgerson) and we think we’ve bought ourselves at least 6 months before we have to upgrade to ES9000. The fact is, this release ( ) and cruft over years of maintaining a popular open source library. **However**, from 5.0 on, we plan on being a lot more liberal with major versions to avoid stop-the-world mega releases like this. To be clear, there will be at least *some* upgrade cost between major versions because that’s just how things go. You’re probably already thinking about how little you want to do the mega-upgrade dance every time the major version is bumped. If you’re a Video.js user or lover of ( ), you’re probably looking at the ( ) and dying inside (or out). New definition around playback technologies (“techs”) Switched to BrowserStack for automated browser testing Switched from Closure Compiler to UglifyJS (we STOPPED mangling object properties) Added 6 more language translations bringing the total to 25 Added support for HLS in desktop browsers **without Flash** Added support for responsive layouts including auto-sizing to the video content Rebuilt the library in ES6/Babel/Browserify including Modules and Classes Using a flex-box-based controls layout for easier add-ons This will include an exhaustive dive into those choices, because…why not? For a widget, we’ve got a pretty awesome community.įor 5.0 we have some interesting new features, and we made A LOT of new technology choices. And thank you to the hundreds of issue commenters and plugin authors who helped shape this latest version. Video.js 5: The Only Thing That’s Changed Is Everything…except for like 3 things that didn’t (including the name).įirst and foremost, **THANK YOU** to the 25 contributors who completed and merged **146 pull requests** and updated just about every line of code in the project.Just a good ol’ Big Buck Bunny so we can have a Tumblr video to embed on.
0 Comments
Leave a Reply. |