See also: IRC log
<trackbot> Date: 16 June 2011
<tbah> zakim
<tbah> zakim +33 is me
<scribe> ScribeNick: heycam
<scribe> Scribe: Cameron
ED: not sure if it was mentioned in the last telcon, but just a reminder to put agenda requests on the agenda page
<ed> 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> 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 meeting
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 overlap?
... 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 agenda
<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 http://www.w3.org/2011/06/16-svg-minutes.html#action01]
<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 people?
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
<ed> 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 cases
... 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 http://www.w3.org/2011/06/16-svg-minutes.html#action02]
<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
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 http://www.w3.org/2011/06/16-svg-minutes.html#action03]
<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
http://lists.w3.org/Archives/Member/w3c-svg-wg/2011AprJun/0025.html
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 july
... 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 call.
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 spec
... 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 timing/sync
... 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 animations
... 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 complicated
... 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
nature
... (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 javascript
... if we have an event model, then people can do sync in JS
themselves
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 model
... 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
syntax
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 itself
... 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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/RB/RC/ Succeeded: s/list/lists/ Succeeded: s/existing implementations/an implementation of the proposal/ Found ScribeNick: heycam Found Scribe: Cameron Default Present: +1.206.675.aaaa, ed, +33.9.53.77.aabb, Doug_Schepers, ChrisL, heycam, tbah, cabanier Present: +1.206.675.aaaa ed +33.9.53.77.aabb Doug_Schepers ChrisL heycam tbah cabanier Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2011AprJun/0151.html Found Date: 16 Jun 2011 Guessing minutes URL: http://www.w3.org/2011/06/16-svg-minutes.html People with action items: chris rik[End of scribe.perl diagnostic output]