- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 24 May 2011 16:01:35 -0700
- To: Brian Manthos <brianman@microsoft.com>
- Cc: www-style list <www-style@w3.org>
On Tue, May 24, 2011 at 3:38 PM, Brian Manthos <brianman@microsoft.com> wrote: > Brian: >>> With and without your proposal, what's the expected behavior for >>> transitions of background-image when the to and from both contain cross- >>> fade? > > Tab: >> Sigh, I had something like this tickling my brain, but I ignored it. >> Yeah, transitioning a cross-fade() image produces a nested cross-fade(), so >> there's no way to disallow it. Never mind, then! > > > Still curious on the answer to the "without your proposal" half of my question. Ah, sorry about that. > (1) Is it supported? Yes. > (2) If yes to (1), what should the user experience be? As currently specced, the fact that an image is generated by cross-fade() is irrelevant, and it's transitioned like any other image - by wrapping another cross-fade() around it. Now that you bring this up, though, it probably makes sense to define a special interpolation mode for <image-combination>s, such that if both the start and end use the same images, just different <percentage>s, they transition intelligently by just adjusting the percentage. If they use different images, it would transition just like a normal image. This is similar to how gradients have a special transition mode when they match sufficiently, and otherwise transition like images. > (2b) Should the intermediate frames be rendered "as if" the cross-fade from the to and from endpoints was rasterized and then cross-fade between the two? They may be, though it's not required. If one or both of the component images are vector formats, an impl is allowed to be smart with the scaling. They may instead just rasterize the endpoints and do a dumb scale if they wish, though. > (3) If yes to 2b, does this rasterization approach apply for SVG images as well? Yes, as explained above. > (4) If yes to (3), does this indirectly end up defining what an SVG to/from PNG transition should look like? Not quite sure where you're going here. An image is an image. You just apply the operations in the spec - scale each image, dissolve each image, combine them with the 'plus' operator. This works between any image format. > (5) If yes to (3), this should be very interesting for (a) multiple-resolutions-in-a-single-file and That is a somewhat interesting case. I guess it's possible to interpret the spec as allowing an impl to switch with resolution to use in an ICO file as the scale happens. I doubt that's a good idea, but unless someone requests it, I'm loathe to special-case that in the algorithm. > (b) for no-intrinsic-dimensions-in-the-specific-format. This should be handled as explained in (2b) - if the image format is scaleable, impls are allowed to be smart, but they're also allowed to just rasterize the endpoints and be dumb. > (6) If yes to (3) and (5b) is covered richly in the spec, then I think { CSS Gradient -> SVG -> PNG -> ICO } interpolations all the sudden become well defined. Yes, they should be, subject to the impl wiggle room above. ~TJ
Received on Tuesday, 24 May 2011 23:02:22 UTC