- From: Erik Dahlstrom <ed@opera.com>
- Date: Tue, 26 Aug 2014 16:21:02 +0200
- To: "www-svg@w3.org" <www-svg@w3.org>
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