See also: IRC log
<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
<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
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
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/xforms/transforms/g Succeeded: s/clear API/clear WG/ Succeeded: s/have a path/have padded content/ Found Scribe: Cameron Found Scribe: Rossen Inferring ScribeNick: Rossen Scribes: Cameron, Rossen Present: Cameron Tav AmeliaBR Rossen present Nikos stakagi Agenda: https://lists.w3.org/Archives/Public/www-svg/2015Jul/0014.html Found Date: 16 Jul 2015 Guessing minutes URL: http://www.w3.org/2015/07/16-svg-minutes.html People with action items:[End of scribe.perl diagnostic output]