See also: IRC log
<trackbot> Date: 18 May 2009
<scribe> Scribe: anthony
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
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
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)"
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/Primier/Primer/ Succeeded: s/DL/DS/ Succeeded: s/... I/DS: I/ Succeeded: s/conflicts/chameleon namespace/ Succeeded: s/reference/referenced/ Found Scribe: anthony Inferring ScribeNick: anthony Default Present: heycam, ed, Doug_Schepers, anthony, jwatt, ChrisL Present: heycam ed Doug_Schepers anthony jwatt ChrisL Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0139.html Found Date: 18 May 2009 Guessing minutes URL: http://www.w3.org/2009/05/18-svg-minutes.html People with action items: anthony cameron[End of scribe.perl diagnostic output]