SVG Working Group Teleconference -- 23 Jul 2012

<trackbot> Date: 23 July 2012

<scribe> scribe: cyril

<scribe> scribeNick: Cyril

Agenda review

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda

cm: new topic on Buffered rendering and others added on wednesday

heycam: the plan is to use the sessions when we are not overlapping to do spec work and actions
... I want to see where we are for publishing the FPWD
... we can have a list of requirements/commitments

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments

heycam: I want to make sure the spec as notes where we want to add things
... is the plan to rework the animation chapter in 2 ?
... it would be good to have a note in the chapter to mention that

<scribe> ACTION: Brian to add annotation to the spec to mention web animation spec [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action01]

<trackbot> Created ACTION-3315 - Add annotation to the spec to mention web animation spec [on Brian Birtles - due 2012-07-30].

there is a bunch of things Doug has to do

scribe: Chris, there is one or two of yours

Chris: once that is sorted, I'm happy to have that done this week

heycam: Dirk; there is a couple of yours

<ChrisL> need to get the spec building working first, then will do those

Dirk: yes, there are some that have my name, related to transform stuff
... some of them are obsolete
... for instance svg canvas we said that we will ahve teh html canvas element directly
... we should prepare SVG 2 to add module later

heycam: this is your preference for having several specs
... I'm not sure how much it needs to change in its structure
... the HTML thing is much more detail change that new elements
... my guess is that it shouldn't be too hard to write a new spec for a new element and to override existing things

Tab: Image Values is an example of how easy to extend the base spec without having the base spec prepared for that

heycam: the ones that JW has signed for
... he's been pulled away to not work on SVG stuff
... so we should redistribute them or not do them

<ChrisL> I can take ACTION-3005

heycam: for instance z-index

chris: it is one of those things that's hard to do

dirk: we are doing some refactoring of our svg code and we have a prototype using z-index

chris: do you create a stacking context

dirk: we do just like HTML, same rules

brian: the rewriting in gecko should allow z-index on SVG

heycam: there is some interest for it, so we should have somebody assigned to it

<nikos> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index

ed: wasn't there some suggested text

tab: are you happy to take that?
... yes

heycam: next one from jw is object-fit
... I think that is probably something that relates to CSS in general
... at the risk of giving myself too many, I could take that one

chris: the last one is about white space and I have a similar action

heycam: there is one on Vincent about glyph data
... that is probably not critical for us in SVG 2
... there was some recent things in HTML canvas
... I think that we should make sure the types work
... but we should be able to use the same objects
... I think it's probably not necessary to work on that right now
... any disagrees

(silence)

resolution: SVG 2 FPWD won't have anything about access to glyph path data via an API

heycam: the final thing is promoting attributes to properties
... for the moment it is assigned to Microsoft
... but I said I would come back with a concrete proposal for naming
... I'll definitely do that for the next CSS meeting

dirk: I want to see to develop the CSS attribute/property spec in a separate spec

heycam: my feeling is that if we can get done in time it should be in SVG 2, but if not it is fine as a separate spec to be integrated in a future spec
... a seperate spec, just for that is strange
... I think we should publish a lot quicker that we've been doing before

ed: do we have to have all attributes as properties or only for some of them
... I'm mostly concerned about width/height for the SVG root element
... it's easier to have them as presentation attributes
... it gives what people expect

dirk: I don't think it's a big problem

chris: it's harder if you bring them together, means we have to change the values

ed: I'm noting that both opera and firefox changed that recently
... we should aligned
... the previous was broken

chris: is it written somewhere?

ed: possibly in the tracker

chris: I think we agreed

ed: david baron did not agree with it

heycam: documenting the current behavior does not necessarily require turning them in presentation attributes
... coming back to the larger issue
... 1) have in the spec and hold up the spec if it takes longer
... if this is the case, we should add a note in the spec
... 2) a separate spec
... we might want to add a note too
... we are doing that for transforms

<ed> the thing I mentioned we had in our tracker is ISSUE-2441

<ed> ISSUE-2441?

<trackbot> ISSUE-2441 -- Intrinsic sizing and percentage values for inline svg in html -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2441

chris: why don't we say that some attributes are being promoted to presentation attributes and in the future we might to promote more

heycam: jen what do you think?

jen: I think it's a pretty important
... we'd like to have sooner than later

heycam: my concern is that because the CSS coordination might take a while
... and end up delaying some of the things in here

jen: I would be happy with starting with a set of attributes

heycam: if you would be happy with a separate spec now, I think it's ok
... to get it published and get comments
... but getting changes in the SVG 2 is a large task
... but with a separate spec describing what we are doing with the promotion but with details later

jen: I think it's ok

dirk: Patrick has written up a document in the past

heycam: I think we need to take into acocunt what we discussed recently

dirk: yes, it just needs updating

heycam: is everyone happy with that?

chris: yes

resolution: we will start a document on SVG attribute to property promotion

<ed> s/david baron did not agree on it/david baron agreed with mapping the width/height attributes into style, see https://bugzilla.mozilla.org/show_bug.cgi?id=668163#c40 (note: this is not what the svg 1.1 spec says)/

<krit> http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html

<scribe> ACTION: heycam to get a spec setup for building the new spec for attribute to property promotion [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action02]

<trackbot> Created ACTION-3316 - Get a spec setup for building the new spec for attribute to property promotion [on Cameron McCormack - due 2012-07-30].

jen: would you be happy to help editing the spec

heycam: do we need to mention it in the SVG 2 spec

dirk: yes

heycam: I'll do that in the SVG 2 spec

<scribe> ACTION: heycam to add to the SVG 2 spec a mention about the separate spec on SVG attribute to property promotion [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action03]

<trackbot> Created ACTION-3317 - Add to the SVG 2 spec a mention about the separate spec on SVG attribute to property promotion [on Cameron McCormack - due 2012-07-30].

heycam: I think that covers all the items that don't have ticks

cyril: I have an action on viewport-fill and viewport-fill-opacity

heycam: does this apply to the outer or the inner things as well

ed: I think it applies to both
... any element that establishes a viewport

heycam: would it be naughty to use background-color

chris: it does make sense until the viewport and the content box don't have the same aspect ratio
... it avoid situation when you have white borders
... people wanted to cover a large area
... vpf and vpfo is used whatever the zoom

tab: the backougrnd on HTML body element is hosted on the canvas and applies no matter what the size of the viewport

chris: do you think we could describe the vpf property in the same way ?

tab: yes

chris: but we do want it also for nested viewports

tab: there is only one canvas

chris: in SVG no

tab: that does not seem problematic

chris: there is 2 things: reusing the SVG 1.2 viewport fill property or extend the CSS background property

tab: I'm in favor of less new properties if possible

heycam: in a mixed HTML + SVG, you can put background and it does the right thing
... I wonder if we put backgrounds if people won't put border and thins

ed: I can see people getting confused about backgroud being the fill

heycam: it's probably easier to define as vpf properties but there are so similar

tab: we can say border and everything as 0

chris: one adv of extending CSS properties is to use other paint servers (not only solid colors)

tab: that's well defined for background

chris: I agree with tab that it's better that way but requires the background property

tab: a little bit

chris: who is the editor of hte background spec?

tab: fantasai

<ChrisL> brad kemper and fantasai

heycam: Cyril are you happy to use background ?

cyril: yes

dirk: is this related to paint phases?

tab: no, SVG is simple
... I believe it would be the same level as fill

chris: I'm happy to do that with tab

tab: yes

heycam: that's all for this list then
... I want to make sure we have all the notes done in the spec by the end of week

Test suite setup

ed: I want to see if there is any update on that front

heycam: no, I need to coordinate with plinss to have the right server settings
... people can add tests without having the harness

chris: the whole point is to collect things to create the harness

heycam: but it shouldn't prevent us from adding tests
... anything else related to SVG 2

cyril: I think we should update the SVG WG page
... with the planning information

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

cyril: should we add the new spec to that table?

heycam: can we add things here charter-wise

chris: yes when it's split from a previous spec that's fine

heycam: ok but I don't know what to put for the timeline

<scribe> ACTION: chris to update the roadmap page [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action04]

<trackbot> Created ACTION-3318 - Update the roadmap page [on Chris Lilley - due 2012-07-30].

<ChrisL> I will add links to specs as they are published

heycam: do we want to review the changes section in the spec to agree ?
... and about the coloring of the spec

chris: the coloring forces us to review the spec
... people outside the wg will want what has changed in the spec
... people in the group want to see the level of review
... and they are different

heycam: I don't want big red sections in the sepc

chris: right, we don't want that

heycam: for the new properties we've added things
... things that are new already have a note
... the remaining things are things completely unchanged or just reworded

<ChrisL> we can have two stylesheets, one for us that color-codes review maturity and a different one for publication that hilights more the new vs old wording (and is less colorful)

heycam: you think it's sufficient to include the issue markers

dirk: yes

heycam: i've put a couple already
... we've already have the list of changes in the appendix
... as long as the default view does not have the red background that's fine, even if people can switch to that view
... do we want to review all of the change sections before it's published

chris: yes
... it doesn't have to be a line by line review

heycam: I agree
... some of them I have separate topics for later
... once we have done that review, we should switch from yellow to white
... we should that later, when we have a free slot

<TabAtkins_> Real-world example of wallpaper groups + probabilistic tiling

<TabAtkins_> https://plus.google.com/u/0/108003177348390798444/posts/5u8TN3DdhFu

<heycam> ScribeNick: heycam

SVG as graphics overlay track

http://www.w3.org/Graphics/SVG/WG/wiki/SVGStreaming

CC: I've prepared this page

… I made this page because I want to be able to do some use cases with SVG

… to do that I need to have the notion of streaming of SVG

… and some concepts of streaming mapped to SVG

… I've got a bit of background in there

… all browsers support progressive loading

… streaming is a bit different, it is progressive loading with some additional control

… you load the data when the clock associated with that stream reaches that time stamp

CL: what if it hasn't been received?

CC: you buffer

… that's a failure, not real time any more

… you can define that if it comes 2s late, you jump 2s later in the animation

… as if it had been received at the right time

… I'm proposing this document because I'm working on MPEG DASH, which is a codename for dynamic adaptive streaming of HTTP

… it's getting some traction

… in 3gpp, and in TVs

… people are starting to stream videos over HTTP and they want to have things like subtitles

… when you stream subtitles with video, you could just replace the subtitles with a graphics overlay

… you could in fact do subtitles with SVG

… last week was the MEPG meeting in Stockholm

… there was Apple pushing for WebVTT for subtitles

… carrying the WebVTT in the MP4 file

… on the other side, MS was supporting TTML as another kind of track

… I proposed another set of tools, a generic framework to allow SVG or HTML in there

… in this document I just describde SVG

CL: so this describes XML payloads, so that would handle TTML too?

CC: XML and text payloads

… so both

CC: the important thing is streaming, you chunk it, deliver it according to timestamps

… random access points are when you jump into a stream where you can start processing without having prior data

… if you can decode an image in a video, for example, that's a random access point

… if you join a broadcast of a TV application, you want an access point where you don't need prior data

… maybe you need some prior information and maybe you don't

CL: so it's like full and partial frames in video

CC: going to the use cases

… some of you remember there was some work done in the past, 2D cartoons in SVG

… I've linked to the paper

… this is an example where you have a frame based representation of graphics animations using SVG

… with this there is at least one representation that you can use to make a stream of SVG

… here we converted Flash cartoons to SVG, and we designed a representation where we had a group that was visible for some amount of time, and not visible otherwise

… if you line up groups one after the other, then you have a series of frames

… if you fragment that file, and each group is an XML fragment, then you can push them from the server to the client

… one by one, at the time it needs to be displayed (or just before)

… on top of that, you can use the <discard> element to remove from the DOM tree the frames that you had in the past. then you can really control the memory occupancy of the player.

… with this I just want to highlight that streaming vs progressive loading, the benefit is that you reduce the maximum amount of memory that you need

… it's useful in some cases that you're doing streaming then

… if you just load the XML chunks at the right time and discard when you don't need them, you're good

Dirk: isn't this covered by SMIL?

CC: no SMIL doesn't define fragmentation of XML

… SMIL isn't really about streaming, it's about you download the whole document and you play it

Dirk: the document can reference different files for different times

CC: that's different from what I have here

… where you split the document, but the browser treats it as if it was progressively downloaded

CL: in SMIL the fragmentation is at the file level

CC: in this first use case, if there are cartoons or animations that are subtitles, there's benefit in doing streaming

… you can almost do it already

… you just need a method of splitting the SVG into pieces and how you deliver those pieces

… the second use case is when you want to display graphics on top of a video, like an overlay

… and you want it to be synchronised with the video

… there is a test linked to in the document

… you have a video with SVG graphics on the top

… I tried different ways of synchronising

… for example html timeupdated events

… unfortunately the events aren't accurate enough

<ChrisL> http://www.w3.org/TR/2012/CR-hr-time-20120522/

CL: have you seen the high resolution time spec?

Dirk: did you also try requestAnimationFrame?

<ChrisL> High Resolution Time

<ChrisL> "This specification defines a JavaScript interface that provides the current time in sub-millisecond resolution and such that it is not subject to system clock skew or adjustments. "

… it's an event handler you pass to it

CC: the video changes, a new frame is displayed, and you want to display the SVG corresponding to that video

… when you play that video, there are many reasons for which the video can not be displayed consistently

… you want the SVG to stay synced with the video regardless of whether the video skips frames etc.

CL: this came out of the testing wg, there was a need for higher resolution time

CC: it's not only accuracy, but when the event is triggered

CL: the events have a time stamp, and this spec gives a way to provide higher accuracy

CC: I don't need accuracy, but sent every time there is a change

… I tried with the HTML event, it didn't work

… I tried with setCurrentTime and things like that, but you can't monitor what's happening with the video

… there are 2 use cases. one is the animations streamed, and the other is syncing the animation to the video

… I think first we should align the SVG timing API with the HTML one

… I think what is missing in the SVG API is the playback rate, you can't play back SVG with a speed different from 1

… so far you can say setCurrentTime on an SVG document but not setCurrentSpeed

… but you can do that on HTML video elements

<ChrisL> this api - http://www.w3.org/TR/html5/media-elements.html#htmlmediaelement

… so we should have the same API for playing, pausing, etc.

… alignment here would be good

… then, if you want to have good syncing, then you can't do it with syncing

… relying on JS giving you the exact time that it changes is not feasible

… I think the syncing must be done in the browser

… there should be a mechanism for the author to say "this SVG should be synced with this video"

… there are several ways to do it

… we could allow the mediagroup attribute on the SVG group

… so far it's only allowed on audio and video in HTML

… if you use the same value on two video elements, then they should play synchronously

… I'm suggesting here we allow that on a root <svg> too

… that's one way to achieve this

… another way, maybe not relevant for SVG WG, would be to allow SVG content as a track in HTML5

… so far you can select in a controls of an html video whether you play this subtitle or not

… I want to be able to select it in just the same way

… allowing directly SVG content pointed to directly by a <video> element, but there are restrictions on the type of content you can point to

… the next level for SVG syncing is at the delivery level

… allowing it to be in an RTP stream, etc.

… I'd just like one of the SVG specs to ease the life of people doing those specs

… and this means defining what could be some guidelines on how to make SVG streams

CL: normally if you want to do progressive rendering, you do HTTP

… if you want packetised you do RTP

… this is a third way, but why use HTTP for this?

CC: the industry is dropping RTP for streaming

… for several reasons, routers don't deliver RTP properly, proxies, firewalls, etc.

… plus RTP is not TCP friendly

<shepazu> (what about SPDY?)

… for a video stream, if you capture it you might want to send RTP packets on the fly

… what they tend to do is store each bit in a separate file, and deliver that file separately

… that's what Netflix is using, Smooth streaming from MS

… that's streaming over HTTP

… I'm asking the group whether it would be agreeable to align the SVG timing API with HTML

… whether we should allow authors to specify a syncing attribute

… and third whether we should have guidelines on constructing streamable content

CL: I think we said we like the markup but use the API from HTML

CC: I think the agreement was using it for audio and video in SVG

CL: so extending it to other elements isn't a big step

CC: for the outer svg

CL: I think it makes sense to reuse it where it makes sense

… so I would argue in favour of it

<birtles> https://etherpad.mozilla.org/lIwpKlVNd2

BB: with Web Animations, we've looked at this

… under point 4

… we've come to the same conclusion

… we'd like to use mediagroups on <object>s and <iframe>s too

… when they reference SVG documents

… with speed control too

… so we're thinking the same thing

… if so, then maybe Web Animations is the place to specify that

Doug: I agree that's the right place to specify it, people will want to use HTML for the same thing, HTML overlays

… it should apply to HTML as well as SVG

Dirk: and discuss it in FX

CC: so the Web Animation spec will define how mediagroup applies to SVG, iframes, objects?

BB: yes

CC: I'd be happy to be part of the discussion there

Doug: it sounds to me like you're on the ball wrt the services using these things

… I just wanted to confirm that you're thinking about the comcasts and the big streamers here

… for non browser cases, like STBs

… these are all considerations you're taking into account

CC: yes

… I'd like to extend what is in reach of SVG

… so far we've only reached browsers in a well defined setup, where the browser requests HTTP content as a file from a server

… but there are other setups where content might arrive in a streaming manner

… and I'd like to enable that

Doug: we've already agreed to use the existing captioning in HTML, TTML and WebVTT

… and that SVG would use those things

CL: I don't think we picked a specific one, just the same that HTML is using

… my understanding is that HTML is using WebVTT, while Flash is using TTML

Dirk: I think TTML is allowed by HTML now too

Doug: I think the US FCC picked TTML because it matches existing industry standards on authoring

BB: about the streaming, you said there are benefits to having everything in one file and having the server do fragmentation

… can you elaborate on the benefits?

CC: if you take a large SVG file, and you download it with progressing loading, if the network bandwidth is higher than the bitrate of the SVG file, then you'll load the SVG file faster

… so the size of the DOM tree will increase

… by adding things you don't need yet

… so memory usage will be higher

… if you use the <discard> element you can delete them when they're not needed, but it's too late

CL: so <discard> is for things you no longer need, but this is the opposite case

BB: maybe that's not quite what I was asking. if you have a master file with time stamps, referencing external content for those times, you've already done the fragmentation at the file level. how is that worse than being in one file?

<ChrisL> things you will need in the future

CC: that is what I'm suggesting, taking the initial very big file, fragment it into files or fragments, it's the same

BB: if that's how SMIL full works, pointing off to external resources, fragmentation is already done at the file level

CC: you don't want to split into too many files, each with a separate HTTP request

… you might want to have a single file and just have it come with chunk transfer encoding

CM: the server can just slow its delivery of the file

… but that doesn't work for skipping forward

CC: that's the random access point

… even if you don't want to skip ahead, how do you tell the HTTP server that it should delay the sending of that chunk of the file until that file?

… in the current framework but the AV industry, they use a DASH system, and this setup assumes standard HTTP servers

… and it's only the client doing the intelligence of downloading things when it needs them, or jumping ahead

<ChrisL> http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP

… the client downloads a playlist and the playlist gives the association between times and files to request

<ChrisL> http://www.w3.org/2011/09/webtv/slides/W3C-Workshop.pdf

CC: if you take all the requests that the client makes, and concat them together, that should be a valid SVG document

CL: that's necessary but not sufficient

CC: yes, you also need not referencing IDs not downloaded, etc.

<ChrisL> http://www.w3.org/TR/xml-fragment

CM: how does the client indicate which bit it wants?

CC: the client gets the playlist, and it gets updated every so often, and that playlist indicates which things the client should fetch

CL: and this uses the existing byte range mechanism?

CC: yes

CL: so nothing special on the server

CC: can use SPDY if you want too

… I think this will extend the scope of SVG

… I'm planning on working on a extension for browsers to support that, some people have done JS implementations of the client to pull media chunks from the playlist

… and it's using the chrome media api, in chrome there's a way to get a file and push it into the local media pipeline

Doug: I just want to keep in mind that if there is a content protection scheme that we should use the same as used elsewhere

CC: DASH supports full encyrption or partial encryption

… used in common "premium" video applications

Dirk: isn't it possible to use XHR to get parts of the file?

CC: yes, the JS library they are getting the playlist, parsing it, sending XHR requests, getting the media bytes, and then pushing the media bytes through the chrome media api

<Cyril> http://www-itec.uni-klu.ac.at/dash/?p=792

… what does the group feel about me writing up a note?

CL: it partly falls in SVG and partly not, so a separate document would be good

CC: I'd like to get in touch with the media pipeline tf

Doug: we could have a joint meeting

<Cyril> http://www.w3.org/2011/webtv/wiki/MPTF

CC: one way to develop a prototype for this is to use JS, and then you need an API to input media data

… other way is to do a wrapper around the browser that intercepts HTTP requests and does the request for small files

BB: about whether we need to change SVG or not, I think there are two ways to do it

… one is to have the container document be SVG, have the frames embedded in there

… you could also have some other sort of container document with embedded SVG fragments, and the container document defines the times

… what are the advantages of making the container document an SVG document?

… you could reuse some definitions I guess?

CC: that's one advantage

… in the cartoons use case, you might have a character or symbol reused in different frames

… so you're sending it in the first frame it's used, then reusing it in the future

BB: so you'd have a section at the start that has resources that are going to be reused?

… which later requested frames use?

CC: yes, almost, but you don't want to send all resources you're going to use all at the beginning

… you want to send them as you go

… so it's a bit like adding a <defs> in the middle of the document

BB: but if you've got a character that's defined and reused in multiple frames, how do you ensure that that gets sent before the frames that need it?

CC: you embed that definition in the frame itself

BB: if you do that, what's the advantage of the SVG container document?

CC: no, all the frames are loaded in the same document context

… the symbol you've defiend in the same frame without having to re-send it

BB: how do I ensure definitions are available if I want to skip forward?

CC: you have to indicate that the client has to fetch from the earlier frame that has the definition

Doug: how would you know, as the client, what resources are where and how far back you have to fetch them?

… would it makes sense to have <defs> always retrieved?

CC: not sure in the general case

… it's similar to video, in some video coding standards you need a previous frame to start showing the current frame

… that previous frame you need is the random access point

… random access points are places where you know you don't need anything frmo before

Dirk: can't the playlist mention which resources are needed at a certain point in time?

CL: there are mechanisms in different streaming technologies to say whether a frame can be played by itself, or needs something from before

… there is roll distance, which allows the playlist to say how far back to fetch

BB: I'm not so concerend abotu the particular format, I'm just wondering if all the resources are defined within a frame, whether you need SVG container document or not

… if you don't, then we don't need to change SVG, we can just define a container format separately

… what's the advantage to having it in one SVG document?

CC: if everything you need to have is in the first frame, then you probably don't need a streaming solution for taht

… the reuse of existing resources is small, you can send it in the first place

BB: but even if you have random access points, if the resources you need are embedded in different frames, you could implement it as some other container document that has embedded SVG fragments in it, in which case we don't need to change SVG at all

<Cyril> http://perso.telecom-paristech.fr/~concolat/SVG/flash10.svg

<Cyril> http://perso.telecom-paristech.fr/~concolat/SVG/

BB: in these examples, there's nothing that is gained from having the document itself shared

CC: the intelligence for fetching playlists and parts of the document can be done in a JS library, or at some lower level

BB: so the big win is fallback for UAs that don't supports streaming? they can still play it?

CC: yes

… you can just load the whole file progressively

CL: that's a useful feature

… if it were some extension to SVG where it can't otherwise play it, you're stuck

CC: that page also mentions <discard>, and it's not in the list of things we'll have in SVG2

<ChrisL> [136] have <discard> element to declaratively discard elements from the document tree

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cdiscard.3E_element

[some discussion on unease about <discard>]

<ChrisL> ACTION: Cyril to add <discard> element in SVG2 [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action05]

<trackbot> Created ACTION-3319 - Add <discard> element in SVG2 [on Cyril Concolato - due 2012-07-30].

RESOLUTION: SVG will via Web Animations support synchronisation with other HTML things like video
... SVG WG will work on a guidelines document for authoring streamable SVG

<Cyril> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-track-element

<scribe> ACTION: Cyril to mail whatwg to ask about SVG graphics as a video track [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action06]

<trackbot> Created ACTION-3320 - Mail whatwg to ask about SVG graphics as a video track [on Cyril Concolato - due 2012-07-30].

BB: subtitles on cartoons, how we would do that?

CC: my first thought would be to allow SVG as the <video> src

… SVG inside an <img> has restrictions wrt scripting

… so SVG inside <video> might have the same restrictions

CL: you can't have <track> children for <iframe>s

BB: maybe we should

<ChrisL> HTML WG would need to resolve that

CC: we haven't come across this use case yet

Dirk: so far <track> is just a child of media elements

… we could define <svg> as media elements

BB: so we want mediagroup on object, iframe, etc. and svg

… so maybe at the same time it would make sense to allow <track> children

TA: we need to make sure that current WebVTT rendering model is what we want for general captiosn in SVG, or if that's really only appropriate for videos and we need something more general in SVG

… otherwise I'm totally fine with this

<scribe> ACTION: Cameron to look into sending out mails for svgwg.org commits [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action07]

<trackbot> Created ACTION-3321 - Look into sending out mails for svgwg.org commits [on Cameron McCormack - due 2012-07-30].

<nikos> c'est bon!

<TabAtkins_> Man, wallpaper groups are hard.

<nikos> scribenick: nikos

<Tav> Inkscape does all the wallpaper groups.

Web Animations update

<Tav> I call in tomorrow.

BB: I was asked to give an update on where web animations is going
... Dmitry has joined Adobe and he's working with us now
... in terms of deliverables, there are 3 or 4 pieces.
... web animations spec + note of integration with css and possibly html
... we have deferred integration notes while we work on core spec - which is script API
... the goal is to have it done for SVG open so we can present then

<birtles> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html

BB: then we'll discuss FPWD at next F2F
... still lots of issues present
... things like reversing
... an interesting development to note is that there are 2 distinct ways animations are used
... one is like ui effects - that's something that is short lived and you don't rewind or replay
... the other is content - things like cartoons which you do want to rewind often
... very different use cases
... css transitions fall under effects
... many existsing svg animations fall under the other
... we are thinking of approaching this by having 2 separate timelines
... one for effects which can't be seeked and elements get dropped as they are finished with
... the other allows seeking

CM: is there a difference between 2 separate timelines and just having a flag which disallows seeking?
... what does having 2 timelines give?
... is it cleaner

BB: we think 2 timelines is the best solution, but would be open to other suggestions
... so that's the main change which would be of interest
... lots of other fundamental questions we are still working through
... particularly regarding templates
... how best to represents in the API

s/represents/represent

scribe: one other thing is that Shane Stephens is working on a Javascript prototype and he'll be working on that until the end of August

CC: how does it related to SMIL?

BB: the goal is to eliminate the dependency on SMIL
... we are still learning from SMIL and in order to support backwards compatibility with SVG 1.1 some SMIL features will make their way into the API or the integration note
... and some ideas in the API are drawn from SMIL - like the time containers
... we are learning from it but removing the dependency
... the SVG implementation note will have to duplicate the functionality in full
... some things from SVG 1.1 we are hoping to deprecate
... we are not sure how to approach sync based timing
... some people want it to stick around and others aren't convinced. We need it for backwards compatibility
... we may define it and then note that it will be removed in a later version

CM: of the content that uses SMIL. It's very easy to use sync based stuff so I imagine it's used

BB: yes. we need it
... circular dependencies are a problem
... I have in mind an alternative that gives you the power of sync based timing without the circular dependencies

CL: it would be useful to give the alternative since it's well used
... so having it spec'ed is a prerequisite to deprecating

BB: we are pushing time containers as the alternative. For most use cases they are superior but there are some use cases that they don't work for
... I am looking at an approach similar to media groups in HTML
... where you define an external name that you sync to

CC: have you looked at how VRML does it?
... there's an element that gives timing and you sync to that element
... in terms of process, I'd like to participate

<birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings

BB: there is a meetings page

CC: what is your timeline?
... this is an FXTF document?

BB: At Hamburg FXTF accepted this as a work item
... timeline is to have core spec ready to present at next F2F and we can discuss FPWD then
... end goal is to have it ready for SVG2
... so we can refer to this spec for the animation features of SVG2

RC: there really is no CSS in the spec
... are you worried that it's getting too complex? some people have said they want it to be simple

BB: we are currently looking at simplifying it
... Dmitry has written some examples with Raffael code and he's working out how hard it is to use
... we have to work on usability definitely

shepazu: is there any way this could work in W3C space?
... it would be good if it could be in a place where all are included

BB: we'll talk about how that can happen

CC: so far it says it's about specifying the animation for an author to include animation in the web page
... do you have anything about controlling - seeking, speed, etc?

BB: the link I dropped before is the core API
... within that you have methods for controlling those things

<heycam> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html#the-timeditem-interface

BB: on top of that we are layering the specifications that will have the declarative methods of controlling that (maybe not seek)
... we are considering producing a primer

CM: I'd like to know what Opera people and Microsoft people think about it - if they have an opinion?

ED: I haven't studied it yet but having a general spec for both CSS animations and transitions and SVG is a nice thing to have
... there definitely should be a Javascript API which SMIL lacks

jen: I feel the same way

CM: the thing that made me like it when I was unsure at the start was the introduction of the Javascript API

<ed> s/SMIL lacks/SMIL lacks (well, mostly)/

BB: from an authoring point of view you can produce animations from script and the will potentially be hardware accelerated

shepazu: I've been talking to a lot of people who wonder how to do animation in svg. it's a common question
... the thing I tell people is, if you want to use declarative animation is to use fake SMIL
... one of the downsides is that it doesn't allow you to add declarative animations
... it would be good if we could publish a library that people can play with while we publish the spec
... we could provide different options for the syntax and let people see what they like

BB: that's what I hope will come of Shane's prototype

<Cyril> can you call back ?

<TabAtkins_> We're coming.

CM: I like how the declarative aspects get exposed at the script level and it's not magical

CC: in general, I think there's a difference between CSS animations and SVG animations wrt modifications of the animation while it's running

BB: that's something that wasn't resolved in CSS.
... the CSS WG did resolve that some timing properties would be live. Currently the spec takes a snapshot at the start of the animation and uses them all the way through.
... as far as I'm aware it hasn't been specified which will become live

krit: for SMIL animations they start when the doc is loaded. For CSS it's not specified when they start

BB: for CSS it's the later of two moments. on document load or when the style is resolved
... it's a bit of a mess
... what we have proposed is the start of the timeline can be set to one of 3 possibilities
... 1. document load
... 2. document start - when parsing finishes
... 3. manual - doesn't start until script calls unPause

CC: You plan to have something at SVG open and we will be having a F2F there

CM: we will definitely have the F2F at SVG open

Updated referencing proposal (ID-less masks etc.)

<birtles> http://people.mozilla.org/~bbirtles/pres/referencing-proposal/

[Brian goes over presentation]

Slide 1: masks are currently referenced with id.

CL: your child keyword is nice, but once you have nth child it reminds me of selectors. I'm wondering if it might be better to have keyword child and then a selector to grab what you want

TA: ultimately we make it a url or a selector article

CL: the selector needs to be scoped. The child parameter is creating a scope

shepazu: We wouldn't have to use a name if we're using selectors, we could just add a class

CM: or you could add your own custom attributes and do it however you like
... I don't think there are CSS properties that have selectors as their values

TA: there will be. They will probably be wrapped in a function
... if we do it that way, I'd still want the child keyword as a shortcut

CL: with the child thing. if the child happens to have visbility hidden is it still honoured?

shepazu: child content of a rendering element doesn't render currently
... in my proposal I had, for forwards compatibility or extensibility, we could have child elements of unknown children render
... you could use this for fallback for UAs that don't recognise the element
... in that case, unknown elements act as a group

BB: it sounds like the idea of using a scheme other than IDs is useful
... I want to eliminate dependence on IDs for things like masks, filters, gradients
... it's a real pain when generating content

shepazu: There's plenty of times I want to drop some content into another SVG file

BB: it sounds like everyone is keen on the general idea but perhaps the solutions we have listed aren't great
... perhaps selectors is the way to go
... would it go inside the bracket of child or what?

TA: I'd say child as keyword and then a function
... currently in CSS 4 images I've removed the special map, it's just an id selector, I have no problem extending it to a full selector

<TabAtkins_> http://dev.w3.org/csswg/css4-images/#element-notation

TA: it is defined as an image subtype but there's no problem defining it as another subtype as well

BB: currently for alpha masks we have a type attribute saying whether its an alpha mask or not
... if you want to support other sources for a mask
... you may need to specify how to link them
... The use case is, I want to use that image over there as a mask, because of backwards compatibility that will give you a luminance mask

CL: it needs to be extensible if, in future, we want other types of alpha mask

TA: A better way to do it would be to have an optional keyword to the grammar

<ChrisL> so mask: url(#foo), alpha

shepazu: There's a lot of things that you currently need to have a specialised clip path.
... your clip path property can only reference a clip path element
... most of the time when you are using a wrapper you are doing it for the viewbox
... if it could be a nested svg that you are referencing to get the viewbox, that solves most of issues
... it might be nice to change the things on the referencing element but not on the default element, so that you could use the same element with a different lumaninance

s/lumaninance/luminance

BB: so we are coming towards a concrete proposal for the syntax, I wanted to discuss the scope
... we have a list of elements that depend on IDS
... clip paths - useful
... cursoros - not

s/cursoros/cursors

CM: I think cursors should be allowed if we made cursor more useful

BB: maybe we won't rule out cursor just yet
... marker - makes sense

CM: are there properties that take paints other than fill or stroke?

TA: not in SVG I don't think

BB: feImage - is that worth allowing child elements for content?
... what co-ordinate space does it end up in?

CM: I think we can look at feImage

BB: text-path - I think we agreed we want to do something with it
... which option is better

CM: I'm tempted to say both
... because of possible extensions of path where for shared segments you will need to use some element syntax

BB: so sounds like for scope - it's pretty much all of it

krit: should we allow more selectors than nth child?

CM: are they scoped?

TA: it should accept a compound selector and then run across the children
... only looks at direct children

CM: I don't think there's a need to look deeper than children
... is the idea that a compound selector could selector a non child ?

<birtles> syntax proposal: mask: <funciri> | child | element(compound-selector) [alpha]

TA: yes

<birtles> corrected syntax proposal:mask: [<funciri> | child | element(compound-selector)] alpha?

<birtles> and again:

<birtles> mask: [<funciri> | child | element(compound-selector)] [alpha|luminance]?

<ChrisL> +1

CM: what do we need to do to get this compound selector working?

TA: needs to be added to CSS images 4

CL: for the fill and stroke, that has an interaction with the extensions to fill and stroke in vector-effects
... I want to make sure that still works

CM: I think it just adds to that

Resolution: Will use the 'mask: [<funciri> | child | element(compound-selector)] [alpha|luminance]?' syntax for ID-less referencing

<scribe> ACTION: Brian Incorporate ID-less referencing into the SVG 2 specification [recorded in http://www.w3.org/2012/07/23-svg-minutes.html#action08]

<trackbot> Created ACTION-3322 - Incorporate ID-less referencing into the SVG 2 specification [on Brian Birtles - due 2012-07-30].

<heycam> TabAtkins_, http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org

- DRAFT -

SVG Working Group Teleconference

23 Jul 2012

Attendees

Contents

Agenda review

Test suite setup

SVG as graphics overlay track

Web Animations update

Updated referencing proposal (ID-less masks etc.)

Summary of Action Items

Scribe.perl diagnostic output