See also: IRC log
<trackbot> Date: 02 May 2011
<scribe> ScribeNick: hober
shepazu: if someone defines a filter effect, but it doesn't exist or isn't supported, what should happen?
<ed> https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#FilterFunction
cabanier: if they don't exist they should be ignored
ed: we apply the null filter in
this case
... which makes elements transparent
... firefox, opera, webkit all make the element invisible
shepazu: this is very
unintuitive
... will follow up in email
ed: it would be nice if the element remained visible
shepazu: what if you have a set
of filters
... you support a b and c, and don't support d
... in a filter chain a b d c, what is the input into filter
c
... expects d to simply pass through the ouptput of b to c
ed: in the svg case, you can have
sub-parts that aren't supported; what should happen in such
cases is hard
... pass-through sounds fine to me
shepazu: also need to address
this to clip paths
... if there's nothing to apply, nothing should happen
<ed> feImage in firefox might be an example, supports raster images but not referencing other svg elements IIRC
shepazu: does anyone have
rationale to this behavior besides it's already how
implementations behave?
... I tried to apply some filter effects to a video
... regardless of if it applies the effect I still want the
video to be visible
... we should nip this in the bud now
... people won't use filters because of the very negative
effect
cabanier: having access to the background is more about blending, should go in possible future blending spec
<TabAtkins> ...dammit, I meant to be in the call. One sec.
cabanier: if we allow enable-background in filters, we then have more than one way of expressing the same thing
ed: describes example of wanting to blur a background while applying a fitler; background may be unusually large
shepazu: filter within a filter
with enable-background gets complicated really quickly
... we need to keep the filter spec simple
ed: we still have to deal with
backwards compat; there are some impls that do some of
this
... but there isn't much content on the open web that contains
this
pdengler: which implementations support this?
ed: batik, opera, both support
some of it
... adobe plugin had support for it
pdengler: would you deprecate it in opera?
ed: enable-background is still used in the compositing spec
shepazu: are you doing filters in IE? what happens now in IE9?
pdengler: IE9 ignores it
[questions about svg v. css compositing spec work]
TabAtkins: is identical to what's being specced in svg
pdengler: we're not changing svg filter spec
shepazu: svg filter spec is becoming *a* filter spec
pdengler: the importance is that we have a consistent model now, so that 2 or 5 years from now authors have consistent experience
ed: there are some tests, but not many
pdengler: if someone were to support enable-background when blending, would they break the future?
ed: blending in terms of
compositing or svg filters?
... don't know if you can get the same behavior between
enable-background in compositing v. svg filters
pdengler: there wouldn't be a collision
cabanier: in a css compositing
spec, should enable-background even be there
... if you have an animation, it's hard to implement that
performantly
ed: can we refer to the
compositing spec for the definition of enable-background?
... background-image and background-alpha are the only things
using enable-background property
... removing, we'd have to do something for existing content,
not sure what
<scribe> ACTION: ed to create test cases for background-image and background-alpha to see what current implementations do [recorded in http://www.w3.org/2011/05/02-fx-minutes.html#action01]
<trackbot> Created ACTION-31 - Create test cases for background-image and background-alpha to see what current implementations do [on Erik Dahlström - due 2011-05-09].
ed: cameron isn't here
anthony: next week i plan to make the fx 2d transforms updates
pdengler: question about integrating transform attribute v. property
shepazu: we've gone back and
forth on that
... from an authoring point of view, keeping them separate is
desirable
ed: cameron was objecting to
it
... haven't seen a proposal that addresses all of the issues
with making it a property; the dom issues, etc.
... might make it harder to promote other attributes to
properties for animating with css animations
... we should see if there are more detailed comments from
cameron on that
... we would have to change the fx transforms spec to reflect
that
... any updates on the animation work in the css group?
TabAtkins: nothing's
changed
... dean's been working on a better js api for animations
ed: that's not been checked in anywhere
TabAtkins: dean will move that along once he's fleshed out his experimental impl
pdengler: will there be an fx meeting in kyoto?
[discussion of when the overlap day will be in kyoto]
ed: we should know svg meeting
dates by thursday
... the intention is to cover fx material in overlap mtg; not
sure how many people doing the fx work will be there
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/shepazu/pdengler/ Succeeded: s/??:/pdengler:/ Succeeded: s/shepazu/pdengler/ Succeeded: s/??:/pdengler:/ Succeeded: s/??:/pdengler:/ Succeeded: s/??:/cabanier:/ Succeeded: s/??:/cabanier:/ Succeeded: s/will/might/ Found ScribeNick: hober Inferring Scribes: hober Default Present: Shepazu, hober, ed, +1.206.675.aaaa, anthony, rik, [Microsoft], +1.650.253.aabb, TabAtkins Present: Shepazu hober ed +1.206.675.aaaa anthony rik [Microsoft] +1.650.253.aabb TabAtkins Regrets: smfr chris Agenda: http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0059.html Found Date: 02 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/02-fx-minutes.html People with action items: ed WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]