W3C home > Mailing lists > Public > www-svg@w3.org > July 2012

minutes, Seattle/Paris SVG WG F2F Day 1

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 23 Jul 2012 13:49:46 -0700
Message-ID: <500DB8EA.1090404@mcc.id.au>
To: SVG public list <www-svg@w3.org>
Minutes below:



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

                                - DRAFT -

                     SVG Working Group Teleconference

23 Jul 2012

    See also: [2]IRC log

       [2] http://www.w3.org/2012/07/23-svg-irc


           Cameron, Doug, Dirk, Jen, Brian, Nikos, Tab, Chris,
           Erik, Cyril




      * [3]Topics
          1. [4]Agenda review
          2. [5]Test suite setup
          3. [6]SVG as graphics overlay track
          4. [7]Web Animations update
          5. [8]Updated referencing proposal (ID-less masks etc.)
      * [9]Summary of Action Items

    <trackbot> Date: 23 July 2012

    <scribe> scribe: cyril

    <scribe> scribeNick: Cyril

Agenda review



    cm: new topic on Buffered rendering and others added on

    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: 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

    <scribe> ACTION: Brian to add annotation to the spec to mention
    web animation spec [recorded in

    <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

    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


      [13] 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
    ... at the risk of giving myself too many, I could take that

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

    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
    ... any disagrees


    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
    ... 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
    ... 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
    ... 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


      [14] 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

    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
    (note: this is not what the svg 1.1 spec says)/

      [15] https://bugzilla.mozilla.org/show_bug.cgi?id=668163#c40



    <scribe> ACTION: heycam to get a spec setup for building the
    new spec for attribute to property promotion [recorded in

    <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

    <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

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

    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

    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

    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> [19]http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap

      [19] 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

    <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
    ... 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

    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

    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



    <heycam> ScribeNick: heycam

SVG as graphics overlay track


      [22] 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

    … 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

    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

    … 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

    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> [23]http://www.w3.org/TR/2012/CR-hr-time-20120522/

      [23] 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

    … 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

    … but you can do that on HTML video elements

    <ChrisL> this api -

      [24] 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

    … 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

    … 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

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

    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> [25]https://etherpad.mozilla.org/lIwpKlVNd2

      [25] 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

    … 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


      [26] 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


      [27] 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> [28]http://www.w3.org/TR/xml-fragment

      [28] 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> [29]http://www-itec.uni-klu.ac.at/dash/?p=792

      [29] 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> [30]http://www.w3.org/2011/webtv/wiki/MPTF

      [30] 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

    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

    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

    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


      [31] http://perso.telecom-paristech.fr/~concolat/SVG/flash10.svg

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

      [32] 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> [$1\47] have <discard> element to declaratively
    discard elements from the document tree



    [some discussion on unease about <discard>]

    <ChrisL> ACTION: Cyril to add <discard> element in SVG2
    [recorded in

    <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



    <scribe> ACTION: Cyril to mail whatwg to ask about SVG graphics
    as a video track [recorded in

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

    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

    <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
    ... 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


      [38] 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
    ... 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
    ... particularly regarding templates
    ... how best to represents in the API


    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
    ... 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
    ... in terms of process, I'd like to participate


      [39] 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

    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

    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,

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



    BB: on top of that we are layering the specifications that will
    have the declarative methods of controlling that (maybe not
    ... 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

    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.)


      [41] 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

    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
    ... in my proposal I had, for forwards compatibility or
    extensibility, we could have child elements of unknown children
    ... 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
    ... 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


      [42] 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
    ... 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


    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


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

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

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

    TA: not in SVG I don't think

    BB: feImage - is that worth allowing child elements for
    ... 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
    ... 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

    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

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

    <heycam> TabAtkins_,

      [44] http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org

Summary of Action Items

    [NEW] ACTION: Brian Incorporate ID-less referencing into the
    SVG 2 specification [recorded in
    [NEW] ACTION: Brian to add annotation to the spec to mention
    web animation spec [recorded in
    [NEW] ACTION: Cameron to look into sending out mails for
    svgwg.org commits [recorded in
    [NEW] ACTION: chris to update the roadmap page [recorded in
    [NEW] ACTION: Cyril to add <discard> element in SVG2 [recorded
    in [49]http://www.w3.org/2012/07/23-svg-minutes.html#action05]
    [NEW] ACTION: Cyril to mail whatwg to ask about SVG graphics as
    a video track [recorded in
    [NEW] ACTION: heycam to add to the SVG 2 spec a mention about
    the separate spec on SVG attribute to property promotion
    [recorded in
    [NEW] ACTION: heycam to get a spec setup for building the new
    spec for attribute to property promotion [recorded in

    [End of minutes]

     Minutes formatted by David Booth's [53]scribe.perl version
     1.136 ([54]CVS log)
     $Date: 2012/07/23 20:47:57 $
Received on Monday, 23 July 2012 20:50:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:36 UTC