- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 23 Jul 2012 13:49:46 -0700
- To: SVG public list <www-svg@w3.org>
Minutes below:
http://www.w3.org/2012/07/23-svg-minutes.html
[1]W3C
[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
Attendees
Present
Cameron, Doug, Dirk, Jen, Brian, Nikos, Tab, Chris,
Erik, Cyril
Regrets
Chair
Cameron
Scribe
cyril
Contents
* [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
<heycam>
[10]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_20
12/Agenda#Agenda
[10]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
cm: new topic on Buffered rendering and others added on
wednesday
heycam: the plan is to use the sessions when we are not
overlapping to do spec work and actions
... I want to see where we are for publishing the FPWD
... we can have a list of requirements/commitments
<heycam>
[11]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Co
mmitments
[11]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
heycam: I want to make sure the spec as notes where we want to
add things
... is the plan to rework the animation chapter in 2 ?
... it would be good to have a note in the chapter to mention
that
<scribe> ACTION: Brian to add annotation to the spec to mention
web animation spec [recorded in
[12]http://www.w3.org/2012/07/23-svg-minutes.html#action01]
<trackbot> Created ACTION-3315 - Add annotation to the spec to
mention web animation spec [on Brian Birtles - due 2012-07-30].
there is a bunch of things Doug has to do
scribe: Chris, there is one or two of yours
Chris: once that is sorted, I'm happy to have that done this
week
heycam: Dirk; there is a couple of yours
<ChrisL> need to get the spec building working first, then will
do those
Dirk: yes, there are some that have my name, related to
transform stuff
... some of them are obsolete
... for instance svg canvas we said that we will ahve teh html
canvas element directly
... we should prepare SVG 2 to add module later
heycam: this is your preference for having several specs
... I'm not sure how much it needs to change in its structure
... the HTML thing is much more detail change that new elements
... my guess is that it shouldn't be too hard to write a new
spec for a new element and to override existing things
Tab: Image Values is an example of how easy to extend the base
spec without having the base spec prepared for that
heycam: the ones that JW has signed for
... he's been pulled away to not work on SVG stuff
... so we should redistribute them or not do them
<ChrisL> I can take ACTION-3005
heycam: for instance z-index
chris: it is one of those things that's hard to do
dirk: we are doing some refactoring of our svg code and we have
a prototype using z-index
chris: do you create a stacking context
dirk: we do just like HTML, same rules
brian: the rewriting in gecko should allow z-index on SVG
heycam: there is some interest for it, so we should have
somebody assigned to it
<nikos>
[13]http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index
[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
general
... at the risk of giving myself too many, I could take that
one
chris: the last one is about white space and I have a similar
action
heycam: there is one on Vincent about glyph data
... that is probably not critical for us in SVG 2
... there was some recent things in HTML canvas
... I think that we should make sure the types work
... but we should be able to use the same objects
... I think it's probably not necessary to work on that right
now
... any disagrees
(silence)
resolution: SVG 2 FPWD won't have anything about access to
glyph path data via an API
heycam: the final thing is promoting attributes to properties
... for the moment it is assigned to Microsoft
... but I said I would come back with a concrete proposal for
naming
... I'll definitely do that for the next CSS meeting
dirk: I want to see to develop the CSS attribute/property spec
in a separate spec
heycam: my feeling is that if we can get done in time it should
be in SVG 2, but if not it is fine as a separate spec to be
integrated in a future spec
... a seperate spec, just for that is strange
... I think we should publish a lot quicker that we've been
doing before
ed: do we have to have all attributes as properties or only for
some of them
... I'm mostly concerned about width/height for the SVG root
element
... it's easier to have them as presentation attributes
... it gives what people expect
dirk: I don't think it's a big problem
chris: it's harder if you bring them together, means we have to
change the values
ed: I'm noting that both opera and firefox changed that
recently
... we should aligned
... the previous was broken
chris: is it written somewhere?
ed: possibly in the tracker
chris: I think we agreed
ed: david baron did not agree with it
heycam: documenting the current behavior does not necessarily
require turning them in presentation attributes
... coming back to the larger issue
... 1) have in the spec and hold up the spec if it takes longer
... if this is the case, we should add a note in the spec
... 2) a separate spec
... we might want to add a note too
... we are doing that for transforms
<ed> the thing I mentioned we had in our tracker is ISSUE-2441
<ed> ISSUE-2441?
<trackbot> ISSUE-2441 -- Intrinsic sizing and percentage values
for inline svg in html -- raised
<trackbot>
[14]http://www.w3.org/Graphics/SVG/WG/track/issues/2441
[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
recently
dirk: yes, it just needs updating
heycam: is everyone happy with that?
chris: yes
resolution: we will start a document on SVG attribute to
property promotion
<ed> s/david baron did not agree on it/david baron agreed with
mapping the width/height attributes into style, see
[15]https://bugzilla.mozilla.org/show_bug.cgi?id=668163#c40
(note: this is not what the svg 1.1 spec says)/
[15] https://bugzilla.mozilla.org/show_bug.cgi?id=668163#c40
<krit>
[16]http://dev.w3.org/SVG/proposals/css-animation/animation-pro
posal.html
[16]
http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html
<scribe> ACTION: heycam to get a spec setup for building the
new spec for attribute to property promotion [recorded in
[17]http://www.w3.org/2012/07/23-svg-minutes.html#action02]
<trackbot> Created ACTION-3316 - Get a spec setup for building
the new spec for attribute to property promotion [on Cameron
McCormack - due 2012-07-30].
jen: would you be happy to help editing the spec
heycam: do we need to mention it in the SVG 2 spec
dirk: yes
heycam: I'll do that in the SVG 2 spec
<scribe> ACTION: heycam to add to the SVG 2 spec a mention
about the separate spec on SVG attribute to property promotion
[recorded in
[18]http://www.w3.org/2012/07/23-svg-minutes.html#action03]
<trackbot> Created ACTION-3317 - Add to the SVG 2 spec a
mention about the separate spec on SVG attribute to property
promotion [on Cameron McCormack - due 2012-07-30].
heycam: I think that covers all the items that don't have ticks
cyril: I have an action on viewport-fill and
viewport-fill-opacity
heycam: does this apply to the outer or the inner things as
well
ed: I think it applies to both
... any element that establishes a viewport
heycam: would it be naughty to use background-color
chris: it does make sense until the viewport and the content
box don't have the same aspect ratio
... it avoid situation when you have white borders
... people wanted to cover a large area
... vpf and vpfo is used whatever the zoom
tab: the backougrnd on HTML body element is hosted on the
canvas and applies no matter what the size of the viewport
chris: do you think we could describe the vpf property in the
same way ?
tab: yes
chris: but we do want it also for nested viewports
tab: there is only one canvas
chris: in SVG no
tab: that does not seem problematic
chris: there is 2 things: reusing the SVG 1.2 viewport fill
property or extend the CSS background property
tab: I'm in favor of less new properties if possible
heycam: in a mixed HTML + SVG, you can put background and it
does the right thing
... I wonder if we put backgrounds if people won't put border
and thins
ed: I can see people getting confused about backgroud being the
fill
heycam: it's probably easier to define as vpf properties but
there are so similar
tab: we can say border and everything as 0
chris: one adv of extending CSS properties is to use other
paint servers (not only solid colors)
tab: that's well defined for background
chris: I agree with tab that it's better that way but requires
the background property
tab: a little bit
chris: who is the editor of hte background spec?
tab: fantasai
<ChrisL> brad kemper and fantasai
heycam: Cyril are you happy to use background ?
cyril: yes
dirk: is this related to paint phases?
tab: no, SVG is simple
... I believe it would be the same level as fill
chris: I'm happy to do that with tab
tab: yes
heycam: that's all for this list then
... I want to make sure we have all the notes done in the spec
by the end of week
Test suite setup
ed: I want to see if there is any update on that front
heycam: no, I need to coordinate with plinss to have the right
server settings
... people can add tests without having the harness
chris: the whole point is to collect things to create the
harness
heycam: but it shouldn't prevent us from adding tests
... anything else related to SVG 2
cyril: I think we should update the SVG WG page
... with the planning information
<heycam> [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
[20]http://www.w3.org/2012/07/23-svg-minutes.html#action04]
<trackbot> Created ACTION-3318 - Update the roadmap page [on
Chris Lilley - due 2012-07-30].
<ChrisL> I will add links to specs as they are published
heycam: do we want to review the changes section in the spec to
agree ?
... and about the coloring of the spec
chris: the coloring forces us to review the spec
... people outside the wg will want what has changed in the
spec
... people in the group want to see the level of review
... and they are different
heycam: I don't want big red sections in the sepc
chris: right, we don't want that
heycam: for the new properties we've added things
... things that are new already have a note
... the remaining things are things completely unchanged or
just reworded
<ChrisL> we can have two stylesheets, one for us that
color-codes review maturity and a different one for publication
that hilights more the new vs old wording (and is less
colorful)
heycam: you think it's sufficient to include the issue markers
dirk: yes
heycam: i've put a couple already
... we've already have the list of changes in the appendix
... as long as the default view does not have the red
background that's fine, even if people can switch to that view
... do we want to review all of the change sections before it's
published
chris: yes
... it doesn't have to be a line by line review
heycam: I agree
... some of them I have separate topics for later
... once we have done that review, we should switch from yellow
to white
... we should that later, when we have a free slot
<TabAtkins_> Real-world example of wallpaper groups +
probabilistic tiling
<TabAtkins_>
[21]https://plus.google.com/u/0/108003177348390798444/posts/5u8
TN3DdhFu
[21]
https://plus.google.com/u/0/108003177348390798444/posts/5u8TN3DdhFu
<heycam> ScribeNick: heycam
SVG as graphics overlay track
[22]http://www.w3.org/Graphics/SVG/WG/wiki/SVGStreaming
[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
track
… I proposed another set of tools, a generic framework to allow
SVG or HTML in there
… in this document I just describde SVG
CL: so this describes XML payloads, so that would handle TTML
too?
CC: XML and text payloads
… so both
CC: the important thing is streaming, you chunk it, deliver it
according to timestamps
… random access points are when you jump into a stream where
you can start processing without having prior data
… if you can decode an image in a video, for example, that's a
random access point
… if you join a broadcast of a TV application, you want an
access point where you don't need prior data
… maybe you need some prior information and maybe you don't
CL: so it's like full and partial frames in video
CC: going to the use cases
… some of you remember there was some work done in the past, 2D
cartoons in SVG
… I've linked to the paper
… this is an example where you have a frame based
representation of graphics animations using SVG
… with this there is at least one representation that you can
use to make a stream of SVG
… here we converted Flash cartoons to SVG, and we designed a
representation where we had a group that was visible for some
amount of time, and not visible otherwise
… if you line up groups one after the other, then you have a
series of frames
… if you fragment that file, and each group is an XML fragment,
then you can push them from the server to the client
… one by one, at the time it needs to be displayed (or just
before)
… on top of that, you can use the <discard> element to remove
from the DOM tree the frames that you had in the past. then you
can really control the memory occupancy of the player.
… with this I just want to highlight that streaming vs
progressive loading, the benefit is that you reduce the maximum
amount of memory that you need
… it's useful in some cases that you're doing streaming then
… if you just load the XML chunks at the right time and discard
when you don't need them, you're good
Dirk: isn't this covered by SMIL?
CC: no SMIL doesn't define fragmentation of XML
… SMIL isn't really about streaming, it's about you download
the whole document and you play it
Dirk: the document can reference different files for different
times
CC: that's different from what I have here
… where you split the document, but the browser treats it as if
it was progressively downloaded
CL: in SMIL the fragmentation is at the file level
CC: in this first use case, if there are cartoons or animations
that are subtitles, there's benefit in doing streaming
… you can almost do it already
… you just need a method of splitting the SVG into pieces and
how you deliver those pieces
… the second use case is when you want to display graphics on
top of a video, like an overlay
… and you want it to be synchronised with the video
… there is a test linked to in the document
… you have a video with SVG graphics on the top
… I tried different ways of synchronising
… for example html timeupdated events
… unfortunately the events aren't accurate enough
<ChrisL> [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
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 -
[24]http://www.w3.org/TR/html5/media-elements.html#htmlmediaele
ment
[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
HTTP
… if you want packetised you do RTP
… this is a third way, but why use HTTP for this?
CC: the industry is dropping RTP for streaming
… for several reasons, routers don't deliver RTP properly,
proxies, firewalls, etc.
… plus RTP is not TCP friendly
<shepazu> (what about SPDY?)
… for a video stream, if you capture it you might want to send
RTP packets on the fly
… what they tend to do is store each bit in a separate file,
and deliver that file separately
… that's what Netflix is using, Smooth streaming from MS
… that's streaming over HTTP
… I'm asking the group whether it would be agreeable to align
the SVG timing API with HTML
… whether we should allow authors to specify a syncing
attribute
… and third whether we should have guidelines on constructing
streamable content
CL: I think we said we like the markup but use the API from
HTML
CC: I think the agreement was using it for audio and video in
SVG
CL: so extending it to other elements isn't a big step
CC: for the outer svg
CL: I think it makes sense to reuse it where it makes sense
… so I would argue in favour of it
<birtles> [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
faster
… so the size of the DOM tree will increase
… by adding things you don't need yet
… so memory usage will be higher
… if you use the <discard> element you can delete them when
they're not needed, but it's too late
CL: so <discard> is for things you no longer need, but this is
the opposite case
BB: maybe that's not quite what I was asking. if you have a
master file with time stamps, referencing external content for
those times, you've already done the fragmentation at the file
level. how is that worse than being in one file?
<ChrisL> things you will need in the future
CC: that is what I'm suggesting, taking the initial very big
file, fragment it into files or fragments, it's the same
BB: if that's how SMIL full works, pointing off to external
resources, fragmentation is already done at the file level
CC: you don't want to split into too many files, each with a
separate HTTP request
… you might want to have a single file and just have it come
with chunk transfer encoding
CM: the server can just slow its delivery of the file
… but that doesn't work for skipping forward
CC: that's the random access point
… even if you don't want to skip ahead, how do you tell the
HTTP server that it should delay the sending of that chunk of
the file until that file?
… in the current framework but the AV industry, they use a DASH
system, and this setup assumes standard HTTP servers
… and it's only the client doing the intelligence of
downloading things when it needs them, or jumping ahead
<ChrisL>
[26]http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_ove
r_HTTP
[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
<ChrisL>
[27]http://www.w3.org/2011/09/webtv/slides/W3C-Workshop.pdf
[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
document
BB: but if you've got a character that's defined and reused in
multiple frames, how do you ensure that that gets sent before
the frames that need it?
CC: you embed that definition in the frame itself
BB: if you do that, what's the advantage of the SVG container
document?
CC: no, all the frames are loaded in the same document context
… the symbol you've defiend in the same frame without having to
re-send it
BB: how do I ensure definitions are available if I want to skip
forward?
CC: you have to indicate that the client has to fetch from the
earlier frame that has the definition
Doug: how would you know, as the client, what resources are
where and how far back you have to fetch them?
… would it makes sense to have <defs> always retrieved?
CC: not sure in the general case
… it's similar to video, in some video coding standards you
need a previous frame to start showing the current frame
… that previous frame you need is the random access point
… random access points are places where you know you don't need
anything frmo before
Dirk: can't the playlist mention which resources are needed at
a certain point in time?
CL: there are mechanisms in different streaming technologies to
say whether a frame can be played by itself, or needs something
from before
… there is roll distance, which allows the playlist to say how
far back to fetch
BB: I'm not so concerend abotu the particular format, I'm just
wondering if all the resources are defined within a frame,
whether you need SVG container document or not
… if you don't, then we don't need to change SVG, we can just
define a container format separately
… what's the advantage to having it in one SVG document?
CC: if everything you need to have is in the first frame, then
you probably don't need a streaming solution for taht
… the reuse of existing resources is small, you can send it in
the first place
BB: but even if you have random access points, if the resources
you need are embedded in different frames, you could implement
it as some other container document that has embedded SVG
fragments in it, in which case we don't need to change SVG at
all
<Cyril>
[31]http://perso.telecom-paristech.fr/~concolat/SVG/flash10.svg
[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
<ed>
[33]http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_In
put#the_.3Cdiscard.3E_element
[33]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cdiscard.3E_element
[some discussion on unease about <discard>]
<ChrisL> ACTION: Cyril to add <discard> element in SVG2
[recorded in
[34]http://www.w3.org/2012/07/23-svg-minutes.html#action05]
<trackbot> Created ACTION-3319 - Add <discard> element in SVG2
[on Cyril Concolato - due 2012-07-30].
RESOLUTION: SVG will via Web Animations support synchronisation
with other HTML things like video
... SVG WG will work on a guidelines document for authoring
streamable SVG
<Cyril>
[35]http://www.whatwg.org/specs/web-apps/current-work/multipage
/the-video-element.html#the-track-element
[35]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-track-element
<scribe> ACTION: Cyril to mail whatwg to ask about SVG graphics
as a video track [recorded in
[36]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
[37]http://www.w3.org/2012/07/23-svg-minutes.html#action07]
<trackbot> Created ACTION-3321 - Look into sending out mails
for svgwg.org commits [on Cameron McCormack - due 2012-07-30].
<nikos> c'est bon!
<TabAtkins_> Man, wallpaper groups are hard.
<nikos> scribenick: nikos
<Tav> Inkscape does all the wallpaper groups.
Web Animations update
<Tav> I call in tomorrow.
BB: I was asked to give an update on where web animations is
going
... Dmitry has joined Adobe and he's working with us now
... in terms of deliverables, there are 3 or 4 pieces.
... web animations spec + note of integration with css and
possibly html
... we have deferred integration notes while we work on core
spec - which is script API
... the goal is to have it done for SVG open so we can present
then
<birtles>
[38]https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.htm
l
[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
timelines
... one for effects which can't be seeked and elements get
dropped as they are finished with
... the other allows seeking
CM: is there a difference between 2 separate timelines and just
having a flag which disallows seeking?
... what does having 2 timelines give?
... is it cleaner
BB: we think 2 timelines is the best solution, but would be
open to other suggestions
... so that's the main change which would be of interest
... lots of other fundamental questions we are still working
through
... particularly regarding templates
... how best to represents in the API
s/represents/represent
scribe: one other thing is that Shane Stephens is working on a
Javascript prototype and he'll be working on that until the end
of August
CC: how does it related to SMIL?
BB: the goal is to eliminate the dependency on SMIL
... we are still learning from SMIL and in order to support
backwards compatibility with SVG 1.1 some SMIL features will
make their way into the API or the integration note
... and some ideas in the API are drawn from SMIL - like the
time containers
... we are learning from it but removing the dependency
... the SVG implementation note will have to duplicate the
functionality in full
... some things from SVG 1.1 we are hoping to deprecate
... we are not sure how to approach sync based timing
... some people want it to stick around and others aren't
convinced. We need it for backwards compatibility
... we may define it and then note that it will be removed in a
later version
CM: of the content that uses SMIL. It's very easy to use sync
based stuff so I imagine it's used
BB: yes. we need it
... circular dependencies are a problem
... I have in mind an alternative that gives you the power of
sync based timing without the circular dependencies
CL: it would be useful to give the alternative since it's well
used
... so having it spec'ed is a prerequisite to deprecating
BB: we are pushing time containers as the alternative. For most
use cases they are superior but there are some use cases that
they don't work for
... I am looking at an approach similar to media groups in HTML
... where you define an external name that you sync to
CC: have you looked at how VRML does it?
... there's an element that gives timing and you sync to that
element
... in terms of process, I'd like to participate
<birtles>
[39]http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
[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
SVG2
RC: there really is no CSS in the spec
... are you worried that it's getting too complex? some people
have said they want it to be simple
BB: we are currently looking at simplifying it
... Dmitry has written some examples with Raffael code and he's
working out how hard it is to use
... we have to work on usability definitely
shepazu: is there any way this could work in W3C space?
... it would be good if it could be in a place where all are
included
BB: we'll talk about how that can happen
CC: so far it says it's about specifying the animation for an
author to include animation in the web page
... do you have anything about controlling - seeking, speed,
etc?
BB: the link I dropped before is the core API
... within that you have methods for controlling those things
<heycam>
[40]https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.htm
l#the-timeditem-interface
[40]
https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html#the-timeditem-interface
BB: on top of that we are layering the specifications that will
have the declarative methods of controlling that (maybe not
seek)
... we are considering producing a primer
CM: I'd like to know what Opera people and Microsoft people
think about it - if they have an opinion?
ED: I haven't studied it yet but having a general spec for both
CSS animations and transitions and SVG is a nice thing to have
... there definitely should be a Javascript API which SMIL
lacks
jen: I feel the same way
CM: the thing that made me like it when I was unsure at the
start was the introduction of the Javascript API
<ed> s/SMIL lacks/SMIL lacks (well, mostly)/
BB: from an authoring point of view you can produce animations
from script and the will potentially be hardware accelerated
shepazu: I've been talking to a lot of people who wonder how to
do animation in svg. it's a common question
... the thing I tell people is, if you want to use declarative
animation is to use fake SMIL
... one of the downsides is that it doesn't allow you to add
declarative animations
... it would be good if we could publish a library that people
can play with while we publish the spec
... we could provide different options for the syntax and let
people see what they like
BB: that's what I hope will come of Shane's prototype
<Cyril> can you call back ?
<TabAtkins_> We're coming.
CM: I like how the declarative aspects get exposed at the
script level and it's not magical
CC: in general, I think there's a difference between CSS
animations and SVG animations wrt modifications of the
animation while it's running
BB: that's something that wasn't resolved in CSS.
... the CSS WG did resolve that some timing properties would be
live. Currently the spec takes a snapshot at the start of the
animation and uses them all the way through.
... as far as I'm aware it hasn't been specified which will
become live
krit: for SMIL animations they start when the doc is loaded.
For CSS it's not specified when they start
BB: for CSS it's the later of two moments. on document load or
when the style is resolved
... it's a bit of a mess
... what we have proposed is the start of the timeline can be
set to one of 3 possibilities
... 1. document load
... 2. document start - when parsing finishes
... 3. manual - doesn't start until script calls unPause
CC: You plan to have something at SVG open and we will be
having a F2F there
CM: we will definitely have the F2F at SVG open
Updated referencing proposal (ID-less masks etc.)
<birtles>
[41]http://people.mozilla.org/~bbirtles/pres/referencing-propos
al/
[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
shortcut
CL: with the child thing. if the child happens to have
visbility hidden is it still honoured?
shepazu: child content of a rendering element doesn't render
currently
... in my proposal I had, for forwards compatibility or
extensibility, we could have child elements of unknown children
render
... you could use this for fallback for UAs that don't
recognise the element
... in that case, unknown elements act as a group
BB: it sounds like the idea of using a scheme other than IDs is
useful
... I want to eliminate dependence on IDs for things like
masks, filters, gradients
... it's a real pain when generating content
shepazu: There's plenty of times I want to drop some content
into another SVG file
BB: it sounds like everyone is keen on the general idea but
perhaps the solutions we have listed aren't great
... perhaps selectors is the way to go
... would it go inside the bracket of child or what?
TA: I'd say child as keyword and then a function
... currently in CSS 4 images I've removed the special map,
it's just an id selector, I have no problem extending it to a
full selector
<TabAtkins_>
[42]http://dev.w3.org/csswg/css4-images/#element-notation
[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
element
... most of the time when you are using a wrapper you are doing
it for the viewbox
... if it could be a nested svg that you are referencing to get
the viewbox, that solves most of issues
... it might be nice to change the things on the referencing
element but not on the default element, so that you could use
the same element with a different lumaninance
s/lumaninance/luminance
BB: so we are coming towards a concrete proposal for the
syntax, I wanted to discuss the scope
... we have a list of elements that depend on IDS
... clip paths - useful
... cursoros - not
s/cursoros/cursors
CM: I think cursors should be allowed if we made cursor more
useful
BB: maybe we won't rule out cursor just yet
... marker - makes sense
CM: are there properties that take paints other than fill or
stroke?
TA: not in SVG I don't think
BB: feImage - is that worth allowing child elements for
content?
... what co-ordinate space does it end up in?
CM: I think we can look at feImage
BB: text-path - I think we agreed we want to do something with
it
... which option is better
CM: I'm tempted to say both
... because of possible extensions of path where for shared
segments you will need to use some element syntax
BB: so sounds like for scope - it's pretty much all of it
krit: should we allow more selectors than nth child?
CM: are they scoped?
TA: it should accept a compound selector and then run across
the children
... only looks at direct children
CM: I don't think there's a need to look deeper than children
... is the idea that a compound selector could selector a non
child ?
<birtles> syntax proposal: mask: <funciri> | child |
element(compound-selector) [alpha]
TA: yes
<birtles> corrected syntax proposal:mask: [<funciri> | child |
element(compound-selector)] alpha?
<birtles> and again:
<birtles> mask: [<funciri> | child |
element(compound-selector)] [alpha|luminance]?
<ChrisL> +1
CM: what do we need to do to get this compound selector
working?
TA: needs to be added to CSS images 4
CL: for the fill and stroke, that has an interaction with the
extensions to fill and stroke in vector-effects
... I want to make sure that still works
CM: I think it just adds to that
Resolution: Will use the 'mask: [<funciri> | child |
element(compound-selector)] [alpha|luminance]?' syntax for
ID-less referencing
<scribe> ACTION: Brian Incorporate ID-less referencing into the
SVG 2 specification [recorded in
[43]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_,
[44]http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
[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
[45]http://www.w3.org/2012/07/23-svg-minutes.html#action08]
[NEW] ACTION: Brian to add annotation to the spec to mention
web animation spec [recorded in
[46]http://www.w3.org/2012/07/23-svg-minutes.html#action01]
[NEW] ACTION: Cameron to look into sending out mails for
svgwg.org commits [recorded in
[47]http://www.w3.org/2012/07/23-svg-minutes.html#action07]
[NEW] ACTION: chris to update the roadmap page [recorded in
[48]http://www.w3.org/2012/07/23-svg-minutes.html#action04]
[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
[50]http://www.w3.org/2012/07/23-svg-minutes.html#action06]
[NEW] ACTION: heycam to add to the SVG 2 spec a mention about
the separate spec on SVG attribute to property promotion
[recorded in
[51]http://www.w3.org/2012/07/23-svg-minutes.html#action03]
[NEW] ACTION: heycam to get a spec setup for building the new
spec for attribute to property promotion [recorded in
[52]http://www.w3.org/2012/07/23-svg-minutes.html#action02]
[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:35 UTC