W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2011

minutes, 14 July 2011 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 15 Jul 2011 09:38:35 +1200
To: www-svg@w3.org
Message-ID: <20110714213835.GA11236@wok.mcc.id.au>
Minutes from today’s SVG WG telcon:


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

                               - DRAFT -

                   SVG Working Group Teleconference

14 Jul 2011


      [2] http://lists.w3.org/Archives/Public/public-svg-wg/2011JulSep/0018.html

   See also: [3]IRC log

      [3] http://www.w3.org/2011/07/14-svg-irc


          erik, vincent, cameron, doug, tav





     * [4]Topics
         1. [5]API for Media Resources 1.0
         2. [6]empty title elements
         3. [7]Status of SVG 1.1 Second Edition publication
         4. [8]Interest in SVG Parameters
         5. [9]textPath method="stretch"
     * [10]Summary of Action Items

   <trackbot> Date: 14 July 2011

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

API for Media Resources 1.0

   ED: spec requesting feedback from us


     [11] http://lists.w3.org/Archives/Public/www-svg/2011Jul/0034.html

   ED: it's about different interfaces for getting information about
   media resources
   ... a javascript api

   VH: are there implementations of the api?

   ED: good question, it's a last call working draft

   VH: second last call

   ED: is there interest in reviewing the spec?

   VH: I think at least someone should take a look and report back to
   ... a while back we were trying to get progress events in svg2, so
   it sounds related
   ... or is it for metadata?

   ED: it seems to be more fore metadata

   VH: not for the loading process?

   ED: doesn't look like it, but I haven't done a length review of the

   CM: I'd be curious to see what the HTMLWG thinks of it, given they
   are probably mainly thinking of HTML video

   <vhardy> [12]http://www.w3.org/2008/WebVideo/Annotations/#Implementa

     [12] http://www.w3.org/2008/WebVideo/Annotations/#Implementa

   ED: end of the review period is 7 August

   VH: shall we put it on the F2F agenda and see if anyone's had a
   chance to look at it before then?
   ... I've put it on the agenda

   <scribe> ACTION: Erik to mail the group list asking for review of
   the mediaont-api spec [recorded in

   <trackbot> Created ACTION-3064 - Mail the group list asking for
   review of the mediaont-api spec [on Erik Dahlström - due

empty title elements


     [14] http://lists.w3.org/Archives/Public/www-svg/2011Jul/0004.html

   VH: someone pointed out the differences between SVG Tiny 1.2 and 1.1
   ... I think the argument I made was that <title> was informative,
   and the fact that you could display titles as a tooltip was just a
   way of dealing with it
   ... so having tooltip-specific behaviour on <title> didn't seem
   ... Olaf pointed out that 1.2T talked more about tooltips

   DS: I think we need to have some standardised behaviour around
   ... I don't care if it's <title> or not
   ... are you saying that we shouldn't have tooltips around <title>?

   VH: we shouldn't assume that titles were exclusively for tooltips

   DS: sure, I agree with that

   ED: the 1.2T spec suggests to use role="tooltip" for title elements
   that are supposed to be tooltips


     [15] http://www.w3.org/TR/SVGTiny12/struct.html#uiTitleDescBehavior

   DS: it's a feature people expect

   "The title attribute represents advisory information for the
   element, such as would be appropriate for a tooltip."

   (that's in the HTML spec)

   DS: it seems the best would be to use a SHOULD to display it as a

   CM: I think for the issue that was brought up, it should just do the
   same thing as in HTML if you have a descendent element with title=""
   (empty string) on it

   ISSUE: Resolve the <title> tooltip issue for SVG2

   <trackbot> Created ISSUE-2414 - Resolve the <title> tooltip issue
   for SVG2 ; please complete additional details at
   [16]http://www.w3.org/Graphics/SVG/WG/track/issues/2414/edit .

     [16] http://www.w3.org/Graphics/SVG/WG/track/issues/2414/edit

   DS: I came up with an algorithm for determining the title of an
   element: every element has a title. the title text comes from its
   immediate child <title>, or its closest ancestor's.
   ... I think that's the only consistent one I can see being applied
   ... we could ask the public list to review the text from 1.1/1.2T,
   get use cases and requirements from accessibility and other people

   <scribe> ACTION: Doug to ask the public list and a11y people about
   title/tooltips [recorded in

   <trackbot> Created ACTION-3065 - Ask the public list and a11y people
   about title/tooltips [on Doug Schepers - due 2011-07-21].

   ISSUE: Specify what an empty <title> element means in SVG2

   <trackbot> Created ISSUE-2415 - Specify what an empty <title>
   element means in SVG2 ; please complete additional details at
   [18]http://www.w3.org/Graphics/SVG/WG/track/issues/2415/edit .

     [18] http://www.w3.org/Graphics/SVG/WG/track/issues/2415/edit

   <scribe> ACTION: Doug to make a proposal for ISSUE-2415, empty
   <title> element [recorded in

   <trackbot> Created ACTION-3066 - Make a proposal for ISSUE-2415,
   empty <title> element [on Doug Schepers - due 2011-07-21].

   <scribe> ACTION: Doug to reply to Klaus on www-svg about empty
   <title> [recorded in

   <trackbot> Created ACTION-3067 - Reply to Klaus on www-svg about
   empty <title> [on Doug Schepers - due 2011-07-21].

Status of SVG 1.1 Second Edition publication

   ED: do we need to do anything there?

   DS: Chris or I need to write up a Director's decision based on the
   ... did you guys see the feedback from Innovimax?

   ED: yes

   DS: have we resolved what to do about that?

   CM: I don't think we've discussed it


     [21] http://www.w3.org/2002/09/wbs/33280/svg11-2011/results

   ED: there's no RNG for 1.1, but there's nothing stopping us
   publishing one later if we want

   CM: I agree, there may be that experimental RNG on www.w3.org, but
   we weren't intending to publish 1.1F2 with one

   DS: yes, if we do publish one going forward we don't need it to be
   linked from the spec
   ... plh agreed with me that these kinds of comments were made too
   late; they should have been made in PR or LC
   ... we should say that the rng on www.w3.org/Graphics/SVG/ is out of
   date, and it would be better to wait for murata-san's updated rng

   ED: he also comments about references
   ... we have discussed this previously and rejected them

   DS: I know that in the past certain things had changed from CSS 2.0
   to 2.1, so we didn't think it was appropriate to change the


     [22] http://lists.w3.org/Archives/Public/www-svg/2011Feb/0034.html

   DS: now that 2.1 is a REC, there's nothing stopping us maturity-wise

   <ed> [23]http://www.w3.org/TR/SVG11/refs.html

     [23] http://www.w3.org/TR/SVG11/refs.html

   ED: we do already link to CSS 2.1 from the references section

   DS: he lists two or three references, what are those?

   ED: SMIL 3.0, I think it's not so easy to reference that
   ... MathML 3.0, he wants an informative reference

   DS: SVG 1.1 Second Edition only made certain changes, and it wasn't
   evaluated entirely in terms of references
   ... we couldn't confidently change some of these references

   ED: we could do the MathML one, it's informative

   DS: yeah, so changing that one to MathML 3.0 would be OK

   CM: so we reference both SMIL Animation (normative) and SMIL 3.0
   (informative). what do we reference SMIL 3.0 for?

   ED: just an informative note, I think

   DS: I'll leave it to you Cameron to update any references you think
   are safe, and keep me updated

   <scribe> ACTION: Cameron to investigate reference updates per
   Innovimax's comment [recorded in

   <trackbot> Created ACTION-3068 - Investigate reference updates per
   Innovimax's comment [on Cameron McCormack - due 2011-07-21].

   ED: I made some tweaks to the test suite, reference image updates
   ... but I think it's in a good state for publication

   CM: did you look any further into how to publish the test suite?

   ED: no, and I'd like to verify that the test suite package is
   generated correctly

   <scribe> ACTION: Erik to look into the testsuite package
   generation/publication [recorded in

   <trackbot> Created ACTION-3069 - Look into the testsuite package
   generation/publication [on Erik Dahlström - due 2011-07-21].

   CM: what is the timing of being able to publish?

   DS: I think we should be able to publish next Thursday

Interest in SVG Parameters

   DS: I never sent off my email about that
   ... I intend on responding to Andreas and others to tell them what
   our plan is
   ... it was interesting that Andreas pointed out another
   implementation out there, some GIS thing
   ... I'm scheduled to meet with an expert on URIs/HTTPs etc. to talk
   about the syntax
   ... one of the problems with Params was that we never settled on a
   URL syntax, you can't use a question mark since that would mean
   resources aren't cached
   ... so I'll talk to him about better syntax for that
   ... there might be conflict between our syntax and the media
   ... (Yves Lafon)
   ... I'm going to try to have an updated ED for the F2F
   ... so is this meant to be an SVG2 feature? or a separate module? I
   don't really care one way or the other.

   CM: not sure

   DS: we could leave it as a separate spec for now and consider
   folding it into SVG2 later
   ... that way people can implement it now

textPath method="stretch"

   ED: it's being proposed that for textPath method="stretch" you warp
   the glyphs, Israel used the term "offset mapping"
   ... so making the glyphs rubbery and stretch them along the path
   ... it's not exactly what opera does at the moment; we don't stretch
   it out fully like that

   VH: but opera does some stretching?

   ED: yes

   (opera doesn't do an exact scaling of the glyphs, it stretches it
   into a trapezoid or something)


     [26] http://www.w3.org/TR/SVG11/text.html#TextPathElementMethodAttribute

   VH: so he wants silverlight-like effects?

   ED: not quite
   ... he made a couple of different examples
   ... they're pretty compelling

   <ed> [27]http://owl3d.com/svg/tests/boundText/circle_text_ar6.svg

     [27] http://owl3d.com/svg/tests/boundText/circle_text_ar6.svg

   ED: Opera wouldn't behave like this
   ... if you take the "Z" character, it wouldn't be following the
   inner circle
   ... it would be positioned on the mid line of the glyph, a straight
   ... and the top line of the character wouldn't follow the circle

   TB: I was playing with some ligatures with that, it looks a bit ugly
   ... if you don't follow the curve
   ... if you have the "ffi", if all three parts of that are on a
   straight line, it doesn't look good

   VH: is he proposing a solution that explains exactly the processing
   to do this?

   ED: I think sort of, but it's not 100% clear in all parts
   ... there are some aspects of this proposal that aren't clear, like
   how rotate="" would affect this
   ... I pointed out a few things, where e.g. if you have a very sharp
   corner, the behaviour in such cases is not fully defined either


     [28] http://owl3d.com/svg/tests/boundText/corner_linejoin_round.svg

   ED: ^ there is an example of a sharp corner

   DS: if we are going to change text path, maybe we might have an
   attribute that changes modes of how textPath behaves

   <ed> [29]http://owl3d.com/svg/tests/boundText/2curves.svg

     [29] http://owl3d.com/svg/tests/boundText/2curves.svg

   DS: we have the current backwards compat mode, and we could opt in
   to this new functionality

   ED: also being able to specify two curves to stretch between
   ... that's similar to the silverlight one I think
   ... so it's following the curve and not using straight lines for the
   top/bottom of the glyphs

   CM: it's a short distance between this and doing it for general

   DS: we did talk about a "shapePath", where it treats individual
   shapes as glyphs

   VH: these documents are pregenerated, do we know how he generates

   <ed> [30]http://owl3d.com/svg/tests/boundText/corner_in_out.svg
   (that's the non-bendy B)

     [30] http://owl3d.com/svg/tests/boundText/corner_in_out.svg

   CM: if he could furnish us with some algorithms that would be a good
   way forward

   VH: is he a Member?

   CM: no, a public

   VH: I would be concerned if he shared them and wasn't a member

   DS: we do allow non-members to give IPR commitments

   TB: it should be pretty easy to duplicate

   <scribe> ACTION: Tav to experiment with glyph warping text path
   stuff [recorded in

   <trackbot> Created ACTION-3070 - Experiment with glyph warping text
   path stuff [on Tavmjong Bah - due 2011-07-21].

   TB: I think Inkscape already has something like this for a general

   VH: is it just done with manipulating control points, or does it
   need to subdivide curves?

   TB: just control points
   ... we have some extensions

   <vhardy> [32]http://owl3d.com/svg/tests/boundText/circle_text_B.svg

     [32] http://owl3d.com/svg/tests/boundText/circle_text_B.svg

   <vhardy> [33]http://owl3d.com/svg/tests/boundText/2curves_B.svg

     [33] http://owl3d.com/svg/tests/boundText/2curves_B.svg


     [34] http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Paths-LivePathEffects-EnvelopeDeformation.html

   (discussion about inkscape live path effects)

   VH: did Israel have a concretre proposal, or was it more about

   ED: more functionality
   ... not sure if he wanted something like live path effects, or just
   wanting the simple things to work

   CM: how might we move forward with this, aside from saying "that's

   VH: for anything like this to go into the spec, we need a real
   ... either we do that or we ask him to do it

   ED: it would nice to be able to apply this to any shape
   ... not just text, textPath
   ... so it'd be nice if we had something like live path effects in

   VH: should we have something like a rubber band effect? fairly
   generic, something that would apply to text or shapes

   ED: I think one of the use cases mentioned there was railroad
   tracks, labels on streets, etc.

   CM: what I want to know is how difficult it is to specify and
   ... it's clearly a high value effect, so if we can do it without too
   much difficulty, I think we should

   VH: we respond saying we could put it in the SVG2 requirements
   document, ask him to join the group help specify it

   ED: yes, if he has algorithms spec text to contribute
   ... writing up use cases for the path effects would be nice to have
   on the wiki

   VH: we have a page for the requirements document, for 2.0?

   CM: I think we never came to a decision on scope for 2.0
   ... there was a discussion on the list
   ... a month or two back

   DS: I'd said to wait for the Community group process to be up and
   ... and use that to help scope the 2.0 work
   ... the infrastructure won't be there, though
   ... are we going to get people to mail to the list? it's work to
   collect that.

   VH: traditionally you would have a requirements document, an editor
   for that document
   ... we could do it on the wiki
   ... and then multiple people could collect things from the list to
   the wiki

   CM: I think we need a page like that for ourselves, at least,
   whether or not we use it for collecting requirements from the public

   VH: we can start a wiki page, that's a zero cost thing, make this
   the first entry
   ... during the meeting we could have someone put things on the page
   as we decide on certain features going in there

   DS: but that's only stuff that we talk about, not from the public

   VH: we could do it like today. we discuss things that come up on the
   list, and during the meeting we talk about adding it to the req

   DS: we could split it into high priority items, medium, low,


     [35] http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements

Summary of Action Items

   [NEW] ACTION: Cameron to investigate reference updates per
   Innovimax's comment [recorded in
   [NEW] ACTION: Doug to ask the public list and a11y people about
   title/tooltips [recorded in
   [NEW] ACTION: Doug to make a proposal for ISSUE-2415, empty <title>
   element [recorded in
   [NEW] ACTION: Doug to reply to Klaus on www-svg about empty <title>
   [recorded in
   [NEW] ACTION: Erik to look into the testsuite package
   generation/publication [recorded in
   [NEW] ACTION: Erik to mail the group list asking for review of the
   mediaont-api spec [recorded in
   [NEW] ACTION: Tav to experiment with glyph warping text path stuff
   [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 14 July 2011 21:39:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:29:46 UTC