06:32:46 RRSAgent has joined #svg 06:32:47 logging to http://www.w3.org/2009/05/18-svg-irc 06:32:48 RRSAgent, make logs public 06:32:49 Zakim has joined #svg 06:32:50 Zakim, this will be GA_SVGWG 06:32:50 ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start 2 minutes ago 06:32:51 Meeting: SVG Working Group Teleconference 06:32:51 Date: 18 May 2009 06:33:20 GA_SVGWG()2:30AM has now started 06:33:28 +??P0 06:33:32 Zakim, ??P0 is me 06:33:32 +heycam; got it 06:33:41 +[IPcaller] 06:33:53 +??P2 06:33:57 Zakim, ??P2 06:33:57 I don't understand '??P2', ed 06:34:00 Zakim, ??P2 is me 06:34:00 +ed; got it 06:35:03 +Doug_Schepers 06:35:07 +??P3 06:35:11 Zakim, ??P3 is me 06:35:11 +anthony; got it 06:35:15 Zakim, who's here? 06:35:15 On the phone I see heycam, [IPcaller], ed, Doug_Schepers, anthony 06:35:16 On IRC I see RRSAgent, heycam, jwatt, anthony, ed, ed_work, shepazu, karl, trackbot 06:35:33 Zakim, [IPCaller] is me 06:35:33 +jwatt; got it 06:35:54 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0139.html 06:35:57 Chair: Cameron 06:36:16 Scribe: anthony 06:36:31 Topic: Revision of Param Spec 06:36:55 +ChrisL 06:37:03 ChrisL has joined #svg 06:37:05 DS: I basically, changed the params spec around 06:37:08 ... a fair bit 06:37:27 ... I took out the ref element 06:37:31 ... and added the param elemnt 06:37:41 http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0137.html 06:37:44 http://dev.w3.org/SVG/modules/param/master/SVGParam.html 06:37:45 http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html 06:37:56 ... which is equivalent to the object param in HTML 06:38:19 ... I basically the param functional notation takes the parameter name as an argument 06:38:26 ... as opposed to the indirection I had before 06:38:34 ... it also highlights how you can use the fall back value 06:38:45 ... instead of having to use a separate element for that 06:39:17 ... you use it a second value for the param property 06:39:43 attribute-name="param(string) [optional-string]" 06:40:09 DS: Optional string would be the default value 06:40:20 ... I also cleaned up the IDL 06:40:33 ... for the parameters and the window parameter interfaces 06:40:49 ... and started talking about how we might put params into CSS 06:41:07 ... I reworked all the examples in the Primier 06:41:15 s/Primier/Primer/ 06:41:18 ... to use the new syntax 06:41:25 http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html 06:41:34 ... I added an example for adding parameterised use elements 06:41:44 ... the very last example 06:42:38 ... we've talked about how markers and use elements, it's hard to do anything useful with them 06:42:45 ... if you want to change parameters on them 06:42:57 CM: One advantage of this parameterisation use here 06:43:08 ... is it's not very heavy weight 06:43:25 ... substituting in one value is pretty easy 06:43:38 DS: With different values you can get quite different results 06:44:01 CM: Basically when you evaluate paint server references, you evaluate the paint at that point 06:44:10 ... rather than the definition time 06:44:15 DS: When you are using something 06:44:19 ... the shadow tree is changed 06:44:29 ... it's treated at its own document 06:45:20 ... I don't see how you could it any other way 06:45:30 CM: Probably the way implementations are handling paint servers 06:45:34 ... might have to change 06:45:56 ... they are kind of global at the moment, well their instances are 06:46:06 ... that scoped thing could be interesting anyway 06:46:18 DS: I resolved that in the my script library by cloning the element 06:46:26 ... then changing the IDs and ID refs 06:46:45 ... this kind of effects use 06:46:55 So, can you say ? 06:47:11 CM: It would be interesting to see what XBL does 06:47:24 CL: Obviously it has to solve the same problem 06:47:36 ... Is this restricted or can you use it on any attribute? 06:47:55 DS: The way I saw it was that it could be used by any attribute 06:48:00 ... yes, could be used on a path 06:48:25 suggest another example where an animation is parameterised, in that case 06:48:26 ... the way I'd like to see it is, that for elements with attribute values that don't take lists you can use the fallback 06:48:36 ... for the ones that do take lists you can't use the fall back 06:49:00 CL: I suggest in that case to provide an animation example 06:49:05 ... if you provide it as a child 06:49:08 ... then parameterise that 06:49:15 ... you could have multiple ones of them 06:49:29 DL: You might want to use this as only part of a value 06:49:34 [[ 06:49:36 For user agents which conform to this specification, the ‘param’ attribute value must be available as a value on any SVG attribute. For attributes which take a list as a value, each ‘param’ attribute value used shall constitute a separate value on that list. For attributes which do not take a list as a value, the following syntax must be applied to attribute values which use a ‘param’ attribute value: 06:49:43 ]] 06:49:55 could you do ? 06:49:58 s/DL/DS/ 06:50:06 DS: [reads out text] 06:50:12 ... ED, exactly, yes 06:50:29 ... You could pass in parameters that would be components of a path 06:50:40 ... you could get some rather interesting effects that way 06:50:57 ED: My question was is it possible to have multiple levels of params? 06:51:04 DS: I think that might complicate things 06:51:09 ... I can see a use for it 06:51:22 ... Looking at the flower example 06:51:25 ... if we had that 06:51:28 ... and some of the values 06:51:32 ... instead of a gradient 06:51:36 ... they wanted a solid fill 06:51:42 ... they could just pass in a single value 06:51:58 ... then in the gradient I could say, in stop one use petal one 06:52:06 ... and for stop two use petal two 06:52:13 ... and if they don't provide one 06:52:17 ... use the previous 06:53:16 CM: You're not really thinking of it as a string substitution in the list? 06:53:18 DS: I am 06:53:29 CL: That is not clear from the spec currently 06:53:33 DS: I think you're right 06:54:19 CL: Might need to define how to do the parsing 06:54:22 ... two level parsing model 06:54:33 ... when you construct the attribute with the param 06:54:39 ... then parse it as per normal 06:54:42 ... that needs to be defined 06:54:53 ... A two stage parsing thing might be a good thing to point out 06:55:12 CM: Advantages I saw to using this functional syntax is 06:55:20 ... it gels well with CSS properties 06:55:37 first stage looks for params and the second stage parses the result according to whatever the attribute value was originally defined as 06:55:41 ... There may be more scope with conflicts with values that can be accepted at th emoment 06:55:56 DS: I think if we going to do something like this, now is the time to do it 06:56:12 CM: I can see people saying why not use the braces similar to XSLT 06:56:26 DS: Curly braces? 06:56:30 CM: Yes 06:56:42 DS: That would match what Adobe do FXG 06:56:52 ... it's their universal interchange format for XML 06:56:58 ... for all their products 06:57:10 ... there is post about why they didn't use SVG 06:58:18 ... I'm fine with that idea of use braces 06:58:28 ... if we are going to more with it like Calc 06:58:33 ... then might have problems 06:58:43 ... not concerned about the syntax at the moment 06:58:51 CM: Might consider doing it that way 06:58:57 ... if it's string substitution 06:59:27 ... it's what level you think that it is operating on 06:59:43 ... if you are using the CSS DOM to get the value of param 06:59:51 ... what do you get? 07:00:04 CL: What you should get back is what you would've gotten back normally 07:00:15 ... the only difference is you give it an ID to later change it 07:00:49 DS: Currently it's a similar model to CSS 07:01:07 CM: Maybe it makes sense to expose the computed things in the animated DOM 07:01:55 DS: Ultimately all these things should be moving to the same model 07:02:00 ... where it makes sense 07:02:08 ... I modified my script library 07:02:18 ... to take into account this param use syntax 07:02:27 ... It did increase the size of my code 07:02:36 ... but I did have to implement a fake shadow tree 07:02:49 ... for people that already implement a shadow tree 07:03:02 .. it shouldn't be too much of a burden 07:03:22 ED: I'm wondering if this spec here is saying we are adding a param in the SVG name space? 07:03:27 ... I don't think that is a good idea 07:03:33 ... because it will conflict with HTML param 07:03:44 ... and it's similar to what we are doing with listener 07:03:55 ... I think it would be better to say that this element is from HTML 07:03:58 ... and is that name space 07:04:07 ... I sent an email to SVG and to HTML 07:04:20 s/... I/DS: I/ 07:04:33 DS: Us adding elements into the SVG name space would be a good thing 07:04:37 ... from what I gathered 07:04:47 ... I do understand the about the conflicts problem 07:05:22 CL: On one hand you don't want to be flipping between SVG and HTML 07:05:30 s/conflicts/chameleon namespace/ 07:06:11 A problem with requiring having namespaced to be in HTML is that people will use a prefix, and that that's not going to work well with SVG parsing in text/html. 07:06:44 ED: But if you're parsing param elements in Text HTML 07:06:51 ... you'd get the param element in HTML by default at the moment 07:06:59 CM: So something has to be changed 07:07:31 DS: I thought about it, if it comes down to us pleasing the HTML working group vs making things easier for authors 07:07:35 Designing XML/Web Languages: A Review of Common Mistakes 07:07:39 ... I'd rather make things easier for authors 07:08:08 CL: If you look at Robin's paper he calls it out as a specific thing 07:08:18 ... we should've brought that stuff into our own name space 07:08:24 ... which is reasonable 07:08:38 DS: In support of that, if we are thinking about the open web stack 07:09:13 ... having features in one language in another language helps people understand that feature in the other language 07:10:44 ... There was another piece of feedback from Robin 07:10:57 ... if you're going to import param, import object 07:11:04 ... just use object 07:11:23 ... and don't change the inheritance model of use 07:11:35 CL: I think we are already changing the inheritance model 07:12:18 CM: use is a pain to implement, because you copy the exact same properties of an element 07:12:25 DS: We could make a new element 07:12:36 ... that isn't a pain to implement 07:12:59 ... we could rely on the params spec to change various different things 07:13:22 ... for now I think we should say we have a param element, anything that references can use it 07:13:44 ... we could make a property called "parameters" that would take a name of list value pairs 07:13:59 ... it could also be use from within CSS as well 07:14:33 CL: If we start saying things like you can use this with any CSS property we may run into trouble 07:14:39 DS: We'd have to check with them first 07:15:02 ... this one would just be "parameters" the only thing it does is it passes in parameters 07:15:41 CM: How is the referencing of parameters done with that? 07:15:49 parameters="fill=param(whatever), ..." 07:16:04 DS: It would be a pass in parameters 07:16:12 ... not a way to receive parameters 07:16:47 parameters="color:red; outline:green; label:hello;" 07:17:11 DS: Instead of having a param element you'd have this property 07:17:40 CM: So what Chris said about defining how CSS properties work, this would still have that problem? 07:17:43 DS: Yes 07:17:56 (found robinb's paper: http://www.xmlprague.cz/2009/presentations/XMLPrague_2009_proceedings.pdf ) 07:18:15 DS: I don't think the spec is done yet 07:18:21 ... I'll take this feedback into account 07:18:31 ... it's a better syntax and a better mechanism 07:18:55 ... I'd like to republish with the new syntax and examples 07:19:00 CL: I have no problems with that 07:19:41 ED: Does the spec define what happens if you change the param in another document? 07:19:47 ... does it have the resource 07:19:53 ... is that implementation independent 07:20:16 ... I'm not 100% sure if you change those params if they have some effect on the plug in for example 07:20:28 ... I think it should be defined what should happen in such cases 07:20:33 DS: I have defined it in the spec 07:20:40 ED: Ok, maybe I haven't seen it 07:20:46 DS: Let me see if I can find it 07:20:56 CM: Plug ins if they want to notice changed param values 07:21:04 ... they can look up the document watch those things 07:21:07 [[ 07:21:09 The user agent must make all of these parameters which have been set at the load time of the target file immediately available, and must also update the list of parameters immediately within the file when they are changed in the referencing file, or in the URL query string. 07:21:11 ]] 07:22:03 DS: If somebody changes something, then it should change straight away 07:22:11 ... I'm not sure if that's even defined in HTML 5 07:22:43 Not sure propagating changes to URL query string parameters to the param()s in the SVG document makes sense. 07:22:48 -anthony 07:22:55 yeah thats a difference betweena query string and a fragment. ? gets sent to the server 07:23:05 Since the query string is outside the document; changing those in the