SVG Working Group Teleconference -- 13 Oct 2011

<trackbot> Date: 13 October 2011

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

SVG2 planning

<ChrisL> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page

ED: we originally thought we'd be done with the requirements and use cases draft
... tomorrow
... that seems unlikely

CL: I think we could agree to finalise it by the end of the F2F though
... we could get rid of some of the proposals, merge some
... also find out which one whether there's any authoring support, any authoring problems, any implementation interest

DS: we could turn this into an opportunity that we are seeking from SVG Open people input on the requirements
... show them what we have so far

ED: you're editing the document?

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback

CL: the wiki page, which I guess is the draft of that document

<cyril> /me trying to call in from Australia but can't get the right prefix ...

CL: where did the 15th come from?
... I'd like to resolve on having a draft of our uc+req document by the end of the F2F
... even if it's incomplete, just to set some direction

ED: anyone opposed?

(none)

RESOLUTION: We will have a draft of SVG2 Use Cases & Reqs document by end of TPAC 2011 and publish a draft directly afterwards

ED: should we assign an action to group these items on the wiki page?

CM: do we need to do that now or just for publication?

TB: would be better to do it earlier

ED: we could do some of this at the SVG Open meeting
... shall we go through the remaining ones that don't have comments?
... I was wonder about the "use cleanup" one

CL: I added something there about what I think it should be
... it relates to two issues
... one is being clearer about shadow dom/trees, how dynamic they are, whether they react to changes/liveness
... the second is the hokey inheritance into shadow trees

CM: I think it needs investigation to see whether the style inheritance does need changes, what the implementation state is, etc.

DS: we should look at the component model work
... maybe for SVG2 we say use is like a templating thing, the inheritance model etc., like the component model
... that way implementors only have to do oen thing, special cased slightly for use, instead of a very different thing for use

CM: I agree

<scribe> ACTION: Tab to investigate how to align SVG use with the Component Model [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action01]

<trackbot> Created ACTION-3135 - Investigate how to align SVG use with the Component Model [on Tab Atkins Jr. - due 2011-10-20].

DS: Tab says he thinks it would be relatively easy to do this, to have something that is very much like use but not identical

<cyril> do you have a link to the Component Model description ?

DS: I think we should get as close to use as we can with the existing Component Model, maybe modify the CM in response
... I want to ensure the use cases are covered, and as backwards compatible as possible
... the component model relies heavily on script, too

TA: we are looking at the script based components first, but we will look at the declarative version

CM: I did mean to look into the Component Model to see how it should work for the sXBL use cases, but I haven't had the time

DS: we should do that, look at the sXBL/RCC use cases
... now that SVG is everywhere, doing things like replacing a table with a chart is something people will now want to do
... I've got this question a few times: does SVG have a data binding model?
... and I've said no, you can make one with script, but it doesn't have a native one
... and rather than having a big scripted solution, it could draw from the data to create the graph
... and the discussions we had earlier about making accessible infographics start to make more sense
... so the Component Model is interesting not just from the "use" perspective but also the "sXBL use cases" perspective

<scribe> ACTION: Doug to investigate the Component Model for SVG re sXBL use cases after 11 Nov 2011 [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action02]

<trackbot> Created ACTION-3136 - Investigate the Component Model for SVG re sXBL use cases after 11 Nov 2011 [on Doug Schepers - due 2011-10-20].

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2011

SVG Open 2011 F2F

ED: please add yourself to the wiki page if you're attending
... this will be on the workshop day
... depending on how much we have to discuss we could go for half a day or the whole day

CM: what topics do we have for that day? at least Gradients for Tav?

TB: maybe connectors?

DS: I'm happy to talk about connectors, didn't think there was much support for it, but if we can build support for it, yeah

TB: there's a group in Inkscape who is interested in that

CL: that reminded me there's a group in Inkscape interested in variable width stroke, so let's put that on the agenda

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/SVGOpen_2011/agenda_proposals

DS: I have a spec for Connectors, even if it doesn't get into browsers right away, if it gets into authoring tools for static stuff, that could still be a useful step towards building support for it

CL: I would like to call in. could someone try to find out whether there is a way?

<scribe> ACTION: Erik to ensure there is a phone available at the SVG Open 2011 F2F [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action03]

<trackbot> Created ACTION-3137 - Ensure there is a phone available at the SVG Open 2011 F2F [on Erik Dahlström - due 2011-10-20].

ED: I suggest starting the SVG Open meeting early in the day to see whether we need the whole day or not
... there might be some people who want to go to the workshops

<TabAtkins_> shepazu has to go to another meeting now

CL: there was a request to discuss the mapping taskforce at the F2F
... so we should ensure there's a substantial discussion on that
... we should check to see whether andreas can attend

<scribe> ACTION: Erik to contact Andreas and Takagi-san about time and attendance of mapping taskforce discussion [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action04]

<trackbot> Created ACTION-3138 - Contact Andreas and Takagi-san about time and attendance of mapping taskforce discussion [on Erik Dahlström - due 2011-10-20].

<ed> http://www.w3.org/2002/09/wbs/19480/Pre-TPAC2011/results

requirements

ED: improving the DOM
... that's a pretty large group of things

CL: it's easy to resolve to make it better, but we need something more concrete
... so we should look at the work WebApps is doing to inform our SVG DOM improvements

ED: we should scope our work to SVG DOM improvements and leave general improvements to the DOM WG

<scribe> ACTION: Cameron to gather and write up a proposal for improving SVG DOM [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action05]

<trackbot> Created ACTION-3139 - Gather and write up a proposal for improving SVG DOM [on Cameron McCormack - due 2011-10-20].

ED: text flow is another one that is a maybe for some people

CL: I put down maybe because it's clearly a requirement, and there's people wanting to do it, otoh the way that we did it produced pushback from css/browser guys
... and now they actually have two specs that cover that (exclusions/regions)
... and it's likely that will work with svg too

CM: so we can include it in the requirements document

CL: but we should point out the different possible approaches (including using the css work)

CM: connectors, it says inkscape folks are working on a proposal to submit about that

TB: not sure they've started on the proposal, but they intend to

ED: I think we can include it as a feature request
... btw do we need to worry about html5/xml?
... whether svg is based on the dom, or the markup

CM: yes I think we should write the spec based on the DOM
... and include details on how particular markup produces a DOM

ED: do we have a writeup of that?

CM: don't think so, discussed briefly in Seattle
... I'd like to see more details

ED: data attributes (and aria) is another thing we should look at from html

CL: yes we should track that

CM: "Intersection of superpath, vector effects and connectors"
... wasn't sure exactly what it was

CL: something similar from vector effects, but it was a real drawing primitive, so probably shouldn't be in VE
... this is useful for shared path edges
... so renderers don't do hazy antialiasing when drawing two shapes with the shared edges
... smaller file size, too
... how that fits with connectors, couldn't tell
... a bit handwavey

CM: so this is basically "shared path edges"

CL: and compound shapes made of multiple paths

<cyril> my colleague at Telecom ParisTech started a wiki page on shared path edges

<cyril> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shared_Path_Motivation

CL: this also means you need to be able to automatically reverse a path edge, for consistent filling

<scribe> ACTION: Chris to work up a shared path edge / superpath proposal [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action06]

<trackbot> Created ACTION-3140 - Work up a shared path edge / superpath proposal [on Chris Lilley - due 2011-10-20].

ACTION-3140: see also http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Shared_Path_Motivation

<trackbot> ACTION-3140 Work up a shared path edge / superpath proposal notes added

ED: next, declarative drawing, the replicate tag

<cyril> chris, feel free to contact Jean-Claude Moissinac, he has several examples on which he could test the proposal

CM: I guess I would like to see it grounded in use cases

ED: I think the gradient-on-lines part of it is interesting

<cyril> what is "gradient-on-lines" ?

CL: one advantage is its declarativeness
... so it would work in HTML background images for example

<ed> cyril: i meant contour gradients, similar to tubefy if you've seen that

<scribe> ACTION: Erik to tease out the different functionality from the "Declarative drawing" requirements entry [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action07]

<trackbot> Created ACTION-3141 - Tease out the different functionality from the "Declarative drawing" requirements entry [on Erik Dahlström - due 2011-10-20].

ED: next, function based input for animate

CL: I'd like to see it motivated a bit more. I think I know what it's for, but I'm not sure.

CM: we might have talked about something like that before, using SMIL for timing and JS for the value computation
... I remember wanting to be able to do that in the past, not sure if it was for anything practical

ED: I'd like to see some actual examples, what it's trying to solve

CM: should we ask david for details / use cases?

CL: yes

<scribe> ACTION: Erik to contact David for more details on function-based input for animate [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action08]

<trackbot> Created ACTION-3142 - Contact David for more details on function-based input for animate [on Erik Dahlström - due 2011-10-20].

ED: next, enhanced text support
... is that the same as the tubefy work?

CM: yes I think the second dotpoint there is
... I can't remember what the outcome of the Seattle discussions on text warping was

<scribe> ACTION: Erik to find the outcome of Seattle text warping discussion and add it to requirements wiki page [recorded in http://www.w3.org/2011/10/13-svg-minutes.html#action09]

<trackbot> Created ACTION-3143 - Find the outcome of Seattle text warping discussion and add it to requirements wiki page [on Erik Dahlström - due 2011-10-20].

- DRAFT -

SVG Working Group Teleconference

13 Oct 2011

Attendees

Contents

SVG2 planning

SVG Open 2011 F2F

requirements

Summary of Action Items

Scribe.perl diagnostic output