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