- From: Brad Kemper <brad.kemper@gmail.com>
- Date: Wed, 3 Jun 2009 09:28:34 -0700
- To: Simon Fraser <smfr@me.com>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, Mark <markg85@gmail.com>, Giovanni Campagna <scampa.giovanni@gmail.com>, Boris Zbarsky <bzbarsky@mit.edu>, www-style@w3.org
On Jun 3, 2009, at 9:18 AM, Simon Fraser wrote: > 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. > > That's true, but doing so forces you to use an alpha PNG, which is > considerably larger than the equivalent opaque GIF or JPEG. I don't think that is necessarily so, especially if the alpha is all one value, because PNGs compress better. They also look better than JPEGs that have been compressed down to the file size of a PNG of the same content/dimensions. > We've also run into situations where separate control of the > background > and foreground opacity of an element would be useful. The existing > opacity property has the disadvantage that it is applied after > compositing > with descendants, so it's impossible for a child to be more opaque > than > its parent. Don't forget RGBA and its brethren. Between PNGs and RGBA, you can make any background as transparent as you like (or at least you will once all the UAs you care about support both of those).
Received on Wednesday, 3 June 2009 16:29:13 UTC