RGBa, text-shadow in Safari, Firefox
While crafting my likes Museo and Sans spec last week, I found that Safari 4 and Firefox 3.5 handle RGBa alpha channel inheritance differently. I’m not sure which way is the right way (or whether, as a matter of W3C spec interpretation, there is a single right way), but both approaches seem logical. Here’s what I learned.
If an element (in our case an H2) uses color:rgba(#,#,#,0.5); and has a text-shadow, the alpha channel value of its color (0.5) is inherited by its text-shadow — in Safari. In Firefox this value is not inherited. Allow me to illustrate a few scenarios.
Hexadecimal colors
#intro h2 {
color: #07cefa;
text-shadow: 18px 0px 0 #ad0918;
}We start with regular hex colors – no alpha values, no opacity. Just color, plain and simple.
RGBa … inherited?
#intro h2 {
color: rgba(7, 206, 250, 0.5);
text-shadow: 18px 0px 0 #ad0918;
}Here we have RGBa color with an alpha value of 0.5, and our text-shadow still has a hex color. Safari applies the color property’s 0.5 alpha value to the text-shadow too; Firefox does not. Incidentally, the way Safari renders in this example is the look I was going for.
RGBa × 2
#intro h2 {
color: rgba(7, 206, 250, 0.5);
text-shadow: 18px 0px 0 rgba(173, 9, 24, 0.5);
}Now we have RGBa color with an alpha value of 0.5, and text-shadow color as RGBa with an alpha value of 0.5. Firefox renders as Safari had in the previous example, because it apparently handles the element and the element’s text-shadow independently. Safari, however, has seemingly multiplied both alpha values to produce a value of 0.25 — lighter than we intended.
Opacity
#intro h2 {
color: #07cefa;
text-shadow: 18px 0px 0 #ad0918;
opacity: 0.5;
}Back to straight hex values this time (no alpha value), but with an opacity of 0.5 applied to the element. Colors match now, as both browsers consider opacity to be inheritable. But the effect we had been striving for is lost; both browsers seem to treat element and text-shadow as a single, flattened layer. This is a nice alternative to have in our toolboxes (imagine the nested opacity/RGBa combos!), but it doesn’t help us with my ALL ABOARD effect.
Inconclusive
As I said, both interpretations seem logical. One might expect RGBa values to be inherited by child elements … though is text-shadow really a child of the element to which it is applied? One might also expect RGBa values not to be inherited: text-shadow has its own parameters, color is one of them, and the alpha channel that’s part of RGBa is technically part of the color. After all, the R, G, and B parts of an element’s RGBa value aren’t inherited.
I can’t wait for this to be standard in every browser.
Thanks for writing up this edge case. Here’s a great example of the need for clearly written and adhered-to web standards!
It seems to me that Firefox has the right of it here, as
rgbais purely a color statement, and abstracting out the alpha component to become opacity for the entire element seems wrong. I poked through the CSS3 spec for a while to see if there was any discussion of this issue, but none came up.@David “I can’t wait for this to be standard in every browser.”
Two letters: IE (in other words, this will never be standard in every browser, just standard in the ones that don’t give web developers high blood pressure)
That is a bug in WebKit (Safari). And fwiw, Opera 10b – or rather the latest snapshot build – agrees with Gecko (Firefox).
The color part of the value for text-shadow overrides the value (color) set for the
colorproperty. If no color is specified ontext-shadow, then Gecko and Opera use the value forcolor. WebKit then plain ignores thetext-shadowtreating it as if the color value was rgba(0, 0, 0, 0)…).Firefox has the right of it. From the examples you gave it looks like Safari wouldn’t allow you to render a solid dropshadow with transparent text. I don’t know what case there would be for that but still…
Matt, thanks for looking through the CSS spec.
Philippe, Sean – the more I think about it, the more it makes sense that Firefox is doing this right. I guess, because I built the Museo review while previewing with Safari, the effect seemed to make sense the wrong way because it looked the way I wanted it to look.
I wonder how often web designers think they’re building something correctly only to find out that their previews are flawed in parallel with their markup and style!
I think this is a bug in WebKit. More specifically it looks like a bug in CoreGraphics that we will need to just work around in WebKit.
Just came across the same bug whilst playing with text-shadow and RGBa – just to mention that Chrome follows Firefox, and doesn’t allow the alpha channel value to be inherited.
Dates on comments would be nice…
Awesome text-shadow tipps. I really like the idea of giving text an opacity! Thx for sharing!
Build the Museo review while previewing with Safari, the effect seemed to make
Thanks for sharing… I combine new and so nice post I agree with you. Your supplement is so informative.
I struggle with opacity. It took me forever to figure out how to deal with the change of font colors in the different search engines. I used to hate dealing with that. You get used to it, for sure.