See also: IRC log
<trackbot> Date: 23 July 2012
<scribe> scribe: cyril
<scribe> scribeNick: Cyril
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
... 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 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
... 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
ed: wasn't there some suggested text
tab: are you happy to take
heycam: next one from jw is
... 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
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
... 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
<trackbot> ISSUE-2441 -- Intrinsic sizing and percentage values for inline svg in html -- raised
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
... 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?
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)/
<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
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
... 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
... 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 ?
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?
<ChrisL> brad kemper and fantasai
heycam: Cyril are you happy to use background ?
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
heycam: that's all for this list
... I want to make sure we have all the notes done in the spec by the end of week
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
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
heycam: i've put a couple
... 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
... 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
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
CL: have you seen the high resolution time spec?
Dirk: did you also try requestAnimationFrame?
<ChrisL> High Resolution Time
… 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
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?
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
… 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
… the client downloads a playlist and the playlist gives the association between times and files to request
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.
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?
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
… 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
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
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?
… 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>  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 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].
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 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.
<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
BB: then we'll discuss FPWD at
... 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
... 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
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
... 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
... there's an element that gives timing and you sync to that element
... in terms of process, I'd like to participate
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
... 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
... 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
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
jen: I feel the same way
<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
... 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
[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
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
... 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
BB: so we are coming towards a
concrete proposal for the syntax, I wanted to discuss the
... 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 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]
<birtles> corrected syntax proposal:mask: [<funciri> | child | element(compound-selector)] alpha?
<birtles> and again:
<birtles> mask: [<funciri> | child | element(compound-selector)] [alpha|luminance]?
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
... 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
This is scribe.perl Revision: 1.136 of Date: 2011/05/12 12:01:43 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/taht/that/ Succeeded: s/access glyph/access to glyph/ Succeeded: s/I want/I want to see/ Succeeded: s/on it/with it/ WARNING: Bad s/// command: 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)/ Succeeded: s/things/viewport fill property/ Succeeded: s/describing using backgrounds/extend the CSS background property/ Succeeded: s/CC/CL/ FAILED: s/represents/represent/ FAILED: s/SMIL lacks/SMIL lacks (well, mostly)/ FAILED: s/lumaninance/luminance/ FAILED: s/cursoros/cursors/ Found Scribe: cyril Inferring ScribeNick: Cyril Found ScribeNick: Cyril Found ScribeNick: heycam Found ScribeNick: nikos ScribeNicks: Cyril, heycam, nikos Present: Cameron Doug Dirk Jen Brian Nikos Tab Chris Erik Cyril Found Date: 23 Jul 2012 Guessing minutes URL: http://www.w3.org/2012/07/23-svg-minutes.html People with action items: brian cameron chris cyril heycam WARNING: Possible internal error: join/leave lines remaining: <scribe> ... Dmitry has joined Adobe and he's working with us now WARNING: Possible internal error: join/leave lines remaining: <scribe> ... Dmitry has joined Adobe and he's working with us now[End of scribe.perl diagnostic output]