minutes, 16 July 2015 SVG WG telcon

Minutes for today’s meeting:



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

                               - DRAFT -

                    SVG Working Group Teleconference

16 Jul 2015


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

   See also: [3]IRC log

      [3] http://www.w3.org/2015/07/16-svg-irc


          Cameron, Tav, AmeliaBR, Rossen, present, Nikos, stakagi


          Cameron, Rossen


     * [4]Topics
         1. [5]Canvas2D API
         2. [6]Fitting mesh in a bbx
     * [7]Summary of Action Items

   <trackbot> Date: 16 July 2015

   <heycam> Scribe: Cameron

   <Rossen> Scribe: Rossen

   heycam: Topic is checkpoint of progress
   ... quick attendance check - everyone seems to be here

   chatter about the "usefullness" of webex - everyone seems to be

   heycam: checkpoint was spposed to be - how is everyone tracking
   towards finishing for f2f as well as a reminder that we need to
   be done by then
   ... first one is Rendering chapter
   ... how is that tracking


      [8] https://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment

   nikos: comming along OK
   ...: added a few checkins yesterday
   ... identified a change from 1.1 in respect to viewports of
   ... the section is ready for review
   ... needs to verify/finish clipping in the same chapter... not
   a lot left to do

   heycam: next is one of mine - Data Types
   ... I haven't done anything or on any of the other chapters
   ... planing to work on all of this next week
   ... worried about the ones listed as "needs discussion" - not
   sure what was already covered and what not
   ... will check minutes and bring back issues as needed
   otherwise will

   AmeliaBR: there's an open issue with transforms and how they
   work/integrate with CSS

   heycam: recalls discussing transforms to elements
   ... the intent was to add a method in the Geometry spec for
   methods that work on all elements thus SVG will not be handled
   in a different way.

   <AmeliaBR> [9]http://dev.w3.org/fxtf/geometry/#DOMMatrix

      [9] http://dev.w3.org/fxtf/geometry/#DOMMatrix

   AmeliaBR: currently there's only methods for handling matrix
   maniputlations but that's about it

   heycam: again, no progress on my end but promisse to do it next
   ... next checkpoint is Paths - this is ready and should be set
   to 5 now

   Tav: I just noticed something about bearing there

   heycam: recalls a discussions in AUS f2f resolving to move the
   catmulrom curves but not beagrings

   AmeliaBR: makes sense - prefers to see bearings sooner than

   shepazu: inserts inapropriate joke

   heycam: next chapter for review is Text

   Tav: have been doing a number of changes
   ... has a plan to finish but is missing one seciton from heycam

   heycam: sorry, will get it to you soon

   AmeliaBR: promisses to review the changes
   ... there was a discussion on the mailling list about text on a
   path and a stretch mode - calls for a better definition and
   hopfully implementation

   Tav: if you want it - write it :)

   shepazu: but this will be "at risk"

   AmeliaBR: it's not really new but it isn't implemented and is
   important for i18n

   shepazu: recalls an impl from Opera in Presto

   Tav: there was a problem that isn't speced well

   shepazu: interoperable?

   AmeliaBR: don't know

   shepazu: interop is what matters

   AmeliaBR: will try to get feedback from implementers to see
   what would be easier
   ... straight line stretch will be probably easier to implement
   ... will look for algos

   shepazu: sounds like a stretch goal for SVG 2

   heycam: thank you for the update Tav
   ... next is Embeded content - Bogdan?

   BogdanBrinza: haven't done anything for anything but promisse
   to have them done by end of July

   heycam: so end of July?

   BogdanBrinza: yes

   heycam: next is Paining - same as others that are assigned to
   ... next is Paint Servers

   Tav: made some progress
   ... want to discuss open issues about how to fit a mesh inside
   ... there are few things that needs ed help with
   ... the content model for hatches needs to be reviewd
   ... sees some inconsistency with other modules

   heycam: not sure about ed's availability so feel free to reach
   out to me instead
   ... next is Interactivity - ed
   ... not many issues on the wiki about this one
   ... will have to wait for ed
   ... next is Linking

   AmeliaBR: I have few outstanding integration actions
   ... not sure if BogdanBrinza has been doing anything else with

   BogdanBrinza: no
   ... will be done with the rest of the spec work

   heycam: last is Animation
   ... since Brian is not here and not sure if he has time for it

   AmeliaBR: wasn't the plan be to move the chapter to its own

   Rossen: yes that was the POR

   BogdanBrinza: I'll try to do the split off

   heycam: advices that this might be a lot of work
   ... shepazu you had some issues you wanted to discuss?

   shepazu: yes, it was about canvas2d

Canvas2D API

   <AmeliaBR> [10]http://www.w3.org/TR/2dcontext/

     [10] http://www.w3.org/TR/2dcontext/

   shepazu: I was talking with PLH about future plans for HTML
   ... he noteed that Canvas2D API has no clear WG
   ... it will possibly move to a new IG

   BogdanBrinza: general Canvas2D API or path API?

   shepazu: both
   ... PLH was noting that there are a lot of similarities btwn
   the SVG and Canvas2D API
   ... he asked if we can own the Canvas2D API space?

   Rossen: yes, as soon as we ship SVG 2

   AmeliaBR: it's really more of a graphics area

   BogdanBrinza: notes that one is retained and the other is
   declarative from impl POV
   ... thus the abcking models are quite different

   shepazu: the question is how much are they related but who owns
   the work?
   ... alternative is the whole "web platform thing"...
   ... since there won't be HTML WG PLH wants to move it to SVG WG

   heycam: wornders how working with whatwg is going to be etc.

   shepazu: there is no whatwg editor at the moment for either
   HTML or Canvas2D

   nikos: The mailing lists are very quiet - why?

   shepazu: not much being done at the moment

   nikos: likes the general idea and thinks that Canon might be
   able to contribute

   shepazu: summarizes that we are open to the idea but we want to
   prioritize SVG2
   ... what if we park it at SVG but encourage th ecurrent authors
   to join and work on it

   Rossen: is still opposed to the idea based on the fact that
   we'll be spending time for things that don't contribute to
   finalizing SVG

   BogdanBrinza: this doesn't seem to align with the charter of
   declarative graphics
   ... perhaps a Graphics rendering TF will be better

   [discussion about how appropriate this to the SVGWG]

   shepazu: any objections other than Microsoft?

   heycam: no objections but it should be a separate TF
   ... if it is more of an administrative move then fine, but not
   if it means who are the people who work on this

   AmeliaBR: it would be great to have the new people join

   shepazu: it will be better from a11y POV as well

   heycam: with 11 mins left, Tav floor is yours

Fitting mesh in a bbx

   Tav: suggested at previous f2f to not use bbox for fitting a

   AmeliaBR: thought that we can just use 0-1 coords

   heycam: so the question was about "how to treat the objects
   ... in respect to the mesh

   AmeliaBR: I did suggest to use a vbox pattern

   <Tav> [11]http://tavmjong.free.fr/SVG/PSERVERS/

     [11] http://tavmjong.free.fr/SVG/PSERVERS/

   Tav: I looked at how pattern treats it and not sure if bbox is
   ... the patern unit is used to determine the size of the tile
   relative to the object you're filling with the pattern

   shepazu: the ratio

   AmeliaBR: as far as mesh we don't have equivalent to pattern

   Tav: anyway there are the pattern units and the pattern content

   nikos: you can ignore the pattern units
   ... it is closer to gradients

   AmeliaBR: does a mesh normally path-out to a rect

   nikos: no

   AmeliaBR: this is different from other paint servers which have
   padded content outside
   ... so basically it is up to authors to make sure it looks good

   Tav: ok so we have mesh units

   nikos: gradient units should match to mesh units
   ... should we have a general unit for such?

   AmeliaBR: it will be hard because of patterns - there are two
   different ones

   shepazu: not necessary because patterns can have the general
   one and a special one

   AmeliaBR: yeah but they don't map well

   Tav: OK so we can use gradient units
   ... but then what if there's not bbox?

   <heycam> shepazu: this might want to be reused by HTML and
   canvas, so let's be mindful of that

   <heycam> trackbot, end telcon

Summary of Action Items

   [End of minutes]

Cameron McCormack ≝ http://mcc.id.au/

Received on Thursday, 16 July 2015 21:47:20 UTC