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" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
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.
