13:00:35 RRSAgent has joined #svg 13:00:35 logging to http://www.w3.org/2014/07/24-svg-irc 13:00:37 RRSAgent, make logs public 13:00:37 Zakim has joined #svg 13:00:39 Zakim, this will be GA_SVGWG 13:00:39 ok, trackbot, I see GA_SVGWG()9:00AM already started 13:00:40 Meeting: SVG Working Group Teleconference 13:00:40 Date: 24 July 2014 13:01:20 Zakim who is on the call? 13:01:29 glenn has joined #svg 13:01:30 Zakim, who is on the call? 13:01:31 On the phone I see ??P6, krit, [IPcaller] 13:01:40 Zakim, [ is me 13:01:40 +birtles; got it 13:01:57 +[IPcaller] 13:02:05 zakim, ??P6 is me 13:02:05 +Smailus; got it 13:02:28 +??P13 13:03:21 +[IPcaller.a] 13:03:22 Zakim, [ is me 13:03:22 sorry, heycam, I do not recognize a party named '[' 13:03:31 Zakim, [IPcaller.a] is me 13:03:31 +heycam; got it 13:03:43 zakim, ??P13 is me 13:03:44 +stakagi; got it 13:03:51 Zakim, who is on the call? 13:03:52 On the phone I see Smailus, krit, birtles, [IPcaller], stakagi, heycam 13:04:12 Chair: Cameron 13:04:20 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2014JulSep/0018.html 13:05:20 +Doug_Schepers 13:06:47 scribe: birtles 13:06:49 scribenick: birtles 13:07:07 +Tav 13:07:17 topic: x and y properties on SVGTextPositionElement 13:07:31 s/SVGTextPoitionElement/SVGTestPositioningElement/ 13:07:42 krit: the issue we had in the past was that x/y on most elements just have one value 13:07:50 ... but for and it is a list of length values 13:08:11 ... question is: should we really try to make x attribute of elements be stylable as well 13:08:20 ... or just attributes 13:09:18 ChrisL has joined #svg 13:09:20 vs 13:09:28 krit: should we allow them to take a list of values? 13:09:58 ... we could still allow x/y to be properties 13:10:03 ... but not allow them to take a list of values 13:10:32 ... if x is a property, then because etc. already takes a list of lengths, the property would also have to take a list 13:10:36 +ChrisL 13:10:42 ... and we'd have to define what to do if a list was set on other elements 13:11:00 ... my proposal is to make x/y properties just accept one value 13:11:13 ... and to have x/y on *not* be presentation attributes, just attributes 13:11:34 zero specificity 13:11:44 heycam: if you have x/y applied to text as a property and you also set x/y on the what happens? 13:12:02 ... if the attribute is *not* a presentation attribute how do you define the processing there 13:12:28 krit: one possibility is that we create an auto value for this purpose 13:12:37 ... if the computed value is still auto then you use the value of the x/y attributes 13:12:52 ChrisL: that would work but it's adding yet another way of how properties/attributes combine 13:12:57 ... let's step back for a minute 13:13:09 ... we have a bunch of attributes that are per-element 13:13:20 ... and that was fine since we could animate attributes or properties 13:13:39 ... but now we're doing this in order to make these things animatable with CSS animations that only work with properties 13:13:44 +??P21 13:13:51 ... but is this still necessary now we have a model that covers both? 13:14:02 Zakim, ??P21 is me 13:14:02 +nikos__; got it 13:14:06 ... this seems to introduce a lot of clashes/complexity 13:14:31 krit: if you look at twitter, a lot of things are animated with CSS that could be animated with SVG animation 13:14:54 ... so people would need to learn SVG animation in order to animate properties 13:15:21 shepazu: the other argument (aside from animation) is that more people are familiar with CSS than SVG 13:15:31 ... and they feel more comfortable using CSS than SVG 13:15:46 ChrisL: understood, but the set of things they are using were designed from the start to be attributes 13:15:52 ... not properties 13:16:14 ... properties are designed to be general and now we're taking attributes that are designed to be more specific and making them properties 13:16:35 krit: most attributes we can turn to properties, but x/y are different because they are used differently on elements 13:16:55 ChrisL: another way to do that--if we're going to break things, we can choose what we break 13:17:10 ... we could break the name mapping, e.g. call the text x/y, tx/ty 13:17:21 krit: I don't think we need to break anything 13:17:29 ... (by turning attributes into properties) 13:17:37 ... based on experience in Blink/WebKit 13:17:47 Tav: is that the case already in Blink/WebKit 13:18:04 krit: there are some exceptions in Blink, but mostly 13:18:40 shepazu: some authoring tools use multiple values in x/y, but I've never seen code besides that using that functionality 13:18:46 krit: for it's quite common 13:18:53 ... so we can't break it 13:19:00 shepazu: is it that common? 13:19:14 krit: not for manual editing, but for authoring tools it's common 13:19:47 shepazu: I think most SVG is actually generated by d3 13:20:12 ... and d3 doesn't use x/y in that way 13:20:27 q+ 13:20:28 Tav: we use x/y like that in Inkscape 13:20:42 shepazu: I don't think this proposal breaks this though right? 13:20:50 krit: no, it doesn't 13:21:03 shepazu: we already have a distinction between attributes and properties, e.g. regarding units 13:21:18 krit: actually in CSS3 syntax, presentation attributes are allowed to omit units 13:21:20 ack ChrisL 13:21:44 ChrisL: a presentation attribute is one syntactic form of a property 13:22:17 ... I see this mixed up a lot 13:22:35 ... code which used to spit out PDF tends to use x/y on every character in the string 13:22:46 ... since internally that's how they do tracking/kerning/etc. 13:22:53 ... each character has its own positioning data 13:23:07 ... it's very fragile unless you have a downloadable font 13:23:23 ... it's also a bit of a hack now that fonts have better kerning thanks to OpenType features 13:23:26 not in hand authored content though 13:23:34 ... I agree with Dirk that you see this usage of x/y alot 13:23:58 shepazu: I agree, but I don't think that what Dirk is proposing breaks that 13:24:05 krit: it doesn't 13:24:19 ... x/y for definitely has a different syntax that for every other element 13:24:25 ... is special, how do we deal with it? 13:24:26 +??P22 13:24:38 ... one possibility is we make x/y a list for every element 13:24:52 ... one is that we say x/y for is not a presentation attribute 13:25:04 ... one way is to introduce "auto" as I suggested before 13:25:18 ... but as ChrisL mentions, it does complicate the interaction of these things 13:25:24 heycam: none stand out to me as a clear winner 13:25:31 Tav: the third seems best 13:25:38 web animation makes this less necessary, yes 13:25:46 ... although I tend to agree with ChrisL that this is not really necessary for animation 13:26:01 ... I don't think we need to handle lists 13:26:50 heycam: all seem to have downsides 13:27:01 krit: I can put forward all three options on the mailing list 13:27:07 ... and we can try to get a resolution next week 13:27:39 heycam: I get the feeling from ChrisL and Tav's comments that they are less enthusiastic about the whole attribute-to-presentation enterprise 13:27:47 Tav: it's not a strong feeling, I won't object to it 13:28:13 ChrisL: I won't object either, but I think we're doing this for the wrong reasons, it just moves the pain around 13:29:01 heycam: I tend to agree but I did see web developers doing responsive SVG and coming up against obstacles because SVG's geometry attributes couldn't be used 13:29:07 -nikos__ 13:29:27 krit: from a code point of view it actually makes the code simpler 13:29:44 Tav: I thought you were initially against making attributes into presentation attributes 13:29:49 krit: I'm not sure I was 13:30:15 heycam: in Gecko, every element pays storage price for additional properties even if they don't apply to that element 13:30:23 ... we do group properties together 13:30:34 ... so if you don't set any of those properties it's only one pointer 13:30:46 ... but it does mean that some memory is used up for every element 13:30:57 krit: I think the cost is still not that big 13:31:16 heycam: maybe, but if the document is large enough, it might not have that much effect 13:31:32 ... but then the CSSWG doesn't seem to be concerned about adding new properties so maybe it's not such a big deal 13:31:51 ... I think width/height are easy to convert because those properties already exist 13:31:58 krit: from a memory/implementation point-of-view? 13:32:07 heycam: more from an aesthetics/spec point of view 13:32:16 ... those things already exist so it's an easy decision to make 13:32:27 ... for the rest, they're new properties, there are name mismatches etc. 13:32:49 krit: the other properties I was thinking about are r/cx/cy etc. 13:33:08 ... these don't have conflicts except dx/dy with regards to / 13:33:25 heycam: there are two classes of issues 13:33:37 ... are there real conflicts across elements 13:33:47 ... and are there conflicts with existing properties that mean we can use the same name 13:34:05 ... with this limited set of properties we don't run into the second class of issues 13:34:45 ... so it's of lesser concern, although the naming is still unusual 13:35:02 ... having thought of the options you presented before, I think I agree with Tav 13:35:24 ... that is, use the new property value 13:35:33 ... to decide between using the computed style or the attribute value 13:35:46 krit: that sounds good to me 13:35:54 heycam: does anyone else want to take this to the list? 13:36:02 ChrisL: I'd like to see this summarised so I can be sure 13:36:13 heycam: krit can you please summarise and send to the list? 13:36:14 krit: sure 13:36:33 topic: Where to add the new x,y,cx,cy,rx,ry,r CSS properties? 13:36:48 krit: we have different sections in the SVG spec, where do I add them? 13:37:02 heycam: at the moment we have an obvious section for defining the attributes that apply to individual elements 13:37:07 krit: and we still need that? 13:37:16 heycam: yes, I think that makes sense since that's where people will look 13:37:34 krit: width/height we still need to define as presentation attributes on the element 13:37:47 ChrisL: I think you need a new section where you define all these properties 13:37:55 ... and then you need the existing sections 13:38:03 ... and you need to link from them to the new section 13:38:43 krit: if we do this, won't that change the numbering? 13:38:52 ChrisL: are people quoting sections by numbers? 13:39:02 heycam: I don't think you should worry about changing the numbering 13:39:20 krit: so you're fine with adding a new section? 13:39:25 heycam: what would be in that new section? 13:39:28 krit: layout properties 13:39:46 heycam: perhaps a section in the styling chapter that summarises all of the geometry properties 13:39:56 ... i.e. refers to width/height in CSS then defines the other ones 13:40:12 ... then in the other sections referring to that 13:40:21 krit: I would agree with that 13:40:30 heycam: you might have to think about how to present that 13:40:39 ... since we only put attributes in the little grey box at the moment 13:40:45 ... I'm sure you can come up with something 13:40:47 krit: suyre 13:40:53 s/suyre/sure 13:40:58 s/suyre/sure/ 13:41:26 heycam: did you say you have patches for doing this already? 13:41:27 krit: yes 13:42:28 topic: London F2F 13:42:37 Tav: will there be a join meeting with CSSWG at TPAC? 13:42:42 heycam: I think so 13:43:10 https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda_proposals 13:43:21 agenda+ dev night in London 13:44:20 ChrisL: I believe we will be able to have a join meeting with CSSWG in Sydney at the start of 2015 13:44:55 krit: I don't think TPAC is a good time for a joint meeting 13:45:26 heycam: normally we encroach on their time, but I think we should try to have a joint meeting at TPAC and Sydney 13:46:07 ... as ChrisL mentioned, please think about agenda items for the London F2F 13:46:14 topic: Dev night in London 13:46:23 shepazu: this came about from a web platform docs meeting 13:46:43 ... apparently there are a lot of design agencies in London that Adobe has connections with and many of them don't know much about SVG 13:46:54 ... but they're good at making assets etc. 13:47:10 ... so if people are going to be in London for SVG, we should try and connect 13:47:33 ... it occurred to me that there will be a lot of people in London who are designers and might be interested in SVG but don't know about the Graphical Web 13:47:36 +1 13:47:53 ... if we wanted to have a dev night, perhaps hosted by Mozilla, similar to how we've done before 13:48:20 ... we could have a few presentations 13:48:31 ... ChrisL could do one on fonts etc. 13:48:35 svg+ 13:48:35 ... it doesn't have to be just SVG 13:48:53 ... London has quite a lot of font activity 13:49:06 ChrisL: yes, I would be interested 13:49:21 shepazu: anyone else interested in doing a talk? 13:49:36 ... perhaps 3 presentations, ~20min each = 1hr, then an open session 13:49:36 wish some other browsers besides firefoxc would implement the CSS3 Font opentype stuff that my talk is about 13:49:53 shepazu: would be good to have someone from W3C 13:50:00 ChrisL: or even getting a local designer coming along 13:50:06 ... so it's not just us talking 13:50:11 ... we should be open to that 13:50:26 shepazu: if we scoped it to people to doing stuff with SVG 13:50:32 ... that might be good 13:50:44 +1 to svg lightning talks 13:50:52 ... we could have an open mic/lightning talk session around what people are doing with SVG 13:51:03 ... I'd like you to think about it 13:51:08 we need to announce asap or it will be too late 13:51:16 ... would be good to hear from implementors 13:52:16 ... I'd like to get names to put on the bill other than just W3C folks 13:53:03 I have tow existing svg-and-font talks, one on css3 fonts and one on SVG Glyphs in OpenType 13:53:21 might be premature, but wouldn't mind talking about diffusion curves and getting input from artists 13:53:30 its not like its the capital or anything 13:54:19 shepazu: if anyone is interested in doing a presentation, let me know 13:54:37 krit: might be interested 13:54:44 but yeh I'd be happy to talk a little about diffusion curves. I'm keen to hear from people how they might use them 13:55:27 krit: to talk about SVG and photoshop 13:55:43 who is hosting? is it at mox london? 13:55:49 s/mox/moz 13:55:52 heycam: did you have a date in mind? 13:56:35 Tuesday night we'll need to head to Winchester 13:56:47 friday 13:58:07 monday is a holiday 13:58:31 shepazu: probably Friday is best 13:58:47 ... heycam can you check if Mozilla can host? 13:58:50 heycam: sure 13:59:59 Simon 14:00:05 simon sapin 14:01:35 -Smailus 14:01:38 -[IPcaller] 14:01:40 -Doug_Schepers 14:01:40 -birtles 14:01:41 -??P22 14:01:41 -Tav 14:01:42 -ChrisL 14:01:42 -krit 14:01:44 -heycam 14:01:44 -stakagi 14:01:44 GA_SVGWG()9:00AM has ended 14:01:44 Attendees were krit, [IPcaller], birtles, Smailus, heycam, stakagi, Doug_Schepers, Tav, ChrisL, nikos__ 14:01:57 RRSAgent: make minutes public 14:01:57 I'm logging. I don't understand 'make minutes public', birtles. Try /msg RRSAgent help 14:02:00 RRSAgent: make minutes 14:02:00 I have made the request to generate http://www.w3.org/2014/07/24-svg-minutes.html birtles 14:02:26 rssagent, make logs public 14:02:32 rssagent, make minutes 14:02:33 thanks ChrisL! 15:50:49 glenn has joined #svg 16:21:30 glenn has joined #svg 16:56:05 glenn has joined #svg 18:00:59 stakagi has joined #svg 19:25:50 TabAtkins: shepazu: Didn’t we agree that we make viewBox an presentation attribute? If yes, what is the name? Also, wasn’t there an auto value? 19:26:21 thorton has joined #svg 19:32:07 I'd have to look it up, but I think we were going to use "viewbox". 19:32:31 And yeah, we wanted to add an auto value, but I forget exactly what it was going to do. 19:35:09 TabAtkins: maybe to cover the bounds of all content elements? 19:35:31 I mean, there was something like that, but I think that was supposed to be for inline