See also: IRC log
<trackbot> Date: 23 May 2011
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
ED: let's try to figure out what
to do with the remaining actions
... since anthony won't be editing the spec for a while
... do we have other editors to take over these actions?
SF: dean, probably
<ed> http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransformsToDoList
SF: but I can do some edits too
ED: is there anything on the todo
list to discuss today?
... I'm personally interested in the optional arguments for
scale()
SF: I'm still kind of fuzzy on
the second todo, which is the role of this spec vs the css 2d
transforms spec
... just because I'd expect the CSS transforms spec to progress
faster
ED: you'd prefer to move this as a pure svg spec?
SF: I agree that a combined spec
is useful, just not sure whether we're ready for it yet
... as long as css doesn't do anything that's totally
incompatible with svg, then i can see we could have a css 2d
transforms spec first, and then later one we have only a single
canonical spec
... I'd like to hear from other implementers too, what should
happen
CM: what's the difference between
the two documents?
... apart from the open issues list?
DJ: my fear would be that there are lots of implementations of css 2d transforms, so it's possibly holding up progress by waiting for svg
CM: to me, as long as the issues are resolved to make css and svg transforms harmonised, I don't particularly mind if two separate specs exist for a bit longer
ED: we could still go for a joint spec for version 2
DJ: we could do it in CR
phase
... my point is that it doesn't seem worth risking delaying one
of them by merging them
... when they can easily reference each other at the moment
CM: I wonder whether it is worth having a separate spec just for the SVG side, maybe it should just be folded into SVG2?
DJ: I think that would reduce the impetus to implement the changes to the SVG side
ED: one of the things that would
concern me is the alignments that are made in the FX version
that have not been made in the CSS version
... where the css and svg transforms syntax differ
slightly
... I'm not sure all of the changes that have already been made
in the FX version have been made as comments against the CSS
version of the spec
DJ: that's right, but I don't remember right now which changes they were
SF: we can look them up
CM: is that the process, for us to comment on the css version to get the changes done?
SF: no, dean and I will work on
making those changes
... and any incompatibilities we find we'll raise them on the
list
CM: what's the current state of the css version of the spec?
DJ: I think it's only had 1 or 2
publications
... but the ED has significantly advanced
... I'd say it's almost worth moving to LC
ED: how many of those changes
that we've made already will get moved to a later
version?
... do you want to mention SVG in the CSS version at all?
DJ: it'd be hard to mention if we
don't explain how it works
... we could have a note that calls out to the FX spec
... but I do think it's worth us making -- if we satsify the
syntax changes in the FX spec, we should make sure they're
merged into the CSS spec now
... extra parameters on rotate? a few small ones.
CM: I think those changes should be done before LC
ED: the other thing is the
transform property vs attribute thing
... I guess the discussion is still useful, but
CM: I guess it's not as urgent
now
... but I will try to get a counter proposal for the transform
as property soon
[discussion about moving FX spec forward or not]
<scribe> ACTION: Erik to look for an editor for the FX version of the transforms spec [recorded in http://www.w3.org/2011/05/23-fx-minutes.html#action01]
<trackbot> Created ACTION-32 - Look for an editor for the FX version of the transforms spec [on Erik Dahlström - due 2011-05-30].
<ed> http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0089.html
DJ: I think the proposal that people seemed happy about was from Tab or Robert
<smfr> filter(image, list of filters)
<smfr> filter(url(foo.png), blur(10px))
SF: whereever you could use
image() in CSS
... maybe it should be filtered-image(), or something like
that
... we can work on the name
<TabAtkins> That was roc's, and yeah, I'm happy with that.
CM: does that give more expressiveness, since you can use filter(filter(...))?
DJ: the current proposal doesn't have different filter inputs
<TabAtkins> filter(filter(...), ...) is equivalent to just concatenating the two filter lists.
DJ: at the moment there's no way to create a circular dependency, which you can in svg filters
SF: then we can define how filters animate
ED: does that actually need a definition? if you use regular numerical types, would that just work with the current definitions in animations?
DJ: the transitions spec has a
definition for how things animate
... but the transforms spec defines there how transform
animates, so maybe the filters spec should define how the
filter property animates
<TabAtkins> Though, filter(cross-fade(filter(...), url()), ...) gets more complicated. ^_^
ED: I agree
<cabanier> Does this work with the image values spec?
DJ: it has to be a list where all the functions are the same
<TabAtkins> cabanier, yes.
<TabAtkins> cabanier, anything that works with/produces an <image> works nicely with Image Values.
<cabanier> filter(image(a.svg, a.png), blur(10px))
ED: one of the things I've
started thinking about is DOM access to those CSS syntax
things
... there was a bit of a discussion on the mailing list about
CSSOM and accessing the shorthand filter notations
... I guess CSSOM is not actively edited at the moment
<TabAtkins> Given the complexity of nested function syntax, I'd be okay with defining a <base-image> (produced by url() and image()), and making it so the image-manipulation functions only take <base-image>.
EO: when anne's back it should be edited
ED: should it be described there, and not in the filters spec?
<TabAtkins> And then letting SVG handle the more complex cases.
SF: I think once we have a CSSOM
API, the spec needs to defined the interface for these
filters
... but we don't have the API yet
... e.g. we also avoid creating new CSSValue things, since
CSSOM is in flux
DJ: we have a
CSSTransformValueList
... but we don't want to keep it
TabAtkins, that sounds like a good idea
ED: do we have an action for writing up this syntax?
DJ: Tab decided on the list that it should be in the Filters spec, so that can be an action on me
<scribe> ACTION: Dean to write up the filter() syntax [recorded in http://www.w3.org/2011/05/23-fx-minutes.html#action02]
<trackbot> Created ACTION-33 - Write up the filter() syntax [on Dean Jackson - due 2011-05-30].
ED: Among the shorthand filter
functions, we don't have the drop shadow one
... was that intentional?
<TabAtkins> If necessary, Dean can ping me. I should already have the right terms set up to hook into.
<TabAtkins> In other words, I probably dont' need an action.
DJ: with drop shadow, let's say
we do want to expose a way to do it directly in a filter
... we have to describe a whole bunch of options
... it has lots of parameters
... if you shadow an svg image, would it shadow only the
non-transparent part?
... the box that the image is in?
ED: for boxes, I'd assume
box-shadow is enough
... but for other things, you would filter based on the alpha
channel
SF: people in CSS have requested
drop shadow as well
... because they want to shadow an alpha image, or the fg
contents of an element
DJ: seems like people want it
<scribe> ACTION: Dean to add a drop shadow filter shorthand [recorded in http://www.w3.org/2011/05/23-fx-minutes.html#action03]
<trackbot> Created ACTION-34 - Add a drop shadow filter shorthand [on Dean Jackson - due 2011-05-30].
DJ: maybe you want a shadow based on what the colour in the images is?
SF: shorthands should be for
common cases
... we should just pick what we think is the most common
application, and define that as the shorthand
ED: hopefully we'll be able to
have some people from the FXTF attending
... covering FX related topics
... it's looking like we'll be having that meeting in the
Seattle area in late July
VH: would it be an SVG F2F first and then FX, or would it be combined/overlapped?
ED: I'd imagine they'd overlpa
CM: I imagined that we'd just
block out some time out of the week to work on FX stuff
... and FX/SVG people would all be there
... for the rest of the week we work on SVG only stuff, and FX
people can go home
ED: who might be able to attend?
VH: I would
DJ: someone from Apple will
ED: I'll try to get a proper agenda set up
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/.../ED:/ Succeeded: s/2d/css 2d/ Succeeded: s/merged in/merged into the CSS spec/ Found Scribe: Cameron Found ScribeNick: heycam Default Present: hober, heycam, ed, cabanier, smfr, dino, +1.408.536.aaaa Present: hober heycam ed cabanier smfr dino +1.408.536.aaaa Agenda: http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0096.html Found Date: 23 May 2011 Guessing minutes URL: http://www.w3.org/2011/05/23-fx-minutes.html People with action items: dean erik[End of scribe.perl diagnostic output]