W3C home > Mailing lists > Public > www-style@w3.org > June 2009

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

From: Brad Kemper <brad.kemper@gmail.com>
Date: Wed, 3 Jun 2009 08:05:47 -0700
Cc: Simon Fraser <smfr@me.com>, Mark <markg85@gmail.com>, Giovanni Campagna <scampa.giovanni@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
Message-Id: <45DE8ADE-9A15-4F6D-B519-37F10FB8D6BC@gmail.com>
To: "Tab Atkins Jr." <jackalmage@gmail.com>

On Jun 3, 2009, at 7:04 AM, Tab Atkins Jr. wrote:

> The issue, though, is that this type of property is (a) specific to
> backgrounds, when there are a lot of places where we probably want
> crossfade transitions, and (b) really *only* necessary for
> transitions, as any place where you are layering static backgrounds or
> other images you can adjust the opacity yourself in any common image
> editor.

I agree.

> (a) is addressed partially by a new functional primitive like the ones
> suggested by Giovanni and Hyatt, but then you return to having
> something unanimateable, unless we substantially change how
> Transitions works.

The way I understood Hyatt's answer was that 'blend(url(a), url(b),  
0.5)' would be returned as the 'background-image' value by  
getComputedStyle() halfway through the transition, but that authors  
would not actually use that value in their style sheets. Thus making  
background-image animatable.

Presumably, if this was also applied to visibility, then the returned  
value halfway between 'visibility:visible'  and 'visibility:hidden'  
would be 'visibility:blend(visible, hidden, 0.5)'. And you could also  
end up with values like 'content:blend('foo', 'bar', 0.5)', and 'text- 
decoration:blend(underline, none, 0.5)'.

> (b) is simply true - it may be somewhat *useful*
> outside of transitions (making it a bit more convenient to alter the
> opacity on images), but it won't ever be necessary in the way some
> other abilities are.
>
> I just don't think that the theoretical purity gained from casting
> this into a form that Transitions can explicitly animate is worth
> giving up the convenience/functionality of having transitions work
> with a bit of magic here.  When you want to animate between images,
> crossfading *is* the correct default choice most of the time imo, and
> Hyatt notes in a previous email that the ability to specify different
> image transitions is something that has been suggested before.

Given Hyatt's 'blend' value, above, then perhaps that would be  
specified something like this:

transition-blend-style: cross-fade /* other values could be 'zoom',  
'barn-door', 'wipe-left', etc. */

Then that would only apply to properties that could not be  
transitioned the normal way (or you could just say that the default  
for transition-blend-style is 'property-value' or something).


> As for what to present to getComputedStyle, the simple answer would be
> foo.jpg while you're in thee first half of the animation, and bar.jpg
> while you're in the second half.

That's what I imagined initially, as it would still be better than  
without any blending at all IMO.
Received on Wednesday, 3 June 2009 15:06:28 GMT

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