Minutes, 12 June 2014 SVG WG telcon

Minutes:

      http://www.w3.org/2014/06/12-svg-minutes.html

as text below:

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                    SVG Working Group Teleconference

12 Jun 2014

   [2]Agenda

      [2] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.html

   See also: [3]IRC log

      [3] http://www.w3.org/2014/06/12-svg-irc

Attendees

   Present
          birtles, heycam, ed, stakagi, cabanier, [IPcaller],
          +1.415.832.aaaa, Tav, krit

   Regrets
          nikos

   Chair
          Cameron

   Scribe
          birtles

Contents

     * [4]Topics
         1. [5]Missing 'turn' unit in SVGAngle
         2. [6]Aiming for SVG Integration Last Call by April 2015
         3. [7]Moving definition of getSVGDocument to HTML
         4. [8]Geometry interfaces: Replace isIdentity?
         5. [9]Geometry interfaces: various issues
         6. [10]Geometry interfaces: replacee translateBy by
            translateSelf for better expressiveness?
         7. [11]F2F in London
     * [12]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 12 June 2014

   <scribe> scribenick: birtles

   <scribe> scribe: birtles

Missing 'turn' unit in SVGAngle

   <ed> [13]http://www.w3.org/2013/07/11-svg-minutes.html#item05

     [13] http://www.w3.org/2013/07/11-svg-minutes.html#item05

   ed: I spoke with Dirk about this and we already had a
   resolution for this
   ... we decided not to add new IDL constants for the old SVG DOM
   ... so the previous resolution wasn't exactly clear what we
   should do with new units for example
   ... for parts of the DOM that expect a unit
   ... I take this to mean we don't want to change any of the
   behaviour
   ... i.e. act as if those new units weren't supported when you
   inspect the SVG DOM

   heycam: so you'd get the unknown value when you look up the
   unit?

   ed: and if you use valueAsString you'd get the default value as
   if the unit wasn't supported
   ... since the new resolution only concerned not adding new IDL
   constants
   ... I wanted to make sure the rest was covered

   heycam: we've had a few instances of this kind of thing of not
   having a new constant in the IDL
   ... but these issues that you bring up now show that it's kind
   of awkward
   ... it makes those interfaces completely useless
   ... I wonder what we should do if in the future we don't go
   ahead with the new SVG DOM proposal
   ... in that case perhaps we should extend these old interfaces
   ... or should we say you can only use get/setAttribute for
   these new unit types

   krit: most of these libraries just use get/setAttribute
   ... most of attributes get presentation properties and then
   they can use 'style' for examples to set the value
   ... and get the string

   <heycam> element.style.someAngledProperty = '2turn'

   krit: with, of course, the units
   ... I don't want to shut the door on the SVG DOM but maybe we
   should wait until we decide what we want to do with the SVG DOM
   ... but keep it as it is for now

   heycam: so keep things exactly as they are for now until we
   finally decide what we're doing with the DOM
   ... then we can add the constants or not depending on which
   course we take
   ... it would be great to have that behavior defined in the spec
   (re: when you use one of the new units)

   ed: I think it is defined already
   ... it's just the angle interface is not so useful
   ... it basically just behaves as if the unit was not supported

   heycam: ok, I guess the existing spec text is sufficient

   ed: yes, I think it is, but I just wanted to confirm that's
   what we wanted
   ... SVGAngle is not so useful but the same issue applies to
   SVGLength and SVGTransform

   heycam: I'm ok with that

   ed: I think the existing resolution and spec text is enough but
   just wanted to confirm

Aiming for SVG Integration Last Call by April 2015

   heycam: I was speaking with Vlad who works on the OpenType font
   format spec which is the spec with the SVG table now
   ... we've been discussing what to do about the reference to the
   SVG Integration spec
   ... April 2015 is basically the last point where they can
   update references in the spec
   ... so if the SVG Integration spec can be in last call by then,
   then it's fine to leave it in as a normative reference
   ... I need to check if that would mean the LC URL would be
   baked in, or if we could use the more general URL
   ... but that's the timeline
   ... so I wanted to see if we can have something usefully at LC
   by then?

   krit: I think we should try to do it before then

   heycam: there is a period for final comments for the MPEG group
   which finishes in about 1.5 days
   ... I'll send in a few suggested wording tweaks including
   suggestions about the SVG reference

Moving definition of getSVGDocument to HTML

   ed: I think I got this from Simon Pieters and I think we should
   go ahead and let HTML define getSVGDocument
   ... basically removing it from the SVG spec

   heycam: so getSVGDocument was a function the Adobe player
   exposed on the <object> and <embed> elements when they
   referenced an SVG document
   ... as a way of getting to the SVG document DOM
   ... since then contentDocument has been added
   ... and people should use that, so getSVGDocument is a bit
   useless
   ... getSVGDocument is defined to be the same thing as
   contentDocument but it isn't precise
   ... it's probably easier to define in HTML where definitions
   about browsing contexts etc. are available

   ed: I think contentDocument doesn't work for <embed> elements

   heycam: does getSVGDocument work?

   ed: yes, I believe so

   heycam: somebody asked me again recently what was the status of
   this and whether it was ok for the HTML spec to add it and us
   to remove it
   ... any objections?

   ??: no

   RESOLUTION: SVG2 will remove the definition of getSVGDocument
   and it will move to the HTML spec

Geometry interfaces: Replace isIdentity?

   <krit> [14]http://dev.w3.org/fxtf/geometry/

     [14] http://dev.w3.org/fxtf/geometry/

   krit: we had some discussions about isIdentity and to have
   something more reliable like hasTransform which basically
   returns false if there are no transforms on the matrix
   ... so it's more reliable because something that has not been
   transformed is definitely not identity
   ... but at the end I think people thought it was more useful to
   have isIdentity even if might return false sometimes where it
   could return true
   ... I think at the end we agreed on the behavior but I just
   wanted to tell the group about it
   ... in the end isIdentity is used for optimizations so it just
   means the code might not run as optimally as it could
   ... there are cases where you transform something and transform
   it back and you might end up returning false in that case
   ... but hasTransform would also return false then
   ... isIdentity would return true more often than hasTransform

   heycam: so how is this different from what is currently
   defined?

   krit: it's not

   cabanier: hasTransform never made it into the spec

   heycam: so it just checks for 0s and 1s?

   krit: yes, the simple-minded way

Geometry interfaces: various issues

   [15]http://lists.w3.org/Archives/Public/public-fx/2014AprJun/01
   64.html

     [15] http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0164.html

   krit: is2D is the next issue
   ... after discussion we decided to make this track
   transformations
   ... if you have transforms that are 3D it will return false
   ... if all transforms are 2D it will return true

   heycam: so it's a flag that once it becomes false it stays that
   way?

   krit: right
   ... this is something that Benoit preferred and I'm fine with
   it too

   heycam: so it requires you to store extra state in the object

   cabanier: but usually you just allocate a 2D matrix until a 3D
   transformation is made and then you swap it out

   heycam: so you'd have some state there already

   krit: I think that was the only open issue there
   ... the use case came from when you have rotation points around
   the x-axis
   ... if you swap to 3D and back for one frame that would be odd

   heycam: in what cases do you expect authors to use it?

   krit: it might be the result of some calculation that you need
   to check if you need to switch to 3D calculations or not
   ... I definitely want people to view the spec and send
   objections to the list
   ... Geometry interfaces: replacee translateBy by translateSelf
   for better expressiveness?

Geometry interfaces: replacee translateBy by translateSelf for better
expressiveness?

   krit: people found translateBy confusing, we think
   translateSelf is easier to understand

   heycam: I agree

   krit: the other suggestion was 'this' instead of 'self'

   heycam: I'm not sure which I prefer

   krit: another topic which may need agreement of WG was whether
   we should have 'invert' or 'invertSelf'
   ... SVG has 'inverse'
   ... but 'invertSelf' is more consistent with the other methods

   heycam: what's the plan for aligning SVGMatrix and DOMMatrix?
   ... does SVGMatrix inherit from DOMMatrix or alias it?

   krit: alias it

   heycam: in that case, will there still be an Inverse method for
   compatibility

   ed: SVG's Inverse returns a new matrix I think

   krit: yes
   ... so any objections to adding 'invertSelf'

   heycam: it seems bad to have 'invert' and 'inverse'

   cabanier: it would be 'inverse' and 'invertSelf'

   heycam: I though Dirk was suggesting we have 'invert' for
   consistency

   krit: no, the question was do we want to rename 'invert' to
   'invertSelf'

   heycam: yes, definitely
   ... do you think it's a silly idea to have 'invert' as well?

   krit: why?

   heycam: for completeness and matching the pattern

   <heycam> 'inverse', 'invert', 'invertSelf'

   <heycam> where inverse means the same as invert

   heycam: I would probably shy away from having all 3 but it's
   also tempting to have for completeness

   krit: we keep inverse, that's for sure
   ... would invert modify itself?
   ... I'm not a fan of adding things for completeness

   heycam: ok, we can add it later

   cabanier: we can always add it later

   heycam: the other matrix interfaces you want to have
   compatibility with, MSMatrix, WebkitMatrix etc., what do they
   have on them?

   <cabanier>
   [16]https://developer.apple.com/library/safari/documentation/Au
   dioVideo/Reference/WebKitCSSMatrixClassReference/WebKitCSSMatri
   x/WebKitCSSMatrix.html

     [16] https://developer.apple.com/library/safari/documentation/AudioVideo/Reference/WebKitCSSMatrixClassReference/WebKitCSSMatrix/WebKitCSSMatrix.html

   heycam: is it a goal to be compatible with them or just to have
   the same features

   krit: it would be good to be compatible. Both have inverse,
   just like SVGMatrix

   heycam: do they have the other methods that modify the same
   object?

   krit: no, they only have the methods that return a new object

   cabanier: WebKitCSSMatrix has setMatrixValue

   krit: I didn't add it because it seems to be redundant
   ... with the constructor that also takes a string

   heycam: so you couldn't modify an existing object by giving it
   a value using a string

   krit: yes, that's correct
   ... if there's a need for that, we'll add it then

   cabanier: you don't have any plans to alias WebKitCSSMatrix to
   DOMMatrix right?

   krit: actually, yes I'd like to do that
   ... but I'd still like to make setMatrixValue not part of
   DOMMatrix
   ... not sure yet how I will do that, but somehow

   cabanier: (checking github to see if anyone uses
   setMatrixValue)

   krit: Rik mentioned that he would like to make isIdentity and
   is2D readonly attributes
   ... it's just a cosmetic issue
   ... I'd like to make them the same (i.e. both attributes or
   both methods)
   ... I'm leaning towards methods
   ... attributes seem to suggest something is stored whereas
   methods suggest checking something
   ... it's not a hard-and-fast rule but that's how I understand
   it
   ... what does the group think?

   heycam: from my intuition I think attributes are right
   ... I think it's fine to have attributes that reflect some
   state of the object

   ed: I think I agree with Cameron

   krit: ok, we'll change it to attributes

   cabanier: I found some places where setMatrixValue are used

   krit: should we add it then, or try to avoid it?

   heycam: I think it would be handy to be able to assign with a
   string value
   ... is it also on MSCSSMatrix

   krit: yes

   heycam: then I'd say go with that

   krit: the last question, should the in-place transformations
   return the same object?

   <cabanier> for instance:
   [17]https://github.com/yui/yui3-gallery/blob/5b0e2d507be5916560
   aebae04f8a74d4211af402/src/gallery-node-transform2d/js/node-tra
   nsform2d.js#L20

     [17] https://github.com/yui/yui3-gallery/blob/5b0e2d507be5916560aebae04f8a74d4211af402/src/gallery-node-transform2d/js/node-transform2d.js#L20

   krit: for example translateSelf, changes it in place
   ... should it return the same object?

   <cabanier> should the xxxSelf function return the object?

   <krit> everything is void atm

   <cabanier> so m.translateSelf(...).scaleSelf(...)

   <krit> matrix.translateSelf()

   <krit> matrix.scaleSelf()

   <krit> matrix.translateSelf()

   krit: the current return value of these is void

   <krit> change this to

   <krit> m.translateSelf(...).scaleSelf(…).translateSelf(...)

   krit: I would like to change it so it returns the object and
   you can chain like this ^

   birtles: why would you not do that?

   heycam: I'm not sure I'm a fan of that kind of chaining style
   approach in general but I think it makes sense in this case
   ... since I think you often want to do these operations in a
   row

   birtles: promises use a lot of chaining

   <ed> why would one not do m.stringSetter = "translate...scale
   ... translate"

   ed: repeating "self" a lot is a bit redundant

   krit: that's because we're dealing with the legacy of SVGMatrix
   which took the short names

   heycam: you could change 'self' to 'me' :)
   ... translateMe

   krit: the benefit of 'me' is it's shorter (same as 'by')

   heycam: I think 'self' is better

   krit: I will make all these changes
   ... I would like to have people review the spec
   ... I'd like people to have a look after I've made the changes
   too
   ... I will have it done today or so
   ... I would like to ask for last call in the next week or the
   week after
   ... it depends if working group members want more time for
   review
   ... just let me know me next week if you need more time or not
   ... I'll send a mail to the WG and to www-style as well

F2F in London

   heycam: I've booked a room for the F2F
   ... I need to tell the office person a few weeks beforehand
   about numbers/dietary requirements so plenty of time still
   ... Chris sent up a registration form for it
   ... I'll look into hotels too

   <heycam> /me birtles do you wear a headset?

   <krit> my

   apologies: Nikos

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [18]scribe.perl version
    1.138 ([19]CVS log)
    $Date: 2014-06-12 14:04:24 $
     __________________________________________________________

     [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [19] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/by/me/
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Default Present: birtles, heycam, ed, stakagi, cabanier, [IPcaller], +1.
415.832.aaaa, Tav, krit
Present: birtles heycam ed stakagi cabanier [IPcaller] +1.415.832.aaaa T
av krit
Agenda: [21]http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.htm
l
Found Date: 12 Jun 2014
Guessing minutes URL: [22]http://www.w3.org/2014/06/12-svg-minutes.html
People with action items:

     [21] http://lists.w3.org/Archives/Public/www-svg/2014Jun/0038.html
     [22] http://www.w3.org/2014/06/12-svg-minutes.html


   [End of [23]scribe.perl diagnostic output]

     [23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 12 June 2014 14:09:14 UTC