IRC log of svg on 2011-06-16

Timestamps are in UTC.

20:02:28 [RRSAgent]
RRSAgent has joined #svg
20:02:28 [RRSAgent]
logging to http://www.w3.org/2011/06/16-svg-irc
20:02:30 [trackbot]
RRSAgent, make logs public
20:02:30 [Zakim]
Zakim has joined #svg
20:02:32 [trackbot]
Zakim, this will be GA_SVGWG
20:02:32 [Zakim]
ok, trackbot, I see GA_SVGWG(SVG1)4:00PM already started
20:02:33 [trackbot]
Meeting: SVG Working Group Teleconference
20:02:33 [trackbot]
Date: 16 June 2011
20:03:45 [Zakim]
+??P14
20:03:54 [ed]
Zakim, ??P14 is me
20:03:54 [Zakim]
+ed; got it
20:04:14 [ed]
Zakim, who's there?
20:04:14 [Zakim]
I don't understand your question, ed.
20:04:41 [tbah]
tbah has joined #svg
20:05:13 [ed]
Zakim, who's here?
20:05:13 [Zakim]
On the phone I see ??P5, +1.206.675.aaaa, ed
20:05:14 [Zakim]
On IRC I see tbah, Zakim, RRSAgent, cabanier, vhardy, shepazu_away, heycam, trackbot, ed
20:05:38 [Zakim]
+ +33.9.53.77.aabb
20:06:07 [ed]
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0151.html
20:06:57 [tbah]
zakim,
20:06:57 [Zakim]
I don't understand '', tbah
20:07:14 [tbah]
zakim
20:07:14 [ChrisL]
ChrisL has joined #svg
20:07:34 [Zakim]
+Doug_Schepers
20:07:38 [tbah]
zakim +33 is me
20:08:04 [Zakim]
+ChrisL
20:08:22 [Zakim]
+??P18
20:08:25 [heycam]
Zakim, ??P18 is me
20:08:25 [Zakim]
+heycam; got it
20:08:58 [heycam]
ScribeNick: heycam
20:08:59 [tbah]
zakim, +33 is me
20:08:59 [Zakim]
+tbah; got it
20:09:01 [heycam]
Scribe: Cameron
20:09:03 [heycam]
Chair: Erik
20:09:13 [heycam]
Topic: Seattle F2F
20:09:33 [cabanier]
zakim, +1.206.675.aaa is me
20:09:33 [Zakim]
+cabanier; got it
20:09:35 [heycam]
ED: not sure if it was mentioned in the last telcon, but just a reminder to put agenda requests on the agenda page
20:09:37 [ChrisL]
q+
20:09:40 [ed]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_2011
20:09:50 [heycam]
... vincent filled out some more details about hotel/location
20:10:01 [heycam]
... any agenda proposals should go to this page:
20:10:05 [ed]
http://www.w3.org/Graphics/SVG/WG/wiki/Seattle_2011
20:10:39 [heycam]
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?
20:10:54 [heycam]
CL: it's a wiki page
20:11:19 [heycam]
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 meeting
20:11:26 [heycam]
CL: last night the CSSWG was looking for an extra F2F meeting
20:11:31 [heycam]
... and they wanted to meet with SVG
20:11:36 [heycam]
... so they've also picked Seattle
20:11:46 [heycam]
... they've picked Thu/Fri/Sat
20:11:52 [heycam]
... and the Thu/Fri would overlap ours
20:12:11 [heycam]
... if those two days aren't entirely FX stuff, then some of us might have to split our time between the meetings
20:12:19 [heycam]
... the week before/after they couldn't do, so that's the best time we could get
20:12:34 [heycam]
VH: what about if we decide to make the meeting be 4 days, and have the last day be overlap with CSSWG?
20:12:59 [heycam]
... so just Mon-Thu for SVG WG
20:13:28 [heycam]
CL: it'd be a change for the CSS WG
20:13:47 [heycam]
VH: sorry, I suggest Thu/Fri/Sat for CSS WG, and Mon-Thu for SVG WG
20:14:18 [heycam]
CM: did they want particularly 2 days of overlap, or just some overlap?
20:14:41 [heycam]
... tbh I think we could have 2 days of FX stuff to discuss
20:15:00 [heycam]
CL: but if the CSS WG meeting is 3 days, leaving only 1 day for only CSS topics would be difficult
20:15:06 [heycam]
ED: I don't mind a 4 day meeting, depends how much we have on the agenda
20:16:52 [heycam]
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
20:16:52 [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].
20:17:03 [heycam]
ED: last day to put in agenda requests is 30th June
20:17:09 [heycam]
... so that's 2 weeks from today
20:17:26 [heycam]
... this is just to make sure me and Cameron can organise the schedule for the meeting itself
20:17:39 [heycam]
... and it's good if there's enough writeups on the wiki to give some indication of how much time each topic will take
20:18:12 [heycam]
VH: so we propose agenda items and should we suggest how much time they will take?
20:18:37 [heycam]
ED: you can suggest if you like, and then we'll settle the schedule and decide times based on that
20:19:01 [heycam]
... so by mid July you need to have writeups on the wiki for the more lengthy topics
20:19:13 [heycam]
VH: on the wiki main page there should be enough information to make your reservations
20:19:17 [heycam]
... let me know if you need more information
20:19:57 [heycam]
CM: when is the closing date for the survey?
20:19:59 [heycam]
ED: 30th June
20:20:33 [heycam]
VH: I've asked for a room for up to 15 people
20:20:41 [heycam]
... now I'm thinking that's not enough for the joint meeting with the CSS WG
20:20:49 [heycam]
... 15 is plenty for SVG WG only days, yes?
20:20:50 [heycam]
CL: yes
20:21:03 [heycam]
VH: for the joint meeting, do you have an idea based on history? 30 people?
20:21:11 [heycam]
CL: probably 30 would be sufficient
20:21:20 [heycam]
... CSS WG can be quite big, but it depends on attendance
20:21:29 [heycam]
DS: if it's in the US, it's likely to be pretty big
20:26:48 [heycam]
Topic: text layout proposal
20:26:55 [ed]
http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Text_layout
20:27:09 [heycam]
ED: I put a few comments on the proposal
20:27:18 [heycam]
... just to point out a few things I found when reading it that wasn't fully defined
20:27:28 [heycam]
... I think I agree with the whole change itself, seems good to me
20:27:36 [heycam]
... might be some minor things to think a bit more about the wording and so on
20:27:57 [heycam]
CL: I have a few concerns/comments
20:28:32 [heycam]
... you don't save anything in the implementation
20:28:41 [heycam]
... there are three cases
20:28:56 [heycam]
... 1, layout of text, fonts available, then you shouldn't be putting individual shifts on letters since it's not going to work
20:29:08 [heycam]
... 2, laying out text, using a particular font and knowing everyone's got it
20:29:23 [heycam]
... 3, the authoring application can do more precise layout, so freezing that as a bunch of glyphs
20:29:35 [heycam]
... in 3 you still need a glyph collection, a dom font
20:29:47 [heycam]
... you'd still need some alt text or something for accessibility, then it'd be more difficult to change that text
20:29:52 [heycam]
... you couldn't have it be dynamic text
20:29:59 [heycam]
... none of these are show stoppers, but these are the different use cases
20:30:09 [heycam]
... so we're going more for #2 now
20:30:12 [heycam]
... with woff fonts etc.
20:30:20 [heycam]
... so you can probably give what people want with #2
20:31:24 [heycam]
CM: I think my proposal just focuses on #1 and #2
20:31:37 [heycam]
... so, defining slightly differently to how the current spec says how to handle x/y/dx/dy on text
20:31:41 [heycam]
... whether with a known font or not
20:32:43 [heycam]
... I don't think we need to think of #1 and #2 differently
20:33:24 [heycam]
... if the author has chosen a downloadable font, then x/y/dx/dy will be fine
20:33:30 [heycam]
... otherwise, tough luck
20:33:31 [Zakim]
-ed
20:33:37 [heycam]
ED: I think we need to address the third point
20:33:47 [heycam]
... so I'd like to be able to switch easily between the two modes
20:34:07 [Zakim]
+??P11
20:34:23 [heycam]
... I don't think we have anything that does that at the moment
20:35:19 [heycam]
CM: so some way to specify "this is a glyph list rather than a a character list"?
20:35:20 [heycam]
ED: yes
20:35:30 [heycam]
... maybe when multiple values are on x/y
20:35:39 [heycam]
RB: maybe we can have a new tag?
20:35:46 [heycam]
CL: I'd think so, yes
20:36:34 [heycam]
CM: so at the moment you can have altGlyph in text
20:36:49 [heycam]
VH: if you leverage altglyph, you can probably do the equivalent of glyph mapping but it would probably be very verbose
20:37:04 [heycam]
CM: beacuse you need to include character data in there too?
20:37:46 [heycam]
VH: no, if you need to do glyph selection you wouldn eed an element per glyph
20:38:03 [heycam]
... can you position glyphs with altGlyph?
20:38:08 [heycam]
CM: you can put x/y on altGlyph
20:38:14 [heycam]
CL: but you can't say here's the baseline of the glyph, etc.
20:38:31 [heycam]
CM: wouldn't that information come from the font file?
20:38:47 [heycam]
CL: only if you know you've got the right font
20:38:51 [heycam]
CM: I think we can assume that in this case
20:39:07 [heycam]
RC: the font has to be available, it could be subsetted
20:39:11 [heycam]
... the glyph ids need to be the same
20:39:14 [heycam]
s/RB/RC/
20:39:55 [heycam]
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
20:40:00 [heycam]
... that wouldn't give you a control over positioning
20:40:10 [heycam]
... if you want exact layout, then you do need one element per glyph
20:40:54 [heycam]
VH: we could also go down the path of having the attribute be "(glyphid x y)+"
20:41:05 [heycam]
CL: right, it's just a list of numbers
20:41:34 [heycam]
CM: we can just reuse the existing x/y attributes for position list
20:41:38 [heycam]
s/list/lists/
20:42:06 [heycam]
CM: so we already have glyphDef
20:42:12 [heycam]
... which has glyphRef children
20:42:23 [heycam]
... (or maybe altGlyphDef)
20:42:29 [heycam]
... so it would be just putting that information in an attribute
20:42:43 [ed]
it's altGlyphDef
20:43:13 [heycam]
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
20:44:29 [heycam]
ACTION: Rik to collect examples for glyph positioning and compare existing to proposed SVG syntax to handle them
20:44:29 [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].
20:46:19 [heycam]
TB: maybe some images on cameron's proposal wiki page would be good
20:46:41 [heycam]
... also comparing existing to new behaviour
20:46:51 [heycam]
ED: I'd be curious to see what existing implementations would do to existing content
20:47:58 [heycam]
Zakim, who is making noise?
20:48:08 [Zakim]
heycam, listening for 10 seconds I heard sound from the following: ??P5 (95%)
20:48:10 [ed]
s/existing implementations/an implementation of the proposal/
20:48:23 [heycam]
Zakim, who is on the call?
20:48:23 [Zakim]
On the phone I see ??P5, cabanier, tbah, Doug_Schepers, ChrisL, heycam, ??P11
20:48:43 [heycam]
Zakim, ??P11 is ed
20:48:43 [Zakim]
+ed; got it
20:48:58 [heycam]
Topic: SVG1.1F2 reference corrections
20:49:06 [heycam]
CL: how will we generate the rec?
20:49:14 [heycam]
... we could regen from the editor's version
20:49:38 [heycam]
... or we could take the existing PR and rejig it to be a Rec
20:50:33 [heycam]
CM: doug did you have to do much to make the PR pubrules compliant?
20:50:36 [heycam]
DS: no, just fixing one link
20:51:06 [heycam]
CM: it turns out there's no reference problem to fix
20:51:50 [heycam]
CL: no, this isn't about glenn's comment
20:52:06 [heycam]
... but I'm happy to take an action to do this
20:52:44 [heycam]
ACTION: Chris to fix the SVG 1.1F2 references
20:52:44 [trackbot]
Created ACTION-3053 - Fix the SVG 1.1F2 references [on Chris Lilley - due 2011-06-23].
20:53:10 [heycam]
CL: if your AC rep hasn't responded to the 1.1F2 survey, please get them to do so
20:54:41 [Zakim]
-ChrisL
20:55:01 [heycam]
ED: anything else to change in the spec before publishing as a Rec?
20:55:12 [heycam]
CM: probably just new SotD text and maybe tweaking the text in the Changes appendix
20:55:24 [Zakim]
+ChrisL
20:56:04 [heycam]
ED: when's the last day for feedback on the PR?
20:56:09 [heycam]
CL: july 7
20:56:18 [Zakim]
-tbah
20:56:48 [Zakim]
+tbah
20:57:22 [heycam]
Topic: Summary of FX work
20:57:35 [heycam]
http://lists.w3.org/Archives/Member/w3c-svg-wg/2011AprJun/0025.html
20:57:40 [heycam]
http://lists.w3.org/Archives/Member/w3c-svg-wg/2011AprJun/att-0025/fx-specs.html
20:58:06 [heycam]
CM: when's the charter work due?
20:58:11 [heycam]
DS: our charter was extended
20:58:19 [heycam]
... we're not under particular stress about it at the moment
20:58:24 [heycam]
... we just need to coordinate with CSS in a timely manner
20:58:35 [heycam]
CL: both are rechartering, SVG has been extended until the end of july
20:59:01 [heycam]
... 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
20:59:26 [heycam]
... 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
20:59:39 [heycam]
... gradients and filters
20:59:46 [heycam]
... some people wanted a joint spec, others separate specs
21:00:34 [heycam]
VH: I took the specs listed on the FX charter page, plus the compositing work
21:00:42 [heycam]
... and I've listed what I could find the relevant spec for each of those topics
21:00:59 [heycam]
... 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
21:01:04 [heycam]
... a good one to agree on would be transforms
21:01:31 [heycam]
... 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
21:01:51 [heycam]
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 call.
21:02:12 [heycam]
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
21:03:18 [heycam]
CM: let's go through each one
21:03:25 [heycam]
ED: 2d transforms
21:03:55 [heycam]
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
21:04:15 [heycam]
... 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 spec
21:04:22 [heycam]
... I also asked if we shouldn't try to tackle both 2d and 3d in the same spec
21:04:26 [heycam]
... so we have one spec about transforms
21:04:31 [heycam]
... and which covers CSS and SVG
21:04:35 [heycam]
... so instead of 4 specs we have 1
21:05:25 [heycam]
CM: I think the SVG WG is happy to have a joint FX spec if CSS is
21:05:39 [heycam]
DS: re the 2d/3d spec, we thought we'd be able to move along quicker with 2d
21:06:03 [heycam]
... but if we have an editor who can get 2d/3d done in the same spec, I think the timing will be ok
21:06:59 [heycam]
DS: so given editing resources, we want a single spec for CSS and SVG, 2D and 3D
21:07:12 [heycam]
CL: I think the risk of having separate CSS/SVG specs is too high
21:07:30 [heycam]
... a separate 2d spec for us doesn't give us (SVG) much
21:07:51 [heycam]
... also the separation was because of current implementation level
21:08:01 [heycam]
DS: yeah, and we thought that we could knock out 2d because it was almost done
21:08:50 [heycam]
CM: are there still major open issues, or is just a matter of smashing the specs together?
21:08:57 [heycam]
VH: anthony had half a page of action items left to do
21:09:07 [heycam]
... also there was the attribute vs property debate
21:10:14 [heycam]
CM: next is Animations/Transitions
21:10:20 [heycam]
... I'm not sure the scope of the joint spec
21:10:27 [heycam]
VH: right now there are a number of issues
21:10:36 [heycam]
... people are using css transitions/animations
21:10:41 [heycam]
... people want to animate svg with that mechanism
21:10:48 [heycam]
... so it's very relevant for the FXTF
21:10:56 [heycam]
... also there's no timing and sync in css animations/transitions
21:11:03 [heycam]
... no notion of time containers, or sync between animations
21:11:10 [heycam]
... which SVG has with SMIL's timing/sync model
21:11:24 [heycam]
... I think it would be natural that there is a consistent model for timing/sync
21:11:36 [heycam]
... also there's no api around animations
21:11:40 [heycam]
... dean is working on something
21:11:45 [heycam]
... but it's not in a spec yet
21:11:53 [heycam]
... on our end, expressed by many people, we really need an api for animations
21:12:03 [heycam]
... to handle animations that are declared in css or svg/smil
21:12:48 [heycam]
CM: I might imagine CSS would be concerned about having a unified spec for all this
21:12:56 [heycam]
... since CSS Transitions/Animations is nearly done
21:13:06 [heycam]
... but this joint animation work would need a lot of work
21:14:25 [heycam]
CM: does CSS really want to have sync for their animations?
21:14:32 [heycam]
RC: yes
21:14:47 [heycam]
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 complicated
21:14:52 [heycam]
... but it's clear content creators want something like this
21:15:15 [heycam]
... I wouldn't want to not provide this to authors because it's a lot of work
21:15:26 [heycam]
... one other aspect of the animation thing is the media elements
21:15:32 [heycam]
... people will want to sync to certain things
21:16:31 [heycam]
... 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
21:16:39 [heycam]
... so I know there are some challenges, I don't know the exact nature
21:16:43 [heycam]
... (might have been someone else)
21:16:58 [heycam]
... but I think we owe it to the community to find out the degree to which these things can be synchronised
21:17:17 [heycam]
... so maybe not syncbases and shared timers, but at least events that can go between elements and animations
21:17:30 [heycam]
RC: i think if we have something that is easily targetted with javascript
21:17:41 [heycam]
... if we have an event model, then people can do sync in JS themselves
21:17:50 [heycam]
DS: hooks throguh events rather than a single model
21:18:10 [heycam]
RC: CSS is a little bit there, but as soon as you do complex things it gets out of sync
21:18:53 [heycam]
VH: I discussed with dean this animation stuff
21:19:06 [heycam]
... what we need is a generic model for timing and sync that is accessible in different ways
21:19:21 [heycam]
... so maybe different syntax in css and svg/smil, so you might want to create/modify/delete animations from script as well
21:19:30 [heycam]
... but what's needed is a common model for what timing is, how to sync up animations
21:19:45 [heycam]
... so listening through script, or having declarative sync arcs in smil (or if they were added to css)
21:20:23 [heycam]
... there are a lot of problems that have been tackled in smil
21:20:37 [heycam]
... it does address the use case, the model for synchronising animations with audio/video
21:20:46 [heycam]
... how tightly you want to sync things together
21:21:04 [heycam]
... so there's definitely research there we can leverage
21:21:54 [heycam]
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
21:25:50 [heycam]
VH: my proposal would be to say we should find out how CSS animation applies to SVG, resolve animating SVG attributes
21:25:58 [heycam]
... try putting that into the scope of the css transitions work
21:26:11 [heycam]
... and say we feel we need to have a joint timing model / scripting model
21:26:19 [heycam]
... but we're not sure yet where that should live yet
21:26:40 [heycam]
DS: I feel like CSS might not want to have the more complicated cases like timing containers
21:26:52 [heycam]
... but would be find to have that as part of the element-based syntax
21:27:00 [heycam]
ED: I think it would be fine to have a separate SVG spec
21:27:05 [heycam]
... for evolving our smil-based syntax
21:27:32 [heycam]
VH: I don't agree, mixing HTML/SVG and complex animation, I would want it to work equivalently well for HTML and SVG
21:27:37 [heycam]
DS: and consistently, using the same methods
21:30:35 [heycam]
VH: one effort is making CSS animations/transitions work with SVG
21:30:45 [heycam]
... another is evolving animating timing / script / etc.
21:32:23 [heycam]
CM: so what do we say about CSS Animations and Transitions as specs?
21:32:39 [heycam]
DS: I think Transitions is a bit different, it can progress by itself
21:32:47 [heycam]
... I think Animations is where the joint work is required
21:34:17 [heycam]
DS: aside, we should make sure property animations are effected in the same way (computed style) in both css and svg style animatinos
21:35:45 [Zakim]
-ChrisL
21:35:50 [heycam]
continue on the mailing list
21:36:25 [Zakim]
-ed
21:36:27 [Zakim]
-??P5
21:36:28 [Zakim]
-cabanier
21:36:28 [Zakim]
-Doug_Schepers
21:36:30 [Zakim]
-heycam
21:36:30 [Zakim]
-tbah
21:36:30 [Zakim]
GA_SVGWG(SVG1)4:00PM has ended
21:36:32 [Zakim]
Attendees were +1.206.675.aaaa, ed, +33.9.53.77.aabb, Doug_Schepers, ChrisL, heycam, tbah, cabanier
21:36:34 [heycam]
RRSAgent, make minutes
21:36:34 [RRSAgent]
I have made the request to generate http://www.w3.org/2011/06/16-svg-minutes.html heycam
22:58:39 [homata]
homata has joined #svg
23:11:42 [homata]
homata has joined #svg
23:13:00 [homata_]
homata_ has joined #svg