14:16:13 <RRSAgent> RRSAgent has joined #svg
14:16:13 <RRSAgent> logging to http://www.w3.org/2012/07/23-svg-irc
14:16:15 <trackbot> RRSAgent, make logs public
14:16:17 <trackbot> Zakim, this will be GA_SVGWG
14:16:17 <Zakim> I do not see a conference matching that name scheduled within the next hour, trackbot
14:16:18 <trackbot> Meeting: SVG Working Group Teleconference
14:16:18 <trackbot> Date: 23 July 2012
14:16:32 <heycam> Chair: Cameron
14:17:01 <Cyril> scribe: cyril
14:17:05 <Cyril> scribeNick: Cyril
14:17:48 <Cyril> topic: Agenda review
14:26:19 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Seattle_Paris_2012/Agenda#Agenda
14:26:27 <jen> jen has joined #svg
14:26:29 <krit> krit has joined #svg
14:26:34 <Cyril> cm: new topic on Buffered rendering and others added on wednesday
14:26:58 <cabanier> cabanier has joined #svg
14:27:01 <ChrisL> ChrisL has joined #svg
14:27:16 <ChrisL> rrsagent, here
14:27:16 <RRSAgent> See http://www.w3.org/2012/07/23-svg-irc#T14-27-16
14:27:21 <Cyril> heycam: the plan is to use the sessions when we are not overlapping to do spec work and actions
14:27:35 <shepazu> shepazu has joined #svg
14:27:40 <Cyril> ... I want to see where we are for publishing the FPWD
14:27:55 <Cyril> ... we can have a list of requirements/commitments
14:27:59 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
14:28:08 <Cyril> ... I want to make sure the spec as notes where we want to add things
14:29:37 <Cyril> ... is the plan to rework the animation chapter in 2 ?
14:29:48 <Cyril> ... it would be good to have a note in the chapter to mention that
14:30:26 <Cyril> ACTION: Brian to add annotation to the spec to mention web animation spec
14:30:27 <trackbot> Created ACTION-3315 - Add annotation to the spec to mention web animation spec [on Brian Birtles - due 2012-07-30].
14:30:49 <Cyril> there is a bunch of things Doug has to do
14:31:04 <Cyril> ... Chris, there is one or two of yours
14:31:17 <Cyril> Chris: once that is sorted, I'm happy to have that done this week
14:31:36 <Cyril> heycam: Dirk; there is a couple of yours
14:31:38 <ChrisL> need to get the spec building working first, then will do those
14:32:08 <Cyril> Dirk: yes, there are some that have my name, related to transform stuff
14:32:15 <Cyril> ... some of them are obsolete
14:32:40 <Cyril> ... for instance svg canvas we said that we will ahve teh html canvas element directly
14:33:24 <Cyril> ... we should prepare SVG 2 to add module later 
14:33:34 <Cyril> heycam: this is your preference for having several specs 
14:33:45 <Cyril> ... I'm not sure how much it needs to change in its structure
14:34:05 <Cyril> ... the HTML thing is much more detail change that new elements
14:34:33 <Cyril> ... my guess is that it shouldn't be too hard to write a new spec for a new element and to override existing things
14:35:55 <Cyril> Tab: Image Values is an example of how easy to extend the base spec without having the base spec prepared for that
14:36:22 <Cyril> heycam: the ones that JW has signed for
14:36:34 <Cyril> ... he's been pulled away to not work on SVG stuff
14:36:42 <Cyril> ... so we should redistribute them or not do them
14:37:14 <ChrisL> I can take ACTION-3005
14:37:39 <Cyril> ... for instance z-index
14:37:54 <Cyril> chris: it is one of those things that's hard to do
14:38:16 <Cyril> dirk: we are doing some refactoring of our svg code and we have a prototype using z-index
14:38:23 <Cyril> chris: do you create a stacking context
14:38:31 <Cyril> dirk: we do just like HTML, same rules
14:38:50 <Cyril> brian: the rewriting in gecko should allow z-index on SVG
14:39:13 <Cyril> heycam: there is some interest for it, so we should have somebody assigned to it
14:39:18 <nikos> http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index
14:39:23 <Cyril> ed: wasn't there some suggested text
14:40:08 <Cyril> tab: are you happy to take taht?
14:40:12 <Cyril> tab: yes
14:40:18 <Cyril> s/taht/that/
14:40:53 <Cyril> heycam: next one from jw is object-fit 
14:41:12 <Cyril> ... I think that is probably something that relates to CSS in general 
14:41:31 <Cyril> ... at the risk of giving myself too many, I could take that one
14:42:13 <Cyril> chris: the last one is about white space and I have a similar action
14:42:50 <Cyril> heycam: there is one on Vincent about glyph data
14:43:49 <Cyril> ... that is probably not critical for us in SVG 2
14:43:57 <Cyril> ... there was some recent things in HTML canvas
14:44:08 <Cyril> ... I think that we should make sure the types work
14:44:19 <Cyril> ... but we should be able to use the same objects
14:45:52 <Cyril> ... I think it's probably not necessary to work on that right now
14:45:56 <Cyril> ... any disagrees
14:45:59 <Cyril> (silence)
14:47:10 <Cyril> resolution: SVG 2 FPWD won't have anything about access glyph path data via an API
14:47:28 <Cyril> s/access glyph/access to glyph/
14:47:42 <Cyril> heycam: the final thing is promoting attributes to properties
14:47:53 <Cyril> ... for the moment it is assigned to Microsoft
14:48:09 <Cyril> ... but I said I would come back with a concrete proposal for naming
14:48:27 <Cyril> ... I'll definitely do that for the next CSS meeting
14:50:13 <Cyril> dirk: I want to develop the CSS attribute/property spec in a separate spec
14:50:34 <ChrisL> s/I want/I want to see/
14:51:13 <Cyril> 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
14:51:27 <Cyril> ... a seperate spec, just for that is strange
14:51:40 <Cyril> ... I think we should publish a lot quicker that we've been doing before
14:51:59 <Cyril> ed: do we have to have all attributes as properties or only for some of them
14:52:11 <Cyril> ... I'm mostly concerned about width/height for the SVG root element
14:52:21 <Cyril> ... it's easier to have them as presentation attributes
14:52:28 <Cyril> ... it gives what people expect
14:52:56 <Cyril> dirk: I don't think it's a big problem
14:53:17 <Cyril> chris: it's harder if you bring them together, means we have to change the values
14:53:37 <Cyril> ed: I'm noting that both opera and firefox changed that recently
14:53:41 <Cyril> ... we should aligned
14:53:52 <Cyril> ... the previous was broken
14:54:00 <Cyril> chris: is it written somewhere?
14:54:06 <Cyril> ed: possibly in the tracker
14:54:19 <Cyril> chris: I think we agreed
14:54:28 <Cyril> ed: david baron did not agree on it
14:54:39 <Cyril> s/on it/with it/
14:55:08 <Cyril> heycam: documenting the current behavior does not necessarily require turning them in presentation attributes
14:55:15 <Cyril> ... coming back to the larger issue
14:55:29 <Cyril> ... 1) have in the spec and hold up the spec if it takes longer
14:55:42 <Cyril> ... if this is the case, we should add a note in the spec
14:55:48 <Cyril> ... 2) a separate spec
14:55:56 <Cyril> ... we might want to add a note too
14:56:15 <Cyril> ... we are doing that for transforms
14:56:28 <ed> the thing I mentioned we had in our tracker is ISSUE-2441
14:56:38 <ed> ISSUE-2441?
14:56:38 <trackbot> ISSUE-2441 -- Intrinsic sizing and percentage values for inline svg in html -- raised
14:56:38 <trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2441
14:56:47 <Cyril> chris: why don't we say that some attributes are being promoted to presentation attributes and in the future we might to promote more
14:56:55 <Cyril> heycam: jen what do you think?
14:57:22 <Cyril> jen: I think it's a pretty important 
14:57:46 <Cyril> ... we'd like to have sooner than later 
14:58:01 <TabAtkins_> TabAtkins_ has joined #svg
14:58:06 <Cyril> heycam: my concern is that because the CSS coordination might take a while 
14:58:17 <Cyril> ... and end up delaying some of the things in here
14:59:06 <Cyril> jen: I would be happy with starting with a set of attributes
14:59:27 <Cyril> heycam: if you would be happy with a separate spec now, I think it's ok
14:59:35 <Cyril> ... to get it published and get comments
14:59:44 <Cyril> ... but getting changes in the SVG 2 is a large task
15:00:04 <Cyril> ... but with a separate spec describing what we are doing with the promotion but with details later
15:00:10 <Cyril> jen: I think it's ok
15:00:32 <Cyril> dirk: Patrick has written up a document in the past
15:00:47 <Cyril> heycam: I think we need to take into acocunt what we discussed recently
15:00:53 <Cyril> dirk: yes, it just needs updating
15:01:05 <Cyril> heycam: is everyone happy with that?
15:01:08 <Cyril> chris: yes
15:01:24 <Cyril> resolution: we will start a document on SVG attribute to property promotion
15:01:33 <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)/
15:02:03 <krit> http://dev.w3.org/SVG/proposals/css-animation/animation-proposal.html
15:02:10 <Cyril> action: heycam to get a spec setup for building the new spec for attribute to property promotion
15:02:10 <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].
15:02:34 <Cyril> jen: would you be happy to help editing the spec
15:02:52 <Cyril> heycam: do we need to mention it in the SVG 2 spec
15:02:55 <Cyril> dirk: yes
15:03:10 <Cyril> heycam: I'll do that in the SVG 2 spec
15:03:47 <Cyril> action: heycam to add to the SVG 2 spec a mention about the separate spec on SVG attribute to property promotion 
15:03:47 <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].
15:04:11 <Cyril> heycam: I think that covers all the items that don't have ticks
15:04:45 <Cyril> cyril: I have an action on viewport-fill and viewport-fill-opacity
15:04:55 <Cyril> heycam: does this apply to the outer or the inner things as well
15:05:01 <Cyril> ed: I think it applies to both
15:05:09 <Cyril> ... any element that establishes a viewport
15:05:20 <Cyril> heycam: would it be naughty to use background-color
15:05:44 <Cyril> chris: it does make sense until the viewport and the content box don't have the same aspect ratio
15:05:57 <Cyril> ... it avoid situation when you have white borders
15:06:15 <Cyril> ... people wanted to cover a large area
15:06:33 <Cyril> ... vpf and vpfo is used whatever the zoom
15:07:19 <Cyril> tab: the backougrnd on HTML body element is hosted on the canvas and applies no matter what the size of the viewport
15:08:03 <Cyril> chris: do you think we could describe the vpf property in the same way ?
15:08:05 <Cyril> tab: yes
15:08:19 <Cyril> chris: but we do want it also for nested viewports 
15:08:26 <Cyril> tab: there is only one canvas
15:08:31 <Cyril> chris: in SVG no
15:09:15 <Cyril> tab: that does not seem problematic
15:09:35 <Cyril> chris: there is 2 things: reusing the SVG 1.2 things or describing using backgrounds
15:09:45 <Cyril> tab: I'm in favor of less new properties if possible
15:10:05 <Cyril> heycam: in a mixed HTML + SVG, you can put background and it does the right thing
15:10:35 <ChrisL> s/things/viewport fill property/
15:10:44 <Cyril> ... I wonder if we put backgrounds if people won't put border and thins
15:10:56 <Cyril> ed: I can see people getting confused about backgroud being the fill
15:11:00 <ChrisL> s/describing using backgrounds/extend the CSS background property/
15:11:14 <Cyril> heycam: it's probably easier to define as vpf properties but there are so similar
15:11:33 <Cyril> tab: we can say border and everything as 0
15:11:57 <Cyril> chris: one adv of extending CSS properties is to use other paint servers (not only solid colors)
15:12:16 <Cyril> tab: that's well defined for background
15:12:33 <Cyril> chris: I agree with tab that it's better that way but requires the background property
15:12:36 <Cyril> tab: a little bit
15:12:51 <Cyril> chris: who is the editor of hte background spec? 
15:12:57 <Cyril> tab: fantasai
15:13:01 <ChrisL> brad kemper and fantasai
15:14:09 <Cyril> heycam: Cyril are you happy to use background ?
15:14:13 <Cyril> cyril: yes
15:15:14 <Cyril> dirk: is this related to paint phases?
15:15:21 <Cyril> tab: no, SVG is simple
15:15:44 <Cyril> ... I believe it would be the same level as fill
15:16:30 <Cyril> chris: I'm happy to do that with tab
15:16:33 <Cyril> tab: yes
15:17:19 <Cyril> heycam: that's all for this list then
15:17:34 <Cyril> ... I want to make sure we have all the notes done in the spec by the end of week
15:17:50 <Cyril> Topic: Test suite setup
15:18:04 <Cyril> ed: I want to see if there is any update on that front
15:18:24 <Cyril> heycam: no, I need to coordinate with plinss to have the right server settings
15:18:36 <Cyril> ... people can add tests without having the harness
15:18:56 <Cyril> chris: the whole point is to collect things to create the harness
15:19:08 <Cyril> heycam: but it shouldn't prevent us from adding tests
15:19:18 <Cyril> heycam: anything else related to SVG 2
15:19:50 <Cyril> cyril: I think we should update the SVG WG page
15:20:01 <Cyril> ... with the planning information
15:20:26 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Roadmap
15:21:33 <Cyril> cyril: should we add the new spec to that table?
15:21:48 <Cyril> heycam: can we add things here charter-wise
15:22:00 <Cyril> chris: yes when it's split from a previous spec that's fine
15:22:12 <Cyril> heycam: ok but I don't know what to put for the timeline
15:22:59 <Cyril> action: chris to update the roadmap page 
15:22:59 <trackbot> Created ACTION-3318 - Update the roadmap page  [on Chris Lilley - due 2012-07-30].
15:23:00 <jarek> jarek has joined #svg
15:23:16 <ChrisL> I will add links to specs as they are published
15:23:46 <Cyril> heycam: do we want to review the changes section in the spec to agree ?
15:23:56 <Cyril> ... and about the coloring of the spec
15:24:05 <Cyril> chris: the coloring forces us to review the spec
15:24:26 <Cyril> ... people outside the wg will want what has changed in the spec
15:24:36 <Cyril> ... people in the group want to see the level of review
15:24:42 <Cyril> ... and they are different
15:25:11 <Cyril> heycam: I don't want big red sections in the sepc
15:25:17 <Cyril> chris: right, we don't want that
15:25:50 <Cyril> heycam: for the new properties we've added things 
15:26:47 <Cyril> heycam: things that are new already have a note
15:27:06 <Cyril> ... the remaining things are things completely unchanged or just reworded
15:27:23 <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)
15:28:56 <Cyril> heycam: you think it's sufficient to include the issue markers
15:28:59 <Cyril> dirk: yes
15:29:06 <Cyril> heycam: i've put a couple already
15:30:02 <Cyril> ... we've already have the list of changes in the appendix
15:30:54 <Cyril> ... as long as the default view does not have the red background that's fine, even if people can switch to that view
15:31:19 <Cyril> ... do we want to review all of the change sections before it's published
15:31:21 <Cyril> chris: yes
15:31:33 <Cyril> ... it doesn't have to be a line by line review
15:31:36 <Cyril> heycam: I agree
15:31:49 <Cyril> ... some of them I have separate topics for later
15:32:09 <Cyril> ... once we have done that review, we should switch from yellow to white
15:32:51 <Cyril> ... we should that later, when we have a free slot
15:45:59 <TabAtkins_> Real-world example of wallpaper groups + probabilistic tiling
15:46:01 <TabAtkins_> https://plus.google.com/u/0/108003177348390798444/posts/5u8TN3DdhFu
15:52:12 <heycam> ScribeNick: heycam
15:52:20 <heycam> Topic: SVG as graphics overlay track
15:52:24 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVGStreaming
15:52:32 <heycam> CC: I've prepared this page
15:52:47 <heycam> … I made this page because I want to be able to do some use cases with SVG
15:52:52 <heycam> … to do that I need to have the notion of streaming of SVG
15:52:57 <heycam> … and some concepts of streaming mapped to SVG
15:53:02 <heycam> … I've got a bit of background in there
15:53:19 <heycam> … all browsers support progressive loading
15:53:32 <heycam> … streaming is a bit different, it is progressive loading with some additional control
15:53:51 <heycam> … you load the data when the clock associated with that stream reaches that time stamp
15:53:56 <heycam> CL: what if it hasn't been received?
15:53:58 <heycam> CC: you buffer
15:54:06 <heycam> … that's a failure, not real time any more
15:54:23 <heycam> … you can define that if it comes 2s late, you jump 2s later in the animation
15:54:29 <heycam> … as if it had been received at the right time
15:54:44 <heycam> … I'm proposing this document because I'm working on MPEG DASH, which is a codename for dynamic adaptive streaming of HTTP
15:54:47 <heycam> … it's getting some traction
15:54:52 <heycam> … in 3gpp, and in TVs
15:55:08 <heycam> … people are starting to stream videos over HTTP and they want to have things like subtitles
15:55:19 <heycam> … when you stream subtitles with video, you could just replace the subtitles with a graphics overlay
15:55:23 <heycam> … you could in fact do subtitles with SVG
15:55:30 <heycam> … last week was the MEPG meeting in Stockholm
15:55:37 <heycam> … there was Apple pushing for WebVTT for subtitles
15:55:43 <heycam> … carrying the WebVTT in the MP4 file
15:55:54 <heycam> … on the other side, MS was supporting TTML as another kind of track
15:56:11 <heycam> … I proposed another set of tools, a generic framework to allow SVG or HTML in there
15:56:22 <heycam> … in this document I just describde SVG
15:56:34 <heycam> CL: so this describes XML payloads, so that would handle TTML too?
15:56:37 <heycam> CC: XML and text payloads
15:56:38 <heycam> … so both
15:56:49 <heycam> CC: the important thing is streaming, you chunk it, deliver it according to timestamps
15:57:04 <heycam> … random access points are when you jump into a stream where you can start processing without having prior data
15:57:12 <heycam> … if you can decode an image in a video, for example, that's a random access point
15:57:24 <heycam> … if you join a broadcast of a TV application, you want an access point where you don't need prior data
15:57:30 <heycam> … maybe you need some prior information and maybe you don't
15:57:44 <heycam> CL: so it's like full and partial frames in video
15:59:35 <heycam> CC: going to the use cases
15:59:45 <heycam> … some of you remember there was some work done in the past, 2D cartoons in SVG
15:59:48 <heycam> … I've linked to the paper
15:59:57 <heycam> … this is an example where you have a frame based representation of graphics animations using SVG
16:00:14 <heycam> … with this there is at least one representation that you can use to make a stream of SVG
16:00:32 <heycam> … 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
16:00:41 <heycam> … if you line up groups one after the other, then you have a series of frames
16:00:56 <heycam> … if you fragment that file, and each group is an XML fragment, then you can push them from the server to the client
16:01:04 <heycam> … one by one, at the time it needs to be displayed (or just before)
16:01:25 <heycam> … 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.
16:01:39 <heycam> … 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
16:01:48 <heycam> … it's useful in some cases that you're doing streaming then
16:01:57 <heycam> … if you just load the XML chunks at the right time and discard when you don't need them, you're good
16:02:03 <heycam> Dirk: isn't this covered by SMIL?
16:02:13 <heycam> CC: no SMIL doesn't define fragmentation of XML
16:02:59 <heycam> … SMIL isn't really about streaming, it's about you download the whole document and you play it
16:03:05 <heycam> Dirk: the document can reference different files for different times
16:03:17 <heycam> CC: that's different from what I have here
16:03:32 <heycam> … where you split the document, but the browser treats it as if it was progressively downloaded
16:03:39 <heycam> CL: in SMIL the fragmentation is at the file level
16:04:06 <heycam> CC: in this first use case, if there are cartoons or animations that are subtitles, there's benefit in doing streaming
16:04:08 <heycam> … you can almost do it already
16:04:20 <heycam> … you just need a method of splitting the SVG into pieces and how you deliver those pieces
16:04:29 <heycam> … the second use case is when you want to display graphics on top of a video, like an overlay
16:04:40 <heycam> … and you want it to be synchronised with the video
16:04:50 <heycam> … there is a test linked to in the document
16:05:00 <heycam> … you have a video with SVG graphics on the top
16:06:20 <ChrisL> q+ to ask relationship to high resolution time
16:06:20 <heycam> … I tried different ways of synchronising
16:06:27 <heycam> … for example html timeupdated events
16:06:36 <heycam> … unfortunately the events aren't accurate enough
16:06:47 <ChrisL> http://www.w3.org/TR/2012/CR-hr-time-20120522/
16:06:47 <heycam> CL: have you seen the high resolution time spec?
16:06:54 <heycam> Dirk: did you also try requestAnimationFrame?
16:06:56 <ChrisL> High Resolution Time
16:07:11 <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. "
16:07:16 <heycam> … it's an event handler you pass to it
16:07:27 <heycam> CC: the video changes, a new frame is displayed, and you want to display the SVG corresponding to that video
16:07:48 <heycam> … when you play that video, there are many reasons for which the video can not be displayed consistently
16:08:01 <heycam> … you want the SVG to stay synced with the video regardless of whether the video skips frames etc.
16:08:30 <heycam> CL: this came out of the testing wg, there was a need for higher resolution time
16:08:37 <heycam> CC: it's not only accuracy, but when the event is triggered
16:09:05 <heycam> CL: the events have a time stamp, and this spec gives a way to provide higher accuracy
16:09:14 <heycam> CC: I don't need accuracy, but sent every time there is a change
16:09:23 <heycam> … I tried with the HTML event, it didn't work
16:09:38 <heycam> … I tried with setCurrentTime and things like that, but you can't monitor what's happening with the video
16:09:52 <heycam> … there are 2 use cases. one is the animations streamed, and the other is syncing the animation to the video
16:10:00 <heycam> … I think first we should align the SVG timing API with the HTML one
16:10:14 <heycam> … 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
16:10:48 <heycam> … so far you can say setCurrentTime on an SVG document but not setCurrentSpeed
16:10:52 <heycam> … but you can do that on HTML video elements
16:11:01 <ChrisL> this api - http://www.w3.org/TR/html5/media-elements.html#htmlmediaelement
16:11:01 <heycam> … so we should have the same API for playing, pausing, etc.
16:11:06 <heycam> … alignment here would be good
16:11:15 <heycam> … then, if you want to have good syncing, then you can't do it with syncing
16:11:24 <heycam> … relying on JS giving you the exact time that it changes is not feasible
16:11:34 <heycam> … I think the syncing must be done in the browser
16:11:48 <heycam> … there should be a mechanism for the author to say "this SVG should be synced with this video"
16:11:52 <heycam> … there are several ways to do it
16:11:58 <heycam> … we could allow the mediagroup attribute on the SVG group
16:12:03 <heycam> … so far it's only allowed on audio and video in HTML
16:12:15 <heycam> … if you use the same value on two video elements, then they should play synchronously
16:12:24 <heycam> … I'm suggesting here we allow that on a root <svg> too
16:12:29 <heycam> … that's one way to achieve this
16:12:40 <heycam> … another way, maybe not relevant for SVG WG, would be to allow SVG content as a track in HTML5
16:12:41 <shepazu> shepazu has joined #svg
16:12:53 <heycam> … so far you can select in a controls of an html video whether you play this subtitle or not
16:13:02 <heycam> … I want to be able to select it in just the same way
16:13:22 <heycam> … allowing directly SVG content pointed to directly by a <video> element, but there are restrictions on the type of content you can point to
16:13:33 <heycam> … the next level for SVG syncing is at the delivery level
16:13:51 <heycam> … allowing it to be in an RTP stream, etc.
16:14:03 <heycam> … I'd just like one of the SVG specs to ease the life of people doing those specs
16:14:11 <heycam> … and this means defining what could be some guidelines on how to make SVG streams
16:14:19 <shepazu> q+ to talk about fullscreen, captions, streaming tv
16:14:30 <heycam> CL: normally if you want to do progressive rendering, you do HTTP
16:14:34 <heycam> … if you want packetised you do RTP
16:14:45 <heycam> … this is a third way, but why use HTTP for this?
16:14:54 <heycam> CC: the industry is dropping RTP for streaming
16:15:08 <heycam> … for several reasons, routers don't deliver RTP properly, proxies, firewalls, etc.
16:15:15 <heycam> … plus RTP is not TCP friendly
16:15:15 <shepazu> (what about SPDY?)
16:15:35 <heycam> … for a video stream, if you capture it you might want to send RTP packets on the fly
16:15:53 <heycam> … what they tend to do is store each bit in a separate file, and deliver that file separately
16:16:04 <heycam> … that's what Netflix is using, Smooth streaming from MS
16:16:08 <heycam> … that's streaming over HTTP
16:16:24 <heycam> … I'm asking the group whether it would be agreeable to align the SVG timing API with HTML
16:16:35 <heycam> … whether we should allow authors to specify a syncing attribute
16:16:48 <heycam> … and third whether we should have guidelines on constructing streamable content
16:16:59 <heycam> CL: I think we said we like the markup but use the API from HTML
16:17:08 <heycam> CC: I think the agreement was using it for audio and video in SVG
16:17:14 <heycam> CL: so extending it to other elements isn't a big step
16:17:18 <heycam> CC: for the outer svg
16:17:23 <heycam> CL: I think it makes sense to reuse it where it makes sense
16:17:27 <heycam> … so I would argue in favour of it
16:17:36 <birtles> https://etherpad.mozilla.org/lIwpKlVNd2
16:17:38 <heycam> BB: with Web Animations, we've looked at this
16:17:42 <heycam> … under point 4
16:17:46 <heycam> … we've come to the same conclusion
16:17:54 <heycam> … we'd like to use mediagroups on <object>s and <iframe>s too
16:18:03 <heycam> … when they reference SVG documents
16:18:08 <heycam> … with speed control too
16:18:11 <heycam> … so we're thinking the same thing
16:18:18 <heycam> … if so, then maybe Web Animations is the place to specify that
16:18:30 <heycam> Doug: I agree that's the right place to specify it, people will want to use HTML for the same thing, HTML overlays
16:18:34 <heycam> … it should apply to HTML as well as SVG
16:18:41 <heycam> Dirk: and discuss it in FX
16:18:51 <heycam> CC: so the Web Animation spec will define how mediagroup applies to SVG, iframes, objects?
16:18:53 <heycam> BB: yes
16:19:09 <heycam> CC: I'd be happy to be part of the discussion there
16:19:22 <heycam> Doug: it sounds to me like you're on the ball wrt the services using these things
16:19:42 <heycam> … I just wanted to confirm that you're thinking about the comcasts and the big streamers here
16:19:53 <heycam> … for non browser cases, like STBs
16:20:01 <heycam> … these are all considerations you're taking into account
16:20:02 <heycam> CC: yes
16:20:08 <heycam> … I'd like to extend what is in reach of SVG
16:20:23 <heycam> … so far we've only reached browsers in a well defined setup, where the browser requests HTTP content as a file from a server
16:20:33 <heycam> … but there are other setups where content might arrive in a streaming manner
16:20:36 <heycam> … and I'd like to enable that
16:20:56 <heycam> Doug: we've already agreed to use the existing captioning in HTML, TTML and WebVTT
16:21:02 <heycam> … and that SVG would use those things
16:21:10 <heycam> CL: I don't think we picked a specific one, just the same that HTML is using
16:21:23 <heycam> … my understanding is that HTML is using WebVTT, while Flash is using TTML
16:21:31 <heycam> Dirk: I think TTML is allowed by HTML now too
16:21:56 <heycam> Doug: I think the US FCC picked TTML because it matches existing industry standards on authoring
16:23:02 <heycam> BB: about the streaming, you said there are benefits to having everything in one file and having the server do fragmentation
16:23:06 <heycam> … can you elaborate on the benefits?
16:23:40 <heycam> 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
16:23:44 <heycam> … so the size of the DOM tree will increase
16:23:49 <heycam> … by adding things you don't need yet
16:23:58 <heycam> … so memory usage will be higher
16:24:08 <heycam> … if you use the <discard> element you can delete them when they're not needed, but it's too late
16:24:19 <heycam> CL: so <discard> is for things you no longer need, but this is the opposite case
16:24:45 <heycam> 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?
16:24:48 <ChrisL> things you will need in the future
16:25:15 <heycam> CC: that is what I'm suggesting, taking the initial very big file, fragment it into files or fragments, it's the same
16:25:37 <heycam> BB: if that's how SMIL full works, pointing off to external resources, fragmentation is already done at the file level
16:26:30 <heycam> CC: you don't want to split into too many files, each with a separate HTTP request
16:26:39 <heycam> … you might want to have a single file and just have it come with chunk transfer encoding
16:27:18 <heycam> CM: the server can just slow its delivery of the file
16:27:33 <heycam> … but that doesn't work for skipping forward
16:27:38 <heycam> CC: that's the random access point
16:27:57 <heycam> … 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?
16:28:42 <heycam> … in the current framework but the AV industry, they use a DASH system, and this setup assumes standard HTTP servers
16:28:54 <heycam> … and it's only the client doing the intelligence of downloading things when it needs them, or jumping ahead
16:28:56 <ChrisL> http://en.wikipedia.org/wiki/Dynamic_Adaptive_Streaming_over_HTTP
16:29:07 <heycam> … the client downloads a playlist and the playlist gives the association between times and files to request
16:29:37 <ChrisL> http://www.w3.org/2011/09/webtv/slides/W3C-Workshop.pdf
16:30:18 <heycam> CC: if you take all the requests that the client makes, and concat them together, that should be a valid SVG document
16:30:22 <heycam> CL: that's necessary but not sufficient
16:30:35 <heycam> CC: yes, you also need not referencing IDs not downloaded, etc.
16:31:23 <shepazu> q+ to ask about content protection
16:31:53 <ChrisL> q-
16:32:33 <ChrisL> http://www.w3.org/TR/xml-fragment
16:33:07 <heycam> CM: how does the client indicate which bit it wants?
16:34:36 <heycam> CC: the client gets the playlist, and it gets updated every so often, and that playlist indicates which things the client should fetch
16:34:44 <heycam> CL: and this uses the existing byte range mechanism?
16:34:46 <heycam> CC: yes
16:34:50 <heycam> CL: so nothing special on the server
16:35:09 <heycam> CC: can use SPDY if you want too
16:35:32 <heycam> … I think this will extend the scope of SVG
16:35:58 <heycam> … 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
16:36:13 <heycam> … 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
16:36:53 <heycam> 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
16:37:07 <heycam> CC: DASH supports full encyrption or partial encryption
16:37:19 <heycam> … used in common "premium" video applications
16:37:31 <heycam> Dirk: isn't it possible to use XHR to get parts of the file?
16:37:56 <heycam> 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
16:38:05 <Cyril> http://www-itec.uni-klu.ac.at/dash/?p=792
16:38:40 <heycam> … what does the group feel about me writing up a note?
16:38:46 <birtles> q+
16:38:50 <shepazu> q-
16:38:51 <heycam> CL: it partly falls in SVG and partly not, so a separate document would be good
16:38:58 <heycam> CC: I'd like to get in touch with the media pipeline tf
16:39:13 <heycam> Doug: we could have a joint meeting
16:39:21 <Cyril> http://www.w3.org/2011/webtv/wiki/MPTF
16:39:59 <heycam> CC: one way to develop a prototype for this is to use JS, and then you need an API to input media data
16:40:13 <heycam> … other way is to do a wrapper around the browser that intercepts HTTP requests and does the request for small files
16:40:47 <heycam> BB: about whether we need to change SVG or not, I think there are two ways to do it
16:40:55 <heycam> … one is to have the container document be SVG, have the frames embedded in there
16:41:09 <heycam> … you could also have some other sort of container document with embedded SVG fragments, and the container document defines the times
16:41:17 <heycam> … what are the advantages of making the container document an SVG document?
16:41:23 <heycam> … you could reuse some definitions I guess?
16:41:26 <heycam> CC: that's one advantage
16:41:39 <heycam> … in the cartoons use case, you might have a character or symbol reused in different frames
16:41:46 <heycam> … so you're sending it in the first frame it's used, then reusing it in the future
16:41:56 <heycam> BB: so you'd have a section at the start that has resources that are going to be reused?
16:42:02 <heycam> … which later requested frames use?
16:42:13 <heycam> CC: yes, almost, but you don't want to send all resources you're going to use all at the beginning
16:42:16 <heycam> … you want to send them as you go
16:42:24 <heycam> … so it's a bit like adding a <defs> in the middle of the document
16:42:37 <heycam> 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?
16:42:42 <heycam> CC: you embed that definition in the frame itself
16:42:52 <heycam> BB: if you do that, what's the advantage of the SVG container document?
16:43:00 <heycam> CC: no, all the frames are loaded in the same document context
16:43:16 <heycam> … the symbol you've defiend in the same frame without having to re-send it
16:43:48 <heycam> BB: how do I ensure definitions are available if I want to skip forward?
16:44:03 <heycam> CC: you have to indicate that the client has to fetch from the earlier frame that has the definition
16:44:17 <heycam> Doug: how would you know, as the client, what resources are where and how far back you have to fetch them?
16:44:27 <heycam> … would it makes sense to have <defs> always retrieved?
16:44:30 <heycam> CC: not sure in the general case
16:44:42 <heycam> … it's similar to video, in some video coding standards you need a previous frame to start showing the current frame
16:44:48 <heycam> … that previous frame you need is the random access point
16:45:05 <heycam> … random access points are places where you know you don't need anything frmo before
16:45:20 <heycam> Dirk: can't the playlist mention which resources are needed at a certain point in time?
16:45:37 <heycam> CC: there are mechanisms in different streaming technologies to say whether a frame can be played by itself, or needs something from before
16:46:30 <heycam> … there is roll distance, which allows the playlist to say how far back to fetch
16:47:41 <heycam> 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
16:47:50 <heycam> … if you don't, then we don't need to change SVG, we can just define a container format separately
16:47:58 <heycam> … what's the advantage to having it in one SVG document?
16:48:11 <heycam> CC: if everything you need to have is in the first frame, then you probably don't need a streaming solution for taht
16:48:18 <heycam> … the reuse of existing resources is small, you can send it in the first place
16:48:46 <heycam> 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
16:48:49 <Cyril> http://perso.telecom-paristech.fr/~concolat/SVG/flash10.svg
16:48:57 <Cyril> http://perso.telecom-paristech.fr/~concolat/SVG/
16:49:41 <heycam> BB: in these examples, there's nothing that is gained from having the document itself shared
16:51:31 <heycam> CC: the intelligence for fetching playlists and parts of the document can be done in a JS library, or at some lower level
16:52:10 <heycam> BB: so the big win is fallback for UAs that don't supports streaming? they can still play it?
16:52:11 <heycam> CC: yes
16:52:17 <heycam> … you can just load the whole file progressively
16:52:25 <heycam> CL: that's a useful feature
16:52:36 <heycam> … if it were some extension to SVG where it can't otherwise play it, you're stuck
16:55:15 <ChrisL> q+ to mention that the discard element is not currently in the SVG2 element index
16:55:23 <birtles> q-
16:56:32 <heycam> CC: that page also mentions <discard>, and it's not in the list of things we'll have in SVG2
16:56:47 <heycam> s/CC/CL/
16:56:48 <ChrisL> [136] have <discard> element to declaratively discard elements from the document tree 
16:57:24 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#the_.3Cdiscard.3E_element
16:59:24 <heycam> [some discussion on unease about <discard>]
17:01:34 <ChrisL> action: Cyril to add <discard> element in SVG2
17:01:34 <trackbot> Created ACTION-3319 - Add <discard> element in SVG2 [on Cyril Concolato - due 2012-07-30].
17:04:02 <heycam> RESOLUTION: SVG will via Web Animations support synchronisation with other HTML things like video
17:04:56 <heycam> RESOLUTION: SVG WG will work on a guidelines document for authoring streamable SVG
17:05:39 <ChrisL> rrsagent, here
17:05:39 <RRSAgent> See http://www.w3.org/2012/07/23-svg-irc#T17-05-39
17:07:48 <birtles> q+
17:08:39 <Cyril> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#the-track-element
17:09:42 <ChrisL> q-
17:10:31 <heycam> ACTION: Cyril to mail whatwg to ask about SVG graphics as a video track
17:10:31 <trackbot> Created ACTION-3320 - Mail whatwg to ask about SVG graphics as a video track [on Cyril Concolato - due 2012-07-30].
17:10:53 <heycam> BB: subtitles on cartoons, how we would do that?
17:11:01 <heycam> CC: my first thought would be to allow SVG as the <video> src
17:11:10 <heycam> … SVG inside an <img> has restrictions wrt scripting
17:11:20 <heycam> … so SVG inside <video> might have the same restrictions
17:11:46 <heycam> CL: you can't have <track> children for <iframe>s
17:11:50 <heycam> BB: maybe we should
17:12:07 <ChrisL> HTML WG would need to resolve that
17:12:07 <heycam> CC: we haven't come across this use case yet
17:12:29 <birtles> q-
17:12:36 <heycam> Dirk: so far <track> is just a child of media elements
17:12:42 <heycam> … we could define <svg> as media elements
17:12:50 <heycam> BB: so we want mediagroup on object, iframe, etc. and svg
17:13:07 <heycam> … so maybe at the same time it would make sense to allow <track> children
17:14:50 <heycam> 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
17:14:56 <heycam> … otherwise I'm totally fine with this
17:18:06 <heycam> ACTION: Cameron to look into sending out mails for svgwg.org commits
17:18:07 <trackbot> Created ACTION-3321 - Look into sending out mails for svgwg.org commits [on Cameron McCormack - due 2012-07-30].
17:26:26 <nikos> nikos has joined #svg
17:38:48 <nikos> c'est bon!
17:39:07 <TabAtkins_> Man, wallpaper groups are hard.
17:41:09 <nikos> scribenick: nikos
17:41:10 <Tav> Inkscape does all the wallpaper groups.
17:41:44 <nikos> Topic: Web Animations update
17:42:00 <Tav> I call in tomorrow.
17:42:11 <nikos> BB: I was asked to give an update on where web animations is going
17:42:20 <nikos> ... Dmitry has joined Adobe and he's working with us now
17:42:58 <nikos> ... in terms of deliverables, there are 3 or 4 pieces.
17:43:20 <nikos> ... web animations spec  + note of integration with css and possibly html
17:43:36 <nikos> ... we have deferred integration notes while we work on core spec - which is script API
17:43:49 <nikos> ... the goal is to have it done for SVG open so we can present then
17:44:05 <birtles> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html
17:44:06 <nikos> ... then we'll discuss FPWD at next F2F
17:44:20 <nikos> BB: still lots of issues present
17:44:31 <nikos> ... things like reversing
17:44:45 <nikos> ... an interesting development to note is that there are 2 distinct ways animations are used
17:45:02 <nikos> ... one is like ui effects - that's something that is short lived and you don't rewind or replay
17:45:17 <nikos> ... the other is content - things like cartoons which you do want to rewind often
17:45:21 <nikos> ... very different use cases
17:45:31 <nikos> ... css transitions fall under effects
17:45:41 <nikos> ... many existsing svg animations fall under the other
17:45:54 <nikos> ... we are thinking of approaching this by having 2 separate timelines
17:46:06 <nikos> ... one for effects which can't be seeked and elements get dropped as they are finished with
17:46:09 <nikos> ... the other allows seeking
17:46:39 <nikos> CM: is there a difference between 2 separate timelines and just having a flag which disallows seeking?
17:46:50 <nikos> ... what does having 2 timelines give?
17:47:02 <nikos> ... is it cleaner 
17:49:08 <nikos> BB: we think 2 timelines is the best solution, but would be open to other suggestions
17:49:23 <nikos> ... so that's the main change which would be of interest
17:49:32 <nikos> ... lots of other fundamental questions we are still working through
17:49:38 <nikos> ... particularly regarding templates
17:49:50 <nikos> ... how best to represents in the API
17:49:56 <nikos> s/represents/represent
17:50:23 <nikos> ... 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
17:50:31 <nikos> CC: how does it related to SMIL?
17:50:41 <nikos> BB: the goal is to eliminate the dependency on SMIL
17:51:04 <nikos> ... 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
17:51:13 <nikos> ... and some ideas in the API are drawn from SMIL - like the time containers
17:51:25 <nikos> ... we are learning from it but removing the dependency
17:51:52 <nikos> ... the SVG implementation note will have to duplicate the functionality in full
17:51:59 <nikos> ... some things from SVG 1.1 we are hoping to deprecate
17:52:07 <nikos> ... we are not sure how to approach sync based timing
17:52:27 <nikos> ... some people want it to stick around and others aren't convinced. We need it for backwards compatibility
17:52:38 <nikos> ... we may define it and then note that it will be removed in a later version
17:52:54 <nikos> CM: of the content that uses SMIL. It's very easy to use sync based stuff so I imagine it's used
17:53:03 <nikos> BB: yes. we need it 
17:53:12 <nikos> ... circular dependencies are a problem
17:53:32 <nikos> ... I have in mind an alternative that gives you the power of sync based timing without the circular dependencies
17:53:44 <nikos> CL: it would be useful to give the alternative since it's well used
17:53:57 <nikos> ... so having it spec'ed is a prerequisite to deprecating
17:54:22 <nikos> 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
17:54:31 <nikos> ... I am looking at an approach similar to media groups in HTML
17:54:42 <nikos> ... where you define an external name that you sync to
17:54:55 <nikos> CC: have you looked at how VRML does it?
17:55:07 <nikos> ... there's an element that gives timing and you sync to that element
17:55:24 <nikos> ... in terms of process, I'd like to participate
17:55:29 <birtles> http://www.w3.org/Graphics/fx/wiki/Web_Animations/Meetings
17:55:34 <nikos> BB: there is a meetings page
17:56:15 <nikos> CC: what is your timeline?
17:56:26 <nikos> ... this is an FXTF document?
17:56:38 <nikos> BB: At Hamburg FXTF accepted this as a work item
17:57:07 <nikos> ... timeline is to have core spec ready to present at next F2F and we can discuss FPWD then
17:57:12 <nikos> ... end goal is to have it ready for SVG2
17:57:22 <nikos> ... so we can refer to this spec for the animation features of SVG2
17:57:35 <nikos> RC: there really is no CSS in the spec
17:58:27 <nikos> RC: are you worried that it's getting too complex? some people have said they want it to be simple
17:58:33 <nikos> BB: we are currently looking at simplifying it
17:59:07 <nikos> ... Dmitry has written some examples with Raffael code and he's working out how hard it is to use
17:59:21 <nikos> ... we have to work on usability definitely
18:00:03 <nikos> shepazu: is there any way this could work in W3C space?
18:01:04 <nikos> ... it would be good if it could be in a place where all are included
18:02:05 <nikos> BB: we'll talk about how that can happen
18:02:38 <nikos> CC: so far it says it's about specifying the animation for an author to include animation in the web page
18:02:46 <nikos> ... do you have anything about controlling - seeking, speed, etc?
18:02:54 <nikos> BB: the link I dropped before is the core API
18:03:02 <nikos> ... within that you have methods for controlling those things
18:03:14 <heycam> https://dvcs.w3.org/hg/FXTF/raw-file/tip/web-anim/index.html#the-timeditem-interface
18:03:25 <nikos> ... on top of that we are layering the specifications that will have the declarative methods of controlling that (maybe not seek)
18:03:52 <nikos> ... we are considering producing a primer
18:05:30 <nikos> CM: I'd like to know what Opera people and Microsoft people think about it - if they have an opinion?
18:06:09 <nikos> 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
18:06:24 <nikos> ... there definitely should be a Javascript API which SMIL lacks
18:06:30 <nikos> jen: I feel the same way
18:06:46 <nikos> CM: the thing that made me like it when I was unsure at the start was the introduction of the Javascript API
18:06:52 <ed> s/SMIL lacks/SMIL lacks (well, mostly)/
18:07:36 <nikos> BB: from an authoring point of view you can produce animations from script and the will potentially be hardware accelerated
18:07:52 <nikos> shepazu: I've been talking to a lot of people who wonder how to do animation in svg. it's a common question
18:08:10 <nikos> ... the thing I tell people is, if you want to use declarative animation is to use fake SMIL
18:08:34 <nikos> ... one of the downsides is that it doesn't allow you to add declarative animations
18:08:51 <nikos> ... it would be good if we could publish a library that people can play with while we publish the spec
18:09:02 <nikos> ... we could provide different options for the syntax and let people see what they like
18:09:17 <nikos> BB: that's what I hope will come of Shane's prototype
18:10:25 <Cyril> can you call back ?
18:10:38 <TabAtkins_> We're coming.
18:11:03 <nikos> CM: I like how the declarative aspects get exposed at the script level and it's not magical
18:11:31 <nikos> CC: in general, I think there's a difference between CSS animations and SVG animations wrt modifications of the animation while it's running
18:12:04 <nikos> BB: that's something that wasn't resolved in CSS. 
18:12:34 <nikos> ... 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.
18:12:34 <krit> q+
18:12:47 <nikos> ... as far as I'm aware it hasn't been specified which will become live
18:13:04 <nikos> krit: for SMIL animations they start when the doc is loaded. For CSS it's not specified when they start
18:13:15 <nikos> BB: for CSS it's the later of two moments. on document load or when the style is resolved
18:13:18 <nikos> ... it's a bit of a mess
18:13:31 <nikos> ... what we have proposed is the start of the timeline can be set to one of 3 possibilities
18:13:34 <nikos> ... 1. document load
18:13:42 <nikos> ... 2. document start - when parsing finishes
18:13:54 <nikos> ... 3. manual - doesn't start until script calls unPause
18:15:25 <nikos> CC: You plan to have something at SVG open and we will be having a F2F there
18:15:42 <nikos> CM: we will definitely have the F2F at SVG open
18:16:20 <nikos> Topic: Updated referencing proposal (ID-less masks etc.)
18:16:26 <birtles> http://people.mozilla.org/~bbirtles/pres/referencing-proposal/
18:16:48 <nikos> [Brian goes over presentation]
18:17:23 <thorton> thorton has joined #svg
18:17:47 <nikos> Slide 1: masks are currently referenced with id.
18:20:47 <ChrisL> q+ to ask about child(n)
18:23:29 <nikos> 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
18:23:40 <nikos> TA: ultimately we make it a url or a selector article
18:23:55 <nikos> CL: the selector needs to be scoped. The child parameter is creating a scope
18:24:10 <nikos> shepazu: We wouldn't have to use a name if we're using selectors, we could just add a class
18:24:20 <nikos> CM: or you could add your own custom attributes and do it however you like
18:24:34 <nikos> ... I don't think there are CSS properties that have selectors as their values
18:24:47 <nikos> TA: there will be. They will probably be wrapped in a function
18:25:02 <nikos> ... if we do it that way, I'd still want the child keyword as a shortcut
18:30:29 <shepazu> q+ to talk about child fallback extension mechanism, and referencing non-specialized resources (e.g. no need for <clipPath>)
18:30:53 <nikos> CL: with the child thing. if the child happens to have visbility hidden is it still honoured?
18:31:32 <krit> q-
18:31:48 <nikos> shepazu: child content of a rendering element doesn't render currently
18:32:55 <nikos> ... in my proposal I had, for forwards compatibility or extensibility, we could have child elements of unknown children render
18:33:17 <nikos> ... you could use this for fallback for UAs that don't recognise the element
18:33:28 <nikos> ... in that case, unknown elements act as a group
18:36:32 <nikos> BB: it sounds like the idea of using a scheme other than IDs is useful
18:36:48 <nikos> ... I want to eliminate dependence on IDs for things like masks, filters, gradients
18:36:53 <nikos> ... it's a real pain when generating content
18:37:25 <nikos> shepazu: There's plenty of times I want to drop some content into another SVG file
18:38:28 <nikos> BB: it sounds like everyone is keen on the general idea but perhaps the solutions we have listed aren't great
18:38:33 <nikos> ... perhaps selectors is the way to go
18:38:54 <nikos> ... would it go inside the bracket of child or what?
18:39:15 <nikos> TA: I'd say child as keyword and then a function 
18:40:46 <nikos> ... 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
18:40:58 <TabAtkins_> http://dev.w3.org/csswg/css4-images/#element-notation
18:41:20 <nikos> TA: it is defined as an image subtype but there's no problem defining it as another subtype as well
18:41:34 <nikos> BB: currently for alpha masks we have a type attribute saying whether its an alpha mask or not
18:41:45 <nikos> ... if you want to support other sources for a mask 
18:42:14 <nikos> ... you may need to specify how to link them
18:43:29 <nikos> ... 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
18:44:00 <nikos> CL: it needs to be extensible if, in future, we want other types of alpha mask
18:44:32 <nikos> TA: A better way to do it would be to have an optional keyword to the grammar
18:44:42 <ChrisL> so mask: url(#foo), alpha
18:44:50 <nikos> shepazu: There's a lot of things that you currently need to have a specialised clip path.
18:45:00 <nikos> ... your clip path property can only reference a clip path element
18:45:55 <nikos> ... most of the time when you are using a wrapper you are doing it for the viewbox
18:46:20 <nikos> ... if it could be a nested svg that you are referencing to get the viewbox, that solves most of issues
18:47:04 <nikos> ... 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
18:47:18 <nikos> s/lumaninance/luminance
18:48:07 <nikos> BB: so we are coming towards a concrete proposal for the syntax, I wanted to discuss the scope
18:48:14 <nikos> ... we have a list of elements that depend on IDS
18:48:22 <nikos> ... clip paths - useful
18:48:24 <nikos> ... cursoros - not
18:48:30 <nikos> s/cursoros/cursors
18:48:42 <nikos> CM: I think cursors should be allowed if we made cursor more useful
18:49:15 <nikos> BB: maybe we won't rule out cursor just yet
18:49:20 <nikos> ... marker - makes sense
18:49:34 <nikos> CM: are there properties that take paints other than fill or stroke?
18:49:43 <nikos> TA: not in SVG I don't think
18:50:25 <nikos> BB: feImage - is that worth allowing child elements for content?
18:50:40 <nikos> ... what co-ordinate space does it end up in?
18:50:45 <nikos> CM: I think we can look at feImage
18:50:54 <nikos> BB: text-path - I think we agreed we want to do something with it
18:50:59 <nikos> ... which option is better
18:51:03 <nikos> CM: I'm tempted to say both
18:51:22 <nikos> ... because of possible extensions of path where for shared segments you will need to use some element syntax
18:52:12 <nikos> BB: so sounds like for scope - it's pretty much all of it
18:52:32 <nikos> krit: should we allow more selectors than nth child?
18:52:41 <nikos> CM: are they scoped?
18:52:50 <nikos> TA: it should accept a compound selector and then run across the children
18:52:59 <nikos> ... only looks at direct children
18:53:17 <nikos> CM: I don't think there's a need to look deeper than children
18:54:09 <nikos> CM: is the idea that a compound selector could selector a non child ?
18:54:15 <birtles> syntax proposal: mask: <funciri> | child | element(compound-selector) [alpha]
18:54:24 <nikos> TA: yes
18:55:00 <birtles> corrected syntax proposal:mask: [<funciri> | child | element(compound-selector)] alpha?
18:55:28 <birtles> and again:
18:55:30 <birtles> mask: [<funciri> | child | element(compound-selector)] [alpha|luminance]?
18:55:36 <ChrisL> +1
18:56:15 <nikos> CM: what do we need to do to get this compound selector working?
18:56:36 <nikos> TA: needs to be added to CSS images 4
18:57:33 <nikos> CL: for the fill and stroke, that has an interaction with the extensions to fill and stroke in vector-effects
18:57:39 <nikos> ... I want to make sure that still works
18:57:57 <nikos> CM: I think it just adds to that
18:59:16 <nikos> Resolution: Will use the 'mask: [<funciri> | child | element(compound-selector)] [alpha|luminance]?' syntax for ID-less referencing
18:59:45 <nikos> Action: Brian Incorporate ID-less referencing into the SVG 2 specification
18:59:45 <trackbot> Created ACTION-3322 - Incorporate ID-less referencing into the SVG 2 specification [on Brian Birtles - due 2012-07-30].
20:06:11 <jen> jen has joined #svg
20:10:45 <heycam> TabAtkins_, http://www.w3.org/Graphics/SVG/WG/wiki/Svgwg.org
20:46:01 <Tav> Tav has joined #svg
20:46:33 <heycam> RRSAgent, make minutes
20:46:33 <RRSAgent> I have made the request to generate http://www.w3.org/2012/07/23-svg-minutes.html heycam
20:47:43 <heycam> Present: Cameron, Doug, Dirk, Jen, Brian, Nikos, Tab, Chris, Erik, Cyril
20:47:50 <heycam> RRSAgent, make minutes
20:47:50 <RRSAgent> I have made the request to generate http://www.w3.org/2012/07/23-svg-minutes.html heycam
21:04:41 <jet> jet has joined #svg
22:50:37 <cabanier> cabanier has joined #svg