See also: IRC log
<nikos> knock knock
<ed> trackbot, start telcon
<trackbot> Date: 26 August 2014
<ed> Meeting: SVG WG F2F London 2014 Day 4
<ChrisL> scribenick: ChrisL
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
... 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?
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
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
... 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
... 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
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
... 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
... 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
<trackbot> action-3546 -- Cyril Concolato to Add piece commands to svg 2 specification -- due 2013-11-22 -- OPEN
<trackbot> action-3422 -- Cyril Concolato to Specify shared-path segments -- due 2013-02-11 -- OPEN
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
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
... 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
... 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
... 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
<nikos> scribenick: nikos
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
... 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
ed: in last paragraph of 13.9 it
... 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
... 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
... 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
... 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?
heycam: but with blending this
... 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?
cabanier: how about performance?
heycam: it'll be as performant as html
jwatt: supporting for us, doesn't
... 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?
heycam: use will as well
... 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].
birtles: We published a new WD in
... 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?
... 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
... we're moving off it
ChrisL: let me know when you have
something ready to publish
... will it be another WD?
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
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
... 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
... 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
... 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
... 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
... 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].
<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
... 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?
... 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
Tav: I got feedback from Andreas
... and they both would like to have the "top", "left", etc. keywords
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
... 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].
ed: we were discussing moving the
SVG test repo to either web-platform-tests or the csswg
... we had questions about which one to pick
jgraham: the long term goal I
think is to consolidate everything under
... 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
... 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
... 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
... 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
... 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].
ed: I created a wiki page for the
... 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
shepazu: there are two
... 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
... 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
... 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
This is scribe.perl Revision: 1.138 of Date: 2013-04-25 13:59:11 Check for newer version at 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 the 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: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda Found Date: 26 Aug 2014 Guessing minutes URL: http://www.w3.org/2014/08/26-svg-minutes.html People with action items: cameron dirk erik rik rossen tav[End of scribe.perl diagnostic output]