Re: Proposal: background-image-opacity or background-opacity

2009/6/2 Tab Atkins Jr. <jackalmage@gmail.com>:
> On Tue, Jun 2, 2009 at 11:59 AM, Giovanni Campagna
> <scampa.giovanni@gmail.com> wrote:
>> 2009/6/2 Tab Atkins Jr. <jackalmage@gmail.com>:
>>> On Tue, Jun 2, 2009 at 11:38 AM, Brad Kemper <brad.kemper@gmail.com> wrote:
>>>>
>>>> On Jun 2, 2009, at 9:21 AM, Boris Zbarsky wrote:
>>>>
>>>>> Mark wrote:
>>>>>>
>>>>>> Now with the css 3 backgrounds module multiple backgrounds are going
>>>>>> to be supported. Webkit has support for it and Gecko is in the
>>>>>> progress of making it all work. Now with that module (once adapted by
>>>>>> the biggest rendering engines) you can give one element both his
>>>>>> normal image and his hover image which is exactly the way it should be
>>>>>> if you ask me. Now i see one issue comming there. If you want to fade
>>>>>> from the normal image to the hover image you currently (if i read the
>>>>>> spec right) can't do that because there is no way of letting either
>>>>>> one of those images disappear, no way to set the opacity per image.
>>>>>
>>>>> Seems like this could be dealt with by just having separate style rules
>>>>> setting the two images and defining CSS transitions on background image to
>>>>> do fade in/out, maybe....
>>
>> How would you do that? Do you mean to fade out completely the previous
>> image, then fade in the new?
>> I don't think this is what the original poster intended.
>
> No, I'm sure Boris means exactly what the poster intended.  You set
> one background on the element normally, another on :hover or whatever,
> then use a CSS transition to tell it to animate.  We'd just need to
> specify in the Transitions spec how to animate transitions between
> images; crossfading is the most obvious way, and should be virtually
> always what you want.

I agree with you, for the general transition case, but note that this
does not allow imperative animation, which IHMO is required: even with
Animation / Transitions (and an adaptation of SMIL animations as well)
there are things you can only do with scripting.

>>>> Yes, I think that fade transitions would be good for a few other properties
>>>> too (those that don't change layout), such as visibility, border-style
>>>> (except for 'none'), content, list-style-image, border-image, etc.
>>>
>>> Basically transitioning any image can be done with a fade like that.
>>
>> If any image can be faded, it seems that "fading level" (opacity) is a
>> property of the image and therefore should be specified along with the
>> image.
>> I mean something like faded-img(<uri>,<number>), to be used in
>> background-image, border-image, list-style-image, etc.
>> It is slightly more verbose when you deal with transitions (since you
>> repeat every time the <uri>), but avoids adding new properties (and
>> potentially new values for the shorthand)
>
> True, if we actually wanted a way to manually run an opacity transform
> on an image, this would be more general and preferable.  But it's
> pretty obvious that doing a manual opacity transform in the use-case
> presented is a hack (as usual, the first idea that pops to mind is one
> based on the method one is currently using to implement something),
> and that it should instead be handled as a simple animated transition,
> with the effect automatically specified by the Transitions spec.

It is not really a hack: the UA has anyway to take the image, do an
opacity transform with a certain value between 1 and 0 (which depends
on transition-timing-function or the value set by javascript), mix
with the image in the second background layer, which is fixed, and
render. I'm just proposing some sort of authoring control over this,
that I'm pretty sure covers more use cases than animation of images.

> ~TJ
>

Giovanni

Received on Tuesday, 2 June 2009 18:54:07 UTC