RE: [css3] support for filters

Hi Alan, 

> I would still like to see some of the affects in Brad's description of a 'drop-shadow', some of which don't behave like a box-shadow filter like the examples 
> with dotted borders casting shadows on the background. Here is one test.> 
> <http://css-class.com/test/temp/box-shadow-borders.htm>

I'm looking at this with different browsers and they all seem to render it differently. :-)
Is it expected that an 'inset' box-shadow is applied on the box, while the regular one is applied to the box + border?

> I have applied Microsoft propriety filter dropShadow to examples 2 and 4. Even though the later test case is semi transparent, the dark part begins on the top
> and left edges (not offset) and unlike the bottom and right edges that are offset.
I agree. The dark part should be offset and the text should have casted a slight shadow in your example.

> Example 5a is a hack using the shadow of example 5a.
I looked at your HTML code and I don't quite follow it. What does the 'test' class do for example 5b?

> I noticed how rgba color and this MS filter combined creates an orange that would not be the same as if you layered a transparent orange background-image 
> or transparent colored (from a child or sibling element) over the same shadow. IE9 seems to create a composite of both colors.
That is expected. You're seeing the dropshadow through the transparent orange which makes it darker. However, the top left should have stayed orange because there's no shadow underneath.
This must be a bug in Microsoft's filter...

>> What I'm looking for is something that would shadow the elements
>> within the box. If the box contained a set of images, text and svg
>> blocks, the box's image would cast a shadow on it previous siblings.
> Don't you mean previous ancestors?
yes

>> The elements within the box should not interact with each other. The
>> shadow would be calculated using the visible part of the element and
>> be visible through non-opaque elements. I attached an example of what
>> this looks like. The html for this image would look like:
> <div style="filter: dropshadow;">
>     <div style="..."></div> <!-- stroked rect -->
>     <div style="..."></div> <!-- filled rect -->
>     <p style="..">Some example text</p>
>     <img src="coin.svg" style="..."></img>
>     <img src="coin.svg" style="..."></img>
> </div>
> Thank you Rik for a good example. I have made some examples using HTML 
> and CSS. There are a few example showing steps in how this could be 
> done. Please remember that I have coded in a non SVG fashion. SVG stroke 
> is the same as border and SVG fill is the same as background-color if 
> clipping is on the padding edge.
> <http://css-class.com/test/temp/coins.htm>
> The test is suited to a 16px font-size setting (IE medium) and I have 
> used Arial font in the test. If your settings are different, the text 
> may be out of place or broken on a new line.
> * Example 1 is constructed in the manner of your code above with <!-- 
> filled rect -->. This requires a bit of use of negative margins.
> * Example 2 is constructed in the manner in how I would approach it 
> where you can offset where the red background begins.

Notice how the text and the red box are casting shadows on their ancestors. This is what I was trying to avoid.
Also, the coins are not generating shadows.

> * Example 3 is the same as example 2 but without any text-shadow or 
> box-shadow.
> * Example 4 has the only CSS property that behaves like a filter, this 
> is opacity. Here is an excerpt from the FX minutes [1].
>   ChrisL: So when you apply a filter, what is it applied to?
>    dbaron: The whole thing; the border/background/etc.
>    ... I think it works like opacity and creates a new stacking context.
>   <dbaron> (but not sure about that)
>
> Indeed David is correct. Opacity creates a new stacking context. I not 
> sure if some of the affects wanted (blur, glow, bevel, gradient glow, 
> gradient bevel) need to really do this. In CSS, gradients are painted in 
> the same painting order as background-image. So this is allowable.
> background: red linear-gradient(right, #0000ff, transparent);
> Here is a test that shows that opacity creates a new stacking context.
> http://css-class.com/test/temp/opacity-z-index.htm


Why do you believe that opacity create a new stacking context? To me it seems that the stacking was already there, it just becomes apparent because the opacity lets you see it.

> * Example 5 has a Microsoft propriety filter dropShadow applied that 
> comes close to the images that Rik has created. Unfortunately this type 
> of filter can not be blurred.

Yes, apart from the lack of blurring, this is exactly what I described.

> * Example 6 has another affect, where I have swapped positive=true for 
>positive=false.
> If some of the SVG affects can be used along side text-shadow and 
> box-shadow, we don't necessary always want to create a new stacking 
> context (well I wouldn't). For drop-shadow though, it makes sense. I 
> would like the format and syntax similar to box-shadow.
> drop-shadow: 20px 20px 10px (optional value for spread) <color>;
> I do believe that both masking and having the drop-shadow appear through 
> semi transparent backgrounds, border, etc should be allowed. Since the 
> box-shadow is in the wild, an optional keyword would help (without this 
> keyword, the initial value of shadow would be masked).
> drop-shadow: 20px 20px 10px (spread #) <color> cast;
> # I do believe that a negative value for spread should be allowed.

I think it's a little early to bring up specifics. However, I don't think we need a new keyword for just drop-shadows.
If we introduce a filter property, the syntax will look somewhat like:
Filter: drop-shadow(angle, distance, quality, color, inner), ...(optional other filters)

The filter will be applied after all other css properties such as text-shadow and box-shadow and will be calculated on the bitmap/framebuffer of its element.


> 1. <http://www.w3.org/2010/05/17-fx-minutes.html#item04>

Rik

Received on Sunday, 9 January 2011 23:23:37 UTC