Re: Filters on HTML question

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