20:58:14 <RRSAgent> RRSAgent has joined #svg
20:58:14 <RRSAgent> logging to http://www.w3.org/2012/12/06-svg-irc
20:58:16 <trackbot> RRSAgent, make logs public
20:58:16 <Zakim> Zakim has joined #svg
20:58:18 <trackbot> Zakim, this will be GA_SVGWG
20:58:18 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)4:00PM scheduled to start in 2 minutes
20:58:19 <trackbot> Meeting: SVG Working Group Teleconference
20:58:19 <trackbot> Date: 06 December 2012
20:59:09 <Zakim> GA_SVGWG(SVG1)4:00PM has now started
20:59:16 <Zakim> +Doug_Schepers
20:59:34 <Zakim> +[IPcaller]
20:59:43 <birtles> Zakim: IPcaller is me
20:59:58 <Zakim> +cabanier
21:00:00 <birtles> Zakim, IPcaller is me
21:00:00 <Zakim> +birtles; got it
21:00:21 <shepazu> Zakim, mute cabanier
21:00:21 <Zakim> cabanier should now be muted
21:00:55 <cabanier> * zakim is weird today*
21:01:00 <Zakim> -cabanier
21:01:08 <jarek> how do you join the teleconference?
21:01:23 <Zakim> +??P4
21:01:25 <jarek> is it for w3c members only?
21:01:37 <ed> Zakim, ??P4 is me
21:01:37 <Zakim> +ed; got it
21:01:38 <Zakim> +cabanier
21:02:03 <Zakim> + +1.415.832.aaaa
21:02:06 <krit> krit has joined #svg
21:02:06 <heycam> jarek: yes it is for working group members
21:02:16 <Zakim> +[IPcaller]
21:02:18 <heycam> Zakim: [ is me
21:02:41 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0051.html
21:02:43 <krit> zakim, who is on the phone?
21:02:43 <Zakim> On the phone I see Doug_Schepers, birtles, ed, cabanier, +1.415.832.aaaa, [IPcaller]
21:02:50 <heycam> Zakime, [IPcaller] is me
21:02:51 <krit> zakim, aaaa is me
21:02:51 <Zakim> +krit; got it
21:02:58 <heycam> Zakim, [IPcaller] is me
21:02:58 <Zakim> +heycam; got it
21:03:55 <heycam> Chair: Erik
21:03:57 <heycam> Scribe: Cameron
21:03:59 <heycam> ScribeNick: heycam
21:04:08 <heycam> Topic: Sydeny F2F
21:04:16 <heycam> s/Sydeny/Sydney/
21:04:46 <heycam> heycam: just brought this up last week to verify that we wouldn't change dates
21:05:17 <ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013 (needs details filled in)
21:05:27 <Zakim> + +61.2.980.5.aabb
21:05:32 <heycam> ed: we have a wiki page
21:05:37 <heycam> heycam: I think we still need a registration form though
21:05:40 <nikos> Zakim, +61.2 is me
21:05:40 <Zakim> +nikos; got it
21:07:24 <Zakim> + +33.9.53.77.aacc
21:07:34 <jarek> shepazu: no, I'm just interested in following the latest news on SVG 2
21:07:45 <Tav> zakim, aacc is me
21:07:46 <Zakim> +Tav; got it
21:09:29 <heycam> ACTION: Cameron to set up a registration form for Sydney F2F 2013
21:09:29 <trackbot> Created ACTION-3401 - Set up a registration form for Sydney F2F 2013 [on Cameron McCormack - due 2012-12-13].
21:10:22 <heycam> heycam: F2F is February 4 - 8, with half a day on Wednesday
21:14:19 <heycam> krit: we should get the Tokyo dates fixed
21:14:24 <heycam> krit: the chairs should coordinate with CSS
21:14:25 <heycam> heycam: ok
21:14:34 <heycam> birtles: I will talk to John who is hosting CSS
21:15:16 <birtles> also, for your planning, test the Web forward will likely be the week of 11 Feb
21:15:37 <birtles> Australia Day is 26 Jan so you might want to come early :)
21:15:44 <heycam> http://wiki.csswg.org/planning/tokyo-2013
21:15:48 <heycam> June 5 - 8
21:15:50 <heycam> s/8/7/
21:17:52 <heycam> birtles: should we be only haing 2 days of SVG in that week? is that enough?
21:18:10 <heycam> heycam: I'm happy to extend it backwards to start on the Sunday if people wanted to do that
21:18:23 <heycam> birtles: or Saturday, and skip Sunday
21:18:52 <heycam> birtles: I'll talk to John and put forward a couple of suggestions
21:20:16 <heycam> Topic: marker-pattern
21:20:27 <heycam> ed: did we have anything more to discuss beyond last week's discussion?
21:20:32 <heycam> heycam: not sure there was any progress
21:20:32 <krit> http://lists.w3.org/Archives/Public/www-svg/2012Nov/0072.html
21:20:35 <heycam> krit: I sent an email, no response yet
21:20:50 <krit> [<distance> <url>]+
21:20:56 <heycam> krit: I just want to make sure we have this basic syntax
21:21:09 <heycam> krit: we might have other keywords around it, but hopefully the core of the syntax doesn't get more complicated than that
21:21:20 <krit> [<distance> <url>]+ [/ <marker-free-region>]? || [repeat | no-repeat]?
21:21:21 <heycam> krit: to address heycam's offset issue, I have this syntax
21:21:56 <heycam> krit: after the repeating distance/urls, you can have lengths from the left and right side where markers don't paint
21:22:44 <heycam> krit: as well as the <marker-free-region>, do you have the initial length value to give the offset as in stroke-dashoffset?
21:22:46 <krit> <marker-free-region> =  [ <distance> | auto ]{1,2}
21:22:59 <heycam> krit: no, I think that syntax with the first length is hard to read
21:23:18 <heycam> krit: that <marker-free-region> syntax is the same as background-size
21:23:21 <heycam> heycam: what does auto mean?
21:23:26 <heycam> krit: we could leave that off, it would just mean 0
21:24:00 <heycam> krit: I think we should just keep one of the two offset interpretations, not both
21:24:13 <heycam> krit: either the one that is like stroke-dashoffset, or the marker free regions
21:24:33 <heycam> Tav: I think there are cases where you want to align the markers with the dashes
21:24:46 <heycam> … you can think of borders on maps
21:24:56 <heycam> … where you have dashes and you want the marker to be in the middle of the dash
21:25:19 <heycam> heycam: and because you might use stroke-dashoffset on that, you would want it for the marker pattern too?
21:25:20 <heycam> Tav: yes
21:26:18 <heycam> heycam: I wonder if it makes sense to have a single offset, instead of per track
21:26:21 <heycam> krit: I don't think that makes sense
21:26:53 <heycam> Tav: this might get complicated too when we have adjusted strokes
21:27:04 <heycam> krit: we could also have a separate marker-pattern-offset property
21:27:12 <heycam> … a list of lengths
21:27:29 <heycam> … I don't think putting everything into the marker shorthand is a good idea
21:28:27 <heycam> heycam: I like having the marker-pattern-offset different from marker-pattern, so it can be animated
21:29:29 <heycam> krit: this would be hard to animate with SMIL, but with CSS animation it would work
21:29:50 <heycam> birtles: you can just define to SMIL to animate this
21:30:09 <heycam> … how is this different from animate?
21:30:17 <heycam> krit: it's a special case
21:30:24 <heycam> birtles: we just define a new data type and how SMIL animates it
21:30:53 <heycam> … I don't think it's SMIL that needs redefining, we just define how the data type animates
21:32:17 <heycam> … as we define new data types we should define how they get animated
21:32:27 <heycam> … CSS animations defines a bunch of base data types that are common
21:32:39 <heycam> … but for example with CSS Transforms, it defines some new data types, and how they get animated
21:32:55 <thorton> thorton has joined #svg
21:33:24 <krit> http://dev.w3.org/csswg/css3-background/#the-background
21:34:44 <Zakim> -krit
21:35:08 <heycam> Topic: arc join naming
21:35:21 <heycam> Tav: I sent an email with a list of possibilities
21:36:07 <Zakim> + +1.415.832.aadd
21:36:14 <heycam> http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0053.html
21:36:25 <krit> zakim, aadd us me
21:36:25 <Zakim> I don't understand 'aadd us me', krit
21:36:29 <heycam> Tav: the top four are arc, claw, extrapolate, talon
21:36:34 <krit> zakim, aadd is me
21:36:34 <Zakim> +krit; got it
21:36:49 <heycam> nikos: extrapolate was the original one that was suggested
21:36:53 <heycam> … what was wrong with it?
21:36:55 <heycam> Tav: it's a bit long
21:37:42 <heycam> heycam: I think there could be multiple ways of extrapolating, so I am not sure it describes it well
21:38:11 <heycam> nikos: if you have to straights lines that converge, they will continue on?
21:38:14 <heycam> Tav: it will fall back to miter
21:38:44 <heycam> shepazu: there must be an existing graphics term for this
21:39:09 <heycam> http://en.wikipedia.org/wiki/Woodworking_joints
21:39:32 <heycam> ed: we can discuss a bit more. but I agree it should fit in well with the existing types.
21:41:01 <heycam> s/arc/arcs/
21:41:11 <heycam> heycam: I think arcs is the most uncontroversial to me
21:41:14 <heycam> … least out there
21:41:32 <heycam> Tav: note that it is two arcs, hence "arcs" not "arc"
21:41:50 <heycam> birtles: I like claw because it makes sense straight or curved
21:42:16 <heycam> Topic: back to marker-pattern
21:43:26 <thorton> thorton has joined #svg
21:43:37 <heycam> heycam: I just wanted to know whether this pattern of parallel of properties is something the CSS WG likes, or whether we should avoid
21:43:42 <heycam> krit: the shorthand can be confusing
21:43:59 <heycam> … but I don't think the CSS WG is against this way of specifying short hands
21:44:36 <heycam> birtles: if you have these two paralllel lists, and the lengths are different, you have to define what happens. and as the author you need to match them up.
21:44:49 <heycam> heycam: right that's my concern, whether this way of specifying multiple properties with lists that match up is good or bad
21:46:16 <heycam> heycam: otoh I like being able to animate the individual parts of it, and not the whole shorthand
21:46:57 <heycam> … it makes me wonder then whether the marker-pattern parts should be separated out into different properties too
21:48:08 <heycam> heycam: just wondering if it makes sense to separate out the marker-free-region into a separate property
21:49:21 <Zakim> -heycam
21:49:37 <heycam> heycam: just wonder whether it makes sense to break marker-pattern up further
21:49:44 <Zakim> +[IPcaller]
21:49:47 <heycam> Zakim: [IPcaller] is me
21:51:02 <heycam> krit: I'm concerned that the marker shorthand will become extremely complicated if we can specify marker-mid etc. and marker-pattern in the one property
21:51:51 <heycam> heycam: what about repeating a marker pattern over segments instead of the whole path?
21:52:01 <heycam> krit: I think it would be fine to leave as a single marker on segments
21:52:29 <heycam> heycam: how do you specify that in your proposal?
21:52:46 <heycam> krit: marker-segment
21:52:54 <heycam> heycam: ok, back to a separate property
21:53:17 <heycam> heycam: but Tab is not in favour of marker-segment and marker-pattern being separate
21:54:11 <heycam> s/heycam/krit/
21:54:24 <heycam> krit: would you want marker-segment as part of the marker shorthand?
21:55:37 <heycam> heycam: I thought that it would be good to have the "blah" shorthand reset all "blah-*" properties
21:55:38 <krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html
21:55:43 <heycam> … are there existing cases where this doesn't happen?
21:55:57 <heycam> krit: in CSS Masking, there is the mask property and mask-box-image, which are both shorthands
21:57:46 <heycam> ACTION: Cameron to reply to Dirk's recent marker-pattern proposal
21:57:46 <trackbot> Created ACTION-3402 - Reply to Dirk's recent marker-pattern proposal [on Cameron McCormack - due 2012-12-13].
21:58:11 <heycam> Topic: fill/stroke url()s
21:58:16 <heycam> krit: can we discuss this in the FX call?
21:58:23 <heycam> … same for mask-type
21:58:28 <heycam> Topic: SVG 2
21:58:43 <heycam> krit: I don't think we've edited so much since the last WD
21:58:53 <heycam> … I'd like to fix a bunch of things first before publishing a new WD
21:59:02 <heycam> … maybe at the end of the Feb F2F meeting?
21:59:32 <heycam> heycam: ok, that's fine
21:59:33 <nikos> http://www.w3.org/2012/10/25-svg-minutes.html#item03
21:59:46 <heycam> … the publishing moratorium is coming up soon anyway, so it'll be hard to publish by this year
21:59:54 <heycam> Topic: SVG 2 - suggestion for a new path command to close a subpath smoothly
22:00:25 <heycam> heycam: I just skimmed the thread, but I think the idea seems OK to me
22:00:32 <heycam> cabanier: I think it introduces a lot of details that need to be worked out
22:00:37 <Zakim> -krit
22:00:51 <heycam> … it's more than just back flipping the initial control points and using them
22:00:55 <heycam> … especially for arcs
22:01:21 <heycam> … if you define it to close smoothly, and the previous point is an arc, how do you connect it?
22:01:28 <heycam> … everyone does arcs to beziers differently
22:01:44 <shepazu> q+
22:02:22 <Zakim> + +1.415.832.aaee
22:02:32 <Zakim> -Tav
22:02:34 <heycam> heycam: I think we can get around this by just inferring the final point of a user specified segment
22:03:13 <Zakim> +Tav
22:03:15 <heycam> shepazu: I'm not sure he was that fussed about how to specify it
22:03:44 <krit> zakim, who is on the phone?
22:03:44 <Zakim> On the phone I see Doug_Schepers, birtles, ed, cabanier, nikos, [IPcaller], +1.415.832.aaee, Tav
22:03:56 <heycam> … but just something that says "let's smoothly close this path" and it might not even be a new command
22:03:57 <krit> zakim, aaee is me
22:03:57 <Zakim> +krit; got it
22:04:19 <heycam> … it might be if you leave off the last value in something that should have a number of values, and you have a z, it smoothly interpolates to the first point
22:04:43 <heycam> … it's backwards compatible because not syntax uses that currently
22:04:52 <heycam> Tav: why do you even need the "z" then?
22:05:04 <heycam> shepazu: I think including the "z" makes it clearer
22:05:46 <Zakim> -birtles
22:06:54 <heycam> heycam: I think we should have an explicit indication that we are going back to the origin
22:06:57 <heycam> shepazu: we could use an "x" command
22:07:36 <heycam> … we don't need to add a new command for a smooth path end segment
22:08:25 <heycam> krit: we also need to specify the rendering behaviour
22:08:51 <heycam> shepazu: it is just the same as if you explicitly specify the final point, but you leave it out
22:09:00 <heycam> heycam: and you don't get marker-start/end
22:09:59 <heycam> shepazu: I think heycam and I are on the same page but thinking of something different from Olaf's suggestion
22:10:35 <heycam> krit: I'd like to see examples
22:10:44 <heycam> shepazu: I think it's already defined though
22:10:57 <heycam> Tav: there are two issues: one is a smooth join, and one is a join without the extra little piece with the z
22:11:14 <heycam> krit: isn't this something authoring tools should provide?
22:11:29 <heycam> shepazu: an authoring tool can provide any number of things. but this has a number of use cases, any time you're hand authoring
22:11:44 <heycam> … if you're making a generator, and you just want it to close with the original point, this prevents you from having to keep track of where the original point was
22:14:24 <heycam> shepazu: putting aside Olaf's proposal, this is what Cameron and I was thinking of
22:14:43 <heycam> … if you leave off the final point of a command and follow it by the "x" (or a "z", or however we decide that syntax to be)
22:14:46 <heycam> … you substitute in the origin point
22:14:52 <heycam> … let's assume there's always a z at the end
22:15:02 <heycam> … if you had the z in the path, you already need to track the start of the path
22:15:16 <heycam> … so this doesn't add any additional complexity to processing the path
22:15:48 <heycam> … it is a bit like error recovery, you have set behaviour for when you have exactly one too few points in your command, and you also end that subpath with a z
22:15:54 <heycam> krit: let's assume the last segment was a cubic curve
22:16:00 <heycam> … you need to to define the control points
22:17:43 <heycam> heycam: I think this allows you to have a closed path, where the final segment is not a straight line segment
22:17:51 <heycam> … and to not have markers painted because of that straight line segment
22:22:50 <heycam> shepazu: let's follow up with Dr Olaf, ask him to provide some visual examples of where this would be useful
22:24:57 <heycam> ACTION: Doug to reply to Dr Olaf's thread to ask for clarification on the proposal, whether the "x" or whatever closing idea might solve it
22:24:58 <trackbot> Created ACTION-3403 - Reply to Dr Olaf's thread to ask for clarification on the proposal, whether the "x" or whatever closing idea might solve it [on Doug Schepers - due 2012-12-13].
22:27:14 <heycam> RRSAgent: pointer?
22:27:14 <RRSAgent> See http://www.w3.org/2012/12/06-svg-irc#T22-27-14
22:27:56 <heycam> http://www.w3.org/2012/11/29-svg-irc
22:28:41 <ed> ok, telcons Dec 27, and Jan 3 (2013) are cancelled
22:30:01 <Zakim> -cabanier
22:30:02 <Zakim> -nikos
22:30:03 <Zakim> -[IPcaller]
22:30:03 <Zakim> -Tav
22:30:05 <Zakim> -Doug_Schepers
22:30:13 <Zakim> -krit
22:30:17 <Zakim> -ed
22:30:19 <Zakim> GA_SVGWG(SVG1)4:00PM has ended
22:30:19 <Zakim> Attendees were Doug_Schepers, cabanier, birtles, ed, +1.415.832.aaaa, krit, heycam, +61.2.980.5.aabb, nikos, +33.9.53.77.aacc, Tav, +1.415.832.aadd, [IPcaller], +1.415.832.aaee
22:30:24 <heycam> RRSAgent: make minutes
22:30:24 <RRSAgent> I have made the request to generate http://www.w3.org/2012/12/06-svg-minutes.html heycam
22:31:07 <heycam> Present: Erik, Cameron, Doug, Dirk, Tav, Rik, Nikos, Brian
22:31:08 <heycam> RRSAgent: make minutes
22:31:08 <RRSAgent> I have made the request to generate http://www.w3.org/2012/12/06-svg-minutes.html heycam
23:07:47 <thorton> thorton has joined #svg
23:15:13 <birtles> birtles has joined #svg