SVG Working Group Teleconference -- 03 Feb 2016

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Path stroking conformance

<nikos> 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 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> 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 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 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 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"? 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: 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: 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> 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> 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> 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> 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> https://github.com/w3c/licenses

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

<shepazu> 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> 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.

- DRAFT -

SVG Working Group Teleconference

03 Feb 2016

Attendees

Contents