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

(wrong string) €™s backdrop

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 17 Apr 2012 13:10:53 -0700
Message-ID: <CAGN7qDBFbxT6x8y5Etnf22B6rD-OOoGG12GjzBGQXKe63QDoGg@mail.gmail.com>
To: Lea Verou <leaverou@gmail.com>
Cc: "public-fx@w3.org" <public-fx@w3.org>
On Tue, Apr 17, 2012 at 3:54 AM, Lea Verou <leaverou@gmail.com> wrote:

>
> Lea Verou (http://lea.verou.me | @LeaVerou)
>
> On 16/4/12 10:11, Rik Cabanier wrote:
>
> Hi Lea,
>
>  It is very powerful. If this feature were available, there would be
> places where people could get pre-canned effects so they wouldn't have to
> learn it.
> There could even be tools to create this code...
>
> I'm not saying it shouldn't exist, just that it shouldn't become an excuse
> for avoiding simpler syntax for more common effects. CSS is primarily meant
> to be written by humans and I don't think anyone here would want that to
> change.
>

I completely agree. Reverting to a new language should only happen if your
existing language is not powerful enough to describe your needs.
In this case, I don't really know what our needs are (is background
blurring just the top of the requirements iceberg?) but know that shaders
are used in different environments to solve similar problems.


>
>  You are asking for an advanced feature so the syntax will be fairly
> complex unless you want JUST blurring of your background (in which case a
> new blending keyword would suffice) but this would not result in the
> appearance of your examples.
>
> How so? It seems to me that it would be sufficient, but perhaps I'm not
> noticing some finer details. However, even in that case I don't think those
> finer details are necessary, especially since they can always be added
> later or done with a shader. If I'm not mistaken, the purpose of these
> shortcuts is to simplify common cases, since the proposals include
> extension points for the most complex ones (e.g. shaders).
>

Designer feedback (such as yourself) drives the spec. If enough people are
happy with having just a blurred background with a multiply blend, we
should add it!
Do you have a suggestion for a name?

>   My proposal was to extend blend-mode to:
>
> blendmode(filter chain on background, filter chain on source)
>
>
>  Maybe compositing would work here too:
>
>   alpha-compositing(filter chain on background, filter chain on source)
>
>
>  The second parameter could be optional so only a filter on the background
> is applied, the syntax then becomes.
>
>  blend-mode: color-burn(blur(5px))
>
>  or
>
>  alpha-compositing: src-over(blur(5px))
>
>  Isn't "filter chain on source" exactly what the `filter` property is for?
>

yes. The filter shorthands always operate on the source and you can define
a list/chain of them.


> Perhaps a new property is needed, to apply a chain of filters to the
> backdrop. Then, by combining blending modes, filters and the new property,
> more complex effects could be achieved, while keeping it simple for more
> basic cases.
>

That's what I was trying to achieve with my syntax: blend/composite a
filtered source with a filtered backdrop.


> Is this already possible in SVG somehow?
>

yes, SVG syntax already supports this. Drawbacks are that it is not that
easy to use and no browser has an implementation for backdrop (except maybe
IE10)


>
> Btw, you are using "background" to refer to an element's backdrop. This is
> also happening in the compositing proposal. The same thing is referred to
> as both "background" and "backdrop" and they are even explicitly declared
> synonymous in the prose (section 3). However, "background" has a very
> specific meaning in CSS already. Using the term to refer to two different
> things is very confusing. Can we stick to "backdrop", please?
>

Thanks! I will update the spec.


>
>
>  This need to be done with the background. For example if you want to
> implement something like the Win7 window, a window would be 1 element that
> contains other elements that implement menu bars, folder view, file view,
> etc. The window has a blurred background but the other views don't so only
> the background of the element has this effect applied to it.
>
> What I suggested only affects the backdrop, not the element itself. If the
> element does not have transparent or semi-transparent parts it would make
> no difference. I guess in that sense it's quite different from blending
> modes.
>

No, blending happens regardless if your element has opacity.
My original example used 'color-burn' [1] to darken the blurred backdrop
with a gradient. If you have a Win7 machine, you should observe how colors
change if you drag a window. There is definitely a gradient with either a
color-burn or multiply effect.

> What I suggested only affects the backdrop, not the element itself
But, it only happens where the element is and the result is composited
normally. This is the definition of blending.

Rik

[1]:
https://dvcs.w3.org/hg/FXTF/rawfile/tip/compositing/index.html#blendingcolorburn
Received on Tuesday, 17 April 2012 20:11:25 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 17 April 2012 20:11:26 GMT