[whatwg] Treat <video> like an image

[ddailey]

I'm thinking that you're thinking like an author. I like it!

Lots of fun and you're right to point out the possibility for problems. 
Allowing video to be turned off (just like browsers used to -- and probably 
still do --  allow for images to be turned off, when the hardware or user 
isn't up for it) would probably be required until about 2024 when the 
browser will be able to handle 4000 concurrent 6-channel 3-D video feeds, 
each diff-ed against all other pairs, in an omni-time-space analytic 
manifold of some sort that is tweaked by a hyperdimensional differential 
brainwave mouse .

The Opera build with real-time SVG filters applied to video, made me think 
that HTML and SVG ought to be sharing the filter business rather than being 
mired down with the troglodytic <canvas> re-invention of wheel business, but 
then who's to say that wheels need to be round anyhow?

cheers
David Dailey
----- Original Message ----- 
From: "João Eiras" <joao.eiras at gmail.com>
To: <whatwg at whatwg.org>
Sent: Monday, August 11, 2008 9:28 PM
Subject: [whatwg] Treat <video> like an image


> Hi !
>
> Not a long time ago, we saw an Opera build which had <video> support. What
> was really really cool about it was that <video> was pretty much supported
> like any other image format so we could apply filtering and other complex
> stuff from svg like in this example.
> http://people.opera.com/howcome/2007/video/svg/video-filter.svg
>
> This gives us an entire range of possibilities with <video>, just like
> with <svg>, or <img>
>
> I think that video should be supported like any other image:
>   - supporting transparencies (if the video codec allows)
>   - embedding video files with <video> or <object> element
>   - embedding video files with url() in css where images can be used, like
> background-image
>   - embedding video files with url() in css content rules
>
> If course, this could raise some issues like:
>   - performance - the UA should provide a way for the use to toggle video
> on and off, or could make decisions based on the platform's overall
> performance. Also, with rendering engines progressively migrating to
> architectures that support hardware acceleration, blending a background
> video with foreground content could be a trivial lightweight operation,
> although the same cannot be said for software renderers.
>   - fallback in css not possible - if a UA does not support video, then it
> would ignore the content embedded in the stylesheet. Such behavior is also
> fully supported for other content types, like unrecognized image formats
> and the likes. However, the problem of adding fallback content with CSS
> not being trivial, is a problem with css itself, and out of scope of the
> <video> specification
>   - accessibility, usability - by providing new means for authors to add
> more video and possibly other annoying animations in webpages, users could
> easily be annoyed with excess of animated content. This is more or less
> the same problem of performance, so the UA should give the user the option
> to disable video, preferably in site specific preferences, if supported.
>
> So, what do you think ?
>
> Bye.
>
>
>
>