- From: Cameron McCormack <cam@mcc.id.au>
- Date: Tue, 24 May 2011 08:57:02 +1200
- To: public-fx@w3.org
http://www.w3.org/2011/05/23-fx-minutes.html
(+1.408.536.aaaa = vhardy.)
[1]W3C
[1] http://www.w3.org/
- DRAFT -
CSS-SVG Task Force Teleconference
23 May 2011
[2]Agenda
[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
Attendees
Present
hober, heycam, ed, cabanier, smfr, dino, +1.408.536.aaaa
Regrets
Chair
Cameron
Scribe
Cameron
Contents
* [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
<ed>
[9]http://www.w3.org/Graphics/SVG/WG/wiki/FX-Taskforce/2DTransformsT
oDoList
[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
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
[10]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>
[11]http://lists.w3.org/Archives/Public/public-fx/2011AprJun/0089.ht
ml
[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
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
[12]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
[13]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
--
Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 23 May 2011 20:57:36 UTC