Minutes, 16 March 2015 SVG WG telcon

Formatted minutes at
http://www.w3.org/2015/03/19-svg-minutes.html

and below as text


SVG Working Group Teleconference
19 Mar 2015

    [2]Agenda

       [2] https://lists.w3.org/Archives/Public/www-svg/2015Mar/0081.html

    See also: [3]IRC log

       [3] http://www.w3.org/2015/03/19-svg-irc

Attendees

    Present
    Regrets
    Chair
           SV_MEETING_CHAIR

    Scribe
           Nikos

Contents

      * [4]Topics
          1. [5]SVG2 (and modules) publication status/deadline
          2. [6]SVG 2 open issue discussion
          3. [7]Rendering chapter issues
          4. [8]Animation
      * [9]Summary of Action Items
      __________________________________________________________

    <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>
    [10]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assess
    ment#Coordinate_Systems.2C_Transformations_and_Units_.28Bogdan.
    29

      [10] 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>
    [11]https://svgwg.org/svg2-draft/painting.html#VisibilityContro
    l

      [11] 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
    [12]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
    [13]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>
    [14]https://svgwg.org/svg2-draft/coords.html#InterfaceSVGTransf
    ormList

      [14] 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>
    [15]http://www.w3.org/TR/css3-transforms/#transform-attribute-d
    om

      [15] 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> [16]http://dev.w3.org/fxtf/geometry/

      [16] 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>
    [17]https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assess
    ment#Needing_discussion

      [17] 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>
    [18]http://blogs.msdn.com/b/ie/archive/2015/03/18/rendering-eng
    ine-updates-in-march-for-the-windows-10-technical-preview.aspx

      [18] 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>
    [19]https://status.modern.ie/csstransitionsanimationsforsvgelem
    ents

      [19] 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> [20]https://svgwg.org/specs/animation-elements/

      [20] 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

Summary of Action Items

    [NEW] ACTION: bogdan to create test case for
    preserveAspectRatio defer [recorded in
    [21]http://www.w3.org/2015/03/19-svg-minutes.html#action01]
    [NEW] ACTION: Tav to come up with solution for issue 17 in
    co-ordinates and units [recorded in
    [22]http://www.w3.org/2015/03/19-svg-minutes.html#action02]

    [End of minutes]

The information contained in this email message and any attachments may be confidential and may also be the subject to legal professional privilege. If you are not the intended recipient, any use, interference with, disclosure or copying of this material is unauthorised and prohibited. If you have received this email in error, please immediately advise the sender by return email and delete the information from your system.

Received on Thursday, 19 March 2015 21:44:05 UTC