- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Mon, 30 Jul 2012 23:54:58 -0700
- To: www-style@w3.org
Current spec[1] says: "As the referenced element changes appearance, the image changes as well." It means that the background image (observer) is a live view on some other element (observable). In order this to work the observable shall exists at moment of observer rendering. Live nature of this mechanism actually limits number of useful cases quite a lot. In fact I cannot imagine UI cases where such live rendering is really needed. But there are many useful cases for makeElementSnapshot(element):Image function. Let's consider ideas/cases defined in spec[1]: 1. "to create live previews of the next/previous slide in a slideshow". Live nature requires "next/previous slide" DOM elements to exist. Why not to use those DOM elements as they are (with transform:scale if needed)? 2. "reference a canvas element for a fancy generated gradient or even an animated background" This is actually about ability to bind/use scripting Image object as CSS background. Here is how I implemented this: In CSS I define: #fancy-back { background: url( memory:fancy-back-image ); } In script, I create the image and its URL binding: var img = new Image(200,200); var canvas = img.getContext("2d"); // drawing ... canvas.fillRect(10,10,130,130); // ... img.src = "memory:fancy-back-image"; // bind it with CSS "consumers". In the same way the Image ctor can be extended to support element reference to make snapshot of the element: var img = new Image(100,100,elem); img.src = "memory:elem-snapshot"; The img will contain snapshot of the element at given moment of time and can be used e.g. for various transition effects. Consider loading document A in some <iframe>, making its snapshot, and loading document B in the same frame while playing transition using stored rendering of A. Here is an example of such frame content transition (screenshot is taken in the middle of scroll transition): http://terrainformatica.com/w3/frame-transition.png In any case the element() feature cannot be (at least it seems so) used without scripting that's why I think this functionality should be left for HTML/JS where dev can better define what he/she needs: live view or just snapshot. And with fine grained parameterization: as-is/reflow, suppress CSS visibility, avoid non-statics, etc. In CSS spec we just need to define mechanism of CSS image bindings with in-memory Image's. My practice shows that something like this: background: url( memory:some-unique-id ); is sufficient enough. Could we convince ourselves in this element() thing by providing more or less real and useful examples? [1] http://dev.w3.org/csswg/css4-images/#element-notation -- Andrew Fedoniouk. http://terrainformatica.com
Received on Tuesday, 31 July 2012 06:55:29 UTC