20:00:17 RRSAgent has joined #svg 20:00:17 logging to http://www.w3.org/2011/06/23-svg-irc 20:00:19 RRSAgent, make logs public 20:00:19 Zakim has joined #svg 20:00:21 Zakim, this will be GA_SVGWG 20:00:21 ok, trackbot; I see GA_SVGWG(SVG1)4:00PM scheduled to start now 20:00:22 Meeting: SVG Working Group Teleconference 20:00:22 Date: 23 June 2011 20:00:36 GA_SVGWG(SVG1)4:00PM has now started 20:00:40 +??P2 20:00:43 +Doug_Schepers 20:00:57 Zakim, ??P2 is me 20:00:57 +ed; got it 20:02:56 +tbah 20:03:16 +Rick 20:04:11 +??P11 20:04:15 Zakim, ??P11 is me 20:04:15 +heycam; got it 20:04:24 Chair: Cameron 20:04:52 Zakim, who is on the call? 20:04:52 On the phone I see Doug_Schepers, ed, tbah, Rick, heycam 20:05:39 Zakim, pick a scribe 20:05:39 Not knowing who is chairing or who scribed recently, I propose heycam 20:05:43 Zakim, pick a scribe 20:05:43 Not knowing who is chairing or who scribed recently, I propose Rick 20:05:54 +Oliver_Goldman 20:06:23 Zakim, pick a scribe 20:06:23 Not knowing who is chairing or who scribed recently, I propose Oliver_Goldman 20:06:59 vhardy has joined #svg 20:07:15 ScribeNick: vhardy 20:07:29 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0162.html 20:07:55 CM: First topic, joint meeting with CSS 20:08:20 VH: We can host the SVG meeting no problem. 20:08:37 ChrisL has joined #svg 20:08:48 VH: We have problems finding a room for the joint meeting. 20:09:24 +ChrisL 20:09:48 VH: we can host the SVG WG meeting. 20:10:03 CL: there has been two offers to host the CSS WG, but none has been confirmed. 20:10:21 CM: My guess is that it should not be a problem to find a big enough room at Microsoft. 20:10:40 CL: I sent a message asking to meet tuesday to Friday, and Tuesday would be the overlap day. 20:10:46 CM: that is fine. 20:11:32 zakim, who is here? 20:11:32 On the phone I see Doug_Schepers, ed, tbah, Rick, heycam, Oliver_Goldman, ChrisL 20:11:34 On IRC I see ChrisL, vhardy, Zakim, RRSAgent, cabanier, heycam, tbah, konaya, karl, shepazu, trackbot, ed 20:11:45 RESOLUTION: The SVG WG will meet Tuesday to Friday. Tuesday will be the joint meeting. 20:12:16 VH: Adobe can host Wednesday/Thursday/Friday. 20:12:26 Zakim, you rang? 20:12:26 I don't understand your question, konaya. 20:12:38 Oh, a bot 20:12:39 VH: we are looking into hosting the FX meeting and the CSS WG meeting but we have issues finding the right-size room. 20:14:09 RC: There are Microsoft and Google buildings in the same neighborhood. 20:14:52 ACTION ITEM: CL to talk to Microsoft to see if they can host the joint FX meeting. 20:14:52 Sorry, couldn't find user - ITEM 20:15:01 ACTION: CL to talk to Microsoft to see if they can host the joint FX meeting. 20:15:01 Created ACTION-3054 - Talk to Microsoft to see if they can host the joint FX meeting. [on Chris Lilley - due 2011-06-30]. 20:15:32 CM: Anything else we need to discuss on the F2F? 20:15:43 CM: The end of the month is coming, remember to enter Action Item requests. 20:15:51 s/Action Items/Agenda Items 20:16:06 CM: Next topic is test suite. 20:16:15 CM: CSS 2.1 test suite conversion 20:16:15 topic: Test suite 20:16:27 http://tavmjong.free.fr/SVG/SVG_CSS_TESTS/2.1/HTML/index.html 20:16:28 CM: Tab mailed in that he is converting CSS 2.1 tests to SVG. 20:17:08 CM: I wanted to use that as a starting point to discuss plans for the test suite and using the same test framework as the CSS working group. 20:17:18 s/Tab/Tav/ 20:17:23 Tav: How does that differ from what we do now. 20:18:40 CL: The test suite does a lot about agregating test results automatically on the back-end. It is worthwhile for someone in the public to run some of the tests. You can get test confirmation by having several people running the same tests. 20:19:05 CL: there was also a plain text format to submit test results. 20:19:32 CM: Do they have both automated and manual tests? 20:20:06 CL: It is automated in the sense there is a button, but the user needs to press the button. There were some automated tests support, so it should be possible to integrate them. 20:20:24 CL: This is being moved to W3C, and it is work in progress. You need to track and follow to see how it is going. 20:20:35 Tav: Does it require us to change our test? 20:20:55 CL: No, but it would require us to do a ref test for all tests, a simplified version of how it is supposed to look. 20:21:12 ED: Yes, that is correct. We already do that for some tests, we would have to do it for all tests. 20:21:22 CL: it may not be possible for all tests, e.g., tests on filters. 20:21:31 CM: In that case, use a PNG. 20:21:36 s/for all tests/for all these CSS tests/ 20:22:02 CL: the advantage of using a ref file instead of a PNG, is that it takes out the issues with sub-pixel and font variations. 20:22:27 Tav: what you mean by a ref test is an SVG capture of what the expected result should be. 20:22:55 CL: for example, if you tested the alignment thing, you could have a ref test that positioned text simply. 20:23:17 CL: we have tests where the expected result is shapes filled in green, and that is simple to produce in a reference SVG image. 20:23:26 CM: Is it worth looking at what they have right now? 20:23:48 CL: I suggest sending an email to ask where they are, what we should do to adopt the harness. 20:23:56 CM: ok. 20:24:08 CM: Peter Linss is the right contact? 20:24:12 CL: Yes, I believe so. 20:24:22 Peter Linss 20:24:37 CM: the other thing that was discussed was having a joint telcon about this. 20:24:55 CL: I talked to Philippe about it, but it was not ready at that time. May be we should have the meeting now. 20:25:03 CM: there is no harm in asking now. 20:25:16 CM: I'd like to have a plan now for a way to add test to the repository. 20:25:44 ED: I think it is useful to add SVG reference tests anyway, even if we figure out how to put them in the harness later. 20:26:18 ACTION: CM to email Peter Linss to coordinate on using the test harness in the SVG WG. 20:26:18 Sorry, amibiguous username (more than one match) - CM 20:26:18 Try using a different identifier, such as family name or username (eg. charles, cmccorma) 20:26:33 ACTION: Cameron to email Peter Linss to coordinate on using the test harness in the SVG WG. 20:26:33 Created ACTION-3055 - Email Peter Linss to coordinate on using the test harness in the SVG WG. [on Cameron McCormack - due 2011-06-30]. 20:27:11 CM: Tav, when you looked at the test suite, there are a bunch of tests that do not apply, right? 20:27:25 Tav/CL: yes, e.g., Box model tests. 20:27:56 CL: Some of the tests tend to be very atomic, instead of grouping things together. 20:28:25 DS: atomic tests can be good, but each test has a cost when you run nightly. 20:28:38 CL: yes, it can take up to 5 days to run the CSS test suite manually. 20:28:56 CM: even the size of the SVG WG test suite is a bit much. 20:29:09 CM: I am glad to be moving towards an automated solution. 20:29:55 DS: what do implementors think between the trade-off between more atomic tests and fewer tests. 20:30:15 CM: I agree there are advantages in having more atomic tests in some cases, but there is overhead. 20:30:46 DS: part of me also wonders if we should think about automatically creating tests. Are there things, like APIs, that we could automate? 20:30:54 DS: that could save work. 20:31:32 CM: for tests that could let you test things automatically, I would tend to do that in the test itself, with script. 20:33:06 VH: in my experience, we tried to break down tests into small atomic pieces grouped into a single test case to avoid having more test files. 20:33:40 DS: may be we can try to keep some atomicity in the tests and combine the ones that are related. 20:34:02 CM: I think there are advantages in grouping, especially if they are the same form. 20:34:23 CL: Yes, and if you have used a particular technique, they you can share code and it is easier to maintain. 20:35:12 CM: Another point people may consider is the absolute number of tests. 20:35:29 CM: Yes, this can be a double edge sword. 20:36:12 CM: we could identify, in the test meta-data, how many subtests there are. So we could talk about the number of tests and test files. So we could say the total number of tests. 20:36:42 CM: that may not always be easy to separate out. 20:37:23 CM: for scripted tests, we have a number of assertions, so you can say, after running the test, how many assertions you had. 20:37:37 DS: that is what I was talking about: how many assertions where tested? 20:37:44 CM: this is possible for scripted tests. 20:38:06 CM: for my own SVG tests, I have tended to make it match a particular rectangle on the rendering. 20:38:17 CM: you can visually see how many subtests are there. 20:39:00 VH: Should we add meta-data as DS suggested? 20:39:33 CM: I don't want to add more meta-data if we can avoid it. They can become out of sync. 20:40:03 CM: my feeling is that in some cases, the number of subtests might be easy, and hard in some other cases. Looking at the number of test files is an easier metric. 20:40:19 CM: I am not sure if I am decided. 20:40:57 VH: The CSS harness has a way to reference back the SVG spec. 20:41:14 CL: yes, that is right, and so does the SVG harness. 20:41:21 DS: We should do that. 20:41:34 CL: yes, we just have to decide and make the pointers to the spec. consistent. 20:42:19 CL: rather to linking to the section, tests should link to the specific testable assertion. The link actually provides a way to highlight the specific assertion. 20:42:28 DS: I am trying to do that with DOM Level 3 events. 20:43:01 DS: I have tried to break things down into testable assertions, which is not easy. 20:43:14 CL: My feeling, is that if you do it like this, then it is easier to implement. 20:43:37 CL: We were very careful with testable assertions in WOFF. 20:43:49 CL: it worked out well, it was a good plan. 20:43:58 thorton has joined #svg 20:44:01 DS: I would like to follow something similar in the SVG WG. 20:44:21 DS: there are benefits to having discipline there. 20:45:10 CM: we should start organizing a space in the repository for tests so that we can start shuffle things there. 20:45:30 ED: Don't we already have a repository set up for SVG 2.0 tests? 20:45:38 CM: I do not remember if there is anything for the test suite. 20:45:56 http://dvcs.w3.org/hg/svg2/ 20:46:12 http://dvcs.w3.org/hg/svg2-tests/ 20:46:13 +??P21 20:46:19 CM: We have that directory already. 20:46:51 CL: apparently, one advantage of using this repository is that you can deploy versions of the test suite fairly easily. 20:47:33 ED: It would be good if we started to review tests if they are put in the repository. 20:48:11 CM: We should start putting tests in the repository. It is currently empty. 20:48:51 VH: Should we have a requirements document for SVG 2.0 to capture the type of agreements we just had. 20:49:24 CL: a requirement document can be written before or after. 20:49:34 DS: you need to have some requirements before. 20:49:43 um. thats not really my point 20:49:56 CM: Either way, we need to have something written up about what our goals are. 20:50:09 there are two ways to develop. on e is a reqts doc in advance and then build that 20:50:42 the second is to spec stuff and see what gets agreement and implementor traction. then you effectively write a summary at the end which is the requirements 20:50:48 ACTION: Vincent to put together a wiki page to capture requirements for the SVG 2.0 test suite. 20:50:49 Created ACTION-3056 - Put together a wiki page to capture requirements for the SVG 2.0 test suite. [on Vincent Hardy - due 2011-06-30]. 20:50:55 there are advantages and disadvantages to oboth approaches 20:51:29 Tav: CL, did you start looking at the test cases you have put together? 20:51:37 CL: yes, I did. They look good so far. 20:51:42 thorton has joined #svg 20:51:52 DS: Tav, thanks a lot for doing that work. 20:51:56 CM: yes. 20:52:20 CM: next topic: Continue discussion on joint FX spec.s 20:52:25 s/spec.s/specs. 20:53:04 CM: I continued the thread after the CSS WG had their meeting this week. Looking at the minutes, I see the CSS WG did not discuss it this week and also got a charter extension. 20:53:15 CL: Yes, that is right and VH could not make it to the meeting this week. 20:53:41 CM: I sent my thoughts on the items VH listed. It would be good if we could have agreement on what our collective opinion is. 20:53:53 CM: I am not sure if the email list discussion will get us to resolution. 20:54:12 CL: Yes, we need resolution to make sure we have a common agreement between the groups. 20:54:16 VH: agreed. 20:54:45 CM: Let's go over my email. 20:54:46 http://www.w3.org/mid/20110623002011.GC3098@wok.mcc.id.au 20:55:08 CM: Filter effects. 20:55:21 CL: Yes, this seems pretty clear. 20:55:47 CL: There may have been confusion where some people thought there would only be canned tests. This seems to have been cleared. 20:55:54 ED: I would prefer a single spec. 20:55:58 RC: Me too. 20:56:08 VH: Is that still undecided? 20:56:25 RC: no, that has been agreed upon. There was confusion, but that is clear now. 20:56:34 DS: Is that clear for everybody now? 20:57:52 VH: It seems that the group's position is that there should be a single spec. applying to CSS and SVG which will include predefined filters and extensible filters. 20:58:14 CL: I'll bring that to the CSS WG meeting next week. 20:58:57 RESOLUTION: The SVG WG agrees we should have a single filter spec. applying to CSS and SVG which will include predefined filters and extensible filters. 20:59:31 CM: next is compositing. I think it is similar to filters so it should be a common spec. 20:59:44 CL: I agree, but I do not see many people in the CSS WG excited about this. 20:59:56 DS: may be it is because they have a lot of other things to think about. 21:00:17 -ed 21:00:23 -tbah 21:00:55 +tbah 21:00:57 CL: there was some interest in the Porter-Duff compositing rules. 21:01:09 DS: yes. 21:01:29 DS: some other people were not interested or questioned the usefulness. 21:02:44 CM: for compositing, since it is reasonably simple, and it is straightforward how it applies to CSS, it is easy to get it in a form that can be reviewed and adopted later on. 21:02:59 -ChrisL 21:03:05 DS: yes, we could also make it so that it could be immediately useful to CSS, like pointer-events. 21:03:36 RC: yes, and things like enable background are also part of filter effects. 21:03:38 +ChrisL 21:04:24 RESOLUTION: The SVG WG think it would be preferable to work jointly on the compositing spec. but would carry it forward if the CSS WG is not interested. 21:04:47 ED: Yes, the spec. is already in last call, so we could work on the next version as a joint effort. 21:05:02 CM: next is gradients. 21:05:51 CM: I am not exactly clear on this one. Tab is working on the CSS Image Values spec. 21:07:01 DS: I would like to work on this together to make sure that there is coordination and interoperability. 21:07:14 CM: Yes, I agree. 21:08:08 DS: syntax is on thing, but we should try to have a common model. 21:08:36 RC: I have raised that on the mailing list before. This was rejected at the time, but I think people are coming back to it now. 21:12:40 RESOLUTION: The SVG WG thinks the gradient effort should be coordinated to ensure an interoperable model with SVG gradients even if there are syntactic variations. There should be a way to reference SVG paint servers. Two separate coordinated specifications seem ok. 21:12:51 CM: next is parameters. 21:13:34 CM: this is interested because it started of as something specific and it can be generalized. This would determine if it should be SVG only or not. DS: what do you think? 21:15:24 DS: I am torn. I want the functionality for SVG. I hear people wanting it for CSS, but I am not sure how to do it in CSS. I have gone through different revisions. I'd be very happy if something like this, even in a different form, were to happen in CSS. I am not sure what it would be though. Trying to get the perfect thing may end up being like RCC/sXBL/XBL and not see implementation / traction. It is very, very useful for SVG. There are a few things 21:15:24 I would change based on feedback I got. 21:15:43 DS: I am happy to work on it with the CSS WG if there is interest. 21:16:00 CM: Do you know how it might relate to CSS variables. 21:16:21 DS: they could be combined I think. It depends on what you mean by CSS variables. 21:16:52 DS: DG's CSS variables allow you to have CSS variables that are then used throughout the file. 21:17:03 CL: Yes, it is like macros. 21:17:12 CL: some people wanted predefined constants. 21:17:30 CL: some people wanted actual variables with values actually computed and modified in scripts. 21:18:11 DS: the primary use case I have is the ability to reuse the same SVG content by passing in data per-instantiation of the image. 21:18:24 DS: CSS variables do not do that, they do something different. 21:18:39 DS: but that is not incompatible. 21:19:55 Tav: Example of param is a button with different text. 21:20:03 DS: yes, or an icon with different colors. 21:20:11 DS: or a t-shir with different colors. 21:20:29 CM: I think you are right that the differences are significant. 21:20:40 CM: there is also the CSS mixin proposal. 21:21:20 VH: I think that is different than parametrized SVG. 21:23:32 DS: I have talked to authoring tool vendors who have actually implemented this because they saw the value. 21:23:48 DS: Yes, it could be generalized, but may be we should start in the SVG WG. 21:24:00 CM: We could always keep in mind that it could be generalized later. 21:24:15 DS: why don't we just say that this an SVG-only effort at this point. 21:24:49 CM: Tab is the one who wants to push forward the CSS variables? 21:25:10 CL: Yes, but Daniel Glazman is as well, and he is writing an authoring tool. 21:26:53 CM: is it worth contacting Tab whether CSS variables are moving forward and evaluate how that relates to parameters? 21:27:02 DS: I am open to other people's suggestion. 21:27:59 VH: CSS variable's initial values could be made the value of parameter, but apart from that, they are different things. 21:28:11 CM: this is the type of things that we should discuss with Tab and others. 21:28:30 DS: whatever we do, we should discuss with the CSS WG to make sure it works. 21:28:43 DS: I'd like to see how this will work with calc() 21:30:32 RESOLUTION: The SVG WG wants to work on parametrized SVG content and we would like to coordinate with the CSS WG on syntax and possible relation to CSS proposed features such as variables and calc(). 21:31:08 CM: next is content layout. 21:32:03 CM: my feeling is that there are parts of the spec. that are directly usable and some that are not. I do not think there is a particular need to specify this in a separate spec. 21:32:23 DS: does that also bear on your constraints efforts? 21:32:27 CM: I am not sure. 21:33:46 RESOLUTION: The SVG WG proposes that any spec. that specifies how any CSS layout spec. applies to SVG content would be done in an SVG WG specification, coordinated with the CSS WG. 21:34:08 CM: Next, shared properties (like object-fit). 21:34:40 CM: I do not think the coordination overhead is worth it. 21:34:43 ED: that is fine. 21:34:45 DS: yes. 21:35:32 RESOLUTION: SVG WG thinks that how random shared properties apply to SVG can be defined in the SVG specification. 21:35:42 CM: advanced text layout. 21:37:47 VH: I would like to see convergence on how single text line composition is done. 21:37:51 CM: I think that is sensible. 21:37:57 CM: what about flowing text. 21:40:51 VH: This depends on how most implementations will be: if they are both HTML and SVG. 21:41:33 CM: Yes, it has an influence on how important to have advanced text features in SVG. 21:41:56 CM: For stand-alone SVG implementations, it is important to have more functionality than a single line of text. 21:42:14 CM: were people keen on enhancing the flow-text features in SVG? 21:42:32 CL: It is a commonly requested feature and a commonly opposed feature. 21:42:42 Tav: Inkspace has an implementation. 21:42:47 CL: Batik as well. 21:43:12 s/Inkscape/Inkscape/ 21:44:14 s/Inkspace/Inkscape/ 21:44:15 VH: I wonder if we should enhance the SVG features or enhance the integration of CSS text feature? 21:44:27 Tav: From our perspective, we should enhance the SVG text features. 21:44:44 DS: these are not contradictory, more CSS text features would enhance the SVG features. 21:46:50 VH: we should strive to have a single model, and may be allow different syntax for SVG for the stand alone case. 21:47:04 CM: it does not sound like that we need a joint specification. 21:47:09 DS: yes, that is right. 21:47:20 DS: this is saying we draw from CSS where we can. 21:47:44 DS: Except that we are asking the CSS WG to take SVG into account as well as HTML. 21:48:20 RESOLUTION: The SVG WG does not the need to have a joint effort on text layout other than regular coordination. 21:49:06 tracbot end telecon 21:49:12 trackbot, end telcon 21:49:12 Zakim, list attendees 21:49:12 As of this point the attendees have been Doug_Schepers, ed, tbah, Rick, heycam, Oliver_Goldman, ChrisL 21:49:13 RRSAgent, please draft minutes 21:49:13 I have made the request to generate http://www.w3.org/2011/06/23-svg-minutes.html trackbot 21:49:14 RRSAgent, bye 21:49:14 I see 5 open action items saved in http://www.w3.org/2011/06/23-svg-actions.rdf : 21:49:14 ACTION: ITEM to CL to talk to Microsoft to see if they can host the joint FX meeting. [1] 21:49:14 recorded in http://www.w3.org/2011/06/23-svg-irc#T20-14-52 21:49:14 ACTION: CL to talk to Microsoft to see if they can host the joint FX meeting. [2] 21:49:14 recorded in http://www.w3.org/2011/06/23-svg-irc#T20-15-01 21:49:14 ACTION: CM to email Peter Linss to coordinate on using the test harness in the SVG WG. [3] 21:49:14 recorded in http://www.w3.org/2011/06/23-svg-irc#T20-26-18 21:49:14 ACTION: Cameron to email Peter Linss to coordinate on using the test harness in the SVG WG. [4] 21:49:14 recorded in http://www.w3.org/2011/06/23-svg-irc#T20-26-33 21:49:14 ACTION: Vincent to put together a wiki page to capture requirements for the SVG 2.0 test suite. [5] 21:49:14 recorded in http://www.w3.org/2011/06/23-svg-irc#T20-50-48