IRC log of svg on 2012-03-29

Timestamps are in UTC.

19:58:38 [RRSAgent]
RRSAgent has joined #svg
19:58:38 [RRSAgent]
logging to http://www.w3.org/2012/03/29-svg-irc
19:58:40 [trackbot]
RRSAgent, make logs public
19:58:40 [Zakim]
Zakim has joined #svg
19:58:42 [trackbot]
Zakim, this will be GA_SVGWG
19:58:42 [Zakim]
ok, trackbot; I see GA_SVGWG(SVG1)4:00PM scheduled to start in 2 minutes
19:58:43 [trackbot]
Meeting: SVG Working Group Teleconference
19:58:43 [trackbot]
Date: 29 March 2012
19:59:41 [cyril]
cyril has joined #svg
20:00:16 [Zakim]
GA_SVGWG(SVG1)4:00PM has now started
20:00:22 [Zakim]
+??P5
20:00:32 [ed]
Zakim, ??P5 is me
20:00:32 [Zakim]
+ed; got it
20:00:58 [Zakim]
+cyril
20:02:38 [Zakim]
+Doug_Schepers
20:02:56 [ed]
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0185.html
20:03:12 [Zakim]
+Tav
20:03:14 [ed]
and agenda+ http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0187.html
20:03:21 [Zakim]
+[IPcaller]
20:03:23 [heycam]
Zakim, [ is me
20:03:23 [Zakim]
+heycam; got it
20:04:27 [Zakim]
+krit
20:04:30 [ed]
Zakim, pick a scribe
20:04:30 [Zakim]
Not knowing who is chairing or who scribed recently, I propose ed
20:04:38 [ed]
Zakim, pick a scribe
20:04:38 [Zakim]
Not knowing who is chairing or who scribed recently, I propose krit
20:04:49 [cyril]
+Present: Nikos
20:04:55 [ed]
Zakim, pick a scribe
20:04:55 [Zakim]
Not knowing who is chairing or who scribed recently, I propose ed
20:04:58 [ed]
Zakim, pick a scribe
20:04:58 [Zakim]
Not knowing who is chairing or who scribed recently, I propose Doug_Schepers
20:05:25 [krit]
scribeNick: krit
20:05:29 [ed]
chair: ed
20:05:51 [krit]
topic: Finishing SVG 2 reuirements
20:05:55 [ed]
http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0175.html
20:06:08 [krit]
cyril: I have an issue
20:08:08 [krit]
heycam: I have an action for the first item
20:08:13 [krit]
heycam: not done yet
20:08:46 [krit]
heycam: action number: 3251
20:08:50 [ed]
ACTION-3251
20:09:21 [krit]
ed: what about smil time containers?
20:09:34 [krit]
heycam: yes, let's take a look at that
20:09:48 [krit]
heycam: I am happy about brians efforts
20:10:20 [krit]
ed: any concerns?
20:10:48 [krit]
shepazu: I suspect MS might have concerns but they are not here
20:12:11 [krit]
heycam: I thing it is the full smil time container
20:12:22 [krit]
cyril: he doesn't want elements but attributes
20:12:53 [nikos]
nikos has joined #svg
20:13:04 [cyril]
zakim, who is here
20:13:04 [Zakim]
cyril, you need to end that query with '?'
20:13:08 [cyril]
zakim, who is here?
20:13:08 [Zakim]
On the phone I see ed, cyril, Doug_Schepers, Tav, heycam, krit
20:13:24 [cyril]
+nikos
20:14:08 [heycam]
http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Issue:_SMIL_is_greatly_complicated_by_syncbase_timing
20:14:12 [krit]
resolution: SVG 2.0 requirement: support SMIL time containers
20:15:04 [krit]
cyril: we want the feature of smil time containers, but not necessarily the element iteself
20:15:22 [cyril]
RRSAgent, pointer
20:15:22 [RRSAgent]
See http://www.w3.org/2012/03/29-svg-irc#T20-15-22
20:15:45 [krit]
heycam: "Consider adding a 'key()' keyword for animation triggers"
20:16:10 [krit]
heycam: You can just get a single character no a key. Not good defined
20:16:25 [krit]
cyril: don't think that this is an issue
20:16:47 [krit]
cyril: I discussed security issues with brian on accessKeys
20:19:45 [krit]
cyril: SVG integration of accessKeys might be modified to address security issues
20:22:11 [krit]
ed: we should come up with a proposal that adresses security issues
20:23:13 [krit]
resolution: SVG 2 requirement:Consider adding a 'key()' keyword for animation triggers and addressing security issues
20:23:57 [krit]
krit: timelineBegin attribute on <svg> element next?
20:24:11 [krit]
krit: even for inner SVG elements?
20:24:49 [krit]
cyril: we should not speack about documents but time container
20:25:25 [krit]
cyril: we can start new time containers anywhere. We should talk about that after we have time container
20:26:07 [krit]
cyril: Oh, I think timlineBegin should only be on the document
20:26:54 [cyril]
see syncBehavior to control the timeline of a time container
20:26:59 [krit]
heycam: you might not want to wait for document load end to start animations
20:27:39 [krit]
krit: I think it should be part of the time container
20:28:01 [krit]
heycam: it might make sense to start animations on a time container before the content is fully loaded
20:28:12 [cyril]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Run-time_Synchronization_attributes
20:28:13 [krit]
cyril: I think we already have a resolution.
20:28:30 [krit]
heycam: it was more about synchronizing media
20:28:49 [krit]
cyril: i don't think so
20:29:14 [krit]
cyril: e.g if you have video and audio that could differ from the timeline of the document
20:29:33 [krit]
cyril: I agree with the request, we should define whne the timeLine begins
20:29:47 [krit]
heycam: Well, I am fine with it
20:30:46 [krit]
resolution: SVG 2 should specify when timeline starts. (maybe by a timeLine attribute)
20:31:40 [krit]
s/resolution: SVG 2 should specify when timeline starts. (maybe by a timeLine attribute)/resolution: SVG2 will support a means for having SMIL animations start before their time container has fully loaded/
20:32:28 [krit]
heycam: The <discard> element
20:32:55 [krit]
ed: to throw away elements based on animations. Good for big files on streaming
20:33:05 [krit]
cyril: use case is still valid
20:33:40 [krit]
cyril: there might be issues on scripting the <discard> elements
20:33:47 [krit]
cyril: we should fix that
20:35:44 [krit]
cyril: have you implemented it?
20:35:49 [krit]
ed: yes, think so
20:37:07 [ed]
s/yes, think so/yes, opera implements the <discard> element/
20:37:32 [krit]
heycam: brian seems not to be opposed to ti
20:37:39 [krit]
s/ti/it/
20:38:01 [krit]
ed: can we resolve requirements?
20:38:33 [krit]
resolution: SVG 2 will have <discard> elements to discard elements from the document tree
20:39:02 [krit]
cyril: The 'playbackOrder' attribute on the<svg> element next
20:39:25 [ed]
s/<discard> elements to discard/<discard> element to declaratively discard/
20:41:02 [cyril]
If 'playbackOrder' is set to 'forwardOnly', the content will probably contain 'discard' elements or scripts that destroy resources, thus seeking back in the document's timeline may result in missing content.
20:41:27 [krit]
heycam: more important for the UI controls
20:41:30 [cyril]
Similarly the UA should disable any controls it may provide in the user interface for seeking backwards.
20:41:46 [cyril]
http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementPlaybackOrderAttribute
20:42:21 [krit]
ed: not sure ahow important the attribute is
20:43:02 [krit]
ed: a lot of shoulds and mays
20:43:42 [krit]
cyril: should you revert the elements?
20:44:05 [krit]
cyril: we could use plabackOrder also with scripts
20:44:26 [krit]
heycam: it might be useful if UIs have some build in controls
20:44:41 [krit]
heycam: does flash have it?
20:45:08 [krit]
heycam: you didn't implement this attribute yet?
20:45:10 [krit]
cyril: no
20:45:19 [krit]
ed: no, oper either
20:45:28 [krit]
s/oper/Opera/
20:46:05 [krit]
ed: might only be useful for UIs
20:46:16 [krit]
ed: not sure if the wording is so great either
20:47:32 [cyril]
resolution: SVG 2 should support the playbackOrder attribute to inform UA to not display controls to seek backwards
20:48:22 [krit]
ed: we have all the things
20:48:47 [krit]
topic: SVG next phase
20:48:49 [ed]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments
20:50:31 [krit]
krit: At adobe we will most likely specialise on glyphs and fonts, discussion is still going on
20:50:42 [krit]
ed: I don't want to sign up for to many at this point
20:51:06 [krit]
ed: I might sing up for a couple more
20:51:33 [krit]
cyril: I haven't discussed it yet with colleagues
20:51:39 [Zakim]
-Tav
20:51:46 [krit]
heycam: I have a bunch of them
20:51:59 [krit]
heycam: most of them will be align with html5
20:52:16 [Zakim]
+Tav
20:54:34 [cyril]
http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page#Milestones
20:55:34 [krit]
cyril: We should do as much as possible till april to publish first WD till July
20:55:53 [krit]
cyril: And then make a second round for missing requirments
20:56:05 [krit]
heycam: july is the first step
20:56:56 [krit]
heycam: and then straight to last call in january
20:59:00 [krit]
shepazu: We should have as much as possible but should go out with what we have
20:59:54 [krit]
shepazu: the first WD should have the new things in it
21:00:05 [krit]
shepazu: we focus on the new stuff
21:00:23 [krit]
shepazu: people are more interessted in the new stuff than what SVG 1.1 has
21:04:49 [Zakim]
-heycam
21:04:58 [cyril]
I think we need to do 3 things: freeze the commitments, start editing the spec to add the annotations for this first set of reqs and then start receiving proposals
21:05:12 [cyril]
and evaluating them
21:07:00 [krit]
resolution: Commitments on SVG parts we want to work on will be frozen by next week
21:08:13 [Zakim]
+??P0
21:08:19 [heycam]
Zakim, ??P0 is me
21:08:19 [Zakim]
+heycam; got it
21:08:37 [krit]
topic: extract part of an SVG image by its id
21:08:46 [heycam]
Zakim, code?
21:08:46 [Zakim]
the conference code is 7841 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam
21:09:05 [krit]
shepazu: I send an email with the conversation that I have with fantasai
21:09:17 [krit]
shepazu: you all have read
21:09:46 [krit]
shepazu: media fragment spec let you point to different parts of document you want
21:10:54 [ed]
http://lists.w3.org/Archives/Public/public-svg-wg/2012JanMar/0189.html has some examples I cooked up, using ids for selecting parts of an svg "spritemap"
21:11:22 [krit]
shepazu: think about a use element can point to an element in SVG and just wants to show this one
21:11:52 [krit]
shepazu: an CSS image would access that
21:12:14 [krit]
shepazu: we had one use case in SVG for navigation
21:12:39 [krit]
shepazu: fantasai proposes what a fragment is in SVG 2 and what to do when the UA points to that
21:12:42 [TabAtkins]
Fantasai's point that SVG just needs to define what a hash *represents* is sufficient. We can take over from there. But defining it as representing "navigate/scale/whatever the viewport" isn't useful.
21:12:48 [krit]
shepazu: what is the navigation behavior
21:13:13 [TabAtkins]
And then you can say that the default behavior is to navigate to the referenced element.
21:14:44 [ed]
http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#chart
21:14:50 [ed]
http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#plus
21:15:17 [krit]
ed: it should work in FF as well
21:15:44 [ed]
it works in all browsers
21:16:25 [krit]
heycam: one use viewBox on the target and two hide the other ones
21:18:01 [shepazu]
http://dev.w3.org/csswg/css3-images/sprites.svg
21:19:48 [krit]
heycam: most document just gone have a part of an image with an ID. There won't be an viewBox arround it
21:19:59 [ed]
ed has left #svg
21:20:05 [ed]
ed has joined #svg
21:20:06 [krit]
ed: what eric did works fin here.
21:21:10 [heycam]
would like to know how this relates to <view> -- <view> is kind of indirect, so this would provide the same/similar functionality but be simpler?
21:21:34 [cyril]
and #svgView()
21:21:35 [TabAtkins]
woo
21:21:49 [krit]
shepazu: if we get auhtoring tools to support this than we are fine
21:21:57 [ed]
http://dahlström.net/tmp/sharp-icons/svg-icon.svg#chart
21:22:38 [ed]
this alternative uses <view> elements to define the viewboxes
21:22:58 [krit]
heycam: you have to define a viewBox
21:23:28 [ed]
... and lacks the display:none things, which could be added of course, similarly to http://dahlström.net/tmp/sharp-icons/svg-icon-target.svg#chart
21:23:41 [krit]
shepazu: currentyl the SVG 1.1 says that its simple goes to view port of the SVG anchetor of this elements
21:23:48 [krit]
shepazu: you just have the svg root
21:25:13 [krit]
krit: I saw eriks solution some times, mostly for zooming
21:25:29 [krit]
shepazu: eirks solution is a good interim solution
21:26:56 [krit]
cyril: just want to confirm the next F2F meetings
21:27:26 [ed]
Seattle, USA, 25-27 July, 2012
21:28:11 [krit]
cyril: what is the next one?
21:28:18 [krit]
cyril: TPAC, SVG open?
21:28:37 [ed]
topic: next svg f2f meetings
21:28:44 [krit]
shepazu: this is the last SVG Open
21:29:08 [krit]
shepazu: would be good to have on f2f at SVG open
21:30:15 [krit]
cyril: can you attend to TPAC and SVG open?
21:30:29 [krit]
Tav: figure it out
21:31:08 [krit]
topic: SVG functionality in Canvas
21:31:36 [krit]
krit: I was surprised about the SVG path stuff in Canvas
21:32:13 [krit]
heycam: I think he wants to make sure that path or matrix work well or at least similar as the SVG one
21:33:04 [krit]
shepazu: hixie asked SVG WG to review it before he lands stuff
21:34:36 [krit]
shepazu: but now he published it
21:34:51 [krit]
shepazu: I think we should review what is there and send coments
21:35:11 [heycam]
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-March/035239.html
21:35:29 [krit]
shepazu: I suggest to mail the comments to the canvas mailing list, svg mailing list and hixie
21:35:49 [TabAtkins]
Yes, please. "Publishing" does not in any way imply it's frozen (until implementations emerge).
21:36:05 [krit]
The SVG stuff in Canvas so far: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path-objects
21:36:44 [krit]
shepazu: SVG WG should be involved in how SVG error handling works
21:38:36 [krit]
heycam: I will review it
21:39:38 [krit]
shepazu: thats enought for now
21:39:55 [krit]
shepazu: can we start with these topics on next meeting minutes?
21:41:21 [cyril]
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions
21:41:36 [krit]
shepazu: next f2f over emails and telcom times on next meeting
21:41:55 [Zakim]
-ed
21:44:08 [Zakim]
-heycam
21:44:11 [Zakim]
-Doug_Schepers
21:44:14 [Zakim]
-Tav
21:44:19 [Zakim]
-cyril
21:44:34 [krit]
RRSAgent, make minutes
21:44:34 [RRSAgent]
I have made the request to generate http://www.w3.org/2012/03/29-svg-minutes.html krit
21:44:38 [cyril]
zakim, who is here?
21:44:38 [Zakim]
On the phone I see krit
21:48:43 [Zakim]
-krit
21:48:44 [Zakim]
GA_SVGWG(SVG1)4:00PM has ended
21:48:44 [Zakim]
Attendees were ed, cyril, Doug_Schepers, Tav, [IPcaller], heycam, krit
21:52:40 [heycam]
shepazu, krit, looking at the spec for the Path(d) constructor, it says "The resulting path could be empty. SVG defines error handling rules for parsing and applying path data."
21:52:55 [heycam]
so I'm not sure what there is to complain about
21:53:07 [heycam]
we do have rules in SVG about rendering up to the point of an error in the path data
21:53:08 [krit]
heycam: just commented some lines before on the chat
21:53:19 [krit]
krit hixie changes the note about error handling on SVG Path to : The resulting path could be empty. SVG defines error handling rules for parsing and applying path data.
21:53:32 [krit]
and this seems fine for me
21:53:35 [heycam]
ok
21:53:37 [krit]
so it was fixed
21:58:15 [shepazu]
yeah, though we don't call it error-handling (and should)
22:05:02 [fantasai]
shepazu, krit: there seems to be some confusion on the CSSWG list about SVG Transforms vs. CSS Transforms. Maybe one of you can clear that up?
22:05:05 [fantasai]
https://lists.w3.org/Archives/Member/w3c-css-wg/2012JanMar/0492.html
22:16:15 [krit]
fantasai: argh. Why are these kind of discussions not on publix-fx?
22:16:56 [krit]
even worst, I did not get these mails :(
22:31:04 [cyril]
just to confirm, we have addressed all the initial proposed requirements (179/179)
22:31:17 [cyril]
there remains only 4 late ones: http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Late_Proposed_Requirements
22:32:12 [TabAtkins]
TabAtkins has left #svg