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

minutes, 16 June 2011 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Fri, 17 Jun 2011 09:38:16 +1200
To: www-svg@w3.org
Message-ID: <20110616213815.GA11042@wok.mcc.id.au>
Minutes at http://www.w3.org/2011/06/16-svg-minutes.html and below as


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

                               - DRAFT -

                   SVG Working Group Teleconference

16 Jun 2011


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

   See also: [3]IRC log

      [3] http://www.w3.org/2011/06/16-svg-irc


          +1.206.675.aaaa, ed, +, Doug_Schepers, ChrisL,
          heycam, tbah, cabanier




     * [4]Topics
         1. [5]Seattle F2F
         2. [6]text layout proposal
         3. [7]SVG1.1F2 reference corrections
         4. [8]Summary of FX work
     * [9]Summary of Action Items

   <trackbot> Date: 16 June 2011

   <tbah> zakim

   <tbah> zakim +33 is me

   <scribe> ScribeNick: heycam

   <scribe> Scribe: Cameron

Seattle F2F

   ED: not sure if it was mentioned in the last telcon, but just a
   reminder to put agenda requests on the agenda page

   <ed> [10]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011

     [10] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011

   ED: vincent filled out some more details about hotel/location
   ... any agenda proposals should go to this page:

   <ed> [11]http://www.w3.org/Graphics/SVG/WG/wiki/Seattle_2011

     [11] http://www.w3.org/Graphics/SVG/WG/wiki/Seattle_2011

   VH: in the agenda you had a pointer to the registration form. is the
   agenda request page a page to fill out, or should we mail the
   mailing list?

   CL: it's a wiki page

   ED: just put whatever topics you want on that wiki page, and be
   prepared to write up a separate page for your topic before the

   CL: last night the CSSWG was looking for an extra F2F meeting
   ... and they wanted to meet with SVG
   ... so they've also picked Seattle
   ... they've picked Thu/Fri/Sat
   ... and the Thu/Fri would overlap ours
   ... if those two days aren't entirely FX stuff, then some of us
   might have to split our time between the meetings
   ... the week before/after they couldn't do, so that's the best time
   we could get

   VH: what about if we decide to make the meeting be 4 days, and have
   the last day be overlap with CSSWG?
   ... so just Mon-Thu for SVG WG

   CL: it'd be a change for the CSS WG

   VH: sorry, I suggest Thu/Fri/Sat for CSS WG, and Mon-Thu for SVG WG

   CM: did they want particularly 2 days of overlap, or just some
   ... tbh I think we could have 2 days of FX stuff to discuss

   CL: but if the CSS WG meeting is 3 days, leaving only 1 day for only
   CSS topics would be difficult

   ED: I don't mind a 4 day meeting, depends how much we have on the

   <scribe> ACTION: Chris to respond to CSS WG to say that perhaps we
   will have a 4 day (Mon-Thu) meeting, or 5 if we want to have 2 days
   of FX topics [recorded in

   <trackbot> Created ACTION-3051 - Respond to CSS WG to say that
   perhaps we will have a 4 day (Mon-Thu) meeting, or 5 if we want to
   have 2 days of FX topics [on Chris Lilley - due 2011-06-23].

   ED: last day to put in agenda requests is 30th June
   ... so that's 2 weeks from today
   ... this is just to make sure me and Cameron can organise the
   schedule for the meeting itself
   ... and it's good if there's enough writeups on the wiki to give
   some indication of how much time each topic will take

   VH: so we propose agenda items and should we suggest how much time
   they will take?

   ED: you can suggest if you like, and then we'll settle the schedule
   and decide times based on that
   ... so by mid July you need to have writeups on the wiki for the
   more lengthy topics

   VH: on the wiki main page there should be enough information to make
   your reservations
   ... let me know if you need more information

   CM: when is the closing date for the survey?

   ED: 30th June

   VH: I've asked for a room for up to 15 people
   ... now I'm thinking that's not enough for the joint meeting with
   the CSS WG
   ... 15 is plenty for SVG WG only days, yes?

   CL: yes

   VH: for the joint meeting, do you have an idea based on history? 30

   CL: probably 30 would be sufficient
   ... CSS WG can be quite big, but it depends on attendance

   DS: if it's in the US, it's likely to be pretty big

text layout proposal


     [13] http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout

   ED: I put a few comments on the proposal
   ... just to point out a few things I found when reading it that
   wasn't fully defined
   ... I think I agree with the whole change itself, seems good to me
   ... might be some minor things to think a bit more about the wording
   and so on

   CL: I have a few concerns/comments
   ... you don't save anything in the implementation
   ... there are three cases
   ... 1, layout of text, fonts available, then you shouldn't be
   putting individual shifts on letters since it's not going to work
   ... 2, laying out text, using a particular font and knowing
   everyone's got it
   ... 3, the authoring application can do more precise layout, so
   freezing that as a bunch of glyphs
   ... in 3 you still need a glyph collection, a dom font
   ... you'd still need some alt text or something for accessibility,
   then it'd be more difficult to change that text
   ... you couldn't have it be dynamic text
   ... none of these are show stoppers, but these are the different use
   ... so we're going more for #2 now
   ... with woff fonts etc.
   ... so you can probably give what people want with #2

   CM: I think my proposal just focuses on #1 and #2
   ... so, defining slightly differently to how the current spec says
   how to handle x/y/dx/dy on text
   ... whether with a known font or not
   ... I don't think we need to think of #1 and #2 differently
   ... if the author has chosen a downloadable font, then x/y/dx/dy
   will be fine
   ... otherwise, tough luck

   ED: I think we need to address the third point
   ... so I'd like to be able to switch easily between the two modes
   ... I don't think we have anything that does that at the moment

   CM: so some way to specify "this is a glyph list rather than a a
   character list"?

   ED: yes
   ... maybe when multiple values are on x/y

   RC: maybe we can have a new tag?

   CL: I'd think so, yes

   CM: so at the moment you can have altGlyph in text

   VH: if you leverage altglyph, you can probably do the equivalent of
   glyph mapping but it would probably be very verbose

   CM: beacuse you need to include character data in there too?

   VH: no, if you need to do glyph selection you wouldn eed an element
   per glyph
   ... can you position glyphs with altGlyph?

   CM: you can put x/y on altGlyph

   CL: but you can't say here's the baseline of the glyph, etc.

   CM: wouldn't that information come from the font file?

   CL: only if you know you've got the right font

   CM: I think we can assume that in this case

   RC: the font has to be available, it could be subsetted
   ... the glyph ids need to be the same

   CL: if you've made your font specially so they all line up nicely,
   then you can have a new element altGlyphList that takes a list of
   glyph ids
   ... that wouldn't give you a control over positioning
   ... if you want exact layout, then you do need one element per glyph

   VH: we could also go down the path of having the attribute be
   "(glyphid x y)+"

   CL: right, it's just a list of numbers

   CM: we can just reuse the existing x/y attributes for position lists
   ... so we already have glyphDef
   ... which has glyphRef children
   ... (or maybe altGlyphDef)
   ... so it would be just putting that information in an attribute

   <ed> it's altGlyphDef

   VH: let's look at some use cases and see if we can come up with a
   proposal in existing syntax, and a better syntax

   <scribe> ACTION: Rik to collect examples for glyph positioning and
   compare existing to proposed SVG syntax to handle them [recorded in

   <trackbot> Created ACTION-3052 - Collect examples for glyph
   positioning and compare existing to proposed SVG syntax to handle
   them [on Rik Cabanier - due 2011-06-23].

   TB: maybe some images on cameron's proposal wiki page would be good
   ... also comparing existing to new behaviour

   ED: I'd be curious to see what an implementation of the proposal
   would do to existing content

SVG1.1F2 reference corrections

   CL: how will we generate the rec?
   ... we could regen from the editor's version
   ... or we could take the existing PR and rejig it to be a Rec

   CM: doug did you have to do much to make the PR pubrules compliant?

   DS: no, just fixing one link

   CM: it turns out there's no reference problem to fix

   CL: no, this isn't about glenn's comment
   ... but I'm happy to take an action to do this

   <scribe> ACTION: Chris to fix the SVG 1.1F2 references [recorded in

   <trackbot> Created ACTION-3053 - Fix the SVG 1.1F2 references [on
   Chris Lilley - due 2011-06-23].

   CL: if your AC rep hasn't responded to the 1.1F2 survey, please get
   them to do so

   ED: anything else to change in the spec before publishing as a Rec?

   CM: probably just new SotD text and maybe tweaking the text in the
   Changes appendix

   ED: when's the last day for feedback on the PR?

   CL: july 7

Summary of FX work


     [16] http://lists.w3.org/Archives/Member/w3c-svg-wg/2011AprJun/0025.html


     [17] http://lists.w3.org/Archives/Member/w3c-svg-wg/2011AprJun/att-0025/fx-specs.html

   CM: when's the charter work due?

   DS: our charter was extended
   ... we're not under particular stress about it at the moment
   ... we just need to coordinate with CSS in a timely manner

   CL: both are rechartering, SVG has been extended until the end of
   ... CSS has been out of charter for months, and we were going to
   send it off, but I suggested to coordinate this FX stuff first
   ... to a certain extent we've had the situation where SVG wants to
   work on a joint spec, and CSS wants to do their own thing
   ... gradients and filters
   ... some people wanted a joint spec, others separate specs

   VH: I took the specs listed on the FX charter page, plus the
   compositing work
   ... and I've listed what I could find the relevant spec for each of
   those topics
   ... my hope was that the result of the discssuion is that we'd agree
   on the number of specs that is common between both groups
   ... a good one to agree on would be transforms
   ... so maybe a way to go abotu this is in this group we could agree
   on which specs we think should be joint, then we can bring that
   information to the CSSWG or a FX telcon

   CL: it was on the agenda for this week's CSS call, btu there were
   too many things on the agenda. so it's first topic for next week's

   VH: if we have a position of this group of what the FXTF should be
   workign on, we can take that to the CSS WG next week

   CM: let's go through each one

   ED: 2d transforms

   VH: on this one the current situation is the last discussion in FX
   or CSS, is taht the CSS WG will move along with the css2d spec,
   since we don't have an editor on the FX spec
   ... dino agreed that if we found an editor for the joint FX spec, we
   could move forward with the FX spec and not move ahead with the CSS
   ... I also asked if we shouldn't try to tackle both 2d and 3d in the
   same spec
   ... so we have one spec about transforms
   ... and which covers CSS and SVG
   ... so instead of 4 specs we have 1

   CM: I think the SVG WG is happy to have a joint FX spec if CSS is

   DS: re the 2d/3d spec, we thought we'd be able to move along quicker
   with 2d
   ... but if we have an editor who can get 2d/3d done in the same
   spec, I think the timing will be ok
   ... so given editing resources, we want a single spec for CSS and
   SVG, 2D and 3D

   CL: I think the risk of having separate CSS/SVG specs is too high
   ... a separate 2d spec for us doesn't give us (SVG) much
   ... also the separation was because of current implementation level

   DS: yeah, and we thought that we could knock out 2d because it was
   almost done

   CM: are there still major open issues, or is just a matter of
   smashing the specs together?

   VH: anthony had half a page of action items left to do
   ... also there was the attribute vs property debate

   CM: next is Animations/Transitions
   ... I'm not sure the scope of the joint spec

   VH: right now there are a number of issues
   ... people are using css transitions/animations
   ... people want to animate svg with that mechanism
   ... so it's very relevant for the FXTF
   ... also there's no timing and sync in css animations/transitions
   ... no notion of time containers, or sync between animations
   ... which SVG has with SMIL's timing/sync model
   ... I think it would be natural that there is a consistent model for
   ... also there's no api around animations
   ... dean is working on something
   ... but it's not in a spec yet
   ... on our end, expressed by many people, we really need an api for
   ... to handle animations that are declared in css or svg/smil

   CM: I might imagine CSS would be concerned about having a unified
   spec for all this
   ... since CSS Transitions/Animations is nearly done
   ... but this joint animation work would need a lot of work
   ... does CSS really want to have sync for their animations?

   RC: yes

   DS: from what I've been able to gather from CSS folks, there's a
   certain reluctance to do taht sort of thing because it's more
   ... but it's clear content creators want something like this
   ... I wouldn't want to not provide this to authors because it's a
   lot of work
   ... one other aspect of the animation thing is the media elements
   ... people will want to sync to certain things
   ... simon fraser said he thought doing it at this level is the wrong
   place, the media stuff would need to be significantly reworked
   because of system library support
   ... so I know there are some challenges, I don't know the exact
   ... (might have been someone else)
   ... but I think we owe it to the community to find out the degree to
   which these things can be synchronised
   ... so maybe not syncbases and shared timers, but at least events
   that can go between elements and animations

   RC: i think if we have something that is easily targetted with
   ... if we have an event model, then people can do sync in JS

   DS: hooks throguh events rather than a single model

   RC: CSS is a little bit there, but as soon as you do complex things
   it gets out of sync

   VH: I discussed with dean this animation stuff
   ... what we need is a generic model for timing and sync that is
   accessible in different ways
   ... so maybe different syntax in css and svg/smil, so you might want
   to create/modify/delete animations from script as well
   ... but what's needed is a common model for what timing is, how to
   sync up animations
   ... so listening through script, or having declarative sync arcs in
   smil (or if they were added to css)
   ... there are a lot of problems that have been tackled in smil
   ... it does address the use case, the model for synchronising
   animations with audio/video
   ... how tightly you want to sync things together
   ... so there's definitely research there we can leverage

   DS: I would like SVG animation to take what it started from, and
   develop it as an element-based animation, but not necessarily be
   backwards compatibile with smil

   VH: my proposal would be to say we should find out how CSS animation
   applies to SVG, resolve animating SVG attributes
   ... try putting that into the scope of the css transitions work
   ... and say we feel we need to have a joint timing model / scripting
   ... but we're not sure yet where that should live yet

   DS: I feel like CSS might not want to have the more complicated
   cases like timing containers
   ... but would be find to have that as part of the element-based

   ED: I think it would be fine to have a separate SVG spec
   ... for evolving our smil-based syntax

   VH: I don't agree, mixing HTML/SVG and complex animation, I would
   want it to work equivalently well for HTML and SVG

   DS: and consistently, using the same methods

   VH: one effort is making CSS animations/transitions work with SVG
   ... another is evolving animating timing / script / etc.

   CM: so what do we say about CSS Animations and Transitions as specs?

   DS: I think Transitions is a bit different, it can progress by
   ... I think Animations is where the joint work is required
   ... aside, we should make sure property animations are effected in
   the same way (computed style) in both css and svg style animatinos

   continue on the mailing list

Summary of Action Items

   [NEW] ACTION: Chris to fix the SVG 1.1F2 references [recorded in
   [NEW] ACTION: Chris to respond to CSS WG to say that perhaps we will
   have a 4 day (Mon-Thu) meeting, or 5 if we want to have 2 days of FX
   topics [recorded in
   [NEW] ACTION: Rik to collect examples for glyph positioning and
   compare existing to proposed SVG syntax to handle them [recorded in

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/
Received on Thursday, 16 June 2011 21:38:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:13 UTC