Minutes, Sydney 2016 F2F Day 1

https://www.w3.org/2016/02/03-svg-minutes.html

W3C - http://www.w3.org/

Sydney 2016 F2F
03 Feb 2016

   [2]Agenda

      [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2016/Agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2016/02/03-svg-irc

Attendees

   Present
   Regrets
   Chair
          Nikos

   Scribe
          Cameron

Contents

     * [4]Topics
         1. [5]Path stroking conformance
         2. [6]arc linejoin fallback
         3. [7]Animation of SVG paths with Web Animations
         4. [8]initial value of 'd' property
         5. [9]Animation of path data
         6. [10]GitHub
         7. [11]SVG 2 issues
     * [12]Summary of Action Items
     * [13]Summary of Resolutions
     __________________________________________________________

   <scribe> Scribe: Cameron

   <scribe> ScribeNick: heycam

Path stroking conformance

   <nikos> [14]https://github.com/w3c/svgwg/issues/41

     [14] https://github.com/w3c/svgwg/issues/41

   nikos: this was some investigation Tav did, into how different
   implementations stroke paths
   ... in some of the corner cases
   ... there's a link to Tav's page in the GH issue
   ... and I had an action to do some further investigation,
   enumerate what each implementation does, and come up with some
   recommendations for what we should specify in SVG 2
   ... so looking at Tav's investigation, there are basically two
   options
   ... Fig 2 and Fig 3 are the common methods that are implemented
   everywhere
   ... currently SVG doesn't define any particular method for
   which pixels should be painted in this sort of case
   ... and it turns out most other specs don't either
   ... PDF has some description which sounds like what Fig 2
   shows, but chatting with some PDF people their opinion was that
   PDF doesn't prescribe one particular way
   ... but the Adobe implementation has always been considered a
   reference implementation so everyone followed that
   ... so pretty much means all PDF implementations have converged
   on one implementation
   ... even though it's not specced

   s/taht/that/

   scribe: Skia and CG do Fig 3, Cairo does Fig 2
   ... Edge follows Fig 2
   ... I also had a chat to Mark Kilgard from nVidia, and what is
   more appropriate for hardware support
   ... NV_path_rendering does Fig 2
   ... his justification is that he would prefer to do something
   expensive per pixel, rather than something that generates
   additional geometry and fills it
   ... so a test per pixel
   ... he also felt that we shouldn't pick a particular method
   over another
   ... I feel the same way
   ... I think this is such a fundamental thing that performance
   is the ultimate consideration, so people should do the fastest
   on their platform, since there's not one method that's used in
   the majority of cases
   ... so I also wouldnt recommend one over the other, but if I
   had to choose I'd choose Fig 2

   heycam: I agree

   AmeliaBR: is there openness to having a long term strategy of
   encouraging people to shift to the way that doesn't have weird
   cutouts?
   ... we can't make it a conformance requirement at this point,
   it'd be a huge performance hit, but if we were somehow to
   indicate a preference then by having that in a standard
   somewhere hopefully that would influence future implementations
   and eventually this problem might go away?

   shane: I think these are fundamental properties of underlying
   OSes, and I don't think there's any chance of shifting by
   including spec language
   ... more useful would be to include recommendations to avoid
   content that differs in rendering by platform

   nikos: yes, if people are using these corner cases to get
   specific effects, we want to avoid that
   ... even a long term strategy of suggesting one over the other,
   I don't think that's worthwhile, things might change maybe one
   method becomes more efficient than another

   shane: can we have author recommendations?
   ... is it as simple as don't use strokes for geometry?

   nikos: I don't want it to be that simple, because there is a
   lot of use for that, as long as you're not doing tight curves
   within small areas, then you're not going to run into issues

   AmeliaBR: rather than specific recommendations, an informative
   warning might be useful
   ... have a note box saying that the SVG spec doesn't define
   what happens when strokes curve back on themselves in tight
   corners, implementations differ, here's an example, be aware

   nikos: I'd be happy to put a couple of examples of what
   rendering looks like on different platforms at the moment

   shane: and a suggestion on the right way to do it

   AmeliaBR: is there a way to do it without changing the geometry
   of the path?

   nikos: no

   heycam: but a suggestion on how to construct your path data to
   avoid those cases

   AmeliaBR: if you're going to make a tight corner, then do that
   rather than a loop
   ... depends. if you're drawing icons, you can adjust things to
   avoid these bugs. if you're plotting data, then you're stuck
   with whatever curves you've got

   nikos: one way to avoid it could be to change the coordinate
   space?

   Tav: don't think that would work

   AmeliaBR: it's not the first time this sort of language has
   been in the spec. SVG 1.1 handled patterns with overflow like
   this.

   nikos: everyone happy with not specifying one way or the other,
   and giving examples/warnings in the spec?

   Tav: I'm not really happy with that but I don't see any
   alternative now
   ... I agree with Amelia that Fig 2 is a much better rendering,
   and what people want

   nikos: I don't disagree with that

   AmeliaBR: would anyone argue for the weird cutout effect?

   nikos: TBH they both look slightly strange. it's not that one
   is clearly better than the other.

   Tav: right, Fig 2 is still not great

   nikos: but is nicer overall

   shane: one option would be to go with a detection of the cases
   where you're happy to be different, and simple not render in
   all of those cases
   ... maybe just that portion of the path
   ... then everything would be consistent, and you wouldn't have
   things that look good on one platform and not on another
   ... don't know it's a good idea, but it's a possibility

   Tav: I don't know how you would cut out part of the stroke

   AmeliaBR: if the reason we're not specifying one way or the
   other is perf, then that would cancel out the perf benefit
   ... if you're going to detect hte problem, it's you can fix it

   shane: it's the perf cost of fixing it, though

   nikos: also only some implementations would need to fix it
   ... the problem with cutting out some path segments if they're
   going to look funny is generated data
   ... if you're drawing a waveform based on some input data, you
   don't have a lot of control in that case
   ... if an author is createing a path in inkscape, they can make
   geometry to represent that section fo stroke, but if it's
   generated data it's just going to disappear

   AmeliaBR: this isn't an error case, where we're saying we don't
   know how to handle the error, this is just geometry that has
   interesting side effects
   ... I don't think we should treat it like an error

   shane: I can't argue with that

   Tav: ok, so we'll put some examples in the spec

   <scribe> ACTION: Nikos to add examples pointing out stroke
   painting inconsistencies between platforms, warning the author
   [recorded in
   [15]http://www.w3.org/2016/02/03-svg-minutes.html#action01]

     [15] http://www.w3.org/2016/02/03-svg-minutes.html#action01]

   <trackbot> Created ACTION-3831 - Add examples pointing out
   stroke painting inconsistencies between platforms, warning the
   author [on Nikos Andronikos - due 2016-02-10].

   heycam: nikos can you review the stroke shape generation
   algorithm since that's where these normative relaxations would
   have to go

arc linejoin fallback

   <Tav> [16]http://tavmjong.free.fr/SVG/LINEJOIN_STUDY/#arcs

     [16] http://tavmjong.free.fr/SVG/LINEJOIN_STUDY/#arcs

   Tav: just above that, fallback for miter clip
   ... I just wanted to make sure that what's in the spec, in the
   stroke generation algorithm, when the two lines are parallel,
   you still draw out to the clipping point
   ... the above one you see a flash because all of a sudden you
   fall back to bevel
   ... but there's no reason to, you can still clip at the
   miter-clip position
   ... I think it's just a matter of Cameron taking this into
   account in the stroke linejoin algorithm

   AmeliaBR: that's certainly what I'd expect, that you can extend
   the stroke by the miter-limit line
   ... when you have that parallel join

   <scribe> ACTION: Cameron to fix the linejoin algorithm to
   handle parallel miter-clip issue [recorded in
   [17]http://www.w3.org/2016/02/03-svg-minutes.html#action02]

     [17] http://www.w3.org/2016/02/03-svg-minutes.html#action02]

   <trackbot> Created ACTION-3832 - Fix the linejoin algorithm to
   handle parallel miter-clip issue [on Cameron McCormack - due
   2016-02-10].

   Tav: so now miter linejoin fallback
   ... I don't think the current fallback behaviour doesn't look
   good

   AmeliaBR: what about falling back to round?

   Tav: it would look better, but still give you an abrupt change
   in behaviour
   ... at the end of the page, look at examples of using this line
   join in a squiggle
   ... if you fallback to a round linejoin it wouldn't look good
   ... the miter linejoin doesn't look too bad, but there are
   cases as you see above that it can look bad
   ... so some kind of fallback where you preserve some of the
   curvature
   ... I came up with three options
   ... at first I thought 2 and 3 would be mathematically
   difficult, turns out not so bad
   ... ignore the jerkiness of the fallback, it's just a weakness
   of the SMIL animation (the interpolation is linear between the
   paths there)
   ... so Fig 7, 8 and 9 are the three fallback options
   ... Option 1 still has a discontinuity, Option 2 & 3 are
   continuous so I would favour one of those
   ... they're both similar level of complexity
   ... I saw we choose either 2 or 3 then I'll do a survey of
   artists to see what they prefer

   <shane> the talons still seem really long in 2 & 3

   AmeliaBR: the problem with these is the same problem in that
   they introduce corners at a certain point at the edges of the
   stroke
   ... it seems to be kicking in later with option 3 than option 2

   Tav: I think it should kick in at the same place. the spec
   would also state that when you have a half line stroke that is
   greater than the curvature, you fall back to round linejoin
   ... in Fig 11, you can see that falling back to a round line
   join looks better, and avoids having cutout regions
   ... round linejoins don't have problems with sharp curves

   ed: one thing I noticed in Options 2 & 3 is that at the top of
   the curve, if you follow the outer stroke, it's not exactly on
   the same curvature

   Tav: that's my constructing the curves, there's a slight error

   ed: as an artist I'd say that's not what you want

   RRSAgent: this meeting spans midnight

   Tav: ideally you'd want a sprial, but that's too complex

   shane: what about a variant of option 1 that morphs between the
   curved and straight variants?
   ... with option 1 the talon doesn't get excessively long

   AmeliaBR: for the static version the simplest end result is to
   just ahve the straight line at the end, but it's a matter of
   connecting over the discontinuity

   Tav: I've picked the worst case, when that talon gets really
   long because the lines are tangent to each other at the end
   ... I don't see the fact that the talons get long as
   particualrly being a problem
   ... if you don't want the talon long, you don't make the two
   segments parallel at the end

   shane: with generated data you might have no choice

   AmeliaBR: probably wouldn't be using this line join on a data
   vis

   Tav: you can always put a miter limit on

   AmeliaBR: I agree with Tav that all of these options are better
   than just switching to the miter which has a discontinuity and
   a weird shape

   Tav: can I get agreement with choosing one of these as a
   fallback then I'll do a survey to see what people prefer?

   nikos: anyone not happy with option 2 or 3 as fallback?
   ... I think I like 3 over 2, esp if you fix the curvature
   ... prob would prefer option 1 if it was continuous
   ... but I'd be happy with any of option 2 or 3

   <ed> +1 for option 3

   Tav: I've got these partially implemented in Inkscape
   ... when I've fixed the bugs I'll release that in a trunk
   version that people can test

   nikos: might be a good test to try with a bunch of vector image
   files and set them all to arcs to see if you get anyhting
   standout horrible

   RESOLUTION: arcs fallback will be option 2 or 3 depending on
   survey feedback

   <scribe> ACTION: Tav to survey whether option 2 or 3 would be
   better for arcs fallback [recorded in
   [18]http://www.w3.org/2016/02/03-svg-minutes.html#action03]

     [18] http://www.w3.org/2016/02/03-svg-minutes.html#action03]

   <trackbot> Created ACTION-3833 - Survey whether option 2 or 3
   would be better for arcs fallback [on Tavmjong Bah - due
   2016-02-10].

Animation of SVG paths with Web Animations

   Tav: my worry was that this would fall through the cracks
   ... but talking to people this will end up in a spec somewhere

   AmeliaBR: there's a lot of push to make d a property, and so it
   would be naturally part of web animations

   shane: I believe that Cameron was working on that this morning
   ... also d should be directly animatable as an attribute once
   we resolve any remaining any issues once we work out Web
   Animations targetting attributes
   ... hasn't fallen through the cracks

   AmeliaBR: one extension that goes beyond Web Animations is
   introducing more flexibility in how you interpolate different
   paths
   ... the SMIL standard and the one that's been implemented in
   snap, d3, has this requirement of same number/type of segments
   ... and another option is to create normalization rules so that
   ifyou're animating frmo a striaght line to a cubic bezier you
   effectively upgrade the line to the cubic
   ... and therefore make it a lot more flexible to do those sorts
   of animations

   shane: we have experimented with this in the past, and in
   making splits in segments so you can animate when the numebr of
   segments difers, and it all works well, would love to do that
   ... but I don't think we can just come up with extended
   interpolation rules, we might need to introduce new syntax for
   that
   ... I certainly would be interested to move in that direction

   Tav: would like to avoid getting complicated right now
   ... I think maybe doing the line->bezier would be an exception,
   since that's an easy thing to do

   shane: it's all very easy, but I don't think we should have
   just one exception, if we're going to do it make it right
   ... the rules aren't hard, just whether to introduce new impl
   requirements or not
   ... and I agree at this stage we shouldn't

   AmeliaBR: I would say there's huge authoring demand for this
   ... when GSAP (?) introduce this, you can morph paths you don't
   have to carefully construct the paths to match
   ... so there's certainly demand for this
   ... but let's not do it piecemeal

   BogdanBrinza: sounds like a good Level 1 / Level 2 thing
   ... we can start with the same number/types of commands for
   Level 1, then extend in Level 2

   shane: are we having a Path module?

   heycam: yes there is one

   Tav: fine with me

   heycam: I'll continue working on that this afternoon

   AmeliaBR: the natual place for it might be CSS Transitions
   spec, which has rules for all other datatypes
   ... not sure if they want us to start throwing path data in
   there
   ... if not, then in SVG 2 Paths chapter which just repeats that
   rule about how to interpolate two paths

   birtles: the intention I think is the latter.. Transitions was
   just catching up for things already defined, but all new
   properties etc. should define their own rules for how they're
   interpolated and animated, so it should go in SVG 2 's path
   definitions

initial value of 'd' property

   ed: I chatted with Eric Willigers last night, and noted lack of
   initial value for d
   ... question is whether none or the empty string

   AmeliaBR: can we all agree that an empty path really means
   nothing, because that impacts on stuff like bbox calcualtions
   ... you don't want that empty path contribute a dot at the
   origin to group bbox calculations
   ... whatever we call it, the "no d value specified" has to
   equate to the path not rendered and doesn't affect geom at all

   heycam: I think having none and path("") be the same would be
   fine, with none being the initial

   shane: also think about computed values

   AmeliaBR: also should normalization be done in the computed
   values?
   ... wouldn't we treat path("") as invalid syntax and dropped at
   parse time?

   shane: no I don't think that should be invalid
   ... just to be clear: path { d: path(""); }

   AmeliaBR: I did send a reply to your mail about path()

   heycam: so what about the d="" presentation attribute, shoudl
   we be accepting path() in there in addition to raw path syntax?

   shane: it's a non-starter to set d with a fill rule and make
   that affect the fill-rule property
   ... so we'd need to ignore the fill rule value in there

   AmeliaBR: we need the fill rule for clip-path

   shane: yes. I suggest having two variants of path(), and spec
   authors choose which one

   heycam: we can't use raw path data in the property value
   ... CSS parsing problems
   ... at that point we have different syntax from the existing
   d="" attribute, so we may as well have path() to match other
   property syntax patterns

   AmeliaBR: then we could also extend to CSS shapes in there like
   circle()

   shane: the only thing I would say is that there is definitely
   interest in CSS in the future in specifying a more readable
   syntax for paths
   ... I think that's a feeling in the CSSWG, that we could get
   quite efficient minimzation that happens with gzip, so we
   should bias towards readbility
   ... making this a function rather than a raw function makes it
   way easier to add new syntaxes in the future

   heycam: so should we allow path() in the presentation attribute
   too?

   shane: decide once we decide to extend the d property syntax?

   AmeliaBR: it wouldn't be hard to support... you don't have to
   parse far to tell

   heycam: true. also happy to leave it for now.

   <shane> a/than a raw function/than a raw string/

   AmeliaBR: so those issues to the side, we're all in agreement
   that if the d property includes a fill rule it's ignored, and
   the fill-rule property is used instead?
   ... or if the path() has a fill rule valid it's invalid?

   shane: I don't think we've made a decision, but I suggest the
   latter
   ... if you provide a fill rule for a property that doesn't
   accept one then that's an error
   ... probably the most CSS-y way to do this is pull the
   fill-rule of the property out of the path()

   AmeliaBR: this has already shipped in some places, though
   ... so path() should match up with the other CSS Shapes
   functions

   shane: I'm really uncomfortable with supporting the d property
   on path elemetns such that it accepts a fill rule that
   necessarily must be ignored

   AmeliaBR: from another perspective, why don't we make the 'd'
   property a shorthand that somehow encompasses the fill-rule and
   overrides it?

   shane: if so then you wouldn't have the fill-rule inside the
   path()

   heycam: so how about we disallow fill-rule and decide to allow
   it if we want to apply d to other properties that need it later

   AmeliaBR: I would prefer generalizing it

   heycam: I think it's safe to disallow now and open up later if
   we need to

   <birtles> shane: I'd like someone to summarize this discussion
   and send it to the CSS list

   <birtles> heycam: I don't think ignoring the value inside there
   is such an extreme change

   <birtles> AmeliaBR: as it is now you can use the fill rule in
   properties where it has no effect

   <birtles> shane: but in this case the fill-rule has an effect
   but we throw it away

   <birtles> heycam: someone can write it up and ask the CSSWG

   <birtles> shane: I'll do it

   <scribe> ACTION: Shane to ask CSSWG if disallowing fill rule in
   path() for d is good [recorded in
   [19]http://www.w3.org/2016/02/03-svg-minutes.html#action04]

     [19] http://www.w3.org/2016/02/03-svg-minutes.html#action04]

   <trackbot> Created ACTION-3834 - Ask csswg if disallowing fill
   rule in path() for d is good [on Shane Stephens - due
   2016-02-10].

Animation of path data

   nikos: Bodgan points out we missed out on a resolution

   AmeliaBR: two aspects: one resolve that SVG 2 Paths chapter
   should have rules for interpolating from SVG 1.1, same
   number/type rules
   ... just c/p the paragraphs from SVG 1.1
   ... and we also agreed that the Paths module would include more
   flexible path interpolation rules
   ... TBD later

   RESOLUTION: SVG 2 Paths chapter will include SVG 1.1 rules for
   interpolating path data with same number/types segments, and
   SVG Paths module will be the place to have extended
   interpolation rules

   <AmeliaBR> Update on that resolution: it looks like the only
   paragraph in SVG 1.1 describing animation of path data is right
   after the "d" attribute is specified. It's already in SVG 2.
   May want to add an informative note that "this may be changed
   by a future specification"?
   [20]https://svgwg.org/svg2-draft/paths.html#DAttribute

     [20] https://svgwg.org/svg2-draft/paths.html#DAttribute

   <nikos> ping AmeliaBR: We're back

   AmeliaBR, I don't think we want to say that it might change;
   rather that we might add new interpolations in the future

   <AmeliaBR> heycam: that's better. Existing rules should stay
   the same, but new options become available.

GitHub

   nikos: this is about how we want to track our work, issues
   ... I've been experimenting with filing issues there, tagging
   them
   ... I like the environment, it tracks the whole conversation,
   easy to drop in a comment and point to something
   ... seems like it would work very well
   ... there are other things too, hooking in with the spec build
   process if we want, hooks on issues being added etc.

   <AmeliaBR> +100 to all Nikos has done to get GitHub rolling...

   nikos: might be an option once we have time
   ... the challenge there is moving everything to one place, and
   not falling back to old habits
   ... keeping conversations from getting fragmented
   ... comments from people who've used GH more would be good
   ... and others' feelings

   shepazu: first I want to mention that W3C most WGs are moving
   to GH, increasingly our toolchain is geared around GH
   ... so we'd be going with the flow
   ... there are ways to reflect issues into the mailing list
   ... some people find that problematic
   ... personally I feel it's a good place to archive our
   conversations
   ... if we really wanted to set up a GH only list then we could
   do that, if we don't want to send them to www-svg
   ... if we move to GH issues, I'm going to set up a demo in a
   few mins of a kanban board we're trying to mimic for the W3C
   issue trackers
   ... it lets you visualise what's going on, it's a useful
   organisational tool
   ... in general people are more prone to comment on GH than MLs,
   it's lower commitment
   ... so I'm in favour of it
   ... I'm not GH expert but I'm conformtable with it

   BogdanBrinza: we've been using it for some internal projects
   ... it's very useful for discussions and code in the same place
   ... test cases, commits, it's incredibly useful

   shane: in Houdini it's been great to have all the comments on
   an issue in the one place, when coming back to an issue months
   later

   nikos: one of the negatives is that it's online
   ... if you want to read conversatiosn offline it might be
   difficult

   shepazu: if you reflect issues to a mailing list that's
   resolved
   ... you can even respond to issues via email
   ... one downside is some organisations aren't allowed to
   participate on GH, because you can post code there
   ... I don't think it's a problem for our WG

   AmeliaBR: one issue I've heard is relying on an outside
   commercial entity, so long as everything is backed up somehwere
   it's not a problem
   ... for Git repos it's fine, since you have copies everywhere
   else
   ... the issues are hosted exclusively on GH, so it's a
   dependency on that company
   ... copying to a ML should be fine as a backup

   Tav: I think that is an improtant issue, inkscape for example
   relied on sourceforge
   ... somebody bought it, it's changed completely, we're moving
   off it

   shepazu: because so many WGs are on GH, if something happened
   there, I'm sure there'd be a grace period to offload their
   resources

   shane: I think we have a tool for migrating issues between GH
   projects

   nikos: I could run a GH Enterprise thing at work and mirror the
   issues

   shepazu: one thing that would be nice is an IRC interface
   ... right now we have Tracker, and the only benefit to tracker
   is its IRC interface
   ... so for the Web Payments WG (and for others) is set up OAuth
   between a W3C interface so you could auth to make changes to
   repos, with that bridge we can make an IRC bot as well
   ... so we could say issue #15 in the channel and open/close
   issues

   nikos: we also have the W3C action tracker, and just have an
   issue assigned to someone

   shepazu: yes, especially now with Zakim also no longer being
   useful

   <AmeliaBR> Possibly relevant: recent effort by some open-source
   groups to push GitHub to improve issues for better project
   management: [21]https://github.com/dear-github/dear-github

     [21] https://github.com/dear-github/dear-github

   heycam: Houdini redirects any issue discussing emails on the ML
   to GH, do we want to do that too?

   nikos: [thumbs up]

   shepazu: I think being in GH "issues" focuses more on specific
   issues, too, rather than general discssion
   ... I remember from the old days in SVG we'd easily lose
   valuable comments because they were in the ML somewhere and
   weren't captured as issues properly
   ... this would help us track stuff more
   ... what about contributions from people not in the WG?
   ... generally it's not a problem, some people worry about it
   though

   shane: there are things you can do. I know that the Google GH
   repo has hooks of some sort to request anybody who is not in a
   list to sign an SLA
   ... that's done on PRs

   birtles: if we use GH more, we're more likely to get PRs
   ... what's the situation with regards to IP, do they need to
   sign a CLA
   ... when I asked about this in the past, I was told it's fine
   to accept PRs from anyone in the WG obviously, also a member
   org
   ... but there is some requirement for people outside those
   categories
   ... not sure we can fulfill that requirement by sticking
   something in the README.md?

   <AmeliaBR> GitHub process for defining contributing agreements:
   [22]https://help.github.com/articles/setting-guidelines-for-rep
   ository-contributors/

     [22] https://help.github.com/articles/setting-guidelines-for-repository-contributors/

   AmeliaBR: this is not something unique to W3C
   ... all open sources communities have to deal with making sure
   people who contribute aren't going to sue
   ... so it's just a case of whether the W3C is OK with using the
   GH warning "don't contribute unless you agree to this", or if
   the W3C wants somebody to actually signed/clicked an agreement

   shepazu: I should know this, but I'm not sure. I will research
   this and get back to you tmr.

   AmeliaBR: one of the most important aspects is tagging issues
   well
   ... Nikos has been tagging them nicely, but I don't know
   whether he as chair wants to do that ongoing, or whteher there
   will be some sort of process of triaging new issues coming in
   ... similarly for things on the ML, do you want to have a
   chair's reponsibility to turn that into an issue?
   ... or reply to ask the commenter to put it on GH?

   nikos: I'm happy to keep doing this, and we should help the
   author by filing the GH issue for them
   ... on the subject of tags, I think it's important to get that
   worked out early
   ... so we don't have a situation where the first 6 months of
   issue filing we don't have tags, but after we do
   ... so at the moment I've got tags for each spec, then tags for
   each chapter of SVG 2
   ... then there are a few others like "needs CSS review"
   ... I think we could use more tags, if people have suggestions
   feel free to just create them or bring it up

   AmeliaBR: my one suggestion is to have a single document that
   outlines the tagging scheme

   nikos: as an outcome of this discussion, I can write up a wiki
   page describing the GH workflow, tagging, etc.

   <shepazu> [23]https://waffle.io/w3c/svgwg

     [23] https://waffle.io/w3c/svgwg

   nikos: what about GH wiki?

   shane: Houdini moved to the GH wiki

   nikos: I'll lay down some best practices in a wiki page

   shepazu: Wendy Seltzer has told me that there is a way of
   setting up a GH repo so there's a click through on
   contributions
   ... so I'll make sure that's set up correctly

   <shepazu> [24]https://waffle.io/w3c/svgwg

     [24] https://waffle.io/w3c/svgwg

   shepazu: this is a kanban board
   ... each column is a label
   ... you have to auth by clicking the person icon in the bottom
   left of the page

   <shepazu> [25]https://waffle.io/w3c/webpayments

     [25] https://waffle.io/w3c/webpayments

   shepazu: we have things broken down into New, Actions,
   Discussion, Proposals, In Progress, Postponed and Done

   AmeliaBR: so the idea is to separate out issues that are being
   discussed, and those where we have a clear resolution but needs
   to be done, or is in progress?

   <shepazu> [26]https://waffle.io/w3c/annotation

     [26] https://waffle.io/w3c/annotation

   shepazu: discussion is for things that will come up in the next
   telcon
   ... editing for when an action is assigned to do it
   ... there are different ways, we can pick our own labels
   ... this is a 3rd party service waffle.io
   ... we're trying to make something like this for W3C, but you
   can drag items between these different groups
   ... and that resolves them
   ... you can raise new issues etc.
   ... we don't have to use this, but it might be useful

   nikos: I like it

   shepazu: one danger is if there are different repos, this
   doesn't reflect that

   AmeliaBR: there's a way of cross linking issues between repos

   shepazu: but we'd need to maintain a master list of issues in
   our repo

   heycam: we have all our specs in the one repo

   AmeliaBR: but there is an FX repo

   shepazu: that's where that issue mover tool comes in handy

   shane: overall: awesome!

   ed: so are we using the kanban?

   <shepazu> [27]https://github.com/w3c/licenses

     [27] https://github.com/w3c/licenses

   nikos: I'm happy to. everyone doesn't need to...

   <shepazu> [28]https://labs.w3.org/hatchery/ash-nazg/

     [28] https://labs.w3.org/hatchery/ash-nazg/

   shepazu: maybe the agenda could reference other issues

   nikos: or a special board for telcons

   shepazu: or just a label
   ... that does mean more work for you (chairs), but it's not
   much

   AmeliaBR: one issue with GH issues is you can't attach SVG
   files
   ... you have to zip it or host it elsewhere

   nikos: realistically I'd put things in jsfiddle and link to it,
   so it's not a dealbreaker

   shepazu: I can raise the issue of SVGs on GH issues and wiki

SVG 2 issues

   nikos: the main goal is that people should have something to
   work on for the rest of the day

   Tav: does anyone have not have spec editing to work on this
   afternoon?
   ... otherwise we should just get on to it

   nikos: the coords chapter does need looking at. I'm going to go
   through it, but you want to go throuhg it and see fi there are
   things that need improving that'd be useful

   shane: sure

   BogdanBrinza: in SVG Integration, looking at currently
   interoperable external resources in use
   ... and CSS sizing behaviour
   ... it's mostly interoperable, the spec didn't help us, so we
   had to build our cases
   ... while looking at SVG integrations the issues there are
   fairly light
   ... and tmr make a call on them?

   heycam: there were previous discussions e.g. in Leipzig, which
   didn't make their way into the spec, you might want to look at
   the minutes there

   AmeliaBR: sizing issues come up a lot for authors

   BogdanBrinza: in my experience, SVG as background-image, inline
   and SVG-as-image, all the browsers are fairly interoperable
   between Firefox/Chrome/Edge, not necessarily IE/Safari
   ... but it's fairly close
   ... if it will help this group, the behaviour we trended to was
   SVG sizing first, then do CSS sizing, rather than making CSS
   sizing taking into account SVG properties
   ... I'll give more details tomorrow

   shepazu: changing topics, I still write SVG from time to time,
   doing it by hand I still struggle with xlink:href
   ... AIUI the only implementation right that supports barename
   href is Edge
   ... how the spec on that?

   heycam: spec changes have been made

   shepazu: href seems like low hanging fruit

   BogdanBrinza: I would imagine implementors would be willing to
   contribute tests suites they have intenrally, once we know the
   right framework
   ... I'm not sure what to do there

   shepazu: could I ask if you have tests for this?

   BogdanBrinza: for SVG sizing etc. we do
   ... I think we have close to 200 tests

   shepazu: could I get you to report back on what tests to
   contribute?

   BogdanBrinza: sure

   birtles: as for the format, we've decide we're doing
   testharness.js in WPT, and reftests

   <nikos> [29]http://www.meetup.com/SVG-AU/events/228075250/

     [29] http://www.meetup.com/SVG-AU/events/228075250/

   <stakagi> I agree. Should a Vector Effect chapter be put on
   both cooords and painting?

   stakagi: I think that's fine. but have the primary property
   definition blue box in the Coords chapter

   <stakagi> heycam: O.K.

Summary of Action Items

   [NEW] ACTION: Cameron to fix the linejoin algorithm to handle
   parallel miter-clip issue [recorded in
   [30]http://www.w3.org/2016/02/03-svg-minutes.html#action02]
   [NEW] ACTION: Nikos to add examples pointing out stroke
   painting inconsistencies between platforms, warning the author
   [recorded in
   [31]http://www.w3.org/2016/02/03-svg-minutes.html#action01]
   [NEW] ACTION: Shane to ask CSSWG if disallowing fill rule in
   path() for d is good [recorded in
   [32]http://www.w3.org/2016/02/03-svg-minutes.html#action04]
   [NEW] ACTION: Tav to survey whether option 2 or 3 would be
   better for arcs fallback [recorded in
   [33]http://www.w3.org/2016/02/03-svg-minutes.html#action03]

     [30] http://www.w3.org/2016/02/03-svg-minutes.html#action02
     [31] http://www.w3.org/2016/02/03-svg-minutes.html#action01
     [32] http://www.w3.org/2016/02/03-svg-minutes.html#action04
     [33] http://www.w3.org/2016/02/03-svg-minutes.html#action03

Summary of Resolutions

    1. [34]arcs fallback will be option 2 or 3 depending on survey
       feedback
    2. [35]SVG 2 Paths chapter will include SVG 1.1 rules for
       interpolating path data with same number/types segments,
       and SVG Paths module will be the place to have extended
       interpolation rules

   [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 Sunday, 7 February 2016 23:38:27 UTC