W3C home > Mailing lists > Public > public-svg-wg@w3.org > April to June 2009

Minutes, 18 May 2009 SVG WG telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Mon, 18 May 2009 22:27:59 +1000
Message-ID: <4A11544F.50002@cisra.canon.com.au>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 18 May 2009 12:28:49 GMT