Fluid widths and aspect ratios with metadata defaults

[heff]

Building on #1440 from @baloneysandwiches. (Would appreciate your feedback Alex.) This isn't completely finished and needs tests but wanted to get it out for review.

The big diff here is that I'm creating a style element and using that to add widths (user-set, metadata-provided, and defaults) and aspect ratios for fluid layouts. The goal was to let the video.js user override player dimensions with CSS the same way they can with the video element. Previously we were using inline styles to add width and height, and we were doing that with the default values, which meant you couldn't easily use CSS to size the player. (I'm able to make this change now because we're in 5.0 development)

I've included a screen shot of all the different user stories from #982 passing.

One question that's come out of this is whether or not we need the width/height functions on other components, since everything is getting sized in the main stylesheet. It would be nice to drop or at least simplify those. In this PR I'm overriding the player's width/height functions so now they work differently from other components.

Amazingly this works in IE8 with Flash, including the metadata widths. I'm just having an issue getting the poster image centered again.

Related Issues: #983, #1440, #982

[gkatsev]

Would be nice if the comments are made directly in this PR rather than on the commits themselves because it's easier to see the context and replies of everything.

[albell]

Yeah, the integers-only requirement for display width seems like a spec bug to me. It's one of those things that look cleaner, but are actually inaccurate. Maybe because the spec was written before onslaught of high DPPX devices? Anyway, videos render at fractional values all the time. There really should be ways to get/set that, to and from the CSSOM.

A simple layout example: browsers currently render border: 0.5px solid #000 as expected on retina+ devices. We're already there. The change happened in FF first, then webkit and IE caught up around three years ago:

http://trac.webkit.org/changeset/116009
http://blogs.msdn.com/b/ie/archive/2012/02/17/sub-pixel-rendering-and-the-css-object-model.aspx

You're right that this would have to be an across the board change in order to work. But in terms of page complexity, I actually think the pure-CSS use cases are simpler, and the JS dimension calculations are for more complex behaviors. In terms of a use case: I'm imagining something like a grid of X-by-Y videos, sized in percentages, with expected subpixel rendering on a 2x tablet. Once elements are getting substituted/replaced, JS animations are flying in, etc, you will want to be able to get and set the size of a given element with JS with subpixel precision. It can be hairpulling to troubleshoot rounding errors in layout, and it's pretty forbidding to rewrite all of a plugin's getters and setters to get a little border edge or unwanted overflow to go away.

If Chrome-style 13 digit CSS values offend your sensibilities (which I can totally understand), perhaps consider truncating to a small number of decimal places?

[frapontillo]

I am really interested in having a responsive video player, just like the native one is. Are there any updates on this? What's blocking?

[heff]

This PR is waiting on the 5.0 release to be fully available. Currently it's waiting on work for changing to ES6 modules. @mmcc we should probably just open a PR for the ES6 change now, so it's there to point to. I also need to write tests for this.

@baloneysandwiches, re CSS widths: I think the right way to do what you're describing is by setting styles on the player element.

myPlayer.el().style.width = '100.555px'
// or
document.querySelector('#video-js').style.width = '100.555px';

Using the style property is the only way to set fractional dimensions on the video element via javascript, you can't use videoEl.width, so by the "mimic the video element" guideline that's how you should set fractional dimensions for the video.js player too. At the same time I can't think of why anyone would complain that we're not rounding off their dimension values, so I don't see an issue with "improving" on the spec in this case to allow floats in the width/height properties/attributes (anyone disagree?). Are there any edge cases you can think of that we should be protecting against while accepting/setting float widths? My plan at this point would just be to switch parseInt with parseFloat.

[heff]

Rebased this on master with the all the ES6 changes. All the sizing tests still work. I still need to write tests.

[heff]

@videojs/core-committers can I get a review on this one? I'd like to get it merged in.

[mmcc]

I don't think it's necessary, but it might actually make this more readable to refactor this into a mixin.

@mixin generate-player-sizing($ratio) {
  width: 100%;
  max-width: 100%;
  height: 0;
  padding-top: 100% * $ratio;
}

.video-js.vjs-fluid,
.video-js.vjs-16-9 {
  @include generate-player-sizing(9/16);
}

.video-js.vjs-4-3 {
  @include generate-player-sizing(3/4);
}

That mixin name sucks, but you get the picture.

[heff]

Cool, I like that.

[mmcc]

👍 🎉 🎋

[dmlap]

Maybe not for this PR, but a thought: should we default this to 16x9?

[heff]

Yeah, this is a hard one for me. We've drawn a hard line around the html5 video spec and there's a lot of benefits in being strict about that. The 300x150 default appears to come from somewhere outside of the html5 video spec, though. The canvas element defaults to 300x150 too. We'd still be going against what browsers have implemented, so a vjs player next to a bare video element wouldn't line up. But I don't think there's any argument against 16:9 being better for video than 2:1. Plus I've already set the default aspect ratio in this to 16:9 when in fluid-mode.

Unless any of that changes your mind I'll make 16x9 the default.

[dmlap]

I've been shifting towards 16:9 as a default for awhile now. I think I'm convinced it's a better default setting at this point.