minutes, December 7 2013 SVG WG telcon

http://www.w3.org/2012/12/06-svg-minutes.html


    [1]W3C

       [1] http://www.w3.org/

                                - DRAFT -

                     SVG Working Group Teleconference

06 Dec 2012

    [2]Agenda

       [2] 
http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0051.html

    See also: [3]IRC log

       [3] http://www.w3.org/2012/12/06-svg-irc

Attendees

    Present
           Erik, Cameron, Doug, Dirk, Tav, Rik, Nikos, Brian

    Regrets
    Chair
           Erik

    Scribe
           Cameron

Contents

      * [4]Topics
          1. [5]Sydney F2F
          2. [6]marker-pattern
          3. [7]arc join naming
          4. [8]back to marker-pattern
          5. [9]fill/stroke url()s
          6. [10]SVG 2
          7. [11]SVG 2 - suggestion for a new path command to close
             a subpath smoothly
      * [12]Summary of Action Items
      __________________________________________________________

    <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> [13]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013
    (needs details filled in)

      [13] http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Sydney_2013

    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
    [14]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 :)

    [15]http://wiki.csswg.org/planning/tokyo-2013

      [15] 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>
    [16]http://lists.w3.org/Archives/Public/www-svg/2012Nov/0072.ht
    ml

      [16] 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>
    [17]http://dev.w3.org/csswg/css3-background/#the-background

      [17] http://dev.w3.org/csswg/css3-background/#the-background

arc join naming

    Tav: I sent an email with a list of possibilities

    [18]http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDe
    c/0053.html

      [18] 
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

    [19]http://en.wikipedia.org/wiki/Woodworking_joints

      [19] 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>
    [20]http://dvcs.w3.org/hg/FXTF/raw-file/tip/masking/index.html

      [20] 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
    [21]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>
    [22]http://www.w3.org/2012/10/25-svg-minutes.html#item03

      [22] 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
    [23]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?

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

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

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

    RRSAgent: make minutes

    RRSAgent: make minutes

Summary of Action Items

    [NEW] ACTION: Cameron to reply to Dirk's recent marker-pattern
    proposal [recorded in
    [25]http://www.w3.org/2012/12/06-svg-minutes.html#action02]
    [NEW] ACTION: Cameron to set up a registration form for Sydney
    F2F 2013 [recorded in
    [26]http://www.w3.org/2012/12/06-svg-minutes.html#action01]
    [NEW] 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
    [27]http://www.w3.org/2012/12/06-svg-minutes.html#action03]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [28]scribe.perl version
     1.137 ([29]CVS log)
     $Date: 2012-12-06 22:31:13 $
      __________________________________________________________

      [28] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
      [29] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.137  of Date: 2012/09/20 20:19:01
Check for newer version at [30]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

      [30] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/Sydeny/Sydney/
Succeeded: s/8/7/
Succeeded: s/arc/arcs/
Succeeded: s/heycam/krit/
Found Scribe: Cameron
Found ScribeNick: heycam
Default Present: 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
Present: Erik Cameron Doug Dirk Tav Rik Nikos Brian
Agenda: [31]http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec
/0051.html
Found Date: 06 Dec 2012
Guessing minutes URL: [32]http://www.w3.org/2012/12/06-svg-minutes.html
People with action items: cameron doug

      [31] 
http://lists.w3.org/Archives/Public/public-svg-wg/2012OctDec/0051.html
      [32] http://www.w3.org/2012/12/06-svg-minutes.html

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.



    End of [33]scribe.perl diagnostic output]

      [33] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm

Received on Thursday, 6 December 2012 22:33:28 UTC