SVG Working Group Teleconference -- 26 Aug 2014

<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> 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: 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> 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> 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> 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 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> 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 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 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 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 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 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 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> 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 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 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 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

- DRAFT -

SVG Working Group Teleconference

26 Aug 2014

Attendees

Contents

initial superpath implementation

hinting

z-index

Web Animations

stroke-position

Annotating the spec

Symbol reference position

Test repository

TPAC F2F

Units in path data

Summary of Action Items

Scribe.perl diagnostic output