- From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
- Date: Mon, 18 May 2009 22:27:59 +1000
- To: public-svg-wg@w3.org
http://www.w3.org/2009/05/18-svg-minutes.html
---
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
18 May 2009
[2]Agenda
[2] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0139.html
See also: [3]IRC log
[3] http://www.w3.org/2009/05/18-svg-irc
Attendees
Present
heycam, ed, Doug_Schepers, anthony, jwatt, ChrisL
Regrets
Chair
Cameron
Scribe
anthony
Contents
* [4]Topics
1. [5]Revision of Param Spec
2. [6]"Clarify getSVGDocument behavior" erratum
3. [7]"Clarification of lineto commands in the path syntax"
erratum for 1.2T
* [8]Summary of Action Items
_________________________________________________________
<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>
[9]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0137
.html
[9] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0137.html
<shepazu>
[10]http://dev.w3.org/SVG/modules/param/master/SVGParam.html
[10] http://dev.w3.org/SVG/modules/param/master/SVGParam.html
<shepazu>
[11]http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html
[11] 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>
[12]http://dev.w3.org/SVG/modules/param/master/SVGParamPrimer.html
[12] 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:
[13]http://www.xmlprague.cz/2009/presentations/XMLPrague_2009_procee
dings.pdf )
[13] 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
[14]http://www.w3.org/mid/20090515053055.GH11882@arc.mcc.id.au
[14] 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>
[15]http://www.w3.org/2003/01/REC-SVG11-20030114-errata#clarify-gets
vgdocument-behavior
[15]
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
[16]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>
[17]http://dev.w3.org/SVG/profiles/1.1F2/errata/REC-SVG11-20030114-e
rrata.html
[17]
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 [18]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>
[19]http://mcc.id.au/temp/2009/svg11-first-to-second-edition-diffs/
[19] http://mcc.id.au/temp/2009/svg11-first-to-second-edition-diffs/
<ChrisL> stroke-width="url(#foo)"
Summary of Action Items
[NEW] ACTION: Anthony to Copy the erratum "Clarification of lineto
commands in the path syntax" to the Tiny 1.2 errata [recorded in
[20]http://www.w3.org/2009/05/18-svg-minutes.html#action02]
[NEW] ACTION: Cameron to Modify the erratum "Clarify getSVGDocument
behavior" to also highlight the change require in the IDL [recorded
in [21]http://www.w3.org/2009/05/18-svg-minutes.html#action01]
[End of minutes]
_________________________________________________________
Minutes formatted by David Booth's [22]scribe.perl version 1.135
([23]CVS log)
$Date: 2009/05/18 08:01:20 $
_________________________________________________________
[22] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[23] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20
Check for newer version at [24]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/
[24] 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: [25]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu
n/0139.html
Found Date: 18 May 2009
Guessing minutes URL: [26]http://www.w3.org/2009/05/18-svg-minutes.html
People with action items: anthony cameron
[25] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0139.html
[26] http://www.w3.org/2009/05/18-svg-minutes.html
End of [27]scribe.perl diagnostic output]
[27] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Monday, 18 May 2009 12:28:47 UTC