W3C home > Mailing lists > Public > www-style@w3.org > August 2012

Re: [css4-images] element() and <video>

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Tue, 31 Jul 2012 23:37:31 -0700
Message-ID: <CALRQH79iVzhC2Q2n9M5+Nv9UbRFbiM4fyQ=C=kKaiaAEo6gJ8w@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:58 GMT