20:26:11 RRSAgent has joined #svg 20:26:11 logging to http://www.w3.org/2015/03/12-svg-irc 20:26:13 RRSAgent, make logs public 20:26:13 Zakim has joined #svg 20:26:15 Zakim, this will be GA_SVGWG 20:26:15 ok, trackbot; I see GA_SVGWG()4:30PM scheduled to start in 4 minutes 20:26:16 Meeting: SVG Working Group Teleconference 20:26:16 Date: 12 March 2015 20:28:06 GA_SVGWG()4:30PM has now started 20:28:13 +Doug_Schepers 20:29:08 Smailus has joined #svg 20:29:17 nikos, did I forget to update the date in the URL :( 20:29:49 yep =) 20:29:54 +[IPcaller] 20:30:47 +[IPcaller] 20:30:52 +Thomas_Smailus 20:30:52 Zakim, [ is me 20:30:53 +birtles; got it 20:31:17 +??P9 20:31:25 zakim,??P9 is me 20:31:25 +stakagi; got it 20:31:29 +??P10 20:31:33 +[IPcaller] 20:31:35 Zakim, [ is me 20:31:35 +heycam; got it 20:31:39 zakim, ??P10 is me 20:31:39 +AmeliaBR; got it 20:31:55 Chair: Cameron 20:32:02 Regrets: Rossen, Bogdan 20:33:24 Zakim, who is on the call? 20:33:24 On the phone I see Doug_Schepers, ed, birtles, Thomas_Smailus, stakagi, AmeliaBR, heycam 20:33:28 Regrets+ Nikos 20:33:58 ScribeNick: AmeliaBR 20:33:59 Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0040.html 20:34:24 TOPIC: Telcon time 20:34:25 +??P12 20:34:42 DS: We should have a telcon time. And debate for an hour. 20:34:46 zakim,??P12 is me 20:34:46 +Tav; got it 20:35:02 s/DS/Doug/ 20:35:23 Cam: I think last time we sent out a list of proposals and selected from it 20:35:48 Doug: Can we re-use the options from last time, or do we have to restart? 20:36:26 Cam: I don't think we really checked everyone's availability, so we might as well check. 20:36:41 ...I'll send an email in the next few weeks, before Europe goes to summer time. 20:37:23 TOPIC: Transform on SVG View 20:38:00 ED: I think we should postpone until we have more replies to Amelia's email. 20:38:29 Amelia: I suspect after a while we can assume if no replies, then no one cares too much and we can decide. But delay for another week. 20:38:59 TOPIC: Controlling box-sizing for ObjectBoundingBox units ("box-rendering" property? 20:39:01 http://www.w3.org/mid/CACfsppBMiK-0uRJrxTgq4Ke-5xyHQDF42tqHpteSM2ct+1bmLg@mail.gmail.com 20:39:14 s/property?/property?)/ 20:39:34 Cam: Proposal on email list from Paul LeBeau 20:40:02 ...Since we have multiple options for getBBox, can we use this for paint servers 20:40:22 ...As we all know, paint servers on strokes are messed up 20:40:39 (particularly for horizontal/vertical lines!) 20:41:07 Cam: ... Paul's proposal was a separate bbox-rendering property 20:41:23 ED: Don't we have something like this from masking 20:41:35 Cam: Yes, that was my comment as well 20:41:41 http://dev.w3.org/fxtf/css-masking-1/#the-clip-path 20:42:05 http://dev.w3.org/fxtf/css-masking-1/#the-mask-origin ? 20:42:25 ... you declare the reference box in the property 20:42:35 http://dev.w3.org/fxtf/css-masking-1/#the-mask-clip 20:42:36 ... I would like to see a similar structure. 20:42:49 Doug: Agreed. Good idea, lets figure out how best to make it work 20:42:57 Amelia: +1 to using the same syntax 20:43:26 Tav: I think the problem with a separate property is what if you wanted different reference box for fill or stroke. 20:44:06 Birtles: In masking, they actually are separate properties, but then there's a shorthand syntax 20:44:56 Cam: Yes, I'd forgotten that. I think that is an argument for creating a separate property, but different properties for fill and stroke 20:45:46 Amelia: And we should use a similar naming convention, whatever that is 20:46:25 Cam: There is the mask-origin property, nothing currently for clipping 20:46:38 Tav(?): That doesn't stop us adding one 20:46:47 there's also http://dev.w3.org/csswg/css-ui-3/#box-sizing 20:47:03 Amelia: There should be one, for the same reason: the clip path can be an SVG path with objectBBox units 20:47:34 Cam: Currently, in clip-path you specify the reference box as part of the main property, it hasn't been split out 20:49:04 Cam: Since clippath uses one property and masking splits it, I suppose we can choose which to follow 20:49:33 Amelia: One thing to consider is the multiple fill/stroke syntax. Might be convenient to have a separate property that applies the reference box for all values in that list 20:50:04 Cam: That's right, it's after all a common enough syntax for background properties 20:50:41 Cam: Also you could specify it once on the SVG for the whole graphic 20:51:12 Amelia: Would it be an inherited property? Fill/stroke are, but mask, clip, background etc. aren't 20:52:07 Cam: We should mirror the inheritance I think 20:53:09 ...so inheritance would be the same as fill and stroke 20:54:11 Cam: Ok. Then if there is a separate property, would fill and stroke become shorthands, with additional properties for other parts? 20:54:46 Amelia: The idea of using fill and stroke as shorthands has come up before, e.g. when talking about contextStroke/fill keywords 20:54:51 https://lists.w3.org/Archives/Public/www-svg/2015Jan/0012.html 20:56:04 ED: We also have to think about what happens for elements which don't have these types of BBoxes 20:56:28 Doug: Let's ask for a proposal and think about all the details then 20:56:55 ACTION on Cameron: Reply to Paul's email regarding BBox reference for paint servers 20:56:55 Error finding 'on'. You can review and register nicknames at . 20:57:12 ACTION Cameron: Reply to Paul's email regarding BBox reference for paint servers 20:57:12 Created ACTION-3772 - Reply to paul's email regarding bbox reference for paint servers [on Cameron McCormack - due 2015-03-19]. 20:57:42 TOPIC: SVG 2 status 20:58:04 Cam: Tav we were still working on the text chapter? 20:58:16 Tav: I think we covered everything that can easily be decided 20:59:04 Cam: There was one issue in the Styling I wanted to discuss -- Issue 25 20:59:17 ...Animation of presentation attributes 21:00:19 +[Microsoft] 21:00:42 BogdanBrinza has joined #svg 21:00:43 There was text that animating presentation attributes was equivalent to animating CSS, but there was a problem. 21:00:48 https://bugzilla.mozilla.org/show_bug.cgi?id=1062106 21:01:04 Birtles: There was, but we have a bug report to fix it in Mozilla ^^^ 21:01:31 "Animation of presentation attributes is equivalent to animating the corresponding property. Thus, the same effect occurs from animating the presentation attribute with attributeType="XML" as occurs with animating the corresponding property with attributeType="CSS" (see ‘attributeType’)." 21:01:43 that is the current text 21:01:58 Amelia: Animating presentation attribute isn't *exactly* the same currently, because there is also the cascade issue 21:03:07 Doug: The XML vs CSS thing confuses a lot of people, so we resolved to get rid of it 21:04:23 Cam: So to answer your question, the animation would go into the cascade as a style, not an attribute 21:05:26 Amelia: So to be clear, this is effectively deprecating/ignoring the attributeType option, and just using the default behavior (CSS if such a style exists, XML if it doesn't) 21:05:58 the issue I'm referring to is issue-1 in the animation chapter 21:06:27 ED: But there would have to be qualifications for elements that have XML attributes with the same name but different meaning to new presentation attributes (e.g. `x`) 21:06:56 Cam: Is there a clear definition somewhere of how CSS animations and SMIL animations interact? What is the cascade? 21:07:13 ...Does SMIL override the style attribute? 21:07:20 Amelia: Yes it does 21:07:51 Cam: Issue 26 in the styling chapter, should we support ::before and ::after? 21:08:52 Doug: I'll argue the pros. For accessibility, If I'm using ARIA markup to indicate that SVG text is a list, I would want to use ::before and CSS counters to add numbering; in other cases, I might want to add a bullet 21:09:30 ...In general, the functionality of using icons in SVG could be enhanced by being able to insert a text definition before/after 21:10:10 ...But, I do think it should be restricted to text elements. It doesn't make sense elsewhere. 21:10:38 Amelia: Might we want to extend that to metadata like title and desc? 21:11:18 Doug: I'm not sure whether it makes sense to use CSS for accessibility content; as of today, I don't think it would have any effect in most screen readers. 21:11:52 Amelia: As you said, it could be a later implementation if there were use cases/implementation. 21:11:57 text::before { content: url(someimage.png); } 21:12:21 ED: Would you explicitly disallow using URL to reference an image? 21:12:38 ...If this is only being used within text content. 21:13:45 Doug: I think we should probably disallow it unless someone comes up with a good use case. 21:14:25 ...But maybe it does make sense, if someone has a graphic they've defined and they want to use it as a bullet or something within the text. 21:14:49 Amelia: But we don't have any rules for how to layout an image in the midst of a stream of text, the way the CSS box layout does. 21:15:26 Doug: But we are already incorporating a lot of CSS box model layout for text, so doesn't it make sense to use the same rules? 21:15:37 Tav: It makes sense for some types of text layout, not others. 21:16:24 Doug: Can we reverse-engineer that? We do have a text box already, it's just a single-line box the length of the text. 21:16:43 ...but then we'd have to figure out padding & margins & so on between text and image 21:17:38 Tav: We resolved last week to not have padding etc. on non-boxed text 21:18:34 Doug: I think it will happen eventually... maybe for SVG 3 21:19:04 Amelia: So we could resolve now to support plain text before/after content, with images to be possibly supported/defined later. 21:19:22 Doug: That works. After all, you could still use unicode characters for bullets. 21:19:48 Tav: How does that affect alignment: text-anchor start/end? 21:20:21 Amelia: I would think that would be straightforward, just adding extra characters to the text. But what about character-by-character positioning attributes? 21:20:49 Doug: I think we need to clearly define this in the proposal 21:21:08 Tav: I think other issues take priority 21:21:38 Doug: We can break it into multiple issues, not committing to which version of SVG they will go in 21:22:38 Proposed resolution: That we will support ::before and ::after pseudoelements with text content; and that we will consider other types of replaced content after resolving all issues related to text content 21:24:52 Correction: That SVG will support ::before and ::after pseudoelements with text content (and possibly other types of replaced content), subject to resolving other text layout issues 21:25:11 ...first 21:25:33 RESOLUTION That SVG will support ::before and ::after pseudoelements with text content (and possibly other types of replaced content), subject to resolving other text layout issues first 21:25:43 (on text content elements only?) 21:25:53 RESOLUTION: That SVG will support ::before and ::after pseudoelements with text content (and possibly other types of replaced content), subject to resolving other text layout issues first 21:28:09 TOPIC: Stroke-dash animation of paths 21:28:50 Doug: This is a common & popular technique, to use stroke-dasharray and stroke-dashoffset to create the effect that a line is being drawn in realtime. It's kind of a Wowzer kind of feature. 21:29:47 ...I've always liked this feature, but it is somewhat limited. You aren't actually drawing the shape in real time, not actually changing the path and other properties related to it. 21:30:29 ...It's kind of a hack, and there are many things it cannot do. 21:31:26 Also, for other path animations (morphing shapes), it is limited by the fact that you need the same number of path segments of the same kind. 21:31:41 s/Also/Doug: Also/ 21:32:29 Doug: So I wanted to throw an idea out a Brian about whether it should be possible to animate two paths together by creating a simplified version and animating between the two. 21:32:45 animate from "M 0,0" to "M 0,0 C ... ... ..." 21:34:35 Bogdan: In IE, we're following the curent Chrome process, I don't think it would be possible to animate from an arbitrary path to another. 21:35:08 Amelia: It's not impossible if there are clear definitions. In transforms, there are definitions for how to animate one type of transform to another (or none). 21:35:44 ...We'd need clear definitions, e.g. to upgrade a straight line to a curve that looks like the same line, and animate that. 21:36:09 Bogdan: That sounds possible, but right now, we need to be able to animate from one another to another. 21:36:30 Cam: The problem is that there are multiple possible solutions. 21:37:20 Doug: I would propose that we keep this in mind, not necessarily for SVG 2, but in future. I like Amelia's idea, and think it's a natural extension of the way we've already defined how there is a clear, decomposed path for all the basic shapes. 21:37:45 ...the logical next step is to decompose one type of path to another. 21:38:32 ...I know there was a JavaScript program that could do this in order to animate any two shapes. If it can be done in JavaScript, it can be done in C. 21:39:37 ...I think it might also be useful to define a standard decomposition for all path elements. Maybe we could create a separate spec. 21:40:36 Presto had a "bezierize" path normalization method for similar purposes... was used for the glyph warping for textPath (method=stretch) 21:41:04 Bogdan: It's definitely something that would have much interest in the community. But I'm not sure it can easily be done in the current situation. 21:41:38 -Thomas_Smailus 21:41:45 Doug: And for the specific case of animating the path length, maybe have a specific "draw a path" algorithm that also draws the fill of the shape. 21:41:49 we can define normalizing path segment types into, e.g. cubic beziers, so that you'd only need to have the same number of segments (not necessarily the same type)--when you have a different number of segments though you need to say how they line up but maybe Cyril's superpath syntax could be used to specify the anchors 21:42:03 Amelia: I'm not sure about the math for that one. 21:42:48 Cam: Doug, why don't you put together some ideas in a wiki page for discussion in the future? 21:43:30 -[Microsoft] 21:43:31 -heycam 21:43:32 -Tav 21:43:33 -stakagi 21:43:34 -birtles 21:43:34 -Doug_Schepers 21:43:35 -ed 21:43:57 rrsagent, make minutes public 21:43:57 I'm logging. I don't understand 'make minutes public', AmeliaBR. Try /msg RRSAgent help 21:44:13 rrsagent, make logs public 21:44:26 rrsagent, publish the minutes 21:44:26 I have made the request to generate http://www.w3.org/2015/03/12-svg-minutes.html AmeliaBR 21:45:21 zakim, bye 21:45:21 leaving. As of this point the attendees were Doug_Schepers, [IPcaller], ed, Thomas_Smailus, birtles, stakagi, heycam, AmeliaBR, Tav, [Microsoft] 21:45:21 Zakim has left #svg