20:29:00 RRSAgent has joined #svg 20:29:00 logging to http://www.w3.org/2014/03/06-svg-irc 20:29:02 RRSAgent, make logs public 20:29:02 Zakim has joined #svg 20:29:04 Zakim, this will be GA_SVGWG 20:29:04 ok, trackbot, I see GA_SVGWG(SVG1)3:30PM already started 20:29:05 Meeting: SVG Working Group Teleconference 20:29:05 Date: 06 March 2014 20:29:14 Chair: Cameron 20:29:20 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014JanMar/0118.html 20:29:54 +??P1 20:30:02 +[IPcaller] 20:30:03 Zakim, [ is me 20:30:03 +heycam; got it 20:30:07 Zakim, ??P1 is me 20:30:07 +nikos_; got it 20:30:25 +krit 20:30:39 +[IPcaller] 20:30:48 +[IPcaller.a] 20:30:49 Zakim, [ is me 20:30:50 sorry, birtles, I do not recognize a party named '[' 20:30:54 Zakim, [IP is me 20:30:54 sorry, ed, I do not recognize a party named '[IP' 20:30:55 Zakim, [IPcaller] is me 20:30:55 +birtles; got it 20:31:12 Zakim, [IPcaller.a] is me 20:31:12 +ed; got it 20:34:44 +Tav 20:34:46 +??P7 20:35:09 zakim, ??P7 is me 20:35:09 +stakagi; got it 20:35:35 scribe: nikos 20:35:40 scribenick: nikos_ 20:36:02 Topic: Shipping paint-order 20:36:28 heycam: last week Dirk brought up the issue of whether we should discuss things in the WG to ship new SVG 2 features in browsers 20:36:39 ... I'm interested in paint-order 20:36:54 ... do people think the definition of that property is stable enough for FF to ship in release build? 20:37:08 ed: I recently enabled it in stable releases for Blink 20:37:23 krit: you said it's up to each implementation 20:37:39 heycam: I thought it would be nice to bring up in the WG before we decide those things 20:37:47 krit: thought we'd decided for paint-order 20:38:00 heycam: I think paint-order is ready anyway 20:38:08 Tav: can we get notified of status? How can I try it out 20:38:16 heycam: available in Chrome Canary and FF nightly 20:38:24 heycam: Webkit, dirk? 20:38:31 krit: patch in but not reviewed yet 20:38:41 Tav: I'd like to see announcements to the WG 20:38:52 ... give a week or so to try it before we agree to release 20:39:08 krit: I wrote 11 reftests and some JS tests. I can upload the reftests 20:39:45 nikos: It would be good for non browser people to know in general when features are being added 20:39:54 Tav: I was thinking of what to add to InkScape 20:40:32 heycam: I don't need to ship it urgently in FF so if you want another week to play around that's fine 20:40:58 ed: Blink change hasn't trickled down to stable release yet, but it will at some point 20:41:07 ... it's been in Canary for a couple of months behind a flag 20:41:55 heycam: sounds like there is time to test paint-order before it hits stable builds 20:42:05 Tav: I'm not too worried about paint-order but other features 20:42:24 heycam: I think we can keep trying to do this where we bring it up in the group 20:42:36 Topic: Reference box keywords for 'clip-path' and 'mask' 20:42:50 krit: simple one first... 20:42:56 http://dev.w3.org/fxtf/masking/#the-clip-path 20:43:10 ... if you open link, you'll see we have two types of value for clip-path 20:43:23 ... clip-source and geometry-box 20:43:38 ... the question is, do we want to have these reference boxes for clip source as well? 20:43:53 ... for instance, you have clip-path and clip path units object bounding box 20:44:06 ... we may want to have a keyword for fill stroke view box that allows you to reference a different box 20:44:21 ... fill would be redundant, but stroke or something would be interesting 20:44:55 heycam: may have discussed this before in the context of another element 20:45:07 ... I feel the choice of which box is intrinsic to the definition of the resource element 20:45:18 ... so having something in the property value where you are referencing it maybe isn't useful 20:45:47 krit: do we want new keywords for HTML elements and new keywords for SVG elements? 20:46:01 ... I wouldn't add it to this level, but I think it needs discussing 20:46:13 heycam: the spec allows new keyword values to be specified in the property 20:46:18 krit: just allows for basic shapes 20:46:31 heycam: basic shapes don't support paths? 20:46:39 ... paths were deferred? 20:46:43 krit: yes 20:46:57 ... it got deferred 20:47:41 heycam: if we don't allow new values in clip-path-units it will be relevant to border box 20:47:59 ... I don't know if we need to do this now 20:48:38 krit: I think this should be deferred until the next level anyway, but should be discussed now 20:49:02 krit: the behaviour should be consistent for all elements - gradient, clips, filters, etc 20:49:13 heycam: agree 20:49:38 ... my feeling would be yes to adding new values to the attributes in general 20:49:47 ... but might need to think about it more 20:49:52 krit: maybe we can discuss at the F2F 20:50:06 krit: anyone object to not having this in the first level of the spec? 20:50:26 krit: not being able to choose which reference box you use. SVG is always object bounding box or user space 20:50:35 krit: we agreed that we want it eventually 20:50:38 ... but level 1 or later? 20:50:47 ... later allows us to come up with a solution for all SVG elements 20:50:55 Tav: doesn't matter to me 20:51:25 Tav: current bounding box doesn't include stroke? 20:51:28 heycam: no 20:52:08 ... I don't think it's urgent enough to do in level 1 right now 20:52:17 ... think we should decide more generally how to treat this 20:52:25 krit: anyone object? 20:52:38 ed: what is the default behaviour for HTML? 20:52:44 ... what would be the equivalent? 20:52:53 krit: would be border-box for HTML elements 20:53:04 ed: that kind of is the same as the stroke bounding box 20:53:14 krit: not really, but if you want to compare SVG to HTML then yes 20:53:47 ed: trying to think of cases where you'd want to use the same thing. Taking a basic-shape and apply same box to HTML and SVG and have it behave the same 20:54:23 heycam: the keywords on the property at the moment, we decided that if you use an SVG specific keyword (e.g. fill) then that means the default box for HTML content? 20:54:27 krit: that's correct 20:54:36 heycam: would we be adding additional keywords for the HTML specific ones? 20:54:53 ... in the geometry-box bit of the clipPath? 20:54:58 krit: we would use the same reference box 20:55:13 heycam: is that in the definition of shape-box? 20:55:29 krit: for polygon, inset, circle, ellipse 20:55:45 heycam: what about border-box, patter-box, margin-box? are they already supported in the property? 20:55:48 krit: yes 20:56:39 richardschwerdtfeger has joined #svg 20:56:53 heycam: as Erik was pointing out. If you want to define a basic shape and have it apply to SVG and HTML 20:57:06 krit: it means the SVG or the HTML would fall back to the default 20:57:09 ... you can only specify one 20:57:35 heycam: is that a problem? 20:57:40 krit: I haven't thought about that yet 20:57:46 ... it's an interesting point 20:57:50 ... don't know if it would be a problem 20:58:06 +Rich_Schwerdtfeger 20:58:10 heycam: in practice, maybe using stroke-box in SVG and border-box in HTML is what you want 90% of the time 20:58:35 krit: if you don't want default values for both, then you need to have two classes 20:58:41 heycam: seems like something we could add later without problems 20:58:45 ... if you think we should go that way 20:59:05 heycam: coming back to your initial question of whether we should decide now 20:59:15 krit: we don't need to decide now, but if we don't I'd like to defer to next level 20:59:30 heycam: didn't hear anyone say that we need to solve it now 20:59:59 RESOLUTION: we will handle new box keywords in units attributes in level 2 of Masking 21:00:22 Topic: Renaming 'fill' and 'stroke' keywords to 'fill-box' and 'stroke-box' 21:00:35 krit: we discussed during the F2F 21:00:40 ... decided we don't want -box at the end 21:00:48 ... because what is a box, block, element, etc 21:00:55 ... Erik brought up that it might make sense for usability 21:01:06 ... we have box at the end of many things already 21:01:40 ... CSS WG decided they want box at the end 21:01:50 ... and it's up to the SVG WG to agree or reject the decision 21:02:14 heycam: I think one of the reasons I like fill and stroke as they are is that it matches the names of the properties you pass to extended getBBox() 21:02:26 ... but not sure that needs to outweigh the issue 21:02:34 krit: it's always good to align the keywords 21:02:44 ... can we use fill-box and stroke-box on getBBox? 21:02:57 heycam: possible, but would need to be camelCase 21:03:09 ... the other thing, we have markers as a value in there 21:03:16 -Rich_Schwerdtfeger 21:03:19 krit: even markers we'd have -box 21:03:45 heycam: I'd lean towards making it -box in the property and leave box off on getBBox 21:04:01 krit: agree 21:04:05 ed: I think it's fine as well 21:04:34 krit: do we rename property keywords to fill-box,stroke-box, etc? 21:05:13 RESOLUTION: fill and stroke keyword values in clip-path and mask property get renamed to fill-box and stroke-box 21:05:32 Topic: Bounding box of without d="" 21:05:49 heycam: we brought discussion to the mailing list 21:06:03 ... seemed like we had agreement 21:06:53 krit: so should path element without d attribute have a bounding box, and should it contribute to it's parent? 21:08:07 nikos: think we had consensus on what model to use 21:08:14 ... just need to decide what happens for path without d 21:08:43 krit: do they render or not? A d attribute can have invalid syntax and it will draw up to that invalid point 21:08:57 heycam: the discussion went a bit into invalid or empty attributes would invoke some lacuna value 21:09:04 ... which would be the way that something gets rendered 21:09:20 ed: think they're all a bit special with regards to lacuna values 21:09:33 ... because broken paths do render up to last good data 21:09:54 krit: but for both you render right? 21:10:04 ed: unless the error is so early you don't render anythying 21:10:20 heycam: it doesn't make sense to have a lacuna value for d that causes rendering 21:10:26 all: agree 21:11:23 heycam: i don't think it makes sense to make a lacuna value an invalid value 21:12:08 nikos: an empty d is not invalid, it just doesn't render. There's a special bit of text 21:12:20 krit: can we change that? 21:12:28 nikos: I would have thought it might be too late 21:12:39 heycam: as long as it doesn't change the rendering behaviour 21:12:52 krit: to make things more confusing. the canvas path syntax doesn't require a moveto 21:14:05 ... if you start with a lineto, it will behave as a moveto 21:14:20 ... empty strings will not render anything 21:14:52 heycam: we can decide the issue of omitting the inital moveto separately 21:15:49 heycam: do you think having an empty string and is analogous to a zero width/height rect ? 21:16:38 heycam: I think everyone agrees that an empty path shouldn't render 21:17:42 nikos: so should a M0,0 render? 21:17:49 krit: a rect with zero width height shouldn't render 21:18:37 heycam: I have a feeling implementations render markers in that case 21:19:25 RESOLUTION: path/polygon/polyline with no data set (empty or completely invalid) should not render 21:20:13 s/completely invalid/zero valid commands 21:21:25 heycam: the next issue is what getBBox should return on path/polygon/polyline with empty or zero valid commands 21:21:44 ... everyone in agreement that it should be [0,0,0,0] I think? 21:22:16 ... would it be useful to distinguish a real empty bbox from an invalid one? 21:22:30 ... I have a feeling we would need to return an actual box 21:22:48 ... I think [0,0,0,0] is probably safer 21:22:53 ed: think that's what implementations do 21:24:04 RESOLUTION: getBBox for path/polygon/polyline with no data set (empty or zero valid commands) should return [0,0,0,0] 21:24:24 heycam: final thing is whether the [0,0,0,0] box contributes to ancestor getBBox calls 21:24:34 nikos: don't think it should 21:24:41 all: agree 21:25:19 heycam: I think this is similar to when display:none is set 21:26:46 RESOLUTION: Bounding box for path/polygon/polyline with no data set (empty or zero valid commands) should not contribute to ancestor bounding box 21:26:52 -Tav 21:27:09 ed: when you have a d attribute which is broken half way through I think the bbox should represent the valid part of the path 21:27:14 ... don't think we define that in the spec 21:27:24 krit: are you sure there's no error handling in the appendix? 21:27:33 ed: doesn't talk about the bbox. Just says you render up to that point 21:28:03 nikos: I think the bounding box should cover what is rendered 21:28:06 heycam: agree 21:28:48 RESOLUTION: bounding box for path with some invalid data following some valid data will include the data which is rendered 21:29:47 action: nikos to update specification with path/polyline/polygon resolutions regarding bounding box for missing data 21:29:48 Created ACTION-3599 - Update specification with path/polyline/polygon resolutions regarding bounding box for missing data [on Nikos Andronikos - due 2014-03-13]. 21:30:09 -Thomas_Smailus 21:30:12 -heycam 21:30:14 -stakagi 21:30:15 -krit 21:30:16 -birtles 21:30:17 -ed 21:30:40 RRSAgent, make minutes 21:30:40 I have made the request to generate http://www.w3.org/2014/03/06-svg-minutes.html nikos_ 21:30:50 -nikos_ 21:30:51 GA_SVGWG(SVG1)3:30PM has ended 21:30:51 Attendees were Thomas_Smailus, heycam, nikos_, krit, birtles, ed, Tav, stakagi, Rich_Schwerdtfeger 21:31:45 well things seem to have worked this time so I'll leave it at that =) 21:31:55 did we end up getting the venue for the F2F sorted? 21:32:11 I might just book a hotel somewhere near the main station and the uni? 21:32:14 Leipzig not that big anyway 21:34:09 regiocast 21:34:29 stakagi, can you send mail to public-svg-wg with that information? 21:34:32 may be venue 21:34:39 yes 21:36:23 that's close to the main station 21:38:27 if you guys find a suitable hotel in that area, I'd like to know 21:45:21 I am thinking novotel leipzig city 21:52:12 stakagi: is that the hotel where the f2f is? 21:56:15 no F2F may be held in the room of REGIOCAST Leizig. 21:57:48 I and Dirk are in the final stage of the determination now. 21:59:03 https://www.google.com/maps/place/RCD+Regiocast+Digital+GmbH/@51.3399428,12.3743289,17z/data=!3m1!4b1!4m2!3m1!1s0x47a6f82152973a17:0xb0549ac733b008cd 22:01:16 krit, stakagi, do you know if you need to pay for teleconference equipment as part of the booking? 22:01:27 as I mentioned in a previous telcon I can bring my polycom if you need 22:02:34 Thank you for the care. 22:03:06 or the moment, the staff of REGIOCAST has said that he can prepare polycom. 22:03:26 stakagi, ok, good to know 22:04:33 Where, the charge of the calls to US is required for a difficulty ^^; 22:05:46 Cost can be disregarded if we can use IPtelephone. 22:05:46 I see :) 22:05:53 if they have IP telephone, that's good 22:06:06 my polycom can in theory connect to Zakim via SIP 22:06:09 but I haven't tested it yet 22:08:21 I am going to ask to regiocast staff whether their polycom can connect to audio in/out of PC. 22:10:12 ok 22:11:11 At least, Polycom SoundStation2 has the function and I have tried Skype using it. 22:19:18 heycam: good that you asked. They actually use a different conference system but are ok with bringing our own. So if you want to bring Polycom, then this is fine. 22:19:23 heycam|away: --^ 22:19:41 heycam|away: We should just verify it we need it before you bring it :) 22:20:04 stakagi: sorry. See comments above --^ 22:21:04 stakagi: internet is included and I agree it would be great if we can just use internet 22:21:28 stakagi: heycam|away: so far no one seem to intend to call in anyway 22:30:51 oh sorry 22:36:07 For the time being, I think that preparation of connection with zakim by the Internet is worthy. 22:37:28 I will be glad if you bring polycom which makes it possible. 22:53:20 ok 22:53:28 I will test it soon and let you know if it indeed works 23:06:08 Zakim has left #svg