SVG Working Group Teleconference -- 18 May 2009

<trackbot> Date: 18 May 2009

<scribe> Scribe: anthony

Revision of Param Spec

DS: I basically, changed the params spec around
... a fair bit
... I took out the ref element
... and added the param elemnt

<shepazu> http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0137.html

<shepazu> http://dev.w3.org/SVG/modules/param/master/SVGParam.html

<shepazu> http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html

DS: which is equivalent to the object param in HTML
... I basically the param functional notation takes the parameter name as an argument
... as opposed to the indirection I had before
... it also highlights how you can use the fall back value
... instead of having to use a separate element for that
... you use it a second value for the param property

<shepazu> attribute-name="param(string) [optional-string]"

DS: Optional string would be the default value
... I also cleaned up the IDL
... for the parameters and the window parameter interfaces
... and started talking about how we might put params into CSS
... I reworked all the examples in the Primer
... to use the new syntax

<shepazu> http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html

DS: I added an example for adding parameterised use elements
... the very last example
... we've talked about how markers and use elements, it's hard to do anything useful with them
... if you want to change parameters on them

CM: One advantage of this parameterisation use here
... is it's not very heavy weight
... substituting in one value is pretty easy

DS: With different values you can get quite different results

CM: Basically when you evaluate paint server references, you evaluate the paint at that point
... rather than the definition time

DS: When you are using something
... the shadow tree is changed
... it's treated at its own document
... I don't see how you could it any other way

CM: Probably the way implementations are handling paint servers
... might have to change
... they are kind of global at the moment, well their instances are
... that scoped thing could be interesting anyway

DS: I resolved that in the my script library by cloning the element
... then changing the IDs and ID refs
... this kind of effects use

<ChrisL> So, can you say <path d="param(foo) M1 2 L 3 4" /> ?

CM: It would be interesting to see what XBL does

CL: Obviously it has to solve the same problem
... Is this restricted or can you use it on any attribute?

DS: The way I saw it was that it could be used by any attribute
... yes, could be used on a path

<ChrisL> suggest another example where an animation is parameterised, in that case

DS: 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
... for the ones that do take lists you can't use the fall back

CL: I suggest in that case to provide an animation example
... if you provide it as a child
... then parameterise that
... you could have multiple ones of them

DS: You might want to use this as only part of a value

<shepazu> [[

<shepazu> 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:

<shepazu> ]]

<ed> could you do <path d="param(foo) param(bar) M1 0 ..."> ?

DS: [reads out text]
... ED, exactly, yes
... You could pass in parameters that would be components of a path
... you could get some rather interesting effects that way

ED: My question was is it possible to have multiple levels of params?

DS: I think that might complicate things
... I can see a use for it
... Looking at the flower example
... if we had that
... and some of the values
... instead of a gradient
... they wanted a solid fill
... they could just pass in a single value
... then in the gradient I could say, in stop one use petal one
... and for stop two use petal two
... and if they don't provide one
... use the previous

CM: You're not really thinking of it as a string substitution in the list?

DS: I am

CL: That is not clear from the spec currently

DS: I think you're right

CL: Might need to define how to do the parsing
... two level parsing model
... when you construct the attribute with the param
... then parse it as per normal
... that needs to be defined
... A two stage parsing thing might be a good thing to point out

CM: Advantages I saw to using this functional syntax is
... it gels well with CSS properties

<ChrisL> first stage looks for params and the second stage parses the result according to whatever the attribute value was originally defined as

CM: There may be more scope with conflicts with values that can be accepted at th emoment

DS: I think if we going to do something like this, now is the time to do it

CM: I can see people saying why not use the braces similar to XSLT

DS: Curly braces?

CM: Yes

DS: That would match what Adobe do FXG
... it's their universal interchange format for XML
... for all their products
... there is post about why they didn't use SVG
... I'm fine with that idea of use braces
... if we are going to more with it like Calc
... then might have problems
... not concerned about the syntax at the moment

CM: Might consider doing it that way
... if it's string substitution
... it's what level you think that it is operating on
... if you are using the CSS DOM to get the value of param
... what do you get?

CL: What you should get back is what you would've gotten back normally
... the only difference is you give it an ID to later change it

DS: Currently it's a similar model to CSS

CM: Maybe it makes sense to expose the computed things in the animated DOM

DS: Ultimately all these things should be moving to the same model
... where it makes sense
... I modified my script library
... to take into account this param use syntax
... It did increase the size of my code
... but I did have to implement a fake shadow tree
... for people that already implement a shadow tree
... it shouldn't be too much of a burden

ED: I'm wondering if this spec here is saying we are adding a param in the SVG name space?
... I don't think that is a good idea
... because it will conflict with HTML param
... and it's similar to what we are doing with listener
... I think it would be better to say that this element is from HTML
... and is that name space

DS: I sent an email to SVG and to HTML
... Us adding elements into the SVG name space would be a good thing
... from what I gathered
... I do understand the about the chameleon namespace problem

CL: On one hand you don't want to be flipping between SVG and HTML

<heycam> A problem with requiring having <param> 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.

ED: But if you're parsing param elements in Text HTML
... you'd get the param element in HTML by default at the moment

CM: So something has to be changed

DS: I thought about it, if it comes down to us pleasing the HTML working group vs making things easier for authors

<ChrisL> Designing XML/Web Languages: A Review of Common Mistakes

DS: I'd rather make things easier for authors

CL: If you look at Robin's paper he calls it out as a specific thing
... we should've brought that stuff into our own name space
... which is reasonable

DS: In support of that, if we are thinking about the open web stack
... having features in one language in another language helps people understand that feature in the other language
... There was another piece of feedback from Robin
... if you're going to import param, import object
... just use object
... and don't change the inheritance model of use

CL: I think we are already changing the inheritance model

CM: use is a pain to implement, because you copy the exact same properties of an element

DS: We could make a new element
... that isn't a pain to implement
... we could rely on the params spec to change various different things
... for now I think we should say we have a param element, anything that references can use it
... we could make a property called "parameters" that would take a name of list value pairs
... it could also be use from within CSS as well

CL: If we start saying things like you can use this with any CSS property we may run into trouble

DS: We'd have to check with them first
... this one would just be "parameters" the only thing it does is it passes in parameters

CM: How is the referencing of parameters done with that?

<heycam> parameters="fill=param(whatever), ..."

DS: It would be a pass in parameters
... not a way to receive parameters

<shepazu> parameters="color:red; outline:green; label:hello;"

DS: Instead of having a param element you'd have this property

CM: So what Chris said about defining how CSS properties work, this would still have that problem?

DS: Yes

<ChrisL> (found robinb's paper: http://www.xmlprague.cz/2009/presentations/XMLPrague_2009_proceedings.pdf )

DS: I don't think the spec is done yet
... I'll take this feedback into account
... it's a better syntax and a better mechanism
... I'd like to republish with the new syntax and examples

CL: I have no problems with that

ED: Does the spec define what happens if you change the param in another document?
... does it have the resource
... is that implementation independent
... I'm not 100% sure if you change those params if they have some effect on the plug in for example
... I think it should be defined what should happen in such cases

DS: I have defined it in the spec

ED: Ok, maybe I haven't seen it

DS: Let me see if I can find it

CM: Plug ins if they want to notice changed param values
... they can look up the document watch those things

<shepazu> [[

<shepazu> 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.

<shepazu> ]]

DS: If somebody changes something, then it should change straight away
... I'm not sure if that's even defined in HTML 5

<heycam> Not sure propagating changes to URL query string parameters to the param()s in the SVG document makes sense.

<ChrisL> yeah thats a difference betweena query string and a fragment. ? gets sent to the server

<heycam> Since the query string is outside the document; changing those in the <object data=""> would refetch a document.

CM: I noticed your button examples work in FF now

DS: I could've made them work before
... I was punishing FF for not having Tref
... I just went ahead and changing the implementation

CM: Where you asking whether we agree to publish this now?

DS: I say publish early publish often

CL: Your flowers don't work in Opera

ED: What version do they work in?

CL: FF beta 4

DS: I change the code quite a lot
... it is possible I didn't change the code for every browser
... your right
... it doesn't work in Opera

ED: I can have a look at it later
... I suspect it could be shadow tree stuff

DS: Probably something funky going on in my code

CL: Everything works except the flowers in Opera

CM: Are there any objections to republishing this?

[None heard]

RESOLUTION: We will republish the params specification

DS: The map is really stylised, it's not meant to be a real map
... I have an error in my code
... in Opera

"Clarify getSVGDocument behavior" erratum

http://www.w3.org/mid/20090515053055.GH11882@arc.mcc.id.au

CM: Was going through the errata document
... to get it ready for publishing

<heycam> http://www.w3.org/2003/01/REC-SVG11-20030114-errata#clarify-getsvgdocument-behavior

CM: came across one I was a bit unsure about
... this is about the getSVGDocument interface
... and the method of the same name
... the erratum says that this can return any object contained
... the IDL still says the method returns an SVG document
... so it's not possible to do this at the moment
... might want to change the IDL
... to have the return type of the document
... and keep that wording
... about it will return what ever document is being referenced
... the second aspect of it
... was implementing this interface on the HTML object element
... I think it might be a good idea to have an indication of where this interface might be implemented
... If we want it to be implemented for compatibility I think we should keep the wording about HTML object
... any thoughts?

ED: Sounds fine

AG: I think the IDL should be changed

<scribe> ACTION: Cameron to Modify the erratum "Clarify getSVGDocument behavior" to also highlight the change require in the IDL [recorded in http://www.w3.org/2009/05/18-svg-minutes.html#action01]

<trackbot> Created ACTION-2561 - Modify the erratum "Clarify getSVGDocument behavior" to also highlight the change require in the IDL [on Cameron McCormack - due 2009-05-25].

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-errata.html

CM: I have the errata in a nice form for publication
... can we get a resolution to publish the errata, pending the change from the action
... any objections?

[None heard]

RESOLUTION: We will publish the errata pending the change from the outstanding action of Cameron

"Clarification of lineto commands in the path syntax" erratum for 1.2T

CM: This issue applied Tiny 1.2 as well as Full 1.1
... the errata didn't get put into Tiny 1.2

<scribe> ACTION: Anthony to Copy the erratum "Clarification of lineto commands in the path syntax" to the Tiny 1.2 errata [recorded in http://www.w3.org/2009/05/18-svg-minutes.html#action02]

<trackbot> Created ACTION-2562 - Copy the erratum "Clarification of lineto commands in the path syntax" to the Tiny 1.2 errata [on Anthony Grasso - due 2009-05-25].

<heycam> http://mcc.id.au/temp/2009/svg11-first-to-second-edition-diffs/

<ChrisL> stroke-width="url(#foo)"

- DRAFT -

SVG Working Group Teleconference

18 May 2009

Attendees

Contents

Revision of Param Spec

"Clarify getSVGDocument behavior" erratum

"Clarification of lineto commands in the path syntax" erratum for 1.2T

Summary of Action Items

Scribe.perl diagnostic output