W3C home > Mailing lists > Public > public-fx@w3.org > January to March 2011

Re: Filters on HTML question

From: Rik Cabanier <cabanier@gmail.com>
Date: Thu, 31 Mar 2011 15:23:12 -0700
Message-ID: <AANLkTikzX7tDXsjcMEXHSCjKTBnGhdymw41Ab-C+Ee++@mail.gmail.com>
To: Simon Fraser <smfr@me.com>
Cc: Dean Jackson <dino@apple.com>, Brad Kemper <brad.kemper@gmail.com>, Patrick Dengler <patd@microsoft.com>, "public-fx@w3.org" <public-fx@w3.org>
Dean's proposal defines the compositing order.
Would your proposal do the same by inferring it from the order in the CSS?

Rik

On Thu, Mar 31, 2011 at 3:05 PM, Simon Fraser <smfr@me.com> wrote:

> I find the filter: <source> <filter> syntax rather ugly.
>
> How about different properties?
>
> background-filter:
> border-filter:
> contents-filter: (or foreground-filter:)?
> filter:
>
> Simon
>
>
> On Mar 31, 2011, at 3:02 PM, Rik Cabanier wrote:
>
> Hi Dean,
>
> If people feel strongly that filters should apply to more than just the
> entire element, this sounds like a reasonable approach.
> I assume that the possible options are:
> - no selector =  take the content of the element and run a filter on it.
> This will be the first thing that is implemented.
> - background
> - border = the border of just this element, not the borders of the children
> - source = the element's content + all children.
>
> Rik
>
> On Wed, Mar 30, 2011 at 6:20 PM, Dean Jackson <dino@apple.com> wrote:
>
>>
>> On 31/03/2011, at 11:34 AM, Brad Kemper wrote:
>>
>> > On Mar 30, 2011, at 12:23 PM, Simon Fraser <smfr@me.com> wrote:
>> >
>> >> On Mar 30, 2011, at 12:05 PM, Brad Kemper wrote:
>> >>
>> >>> On Mar 30, 2011, at 11:13 AM, Simon Fraser <smfr@me.com> wrote:
>> >>>
>> >>>> I think we should avoid attempting to filter
>> background/border/content etc separately in the first pass.
>> >>>
>> >>> That was actually one of the things I was most looking forward to with
>> filters. I had made a presentation to the CSS working group a while back
>> about a proposed drop-shadow property that could act on just borders, just
>> backgrounds, just contents, or a combination of these as either individual
>> items or composited together. It was the same meeting where we discussed
>> filters for the first time (I think), and it was suggested that SVG filters
>> would be the best shot for that sort of thing.
>> >>>
>> >>> I think there is a lot of usefulness in being able to act on these
>> things separately or together.
>> >>
>> >> I agree, but I think we should postpone that until we've nailed the
>> filter syntax, and have a couple of implementations working.
>> >
>> > I dont mind having a phased approach to implementation, but it seems
>> prudent to consider it when designing the syntax. Then mark that part of it
>> as at-risk until the next level or something. That would likely be easier
>> than trying to tack it on later.
>>
>>
>> If we really want to go ahead with thinking syntax ahead of time, here's a
>> suggestion I have not thought through (i.e. I'd be surprised if it works,
>> nor have I spoken to anyone at Apple).
>>
>> Given that CSS filters are a list rather than a graph, we only really need
>> to specify the input to the first filter operation. So why not have shortcut
>> names for operations that filter the input element. For example:
>>
>> filter: border sepia() blur(5px);
>>
>> This would take only the border of the filtered element, apply the sepia
>> filter, then blur the result.
>>
>> NOTE: The result here would be that you'd only see the filtered output, so
>> only the border would show. If you want to show the element content + a
>> filtered border...
>>
>> filter: source, border sepia() blur(5px);
>>
>> This would composite the source element then the filtered border. But
>> wait, the source already contains the border, so you'd have to be careful
>> about transparency. This is the pain you will experience when using filters
>> (see below).
>>
>> ANOTHER NOTE: I used "source" in place of "none" from the original
>> proposal. It seems weird to explicitly specify something as "none" and have
>> it really do something.
>>
>> Another example:
>>
>> filter: background grayscale(), source;
>>
>> Takes the background of the element, makes it grayscale and then
>> composites the normal element over the top.
>>
>> One advantage of this syntax is that we don't need to fully bake it now.
>> It's just an addition to a more simple list of operations. In effect, the
>> inputs are filters themselves - just magic ones.
>>
>> BTW - as noted above, we'll probably need more than just "border". Like
>> SVG and its fill+stroke inputs people will want "content-without-border".
>>
>> Dean
>>
>>
>>
>
>
Received on Thursday, 31 March 2011 22:23:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 31 March 2011 22:23:49 GMT