Re: [css3-background] blending on 'box-shadow' and 'text-shadow'

So, basically, you want to be able to target:

- The text
- The text shadow
- Any image, anywhere images are allowed
- border
- The box shadow
- outline
- ...

That would mean that if you go the keyword way, you'd have to change the 
definition of A LOT of basic properties, as well as many future 
properties. Pretty much everything that uses <image> or <color> could 
benefit from it.

I think a function that returns an <image> and another that returns a 
<color> would be the best options. Of course, there is the gradient 
problem, but you just need to extend the definition of blending modes to 
cover that case. I guess it must be quite similar to how something 
behaves with a blending mode + transparency. However, I have no idea if 
that would be possible to implement efficiently. It seems that blending 
modes on shadows were already challenging.

Lea Verou (http://lea.verou.me | @LeaVerou)


On 11/4/12 20:28, Rik Cabanier wrote:
> true.
> Also, a common use case would be to have blending between background.
> We got some feedback that this would be very handy to have. ie
>
>     the shadow effekt on the pictures in the slider in
>     http://bailey.dukedesign.co/ could be made this way
>
> and
>
>     In CSS we can have multiple backgrounds (http://goo.gl/tPoDE) what
>     I think would be awesome is if we could enhance this spec for this
>     new attribute. Something like:
>
>     background: url(images/play_icon.png) no-repeat 5% 50% overlay,
>     -webkit-gradient(linear, left top, left bottom, color-stop(0%,
>     #ffcc00), color-stop(11%, #ffc903), color-stop(100%, #ff9d2f));
>
>     In this example I can blend a Play Icon into a gradient background.
>
> I think we're going to need a new keyword to target each layer (= the 
> whole element, the background layers, shadow and the text/image layer)
>
> Rik
>
> On Wed, Apr 11, 2012 at 6:22 PM, Lea Verou <leaverou@gmail.com 
> <mailto:leaverou@gmail.com>> wrote:
>
>     Another idea could be to make blend-mode a shorthand. That would
>     avoid adding multiple semi-related properties. Perhaps something like:
>
>     blend-mode: <blend-mode-text> <blend-mode-background>
>     <blend-mode-border>;
>
>     (note that order is significant, for disambiguation purposes)
>
>     However, neither your `text-blend-mode` idea nor this one
>     addresses your original use case, i.e. applying blending modes to
>     the shadows only.
>
>
>     Lea Verou (http://lea.verou.me  | @LeaVerou)
>
>
>     On 11/4/12 09:53, Rik Cabanier wrote:
>>     Maybe a new separate keyword makes more sense and doesn't
>>     introduce all these exceptions.
>>
>>     The spec text for 'color' states:
>>
>>         This property describes the foreground color of an element's
>>         text content (http://www.w3.org/TR/css3-color/#foreground)
>>
>>     We could call it 'text-blend-mode'...
>>
>>     Rik
>>     On Wed, Apr 11, 2012 at 9:34 AM, Brad Kemper
>>     <brad.kemper@gmail.com <mailto:brad.kemper@gmail.com>> wrote:
>>
>>
>>         On Apr 11, 2012, at 9:10 AM, Rik Cabanier wrote:
>>
>>>
>>>
>>>         On Wed, Apr 11, 2012 at 8:50 AM, Brad Kemper
>>>         <brad.kemper@gmail.com <mailto:brad.kemper@gmail.com>> wrote:
>>>
>>>
>>>             On Apr 10, 2012, at 5:51 PM, Lea Verou
>>>             <leaverou@gmail.com <mailto:leaverou@gmail.com>> wrote:
>>>
>>>             > I think this problem should be solved more
>>>             generically, rather than adding keywords to random
>>>             properties. For example, the `difference` blending mode
>>>             could be used on text color to make it more legible
>>>             regardless of background. Or, blending modes on borders
>>>             and/or backgrounds could produce quite interesting
>>>             effects. They could also replace the `invert` keyword on
>>>             `outline`.
>>>             > Maybe a function that can be used in place of any
>>>             <color> value?
>>>
>>>             That was my first thought. Maybe even just extending
>>>             rgba() and hsla() to be able to do this sort of thing:
>>>             rgba(255,255,0,1,m) to multiply, and rgba(255,255,0,1,s)
>>>             to screen.
>>>
>>>
>>>         Doing it that way forces people to use the 'rgba' notation
>>>         so they won't be able to do 'color: red screen'
>>
>>         You wouldn't be able to do that as part of any <color>
>>         anyway, because the space would confuse shorthand properties
>>         that use a space. Maybe if there was a new separator that
>>         wasn't used elsewhere it would work, like 'background:
>>         red•screen'.
>>
>>>         Another issue is that this implies that you can use it in
>>>         gradient color stops which would be very strange.
>>
>>         True. Same issue if you use 'red screen' or 'red•screen' in a
>>         gradient. Or if you use any syntax of color mode in an
>>         animation or transition to go between two color modes. You'd
>>         have to say that there is a sharp cutoff midway between any
>>         two color modes.
>>
>>
>