20:27:52 <RRSAgent> RRSAgent has joined #svg
20:27:52 <RRSAgent> logging to http://www.w3.org/2015/03/19-svg-irc
20:27:54 <trackbot> RRSAgent, make logs public
20:27:54 <Zakim> Zakim has joined #svg
20:27:56 <trackbot> Zakim, this will be GA_SVGWG
20:27:56 <Zakim> ok, trackbot; I see GA_SVGWG()4:30PM scheduled to start in 3 minutes
20:27:57 <trackbot> Meeting: SVG Working Group Teleconference
20:27:57 <trackbot> Date: 19 March 2015
20:31:01 <Zakim> GA_SVGWG()4:30PM has now started
20:31:07 <Zakim> +[IPcaller]
20:31:14 <ed> Zakim, [IP is me
20:31:14 <Zakim> +ed; got it
20:31:37 <Zakim> +??P1
20:31:46 <Zakim> +??P2
20:32:03 <ed> Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Mar/0081.html
20:32:10 <stakagi> zakim, ++P2 is me
20:32:10 <Zakim> sorry, stakagi, I do not recognize a party named '++P2'
20:32:12 <krit> Zakim, P1 is me
20:32:12 <Zakim> sorry, krit, I do not recognize a party named 'P1'
20:32:22 <krit> Zakim, ??P1 is me
20:32:22 <Zakim> +krit; got it
20:32:23 <stakagi> zakim, ??P2 is me
20:32:24 <Zakim> +stakagi; got it
20:33:29 <Zakim> +??P3
20:33:34 <nikos> Zakim, ??P3 is me
20:33:35 <Zakim> +nikos; got it
20:34:11 <Smailus> Smailus has joined #svg
20:34:40 <Zakim> +[Microsoft]
20:34:41 <Zakim> +Thomas_Smailus
20:34:59 <Rossen> zakim, microsoft has me
20:34:59 <Zakim> +Rossen; got it
20:35:33 <nikos> scribenick: nikos
20:35:33 <Zakim> +[IPcaller]
20:35:53 <nikos> Scribe: Nikos
20:36:05 <Zakim> +??P7
20:36:11 <Rossen> zakim, don't be so difficult
20:36:11 <Zakim> I don't understand 'don't be so difficult', Rossen
20:36:15 <nikos> Topic: SVG2 (and modules) publication status/deadline
20:36:31 <nikos> ed: I was wondering if we had set a date for when to publish SVG 2 ?
20:36:37 <nikos> ... and the associated modules
20:36:39 <Tav> Zakim, ??P7 is me
20:36:39 <Zakim> +Tav; got it
20:36:44 <nikos> Rossen: are you talking about the modules or SVG 2?
20:36:57 <nikos> ed: At the F2F we said we'd publish the split out modules and chapters along with the svg 2 spec
20:37:07 <nikos> ... wondering how far along we are?
20:37:10 <Zakim> +[IPcaller]
20:37:11 <nikos> ... is what we have now sufficient?
20:37:12 <heycam> Zakim, [ is me
20:37:12 <Zakim> sorry, heycam, I do not recognize a party named '['
20:37:16 <heycam> Zakim, [ is me
20:37:16 <Zakim> sorry, heycam, I do not recognize a party named '['
20:37:20 <heycam> Zakim, [IPcaller] is me
20:37:20 <Zakim> +heycam; got it
20:37:29 <nikos> Rossen: if we're talking about publishing a bunch of FPWD and a refreshed WD of SVG 2
20:37:33 <nikos> ... I don't see why we should hold off
20:37:44 <nikos> heycam: we agreed to do that - I was going to take care of it
20:37:50 <nikos> ... I think the date we set is coming up in the next week
20:37:59 <nikos> ... the only thing is I want to do the splitting of the stroking features
20:38:06 <nikos> ... that's not so straight forward
20:38:20 <nikos> ed: so do we have a set date for last edits?
20:38:32 <nikos> heycam: If you really want them in then the end of this week
20:38:41 <nikos> ... Not sure when I'll do the bundling but probably early next week
20:38:57 <nikos> ed: so expect to publish Thursday next week?
20:38:59 <nikos> heycam: yes
20:39:10 <nikos> ... that will be the main spec, the marker module, and the stroking module
20:39:33 <nikos> Topic: SVG 2 open issue discussion
20:39:53 <Zakim> +??P9
20:39:53 <nikos> bogdan: we did iniital pass through of co-ord system and units chapter
20:39:57 <nikos> ... want to know if it's the right approach
20:40:03 <AmeliaBR> zakim, ??P9 is me
20:40:03 <Zakim> +AmeliaBR; got it
20:40:14 <nikos> ... we put everything that does need discussing separately
20:40:18 <nikos> ... does that make sense so far?
20:40:25 <nikos> ed: yes I think so
20:40:47 <nikos> Rossen: we can jump into discussion and allow everyone to review the not an issue and actionable bits and discuss later
20:41:04 <nikos> ... or we can spend some time walking through the 'not an issue and actionable' first and then get into discussion
20:41:23 <nikos> ... imo the wg time will be spent jumping into the issues that need discussion
20:41:29 <nikos> ... sound good?
20:41:41 <nikos> heycam: yes - we've been doing that for the last couple of weeks where people have put their issues up for assessment
20:41:50 <Zakim> +Doug_Schepers
20:41:50 <nikos> ... many chapters now only have issues that need discussion
20:42:02 <nikos> ... but require chapter manager to do work or investigation before they can be discussed
20:42:29 <nikos> Rossen: let's dive into open issues on co-ordinates and units then
20:42:41 <nikos> bogdan: issue 5 - effect of transform matrix on sibling element
20:42:49 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Coordinate_Systems.2C_Transformations_and_Units_.28Bogdan.29
20:45:54 <nikos> bogdan: proposal is to move this to the attributes section
20:46:09 <nikos> ... doesn't look like this is specific to transforms
20:46:13 <nikos> ... are we missing something here?
20:46:39 <nikos> heycam: I think the section was removed illustrated how other elements on the element that the attribute is specified on are affected by the transform
20:46:47 <nikos> ... same behaviour is going to occur for transform property
20:46:54 <nikos> ... so not sure why that section would have been removed
20:47:10 <nikos> bogdan: that's the question - is there anything specific to do with transforms? if so we should put it back
20:47:21 <nikos> ... otherwise we should move it to somewhere more general
20:47:37 <nikos> heycam: think it would be good to have wording describing how transform affects other attributes on the element
20:47:41 <nikos> bogdan: so bring back the removed part?
20:47:42 <nikos> heycam: yes
20:48:05 <nikos> bogdan: issue 6 - about the blue box for attributes in general - a generic question
20:48:09 <nikos> ... doesn't look like we need it in this case
20:48:13 <nikos> ... proposal is to remove it
20:48:32 <nikos> heycam: agree it should be removed
20:48:53 <nikos> ... pattern i was using in the rest of the spec is for properties defined completely in other specs - we wouldn't have the blue box
20:48:54 <Zakim> -nikos
20:49:09 <nikos> ... just point to the other spec - like in hte green box
20:49:41 <Zakim> +??P3
20:49:45 <nikos> Zakim, ??P3 is me
20:49:45 <Zakim> +nikos; got it
20:50:38 <nikos> bogdan: resolved that we don't need a resolution on minor editorial changes - just put it in the commit message so it's trackable
20:50:49 <nikos> Tav: noticed css 3 transform spec is in the green note - is that how we should do it?
20:50:58 <nikos> ... 'see other specs' should be in green?
20:51:01 <nikos> heycam: I'll find an example
20:51:09 <nikos> Tav: there's a mixture of styles
20:51:34 <nikos> Rossen: bikeshed will usually link automatically and generate the reference table
20:52:04 <nikos> heycam: think we'd like to switch to using bikeshed but there's some issues at the moment with features that aren't supported
20:52:32 <heycam> https://svgwg.org/svg2-draft/painting.html#VisibilityControl
20:52:53 <nikos> heycam: the pattern I've been using is this "See the blah specification for the definitions of blah"
20:53:03 <nikos> ... and name the section 'The effect of the so and so property'
20:53:16 <nikos> ... to distinguish that we're not defining the property here
20:53:23 <nikos> Tav: that's awfully wordy
20:53:28 <nikos> Rossen: only makes it worse for the writers
20:53:40 <nikos> AmeliaBR: so you'd have 'The effect of the transform on svg layout properties'?
20:54:03 <nikos> ... so a kind of a note section?
20:54:07 <nikos> heycam: it is a kind of a note
20:54:30 <nikos> ... we usually have the property name, then colon, then a short description of the property
20:54:41 <nikos> ... in this case the only difference is to include 'The effect of'
20:54:51 <nikos> Tav: personally I don't think it's neccessary
20:54:56 <nikos> ... but don't care that much
20:55:13 <nikos> heycam: I like seeing from the TOC here is something we define, and here is something we reference
20:55:22 <nikos> Rossen: ok sounds good
20:55:30 <nikos> bogdan: Issue 9
20:55:36 <nikos> ... more or less the same as issue 5
20:55:49 <nikos> ... suggest we follow the same resolution and update the link if we bring the paragraph back
20:56:00 <nikos> ... it's also about the effect of the transform attribute
20:56:07 <nikos> heycam: sounds fine
20:56:12 <nikos> bogdan: Issue 10
20:56:27 <nikos> ... it appears we won't need this
20:56:37 <nikos> ... but would like to hear from the group
20:56:45 <nikos> heycam: think someone put that issue there because I haven't seen anyone use defer
20:56:58 <nikos> ed: my preference is to ignore it
20:57:07 <nikos> AmeliaBR: the only place it's useful is when embedding svg images using an svg image element
20:57:32 <nikos> ... usually you use 'use' elements rather than images
20:57:45 <nikos> Smailus: we have a use case at Boeing for putting svg documents in svg documents
20:57:55 <nikos> AmeliaBR: would it be useful to use the defer setting ?
20:58:15 <nikos> Smailus: yes, we're using it to overlay two images so we'd need to have each of those separate SVGs properly retain their look and feel
20:58:23 <nikos> Rossen: not sure I follow how that correlates?
20:58:43 <nikos> Smailus: what's the key question?
20:58:50 <nikos> AmeliaBR: is defer useful on preserveAspectRatio
20:58:57 <nikos> Smailus: can't speak to that - don't think we're using it that way
20:59:28 <nikos> AmeliaBR: is it difficult to support defer on preserveAspectRatio in implementations?
20:59:40 <nikos> ... in an html document this is used automatically
20:59:52 <nikos> Rossen: I was thinking the opposite - the aspect ratio preservation is assumed
21:00:12 <nikos> ... and I don't know when you'd want to have a non ratio preserved image
21:00:24 <nikos> ... does that make sense?
21:00:34 <nikos> ... for implementation you're already doing that for images
21:00:45 <nikos> ... don't see non aspect preserving scenario being a useful use case
21:00:55 <nikos> AmeliaBR: the idea you can override the setting on the file you're embedding?
21:00:56 <Zakim> -krit
21:00:59 <nikos> ... one case might be alignment
21:01:03 <nikos> ... file embedding has cetner
21:01:08 <nikos> ... and you want it left aligned
21:01:14 <nikos> Rossen: what does that have to do with aspect ratio?
21:01:31 <nikos> AmeliaBR: preserveAspectRatio does both
21:01:44 <nikos> ... whether you preserve and if you are how do you align within the space
21:01:47 <heycam> xMinYMin vs xMidYMix for example
21:01:50 <heycam> *Mid
21:01:56 <nikos> Rossen: can you explain what you mean by alignment in here?
21:02:09 <nikos> ... even if you preserve the aspect ratio you always have an origin where the image is going to be rendered
21:02:15 <nikos> ... not sure what alignment you are referring to exactly
21:02:28 <nikos> AmeliaBR: in your main file you have a certain area described for 'draw the image in this space'
21:02:33 <nikos> ... but embedded image doesn't fit in that space
21:02:41 <nikos> ... if you're preserving aspect ratio you're not stretching to fit that space
21:02:49 <nikos> ... so the question is how you align it ?
21:02:59 <nikos> Rossen: there's no aligment here . there's just an origin where the image goes
21:03:08 <nikos> ... assume you have a square and a 1x2 svg that has to go inside
21:03:22 <nikos> ... when the svg is scaled with ratio preservation half the square to the left where the origin is
21:03:26 <nikos> ... the other half will be empty
21:03:36 <nikos> ... there's no way to align the image that I know of
21:03:47 <nikos> ... are we trying to invent something different here?
21:03:55 <nikos> AmeliaBR: think we have a language mix up
21:04:05 <nikos> ... by align I'm talking about xMid yMax, etc
21:04:32 <nikos> Rossen: these would be applied as they would, regardless of the aspect ratio
21:04:35 <Zakim> -nikos
21:05:09 <Zakim> +??P1
21:05:11 <nikos> Zakim, ??P1 is me
21:05:11 <Zakim> +nikos; got it
21:05:46 <nikos> ed: so what do we do - investigate further?
21:05:55 <nikos> ... can we decide something here?
21:06:06 <nikos> bogdan: don't think we need an action. if it's there it should work
21:06:09 <nikos> ... can discuss dropping later
21:06:20 <nikos> ed: think we should maybe ask if there's someone that has use cases
21:06:22 <nikos> ... put it to the list
21:06:27 <nikos> ... raise again in future
21:06:31 <nikos> bogdan: i can do that
21:06:48 <nikos> action: bogdan to create test case for preserveAspectRatio defer
21:06:48 <trackbot> Created ACTION-3773 - Create test case for preserveaspectratio defer [on Bogdan Brinza - due 2015-03-26].
21:07:12 <nikos> bogdan: issue 17
21:07:16 <nikos> ... need align for mesh gradients?
21:07:26 <nikos> ... so mesh gradient owner needs to add this?
21:07:42 <nikos> Tav: can give me an action. It's going to take some thought
21:07:50 <nikos> s/need align for/need a line for
21:08:06 <jcraig> jcraig has joined #svg
21:08:12 <nikos> action: Tav to come up with solution for issue 17 in co-ordinates and units
21:08:13 <trackbot> Created ACTION-3774 - Come up with solution for issue 17 in co-ordinates and units [on Tavmjong Bah - due 2015-03-26].
21:08:21 <nikos> bogdan: Issue 18
21:08:50 <nikos> ... it's not clear
21:09:05 <nikos> AmeliaBR: is there going to be a way to set object bounding boxes to use the other types of bounding boxes?
21:09:18 <nikos> heycam: similar to what we discussed last week relating to Paul's request on the list
21:09:49 <nikos> AmeliaBR: it's not necessarily either, or
21:10:05 <nikos> ... the issue itself seems to be just 'reference the definition and how it's calcualted'
21:10:24 <nikos> heycam: think we just need a sentence saying 'the bounding box that this is talking about is the one you get by invoking that algorithm'
21:11:46 <nikos> heycam: next is issue 20
21:12:17 <nikos> bogdan: that should be a comment at the end
21:12:31 <ed> https://svgwg.org/svg2-draft/coords.html#InterfaceSVGTransformList
21:12:38 <nikos> ... is this something specific we need to add or can we just defer to CSS transforms?
21:12:51 <nikos> heycam: dirk not here, but pretty sure all this dom transform stuff got added to css transforms
21:12:55 <nikos> ... so shouldn't need to define it
21:12:59 <nikos> ... but person doing the editing should check
21:13:06 <nikos> ... if it is then we don't want to duplicate the wording
21:13:30 <AmeliaBR> http://www.w3.org/TR/css3-transforms/#transform-attribute-dom
21:13:33 <nikos> bogdan: will clarify with the editor about what is the best way to proceed - sounds like deferring to transforms is preferable
21:13:38 <nikos> AmeliaBR: css transform spec references svg
21:13:42 <nikos> ... doesn't have a full definition
21:14:04 <nikos> heycam: perhaps person who added the issue thought incorrectly
21:14:06 <ed> http://dev.w3.org/fxtf/geometry/
21:14:08 <nikos> ed: think it's the geometry spec
21:14:25 <nikos> heycam: would suggest talking to Dirk about where these things should live
21:14:35 <nikos> bogdan: I'll follow up
21:14:42 <nikos> bogdan: Issue 21
21:14:49 <ed> "The DOMMatrix and DOMMatrixReadOnly interfaces replace the SVGMatrix interface from SVG [SVG11]."
21:14:56 <nikos> ... is there anything new with regards to svg 1.1 that we need to put here?
21:15:30 <nikos> heycam: there is a question in that issue 7 in the spec about whether the none value (added in tiny 1.2) should be included here
21:15:32 <nikos> ... not sure of the answer
21:15:45 <nikos> bogdan: sounds like answer is yes - just needs to be done
21:15:56 <nikos> ... hard to imagine the case where it wouldn't be true
21:16:08 <nikos> heycam: I'm not sure what the implementation status is
21:16:11 <pdr__> ed, DOMMatrix has faced resistance from implementations (Webkit and Blink) for performance concerns.
21:16:52 <nikos> AmeliaBR: if you say viewbox none I'm pretty sure every implementation would treat it as not having a viewbox attribute
21:16:56 <nikos> ... which is the result you want
21:17:09 <nikos> ... might fail validation but as far as what is displayed on screen the result is fine
21:17:15 <nikos> heycam: that makes it an easy decision to include it
21:17:40 <nikos> bogdan: sounds like we don't need the attribute table?
21:17:44 <nikos> heycam: we should have the attribute table
21:17:55 <nikos> ... that will define the lacuna value
21:17:57 <ed> pdr__, true, also in the issue we were discussing it wouldn't be sufficient to have DOMMatrix anyway, SVGTransformList is a list of "DOMMatrix"...
21:18:03 <nikos> bogdan: issue 23
21:18:17 <nikos> ... want to clarify the intent here?
21:18:54 <nikos> AmeliaBR: for shapes with width or height is zero we have disable rednering
21:19:00 <nikos> ... not sure if that's true for negative values
21:19:23 <nikos> Rossen: if I have a rectangle that is 1,1,-1,-1
21:19:30 <nikos> ... make it -2,-2
21:19:40 <nikos> ... a 2x1 rectangle spanning the origin
21:19:43 <nikos> ... is that valid?
21:19:50 <nikos> AmeliaBR: no - you can't use negative height and width
21:20:05 <nikos> ... I think it would be a neat feature, but it's currently an error
21:20:17 <nikos> shepazu: we could allow that to happen because there's no content that is counting on it being otherwise
21:20:29 <nikos> Rossen: not looking for things to add - just looking to resolve the issue
21:20:34 <nikos> ... so are we saying this is an error?
21:20:37 <Zakim> -nikos
21:21:23 <Zakim> +??P1
21:21:42 <nikos> Zakim, ??P1 is me
21:21:42 <Zakim> +nikos; got it
21:22:01 <nikos> ed: error processing rules is that we should render up to and including the element with the error
21:22:44 <nikos> AmeliaBR: what if you had nested SVGs and one had an error? you wouldn't render that and anything after in the containing file
21:23:20 <nikos> bogdan: issue 24
21:23:29 <nikos> bogdan: looks like the same as issue 21
21:23:50 <nikos> Rossen: why are we adding a table?
21:23:55 <nikos> heycam: every attribute in the spec needs a table
21:24:07 <nikos> ed: this chapter is particularly bad in defining attributes
21:24:57 <nikos> Rossen: 2 more issues in this chapter are waiting for further discussion
21:25:03 <nikos> ... one for chat with dirk, one for test case
21:25:07 <nikos> ... others are all actionable
21:25:21 <nikos> ... do you want to walk over the non-issues we've identified ?
21:25:26 <nikos> bogdan: I suggest doing that offline
21:26:48 <nikos> Topic: Rendering chapter issues
21:26:50 <ed> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Needing_discussion
21:28:04 <nikos> nikos: Should we keep the non normative text that jwatt wrote for the z-index feature?
21:28:11 <nikos> ... don't think it says anything that isn't said in the normative text
21:29:21 <nikos> nikos: I guess it's a general q about the svg 2 spec - do we want to have big blocks of non normative text?
21:29:39 <nikos> Tav: think having a description is useful
21:29:52 <nikos> nikos: what about the pattern of saying 'this is non-normative' and 'this is normative'
21:30:03 <nikos> heycam: having in a green box might be useful - but that would be a large block
21:30:49 <nikos> heycam: if you think the normative text + the examples explain everythign
21:30:54 <nikos> ... then I'd be alright with removing it
21:31:00 <nikos> nikos: that would be my feeling
21:31:09 <nikos> Tav: you should probably have a few lines introducing the concept
21:31:34 <nikos> nikos: 2.3 - rendering order introduces the concept
21:32:18 <nikos> Tav: I didn't see 2.3 - if it's repetitive then it's probably not needed
21:32:50 <nikos> resolution: remove non-normative text for z-index. keep examples and move to where appropriate
21:33:10 <nikos> Topic: Animation
21:33:20 <nikos> shepazu: in Sparta, they have some SVG animation stuff - thank you for putting that in
21:33:36 <shepazu> http://blogs.msdn.com/b/ie/archive/2015/03/18/rendering-engine-updates-in-march-for-the-windows-10-technical-preview.aspx
21:34:02 <nikos> bogdan: we still haven't introduced smil
21:34:09 <shepazu> https://status.modern.ie/csstransitionsanimationsforsvgelements
21:34:22 <nikos> shepazu: there has been a lot of heat and not a lot of light regarding smil
21:34:25 <nikos> ... on the mailing list
21:34:50 <nikos> ... my understanding is that the element based animation syntax will be supported by the animation model
21:34:52 <nikos> birtles: right
21:35:03 <nikos> shepazu: and all this gloom and doom about smil is not neccessary
21:35:09 <nikos> birtles: I believe so
21:35:25 <nikos> ... think part of the concern is that google says they're not interested in extending the feature set of element based animation
21:35:30 <nikos> shepazu: ok, but old stuff will work
21:35:39 <nikos> birtles: though there was some indication there might be slight changes in the behaviour
21:35:48 <nikos> ed: that's in the engine itself. doesn't have to affect content
21:35:54 <nikos> shepazu: I'm going to make a wiki page that spells this out
21:36:10 <nikos> ... think if we're going to have this element based syntax it should be in a spec right?
21:36:27 <nikos> birtles: yes. I started writing a spec called 'Animation Elements'
21:36:32 <nikos> ... don't have much time to work on it at the moment
21:36:45 <nikos> ... main problem with the draft is that I started adding extra features
21:36:46 <Zakim> -nikos
21:36:52 <AmeliaBR> https://svgwg.org/specs/animation-elements/
21:37:56 <AmeliaBR> ScribeNick: AmeliaBR
21:38:10 <Zakim> -Thomas_Smailus
21:38:15 <Zakim> -Doug_Schepers
21:38:16 <Zakim> -[Microsoft]
21:38:17 <Zakim> -ed
21:38:18 <Zakim> -birtles
21:38:18 <Zakim> -stakagi
21:38:20 <AmeliaBR> Doug: ok, I'm going to set up a wiki page, to try to clarify our current strategy
21:38:22 <Zakim> -Tav
21:38:24 <Zakim> -heycam
21:38:44 <nikos> RRSAgent, make minutes
21:38:44 <RRSAgent> I have made the request to generate http://www.w3.org/2015/03/19-svg-minutes.html nikos
21:39:50 <Zakim> -AmeliaBR
21:39:51 <Zakim> GA_SVGWG()4:30PM has ended
21:39:51 <Zakim> Attendees were ed, krit, stakagi, nikos, Thomas_Smailus, Rossen, birtles, Tav, heycam, AmeliaBR, Doug_Schepers
21:45:31 <shepazu> ed, will Opera do the same as Chrome with SMIL?
22:22:01 <jcraig> jcraig has joined #svg
23:00:02 <jcraig_> jcraig_ has joined #svg
23:54:08 <jcraig> jcraig has joined #svg
23:55:12 <Zakim> Zakim has left #svg