IRC log of fx on 2011-01-31

Timestamps are in UTC.

20:59:40 [RRSAgent]
RRSAgent has joined #fx
20:59:40 [RRSAgent]
logging to
20:59:42 [trackbot]
RRSAgent, make logs world
20:59:43 [Zakim]
Zakim has joined #fx
20:59:44 [trackbot]
Zakim, this will be 3983
20:59:44 [Zakim]
ok, trackbot; I see GA_FXTF()4:00PM scheduled to start in 1 minute
20:59:45 [trackbot]
Meeting: CSS-SVG Task Force Teleconference
20:59:46 [trackbot]
Date: 31 January 2011
21:00:13 [heycam]
Zakim, code?
21:00:13 [Zakim]
the conference code is 3983 (tel:+1.617.761.6200 tel:+ tel:+44.203.318.0479), heycam
21:00:31 [Zakim]
GA_FXTF()4:00PM has now started
21:00:38 [Zakim]
21:00:41 [heycam]
Zakim, ??P0 is me
21:00:41 [Zakim]
+heycam; got it
21:00:53 [Zakim]
21:00:55 [Zakim]
21:00:56 [dbaron]
Zakim, [Mozilla] is dbaron
21:00:56 [Zakim]
+dbaron; got it
21:00:58 [Zakim]
21:01:06 [ed]
Zakim, [IP is me
21:01:06 [Zakim]
+ed; got it
21:01:28 [ed]
21:01:34 [Zakim]
21:02:11 [Zakim]
+ +1.408.881.aaaa
21:02:23 [dino]
zakim, aaaa is me
21:02:23 [Zakim]
+dino; got it
21:03:09 [ed]
Zakim, pick a victim
21:03:09 [Zakim]
Not knowing who is chairing or who scribed recently, I propose dino
21:03:18 [dino]
i cannot scribe today
21:03:28 [dino]
i will be leaving early
21:03:34 [ed]
Zakim, pick a victim
21:03:34 [Zakim]
Not knowing who is chairing or who scribed recently, I propose heycam
21:03:55 [heycam]
Scribe: Cameron
21:03:58 [heycam]
ScribeNick: heycam
21:04:12 [heycam]
Topic: SVG/CSS filters
21:04:23 [heycam]
ED: i just wanted to go over what i've done so far with this
21:04:37 [heycam]
... and that is basically just to move the SVG 1.2 filters module over to the public fx repository
21:04:42 [heycam]
... and to set up the build scripts so that it can build from that location
21:04:54 [heycam]
... bascially at the moment it's requiring the svg subdirectory to be checked out as well, since it's pulling the java tools from there
21:04:54 [shepazu]
agenda+ Hg repo?
21:05:07 [heycam]
... i also started a wiki page trying to summarise some of the email threads
21:05:14 [heycam]
... haven't got everything yet, been a lot of discussions on the list
21:05:25 [heycam]
... what i wanted to hear from you guys is what direction you'd like this to take
21:05:37 [heycam]
... would you prefer having one spec or two? one for css specifically and one for svg, or a joint one?
21:06:12 [shepazu]
[I'd like a joint one]
21:06:13 [heycam]
SF: there's ambiguity about what applies to svg and what to css
21:06:19 [heycam]
DS: it can be called out
21:06:31 [heycam]
SF: UAs that implement both have to be compliant with both parts of the spec
21:06:33 [heycam]
DS: isn't that the goal?
21:06:56 [heycam]
SF: with transforms as well, if we want to advance one faster than the other, then it's going to take longer to get compliant implementations
21:07:24 [heycam]
ED: i can see the problem with that. otoh there are already implementations of the svg filters, so i wouldn't expect minor changes or additions to the svg side of things to have a slow down effect
21:07:40 [heycam]
SF: implmentations compliant with svg filters would no longer be compliant, because of the css parts, right?
21:07:45 [heycam]
ED: depends how you set up the conformance classes
21:07:55 [heycam]
DB: i would think the normal way to do it would be to have two conformance definitions, and you can meet one or both
21:07:56 [heycam]
ED: yeah
21:07:58 [heycam]
SF: ok that sounds fine
21:08:17 [heycam]
ED: if eveyrone is on board with that, i'll start merging some of the mozilla proposals
21:08:31 [heycam]
... bascially to allow the html/css cases to use the svg filters directly
21:08:44 [shepazu]
q+ to ask about canned effects
21:08:57 [heycam]
... at the moment what's in the spec is kidn of loose, and the host language has to define the regions and the input keywords
21:09:17 [heycam]
DS: do you have a link?
21:09:22 [ed]
21:09:39 [heycam]
ED: it's mostly the same as the 1.2 filters that got published, some minor changes
21:09:53 [heycam]
... i will have to go over it again, making sure we have all the changes from 1.1SE, there've been some minor changes there
21:10:03 [heycam]
DS: do you talk at all about canned effects?
21:10:25 [heycam]
ED: at the moment it's mostly dealing with the svg side of things, and i would like to have some sort of css canned effects, a simpler syntax, for common effects as has been discussed on the list
21:10:34 [heycam]
DS: there's been a lot of discussion on the css list about this
21:10:46 [heycam]
... i think to build excitement/interest abotu this, it might be useful for us to have some wording in there
21:10:47 [heycam]
ED: i agree
21:10:51 [ed]
21:10:58 [heycam]
... if you look at the wiki page, i have summarised some of the proposals/wishes for common primitives
21:11:12 [heycam]
... like i said, this is not everything, i haven't gone through the whole email thread yet, but it's a start
21:11:22 [heycam]
... and i'd like to structure it like this and keep it on the wiki, it's easier to get an overview
21:11:38 [heycam]
... i'll use that as a starting point. i'm not at this point concerned about the syntax itself, just the general idea of having it.
21:11:50 [heycam]
... i can probably start putting some suggestions into the draft, if that sounds like a good idea
21:12:03 [heycam]
... i think some of the more common ones like blur/glow would be something i could put in relatively quickly
21:12:07 [heycam]
DS: i think that would be great
21:12:22 [heycam]
... we can poitn people to that and it could help spur the conversation, having something concrete in there
21:12:28 [heycam]
... regardless of that's the exact way we do it
21:12:34 [heycam]
s/that/whether that/
21:12:54 [heycam]
ED: i think there's still a lot of changes on the svg side of things that i've been planning to do, but haven't got to
21:12:58 [heycam]
... some are in the svg tracker
21:13:06 [heycam]
... i will try to do my edits on the public fx repository now, going forward
21:13:12 [heycam]
... and just leave the svg part of it as it was
21:13:24 [heycam]
CM: does that mean we're definitely going forward with a single spec?
21:13:30 [heycam]
ED: yes going forward, that's what i'm hearing
21:13:34 [heycam]
DS: it's my preference
21:14:05 [heycam]
ED: my requirement is to keep the actual implementation side of things compatible between the svg and css
21:14:17 [heycam]
... so that we can have some common ground, making the implementation easier for everyone
21:14:20 [dino]
my only concern with single specs is that they tend to make little progress overall. it always seems faster to combine afterwards. not a big deal.
21:14:21 [heycam]
... even if the syntax may not exactly be the same
21:15:00 [heycam]
ED: the point about the repository, is that something we should try to do right away? moving to hg?
21:15:02 [smfr]
hg, not git?
21:15:26 [heycam]
DS: i've just been using mercurial for the web events specs, and it's pretty cool, people can fork and fold changes back in more easily
21:15:34 [dino]
do we really want forks of specs?
21:15:44 [heycam]
... since this group is more collaborative by nature, with multiple editors, it might be an interesting way forward
21:15:56 [heycam]
SF: is hg something used by other groups? i remember hearing something about git rather than hg
21:16:06 [heycam]
DS: i don't think w3c supports git, they chose hg in the end
21:16:51 [heycam]
... relatedly, i've been using berjon's respec, and really like it a lot. we might consider it. but let's have that conversation on the list.
21:17:00 [heycam]
ED: simon, you said you'd like to be coeditor on the filters spec?
21:17:09 [heycam]
SF: me, or maybe dean is interested
21:17:21 [heycam]
DJ: yeah you can put me down as interested
21:17:26 [shepazu]
action: shepazu to get an HG repo set up for FX
21:17:26 [trackbot]
Created ACTION-24 - Get an HG repo set up for FX [on Doug Schepers - due 2011-02-07].
21:17:48 [heycam]
ED: the other minor thing is what to call the spec itself, do we need a new name for it?
21:17:57 [heycam]
... or is that too earlier?
21:18:00 [heycam]
DS: filter effects 1.0?
21:18:02 [heycam]
SF: sounds good
21:18:21 [heycam]
ED: i guess it's fine to go ahead and start changing the spec itself, if you want to have a go at it
21:18:29 [heycam]
... my first edit will probably be to fold in the filter proposal from mozilla
21:18:37 [heycam]
... and then try to merge back some of the changes from svg 1.1 second edition, minor things
21:19:02 [heycam]
... and another major thing is removing the margin attributes, which were originally added from svg 1.2 full
21:19:20 [heycam]
... but the consensus seems to be that it's a bit clunky, and we should look at other ways of doing clipping of filters
21:19:36 [heycam]
... e.g. to make sure that blurs aren't clipped at the edges, and you just get the effect you're after
21:19:58 [heycam]
... there are some bugs in inkscape where the filter size attribtues are set too small and that causes issues when viewing
21:19:58 [Zakim]
21:20:04 [heycam]
... so aiming to fix those cases, and making it easier to use
21:20:12 [heycam]
... i don't see the point in making it more complex to control the filter region
21:20:16 [anthony_work]
Zakim, ??P4 is me
21:20:16 [Zakim]
+anthony_work; got it
21:20:47 [heycam]
CM: sometimes you want to clip some of the filter region out, would there be a way to do that?
21:20:54 [heycam]
ED: we would need to add something to allow that
21:21:08 [heycam]
DB: i think we have code that tracks how much different filter effects extend, so we could work it out, without adding much code
21:21:16 [heycam]
... since we have that infomration for invalidation
21:21:17 [heycam]
ED: same
21:21:28 [heycam]
SF: same for webkit, e.g. with box shaodw you need a larger invalidation rect
21:22:16 [heycam]
CM: there was also discussion about parameterised filters
21:22:24 [heycam]
ED: i think the first thing to do is look at the common effects people are after
21:22:30 [heycam]
... blur/glow/etc for example
21:22:35 [heycam]
... we should put those in as a first step
21:22:45 [heycam]
... trying to figure out the rest on the wiki, from the email threads, is probably a good second step
21:22:50 [heycam]
... and we can proceed from there
21:23:16 [heycam]
DJ: there've been lots of proposals, and i tend not to like the ones where the idea is to define something in svg and somehow expose that as a shorthand in css, where you can pass in params
21:23:34 [heycam]
... the set of available filters, is small enough that you could define the svg equivalent and just call it "blur" with one parameters
21:23:42 [heycam]
... and a sharpening, you know what the one parameter is, etc.
21:23:54 [heycam]
... seems like that's much simpler to implement than coming up with a lgnauge where you define a parameterisation scheme
21:24:06 [heycam]
... and in fact, the good thing is that it falls back nicely you could implement it in svg anyway
21:24:15 [heycam]
... let's say you did 'filter: blur 10 sharpen 5
21:24:26 [heycam]
... you could easily transcode that into an svg filter chain
21:24:33 [heycam]
s/blur 10 sharpen 5/blur(10) sharpen(5)/
21:24:54 [heycam]
DB: there are also cases like shadows where they don't want a direct chain of filters, they want to composite that with some other non-shadowed part
21:24:58 [heycam]
ED: where do you draw the line?
21:25:06 [Zakim]
+ +1.415.920.aabb
21:25:09 [heycam]
DJ: i think in most cases people will apply these to images, or a standalone thing like a single element
21:25:14 [heycam]
... if they do it to a tree of things...
21:25:18 [fantasai]
Zakim, aabb is me
21:25:18 [Zakim]
+fantasai; got it
21:25:28 [heycam]
... let's make the simple things simple, and fall back to complicated svg things if they need something complex
21:25:32 [heycam]
DB: i guess that's probably ok
21:25:47 [heycam]
DJ: the other huge advantage here is that it makes animation of filters very simple, we know exactly what the parameters are for the canned filters
21:25:58 [heycam]
... while we've defined how it might work exactly with svg filters, you might not implement it that way
21:26:08 [heycam]
... you know in adance you'll animate some parameter
21:26:13 [heycam]
... so you can get better performance
21:26:16 [heycam]
DS: i think that's a great point
21:26:27 [heycam]
SF: you're saying all filters in css are canned?
21:26:38 [heycam]
DJ: no you'd still allow url(somesvg), but you'd define some precanned ones
21:26:47 [heycam]
... i don't think we need to define a full parametersiation syntax yet
21:26:55 [heycam]
... where the svg filter can expose a param via a name
21:27:09 [heycam]
... the list on the wiki is a great start, let's look around for others people use, anything more complex just use url() and point to svg
21:27:16 [heycam]
DS: that's how i'd expect it to work
21:27:30 [heycam]
... when i was referring to parameterisation, whether you can say more blur/less blur, what direction it's in
21:27:45 [heycam]
DJ: it was an interesting suggestion, the ability to mark up svg with parameters, and expose that to css
21:28:06 [heycam]
... if i write deanblur, a gaussian blur plus a hue rotation, i could expose the blur radius to css -- i don't think we want to go there yet
21:28:14 [heycam]
... there's a simple set of filters we want to tick off before we go down that path
21:28:37 [heycam]
DS: thanks, my idea of parametersiation was that simply it'd be a css function and you'd give a blur direction, stddeviation, etc.
21:28:40 [heycam]
... so we're on the same page there
21:28:51 [heycam]
... with regards to real parametersiation, the svg parameters spec would be fine for that
21:28:58 [heycam]
... it's not specific to filters, but we can have that discussion later
21:29:07 [heycam]
... i'm with you that having the simplest solution first is probably the best way forward
21:29:20 [heycam]
... so all of what you described is what i meant by canned effects
21:30:04 [heycam]
ED: dean or simon, you can go and propose some syntax for the canned filters
21:30:08 [heycam]
... my first changes won't touch that yet
21:30:10 [dino]
yes, sure
21:31:17 [heycam]
Topic: alignment-baseline initial value being different between SVG and CSS
21:31:27 [ed]
scribeNikck: ed
21:31:33 [Zakim]
21:31:35 [ed]
scribeNick: ed
21:31:54 [ed]
CM: in the svg testsuite we have a test, *dropping link in*
21:32:04 [heycam]
21:32:32 [ed]
... this test asserts that the different set of glyphs are supposed to align with the three baselines
21:32:42 [ed]
... it's using the alignment-baseline property
21:33:02 [ed]
... while investigating this test, i found the definitions between CSS3 linebox and SVG are slightly different
21:33:08 [ed]
... in svg initial value is auto
21:33:37 [ed]
... in css there's a keyword 'use-script' that gives the behaviour the test expects
21:33:55 [ed]
... in css the inital value is baseline
21:34:21 [ed]
... each set of glyphs in a fontsize establish a separate group for alignment purposes
21:34:45 [ed]
EE: CSS3 linebox hasn't been actively edited for some years
21:35:38 [ed]
... doesn't make sense to align to the different baseline, how do you handle punctiuation characters?
21:35:54 [ed]
CM: there's a referral to the text-script property
21:36:17 [ed]
EE: you're going to pick a dominant baseline for all your text, otherwise it's going to look weird
21:37:12 [ed]
... having different glyphs aligned to different baselines, mixing numbers, alphabetic text and indic text for example
21:37:40 [ed]
...there shouldn't be a value that picks a baseline for each character
21:37:47 [ed]
... it should be per element
21:37:57 [ed]
... not per character, that doesn't make any sense
21:38:27 [ed]
CM: in css3 linebox, the use-script value should be dropped
21:38:43 [ed]
DS: so we should drop this test from the svg testsuite
21:38:54 [ed]
... and going forward align with css
21:39:07 [ed]
CM: is the spec going to be worked on again?
21:39:38 [ed]
EE: john daggett will work on it
21:40:09 [ed]
... you may want to keep a test to align to the alphabetic baseline, which is what i believe most implementations do atm
21:40:24 [ed]
DS: do we need to change the SVG 1.1 spec to deal with this?
21:40:31 [ed]
CM: possibly
21:40:38 [ed]
... kind of a big change
21:41:25 [ed]
DS: suggest that we remove the relevant section, and drop the test for now
21:41:37 [ed]
CM: the alignment-baseline property (in svg 1.1)
21:42:01 [ed]
DS: or worry about the spec change later
21:42:25 [ed]
... it's not clear what the implications of changing it would be
21:42:52 [ed]
CM: aligning with css text stuff will come up in context of the vertical text stuff in css
21:43:27 [ed]
... will people never want to align to different baselines like the test expects?
21:44:12 [ed]
EE: maybe, but you could do that using spans and styling
21:44:26 [ed]
... for a given run of text you'd want one baseline
21:44:37 [ed]
... doing it per character doesn't really make a lot of sense to me
21:45:09 [ed]
... especially considering shared classes, like numerical characters and punctuation
21:46:14 [ed]
<explanation about fonts and glyphs and baselines>
21:46:37 [ed]
DS: so let's bring this back to the svgwg
21:46:47 [ed]
CM: curious about the use-cases
21:49:28 [ed]
ACTION: CM to ask XSL WG about the use-cases for alignment-baseline=use-script (or equivalent)
21:49:29 [trackbot]
Created ACTION-25 - Ask XSL WG about the use-cases for alignment-baseline=use-script (or equivalent) [on Cameron McCormack - due 2011-02-07].
21:52:31 [ed]
Topic: animationFramerate
21:52:47 [ed]
CM: we want to bring this to the WG to standardise
21:53:16 [ed]
... could be done in the FXTF and put into the SVG charter
21:53:31 [ed]
SF: we're interested in it
21:53:41 [ed]
... for canvas games and canvas animations
21:53:57 [ed]
CM: my first choice was webapps, but it's hard to add specs to webapps
21:54:04 [ed]
SF: what about Html?
21:54:11 [ed]
CM: hadn't considered, maybe
21:54:39 [ed]
... i've started writing something up... to help discussions on the list
21:55:28 [ed]
DS: it's a challenge to add things to existing charters
21:56:08 [ed]
... but if we have the right people involved it doesn't really matter in which charter it is, or in which group/taskforce
21:56:24 [ed]
SF: it's fine to work on a proposal, we'll figure out where it should go
21:56:33 [ed]
DS: why would it be a problem in svg?
21:56:54 [ed]
... it's something that will cover svg, canvas, html and webapps...
21:57:24 [ed]
... don't see a problem keeping it in the FXTF
21:58:13 [ed]
... it's mostly an issue of finding the right people to work on it, and i think we have these here in FX
21:58:26 [Zakim]
21:58:58 [smfr]
requestAnimationFrame, yeah
21:59:21 [ed]
RESOLUTION: to start work on requestAnimationFrame in the FXTF
22:00:20 [Zakim]
22:00:21 [Zakim]
22:00:21 [Zakim]
22:00:23 [Zakim]
22:00:23 [Zakim]
22:00:24 [Zakim]
22:00:24 [Zakim]
GA_FXTF()4:00PM has ended
22:00:26 [Zakim]
Attendees were heycam, smfr, dbaron, [IPcaller], ed, Doug_Schepers, +1.408.881.aaaa, dino, anthony_work, +1.415.920.aabb, fantasai
22:01:00 [smfr]
smfr has left #fx
22:01:52 [ed]
trackbot, end telcon
22:01:52 [trackbot]
Zakim, list attendees
22:01:52 [Zakim]
sorry, trackbot, I don't know what conference this is
22:01:53 [trackbot]
RRSAgent, please draft minutes
22:01:53 [RRSAgent]
I have made the request to generate trackbot
22:01:54 [trackbot]
RRSAgent, bye
22:01:54 [RRSAgent]
I see 2 open action items saved in :
22:01:54 [RRSAgent]
ACTION: shepazu to get an HG repo set up for FX [1]
22:01:54 [RRSAgent]
recorded in
22:01:54 [RRSAgent]
ACTION: CM to ask XSL WG about the use-cases for alignment-baseline=use-script (or equivalent) [2]
22:01:54 [RRSAgent]
recorded in