W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2014

Minutes, SVG WG London F2F 2014 minutes, day 4

From: Erik Dahlstrom <ed@opera.com>
Date: Tue, 26 Aug 2014 16:21:02 +0200
To: "www-svg@w3.org" <www-svg@w3.org>
Message-ID: <op.xk7gxcrcgeuyw5@mbp>
Minutes:


     http://www.w3.org/2014/08/26-svg-minutes.html


as text below:


    [1]W3C

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

                                - DRAFT -

                     SVG Working Group Teleconference

26 Aug 2014

    [2]Agenda

       [2] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda

    See also: [3]IRC log

       [3] http://www.w3.org/2014/08/26-svg-irc

Attendees

    Present
           cyril, brian, dirk, tav, chris, rossen, erik, cameron,
           nikos, konno, doug, jet, jun, jwatt

    Regrets
    Chair
           ed

    Scribe
           ChrisL, nikos, heycam

Contents

      * [4]Topics
          1. [5]initial superpath implementation
          2. [6]hinting
          3. [7]z-index
          4. [8]Web Animations
          5. [9]stroke-position
          6. [10]Annotating the spec
          7. [11]Symbol reference position
          8. [12]Test repository
          9. [13]TPAC F2F
         10. [14]Units in path data
      * [15]Summary of Action Items
      __________________________________________________________

    <nikos> knock knock

    <nikos> heycam

    <ed> trackbot, start telcon

    <trackbot> Date: 26 August 2014

    <ed> Meeting: SVG WG F2F London 2014 Day 4

    <ChrisL> scribenick: ChrisL

initial superpath implementation

    <Cyril> [16]https://github.com/moissinac/SuperPath

      [16] https://github.com/moissinac/SuperPath

    Cyril: a colleague has been working on a polyfil, its on github

    ed: oh so it is a superpath

    Cyril: yes, re-using paths and joining them

    <heycam> Agenda:
    [17]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Age
    nda

      [17] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda

    Cyril: so to let you know this js impl exists,it expands the
    path references out into a full path
    ... see examples at end of github page
    ... does relative and abs coordinates in fwd and reverse order
    ... reusable sequence of commends
    ... shared paths referenced by ID

    ChrisL: a native implementation can avoid antialiasing bugs on
    the shared path when two filled shapes conjoin

    nikos: (describes an inline named subpath)

    shepazu: does proposal and polyfill deal with path direction?

    Cyril: yes

    shepazu: how does it deal with relative coords, are they
    normalized to absolute?

    Cyril: it computes the reversed path which is not trivial
    ... already have action to add this to the spec. what letter
    shall we use now?

    (discussion on separator to tell end of ID)

    heycam: just use the hash?

    Cyril: and for reversed?

    ChrisL: doug are you wanting relative coords preserved?

    shepazu: not necessarily
    ... need to define what the normalized path looks like

    Cyril: yes

    ChrisL: the normalized result

    heycam: ussuming use of normalized pathseglist, need to define
    effect of hash

    ed: does referenced path have to start with moveto?
    ... to make relative commands meaningful

    ChrisL: you won't know its valid until it is expanded

    <ed> you can of course do "m0,0" as the start of the referenced
    path

    shepazu: if you get the dom of the path then change it. or save
    back whole thing. do you loose the reference

    Cyril: same with modifying a normalized path now

    heycam: normPSL does not let you modify like that

    shepazu: (draws on board) retrieve the dom of the path

    ChrisL: need to add a second dom method that preserves the hash
    unexpanded

    shepazu: which letters

    heycam: I and J?

    I for insert

    shepazu: can lowercase mean not normalize?
    ... need to consider use cases for explicitly normalizing to
    absolute

    Tav: what about a minus to reverse -#

    shepazu: makes a difference if relative and re-referenced

    ed: referencing same path twice

    shepazu: then the serialization is critical

    ChrisL: yes its recalculating the coordinates of the path

    ed: say there is a transform on the path does it apply?

    Cyril: no, the ctm is not used here
    ... recursive path reuse should be forbidden

    ed: whatabout reversing?

    ChrisL: we have some spec language on detecting cycles

    ed: common to declare a transform and apply it

    Cyril: in different coord systems

    ChrisL: so coords are reinterpreted for the place they are used

    Cyril: yes

    Tav: looks like a pathref and we just got rid of tref. can it
    link to other docs

    ChrisL: ID not URI so restricted to same doc

    ed: but cross fragments in same doc
    ... is it a string or does it have to use the path parser? eg
    html data-foo agttribute?

    Cyril: must use ID of an element that has a path

    ed: so it depends on the right underlying objects

    ChrisL: do we want to exclude pulling data from html data-*
    attrs?

    Tav: random path would not draw if it misses the m at the
    beginning. invalid standalone path

    ChrisL: not clear we had a decision on requiring m

    Cyril: m is not disallowed

    ChrisL: better to wrap the subpaths inside defs

    Cyril: authoring advice

    ChrisL: need to explicitly say styling on original subpath are
    ignored

    Tav: path reversing is a unique feature

    Cyril: next steps, update polyfil more examples and multiple
    reusable relative subpaths

    shepazu: (reversing catmull-rom gives same path?)

    (we need to test this)

    Cyril: computing path length is straightforward
    ... rendering is after the path substitution
    ... some apis it makes sense to do post substitution
    ... itersating you want to know its a referenced command
    ... but some apis like get pathsegindex you want to count the
    referenced segments as well
    ... simplest is not expand by default then see which to add new
    args for expanded or not

    action-3546?

    <trackbot> action-3546 -- Cyril Concolato to Add piece commands
    to svg 2 specification -- due 2013-11-22 -- OPEN

    <trackbot>
    [18]http://www.w3.org/Graphics/SVG/WG/track/actions/3546

      [18] http://www.w3.org/Graphics/SVG/WG/track/actions/3546

    action-3422?

    <trackbot> action-3422 -- Cyril Concolato to Specify
    shared-path segments -- due 2013-02-11 -- OPEN

    <trackbot>
    [19]http://www.w3.org/Graphics/SVG/WG/track/actions/3422

      [19] http://www.w3.org/Graphics/SVG/WG/track/actions/3422

hinting

    Rossen_: feedback from people using svg as icons, they want
    hinting
    ... office and visual studio teams using svg as icons, moving
    away from fonts. complain small size icons have no control for
    making them sharp
    ... sothey ask where is the hinting
    ... also level of detail for different sizes
    ... unaware of anythingthat does the trick
    ... sharp joins, shallow curves, hinting may not help there.
    but some cases it does help

    ChrisL: this is the key differentiator between MS COLR font and
    SVG font - truetype hinting

    birtles: hinting only on windows?

    ChrisL: apple ignore hinting nowadays

    birtles: hinting is now seen as a legacy thing in some circles
    ... a school of thought says this will go away

    krit: we say that about a lot of things but they persist
    ... even with retiina you see details differently
    ... and contrast changes
    ... vertical lines in text you see hinting issues even on
    retina

    ChrisL: (declarative type1 sttyle hinting, but hard to test)

    Rossen_: could start from that

    shepazu: think its worth pursuing, want to see a concrete
    proposal

    birtles: is this about pixel alignemtn or level of detail as
    well

    Rossen_: in terms of pixel grid, not @media rules

    heycam: saw a blog post complaining about rendering of svg
    icons across browsers, impls differ

    Rossen_: even no noun project, vast differences in way some
    simple icons appear, on same device different impls

    <ed> [20]https://twitter.com/kaelig/status/494805682848550912

      [20] https://twitter.com/kaelig/status/494805682848550912

    rik: adobe has a shift by 0.5px export option "for web"

    krit: still have aliasing in some cases

    rik: flash player does that snap to 0.5 px

    ChrisL: is it possible now to define where the pixel position
    is?

    heycam: shape rendering allows some snap

    rik: canvas says the coordinate is in the middle of the pixel
    ... you want the stroke to be crisp

    jwatt: stroke crisp more important than fill

    Rossen_: underlines we render on pixel boundary but lines, esp
    one pixel borders suck if not poixel aligned

    krit: ios had scrolling issue with underlines getting thicker
    and thinner

    ChrisL: can we define same as canvas

    heycam: but that is the wrong way
    ... can we define the right way but allow shape rendring to
    snap to grid
    ... geometric precision means leave it on mathematical
    geometric position
    ... if line starts at 0.2 then it touches more pixels

    jwatt: browsers are consistent now
    ... dont break content
    ... easier too now transform on svg element to add 0.5px

    rik: what about with zoom

    ed: would pixel snap preserve squares as squares not
    rectangles?

    Rossen_: truetype has shape consistency regardless of pixel
    alignment

    ed: shape rendering doe snot deal with that currently

    Rossen_: and shape similarity musyt be [preserved

    rik: browser zoom keeps snapping to pixels, but today in svg it
    all gets blurry

    Rossen_: often on windows with higher dpi browsers go to higher
    zoom default but sacrifice image quality
    ... even at 2x we sometimes have problems
    ... wanted to put that ontable. will take an actin to get a
    proposal

    <scribe> ACTION: rossen to come up with hinting proposal for
    SVG [recorded in
    [21]http://www.w3.org/2014/08/26-svg-minutes.html#action01]

    <trackbot> Created ACTION-3657 - Come up with hinting proposal
    for svg [on Rossen Atanassov - due 2014-09-02].

    resolution: we will adopt a precision rendering mechanism for
    pixel-crisp SVG

    ** break**

    <nikos> scribenick: nikos

z-index

    <heycam>
    [22]https://svgwg.org/svg2-draft/painting.html#ZIndexProperty

      [22] https://svgwg.org/svg2-draft/painting.html#ZIndexProperty

    heycam: We've talked about z-index for a while - it's a
    requirement for SVG 2
    ... jwatt wrote up some text on a wiki which I've now added to
    the spec
    ... the text about stacking contexts was written a while ago
    before blending and compositing
    ... so either the list needs to be updated - e.g. to include
    mix-blend-mode
    ... or reference some other list if there is one available

    krit: every property must define if it creates a stacking
    context or not

    heycam: the list needs updating
    ... are you saying we have already added the wording to the
    properties?

    krit: in the specs that have properties that create stacking
    context we have

    cabanier: it's not going to be the same list as blending
    ... blending doesn't create a stacking context for clip
    ... but you do
    ... there's no reason clip should force you to do a stacking
    context

    krit: it does in html

    shepazu: how does this interact with 3d transforms?

    krit: 3d transforms create a stacking context

    shepazu: transform spec should define how it interacts with
    this z-index property

    ChrisL: needs a few examples because the way it works isn't
    intuitive

    <ChrisL> each 3d transform gets flattened and then the z-index
    happens

    Cyril: can you explain the paragraph that talks about the rules
    of css 2.1
    ... there is one exception

    heycam: in css z-index doesn't have any effect if element is
    static
    ... that sentence is there to make z-index apply always
    ... to avoid authors having to put z-index=something
    position:relative

    Cyril: the exception is the outer svg element?

    heycam: when you put z-index on the outer for inline content

    <ed> "Since the ‘foreignObject’ element creates a "fixed
    position containing block" in CSS terms," - is that actually
    defined for FO anywhere? is it part of being "inital containing
    block"?

    heycam: it's for the svg in the outer world

    Tav: do others plan on implementing?

    krit: how about performance in FF?

    heycam: don't think there will be issues

    (discussion on 2d transform not creating a stacking context in
    SVG)

    krit: I'm not sure we want different definitions of a stacking
    context in svg and css

    ChrisL: transforms are used a lot in SVG so if we make them
    have a stacking context z-index will be pointless

    krit: if you have html elements in svg then you have two models

    jwatt: css talks about when laying out with box model and is
    very specific about that

    cabanier: we've been talking about bringing box model into svg
    for some things

    ChrisL: our use of box model is very simplified - not talking
    about reflow or anything

    Rossen_: box model is just about margins, borders, etc. it's a
    very simple concept

    Cyril: there's a list of conditions for establishing a new
    stacking context
    ... 3rd bullet says ...

    3rd bullet point = the element is an outermost svg element, or
    a ‘foreignObject’, ‘image’, ‘marker’, ‘mask’, ‘pattern’,
    ‘symbol’ or ‘use’ element

    heycam: that should mention that it is only if positioned

    cabanier: I think that sentence should go away

    jwatt: my intention was to say that element is part of the box
    model

    Rossen_: z-index applies to grid items without position

    heycam: should say position value other than static then?

    Cyril: it's less error prone if you don't say positioned - say
    as defined in css

    jwatt: yes

    ed: in last paragraph of 13.9 it says ...
    ... is it actually defined that it does what is described
    there?

    heycam: we resolved it should be an initial containing block

    Rossen_: initial containing block is the only one that can
    contain fixed position things

    Cyril: I don't fully understand why fO behaves differently wrt
    back to front stacking order

    cabanier: seems some text is missing or it's wrong

    jwatt: should say the content of the fO
    ... because 4 point list is simplified version of css 2 rules
    ... it's saying for svg here's the simplified rules
    ... but for fO the full rules apply

    Cyril: can you rephrase it?
    ... and explain why this is a simplified model

    heycam: Doug, you
    ... Doug, you'll need to add where the outline is renderered

    shepazu: it would be immediately above the element, but before
    any other element
    ... rendered after

    heycam: can you add to last item in bullet list please?

    shepazu: there is a consideration for outlines being rendered
    at the very to of the viewport
    ... what if the item that has the focus is not actually
    visible?
    ... if it's obscured
    ... but you want to indicate it has focus

    heycam: if it's possible to bring the outline right up then you
    should be able to do that in html content
    ... but you can't do that at the moment

    shepazu: we should do whatever css and html does for now

    heycam: I just wanted to point out the section has been added
    and get reviews
    ... going back to that list - where is the rendering of the
    element

    Rossen_: what this is missing is the content layer where in css
    you will have the content layer being e.g. text
    ... it's also missing floats and inline blocks, etc
    ... so the element itself has already been rendered
    ... if you want to also say the object itself, e.g. a shape
    ... then it should be rendered in css, if we follow the
    equivalent of the content layer, it should be rendered after
    number 2
    ... background, borders, negative z, content layer, regular z

    shepazu: I will define background but we don't have it defined
    yet

    krit: svg element would need to define a new stacking context
    to ensure it doesn't interact with html?

    Rossen_: if it's not a full stacking context then you're going
    to be subject to interleaving with the html context
    ... which would not be good

    cabanier: except for blending we said an inline svg root is not
    a stacking context
    ... it's implemented that way

    krit: blending goes through the barrier of the stacking
    context?

    cabanier: no that's not it
    ... outer svg element is not a stacking context

    krit: but you've defined it based on properties. You don't use
    the term 'stacking context'

    cabanier: spec talks about stacking context for html - we don't
    blend through stacking contexts in html
    ... blending spec calls out some specific things that create
    isolated groups in svg - where isolated group is different from
    a stacking context
    ... isolated groups always force a stacking context, but not
    the other way around

    <ed> "Everything in CSS that creates a stacking context must be
    considered an ‘isolated’ group." is what the spec says

    heycam: Rossen, it sounds like you are expecting inline svg
    root to create a stacking context?

    Rossen_: yes

    heycam: but with blending this isn't compatible
    ... it's a stacking context, but not a black box image

    krit: it's confusing, but all works out

    cabanier: is there a lot of demand for z-index?

    heycam: yes

    cabanier: how about performance?

    heycam: it'll be as performant as html

    jwatt: supporting for us, doesn't add overhead
    ... if it's not used

    Tav: anyone else interested in implementing?

    krit: not in the short term, but long term we have to

    ed: it's not going to be easy

    krit: we would like to limit creation of stacking context as
    much as possible

    heycam: not all use of z-index will need a stacking context
    ... common case probably doesn't require additional stacking
    contexts

    krit: I want to make sure current docs will make more stacking
    contexts than they do now

    heycam: don't think the intention of the text is for that to
    happen
    ... krit, if you could review dot points to make sure it
    matches up with other specs

    Rossen_: does use create a stacking context?

    krit: why would it?
    ... by default it wouldn't

    heycam: web components will cause stacking context for shadow
    trees?

    ed: yes

    heycam: use will as well then
    ... I would be happy for list in z-index spec not being
    normative, point to other specs but give examples

    <scribe> ACTION: Rik to review z-index addition to SVG 2
    [recorded in
    [23]http://www.w3.org/2014/08/26-svg-minutes.html#action02]

    <trackbot> Created ACTION-3658 - Review z-index addition to svg
    2 [on Rik Cabanier - due 2014-09-02].

    <scribe> ACTION: Dirk to review z-index addition to SVG 2
    [recorded in
    [24]http://www.w3.org/2014/08/26-svg-minutes.html#action03]

    <trackbot> Created ACTION-3659 - Review z-index addition to svg
    2 [on Dirk Schulze - due 2014-09-02].

    <scribe> ACTION: Rossen to review z-index addition to SVG 2
    [recorded in
    [25]http://www.w3.org/2014/08/26-svg-minutes.html#action04]

    <trackbot> Created ACTION-3660 - Review z-index addition to svg
    2 [on Rossen Atanassov - due 2014-09-02].

Web Animations

    birtles: We published a new WD in June
    ... that incorporates some feedback from the TAG
    ... mostly fixing up API issues
    ... since then we've changed the player interface to use
    promises instead of events
    ... and also made it more asynchronous so that when you trigger
    an animation it doesn't always start straight away
    ... by default it will leave it to the browser to start timing
    from the moment it first paints it
    ... this avoids stutter at the start of the animation
    ... in terms of future spec work there's some more TAG feedback
    to address
    ... and the issue about defining animation tasks on the web
    platform
    ... more generically and thouroughly

    heycam: as in html task queues?

    birtles: yes
    ... interaction between web animations and other specs isn't
    well defined
    ... there's interest from a few people regarding speccing that
    properly
    ... order of taskss
    ... we're also moving spec to github and bikeshed
    ... Chrome is now shipping a very limited subset of the API
    ... which lets you create animations from script
    ... browser runs them on compositor in some cases
    ... you can't interact with the animations at all yet
    ... we're minimising surface area of API in first release
    ... in Gecko we've started implementing
    ... you can already see what animations are running and what
    they're up to
    ... next I'll add playback control for css animations
    ... target for both Chrome and FF is to get enough API
    implemented that lets you create animations from script and
    inspect those created with css
    ... and some playback control
    ... it's almost the whole spec but doesn't include animation
    groups, custom effects, and a few other features that are svg
    specific
    ... adding and building on animations
    ... plan is to split them out to next level
    ... but under discussion
    ... the other area we talked about yesterday is tying
    animations to scroll position and gestures
    ... but needs more investigation
    ... there's no official mapping between web animations and css.
    Google will work on it

    Cyril: mapping from web animations to svg animations?

    birtles: it exists but low priority at the moment
    ... will do it when I implement next year some time

    krit: do you think we could put fxtf repo under w3c?
    ... how do you publish latest version to w3c?

    birtles: we've yet to do that part of the transition
    ... will look at adding fxtf under w3c

    heycam: IDL now requires parameterised Promise types

    birtles: respec didn't allow that
    ... we're moving off it

    ChrisL: let me know when you have something ready to publish
    ... will it be another WD?

    birtles: yes

    Cyril: where are we in terms of svg features (including Tiny
    1.2) in web animations?

    birtles: current feature set should be able to express
    everything from 1.1
    ... there is some stuff beyond that, such as groups
    ... but that might get split to a later implementation

stroke-position

    heycam: stroke-position was on list of requirements for SVG 2
    ... it got cut
    ... it lets you specify if stroke is on inside or outside or
    current half/half

    ChrisL: that's a shame to lose that
    ... helps with text

    <ChrisL> it hellps a lot with stroking text without deforming
    letter shapes

    paint-order lets you do a lot of the stroke-position=outside
    stuff

    heycam: to get stroke-position=inside you can clip the shape to
    itself and double the stroke width

    krit: don't think that would work with overlapping paths

    ChrisL: these are work arounds and not as good

    heycam: dropping because of time and implementation difficulty
    ... libraries currently don't support this

    krit: you could use masking

    heycam: that would work
    ... might not be fastest solution

    shepazu: couldn't you separate stroke shape and fill shape and
    composite?

    heycam: the issue is the shape of the stroke
    ... you still have to compute the shape

    krit: the biggest difficulty is when doing dashing with rounded
    ends
    ... you can't just mask out part of the stroke

    Tav: that's what we would do - calculate the shape of the
    original path

    heycam: we are just relying on graphics libraries currently so
    it would be a bit of work to support that
    ... I brought it up because someone emailed me lamenting it's
    loss

    Tav: if we implemented in Inkscape and showed you how to do it
    would you be interested in adding it back to the spec?
    ... I'll see how hard it is to implement
    ... will try to find someone who's interested

    heycam: we already have code from Cairo which does the stroking
    ... so ideally it would be a modification of that

    jwatt: I think we'd like code that generates another path that
    is offset from the current path
    ... there will be a performance hit but it shouldn't be a
    commonly used feature

    shepazu: if you have a shape with a fill and the stroke is an
    offset outline that is larger than the shape
    ... you could have multiples
    ... whether we go whole hog and do all that, but those are
    possibilities that this feature opens up

    heycam: Jeremie Patonier wrote up spec text so that bit is done

    krit: would help implementers to say how to calculate the
    offset path

    cabanier: offsetting a stroke is very difficult

    jwatt: so algorithms are difficult, how is performance?

    krit: there's a noticeable performance impact

    heycam: constructing a normal stroke is just two offsetting
    operations? in and out?

    cabanier: issues that show up are more obvious - path sections
    may dissapear
    ... don't think the algorithm is that difficult, but it's very
    fiddly

    heycam: if you can supply me some performant code I'd a lot
    happier with the feature

    <scribe> ACTION: Tav to look at algorithms for path offsetting
    to support stroke-position [recorded in
    [26]http://www.w3.org/2014/08/26-svg-minutes.html#action05]

    <trackbot> Created ACTION-3661 - Look at algorithms for path
    offsetting to support stroke-position [on Tavmjong Bah - due
    2014-09-02].

    ***lunch***

Annotating the spec

    <ed> scribeNick: heycam

    shepazu: [shows annotations of web audio api]
    ... this is something we've been working on for a while
    ... the produce is called Annotator, by a non profit group
    called Hypothesis
    ... the idea is that you can annotate documents
    ... over on the right you see a bar, the "3+4" means 3 comments
    and 4 replies
    ... on the bottom right it says "14+3" so 17 comments on the
    spec
    ... you can click to open up the annotations
    ... you can see where in the spec they're based
    ... we could use annotations to track testable assertions, and
    reply to them to say where the tests are
    ... we'll deploy a bunch of preset tags for commenting on a
    spec
    ... "typo", etc.
    ... you can search by tag
    ... when you leave an annotation it sends a mail to a mailing
    list
    ... could be integrated into an issue tracker, or it could be
    an issue tracker itself, depending on how much of a tracker you
    need
    ... bots can make annotations for us
    ... now, when someone wants to comment on the spec, they need
    to subscribe to a list (and get the full firehose), listen
    specifically for replies to them
    ... which often doesn't happen for days/weeks/months
    ... this would let them listen to replies to their annotation,
    and respond when that happens
    ... so they don't have to pay attention to the WG, or know much
    about how to present their case to the WG
    ... it encourages an annotation per issue, rather than a big
    email with a bunch of issues
    ... it encourages people leave targetted comments on specific
    areas of the spec
    ... you can have owners for different sections of the spec, so
    individuals can get notifications for annotations in different
    areas
    ... we're planning on using this in the Annotation WG, others
    are welcome to use it too
    ... will be deployed in a month and a half or so

    Tav: looks good
    ... what happens when you make big changes to the document?

    shepazu: that's why we have the Annotations WG
    ... it will try to find the closest match
    ... if that fails, it'll become an orphaned annotation

    nikos: have you seen a tool called Peer Review? similar sort of
    tool we use internally.

    shepazu: right now we raise issues in the body of the spec. we
    could leave them as annotations instead.

    heycam: is there a way to make them appear inline?

    shepazu: not right now, but it could

    heycam: so just add a <script src></script> to add this to our
    spec?

    shepazu: yes
    ... one thing we're doing for webplatform.org is we want to
    annotate specs with the webplatform.org doc links

    Rossen_: why doesn't it work in IE?

    shepazu: it does but the robust anchoring doesn't work
    ... this version doesn't, because it's an older version. the
    new version does work in IE; if the annotations are broken at
    all it can't reanchor them.
    ... but that's an issue we're trying to fix
    ... I'll give you all a status update at TPAC

    krit: where's the databse for this?

    shepazu: the annotations are stored on notes.webplatform.org
    ... one last feature we want to have:
    ... often documentation is frequently out of date
    ... we're going to have each page in the documentation have a
    link to the spec that's defining the behaviour
    ... and watch for specification updates
    ... which then pings the documentation page with an annotation
    to get people to check what the spec changes are
    ... you can have private and public annotations too
    ... and you should be able to save them locally

Symbol reference position

    Tav: I got feedback from Andreas and Konno-san
    ... and they both would like to have the "top", "left", etc.
    keywords

    heycam: why?

    Tav: it's typically how they indicate these attachment points
    in the mapping community

    ChrisL: and it's simple to spec

    krit: it's easier to spec than to implement

    ed: if you have something that got promoted to a presentation
    attribute, can you put "center" instead of "50%"?
    ... those keywords are not part of length in CSS

    heycam: I don't think it's a difficult thing to support

    Rossen_: what is this for?

    Tav: with <symbol>, you want to align a position of the
    symbol's content to somewhere
    ... that's allowed for <symbol> now (refX, refY)
    ... Andreas asked if we could also allow top/center/bottom,
    left/center/right as a way of specifying that point
    ... since that's the most common things

    ed: we already have from the background syntax,
    left/right/center/etc.

    krit: sure. it's css though.

    <ed> s/background syntax/background syntax (for the new
    fill/stroke properties)

    ChrisL: given the community we're trying to reach here wants
    this, I think we should go for it

    Rossen_: should the percentage refX/refY still exist then?
    ... or is this sufficient?

    Tav: no that would already exist

    heycam: I think the only question is what would the
    SVGAnimatedLength object reflect
    ... we already decided to map new units to "unknown"
    SVGAnimatedLength values, so we could just do the same thing
    ... I think it's unnecessary but I won't object

    RESOLUTION: We will add top/center/bottom, left/center/right
    keywords to refX/refY on marker/symbol

    <scribe> ACTION: Tav to add top/center/bottom,
    left/center/right keywords to refX/refY on marker/symbol in the
    spec [recorded in
    [27]http://www.w3.org/2014/08/26-svg-minutes.html#action06]

    <trackbot> Created ACTION-3662 - Add top/center/bottom,
    left/center/right keywords to refx/refy on marker/symbol in the
    spec [on Tavmjong Bah - due 2014-09-02].

Test repository

    ed: we were discussing moving the SVG test repo to either
    web-platform-tests or the csswg repo
    ... we had questions about which one to pick

    jgraham: the long term goal I think is to consolidate
    everything under web-platform-tests
    ... I think the fact that css is separate is largely historical
    at this point
    ... they have some particular infrastructure they want to keep
    using
    ... but I think it makes more sense for the wider community to
    have exactly one place
    ... so you can say if you want to contribute tests, you put
    them here and follow this process
    ... rather than having different places/processes
    ... so it's convenient to put everything in one place
    ... it seems like the goal is to make that place
    web-platform-tests
    ... so I would definitely prefer that SVG uses that rather than
    using CSS'
    ... which would be something we need to transfer in the future
    ... we have some infrastructure that works better with
    web-platform-tests
    ... we have a test harness that can run the whole test suite
    ... it's set up to work with web-platform-tests specifically
    ... you sort of can run it against the CSS tests, but you need
    to start manually copying things around, so it's not really
    designed to work with that in a nice way

    heycam: we have tests we want to make reftests, plus scripted
    tests

    jgraham: you can put reftests in web-platform-tests
    ... we have a small test runner that will open test/reference
    in different tabs
    ... we also have a way to use something like WebDriver
    (marionette, or selenium) to run reftests automatically

    heycam: that works now?

    jgraham: yes, in Firefox. and I think someone worked on it for
    IE (using selenium). so I think it should work in Chrome too.

    krit: something we do in the FX specs is to get the test
    results in each section embedded in the spec

    jgraham: there's no standard thing for that. we don't have any
    database of results, which css does have
    ... my goal for this is that we push a lot of the generating of
    results upstream to browser vendors
    ... once browsers are running these tests in the CI, we
    standardise a JSON format that web-platform-tests can fetch for
    each browser

    krit: that's a plan for the future?

    jgraham: yes, it's not something we've done yet. but certainly
    what we've done for Gecko we could produce this data trivially.
    ... yes if you want to allow third parties to contribute
    results that end up in the spec, you need more infrastructure
    ... some people have objected to that in other contexts

    Tav: this would be how in INkscape we'd put our results in

    jgraham: if we had a standard format, as long as you could
    write that file you could contribute the results that way
    ... we have a format, but we haven't done the part where it
    adds annotations to a spec
    ... but definitely in the past, when people have suggested in
    other contexts that anybody should be allowed to submit test
    results, there have been objections to that
    ... so we've been avoiding that
    ... if you want to be included in the official test results you
    have to submit that

    heycam: is it in your roadmap for the in-spec annotations for
    test results?

    jgraham: not only CSS specs, I think XHR also has it too, but
    using another system
    ... my hope for all this is that we all help contribute tests
    to web-platform-tests. if any WGs have specific needs on top of
    web-platform-tests for example for test reviews, then groups
    can add additional metadata to the tests

    heycam: what's the review process for w-p-t?

    jgraham: the process it the normal GH work flow. file a PR,
    then somebody reviews that.
    ... we've mostly been using an external review system called
    Critic
    ... but if you have already written these tests as part of some
    open source project, which is already reviewed, you don't need
    to get additional review when merging the test into w-p-t

    heycam: do you have specific people reviewing specific spec's
    tests?

    jgraham: in theory anyone can review tests for any spec
    ... we let people review tests if we think they're going to be
    the right kind of person to review tests
    ... if you're a member of the WG we're happy to hand out review
    privs for the repo
    ... or if you're doing a lot of test work
    ... for particular directories/specs, if you want more
    stringent requirements, then that is possible. or it's possible
    to take the approach where you accept more tests in w-p-t, but
    then extra metadata on top of that to say which ones the WG has
    validated.

    shepazu: I like the idea of using w-p-t

    krit: the thing I would still like to know is that tests in the
    repo are bound to particular parts of the spec
    ... so they have metadata in there
    ... but w-p-t tests don't?

    jgraham: one of the philosophies is to minimise the metadata
    people have to add
    ... for various reasons

    krit: but there is a good side to having the metadata
    ... you know which parts of the spec are tested

    ChrisL: it helps understanding the tests, reviewing them for
    correctness

    jgraham: there is of course a cost. there's the option for
    adding metadata, if you want to add it.
    ... but we're not going to force test contributors to add it
    ... the metadata is never entirely accurate, it's testing one
    bit of the spec but it's also relying on various other parts of
    the spec

    ChrisL: that's certainly true. two ways around that. one is to
    have a pre-set of tests, and for a given impl if it doesn't
    pass 100% of those, all the things depending on that are not
    counted
    ... CSS tests do allow you to point to multiple parts of the
    spec

    jgraham: so you are allowed to add metadata like that. if CSS
    want to have the requirement to have that metadata, that would
    be a way they could use this concept of having a pool of tests,
    but only ones where people have bothered to add the metadata
    are considered accepted tests
    ... in the long term, I'm hoping we can get more data out of
    things like coverage tools, if you run this test suite which
    bit sof the implementation are we hitting

    krit: I don't care where we put the tests. but I would like to
    know which parts of the spec are tested.

    ChrisL: shepherd doesn't care where the tests live, as long as
    it has a pointer to them
    ... the CSSWG have metadata requirements which are generally
    onerous for fly-by contributions, but helpful for people
    actively working on it
    ... you can have a curated list of a subset of tests that have
    been reviewed, or have the metadata we want
    ... a way forward is to say we want to have a moderate level of
    metadata, tests in w-p-t, manage the results shepherd
    ... then we get the best of both worlds

    heycam: does the metadata live inside the test?

    jgraham: there are two types. explicit metadata, <meta
    name=...>
    ... in the test
    ... then there's implicit metadata, so one of the typical
    things we do with w-p-t is to organise the test dir structure
    in a way that mirrors the spec
    ... in HTML, we have each section in the spec down to 3 levels
    deep, and put the tests in those sections
    ... also things like git author information is in there. so you
    don't need to type in the author for every test.

    heycam: that dir structure is common in w-p-t?

    jgraham: yes. in html we use it. some smaller specs go flat.
    ... I think ther was some tooling around generating section
    boxes. I think robin was working on this a year or two ago.

    heycam: I think that sounds like a good way to go

    RESOLUTION: SVG tests will live in web-platform-tests, with
    Shepherd managing test results.

    jgraham: the docs on testthewebforward.org is a little out of
    date now

    ed: who handles who is a reviewer of tests?

    jgraham: in principle anyone can be. you can constrain it if
    it's necessary. typically so far there have been 4 or 5 people
    who have done most of the review for most things.
    ... then a few people concentrating on specs that they know
    ... two points to the review. is this test right per spec? and,
    is this using w-p-t features properly/

    <scribe> ACTION: Cameron to add a couple of SVG tests to w-p-t
    and mail the WG with those examples. [recorded in
    [28]http://www.w3.org/2014/08/26-svg-minutes.html#action07]

    <trackbot> Created ACTION-3663 - Add a couple of svg tests to
    w-p-t and mail the wg with those examples. [on Cameron
    McCormack - due 2014-09-02].

TPAC F2F

    <ed> [29]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014

      [29] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2014

    ed: I created a wiki page for the meeting
    ... with pointers to the TPAC registration forms

    <ChrisL> registration here
    [30]https://www.w3.org/2002/09/wbs/35125/TPAC2014/

      [30] https://www.w3.org/2002/09/wbs/35125/TPAC2014/

    krit: you wanted to have the meeting on Mon/Tue. did that not
    work out?
    ... it became Thu/Fri

    ed: will we have people calling in? we need to request
    equipment if so.

    birtles: not sure if I'll be there

    ChrisL: if nobody will be calling in, we should indicate we
    don't need the polycom since it costs

    <scribe> ACTION: Erik to mail the list asking if we need the
    polycom for TPAC [recorded in
    [31]http://www.w3.org/2014/08/26-svg-minutes.html#action08]

    <trackbot> Created ACTION-3664 - Mail the list asking if we
    need the polycom for tpac [on Erik Dahlström - due 2014-09-02].

    <ed> trackbot, end telcon

Units in path data

    shepazu: there are two things
    ... one, the idea of units in paths
    ... second, just percentages
    ... I don't care about using px or cm, etc.

    krit: vw/vh would still be useful
    ... maybe em

    ed: we'd need to think about whether it clashes with the
    existing path syntax
    ... you'd need to change the parser. there might be cases where
    they clash.

    krit: currently they don't
    ... all the length units have two letters

    shepazu: my biggest frustration with doing things with paths is
    not being able to have part of them relative to other things
    ... we could have a path around some text

    heycam: it's still an approximation

    shepazu: will people want to change these via CSS?

    krit: there is a proposal to make the d="" attribute a property
    ... which takes a path() CSS function value
    ... there are certain use cases in CSS as well

    shepazu: what are the obstacles to this?

    krit: the SVG DOM path reflections would need changing

    ChrisL: if you have a 'd' property what does it mean when it's
    applied to other elements
    ... I can see benefit for CSS having shapes other than
    rectangles/ellipses

    shepazu: we should start from the use cases here

    krit: the use cases are most for SVG in HTML, where people want
    to have the path relative to the viewport

    heycam: another problem is that caching of internal graphics
    library path objects is more complex since it's now parametric
    in font size, %-base, etc.

    <scribe> ACTION: Dirk to gather use cases that might be solved
    by units in path data [recorded in
    [32]http://www.w3.org/2014/08/26-svg-minutes.html#action09]

    <trackbot> Created ACTION-3665 - Gather use cases that might be
    solved by units in path data [on Dirk Schulze - due
    2014-09-02].

    krit: but I am sure these use cases will be real once we allow
    paths in CSS (basic shapes)

    shepazu: we have an opportunity to influence the alignment with
    CSS here
    ... by resisting this we could put off this change, but it will
    likely happen in CSS
    ... I think if we want to expose some units we should do all

    Rossen_: how do the percentages resolve?

    krit: you know whether it's an x or y coordinate, so against
    the viewport size in that dimension

    birtles: that wouldn't work with turtle graphics

    shepazu: let's look at the use cases

Summary of Action Items

    [NEW] ACTION: Cameron to add a couple of SVG tests to w-p-t and
    mail the WG with those examples. [recorded in
    [33]http://www.w3.org/2014/08/26-svg-minutes.html#action07]
    [NEW] ACTION: Dirk to gather use cases that might be solved by
    units in path data [recorded in
    [34]http://www.w3.org/2014/08/26-svg-minutes.html#action09]
    [NEW] ACTION: Dirk to review z-index addition to SVG 2
    [recorded in
    [35]http://www.w3.org/2014/08/26-svg-minutes.html#action03]
    [NEW] ACTION: Erik to mail the list asking if we need the
    polycom for TPAC [recorded in
    [36]http://www.w3.org/2014/08/26-svg-minutes.html#action08]
    [NEW] ACTION: Rik to review z-index addition to SVG 2 [recorded
    in [37]http://www.w3.org/2014/08/26-svg-minutes.html#action02]
    [NEW] ACTION: rossen to come up with hinting proposal for SVG
    [recorded in
    [38]http://www.w3.org/2014/08/26-svg-minutes.html#action01]
    [NEW] ACTION: Rossen to review z-index addition to SVG 2
    [recorded in
    [39]http://www.w3.org/2014/08/26-svg-minutes.html#action04]
    [NEW] ACTION: Tav to add top/center/bottom, left/center/right
    keywords to refX/refY on marker/symbol in the spec [recorded in
    [40]http://www.w3.org/2014/08/26-svg-minutes.html#action06]
    [NEW] ACTION: Tav to look at algorithms for path offsetting to
    support stroke-position [recorded in
    [41]http://www.w3.org/2014/08/26-svg-minutes.html#action05]

    [End of minutes]
      __________________________________________________________


     Minutes formatted by David Booth's [42]scribe.perl version
     1.138 ([43]CVS log)
     $Date: 2014-08-26 15:18:38 $
      __________________________________________________________

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

Scribe.perl diagnostic output

    [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [44]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

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

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/subpath/superpath/
Succeeded: s/wasnt/want/
Succeeded: s/scg/svg/
Succeeded: s/t hat/that/
Succeeded: s/we blend through stacking/we don't blend through stacking/
Succeeded: s/flex items/grid items/
Succeeded: s/parameterised types/parameterised Promise types/
Succeeded: s/helps/encourages/
WARNING: Bad s/// command: s/background syntax/background syntax (for th
e new fill/stroke properties)
Found ScribeNick: ChrisL
Found ScribeNick: nikos
Found ScribeNick: heycam
Inferring Scribes: ChrisL, nikos, heycam
Scribes: ChrisL, nikos, heycam
ScribeNicks: ChrisL, nikos, heycam
Present: cyril brian dirk tav chris rossen erik cameron nikos konno doug
  jet jun jwatt
Agenda: [45]https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agen
da
Found Date: 26 Aug 2014
Guessing minutes URL: [46]http://www.w3.org/2014/08/26-svg-minutes.html
People with action items: cameron dirk erik rik rossen tav

      [45] https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda
      [46] http://www.w3.org/2014/08/26-svg-minutes.html


    [End of [47]scribe.perl diagnostic output]

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


-- 
Erik Dahlstrom, Web Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Received on Tuesday, 26 August 2014 15:21:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:20 UTC