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

Minutes, May 20 2009 SVG WG telcon

From: Anthony Grasso <anthony.grasso@cisra.canon.com.au>
Date: Wed, 20 May 2009 18:03:21 +1000
Message-ID: <4A13B949.9050905@cisra.canon.com.au>
To: "public-svg-wg@w3.org" <public-svg-wg@w3.org>
http://www.w3.org/2009/05/20-svg-minutes.html

---


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                    SVG Working Group Teleconference

20 May 2009

    [2]Agenda

       [2] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0144.html

    See also: [3]IRC log

       [3] http://www.w3.org/2009/05/20-svg-irc

Attendees

    Present
           Doug_Schepers, ed, anthony, jwatt, ChrisL

    Regrets
           Cameron

    Chair
           Erik

    Scribe
           anthony

Contents

      * [4]Topics
          1. [5]ISSUE-2271 - Add mechanism for variable stroke width (as
             in calligraphy)
          2. [6]ISSUE-2015 - Should the svg element provide a duration
             element?
          3. [7]ISSUE-2022 - The activation behaviour of <a> elements
             should be defined
          4. [8]ISSUE-2024 - Elements for which "defer" can be used in
             preserveAspectRatio=""
          5. [9]ISSUE-2040 (Related to ISSUE-2045) - Consider adding
             placeholders or fallback for unresolved resources
          6. [10]ISSUE-2054 - Consider removing the requirement for
             @width and @height for <foreignObject>
          7. [11]ISSUE-2042
      * [12]Summary of Action Items
      _________________________________________________________



    <trackbot> Date: 20 May 2009

    <scribe> Scribe: anthony

ISSUE-2271 - Add mechanism for variable stroke width (as in
calligraphy)

    ISSUE-2271?

    <trackbot> ISSUE-2271 -- Add mechanism for variable stroke width (as
    in calligraphy) -- RAISED

    <trackbot> [13]http://www.w3.org/Graphics/SVG/WG/track/issues/2271

      [13] http://www.w3.org/Graphics/SVG/WG/track/issues/2271

    ED: For us to consider way of doing variable stroke widths
    ... this is feature that's been requested a couple of times

    DS: I pointed to the threads there
    ... I pointed to my very early proposal
    ... not sure exactly how we should do it
    ... may or may not be able to do it with Vector Effects
    ... it's not hard to do this, it's just had to figure out the right
    way to specify these things

    ED: There is a mention here of one of the inkscape implementers
    ... have you spoken to him?

    DS: No, but he's very supportive of having this
    ... most Inkscape implementers like the idea
    ... they've implemented something
    ... but they just do it as a path
    ... We should do a little more research into how we could do it

    ED: Two things to do
    ... talk to the Inkscape guys
    ... and gather use case and requirements on the wiki

    <scribe> ACTION: Doug to Contact the Inkscape guys regarding
    variable stroke width (ideas, requirements) [recorded in
    [14]http://www.w3.org/2009/05/20-svg-minutes.html#action01]

    <trackbot> Created ACTION-2563 - Contact the Inkscape guys regarding
    variable stroke width (ideas, requirements) [on Doug Schepers - due
    2009-05-27].

    <heycam> shepazu, when you've uploaded the errata document and test
    cases could you ping me, and then i'll mail out the notification to
    www-svg mentioning the changes, thanks.

ISSUE-2015 - Should the svg element provide a duration element?

    ISSUE-2015

    ISSUE-2015?

    <trackbot> ISSUE-2015 -- Should the svg element provide a duration
    element? -- RAISED

    <trackbot> [15]http://www.w3.org/Graphics/SVG/WG/track/issues/2015

      [15] http://www.w3.org/Graphics/SVG/WG/track/issues/2015

    ED: This is about specifying intrinsic animation have an animation
    and want to use it in another file
    ... and you want to specify the duration
    ... we don't have a way to specify the duration at the moment

    AG: Has Opera done anything like this?

    ED: I think it would be easy to add a 'dur' attribute to the SVG
    root element
    ... I'd be in favour of this
    ... the question is where would this go
    ... in the structure chapter perhaps
    ... we don't have this as a module though
    ... we could add this to the main module
    ... or we could split the structure chapter into a module
    ... or a third option is specify this in a small file
    ... and stick it somewhere
    ... it would be useful to have something like this because it would
    animations much easier to reuse

    AG: I agree with putting it on the root element

    CL: This is so when an SVG is reference by another SVG element you
    say what the duration is?

    ED: Yes

    CL: Why can't you say that in the SVG itself
    ... on the animation element

    ED: You can specify the duration as a dur="media" on the animation
    element
    ... it's a good way of saying in the file how long your animation
    runs for

    AG: What about if the intrinsic duration was shorter than an
    animation in the file?

    ED: I guess the intrinsic duration is good for repeats
    ... may cut off the animation

    AG: I don't really have an opinion on it

    ED: I could email Julien to see what he thinks and what behaviour
    he'd expect
    ... I can also try this out in Opera

    <scribe> ACTION: Erik to Email Julien regarding intrinsic animation
    idea and what behaviour he'd expect [recorded in
    [16]http://www.w3.org/2009/05/20-svg-minutes.html#action02]

    <trackbot> Created ACTION-2564 - Email Julien regarding intrinsic
    animation idea and what behaviour he'd expect [on Erik Dahlström -
    due 2009-05-27].

ISSUE-2022 - The activation behaviour of <a> elements should be defined

    ISSUE-2022?

    <trackbot> ISSUE-2022 -- The activation behaviour of <a> elements
    should be defined -- RAISED

    <trackbot> [17]http://www.w3.org/Graphics/SVG/WG/track/issues/2022

      [17] http://www.w3.org/Graphics/SVG/WG/track/issues/2022

    ED: I had a look at the Tiny 1.2 spec
    ... it doesn't say that much
    ... doesn't have the text wording
    ... discussed in this issue
    ... we discussed it but I can't remember why it wasn't included in
    Tiny 1.2
    ... It looks like good wording to have

    <chrisl> suggested text looks good to me.

    CL: Text looks good to me

    <chrisl> clarifies, does not change conformance

    ED: Would this be ok to add as an errata

    <scribe> ACTION: Anthony to Add the wording discussed in ISSUE-2022
    to the Tiny 1.2 errata [recorded in
    [18]http://www.w3.org/2009/05/20-svg-minutes.html#action03]

    <trackbot> Created ACTION-2565 - Add the wording discussed in
    ISSUE-2022 to the Tiny 1.2 errata [on Anthony Grasso - due
    2009-05-27].

    AG: Category 3?

    CL: Yes I think so

ISSUE-2024 - Elements for which "defer" can be used in
preserveAspectRatio=""

    ISSUE-2024?

    <trackbot> ISSUE-2024 -- Elements for which "defer" can be used in
    preserveAspectRatio="" -- RAISED

    <trackbot> [19]http://www.w3.org/Graphics/SVG/WG/track/issues/2024

      [19] http://www.w3.org/Graphics/SVG/WG/track/issues/2024

    ED: Can have defer inside of a preserveAspectRatio attribute

    JW: You can't reference an SVG from the image element?

    ED: In Tiny 1.2 you can't
    ... in Full 1.1 you can
    ... this is basically 1.2 Tiny errata?
    ... personally I think it's good to reference SVG images in the
    image element
    ... and they be static images
    ... similar to the img tag in HTML behaves

    JW: As similar as possible

    CL: SVG Full 1.1 was a bit ambiguous about that
    ... and didn't really say what happened
    ... we really need to clarify that as well

    ED: This basically splits into two actions
    ... one for fixing Tiny 1.2
    ... and one for clarifying 2.0 Full

    AG: Should it be an Issue on 2.0 and an action on Tiny 1.2?

    <ed>
    [20]http://www.w3.org/TR/SVGMobile12/coords.html#PreserveAspectRatio
    Attribute

      [20] http://www.w3.org/TR/SVGMobile12/coords.html#PreserveAspectRatioAttribute

    ED: I think that would be a small fix up
    ... and I don't think it would effect conformance

    CL: So you're saying that it already says you can't reference
    images?
    ... which spec?

    ED: In the linking chapter

    <ed>
    [21]http://www.w3.org/TR/SVGMobile12/linking.html#ReferenceRestricti
    ons

      [21] http://www.w3.org/TR/SVGMobile12/linking.html#ReferenceRestrictions

    ED: In the table here
    ... the Image element is listed here
    ... won't get any visible results

    <ed> a reference to an SVG document in <image> would be an invalid
    IRI reference, and would mean the element doesn't render

    ED: This would be category 2 then

    <scribe> ACTION: Anthony to Add an errata item for Tiny 1.2 to
    remove the mention of "defer" in the image text [recorded in
    [22]http://www.w3.org/2009/05/20-svg-minutes.html#action04]

    <trackbot> Created ACTION-2566 - Add an errata item for Tiny 1.2 to
    remove the mention of "defer" in the image text [on Anthony Grasso -
    due 2009-05-27].

    <ed> to remove 'image' in the defer wording really, but ok :)

ISSUE-2040 (Related to ISSUE-2045) - Consider adding placeholders or
fallback for unresolved resources

    ISSUE-2040?

    <trackbot> ISSUE-2040 -- Consider adding placeholders or fallback
    for unresolved resources -- RAISED

    <trackbot> [23]http://www.w3.org/Graphics/SVG/WG/track/issues/2040

      [23] http://www.w3.org/Graphics/SVG/WG/track/issues/2040

    ED: About having a way to fallback when something is unresolved,
    like an image

    CL: Like a broken image icon?

    ED: In Tiny 1.2 when the link is broken you get an invalid IRI
    reference
    ... and nothing is rendered
    ... so you don't know it's missing

    JW: Could this be done with a CSS property
    ... it seems like that it's something common with specs

    ED: What type of CSS property where you thinking of?

    JW: Something new
    ... dunno what it would be called

    CL: The initial value would be the current behaviour
    ... then do you point to a certain image?
    ... or a browser broken image picture?
    ... we should avoid binary values
    ... what about point to something else in the same file
    ... where you say draw this if the image doesn't load

    JW: I was thinking about the HTML object tag

    CL: the object element allows you to have a child that displays the
    fallback content
    ... then in SMIL and SVG tend to do that with a switch
    ... not clear on what the condition would be
    ... another possibly would to evaluate whether the thing loaded

    DS: At one point we had wording in SVG Tiny 1.2
    ... that talked about what to do for fallback behaviour of raster
    images
    ... we took it out

    <chrisl> in general we seem to use switch here, so a test attribute
    looks like good solution

    DS: and I can't remember why

    JW: That's an interesting suggestion Chris

    CL: So this is something that evaluates to True if the IRI reference
    is resolved
    ... then obviously you could draw anything you wanted to
    ... text, image

    JW: Like in the object tag
    ... you can have nested objects
    ... until you find something that works
    ... I think it would be a good idea to have a cross spec solution

    CL: HTML has multiple ways of doing it
    ... I think currently if you put child content of an image it
    wouldn't be used as a fallback

    JW: I think that if you put this property in and it's consistent
    then it's something
    ... that could be deployed across documents
    ... I guess I need to come up with a more concrete suggestion

    ED: Two problems that we want to solve
    ... what to rendered if the content didn't specify and fallback and
    the link is broken
    ... and if you want some particular fallback behaviour how do you
    specify that
    ... the first one is a bit more easy to solve

    CL: We already have some of the options here
    ... At one point opera gives you a checkerboard if an image was
    broken

    ED: We used to

    CL: We got one of the options which is don't display anything
    ... the other two options there is no way to indicate what you want

    ED: There is external resources required
    ... which gives you an indication that something is broken

    CL: If we did have that for the switch case
    ... on the branch of the switch that has an image, you could put on
    there something says fail silently
    ... the reason I like the switch idea, is we already do that sort of
    thing
    ... we just need a test attribute to say if the link loaded or not

    JW: There scenarios?

    CL: A.svg points to an image
    ... only display it if it's completely correct
    ... option B is you fail silently
    ... option C is you fail with a visible indication
    ... don't have a way to specify B or C currently
    ... I suppose option D is the author provides a fallback and say
    explicitly what's to happen

    <jwatt> so I guess I was thinking of a CSS property something like
    this: on-failure-display: nothing | children | error-pattern

    CL: Error-pattern, would that be a link?

    <chrisl> ok so error-pattern means the default browser indication

    <jwatt> so I guess rather than error-pattern, you could want two
    things

    <jwatt> an error pattern specified by the spec and supplied by the
    UA

    <jwatt> or a link to another piece of markup in the doc, sort of
    like a <use>

    <jwatt> to provide your own pattern

    ED: Might be a way of solving it
    ... Suggest that the default value works based on what element it is
    on
    ... that's slightly different from Chris's idea of switching

    JW: It's not impossible to have two and let the user decide which
    one is better
    ... going to other groups and figure out their requirements and get
    feedback

    CL: Would you be prepared to write up an email to CSS and HTML with
    the proposal?
    ... I think it would be just the CSS group that would have feedback

    <chrisl> trackbot, status

    <scribe> ACTION: Jonathan to Write up an email proposing the JWatt
    idea for fallback behaviour [recorded in
    [24]http://www.w3.org/2009/05/20-svg-minutes.html#action05]

    <trackbot> Created ACTION-2567 - Write up an email proposing the
    JWatt idea for fallback behaviour [on Jonathan Watt - due
    2009-05-27].

    <scribe> ACTION: Chris to Write up an email proposing the Chris idea
    for fallback behaviour [recorded in
    [25]http://www.w3.org/2009/05/20-svg-minutes.html#action06]

    <trackbot> Created ACTION-2568 - Write up an email proposing the
    Chris idea for fallback behaviour [on Chris Lilley - due
    2009-05-27].

    ED: In the agenda I mention this issues is related to ISSUE-2045
    ... I'm not completely sure that this is exactly the same ore not
    ... but we have two that are very similar
    ... that issue has a note on it
    ... that comes from Bugzilla

    ISSUE-2045?

    <trackbot> ISSUE-2045 -- Consider adding fallback behavior -- RAISED

    <trackbot> [26]http://www.w3.org/Graphics/SVG/WG/track/issues/2045

      [26] http://www.w3.org/Graphics/SVG/WG/track/issues/2045

    ED: I'm just wondering if the issues are different in someway or if
    we can close one of them

    AG: They look the same
    ... could close 2045 and add a note to 2040

    ED: Ok, I'll do that

ISSUE-2054 - Consider removing the requirement for @width and @height
for <foreignObject>

    ISSUE-2054?

    <trackbot> ISSUE-2054 -- Consider removing the requirement for
    @width and @height for <foreignObject> -- RAISED

    <trackbot> [27]http://www.w3.org/Graphics/SVG/WG/track/issues/2054

      [27] http://www.w3.org/Graphics/SVG/WG/track/issues/2054

    CL: If you don't have width and height how do you figure out
    ... where to put it
    ... and how big it should be

    ED: The thing I was thinking of was use the width and height CSS
    properties
    ... allow them to define the size
    ... this mentions particularly MathML
    ... if you don't know what the size of the thing you embedded
    ... like the size of the MathML

    CL: Normally when we draw something you say what size it is
    ... what's the motivation for removing it?
    ... the audio case is different
    ... but for something that renders you'd want to say how big it is
    ... for audio the width and height would be 0

    ED: The audio wouldn't be heard

    CL: I seem to remember we discussed what was part of the render tree
    ... and if it was visual only

    ED: I do think it would be interesting to see if the width height
    CSS properties could be used
    ... such as the case where you have the SVG root element inside an
    XHTML document
    ... and you have width and height in CSS
    ... the size is negotiated
    ... so it probably be possible to do something with the elements
    that use width and height
    ... It would go inline with what Doug was suggesting
    ... which is make the SVG attributes into properties
    ... I would personally think that it would be interesting to specify
    width and height in CSS
    ... for the case where you have a bunch of images
    ... would there be any problems with trying to specifying something
    like this

    CL: Depends, I'd like to see how it would work
    ... need to consider the geometrical layout which is crucial for SVG

    <scribe> ACTION: Erik to Draft a proposal to have width and height
    properties [recorded in
    [28]http://www.w3.org/2009/05/20-svg-minutes.html#action07]

    <trackbot> Created ACTION-2569 - Draft a proposal to have width and
    height properties [on Erik Dahlström - due 2009-05-27].

ISSUE-2042

    ISSUE-2042?

    <trackbot> ISSUE-2042 -- Consider adding adding non-NS linking
    syntax -- RAISED

    <trackbot> [29]http://www.w3.org/Graphics/SVG/WG/track/issues/2042

      [29] http://www.w3.org/Graphics/SVG/WG/track/issues/2042

    ED: This us for consider adopting link:href in svg as href
    ... there has been a thread going on in SVG www
    ... I think Robin B seemed to be against it

    CL: That's odd in his XML paper he was arguing the other way
    ... maybe he's saying the change is too much now we already got it

    ED: That's the impression I got
    ... it would be a pretty big change
    ... to have some kind of alias
    ... it would be kind of messy at least in a transitional phase

    CL: We would need to say what happens if you put in both
    ... xlink:href and href

    ED: Some chases where it is problematic
    ... HTML uses different names
    ... for the hrefs on different tags

    CL: It's not only href
    ... there is somethings that give a src vs href functionality
    ... which mean different things

    ED: The question is then, is that more confusing
    ... ore less confusing

    CL: xlink always had an attribute that says whether it's replace or
    embed

    ED: xlink:show maybe?

    CL: That's the one

    ED: And we probably have about zero tests for that?

    CL: Right, but it's providing metadata
    ... it's telling something that knows about xlink but not about SVG
    what to do
    ... of course the number things that understand xlink and not SVG is
    zero
    ... this has come up before in discussion
    ... that if you were going to redesign xlink how would you do it
    ... they'd be remapped to ref and src

    ED: There are three values new, replace, embed

    CL: Instead of taking a single attribute that takes the URI, you'd
    have three ones that would take the URI and tell you what to do with
    it

    <ed> (xlink spec says also 'other' and 'none')

    CL: there are other things that xlink does as well
    ... which xlink:rel
    ... specifies relationships

    ED: If we were to replace or make a new name for the hrefs, which
    would be?

    CL: I'd tend to favour replacing href

    ED: And that would be overriding or the same?

    CL: It depends on our fallback strategy
    ... depends on if people want to write content that worked in both
    ... could have a similar situation with xml:id
    ... one possibility is you can specify href every where xlink:href
    can be put
    ... href takes priority

    ED: I'd make content with href and have a script
    ... that fixes it
    ... for older implementations
    ... there are some cases where that doesn't work
    ... I guess we should the whole thread on www-svg
    ... together
    ... then propose something, based on what everyone is saying

    <scribe> ACTION: Chris to Go through the www-svg list regarding
    link:href and make a proposal based on the feedback [recorded in
    [30]http://www.w3.org/2009/05/20-svg-minutes.html#action08]

    <trackbot> Created ACTION-2570 - Go through the www-svg list
    regarding link:href and make a proposal based on the feedback [on
    Chris Lilley - due 2009-05-27].

Summary of Action Items

    [NEW] ACTION: Anthony to Add an errata item for Tiny 1.2 to remove
    the mention of "defer" in the image text [recorded in
    [31]http://www.w3.org/2009/05/20-svg-minutes.html#action04]
    [NEW] ACTION: Anthony to Add the wording discussed in ISSUE-2022 to
    the Tiny 1.2 errata [recorded in
    [32]http://www.w3.org/2009/05/20-svg-minutes.html#action03]
    [NEW] ACTION: Chris to Go through the www-svg list regarding
    link:href and make a proposal based on the feedback [recorded in
    [33]http://www.w3.org/2009/05/20-svg-minutes.html#action08]
    [NEW] ACTION: Chris to Write up an email proposing the Chris idea
    for fallback behaviour [recorded in
    [34]http://www.w3.org/2009/05/20-svg-minutes.html#action06]
    [NEW] ACTION: Doug to Contact the Inkscape guys regarding variable
    stroke width (ideas, requirements) [recorded in
    [35]http://www.w3.org/2009/05/20-svg-minutes.html#action01]
    [NEW] ACTION: Erik to Draft a proposal to have width and height
    properties [recorded in
    [36]http://www.w3.org/2009/05/20-svg-minutes.html#action07]
    [NEW] ACTION: Erik to Email Julien regarding intrinsic animation
    idea and what behaviour he'd expect [recorded in
    [37]http://www.w3.org/2009/05/20-svg-minutes.html#action02]
    [NEW] ACTION: Jonathan to Write up an email proposing the JWatt idea
    for fallback behaviour [recorded in
    [38]http://www.w3.org/2009/05/20-svg-minutes.html#action05]

    [End of minutes]
      _________________________________________________________


     Minutes formatted by David Booth's [39]scribe.perl version 1.135
     ([40]CVS log)
     $Date: 2009/05/20 08:01:32 $
      _________________________________________________________

      [39] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [40] 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 [41]http://dev.w3.org/cvsweb/~checkout~/2002
/scribe/

      [41] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/implementors/implementers/
Succeeded: s/media/dur="media"/
Succeeded: s/element/element?/
Succeeded: s/img/object/
Succeeded: s/decide which/let the user decide which/
Succeeded: s/:href//
Found Scribe: anthony
Inferring ScribeNick: anthony
Default Present: Doug_Schepers, ed, anthony, jwatt, ChrisL
Present: Doug_Schepers ed anthony jwatt ChrisL
Regrets: Cameron
Agenda: [42]http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJu
n/0144.html
Found Date: 20 May 2009
Guessing minutes URL: [43]http://www.w3.org/2009/05/20-svg-minutes.html
People with action items: anthony chris doug erik jonathan

      [42] http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0144.html
      [43] http://www.w3.org/2009/05/20-svg-minutes.html

    End of [44]scribe.perl diagnostic output]

      [44] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Wednesday, 20 May 2009 08:04:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 20 May 2009 08:04:12 GMT