- From: Andrew Fedoniouk <news@terrainformatica.com>
- Date: Sat, 12 Apr 2008 16:11:57 -0700
- To: David Hyatt <hyatt@apple.com>
- CC: robert@ocallahan.org, www-style@w3.org
David Hyatt wrote: > > On Apr 12, 2008, at 7:49 AM, Robert O'Callahan wrote: > >> The issue at the end of section 2.5 is important. A useful experiment >> for evaluating animation proposals is to try to implement the OS X >> dock's behaviours, and that issue comes up immediately --- I gave up >> on SMIL when I couldn't figure out how to handle that :-). >> > > A dock implemented using CSS animations: > > http://www.sitepen.com/blog/2008/03/28/svg-css-animations-fisheye-fun/ > > dave > (hyatt@apple.com) > Here is another implementation of the fisheye: http://www.terrainformatica.com/htmlayout/images/fisheye.jpg It is implemented as a behavior (system of event handling functions) I strongly believe that things like these are better describable in terms events/behaviors. E.g. which event trigger transition and which one stops/cancels it? In my implementation of the fisheye the behavior changes value of attribute @magnified so CSS is able to better style transition steps, for example rightmost table on the screenshot above has following declarations: table[magnified="1.75"] { font-size:11px; // bigger } table[magnified="2.00"] { font-size:13px; // something readable } behavior in my case is a pure behavioral thing - it is responsible for setting attributes and dimensions of the elements so CSS can do what it was designed for - styling states of the elements. I think that it is really makes sense to move things like this into BECSS document and define there standard set of behaviors. Thus behavior:fisheye(); there will have a definition of list of events and will define DOM attributes/states that the behavior will change dynamically. So authors will be able to style states according to their needs. -- Andrew Fedoniouk. http://terrainformatica.com
Received on Saturday, 12 April 2008 23:12:34 UTC