IRC log of svg on 2012-12-06

Timestamps are in UTC.

20:58:14 [RRSAgent]
RRSAgent has joined #svg
20:58:14 [RRSAgent]
logging to
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]
20:59:34 [Zakim]
20:59:43 [birtles]
Zakim: IPcaller is me
20:59:58 [Zakim]
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]
21:01:08 [jarek]
how do you join the teleconference?
21:01:23 [Zakim]
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]
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]
21:02:18 [heycam]
Zakim: [ is me
21:02:41 [ed]
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]
21:04:46 [heycam]
heycam: just brought this up last week to verify that we wouldn't change dates
21:05:17 [ed] (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]
+ +
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]
21:15:48 [heycam]
June 5 - 8
21:15:50 [heycam]
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]
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]
21:34:44 [Zakim]
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]
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]
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]
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]
21:49:37 [heycam]
heycam: just wonder whether it makes sense to break marker-pattern up further
21:49:44 [Zakim]
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]
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]
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]
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]
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]
22:02:22 [Zakim]
+ +1.415.832.aaee
22:02:32 [Zakim]
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]
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]
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]
22:27:56 [heycam]
22:28:41 [ed]
ok, telcons Dec 27, and Jan 3 (2013) are cancelled
22:30:01 [Zakim]
22:30:02 [Zakim]
22:30:03 [Zakim]
22:30:03 [Zakim]
22:30:05 [Zakim]
22:30:13 [Zakim]
22:30:17 [Zakim]
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, +, 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 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 heycam
23:07:47 [thorton]
thorton has joined #svg
23:15:13 [birtles]
birtles has joined #svg