SVG Working Group Teleconference -- 19 Mar 2015

<trackbot> Date: 19 March 2015

<scribe> scribenick: nikos

<scribe> Scribe: Nikos

SVG2 (and modules) publication status/deadline

ed: I was wondering if we had set a date for when to publish SVG 2 ?
... and the associated modules

Rossen: are you talking about the modules or SVG 2?

ed: At the F2F we said we'd publish the split out modules and chapters along with the svg 2 spec
... wondering how far along we are?
... is what we have now sufficient?

Rossen: if we're talking about publishing a bunch of FPWD and a refreshed WD of SVG 2
... I don't see why we should hold off

heycam: we agreed to do that - I was going to take care of it
... I think the date we set is coming up in the next week
... the only thing is I want to do the splitting of the stroking features
... that's not so straight forward

ed: so do we have a set date for last edits?

heycam: If you really want them in then the end of this week
... Not sure when I'll do the bundling but probably early next week

ed: so expect to publish Thursday next week?

heycam: yes
... that will be the main spec, the marker module, and the stroking module

SVG 2 open issue discussion

bogdan: we did iniital pass through of co-ord system and units chapter
... want to know if it's the right approach
... we put everything that does need discussing separately
... does that make sense so far?

ed: yes I think so

Rossen: we can jump into discussion and allow everyone to review the not an issue and actionable bits and discuss later
... or we can spend some time walking through the 'not an issue and actionable' first and then get into discussion
... imo the wg time will be spent jumping into the issues that need discussion
... sound good?

heycam: yes - we've been doing that for the last couple of weeks where people have put their issues up for assessment
... many chapters now only have issues that need discussion
... but require chapter manager to do work or investigation before they can be discussed

Rossen: let's dive into open issues on co-ordinates and units then

bogdan: issue 5 - effect of transform matrix on sibling element

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Coordinate_Systems.2C_Transformations_and_Units_.28Bogdan.29

bogdan: proposal is to move this to the attributes section
... doesn't look like this is specific to transforms
... are we missing something here?

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
... same behaviour is going to occur for transform property
... so not sure why that section would have been removed

bogdan: that's the question - is there anything specific to do with transforms? if so we should put it back
... otherwise we should move it to somewhere more general

heycam: think it would be good to have wording describing how transform affects other attributes on the element

bogdan: so bring back the removed part?

heycam: yes

bogdan: issue 6 - about the blue box for attributes in general - a generic question
... doesn't look like we need it in this case
... proposal is to remove it

heycam: agree it should be removed
... 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
... just point to the other spec - like in hte green box

bogdan: resolved that we don't need a resolution on minor editorial changes - just put it in the commit message so it's trackable

Tav: noticed css 3 transform spec is in the green note - is that how we should do it?
... 'see other specs' should be in green?

heycam: I'll find an example

Tav: there's a mixture of styles

Rossen: bikeshed will usually link automatically and generate the reference table

heycam: think we'd like to switch to using bikeshed but there's some issues at the moment with features that aren't supported

<heycam> https://svgwg.org/svg2-draft/painting.html#VisibilityControl

heycam: the pattern I've been using is this "See the blah specification for the definitions of blah"
... and name the section 'The effect of the so and so property'
... to distinguish that we're not defining the property here

Tav: that's awfully wordy

Rossen: only makes it worse for the writers

AmeliaBR: so you'd have 'The effect of the transform on svg layout properties'?
... so a kind of a note section?

heycam: it is a kind of a note
... we usually have the property name, then colon, then a short description of the property
... in this case the only difference is to include 'The effect of'

Tav: personally I don't think it's neccessary
... but don't care that much

heycam: I like seeing from the TOC here is something we define, and here is something we reference

Rossen: ok sounds good

bogdan: Issue 9
... more or less the same as issue 5
... suggest we follow the same resolution and update the link if we bring the paragraph back
... it's also about the effect of the transform attribute

heycam: sounds fine

bogdan: Issue 10
... it appears we won't need this
... but would like to hear from the group

heycam: think someone put that issue there because I haven't seen anyone use defer

ed: my preference is to ignore it

AmeliaBR: the only place it's useful is when embedding svg images using an svg image element
... usually you use 'use' elements rather than images

Smailus: we have a use case at Boeing for putting svg documents in svg documents

AmeliaBR: would it be useful to use the defer setting ?

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

Rossen: not sure I follow how that correlates?

Smailus: what's the key question?

AmeliaBR: is defer useful on preserveAspectRatio

Smailus: can't speak to that - don't think we're using it that way

AmeliaBR: is it difficult to support defer on preserveAspectRatio in implementations?
... in an html document this is used automatically

Rossen: I was thinking the opposite - the aspect ratio preservation is assumed
... and I don't know when you'd want to have a non ratio preserved image
... does that make sense?
... for implementation you're already doing that for images
... don't see non aspect preserving scenario being a useful use case

AmeliaBR: the idea you can override the setting on the file you're embedding?
... one case might be alignment
... file embedding has cetner
... and you want it left aligned

Rossen: what does that have to do with aspect ratio?

AmeliaBR: preserveAspectRatio does both
... whether you preserve and if you are how do you align within the space

<heycam> xMinYMin vs xMidYMix for example

<heycam> *Mid

Rossen: can you explain what you mean by alignment in here?
... even if you preserve the aspect ratio you always have an origin where the image is going to be rendered
... not sure what alignment you are referring to exactly

AmeliaBR: in your main file you have a certain area described for 'draw the image in this space'
... but embedded image doesn't fit in that space
... if you're preserving aspect ratio you're not stretching to fit that space
... so the question is how you align it ?

Rossen: there's no aligment here . there's just an origin where the image goes
... assume you have a square and a 1x2 svg that has to go inside
... when the svg is scaled with ratio preservation half the square to the left where the origin is
... the other half will be empty
... there's no way to align the image that I know of
... are we trying to invent something different here?

AmeliaBR: think we have a language mix up
... by align I'm talking about xMid yMax, etc

Rossen: these would be applied as they would, regardless of the aspect ratio

ed: so what do we do - investigate further?
... can we decide something here?

bogdan: don't think we need an action. if it's there it should work
... can discuss dropping later

ed: think we should maybe ask if there's someone that has use cases
... put it to the list
... raise again in future

bogdan: i can do that

<scribe> ACTION: bogdan to create test case for preserveAspectRatio defer [recorded in http://www.w3.org/2015/03/19-svg-minutes.html#action01]

<trackbot> Created ACTION-3773 - Create test case for preserveaspectratio defer [on Bogdan Brinza - due 2015-03-26].

bogdan: issue 17
... need a line for mesh gradients?
... so mesh gradient owner needs to add this?

Tav: can give me an action. It's going to take some thought

<scribe> ACTION: Tav to come up with solution for issue 17 in co-ordinates and units [recorded in http://www.w3.org/2015/03/19-svg-minutes.html#action02]

<trackbot> Created ACTION-3774 - Come up with solution for issue 17 in co-ordinates and units [on Tavmjong Bah - due 2015-03-26].

bogdan: Issue 18
... it's not clear

AmeliaBR: is there going to be a way to set object bounding boxes to use the other types of bounding boxes?

heycam: similar to what we discussed last week relating to Paul's request on the list

AmeliaBR: it's not necessarily either, or
... the issue itself seems to be just 'reference the definition and how it's calcualted'

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'
... next is issue 20

bogdan: that should be a comment at the end

<ed> https://svgwg.org/svg2-draft/coords.html#InterfaceSVGTransformList

bogdan: is this something specific we need to add or can we just defer to CSS transforms?

heycam: dirk not here, but pretty sure all this dom transform stuff got added to css transforms
... so shouldn't need to define it
... but person doing the editing should check
... if it is then we don't want to duplicate the wording

<AmeliaBR> http://www.w3.org/TR/css3-transforms/#transform-attribute-dom

bogdan: will clarify with the editor about what is the best way to proceed - sounds like deferring to transforms is preferable

AmeliaBR: css transform spec references svg
... doesn't have a full definition

heycam: perhaps person who added the issue thought incorrectly

<ed> http://dev.w3.org/fxtf/geometry/

ed: think it's the geometry spec

heycam: would suggest talking to Dirk about where these things should live

bogdan: I'll follow up
... Issue 21

<ed> "The DOMMatrix and DOMMatrixReadOnly interfaces replace the SVGMatrix interface from SVG [SVG11]."

bogdan: is there anything new with regards to svg 1.1 that we need to put here?

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
... not sure of the answer

bogdan: sounds like answer is yes - just needs to be done
... hard to imagine the case where it wouldn't be true

heycam: I'm not sure what the implementation status is

<pdr__> ed, DOMMatrix has faced resistance from implementations (Webkit and Blink) for performance concerns.

AmeliaBR: if you say viewbox none I'm pretty sure every implementation would treat it as not having a viewbox attribute
... which is the result you want
... might fail validation but as far as what is displayed on screen the result is fine

heycam: that makes it an easy decision to include it

bogdan: sounds like we don't need the attribute table?

heycam: we should have the attribute table
... that will define the lacuna value

<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"...

bogdan: issue 23
... want to clarify the intent here?

AmeliaBR: for shapes with width or height is zero we have disable rednering
... not sure if that's true for negative values

Rossen: if I have a rectangle that is 1,1,-1,-1
... make it -2,-2
... a 2x1 rectangle spanning the origin
... is that valid?

AmeliaBR: no - you can't use negative height and width
... I think it would be a neat feature, but it's currently an error

shepazu: we could allow that to happen because there's no content that is counting on it being otherwise

Rossen: not looking for things to add - just looking to resolve the issue
... so are we saying this is an error?

ed: error processing rules is that we should render up to and including the element with the error

AmeliaBR: what if you had nested SVGs and one had an error? you wouldn't render that and anything after in the containing file

bogdan: issue 24
... looks like the same as issue 21

Rossen: why are we adding a table?

heycam: every attribute in the spec needs a table

ed: this chapter is particularly bad in defining attributes

Rossen: 2 more issues in this chapter are waiting for further discussion
... one for chat with dirk, one for test case
... others are all actionable
... do you want to walk over the non-issues we've identified ?

bogdan: I suggest doing that offline

Rendering chapter issues

<ed> https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment#Needing_discussion

nikos: Should we keep the non normative text that jwatt wrote for the z-index feature?
... don't think it says anything that isn't said in the normative text
... I guess it's a general q about the svg 2 spec - do we want to have big blocks of non normative text?

Tav: think having a description is useful

nikos: what about the pattern of saying 'this is non-normative' and 'this is normative'

heycam: having in a green box might be useful - but that would be a large block
... if you think the normative text + the examples explain everythign
... then I'd be alright with removing it

nikos: that would be my feeling

Tav: you should probably have a few lines introducing the concept

nikos: 2.3 - rendering order introduces the concept

Tav: I didn't see 2.3 - if it's repetitive then it's probably not needed

resolution: remove non-normative text for z-index. keep examples and move to where appropriate

Animation

shepazu: in Sparta, they have some SVG animation stuff - thank you for putting that in

<shepazu> http://blogs.msdn.com/b/ie/archive/2015/03/18/rendering-engine-updates-in-march-for-the-windows-10-technical-preview.aspx

bogdan: we still haven't introduced smil

<shepazu> https://status.modern.ie/csstransitionsanimationsforsvgelements

shepazu: there has been a lot of heat and not a lot of light regarding smil
... on the mailing list
... my understanding is that the element based animation syntax will be supported by the animation model

birtles: right

shepazu: and all this gloom and doom about smil is not neccessary

birtles: I believe so
... think part of the concern is that google says they're not interested in extending the feature set of element based animation

shepazu: ok, but old stuff will work

birtles: though there was some indication there might be slight changes in the behaviour

ed: that's in the engine itself. doesn't have to affect content

shepazu: I'm going to make a wiki page that spells this out
... think if we're going to have this element based syntax it should be in a spec right?

birtles: yes. I started writing a spec called 'Animation Elements'
... don't have much time to work on it at the moment
... main problem with the draft is that I started adding extra features

<AmeliaBR> https://svgwg.org/specs/animation-elements/

<AmeliaBR> ScribeNick: AmeliaBR

Doug: ok, I'm going to set up a wiki page, to try to clarify our current strategy

- DRAFT -

SVG Working Group Teleconference

19 Mar 2015

Attendees

Contents

SVG2 (and modules) publication status/deadline

SVG 2 open issue discussion

Rendering chapter issues

Animation

Summary of Action Items

Scribe.perl diagnostic output