W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2012

Re: [compositing?] Blurring an elementís backdrop

From: Lea Verou <leaverou@gmail.com>
Date: Mon, 16 Apr 2012 00:10:45 -0700
Message-ID: <4F8BC5F5.9040302@gmail.com>
To: Rik Cabanier <cabanier@gmail.com>
CC: "public-fx@w3.org" <public-fx@w3.org>
1. Absolutely not. Most authors don't even want to learn SVG, do you 
seriously expect them to learn a new C-based shader language?!

2. This depends on the background-blend-mode proposal, which is still 
under discussion and consensus is not even close. I like the idea of 
adding this to blend-mode, but I'm afraid your proposed syntax is quite 
unintuitive. I, for one, have no idea how it's supposed to work and I 
have actually read the current proposal.
I think we shouldn't be concerned with layers at the moment (such as 
background). Even if the effect operates on the entire element's 
backdrop, it would still be a big improvement over current methods. 
After all, that's what's needed in most cases.

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


On 15/4/12 21:53, Rik Cabanier wrote:
> This looks like a case of blending since it takes 2 inputs and changes 
> colors. Filters always have 1 input and compositing works by applying 
> alpha in different ways.
> I can see 2 ways of implementing this:
> 1. provide support for custom blending through shaders like we do in 
> filters[1]
> This would be very powerful but hard to use since the user would have 
> to learn a new language.
>
> 2. extend the blend-mode syntax [2] so you can specify a filter 
> operation on the source or the background.
> This is not quite as powerful but more intuitve.
> For instance, the Windows 7 example could be done as:
>
>     background: linear-gradient(...)
>
>     background-blendmode: color-burn(blur(5px), opacity(...))
>
> The shadow in the taskbar could be done as an axial gradient in an 
> additional background layer.
>
> [1]: 
> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html#feCustomElement
> [2]: 
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blend-mode + 
> https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#background-blend-mode
> [3]: 
> http://www.elmajdal.net/Win7/Windows_7_Aero_Peek_Feature/3-before-peek.png 
>
>
> On Sun, Apr 15, 2012 at 8:38 PM, Lea Verou <leaverou@gmail.com 
> <mailto:leaverou@gmail.com>> wrote:
>
>     One of the most common use cases of blurring I have encountered
>     (both in my own work and of others) is blurring an elementís
>     backdrop. Not only does it make designs more visually appealing,
>     but also helps to make text more legible over complex backdrops.
>     This is exactly the reason why it's widely used on native
>     interfaces that include semi transparent containers, such as the
>     Windows 7 Aero enviromment [1].
>
>     Currently, authors are relying on inflexible hacks that require
>     multiple images for simulating this effect [2]. Even with the
>     current CSS Filters proposal [3], this is not possible in the
>     general case, since filters operate on an element without taking
>     its backdrop into account. Perhaps it could be added as a blending
>     mode [4], but I think it might be outside the scope of that spec,
>     since blending modes seem to only operate on pixel colors
>     (operations of the sort result pixel color = f(element's pixel
>     color, backdrop pixel color) for every pixel), without taking
>     surrounding pixels into account.
>
>     I'm not sure I have a concrete proposal, as my knowledge is very
>     limited on whatís possible (efficiently) in this area. However,
>     it's a very common use case that needs to be addressed somehow.
>
>     [1]:
>     http://www.elmajdal.net/Win7/Windows_7_Aero_Peek_Feature/3-before-peek.png
>     [2]: http://css-tricks.com/blurry-background-effect/
>     [3]: https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html
>     [4]: https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html
>
>     -- 
>     Lea Verou (http://lea.verou.me | @LeaVerou)
>
>
Received on Monday, 16 April 2012 07:11:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 16 April 2012 07:11:22 GMT