- From: Nikos Andronikos <Nikos.Andronikos@cisra.canon.com.au>
- Date: Sun, 7 Feb 2016 23:37:49 +0000
- To: www-svg <www-svg@w3.org>
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