- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Tue, 31 Jul 2012 23:37:31 -0700
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- Cc: www-style@w3.org
On Tue, Jul 31, 2012 at 9:53 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: > On Tue, Jul 31, 2012 at 9:44 PM, Andrew Fedoniouk > <news@terrainformatica.com> wrote: >> Is this >> >> div { background: element(#video1) repeat; } >> >> supposed to work if #video is some <video> element running movie? >> To work here means that div will show movie(s) at its background. > > Yes. Why do you think it wouldn't work? The spec is clear about this. This will increase required hardware level, HW should be capable to render video streams at multiple target locations/textures. Any fallback mechanism if hardware is not capable like average mobile device that even cannot do CSS transition with acceptable FPS? > > Look at the -moz-element() function that I based the spec off of. > Here's a page showing off some of the things it can do: > http://hacks.mozilla.org/2010/08/mozelement/ > The only thing across all samples there that requires live nature of element() rendering is that reflection sample. (That mimics -webkit-box-reflect features I think) All others are static cases that can be done either out of the box by existing CSS means or by binding Image object with css image. Image+Graphics bound with CSS background/border allows to achieve way more effects if to compare with this feature. Off the top of my head, the list of effects that were requested: #1. <frame> content transitions from content A to content B: blend, cross-fade, sliding etc. #2. swipe animation on DOM element that renders some record details. That is transition from content 1 to content 2 of the same DOM element (pretty much the same as #1 ) #3. Layout change transition: Animated flow: horizontal <-> vertical switch with some nontrivial morphing between start/end states and trajectories. All this require snapshot(s) of element to be taken at some moments of time. In any case element() in its current form requires scripting to achieve anything useful. Why not to leave this functionality to the Image/Graphics then? And it seems like element() will imply use of non-semantic DOM elements for rendering purposes solely. That's far from CSS ideology, no? -- Andrew Fedoniouk. http://terrainformatica.com
Received on Wednesday, 1 August 2012 06:38:02 UTC