- From: Cameron McCormack <cam@mcc.id.au>
- Date: Thu, 03 Nov 2011 17:31:00 -0700
- To: FX Taskforce <public-fx@w3.org>
- CC: SVG public list <www-svg@w3.org>
Hello FXTF,
please find the minutes from today's F2F meeting at TPAC here:
http://www.w3.org/2011/11/03-fx-minutes.html
and below as text.
[1]W3C
[1] http://www.w3.org/
- DRAFT -
FX Taskforce at TPAC 2011
03 Nov 2011
See also: [2]IRC log
[2] http://www.w3.org/2011/11/03-fx-irc
Attendees
Present
Cameron_McCormack, Erik_Dahlstrom, Tab_Atkins, Doug_Schepers,
Jun_Fujisawa, Sylvain_Galinaeu, David_Baron, Simon_Fraser,
Dean_Jackson, Timothy_Horton, Shane_Stephens,
Cyril_Concolato, Satoru_Takagi, Jennifer_Yu, Chris_Lilley,
Rik_Cabanier_phone, Patrick_Dengler_phone,
Tavmjong_Bah_phone, Vincent_Hardy, Eli_Fidler, Johannes_Behr,
Eric_Mueller, Alan_Stearns
Regrets
Chair
Erik
Scribe
Cameron
Contents
* [3]Topics
1. [4]CSS Compositing
2. [5]clip-path and mask in HTML
3. [6]Transforms
4. [7]CSS Shaders
5. [8]Mesh gradients
6. [9]Filter effects
7. [10]Next F2F
8. [11]Presentation from Declarative 3D group
9. [12]CSS Animation
* [13]Summary of Action Items
_________________________________________________________
cabanier, you can call in now ^
<cabanier> thanks!
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
<cyril>
[14]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_T
PAC
[14]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
CSS Compositing
<vhardy>
[15]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
[15] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda
ED: we have SVG Compositing, which defines compositing modes for SVG
... some people have asked to have this apply to CSS/HTML
<smfr> agenda link again please?
ED: we dont' have a spec for that at the moment
... in Seattle we decided to investigate it
VH: there is an agreement to have a CSS Compositing spec that would
apply to CSS in general
... and the editors are Rik Cabanier and Alex Danilo
... but there is no draft yet
<cabanier> The phone connection is very bad
<dino>
[16]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_T
PAC
[16]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
CM: applying to both CSS and SVG?
VH: the plan was to take the SVG Compositing spec, fix it up, and
make it also apply to CSS
DJ: this is more of a meta question
<ed> [17]http://www.w3.org/Graphics/fx/track/actions/44
[17] http://www.w3.org/Graphics/fx/track/actions/44
DJ: for SVG Compositing, it seems like the editor was Anthony, who's
...
CC: replaced by me
DJ: do we have implementations of this anywhere?
VH: I think Abbra has it
CC: I think the examples in the spec were made with the Abbra player
DJ: there's lots in the spec that is not covered by this, but I'm
wondering if it's possible that most of the effects people will want
to do is covered by filters
... when we've talked to content developers who want compositing,
they just want e.g. "screen mode" that photoshop can do
... people rarely want to use the porter-duff modes
... so a filter, if there's enough power to do this, typically you
have one image and you want to combine it with another one, seems
like compositing is a heavyweight solution to a problem that I
haven't seen
... not that they don't exist, but not many people are asking to be
solved
... in the Compositing spec there's also stuff about clipping to
self etc., which makes it more difficult
... then there's the other interesting thing with the spec, browsers
now have hardware acceleration, and if you have to read from your
background, in many cases it's going to be hard to do that
... for performance, people will need to do compositing in very
isolated part of the tree, so that might be better achieved with a
filter
VH: even if you do it with filters you'll need background access
... you need something like the BackgroundImage in the filters spec
DJ: which is going to be a difficult thing to support now
... I'm not saying we should drop it, my question is whether people
wanting compositing will really want to composite with the page
background
VH: I've seen examples where artists turn on blend modes, e.g. add
or multiply, and the thing they add to the graph is a blend mode
... it's not like they have a predefined image
... I haven't seen them use porter-duff much, but artists use "add"
<cabanier> Looking at how people use compositing today in Flash and
PDF. it is a very commonly used algorithm.
CM: and you see them blend on to the background?
VH: yes
<cabanier> I agree that we don't see much point to PD
VH: they do this in flash too, where it's available
RC: I think it makes more sense in canvas, but a place like SVG or
HTML it doesn't really make much sense
... I thought there was a group that really wanted to see PD
<dbaron> If Porter-Duff were included, could "source" and "dest" be
spelled out rather than being src and dst?
<vhardy> For example: [18]http://fluid.nl/ (look at Space
Collective)
[18] http://fluid.nl/
DJ: what is the status of the spec?
VH: for SVG Compositing, we had Anthony and Alex being the editors
... not active lately
... we have editors who were willing to take on the work but had
limited bandwidth to do so
... so at the moment there's a statement of intent to move the spec
to CSS and move it along, but it's limited by people's bandwidth
CC: I can contribute to the editing of this spec, for sure
... I'd like to understand the problem with the background
... is it just enable-background?
DJ: setting it to new is good, but let me talk about how
apple/webkit composite
... you could say enable-background:new on an element, the childreno
f that element might be composed in separate textures on the gpu
... if you're trying to apply a filter effect on the whole thing,
you need to composite it back into one texture, then read it back
from the gpu
SF: imagine a div that has webgl under half of it, and something
else on the other half
... you have to flatten the webgl and the other thing into a
texture, then read it back
... the way our compositing algorithjm works right now is that if
something needs to be a gpu texture, it only needs to influence
things that are in front in z-order
... so this would add a requirement to look at ththings that are
behind it and put those in gpu textures too, and work out when to
flatten
CM: so difficult but not impossible?
DJ: it's not that everything is not on the gpu
... imagine you're trying to composite over a page element where
something is in webgl and another is filtered
... you've done this on the gpu to composite them together
RC: but that's just a webkit implementation
... you could do it with pixel shaders right?
DJ: it's possible
RC: in acrobat we have hardware acceleration where everything is
composited in the gpu, including blend modes and masks
VH: what about using blend modes instead of using shaders? it's more
limited in what you can do, but they don't require adding new
shaders and reading back stuff
... it's basically an alternate order to your source mode
SF: it's not impossible for us to do this, it's just hard
EF: on mobile we have severe constraints with the gpu
... so we can't put everything in a texture
... you would normally have one big base layer that is not in a
texture
... we've had a lot of people ask us for content developers to find
out which things are on the gpu automatically
... people have asked for control in that area, not sure what a good
way to do this is, or whether we should
VH: on the blend modes, are you saying that to use non src-over
blend modes you need to put the background in a texture?
EF: yes, and we can't do that due to resource constraints
CC: two issues, performance, and the use cases
... performance issue we could put restrictions, this number of
textures, that's one thing
... but we should see what are the use cases that could be
accommodated with these restrictions
... I hear also that PD might not be the best modes
... we have some use cases for PD
... I'm not fully up to date on them, but I can take an action to
provide more use cases on how they can be useful in SVG
... even if the scope is broader, it applies to HTML, keeping the
use cases for SVG is important
<scribe> ACTION: Cyril to provide use cases for blend modes
[recorded in
[19]http://www.w3.org/2011/11/03-fx-minutes.html#action01]
<trackbot> Sorry, couldn't find user - Cyril
VH: with PD, you never need to read background
... blend modes do need to, though
DB: if the PD modes don't interact with enable-background, what
defines what the background is that you're compositing against in
those modes
VH: In SVG terms it does rely on the notion of what the background
is, and there's enable-background property
CC: if you set enable-background:new, you forget what was on the bg
... and then later int he document that says comp-op:something, you
composite that thing with what's on the background between the
enable-background:new and now
DB: what if there's opacity?
VH: enable-background:new is like creating a new surface
DB: I know how that works with filter effects
VH: compositing operators are like shorthands for filter effects
DB: one other comment from a CSS perspective is that keywords tend
not to be abbreviated like "src" and "dst"
... at least they would be "source" and "dest"
DS: I think most people would understand
PL: I think those abbreviations are common in the graphics world
<vhardy>
[20]http://www.w3.org/TR/SVGCompositing/#enable-background-property
[20] http://www.w3.org/TR/SVGCompositing/#enable-background-property
SF: canvas has "source-atop"
DB: that feels more CSS-like
<smfr> canvas:
[21]http://www.whatwg.org/specs/web-apps/current-work/multipage/the-
canvas-element.html#compositing
[21]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#compositing
DB: but maybe I'm just used to it from canvas
DS: isn't this a similar problem to why SVG doesn't have z-index?
SF: doesn't SVG behave like every element is a stacking context?
VH: yes
... the model is any group, you render the group, then composite it
with the parent
CC: I think we need to first make sure this is implementable, even
on gpus and on mobile with reasonable performance
VH: I would say the implementability is not a question, because we
know filters are implemented
... and largely compositing is a shorthand for filters
... it might not be optimal and efficient though
CC: we might need to make changes to the spec to allow efficient
implementations
<cabanier> correct. and we know compositing is working well on
mobile devices since Flash is alreayd using it
<cabanier> on those platforms
SF: I don't know that adding properties is the way to do that, I
don't like it when specs have descriptions of resource limitations
<cabanier> enable-background is the one that might make things slow
SF: I'd like to avoid that if possible
<cabanier> but there are tricks to avoid it in most cases
VH: I think the way forward is that we need a converged spec, and we
already have an action to produce that
... the thing that has been questioned is PD rules
... coming back to the WG with use cases is good
... then the regular Rec track, see if you get implementations, and
if there are problems then it doesn't advance, it's a regular
process route
SF: I do agree that we need input from implementors, don't know when
we'll get that
CM: are the blend modes useless without being able to read the
background?
VH: yes
... you do too for src-over, since there's opacity, but that's
already supported
SF: I'm confused by enable-background
... it could use a better name
DB: who implements BackgroundImage?
<cabanier> Adobe calls it isolate group
ED: Opera, Batik, ASV, IE10
DB: I don't how they interact with other features, but that's a
separate conversation
<cabanier> an isolated group = background: false
VH: I think the CSS rendering context is different, how does that
work with stacking contexts
... SVG is pure painter's algorithm
<cabanier> non-isolated = enable-background: true
DB: if this were added to HTML, then enable-background would need to
force a stacking context
SF: it behaves like non-1 opacity
DB: transforms do the same thing
VH: enable-background is not simple
CC: on the question of implementability, it's difficult but
possible?
VH: Adobe has implemented gpu accelerated blend modes
... using pixel shaders
SF: I think HTML/CSS is more complex, we have video and WebGL which
makes it harder
DJ: video's a good example of not having access to those pixels
<cabanier> flash has it in hardware too but they don't have
enable-background
SF: to give an indication of how iOS is different, the rendering
model is complex and the final rendering is not done in the
application
... in your app you won't have access to video frames
<cabanier> that problem would apply to filters as well. They would
need access to the video pixels
SF: it may not have the ability to do filters etc.
VH: that means the issue you're facing is true for compositing but
also for filters
CC: we also need more reports from implementations, nailing down the
exact issues that might be impossible
VH: since the issue is really background access, I think this is
something we're going to hit pretty soon
... we have one data point from MS
... are the filters in IE10 supported on mobile?
JY: don't know
VH: it would be great data to know, for implementability, on mobile
JY: I could find out
<scribe> ACTION: Jen to find out whether filters with
enable-background are implemented on mobile [recorded in
[22]http://www.w3.org/2011/11/03-fx-minutes.html#action02]
<trackbot> Sorry, couldn't find user - Jen
SF: we might figure some of this out while we're doing Filter
implementations
VH: we will hit this with shaders as well
<scribe> ACTION: Vincent to look into implementability of blend
modes [recorded in
[23]http://www.w3.org/2011/11/03-fx-minutes.html#action03]
<trackbot> Created ACTION-54 - Look into implementability of blend
modes [on Vincent Hardy - due 2011-11-10].
CC: could we remove enable-background?
ED: that's one option
... we could split the parts we don't want out, or have two
conformance classes
SF: I hate conformance classes
VH: also blend modes, they need to composite with something
... in the filter you could say you don't have BackgroundImage, but
for compositing you need it
... for filters there are certainly things you can do without
BackgroundImage
ED: let's wait for feedback then
VH: what does Opera do for mobile?
ED: for mini, we render on the server
... but it sends a raster back
... for mobile, we do the same implementation as for desktop
... it does render filters, if the hardware is not good, it won't
have the best performance
... but it's the same code
CC: should we record the issues in the spec?
VH: yes, wouldn't hurt
<scribe> ACTION: Cyril to record implementability concerns in the
Compositing spec [recorded in
[24]http://www.w3.org/2011/11/03-fx-minutes.html#action04]
<trackbot> Sorry, couldn't find user - Cyril
clip-path and mask in HTML
ED: I had an action to make clip-path and mask apply to HTML content
... it's already implemented in Firefox
<smfr> [25]https://developer.mozilla.org/en/CSS/clip-path
[25] https://developer.mozilla.org/en/CSS/clip-path
<smfr> [26]https://developer.mozilla.org/en/CSS/mask
[26] https://developer.mozilla.org/en/CSS/mask
ED: my action was to move the definitions of those properties, and
make it work, to the Filters spec
... I don't think it's the right place to put it, but we already
have the wording we need for filters
... my question was, wouldn't it be a better match to put it in the
compositing spec instead?
CC: it's also an editing question for the SVG spec
ED: it's not something that's in the filter chapter currently
VH: would it be more natural to have a CSS Masking & Compositing
spec?
... it would be one more spec
... it's a different place in the rendering pipeline
CC: does WebKit support it?
SF: we have two mask properties
... one is equivalent to background-image, the other equivalent to
border-image
<cabanier> Webkit's mask is more of a softmask. It
<cabanier> is not a clip
AS: it's the luminance from the resulting image that is the mask
value
SF: my reaction to these two properties, re clip-path is similar to
CSS clip, which already take as rectangle
... it would be nice to do that without SVG
... giving the path in the property
... kind of ugly, but we might want that
... with mask, we found the need to do this 9-piece image thing
VH: is that in a spec?
SF: no
... in CSS it's odd when it interacts with overflow, it always hides
overflowing content because the mask never goes past the border box
<smfr> [27]http://www.webkit.org/blog/181/css-masks/
[27] http://www.webkit.org/blog/181/css-masks/
CC: would IE like it?
<smfr>
[28]https://developer.mozilla.org/en/CSS/-webkit-mask-box-image is
the border-image equivalent
[28] https://developer.mozilla.org/en/CSS/-webkit-mask-box-image
JY: seems like something that would be useful in general
... curious if people are asking for it though
SG: in the abstract, it sounds useful, use cases would be helpful
SF: one for masks is that webkit has this box-reflect, and part of
that is an image that gets used as a mask
... that's how you get the alpha dropoff in reflections
<cabanier> Very useful for us. We used it but it was very fragile.
SF: would be nice to provide enough properties that they could do
this themselves
DJ: typically with a gradient
ED: you could do it with filters, the thing that would be hard is
transforms
CC: how do we move forward on this?
ED: I have an action to put it into the Filters draft, but I think
it's the wrong place
VH: I vote for creating a new draft
SF: I don't care where it goes, but CSS clip should go along side
these things
VH: your point is to make these things work together
SF: I would like to see the properties converge
PL: that's why the CSS clip property took a rect() value
... so it could be extended later
<dbaron> Peter is suggesting clip: path(...) or similar
CM: I don't think people use clip and clip-path
... we could have them be aliases or something
ED: nobody uses the 'clip' property in SVG content, since it's
broken
JY: the definition changed between CSS20 and CSS21
<smfr>
[29]http://www.w3.org/TR/SVG/masking.html#OverflowAndClipProperties
[29] http://www.w3.org/TR/SVG/masking.html#OverflowAndClipProperties
<dbaron> DB: In CSS 'clip' only applies to absolutely positioned
elements
<dbaron> VH: In SVG it only applies to elements that establish a new
viewport (e.g., svg, image)
<vhardy>
[30]http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewpo
rts
[30]
http://www.w3.org/TR/SVG/coords.html#ElementsThatEstablishViewports
CM: we could have clip-path apply just to SVG content, extend clip
to be able to reference paths, have clip apply to both SVG and CSS
content, and say clip is the way forward
SF: we would need to extend clip so that it applies not just to SVG
viewport creating elemetns
... the other thing, for css, is to define how clip and masking
affect hit testing
... I forget if CSS clip makes elements transparent to hit testing?
DB: we don't define that properly, but it should affect hit testing
SF: is the same true of masking?
... we've talked about extending pointer-events to look at alpha
ED: in SVG, clip-path you do get clipping of events
... but for masks it's treated as a raster, and just a rectangle
<ed>
[31]http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
[31] http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty
CC: how would you specify the path in CSS? what units would you use
for coordinates? the SVG syntax for path doesn't have units.
TA: wonderful question. I would assume that non-united values would
work, and map into CSS pxs
... but also allow normal CSS units in there
SF: do you really want to have a path that has mixed units?
TA: maybe it's useful?
DB: there are plenty of existing things that are a bad idea
SG: let's add more!
SF: CSS rect() doesn't have units?
DB: it does
... mixing CSS units between different properties is a bad idea
already
... specifying one box's width in ems and aligining it with another
that's in px is not going to work
SF: so you're saying it's ok to allow mixed units in paths because
it's as bad as things already?
DB: pretty much
TA: you can do that in gradient definitions too
DB: I wouldn't want to forbid other units in a path
SG: there's a difference between mixing them, and using the same
unit across the whole path
TA: the problem is that, we could potentially say to use the same
units across the path
... that wouldn't be difficult, don't see a lot of use for it though
DB: I also think there are probably useful for different units in
paths
... esp with relative units
... one unit in one dimension, and another in the other
VH: or if you want to align things you've done on the page
SG: if you have relative units, and your path changes based on font
size, that's weird
... but could be interesting
VH: the pre-1.0 draft of SVG had units in there
... if you specified a stroke-width of 5px, that would be
non-scaling
CC: device pixels?
VH: yes
... and that was taken about
... we will have this in transforms, too
... so it might make sense to bring it up as a general issue
created [32]http://www.w3.org/Graphics/SVG/WG/track/issues/2428/
[32] http://www.w3.org/Graphics/SVG/WG/track/issues/2428/
(without the slash on the end)
VH: so we'd need to find editors for this
CC: do we want to resolve on creating a new spec?
RESOLUTION: We will put clip-path and mask in a separate joint FX
spec, and merge the clip/mask properties from CSS
DS: so currently you need to reference a clipPath element in SVG
... have we talked about relaxing that?
SF: I mentioned the desire to have a path directly in the CSS
DS: I meant more referencing an SVG <path>, rather than a <clipPath>
VH: I think we should
... it's the same problem with Exclusions
... we want to reference geometry
<scribe> ACTION: Erik to write up a spec for clip/mask in SVG/CSS
[recorded in
[33]http://www.w3.org/2011/11/03-fx-minutes.html#action05]
<trackbot> Created ACTION-55 - Write up a spec for clip/mask in
SVG/CSS [on Erik Dahlström - due 2011-11-10].
-- 15 minute break, return at 10:40 --
trackbot, bye
trackbot, list users
<trackbot> Sorry, heycam, I don't understand 'trackbot, list users'.
Please refer to [34]http://www.w3.org/2005/06/tracker/irc for help
[34] http://www.w3.org/2005/06/tracker/irc
trackbot, status
dom, are you able to add Jennifer Yu to tracker's list of FX people?
cabanier, just to reset the timer for people to call in in case they
want to, I'm going to hang up
cabanier, then you'll have to call back in (sorry)
<smfr>
[35]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_T
PAC
[35]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2011/Agenda#At_TPAC
Transforms
ED: first issue is unification of CSSMatrix/SVGMatrix
DJ: the general topic is that SVGMatrix has been around for a while,
but it only supports 2D transforms
... and CSSMatrix we found we needed to add a Matrix API for CSS
transforms, which supports 3D
... it's a bit unusual that there's two matrix classes
... recently there was a proposal to add an immutable matrix class
... people are doing lots of math in their JS code
... and copying these matrix objects around is making things slow
CL: so would you be able to instantiate a 3D matrix from a 2D one?
DJ: the main thing we're asking for is being able to do .scale(2)
and return a new object
... creating one from the other is not as big a deal
... the main issue is that matrix math in JS can be a performance
issue, so it would be nice if there were APIs that were native doing
this in the browser
... secondly, those APIs should be a mutable matrix, so that you
don't have to do lots of JSgarbage collection
DB: one thing that worries me, when you're proposing a mutable
matrix, you're adding new methods to the existing type? or a new
type?
DJ: we thought about this multiple times, never came up with a good
solution
... maybe translateInPlace(), but that looks terrible
... so not sure
SF: the other way to spin this, if we're inventing a new matrix
class to be shared across SVG/CSS we want that class to allow
mutability
... not extending existing APIs, but adding a new one
DB: one thing abotu mutability and copying, depending on what the
APIs are that return them, you might need more copying at the
beginning
... since you can't return the same thing twice
... I don't know if that matters
... depends what the APIs that return a matrix are
... with immutable matrices, you can return new ones
CM: you don't have to still write to SVGMatrix's a, b, c, etc.
... even if the methods return new objects
... so I think implementations don't have that optimization atm
SF: I think the issues are, do we want a new matrix class, where is
it specified, does it expose 3d and 3d?
trackbot, status
DJ: mutable and immutable on the same object?
trackbot, status?
CL: that would allow avoiding serialising/reparsing
trackbot, bye
trackbot, status?
DJ: we should design it with the idea that it could be used in
shader?
CL: the declarative 3D people want to come up with new JS types for
matrix etc.
... is there a concrete proposal?
DJ: there's one in the stage of going from liquid to solid
... there's been a message on the webapps mailing list
SF: a question for implementors who implemented CSSMatrix
ED: opera does
SG: we have
ED: but you can't construct those objects
SF: is the IE implementation exposed to JS?
SG: yes
SF: prefixed?
SG: yes
SF: so this would be an evoluation of the CSSMatrix?
DJ: yes
<scribe> ACTION: Dean to propose a unified Matrix for SVG/CSS
[recorded in
[36]http://www.w3.org/2011/11/03-fx-minutes.html#action06]
<trackbot> Created ACTION-56 - Propose a unified Matrix for SVG/CSS
[on Dean Jackson - due 2011-11-10].
ACTION-56?
<trackbot> ACTION-56 -- Dean Jackson to propose a unified Matrix for
SVG/CSS -- due 2011-11-10 -- OPEN
<trackbot> [37]http://www.w3.org/Graphics/fx/track/actions/56
[37] http://www.w3.org/Graphics/fx/track/actions/56
edited the action
DJ: the other part of the issue is the unification
... now if you want to add 3D transforms to SVG, what do we return?
... given the SVG spec for 10 years has said element.transform you
can get an SVGMatrix in there
... with this combined transform spec, we have 3D transforms
CM: so whether we should double up on the memory overflow methods on
a unified matrix?
VH: so let's have this as an issue to resolve in the spec
DJ: so this is a bit of a hack, becayes in the 2D spec we define
CSSMatrix
... and in the 3D spec we define CSSMatrix
... and they're different
... the 3D only adds
... it would be nice if we could come up with an API that does not
break SVG content when an implementation starts supporting 3D
... and without doing something like having rules like "if it's a 2d
transform, return an SVGMatrix"
JY: aren't we rehashing the SVG DOM anyway?
DS: yes
CM: we might break some existing stuff
... not sure
ED: I don't think the risk is that high
CM: there's a,b,c,d,e,f and m00, etc.
DJ: the former are on both SVGMatrix and CSSMatrix, the latter are
only on CSSMatrix
CM: I assume then we're not going to get rid of a,b,c etc.
DJ: no
VH: I think this is tractable
... the two fields map to the same values
CM: it's not a huge deal to keep both set of methods either
VH: the Tiny DOM has mutable versions of methods
ED: yes
VH: I took an action at the last FX meeting to maek a draft of the
merged spec
... under the dev repository there's a transforms spec
<ed> [38]http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix
[38] http://www.w3.org/TR/SVGTiny12/svgudom.html#svg__SVGMatrix
<vhardy> [39]http://dev.w3.org/csswg/css3-transforms/
[39] http://dev.w3.org/csswg/css3-transforms/
VH: so that spec is just 2D transforms, trying to converge with SVG
... I will try to get that spec to be a merged 2D SVG/CSS spec first
... then worry about 3D later
... that's the only update I had
DJ: do we want to publish what we have?
SG: we have these two specs on CSS, and having them at the same
time, is a bit weird
SF: I think we also resolved to publish newer WDs of CSS 2D
transforms
... but I agree with SG that we should cut over at the same time to
the merged spec
<scribe> ACTION: Vincent to make clear in the merged transforms spec
that it hasn't yet replaced the separate specs [recorded in
[40]http://www.w3.org/2011/11/03-fx-minutes.html#action07]
<trackbot> Created ACTION-57 - Make clear in the merged transforms
spec that it hasn't yet replaced the separate specs [on Vincent
Hardy - due 2011-11-10].
[ discussion of which/whether/when CSS and merged transforms specs
get published ]
[ concern about 3D holding 2D merged spec back ]
<dbaron> 3D transforms should be in Firefox 10, assuming nothing bad
comes up. Firefox 10 expected to ship January 31, per
[41]http://en.wikipedia.org/wiki/History_of_Firefox#Expected_Release
_Dates
[41]
http://en.wikipedia.org/wiki/History_of_Firefox#Expected_Release_Dates
RESOLUTION: We will publish a merged SVG/CSS/2D/3D spec as WD, and
republish CSS 2D and 3D with a note about the merged spec
ED: who will do the merging of 3D?
VH: Simon, Dean and myself
s/CSS 2D and 3D/CSS 2D and CSS 3D/
RESOLUTION: We will republish the SVG Transforms module to obsolete
it.
<scribe> ACTION: Cyril to prepare SVG Transforms module for
obsolescence. [recorded in
[42]http://www.w3.org/2011/11/03-fx-minutes.html#action08]
<trackbot> Created ACTION-58 - Prepare SVG Transforms module for
obsolescence. [on Cyril Concolato - due 2011-11-10].
CSS Shaders
VH: I can show a demo
[ Vincent shows a demo/presentation of CSS shaders ]
CC: so you having picking there?
VH: no
CL: that's going to be confusing, and limiting
VH: we're working on that issue
... let's get back to that issue later
[ demo continues ]
trackbot, status?
trackbot, bye
trackbot, status?
[ issue brought up relating to animation of particular parameters to
shaders, and how that is a general problem with css animations,
since you have to repeat the whole list of un-animated params too ]
VH: summary of where we stand
... the patch is available
... the main issue we've had is the shader language requirement
... there have been security concerns expressed
... and questions on filter margins
... and pointer events handling
... for the shader language, it's a key decision
... agreeing on one thing will allow content to have just one shader
... otherwise we'll end up in the same situation than audio/video
... which is actually worse, since we're talking about code
... people will need to write shading code twice
... unless there's a way to transcode
... that's a requirement, and orthogonal to the one we picked
... there are only so many solutions here
... we pick an existing shading language or we invent a new one
... maybe a better language comes up in the future
... at adobe we have pixel bender, another shading language
<shepazu> [43]http://xkcd.com/927/
[43] http://xkcd.com/927/
VH: which would be suitable for this, but we're not proposing it,
because we think it's hard to get adoption for it
... and it'd cause fragmentation
DJ: I also think there's something to be said about choosing a
language that's defined as an "open standard", whatever you define
that as
... something people can participate in
SF: I think there's also a benefit from choosing a language there's
existing content for
DS: something that's used commonly in open source
DJ: the other big thing is WebGL, speaking for GLSL as a shading
language
VH: the current draft recommends we converge on GLSL
... the question is to allow other languages, and have a type
attribute to select
<pdengler> Isn't there a method by which we could delivery a model
where the language is not defined, much like the codec model for
Video?
VH: like <script> in HTML
... HTML5 requires image formats
DS: no
TA: there was no need to
DS: the codec model for HTML is suboptimal
TA: it's horrible, the only reason is because we couldn't agree on
codec
SG: what makes you think we can agree on this?
CL: you end up with a bunch of switching, "if i'm on this browser
then do this, otherwise do this"
VH: it's a bit different from audio/video, since it's not just
transcoding content
CL: can we compile these shaders down to something else?
VH: there are precedents for this
... there was AGAL at adobe
... which allowed GLSL and HLSL to compile down to it
DS: would that inhibit looking at the source?
... because there's power on view-source
VH: so it's view source on the assembly
CL: I'm not asking can we pick another shader language, rather can
we compile GLSL down to another language
Johannes Behr from decl 3d
JB: google had a a project ANGLE, which compiles GLSL to HLSL
... people have solved this problem
PD: I want to think about it more
... I will talk to some folks on my side about that
DS: I want to make sure we have that view source
CM: I agree view source is important here
VH: ANGLE is a great point
... chrome has this built in, that's the way they implement WebGL on
windows
... that would be an argument for standardising GLSL
... because you could convert in your implementation to HLSL
CM: are there any issues with this?
<cabanier> the acronym is AGAL
<TabAtkins_> cyril: The word is "wonks".
cabanier, AGAL is the adobe thing, ANGLE is the chrome thing
<cabanier>
[44]http://www.adobe.com/devnet/flashplayer/articles/what-is-agal.ht
ml
[44]
http://www.adobe.com/devnet/flashplayer/articles/what-is-agal.html
<TabAtkins_> cyril: And it translates roughly to "geeks".
VH: to move forward on this, with the chrome proposal, let's move
forward on GLSL. and then ask if we have room for alternative
proposals.
... it's similar to scripting, images
... a baseline that everyone has
CL: I'd rather not see that in the first version, it adds
uncertainty
... it also means not each language will have the same level of
review, etc.
<shans> [45]http://code.google.com/p/angleproject/
[45] http://code.google.com/p/angleproject/
JV: what's nice about glsl is that Khronos is really interested in
solving the security issues
DJ: we support mandating GLSL for OpenGL ES 2.0
CL: and the reason for that specific one is that it's more secure
DJ: also it's the version for embedded systems
CL: so performant on mobile
DJ: it's not a functional limitation
... maybe in some extreme shaders
<shepazu> ("wonks" means "people who have very deep, specialized
knowledge, and who spend a lot of time tweaking things in a very
fine-grained manner")
VH: I'll cover the security concerns
ED: should we have a vote?
CM: a poll?
VH: three options
... one, GLSL only
... two, GLSL required and allow other languages
... three, don't mandate any particular languages
CL: even if we go for the first option, we should allow specifying
another language
<pdengler> three
CL: this is just a strawpoll
ED: so that's 14 for option one
... 1 for option two
... 1 for option three
DS: option two does give us the future proofing thing
CL: the way I was arguing it was that option one also does
... in PNG there's a byte that allows specifying which compression
method is used
... but there's only one value allowed
... but it's there to possibly extend in the future
VH: on the security concerns
... I wanted to recap what's been raised
... in general, with WebGL and shaders, there have been 3 concerns
... one, DoS
... hogging the GPU
... two, timing attacks
... three, memory overflows
... which doesn't actually pertain to css shaders, more about WebGL
APIs, which has been taken care of in the spec
... those three things are being dealt with for WebGL
... a company did a PoC for timing attacks
... the WebGL group has been tightening up the spec to respond to
these
... all these issues are being resolved for WebGL
... DoS is being dealt with at the driver or OS level
... the system has a way to detect if the gpu is hogged, so that the
application can be informed and be able to kill the context
... there's work being done with gpu vendors to build this in to
hardware
... timing attacks, webgl is addressing this with cors
... so you won't be able to process images from other domains unless
you use CORS to allow this
... let me talk a bit about timing attack
s/attack/attacks/
scribe: basically, the crux of a timing attack is that there's come
content I can't get my hand on
... and rendering it on the page
... browsers have prevented me from getting to pixel values in the
content
... but one thing I can do is measure how long the content takes to
get rendered
<cyril> see [46]http://www.contextis.co.uk/resources/blog/webgl/
[46] http://www.contextis.co.uk/resources/blog/webgl/
scribe: very simple example, if I have an image that has no colour
... just translucent pixels
... and I know my browser renders that really fast
... but another image with all opaque pixels is slower
... and let's say your bank has an image that is either translucent
or green, representing whether hte password typed in is correct
... I can time how long it takes to render that piece of content,
infer whether the image was translucent or green, and thereby
determine the password
... shaders help that kind of attack, since they can influence the
time of rendering
... based on the pixel values, you can make it longer for some
values and shorter for other values
... you can do that individually for each pixel values
... so you can determine the pixel values without being able to get
to them directly in the dom
... in WebGL the PoC showed that you get fuzzy results, and it takes
time, but the underlying threat is there
... one thing to understand is that shaders will make this worse,
but the problem exists regardless of shaders
... with a general iframe, you could start inferring what's in the
iframe just based on rendering time
... maybe that's low bandwidth enough not to get information out
quickly enough
... possible solutions, one is to say use CORS
... so anything you render, if it's cross domain, you'll get a blank
image
... I think this is what the WebGL group is doing to address this
attack
... in WebGL you can do the attack by getting the time just before
the shader runs and just after the shader runs, so that's a pretty
precise time measurement
... but for general content you'd need to use requestAnimationFrame
or something similar, and that's less precise
... so implementations needs to be careful in general with
setTimeout and requestAnimationFrame
... information can be leaked there
... I talked to our security experts on the Flash platform, the
parallel they drew was something happening on the network
... if you're on a webpage, broadcasting network addresses to
everything on the network
... if you get immediate failure, you know that IP address is on the
network
... the way to address this is inserting timeouts that happen no
matter what
... the failure would come sooner or later
... so they were similarly using time
... their solution was to hide the time by adding extra noise to it
... might be other options, haven't heard them so far
TA: in general the last requirement is impossible, since browser
have to be cryptographically secure
... basically impossible for rendering I assume
... but we do need to handle timing attacks somehow
VH: my suggestion would be to go for the CORS solution
... and sync up with the webapps group
TA: I'm confused how CORS helps here
... in other cases, with canvas, you're explicitly saying to render
this image/video to the canvas
... with shaders, you need to say "hey webpage, is anything in the
page cross origin"?
VH: it's the same problem with SVG painting to canvas
... atm we taint unconditionally
... but we'd like to know if any cross origin resources are used
SF: if we add compositing, that also lets you get information below
the element
... so you need to worry about the whole document
TA: we already have simple things, like being able to detect
:visited state
... a timing channel attack is very viable on that
... in less than a second
VH: getting computed style?
TA: no, using timing channel attacks
... you can extra 5-10 bits of data per second on that
... if you're just using the rendered layer
... we already hide information from the DOM
... so we already need to be handing a modified layer to the shader
beforehand
... at that point, blanking out iframes might not be as big of a
deal
... since we already have to be handing things different from what's
being rendered on the screen
VH: in the shader you can get that information, but then how do you
get that information back to the site?
TA: that's the timing channel
... the :visited thing itself will require changes to the layer we
hand to css shaders
SF: we've been disussing similar issues with the desire to draw
arbitrary elements into the canvas
VH: I think it's the same issue
SF: hiding iframes, links, is like playing whackamole
... there are unknown pieces of privacy data we need to hit on the
head
... adam is worried about this whackamole approach
VH: where can we discuss these issues?
... webapps?
SF: we should get adam barth in here
VH: there's no resolution we can take right now on security
DJ: the things we can decide/discuss now is, whether to combine css
shaders into the filters spec
... tab disagreed
... for two reasons, and this was one of the reasons
... the question is, now that we've talked it through, css shaders
makes this problem worse, is it enough to say it shouldn't be
included in the spec?
TA: I don't think there's a necessity to have them in the same spec
... the fact that i'm pretty sure this will slow down shaders
CM: slow down filters you mean?
TA: I believe that filters has feCmponentTransform
... I think the rate at which you could extract data is lower than
this
... if you're getting only a bit a second, that drops it into the
probably not a concern bucket
SF: because filters will be implemented in software?
TA: no, but you can't do such dramatic changes to timing
VH: let's get adam barth here
DJ: adam is not here today
VH: let's get him on a call
... the next issue is filter margins
... this has been discussed on filter effects in general
... there's no margins in svg
... there's filter regions
... people either get it wrong, and are unhappy with what they get,
or they don't bother and set it to the entire viewport
... and then implementations need to second guess the region
ED: yes, if you don't optimize it
VH: with a lot of filters you can compute the filter region
automatically
... we found with shaders that it's not possible to compute the
filter region properly for trivial shaders
... with vertex shaders, it's hard to know what the user wants
... when you try to compute ti, then animate it, you can optimize
that kind of problem but then your filter region changes over time
... we found it more efficient that you specify the array you need
CM: why won't this have the same problems as with SVG specified
regions?
VH: I feel margins is already a better way to talk about it in CSS,
since margins are additional offsets on the box
... for documentation on shaders, I'd expect it to say how to
compute the margins
... also I don't have any good suggestions about how to compute
margins automatically
... we discussed this on the list, an exchange with Dirk, I
explained how SVG filter margins work, but he hasn't responded
CL: I had initially agreed with Dirk but now I agree with you
SF: your proposal is that the author specifies the filter margin
VH: yes
... there's a note in the spec to say that if the way you can
compute the filter margin...
SF: but you can't do that without running the shader
VH: and you need to know the size of the surface
... so right now we have margins, but if we find a better way we
will specify that
... so the shader margins default to -10%,-10%,120%,120%, i.e. the
same as svg filter regions
... one final issue is pointer events and picking
... don't have a lot to say there
... I think we all agree that it's desirable you can do proper
selection and interactivity on shaded content
... some ideas have been bounced around, it's non trivial
CL: you get projections which are noninvertable
VH: yes, that
... you need an inverse from what the shader does
... in the rendering pipeline you can't get the output of the vertex
shader
CM: could you allow the author to specify a mapping back to user
coordinate space?
TB: yes, we allow the author to specify a shader to reverse the
transformation
... if you are interested in precise picking positions
VH: it does the inverse transform?
TB: no, the buffer will contain final coordinates encoded as colours
... and then you read back the buffer
... not as part of the webpage
DJ: it's not the inverse transform?
TB: no
DJ: we want to know where the input was
TB: you just look up the position
DJ: ok so it is the transform then
EF: you would frequently have to do this
TB: with modern gpus, the second option is to do it on the cpu
VH: the picking buffer, I didn't completely get it, are there docs?
TB: use
SF: why not just let JS do it?
s/TB/DB/
s/TB/DB/
s/TB/DB/
[ various TBs in this recent issue discussion should be DBs ]
VH: so one thing I can do short term is to add those options/ideas
to the draft
... I think that's all we had
... there was a proposal on the list, Charles brought up the idea of
a JS based shading language
<ed>
[47]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0052.ht
ml
[47]
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0052.html
VH: I think Dean responded saying that it's too early to do this
... I've talked to people internally, who think it's a bad idea
... they told me there were reasons to use a C-like language
... typing is important in the shader
... we've moved all the issues to the bugzilla
... I just want to know what the next step for the document is
... it's an editor's draft now
... if we keep it as a separate editor's draft, we need a space to
put it
... since it's not an "official" editor's draft
... my preference is to merge it into the next Filters WD
CM: I would rather have them separate
... shaders could slow down the progress of Filters
VH: the shader implementation is actually simpler than Filters
TA: but we already have filter implementations
CL: we have many existing mature filters implementations
... however, even if we decide not to merge them, I would like to
have a FPWD of it
VH: yes, I'd be happy with either agreeing to merge it and include
it in the next WD
... or to publish it as a separate FPWD
TA: there's no downside to having it as a separate draft
DJ: I don't have any technical reason
... the reason I like it is that Filters already had a feCustom
... it has a suggestion of this element
... this is fleshing out that bit
... it really is part of filters
... it sends a clear message that you can use this technology to do
this kind of effect
TA: I understand the aesthetic concerns, but it's not a bad thing to
split out and have small specs
... especially when they have different maturity levels
... we've solved filters with svg
... there are minor issues
... but it's mostly a solved spec
[ Any "DB" in the shaders discussion is really "JB". ]
DS: are there issues that are common to both, and which will be
solved when we think about them for shaders?
DJ: pointer events
<ChrisL> [and JB is Johannes Behr , chair of the Declarative 3D for
the Web Architecture Community Group]
<ChrisL> [48]http://www.w3.org/community/declarative3d/ ]
[48] http://www.w3.org/community/declarative3d/
VH: I think Dean and I's preference is to keep a single spec
CM: I don't object to having them in a single spec
TB: it's my preference to being split out, I won't object to them
being in the same spec
DJ: we haven't even published the first draft of the filters spec
RESOLUTION: We will add CSS Shaders into the Filter Effects spec.
ED: do we still want to publish the Filter Effects draft without it
first?
VH: I say both at the same time
RESOLUTION: We will publish the Filter Effects draft once CSS
Shaders has been added.
<scribe> ACTION: Vincent to add CSS Shaders to the Filter Effects
spec and ready it for publishing. [recorded in
[49]http://www.w3.org/2011/11/03-fx-minutes.html#action09]
<trackbot> Created ACTION-59 - Add CSS Shaders to the Filter Effects
spec and ready it for publishing. [on Vincent Hardy - due
2011-11-10].
VH: So we will keep the issue of shader language flagged in the spec
first, but not resolved yet.
<scribe> ACTION: Vincent to get security experts to talk with the FX
group about CSS Shaders security issues [recorded in
[50]http://www.w3.org/2011/11/03-fx-minutes.html#action10]
<trackbot> Created ACTION-60 - Get security experts to talk with the
FX group about CSS Shaders security issues [on Vincent Hardy - due
2011-11-10].
-- Lunch, we will resume at 2pm --
Mesh gradients
ED: we're doing mesh gradients as one of the new features for SVG2
... I think the point of bringing this up in the FX meeting was to
see if there was interest with using that, or having that in a CSS
syntax
... I wanted to give Tav the opportunity to present what he's done
in Inkscape
<Tavmjong>
[51]http://tavmjong.free.fr/SVG/SVGOpen2011/MESH/svg_2011_mesh.svg
[51] http://tavmjong.free.fr/SVG/SVGOpen2011/MESH/svg_2011_mesh.svg
[ Tav presents his gradient mesh work ]
[ Proposed SVG syntax:
[52]http://tavmjong.free.fr/SVG/SVGOpen2011/MESH/svg_2011_mesh.svg#1
4_0 ]
[52]
http://tavmjong.free.fr/SVG/SVGOpen2011/MESH/svg_2011_mesh.svg#14_0
SF: question on implementation
... how expensive is it to render these?
... existing gradients are fairly expensive to repaint already
... seems like this would be more expensive to paint
CL: these are implemented in Inkscape
... an editor has to deal with redraw issues
... do you have noticeable redraw lags?
TB: not really, if you zoom way in and move them quickly there is
some lag
CM: this is already required for PDFs
SF: but PDFs aren't performance critical
<cabanier> if you go the GPU route, they are easy to draw.
SF: CoreGraphics does not support this
... so we'd need to impleement this ourselves
<cabanier> you could possibly do it with CSS shaders...
SF: I'm not against them, just saying there may be performance
considerations
JY: how useful would it be for CSS?
in SVG you have non-square shapes everywhere
scribe: seems like it would be less valuable for HTML
<ChrisL> if it was found useful to use these in CSS I would suggest
a url() reference to some svg, rather thant eh @-rule-from-hell
approach
Filter effects
ED: to go through a few of the issues that came up on the mailing
list
<ed>
[53]http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0031.ht
ml
[53]
http://lists.w3.org/Archives/Public/public-fx/2011OctDec/0031.html
ED: the list of shorthand filters, we keep that in?
... this isn't adding anything, but just raising some issues
DJ: there were two issues
... one is that an apple engineer pointed out greyscale is the same
as saturation
... with the exception that saturation could go beyond 100%
... the good thing about greyscale is anyone can understand what it
does
... are we ok keeping something that is effectively a duplicate?
DS: I think it's fine
... people will look for it
ED: I think so too
CM: I think greyscale is going to be the kind of saturation most
people want to use anyway
DJ: next, sharpen
... we had feedback suggesting that in most cases, thinking about
what's the use case for a sharpening filter
... it'll be people with digital photography wanting to make it look
better
... it's not likely people will want to put unprocessed
photographics on a webpage
... the sharpen effect in the filter spec isn't what anyone wants to
use
... all these tools have a custom sharpening filter that is a lot
more complicated than what's there
... so the suggestion is just to remove it
CL: that's a bit sad, there are many people who would be happy with
sharpen as it is
... using an image at different sizes, and being able to sharpen it
... for the smaller one you want to sharpen it a bit
DJ: the feedback was you could still use CSS Shaders to do this
... the question is, even the phones nowadays have some image
processing on them
... uploading the raw image is becoming less common
DS: rather than argue about this now, that we simply put this in the
court of public opinion?
... I would say, drop it for now, and if we want it later add it
... identify use cases for what this thing can do
SF: a good way to approach this is that css filters should allow you
to do two types of things
... one is to animate something, do some kind of transition to make
things pretty
... second, they should allow you to reduce the number of image
assets you have
... something like sharpen, which you want to do permanently once,
should have already been done
... before uploading
... that'd be my reasoning to be able to to this
DS: there are some tools that allow this
SF: but not to save the output of the filtered output
... maybe canvas.drawElement will allow us to do that
DS: mark it at risk?
DJ: ok
RESOLUTION: We will mark sharpen shorthand and feSharpen as at risk.
... We will keep greyscale shorthand.
DJ: many of these shorthands take the first parameter as amount
... 0 = no effect, 1 = full effect
... would it be better to accept percentage values as well?
... 100% greyscale makes more sense to some people than 1
SF: accepting both fractions and percentages?
... we talked about this in the context of crossfade
TA: I'm in favour of this
VH: unitless is a normalised value?
DJ: we should clamp
... this spec needs to change to be more like what image values
says, which defines a grammar for each thing, instead of text prose
... the question about parsing is something we've come up against in
implementation
<cyril> the term shorthand is not used consistently in the spec
DJ: when taking multiple parameters, should it be invalid if we put
commas?
<cyril> sometimes it's filter function sometimes shorthand
DJ: I like the idea of CSS being very permissive, otoh I don't like
it if they've accidentally made an error then it's hard to
understand the result
... might be a good thing, stylistically, to know what happened when
something when wrong
TA: fail quickly and as tinily as possible
DJ: at the moment we fail for things with commas in them
... so if you put gamma(1,1,1) the whole property would fail
... CSS Shaders has a comma separated parameter list
... so that's a bit different
TA: that one has constraints on it, the syntax is sufficiently
complex to warrant commas
RESOLUTION: We will accept percentages for 0..1 values in
shorthands.
... We will have the shorthand properties fail to parse if using
commas where not allowed, etc.
DJ: I'll update the spec to be less prose, have a defined grammar.
CC: can you also add a definition of shorthand?
... sometimes it's called filter function, sometimes called
shorthand
CM: shorthand means something else in CSS
DJ: that's all on the filter functions
ED: a couple of people have been requesting ...
DJ: currently you can't transform the filter in any way, do a blur
then scale it by 1.5 for example
... the proposal is to add a filter function and element,
feTransform
DS: Anthony Grasso proposed something similar a couple of years ago
at SVG Open
... one would be to do the filter reflection effect
<cyril>
[54]http://lists.w3.org/Archives/Public/public-fx/2011JulSep/0082.ht
ml
[54]
http://lists.w3.org/Archives/Public/public-fx/2011JulSep/0082.html
DS: I was wondering if it made sense instead of feTransform, but to
put a transform on a particular filter
CL: it doesn't fit into the node filter model as nicely
... if we were to add feTransform, you'd need to decide what happens
when you get pixels that aren't covered
DJ: in CSS Shaders there's a similar issue
... you need to define what happens outside the mesh
CL: is the shader writer required to cope with that?
DJ: no
... in GL you define this as part of the state you set u
s/set u/set up/
scribe: the texture either repeats, clamps
... the feTransform is an operation on its input and it produces a
new output
... that allows it to sit in the filter function list
CC: what kind of transform?
DJ: only 2D affine transforms
CC: coudl it be an extension to the feDisplacementMap
s/coudl/could/
CL: it's simpler to say scale(2,0.5) than to work out what the RGB
image should be for feDisplacementMap
... feDisplacementMap is still useful for non-affine
EF: you get people trying to do perspective transforms
CL: why restrict it to affine?
... especially if we're adding non-affine in SVG2?
... if people can do it in one place they'll expect to do it in
another
DJ: can't think of a good reason why not
CL: picking the SVG 1 transform set is a good start, but if SVG2 is
extending that to include non-affine...
... if you have it there, you'd want it in the filter as well
DJ: it should just take a transform
CL: it'll just point to the Transforms chapter, ok
... do we need to say anything about resampling?
DJ: we should say something in the filters spec in general
CL: we have some talk about resampling for raster images in the spec
DJ: when we merge shaders and filters it should be a separate
section that covers both
VH: there is an open issue on that
... we need a way to specify the interpolation method when scaling
up and scaling down
DJ: this addresses Dirk's request from January
... doesn't address perspective transforms
... the other part of the proposal in my email was that when you do
a filter effect, you don't necessarily want to replace the element
you're drawing
... but to blend with it
... with the canned filter effects it's not as easy to blend
... so maybe we should have a keyword that allows you to composite
the element with its filtered result
... the question is, whether doing something like that a common
enough use case that we want it to canned effects
... or complicated enough to leave it to the markup version of
filters
TA: I think it's an easy and ocmmon use case
DJ: I was proposing two keywords, composite-over and composite-under
... you would use that anywhere in the list
... (which would be a bit strange)
... not sure it's a good idea, but I made the proposal
... composite-under right at the end would be like doing an feMerge
with all the others, and merging it with SourceGraphic
... or drawing it twice one without the filter one with
CL: I think that's useful functionality
... clear to explain with a couple of examples
... simple enough to have it canned
DJ: I still want to go back and see why Simon doesn't think it's a
good idea
<scribe> ACTION: Dean to make a proposal for feTransform and
corresponding canned function [recorded in
[55]http://www.w3.org/2011/11/03-fx-minutes.html#action11]
<trackbot> Created ACTION-61 - Make a proposal for feTransform and
corresponding canned function [on Dean Jackson - due 2011-11-10].
DJ: another request that came in was to add more canned effects like
lighting
... that was intentionally not put into the spec at the start
VH: they're missing from the spec?
DJ: they're there as markup, not canned functions
... not sure how useful they are
... as shorthands
... one of the disadvantages is that normally it's a tree of lights,
writing them in the property you get a big long thing
... one it's annoying to parse, two difficult to animate
CL: usually you want to combine lighting with something else
VH: if we're doing something like this I'd rather have a shorthand
for emboss, or chisel, or something like this
CL: right, lighting doesn't do anything by itself
VH: do we do a chisel etc.?
DJ: this is just my feeling, I like the idea of canned ones be very
simple and a short list
... it's for the simple case
... go to shaders or markup for anything beyond that
VH: with simple canned filters, if you take a version of a tool like
powerpoint, they have a set of canned filter effects
... and those are pretty close to the list you have
... some that apply to images, some that apply to geometry
... emboss, glossy effects are ones that are in tools like this
DJ: I'd be happy a proposal was made
... I think it's easy to add these canned effects, we know how to do
them
... the problem is doing it in a way that's readable and
understandable
VH: I was thinking one thing would be to have a syntax for custom
declarative filters
DJ: that would be very useful
CL: some people are going to just use the keywords, some will write
their own thing
... there's a middle ground, the same people who would take a script
library but not write it, they'll copy/paste/tweak a fancy filter
thing
... from there their css syntax will just be url(...)
VH: could we mark this as an issue for us?
<scribe> ACTION: Vincent to add an issue for parameter passing into
markup filters [recorded in
[56]http://www.w3.org/2011/11/03-fx-minutes.html#action12]
<trackbot> Created ACTION-62 - Add an issue for parameter passing
into markup filters [on Vincent Hardy - due 2011-11-10].
DJ: another thing I'll just raise as a potential, though I think we
won't do it
... IE5 has the filter property with a bunch of shorthands
... a wave filter, invert
Next F2F
ED: when is CSS meeting?
VH: the next one is in paris
<shepazu> [57]http://wiki.csswg.org/planning/2012
[57] http://wiki.csswg.org/planning/2012
VH: for Bucharest in May, Adobe can host an FX day and the SVGWG
meeting before/after the CSSWG meeting
... the CSSWG hasn't decided which days exactly
... in the week listed on that page
... typically CSS does 3 days with 1 day of overlap
DS: maybe we can have the WGs meet the same time?
VH: rather not split myself over both
... otoh we could stagger it, meeting over 4 days, have one day of
SVG and CSS meeting separately on the same day
... that makes it shorter for those who are going to both
RESOLUTION: We will meet with the CSS WG in May.
<scribe> ACTION: Erik to coordinate with CSSWG regarding SVG/FX
meeting. [recorded in
[58]http://www.w3.org/2011/11/03-fx-minutes.html#action13]
<trackbot> Created ACTION-63 - Coordinate with CSSWG regarding
SVG/FX meeting. [on Erik Dahlström - due 2011-11-10].
VH: I think we should either have SVG in Paris in January, or have
it several weeks apart in Australia/NZ.
... so CSS is Paris, Feb 6-8
... if we had it earlier than that would be Jan, probably too early
... with the holiday period upcoming, we won't have made as much
progress by Jan
... my preference is to colocate with CSS
... more efficient travel wise for those attending both
... and good timing between now and May
DJ: also two consecutive Europe meetings
... although CSS is already doing that
VH: we still have a lot of work with requirements, getting the spec
together, no lack of things to talk about
CM: I would prefer Aus/NZ in January
... in fact prefer Sydney to Auckland, to maximise dino/danilo
chance of attendance
<shans> [59]http://lca2012.linux.org.au/
[59] http://lca2012.linux.org.au/
RESOLUTION: SVGWG will meet in Sydney the week of 9 January 2012,
deciding exact meeting length later.
Presentation from Declarative 3D group
[ Johannes Behr shows some demos ]
<ed> ACTION: ed to add the decided upon F2F dates to the wiki
[recorded in
[60]http://www.w3.org/2011/11/03-fx-minutes.html#action14]
<trackbot> Created ACTION-64 - Add the decided upon F2F dates to the
wiki [on Erik Dahlström - due 2011-11-10].
DJ: is this demo using WebGL?
... in the example where you're adding nodes...
JB: it uses mutation events
... demoing the feature as if you'd extended the browser
DJ: my questions is, is that enough?
JB: there are a couple of things we can't do well
... the big open question is how the material system should look
like
... in CSS Shaders, it's got a fixed set of parameters for colour
calculations
... in SVG you have filters, but they're all predefined
... with 3D graphics you often want to define something ustom
... native implementations will be much more efficient
... right now, if the CSS transforms changed, I think a native
implementations would be better
DS: Google had a proposal a while ago
CM: O3D?
DS: but they eventually went the way of WebGL
... do you know why they decided to abandon their push for O3D?
JB: one reason is that it was sitting in the middle
... this approach sits on one side, declarative
CM: why did the X3D work get a bad reaction in the HTMLWG a couple
of years ago?
CL: the old proposal was basically just XML-ized deriviative of VRML
... this new work is much more informed by current W3C work
<stakagi> I have a comment about the relationship between 3D and
SVG.
<stakagi>
[61]http://svg.mbsrv.net/mapdata/fgdv25000/tokyo/cntr/Cntr02_l3_8-8.
svg This is contour map a sort of 2.5D? (no-overhanging 3D?) data by
SVG. Contour is well known presentation of 2.5D on 2D canvas for the
map.
[61]
http://svg.mbsrv.net/mapdata/fgdv25000/tokyo/cntr/Cntr02_l3_8-8.svg
<stakagi> Please view source; property lm:(japanese char) describes
altitude (in meter). Is the interim data of such 3D and 2D also
thought of? This data has the advantage that a common data can be
used also by a view by 3D and 2D.
<dbaron> what's the agenda for after break?
dbaron, a forgotten item of animation
unfortunately dean had to leave
but patrick will be calling in and wants to discuss css animations
targetting attributes
CSS Animation
DJ: [who had to leave earlier]
... Haven't made any progress on any of the animation issues
<ed> [62]http://www.w3.org/Graphics/fx/track/actions/48
[62] http://www.w3.org/Graphics/fx/track/actions/48
<pdengler2> calling in one sec
ED: so that is what we decided in Seattle, the action on Dean
PD: I wanted to ask the group if anyone's in a position to put a
stake in the ground about SVG attributes modelled using the attr()
thing we discussed, or promoting them to properties
... I kind of wanted to get a sense of their positions
... both WebKit/Firefox can target properties on SVG elements, which
is great
... I developed some JS to mimic it in IE, and found it confusing
knowing which ones were attributes and which ones weren't
... wanted to get the temperature from other folks
DB: this is putting attr() on the left side of a declaration?
TA: yes, on the property side
PD: yes, but it was very simple
... just to play with it
... [explains how he did that in js to mimic the proposal]
... just to get a feel ancedotally how it works
... Firefox/WebKit target SVG properties
... we (IE) only have it where SVG properties overlap with HTML ones
... independent of SMIL, I think we could do more creative things
ED: one thing dean said before he left, he didn't want to be the
gating factor
... he was fine with someone taking the ACTION-48
... and was suggesting Brian to do that
PD: this is what I'd love to do
... I'm happy for someone to go off, do the investigation (again?)
... let's decide
CC: could you do something like the data-* that was proposed for CSS
recently?
DB: attr-* sounds a bit nicer than attr()
... I think attr() doesn't match the forward compatible grammar
CM: first, should we solve this problem?
DB: yes, just not quite sure how it's going to work
CL: I am concerned about property bloat
... showing up on many elements
... they don't apply to many elements
TA: I'm a bit troubled by allowing something specifically in
animations, and not generally
CL: if it's seen more as a syntax that pretends an attribute as
properties, rather than promoting properties, I'm more conformtable
... less uncomfortable
TA: there are a few conflicts, from the discussion several months
ago, where the grammars are a bit different
... I think there are a few cases where the same attribute name are
used with different values on different elements
PD: is that such a bad thing?
... we have rules to say how that's resolved
... there are a lot of issue that have come up, there are reasonable
calls to make either way you go
... I think it's a matter of committing and going
<TabAtkins_> As a note - while "attr(): foo;" violates the Core
Grammar, it's compatible with the error-parsing rules; the parser
will just skip to the next ";".
<dbaron> yeah, CSS forward compatible grammar doesn't allow anything
other than idents on the left side of the : in a declaration
[ discussion about way forward ]
<scribe> ACTION: Patrick to come up with a concrete proposal for CSS
Animations targetting SVG attributes and mail it to public-fx
[recorded in
[63]http://www.w3.org/2011/11/03-fx-minutes.html#action15]
<trackbot> Sorry, couldn't find user - Patrick
ChrisL, that worked :)
<ChrisL> nope, because the lasst thing is
<ChrisL> CM: a poll?
<ChrisL> VH: three options
ChrisL, refresh
<ChrisL> and then the minutes end
(maybe shift+refresh or whatever)
<ChrisL> oh, right
<ChrisL> ok, its good
Summary of Action Items
[NEW] ACTION: Cyril to prepare SVG Transforms module for
obsolescence. [recorded in
[64]http://www.w3.org/2011/11/03-fx-minutes.html#action08]
[NEW] ACTION: Cyril to provide use cases for blend modes [recorded
in [65]http://www.w3.org/2011/11/03-fx-minutes.html#action01]
[NEW] ACTION: Cyril to record implementability concerns in the
Compositing spec [recorded in
[66]http://www.w3.org/2011/11/03-fx-minutes.html#action04]
[NEW] ACTION: Dean to make a proposal for feTransform and
corresponding canned function [recorded in
[67]http://www.w3.org/2011/11/03-fx-minutes.html#action11]
[NEW] ACTION: Dean to propose a unified Matrix for SVG/CSS [recorded
in [68]http://www.w3.org/2011/11/03-fx-minutes.html#action06]
[NEW] ACTION: ed to add the decided upon F2F dates to the wiki
[recorded in
[69]http://www.w3.org/2011/11/03-fx-minutes.html#action14]
[NEW] ACTION: Erik to coordinate with CSSWG regarding SVG/FX
meeting. [recorded in
[70]http://www.w3.org/2011/11/03-fx-minutes.html#action13]
[NEW] ACTION: Erik to write up a spec for clip/mask in SVG/CSS
[recorded in
[71]http://www.w3.org/2011/11/03-fx-minutes.html#action05]
[NEW] ACTION: Jen to find out whether filters with enable-background
are implemented on mobile [recorded in
[72]http://www.w3.org/2011/11/03-fx-minutes.html#action02]
[NEW] ACTION: Patrick to come up with a concrete proposal for CSS
Animations targetting SVG attributes and mail it to public-fx
[recorded in
[73]http://www.w3.org/2011/11/03-fx-minutes.html#action15]
[NEW] ACTION: Vincent to add an issue for parameter passing into
markup filters [recorded in
[74]http://www.w3.org/2011/11/03-fx-minutes.html#action12]
[NEW] ACTION: Vincent to add CSS Shaders to the Filter Effects spec
and ready it for publishing. [recorded in
[75]http://www.w3.org/2011/11/03-fx-minutes.html#action09]
[NEW] ACTION: Vincent to get security experts to talk with the FX
group about CSS Shaders security issues [recorded in
[76]http://www.w3.org/2011/11/03-fx-minutes.html#action10]
[NEW] ACTION: Vincent to look into implementability of blend modes
[recorded in
[77]http://www.w3.org/2011/11/03-fx-minutes.html#action03]
[NEW] ACTION: Vincent to make clear in the merged transforms spec
that it hasn't yet replaced the separate specs [recorded in
[78]http://www.w3.org/2011/11/03-fx-minutes.html#action07]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [79]scribe.perl version 1.136
([80]CVS log)
$Date: 2011/11/04 00:26:18 $
_________________________________________________________
[79] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[80] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43
Check for newer version at [81]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[81] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/Opera/Abbra/
Succeeded: s/filteres/filters/
Succeeded: s/dev/content dev/
Succeeded: s/CC/RC/
Succeeded: s/affects/effects/
Succeeded: s/ASV/ASV, IE10/
Succeeded: s/... for mini/ED: for mini/
Succeeded: s/somethign/something/
Succeeded: s/Compsiting/Compositing/
Succeeded: s/nobody uses clip in SVG content, since it's broken/nobody
uses the 'clip' property in SVG content, since it's broken/
Succeeded: s/Exclusiosn/Exclusions/
Succeeded: s/immutable/a mutable/
Succeeded: s/you can/you don't have to/
Succeeded: s/SF/SG/
Succeeded: s/immutable/mutable/
FAILED: s/CSS 2D and 3D/CSS 2D and CSS 3D/
Succeeded: s/all these/the memory overflow/
FAILED: s/attack/attacks/
Succeeded: s/WebGL/shader/
Succeeded: s/use/yes/
FAILED: s/TB/DB/
FAILED: s/TB/DB/
FAILED: s/TB/DB/
FAILED: s/set u/set up/
FAILED: s/coudl/could/
Found Scribe: Cameron
Found ScribeNick: heycam
WARNING: Replacing list of attendees.
Old list: +1.206.675.aaaa [Microsoft] tpac cabanier
New list: tpac cabanier tbah
WARNING: Replacing list of attendees.
Old list: tpac cabanier tbah
New list: tpac +1.425.868.aaaa
Default Present: tpac, +1.425.868.aaaa
Present: Cameron_McCormack Erik_Dahlstrom Tab_Atkins Doug_Schepers Jun_
Fujisawa Sylvain_Galinaeu David_Baron Simon_Fraser Dean_Jackson Timothy
_Horton Shane_Stephens Cyril_Concolato Satoru_Takagi Jennifer_Yu Chris_
Lilley Rik_Cabanier_phone Patrick_Dengler_phone Tavmjong_Bah_phone Vinc
ent_Hardy Eli_Fidler Johannes_Behr Eric_Mueller Alan_Stearns
Got date from IRC log name: 03 Nov 2011
Guessing minutes URL: [82]http://www.w3.org/2011/11/03-fx-minutes.html
People with action items: cyril dean ed erik jen patrick vincent
Received on Friday, 4 November 2011 00:32:12 UTC