Re: Filters on HTML question

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
>>
>>
>>
>
>