W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2011

minutes, May 23 2011 FXTF telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Tue, 24 May 2011 08:57:02 +1200
To: public-fx@w3.org
Message-ID: <20110523205702.GA18297@wok.mcc.id.au>
(+1.408.536.aaaa = vhardy.)


      [1] http://www.w3.org/

                               - DRAFT -

                   CSS-SVG Task Force Teleconference

23 May 2011


      [2] http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0096.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/05/23-fx-irc


          hober, heycam, ed, cabanier, smfr, dino, +1.408.536.aaaa




     * [4]Topics
         1. [5]FX 2D transforms
         2. [6]Reusing filter functions as images in CSS
         3. [7]Upcoming SVG F2F
     * [8]Summary of Action Items

   <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


      [9] 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

   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

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

   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

   <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


     [11] 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

   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

   <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

   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

   <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

   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

   <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

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

   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

Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 23 May 2011 20:57:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:49:38 UTC