CSS-SVG Task Force Teleconference -- 23 May 2011

<trackbot> Date: 23 May 2011

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

FX 2D transforms

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

Reusing filter functions as images in CSS

<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

Upcoming SVG F2F

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

- DRAFT -

CSS-SVG Task Force Teleconference

23 May 2011

Attendees

Contents

FX 2D transforms

Reusing filter functions as images in CSS

Upcoming SVG F2F

Summary of Action Items

Scribe.perl diagnostic output