h5ive-DEPRECATED

h5ive-DEPRECATED copied to clipboard

Starting point for a suggestion of the HTML5 video element wrapper.

starting to work on video, now. #2 above is a bogus comment, disregard. :)

also, I want to expose a snapshot() function to capture a frame from the video. it will mean the video module depends on the canvas module. not wild about inter-module dependency, but I think in this case it'll be better than not.

Hi Kyle,

That's a cool idea, but doesn't it kind of go against the point of the library which was to just instate the facade over existing features of the HTML5 modules? Like you said, it's basically a combination of features from two modules rather than an actual feature of one of the individual modules...

Cheers,

Nathaniel

@nathaniellee yeah, i see your point. hmmmm....

Just to point out, there is in scope of h5ive the ability to define some sugar/helpers, they just need to be very thin and close to the bare metal. So, it's kind of a judgement call. In this case, I'm still not sure one way or the other. On one hand, "snapshot" is an extremely common use-case (probably the most common) for hooking up a video media-stream to a video tag. On the other hand, you're right, it does represent a higher-level operation across two separate modules.

For reference, I just up'd the first pass at the animationFrame module, and in that one, I not only have the equiv of requestAnimationFrame and cancelAnimationFrame, but I also have a slight bit of sugar for requestNextAnimationFrame, which just nests two calls to requestAnimationFrame. Again, this sugar was because there's some pretty decent use-cases that call for that. One could easily argue (as I have) that it's something that should be supported natively.

Bottom line: light sugar is OK for a facade. still unclear if snapshot is too heavy or not.

I've been struggling to figure out how to work HTML5 video into the concept of this facade. The video object itself really doesn't have much to it as far as methods are concerned... the real "meat" of it is in the events.

It may or may not be important to note that I work at a company that focuses on the online video space, and the project I've been working on pretty much the whole time I've been there is a video player that serves up either a Flash-based player or an HTML5 video player based on the user's platform.

We happen to use the animation frame loop quite a bit here so I'll be interested in checking out what you did with that facade. We basically just assign the appropriate request method to an onFrame method off of the window object or if there isn't one we fall back to setTimeout.

I still haven't made up my mind on if the "events" should be a core centralized thing, or if they should be handled individually by each module. I have strong arguments for both. Obviously, the video element is going to have a lot more events than something like canvas. So if we're doing a centralized system, it should be one that's not too heavy for that lighter module case.

But there's no question that there are important API functionalities in video that we should wrap. Not just the play/pause stuff, but also the canPlayType functionality.

Also, keep in mind, some of these modules are very simple, and that's perfectly OK. It doesn't have to be (and probably SHOULDN'T be) a really complex module to justify itself.

Took a quick look at your animation frame facade code... just curious if there's a particular reason why there isn't a fallback offered in case the user's browser doesn't support any of those methods? Or is that beyond the goal of this library?

Generally, we do something like this:

window.onFrame = window.requestAnimationFrame || window.mozRequestAnimationFrame ||
    window.webkitRequestAnimationFrame || window.msRequestAnimationFrame || function (fn) {
    window.setTimeout(fn, 1000 / 60);
};

@nathaniellee From the README:

This is not a "HTML5 shim|v" for semantic tags. It is not a library or framework. It is not a polyfill for older browsers.

I definitely want to keep out of scope anything that looks like polyfills or other things like that, because that's a whole different set of motivations, and brings a whole different set of bugs and problems to deal with. For instance, the video module would obviously have to include some sort of flash-based video player, and then we'd have to decide which player we wanted to bless, or build our own, etc. That kind of thing makes 'h5ive' more brittle, less flexible, and thus less useful, I think.

Instead, what I hope is, that 'h5ive' can be a good building block that people use for their own needs, including polyfills. In fact, having a companion project, or a 'contrib' folder in 'h5ive' for wrappers for various things like that, that's certainly a plausible thing. But I want to keep the main core and modules to that more limited focus.

In the case of animationFrame module, to use a setTimeout fallback, you could easily have a 'contrib' wrapper like this:

(function(aFrame){
   var supported = h5.supported("animationFrame");

   if (!supported) {
      h5.animationFrame = {
         // do your setTimeout fallback stuff here
      }
   }

})(h5.animationFrame);

BTW, that snippet shows that I want the h5.core to have a feature-test facility, where each module will register its own feature-test callback with the core, so a dev can easily detect if the module will work, or if they need to use a fallback.

Generally, we do something like this:

FYI, I believe the "fallback" scenario for requestAnimationFrame is slightly more complex in the robust case... this is what I currently use: https://gist.github.com/3004342#file_raf.js BTW, that same gist shows my requestNextAnimationFrame feature in stand-alone fashion.

OK... so I think I've got it... no fallbacks since it would be up to the developer to decide what kind of fallback code they want to use...?

...

I've seen Mr. Moller's post in the past when we were first investigating whether there was something better than what we were doing with the 1000 / 60 technique.

Ultimately we decided that while it was a really nice polyfill, we didn't necessarily need it since we tended to call setTimeout before executing our frame rendering code anyway AND we actually weren't that concerned with being on the mark with the frames per second... we weren't doing perfectly timed animations but actually just using the frame loop to render a canvas-based UI that changed based on changes to our model's state.

Great little piece of code, though...

no fallbacks since it would be up to the developer to decide what kind of fallback code they want to use...?

yes, that's a fair statement.

Ultimately we decided...

sure, I was merely pointing out that a generalized polyfill for the purposes of a "contrib" section of this library would need to be a bit more robust.

@getify about snapshot: Can't you just expose snapshot() function in it's own submodule of video, that will depend both on video and canvas? That way it can be included only if needed

@jpass -- that sort of functionality is perfectly legitimate, and will be quite useful! But it's more for a contrib library, or other framework, on top of h5ive, rather than part of h5ive proper.

The restrained design goal of h5ive is to build thin facades that expose existing functionality in similar (or better) APIs, not to add entirely new composed API functionalities (which is what a lot of other frameworks do).