SVG Working Group Teleconference -- 16 Jul 2015

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

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

<heycam> 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 foreignObject
... 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> 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 week
... 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 later

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 me
... next is Paint Servers

Tav: made some progress
... want to discuss open issues about how to fit a mesh inside bbox
... 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 it

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 nodule?

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> 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 mesh

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

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

AmeliaBR: I did suggest to use a vbox pattern

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

Tav: I looked at how pattern treats it and not sure if bbox is correct
... 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 units

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

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

- DRAFT -

SVG Working Group Teleconference

16 Jul 2015

Attendees

Contents

Canvas2D API

Fitting mesh in a bbx

Summary of Action Items

Scribe.perl diagnostic output