SVG Working Group Teleconference -- 06 Dec 2012

<trackbot> Date: 06 December 2012

<birtles> Zakim: IPcaller is me

<cabanier> * zakim is weird today*

<jarek> how do you join the teleconference?

<jarek> is it for w3c members only?

jarek: yes it is for working group members

Zakim: [ is me

Zakime, [IPcaller] is me

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

Sydney F2F

heycam: just brought this up last week to verify that we wouldn't change dates

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013 (needs details filled in)

ed: we have a wiki page

heycam: I think we still need a registration form though

<jarek> shepazu: no, I'm just interested in following the latest news on SVG 2

<scribe> ACTION: Cameron to set up a registration form for Sydney F2F 2013 [recorded in http://www.w3.org/2012/12/06-svg-minutes.html#action01]

<trackbot> Created ACTION-3401 - Set up a registration form for Sydney F2F 2013 [on Cameron McCormack - due 2012-12-13].

heycam: F2F is February 4 - 8, with half a day on Wednesday

krit: we should get the Tokyo dates fixed
... the chairs should coordinate with CSS

heycam: ok

birtles: I will talk to John who is hosting CSS

<birtles> also, for your planning, test the Web forward will likely be the week of 11 Feb

<birtles> Australia Day is 26 Jan so you might want to come early :)

http://wiki.csswg.org/planning/tokyo-2013

June 5 - 7

birtles: should we be only haing 2 days of SVG in that week? is that enough?

heycam: I'm happy to extend it backwards to start on the Sunday if people wanted to do that

birtles: or Saturday, and skip Sunday
... I'll talk to John and put forward a couple of suggestions

marker-pattern

ed: did we have anything more to discuss beyond last week's discussion?

heycam: not sure there was any progress

<krit> http://lists.w3.org/Archives/Public/www-svg/2012Nov/0072.html

krit: I sent an email, no response yet

<krit> [<distance> <url>]+

krit: I just want to make sure we have this basic syntax
... we might have other keywords around it, but hopefully the core of the syntax doesn't get more complicated than that

<krit> [<distance> <url>]+ [/ <marker-free-region>]? || [repeat | no-repeat]?

krit: to address heycam's offset issue, I have this syntax
... after the repeating distance/urls, you can have lengths from the left and right side where markers don't paint
... as well as the <marker-free-region>, do you have the initial length value to give the offset as in stroke-dashoffset?

<krit> <marker-free-region> = [ <distance> | auto ]{1,2}

krit: no, I think that syntax with the first length is hard to read
... that <marker-free-region> syntax is the same as background-size

heycam: what does auto mean?

krit: we could leave that off, it would just mean 0
... I think we should just keep one of the two offset interpretations, not both
... either the one that is like stroke-dashoffset, or the marker free regions

Tav: I think there are cases where you want to align the markers with the dashes

… you can think of borders on maps

… where you have dashes and you want the marker to be in the middle of the dash

heycam: and because you might use stroke-dashoffset on that, you would want it for the marker pattern too?

Tav: yes

heycam: I wonder if it makes sense to have a single offset, instead of per track

krit: I don't think that makes sense

Tav: this might get complicated too when we have adjusted strokes

krit: we could also have a separate marker-pattern-offset property

… a list of lengths

… I don't think putting everything into the marker shorthand is a good idea

heycam: I like having the marker-pattern-offset different from marker-pattern, so it can be animated

krit: this would be hard to animate with SMIL, but with CSS animation it would work

birtles: you can just define to SMIL to animate this

… how is this different from animate?

krit: it's a special case

birtles: we just define a new data type and how SMIL animates it

… I don't think it's SMIL that needs redefining, we just define how the data type animates

… as we define new data types we should define how they get animated

… CSS animations defines a bunch of base data types that are common

… but for example with CSS Transforms, it defines some new data types, and how they get animated

<krit> http://dev.w3.org/csswg/css3-background/#the-background

arc join naming

Tav: I sent an email with a list of possibilities

http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0053.html

Tav: the top four are arcs, claw, extrapolate, talon

nikos: extrapolate was the original one that was suggested

… what was wrong with it?

Tav: it's a bit long

heycam: I think there could be multiple ways of extrapolating, so I am not sure it describes it well

nikos: if you have to straights lines that converge, they will continue on?

Tav: it will fall back to miter

shepazu: there must be an existing graphics term for this

http://en.wikipedia.org/wiki/Woodworking_joints

ed: we can discuss a bit more. but I agree it should fit in well with the existing types.

heycam: I think arcs is the most uncontroversial to me

… least out there

Tav: note that it is two arcs, hence "arcs" not "arc"

birtles: I like claw because it makes sense straight or curved

back to marker-pattern

heycam: I just wanted to know whether this pattern of parallel of properties is something the CSS WG likes, or whether we should avoid

krit: the shorthand can be confusing

… but I don't think the CSS WG is against this way of specifying short hands

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.

heycam: right that's my concern, whether this way of specifying multiple properties with lists that match up is good or bad
... otoh I like being able to animate the individual parts of it, and not the whole shorthand

… it makes me wonder then whether the marker-pattern parts should be separated out into different properties too

heycam: just wondering if it makes sense to separate out the marker-free-region into a separate property
... just wonder whether it makes sense to break marker-pattern up further

Zakim: [IPcaller] is me

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

heycam: what about repeating a marker pattern over segments instead of the whole path?

krit: I think it would be fine to leave as a single marker on segments

heycam: how do you specify that in your proposal?

krit: marker-segment

heycam: ok, back to a separate property

krit: but Tab is not in favour of marker-segment and marker-pattern being separate
... would you want marker-segment as part of the marker shorthand?

heycam: I thought that it would be good to have the "blah" shorthand reset all "blah-*" properties

<krit> http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

… are there existing cases where this doesn't happen?

krit: in CSS Masking, there is the mask property and mask-box-image, which are both shorthands

<scribe> ACTION: Cameron to reply to Dirk's recent marker-pattern proposal [recorded in http://www.w3.org/2012/12/06-svg-minutes.html#action02]

<trackbot> Created ACTION-3402 - Reply to Dirk's recent marker-pattern proposal [on Cameron McCormack - due 2012-12-13].

fill/stroke url()s

krit: can we discuss this in the FX call?

… same for mask-type

SVG 2

krit: I don't think we've edited so much since the last WD

… I'd like to fix a bunch of things first before publishing a new WD

… maybe at the end of the Feb F2F meeting?

heycam: ok, that's fine

<nikos> http://www.w3.org/2012/10/25-svg-minutes.html#item03

… the publishing moratorium is coming up soon anyway, so it'll be hard to publish by this year

SVG 2 - suggestion for a new path command to close a subpath smoothly

heycam: I just skimmed the thread, but I think the idea seems OK to me

cabanier: I think it introduces a lot of details that need to be worked out

… it's more than just back flipping the initial control points and using them

… especially for arcs

… if you define it to close smoothly, and the previous point is an arc, how do you connect it?

… everyone does arcs to beziers differently

heycam: I think we can get around this by just inferring the final point of a user specified segment

shepazu: I'm not sure he was that fussed about how to specify it

… but just something that says "let's smoothly close this path" and it might not even be a new command

… 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

… it's backwards compatible because not syntax uses that currently

Tav: why do you even need the "z" then?

shepazu: I think including the "z" makes it clearer

heycam: I think we should have an explicit indication that we are going back to the origin

shepazu: we could use an "x" command

… we don't need to add a new command for a smooth path end segment

krit: we also need to specify the rendering behaviour

shepazu: it is just the same as if you explicitly specify the final point, but you leave it out

heycam: and you don't get marker-start/end

shepazu: I think heycam and I are on the same page but thinking of something different from Olaf's suggestion

krit: I'd like to see examples

shepazu: I think it's already defined though

Tav: there are two issues: one is a smooth join, and one is a join without the extra little piece with the z

krit: isn't this something authoring tools should provide?

shepazu: an authoring tool can provide any number of things. but this has a number of use cases, any time you're hand authoring

… 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

shepazu: putting aside Olaf's proposal, this is what Cameron and I was thinking of

… 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)

… you substitute in the origin point

… let's assume there's always a z at the end

… if you had the z in the path, you already need to track the start of the path

… so this doesn't add any additional complexity to processing the path

… 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

krit: let's assume the last segment was a cubic curve

… you need to to define the control points

heycam: I think this allows you to have a closed path, where the final segment is not a straight line segment

… and to not have markers painted because of that straight line segment

shepazu: let's follow up with Dr Olaf, ask him to provide some visual examples of where this would be useful

<scribe> 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 [recorded in http://www.w3.org/2012/12/06-svg-minutes.html#action03]

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

RRSAgent: pointer?

http://www.w3.org/2012/11/29-svg-irc

<ed> ok, telcons Dec 27, and Jan 3 (2013) are cancelled

RRSAgent: make minutes

- DRAFT -

SVG Working Group Teleconference

06 Dec 2012

Attendees

Contents