IRC log of svg on 2014-08-26

Timestamps are in UTC.

00:01:01 [stakagi_]
stakagi_ has joined #svg
00:27:57 [thorton]
thorton has joined #svg
05:03:39 [jun]
jun has joined #svg
05:38:14 [Tav]
Tav has joined #svg
05:40:15 [jdaggett]
jdaggett has joined #svg
06:10:43 [jdaggett]
jdaggett has joined #svg
06:27:53 [tkonno]
tkonno has joined #svg
06:57:32 [shepazu]
shepazu has joined #svg
07:57:26 [nikos]
nikos has joined #svg
07:57:35 [nikos]
knock knock
07:57:56 [nikos]
08:01:49 [Cyril]
Cyril has joined #svg
08:02:06 [tkonno]
tkonno has joined #svg
08:04:55 [nikos_]
nikos_ has joined #svg
08:09:53 [nikos__]
nikos__ has joined #svg
08:19:55 [ChrisL]
ChrisL has joined #svg
08:20:18 [ed]
trackbot, start telcon
08:20:20 [trackbot]
RRSAgent, make logs public
08:20:20 [Zakim]
Zakim has joined #svg
08:20:22 [trackbot]
Zakim, this will be GA_SVGWG
08:20:22 [Zakim]
I do not see a conference matching that name scheduled within the next hour, trackbot
08:20:23 [trackbot]
Meeting: SVG Working Group Teleconference
08:20:23 [trackbot]
Date: 26 August 2014
08:20:37 [Rossen_]
Rossen_ has joined #svg
08:21:41 [ed]
Meeting: SVG WG F2F London 2014 Day 4
08:21:51 [ed]
08:21:55 [ed]
chair: ed
08:23:01 [ed]
present: cyril, brian, dirk, tav, chris, rossen, erik, cameron, nikos, konno
08:24:01 [ed]
present+ doug
08:26:03 [jwatt]
jwatt has joined #svg
08:26:58 [nikos]
nikos has joined #svg
08:27:02 [shepazu]
shepazu has joined #svg
08:32:17 [ChrisL]
scribenick: ChrisL
08:32:32 [ChrisL]
topic: initial subpath implementation
08:33:03 [Cyril]
08:33:04 [ChrisL]
Cyril: a colleague has been working on a polyfil, its on github
08:33:34 [ChrisL]
ed: oh so it is a superpath
08:33:41 [ed]
08:33:47 [ChrisL]
Cyril: yes, re-using paths and joining them
08:34:16 [heycam]
08:34:20 [Tav]
Tav has joined #svg
08:34:47 [ChrisL]
Cyril: so to let you know this js impl exists,it expands the path references out into a full path
08:34:55 [shepazu]
08:34:58 [ChrisL]
... see examples at end of github page
08:35:25 [ChrisL]
... does relative and abs coordinates in fwd and reverse order
08:35:38 [ed]
present+ jet
08:35:42 [ChrisL]
Cyril: reusable sequence of commends
08:35:47 [ChrisL]
08:36:50 [ChrisL]
Cyril: shared paths referenced by ID
08:36:53 [jet]
jet has joined #svg
08:37:48 [ChrisL]
ChrisL: a native implementation can avoid antialiasing bugs on the shared path when two filled shapes conjoin
08:38:35 [ChrisL]
nikos: (describes an inline named subpath)
08:38:52 [ChrisL]
shepazu: does proposal and polyfill deal with path direction?
08:38:54 [ChrisL]
Cyril: yes
08:39:26 [ChrisL]
shepazu: how does it deal with relative coords, are they normalized to absolute?
08:39:48 [ChrisL]
Cyril: it computes the reversed path which is not trivial
08:40:21 [ChrisL]
Cyril: already have action to add this to the spec. what letter shall we use now?
08:41:08 [ChrisL]
(discussion on separator to tell end of ID)
08:41:56 [ChrisL]
heycam: just use the hash?
08:42:02 [ChrisL]
Cyril: and for reversed?
08:42:42 [ChrisL]
ChrisL: doug are you wanting relative coords preserved?
08:42:49 [ChrisL]
shepazu: not necessarily
08:43:09 [ChrisL]
shepazu: need to define what the normalized path looks like
08:43:19 [ChrisL]
Cyril: yes
08:43:38 [ChrisL]
ChrisL: the normalized result
08:43:40 [ed]
present+ jun
08:44:17 [ChrisL]
heycam: ussuming use of normalized pathseglist, need to define effect of hash
08:44:41 [ChrisL]
ed: does referenced path have to start with moveto?
08:44:52 [ChrisL]
... to make relative commands meaningful
08:45:19 [ChrisL]
ChrisL: you won't know its valid until it is expanded
08:45:58 [ed]
you can of course do "m0,0" as the start of the referenced path
08:46:12 [ChrisL]
shepazu: if you get the dom of the path then change it. or save back whole thing. do you loose the reference
08:46:37 [ChrisL]
Cyril: same with modifying a normalized path now
08:47:13 [ChrisL]
heycam: normPSL does not let you modify like that
08:47:21 [jun]
jun has joined #svg
08:48:06 [ChrisL]
shepazu: (draws on board) retrieve the dom of the path
08:48:48 [ChrisL]
ChrisL: need to add a second dom method that preserves the hash unexpanded
08:48:58 [ChrisL]
shepazu: which letters
08:49:29 [ChrisL]
heycam: I and J?
08:49:35 [ChrisL]
I for insert
08:49:51 [ChrisL]
shepazu: can lowercase mean not normalize?
08:50:56 [ChrisL]
shepazu: need to consider use cases for explicitly normalizing to absolute
08:51:33 [ChrisL]
Tav: what about a minus to reverse -#
08:51:57 [ChrisL]
shepazu: makes a difference if relative and re-referenced
08:52:29 [ChrisL]
ed: referencing same path twice
08:52:51 [ChrisL]
shepazu: then the serialization is critical
08:53:17 [ChrisL]
ChrisL: yes its recalculating the coordinates of the path
08:54:30 [ed]
present+ jwatt
08:54:58 [ChrisL]
ed: say there is a transform on the path does it apply?
08:55:08 [ChrisL]
Cyril: no, the ctm is not used here
08:55:37 [ChrisL]
Cyril: recursive path reuse should be forbidden
08:55:48 [ChrisL]
ed: whatabout reversing?
08:57:00 [ChrisL]
ChrisL: we have some spec language on detecting cycles
08:57:11 [ChrisL]
ed: common to declare a transform and apply it
08:57:19 [ChrisL]
Cyril: in different coord systems
08:57:54 [ChrisL]
ChrisL: so coords are reinterpreted for the place they are used
08:57:57 [ChrisL]
Cyril: yes
08:58:51 [ChrisL]
Tav: looks like a pathref and we just got rid of tref. can it link to other docs
08:59:01 [ChrisL]
ChrisL: ID not URI so restricted to same doc
08:59:18 [ChrisL]
ed: but cross fragments in same doc
09:00:04 [ChrisL]
ed: is it a string or does it have to use the path parser? eg html data-foo agttribute?
09:00:17 [ChrisL]
Cyril: must use ID of an element that has a path
09:00:39 [ChrisL]
ed: so it depends on the right underlying objects
09:01:15 [ChrisL]
ChrisL: do we want to exclude pulling data from html data-* attrs?
09:02:20 [ChrisL]
Tav: random path would not draw if it misses the m at the beginning. invalid standalone path
09:02:48 [ChrisL]
ChrisL: not clear we had a decision on requiring m
09:02:53 [ChrisL]
Cyril: m is not disallowed
09:03:36 [ChrisL]
ChrisL: better to wrap the subpaths inside defs
09:03:42 [ChrisL]
Cyril: authoring advice
09:04:53 [ChrisL]
ChrisL: need to explicitly say styling on original subpath are ignored
09:06:06 [ChrisL]
Tav: path reversing is a unique feature
09:07:05 [ChrisL]
Cyril: next steps, update polyfil more examples and multiple reusable relative subpaths
09:08:22 [ChrisL]
shepazu: (reversing catmull-rom gives same path?)
09:08:29 [ChrisL]
(we need to test this)
09:09:03 [ChrisL]
Cyril: computing path length is straightforward
09:09:44 [ChrisL]
Cyril: rendering is after the path substitution
09:10:09 [ChrisL]
Cyril: some apis it makes sense to do post substitution
09:10:24 [ChrisL]
... itersating you want to know its a referenced command
09:10:48 [ChrisL]
... but some apis like get pathsegindex you wasnt to count the referenced segments as well
09:11:05 [ChrisL]
... simplest is not expand by default then see which to add new args for expanded or not
09:11:17 [heycam]
09:11:50 [ChrisL]
09:11:50 [trackbot]
action-3546 -- Cyril Concolato to Add piece commands to svg 2 specification -- due 2013-11-22 -- OPEN
09:11:50 [trackbot]
09:11:57 [ChrisL]
09:11:57 [trackbot]
action-3422 -- Cyril Concolato to Specify shared-path segments -- due 2013-02-11 -- OPEN
09:11:57 [trackbot]
09:12:16 [ChrisL]
topic: hinting
09:12:50 [ChrisL]
Rossen_: feedback from people using svg as icons, they want hinting
09:13:29 [ChrisL]
... office and visual studio teams using svg as icons, moving away from fonts. complain small size icons have no control for making them sharp
09:13:38 [ChrisL]
... sothey ask where is the hinting
09:14:01 [ChrisL]
... also level of detail for different sizes
09:14:13 [ChrisL]
... unaware of anythingthat does the trick
09:14:15 [ChrisL]
09:14:42 [ChrisL]
Rossen_: sharp joins, shallow curves, hinting may not help there. but some cases it does help
09:16:28 [ChrisL]
ChrisL: this is the key differentiator between MS COLR font and SVG font - truetype hinting
09:16:43 [ChrisL]
birtles: hinting only on windows?
09:17:03 [ChrisL]
ChrisL: apple ignore hinting nowadays
09:17:20 [ChrisL]
birtles: hinting is now seen as a legacy thing in some circles
09:17:55 [ChrisL]
birtles: a school of thought says this will go away
09:18:06 [ChrisL]
krit: we say that about a lot of things but they persist
09:18:29 [ChrisL]
krit: even with retiina you see details differently
09:18:36 [ChrisL]
... and contrast changes
09:18:48 [ChrisL]
q+ blue hints
09:19:40 [ChrisL]
krit: vertical lines in text you see hinting issues even on retina
09:21:33 [ChrisL]
ChrisL: (declarative type1 sttyle hinting, but hard to test)
09:22:00 [ChrisL]
Rossen_: could start from that
09:22:15 [ChrisL]
shepazu: think its worth pursuing, want to see a concrete proposal
09:22:37 [ChrisL]
birtles: is this about pixel alignemtn or level of detail as well
09:22:53 [ChrisL]
Rossen_: in terms of pixel grid, not @media rules
09:23:26 [ChrisL]
heycam: saw a blog post complaining about rendering of svg icons across browsers, impls differ
09:23:58 [ChrisL]
Rossen_: even no noun project, vast differences in way some simple icons appear, on same device different impls
09:24:24 [ed]
09:25:12 [ChrisL]
rik: adobe has a shift by 0.5px export option "for web"
09:25:40 [ChrisL]
krit: still have aliasing in some cases
09:25:56 [ChrisL]
rik: flash player does that snap to 0.5 px
09:27:42 [ChrisL]
ChrisL: is it possible now to define where the pixel position is?
09:28:05 [ChrisL]
heycam: shape rendering allows some snap
09:29:04 [ChrisL]
rik: canvas says the coordinate is in the middle of the pixel
09:29:19 [ChrisL]
rik: you want the stroke to be crisp
09:29:42 [ChrisL]
jwatt: stroke crisp more important than fill
09:30:11 [ChrisL]
Rossen_: underlines we render on pixel boundary but lines, esp one pixel borders suck if not poixel aligned
09:30:35 [ChrisL]
krit: ios had scrolling issue with underlines getting thicker and thinner
09:31:08 [ChrisL]
ChrisL: can we define same as canvas
09:31:16 [ChrisL]
heycam: but that is the wrong way
09:31:33 [ChrisL]
... can we define the right way but allow shape rendring to snap to grid
09:32:00 [ChrisL]
... geometric precision means leave it on mathematical geometric position
09:32:36 [ChrisL]
heycam: if line starts at 0.2 then it touches more pixels
09:32:52 [ChrisL]
jwatt: browsers are consistent now
09:33:10 [ChrisL]
... dont break content
09:34:45 [ChrisL]
jwatt: easier too now transform on svg element to add 0.5px
09:34:54 [ChrisL]
rik: what about with zoom
09:35:31 [ChrisL]
ed: would pixel snap preserve squares as squares not rectangles?
09:35:49 [ChrisL]
Rossen_: truetype has shape consistency regardless of pixel alignment
09:36:02 [ChrisL]
ed: shape rendering doe snot deal with that currently
09:36:17 [ChrisL]
Rossen_: and shape similarity musyt be [preserved
09:36:48 [ChrisL]
rik: browser zoom keeps snapping to pixels, but today in scg it all gets blurry
09:36:53 [ChrisL]
09:37:28 [ChrisL]
Rossen_: often on windows with higher dpi browsers go to higher zoom default but sacrifice image quality
09:38:30 [ChrisL]
Rossen_: even at 2x we sometimes have problems
09:38:48 [ChrisL]
Rossen_: wanted to put that ontable. will take an actin to get a proposal
09:39:09 [ChrisL]
action: rossen to come up with hinting proposal for SVG
09:39:09 [trackbot]
Created ACTION-3657 - Come up with hinting proposal for svg [on Rossen Atanassov - due 2014-09-02].
09:41:50 [ChrisL]
resolution: we will adopt a precision rendering mechanism for pixel-crisp SVG
09:42:06 [ChrisL]
** break**
09:52:28 [jun]
jun has joined #svg
10:06:36 [jun]
jun has joined #svg
10:06:43 [nikos]
nikos has joined #svg
10:06:58 [stakagi]
stakagi has joined #svg
10:09:35 [stakagi]
stakagi has joined #svg
10:10:10 [nikos]
scribenick: nikos
10:10:15 [nikos]
Topic: z-index
10:10:45 [jwatt]
jwatt has joined #svg
10:11:00 [heycam]
10:11:21 [nikos]
heycam: We've talked about z-index for a while - it's a requirement for SVG 2
10:11:33 [nikos]
... jwatt wrote up some text on a wiki which I've now added to the spec
10:12:07 [nikos]
... the text about stacking contexts was written a while ago before blending and compositing
10:12:20 [nikos]
... so either the list needs to be updated - e.g. to include mix-blend-mode
10:12:26 [nikos]
... or reference some other list if there is one available
10:12:44 [nikos]
krit: every property must define if it creates a stacking context or not
10:12:50 [nikos]
heycam: the list needs updating
10:12:59 [nikos]
... are you saying we have already added the wording to the properties?
10:13:15 [nikos]
krit: in the specs that have properties that create stacking context we have
10:13:26 [nikos]
cabanier: it's not going to be the same list as blending
10:13:37 [nikos]
... blending doesn't create a stacking context for clip
10:13:39 [nikos]
... but you do
10:13:56 [nikos]
... there's no reason clip should force you to do a stacking context
10:13:59 [nikos]
krit: it does in html
10:14:32 [nikos]
shepazu: how does this interact with 3d transforms?
10:14:39 [nikos]
krit: 3d transforms create a stacking context
10:15:08 [nikos]
shepazu: transform spec should define how it interacts with this z-index property
10:15:41 [nikos]
ChrisL: needs a few examples because the way it works isn't intuitive
10:16:03 [stakagi_]
stakagi_ has joined #svg
10:16:24 [ChrisL]
each 3d transform gets flattened and then the z-index happens
10:16:31 [nikos]
Cyril: can you explain the paragraph that talks about the rules of css 2.1
10:16:33 [Rossen_]
Rossen_ has joined #svg
10:16:38 [nikos]
... there is one exception
10:16:55 [nikos]
heycam: in css z-index doesn't have any effect if element is static
10:17:04 [nikos]
... that sentence is there to make z-index apply always
10:17:21 [nikos]
... to avoid authors having to put z-index=something position:relative
10:17:39 [nikos]
Cyril: the exception is the outer svg element?
10:17:51 [nikos]
heycam: when you put z-index on the outer for inline content
10:18:00 [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"?
10:18:05 [nikos]
... it's for the svg in the outer world
10:18:34 [nikos]
Tav: do others plan on implementing?
10:18:42 [nikos]
krit: how about performance in FF?
10:18:46 [nikos]
heycam: don't think there will be issues
10:19:17 [konno]
konno has joined #svg
10:19:26 [jet]
jet has joined #svg
10:19:48 [nikos]
(discussion on 2d transform not creating a stacking context in SVG)
10:20:11 [nikos]
krit: I'm not sure we want different definitions of a stacking context in svg and css
10:20:46 [nikos]
ChrisL: transforms are used a lot in SVG so if we make them have a stacking context z-index will be pointless
10:21:31 [konno]
konno has joined #svg
10:21:51 [nikos]
krit: if you have html elements in svg then you have two models
10:22:25 [nikos]
jwatt: css talks about when laying out with box model and is very specific about that
10:22:40 [nikos]
cabanier: we've been talking about bringing box model into svg for some things
10:23:03 [nikos]
ChrisL: our use of box model is very simplified - not talking about reflow or anything
10:23:17 [nikos]
Rossen_: box model is just about margins, borders, etc. it's a very simple concept
10:23:31 [nikos]
Cyril: there's a list of conditions for establishing a new stacking context
10:23:39 [nikos]
... 3rd bullet says ...
10:23:46 [tkonno]
tkonno has joined #svg
10:24:12 [nikos]
3rd bullet point = the element is an outermost svg element, or a ‘foreignObject’, ‘image’, ‘marker’, ‘mask’, ‘pattern’, ‘symbol’ or ‘use’ element
10:25:00 [nikos]
heycam: that should mention that it is only if positioned
10:25:10 [nikos]
cabanier: I think that sentence should go away
10:25:42 [nikos]
jwatt: my intention was to say that element is part of the box model
10:26:02 [nikos]
Rossen_: z-index applies to flex items without position
10:26:12 [nikos]
heycam: should say position value other than static then?
10:26:41 [nikos]
Cyril: it's less error prone if you don't say positioned - say as defined in css
10:26:44 [nikos]
jwatt: yes
10:26:53 [nikos]
ed: in last paragraph of 13.9 it says ...
10:27:04 [nikos]
... is it actually defined that it does what is described there?
10:27:24 [nikos]
heycam: we resolved it should be an initial containing block
10:27:42 [nikos]
Rossen_: initial containing block is the only one that can contain fixed position things
10:28:31 [nikos]
Cyril: I don't fully understand why fO behaves differently wrt back to front stacking order
10:28:54 [nikos]
cabanier: seems some text is missing or it's wrong
10:29:24 [nikos]
jwatt: should say the content of the fO
10:29:32 [nikos]
... because 4 point list is simplified version of css 2 rules
10:29:46 [nikos]
... it's saying for svg here's the simplified rules
10:29:49 [nikos]
... but for fO the full rules apply
10:30:02 [nikos]
Cyril: can you rephrase it?
10:30:17 [nikos]
... and explain why this is a simplified model
10:30:39 [nikos]
heycam: Doug, you
10:30:48 [nikos]
heycam: Doug, you'll need to add where the outline is renderered
10:31:00 [nikos]
shepazu: it would be immediately above the element, but before any other element
10:31:04 [nikos]
... rendered after
10:31:19 [nikos]
heycam: can you add to last item in bullet list please?
10:31:44 [nikos]
shepazu: there is a consideration for outlines being rendered at the very to of the viewport
10:31:52 [nikos]
... what if the item that has the focus is not actually visible?
10:31:55 [nikos]
... if it's obscured
10:32:00 [nikos]
... but you want to indicate it has focus
10:32:13 [nikos]
heycam: if it's possible to bring the outline right up then you should be able to do that in html content
10:32:14 [jun]
jun has joined #svg
10:32:20 [nikos]
... but you can't do t hat at the moment
10:32:26 [nikos]
s/t hat/that
10:32:44 [nikos]
shepazu: we should do whatever css and html does for now
10:33:12 [nikos]
heycam: I just wanted to point out the section has been added and get reviews
10:34:06 [nikos]
heycam: going back to that list - where is the rendering of the element
10:34:22 [nikos]
Rossen_: what this is missing is the content layer where in css you will have the content layer being e.g. text
10:34:34 [nikos]
... it's also missing floats and inline blocks, etc
10:34:41 [nikos]
... so the element itself has already been rendered
10:34:52 [nikos]
... if you want to also say the object itself, e.g. a shape
10:35:12 [nikos]
... then it should be rendered in css, if we follow the equivalent of the content layer, it should be rendered after number 2
10:35:28 [nikos]
... background, borders, negative z, content layer, regular z
10:35:40 [nikos]
shepazu: I will define background but we don't have it defined yet
10:36:02 [nikos]
krit: svg element would need to define a new stacking context to ensure it doesn't interact with html?
10:36:22 [nikos]
Rossen_: if it's not a full stacking context then you're going to be subject to interleaving with the html context
10:36:33 [nikos]
... which would not be good
10:36:53 [nikos]
cabanier: except for blending we said an inline svg root is not a stacking context
10:37:02 [nikos]
... it's implemented that way
10:38:45 [nikos]
krit: blending goes through the barrier of the stacking context?
10:38:48 [nikos]
cabanier: no that's not it
10:39:06 [nikos]
... outer svg element is not a stacking context
10:39:36 [nikos]
krit: but you've defined it based on properties. You don't use the term 'stacking context'
10:39:54 [nikos]
cabanier: spec talks about stacking context for html - we blend through stacking contexts in html
10:40:09 [nikos]
s/we blend through stacking/we don't blend through stacking
10:40:32 [Rossen_]
s/flex items/grid items/
10:41:00 [nikos]
... blending spec calls out some specific things that create isolated groups in svg - where isolated group is different from a stacking context
10:41:26 [nikos]
cabanier: isolated groups always force a stacking context, but not the other way around
10:41:49 [ed]
"Everything in CSS that creates a stacking context must be considered an ‘isolated’ group." is what the spec says
10:42:02 [nikos]
heycam: Rossen, it sounds like you are expecting inline svg root to create a stacking context?
10:42:05 [nikos]
Rossen_: yes
10:42:34 [nikos]
heycam: but with blending this isn't compatible
10:42:48 [nikos]
... it's a stacking context, but not a black box image
10:42:59 [nikos]
krit: it's confusing, but all works out
10:43:31 [nikos]
cabanier: is there a lot of demand for z-index?
10:43:33 [nikos]
heycam: yes
10:43:40 [nikos]
cabanier: how about performance?
10:43:47 [nikos]
heycam: it'll be as performant as html
10:44:06 [nikos]
jwatt: supporting for us, doesn't add overhead
10:44:08 [nikos]
... if it's not used
10:44:16 [nikos]
Tav: anyone else interested in implementing?
10:44:23 [nikos]
krit: not in the short term, but long term we have to
10:44:27 [nikos]
ed: it's not going to be easy
10:44:38 [nikos]
krit: we would like to limit creation of stacking context as much as possible
10:44:47 [nikos]
heycam: not all use of z-index will need a stacking context
10:45:02 [nikos]
... common case probably doesn't require additional stacking contexts
10:45:12 [nikos]
krit: I want to make sure current docs will make more stacking contexts than they do now
10:45:24 [nikos]
heycam: don't think the intention of the text is for that to happen
10:45:51 [nikos]
heycam: krit, if you could review dot points to make sure it matches up with other specs
10:46:00 [nikos]
Rossen_: does use create a stacking context?
10:46:04 [nikos]
krit: why would it?
10:46:11 [nikos]
... by default it wouldn't
10:46:31 [nikos]
heycam: web components will cause stacking context for shadow trees?
10:46:34 [nikos]
ed: yes
10:46:38 [nikos]
heycam: use will as well then
10:47:15 [nikos]
... I would be happy for list in z-index spec not being normative, point to other specs but give examples
10:47:42 [nikos]
ACTION: Rik to review z-index addition to SVG 2
10:47:42 [trackbot]
Created ACTION-3658 - Review z-index addition to svg 2 [on Rik Cabanier - due 2014-09-02].
10:47:47 [nikos]
ACTION: Dirk to review z-index addition to SVG 2
10:47:47 [trackbot]
Created ACTION-3659 - Review z-index addition to svg 2 [on Dirk Schulze - due 2014-09-02].
10:47:51 [nikos]
ACTION: Rossen to review z-index addition to SVG 2
10:47:52 [trackbot]
Created ACTION-3660 - Review z-index addition to svg 2 [on Rossen Atanassov - due 2014-09-02].
10:49:06 [nikos]
Topic: Web Animations
10:49:43 [nikos]
birtles: We published a new WD in June
10:49:52 [nikos]
... that incorporates some feedback from the TAG
10:50:02 [nikos]
... mostly fixing up API issues
10:50:14 [nikos]
... since then we've changed the player interface to use promises instead of events
10:50:27 [nikos]
... and also made it more asynchronous so that when you trigger an animation it doesn't always start straight away
10:50:42 [nikos]
... by default it will leave it to the browser to start timing from the moment it first paints it
10:50:51 [nikos]
... this avoids stutter at the start of the animation
10:51:01 [nikos]
... in terms of future spec work there's some more TAG feedback to address
10:51:08 [nikos]
... and the issue about defining animation tasks on the web platform
10:51:13 [nikos]
... more generically and thouroughly
10:51:19 [nikos]
heycam: as in html task queues?
10:51:23 [nikos]
birtles: yes
10:51:36 [nikos]
... interaction between web animations and other specs isn't well defined
10:51:49 [nikos]
... there's interest from a few people regarding speccing that properly
10:51:55 [nikos]
... order of taskss
10:52:04 [nikos]
... we're also moving spec to github and bikeshed
10:52:15 [nikos]
... Chrome is now shipping a very limited subset of the API
10:52:24 [nikos]
... which lets you create animations from script
10:52:34 [nikos]
... browser runs them on compositor in some cases
10:52:40 [nikos]
... you can't interact with the animations at all yet
10:52:55 [nikos]
... we're minimising surface area of API in first release
10:53:08 [nikos]
... in Gecko we've started implementing
10:53:18 [nikos]
... you can already see what animations are running and what they're up to
10:53:27 [nikos]
... next I'll add playback control for css animations
10:53:48 [nikos]
... 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
10:53:51 [nikos]
... and some playback control
10:54:09 [nikos]
... it's almost the whole spec but doesn't include animation groups, custom effects, and a few other features that are svg specific
10:54:17 [nikos]
... adding and building on animations
10:54:34 [nikos]
... plan is to split them out to next level
10:54:37 [nikos]
... but under discussion
10:55:04 [nikos]
... the other area we talked about yesterday is tying animations to scroll position and gestures
10:55:08 [nikos]
... but needs more investigation
10:55:29 [nikos]
... there's no official mapping between web animations and css. Google will work on it
10:56:19 [nikos]
Cyril: mapping from web animations to svg animations?
10:56:29 [nikos]
birtles: it exists but low priority at the moment
10:56:35 [nikos]
... will do it when I implement next year some time
10:57:01 [nikos]
krit: do you think we could put fxtf repo under w3c?
10:57:12 [nikos]
... how do you publish latest version to w3c?
10:57:21 [nikos]
birtles: we've yet to do that part of the transition
10:57:50 [nikos]
... will look at adding fxtf under w3c
10:58:01 [nikos]
heycam: IDL now requires parameterised types
10:58:10 [nikos]
birtles: respec didn't allow that
10:58:16 [nikos]
... we're moving off it
10:58:28 [nikos]
ChrisL: let me know when you have something ready to publish
10:58:32 [nikos]
... will it be another WD?
10:58:48 [nikos]
birtles: yes
10:59:58 [nikos]
Cyril: where are we in terms of svg features (including Tiny 1.2) in web animations?
11:00:08 [nikos]
birtles: current feature set should be able to express everything from 1.1
11:00:19 [nikos]
... there is some stuff beyond that, such as groups
11:00:29 [nikos]
... but that might get split to a later implementation
11:01:01 [heycam]
s/parameterised types/parameterised Promise types/
11:01:14 [nikos]
Topic: stroke-position
11:01:22 [nikos]
heycam: stroke-position was on list of requirements for SVG 2
11:01:27 [nikos]
... it got cut
11:01:47 [nikos]
... it lets you specify if stroke is on inside or outside or current half/half
11:01:52 [nikos]
ChrisL: that's a shame to lose that
11:02:00 [nikos]
... helps with text
11:02:15 [ChrisL]
it hellps a lot with stroking text without deforming letter shapes
11:02:37 [nikos]
paint-order lets you do a lot of the stroke-position=outside stuff
11:03:07 [nikos]
heycam: to get stroke-position=inside you can clip the shape to itself and double the stroke width
11:03:16 [nikos]
krit: don't think that would work with overlapping paths
11:03:35 [nikos]
ChrisL: these are work arounds and not as good
11:03:56 [nikos]
heycam: dropping because of time and implementation difficulty
11:04:08 [nikos]
... libraries currently don't support this
11:04:11 [nikos]
krit: you could use masking
11:04:14 [nikos]
heycam: that would work
11:04:18 [nikos]
... might not be fastest solution
11:04:36 [nikos]
shepazu: couldn't you separate stroke shape and fill shape and composite?
11:04:48 [nikos]
heycam: the issue is the shape of the stroke
11:05:04 [nikos]
... you still have to compute the shape
11:05:50 [Cyril]
RRSAgent, pointer
11:05:50 [RRSAgent]
11:06:51 [Cyril]
RRSAgent, draft minutes
11:06:51 [RRSAgent]
I have made the request to generate Cyril
11:07:12 [Cyril]
RRSAgent, make minutes public
11:07:12 [RRSAgent]
I'm logging. I don't understand 'make minutes public', Cyril. Try /msg RRSAgent help
11:07:43 [nikos]
krit: the biggest difficulty is when doing dashing with rounded ends
11:07:52 [nikos]
... you can't just mask out part of the stroke
11:08:40 [stakagi]
stakagi has joined #svg
11:09:18 [nikos]
Tav: that's what we would do - calculate the shape of the original path
11:09:44 [nikos]
heycam: we are just relying on graphics libraries currently so it would be a bit of work to support that
11:10:10 [nikos]
... I brought it up because someone emailed me lamenting it's loss
11:10:45 [nikos]
Tav: if we implemented in Inkscape and showed you how to do it would you be interested in adding it back to the spec?
11:10:51 [nikos]
... I'll see how hard it is to implement
11:10:57 [nikos]
... will try to find someone who's interested
11:11:21 [nikos]
heycam: we already have code from Cairo which does the stroking
11:11:27 [nikos]
... so ideally it would be a modification of that
11:11:50 [nikos]
jwatt: I think we'd like code that generates another path that is offset from the current path
11:12:34 [nikos]
jwatt: there will be a performance hit but it shouldn't be a commonly used feature
11:13:19 [nikos]
shepazu: if you have a shape with a fill and the stroke is an offset outline that is larger than the shape
11:13:23 [nikos]
... you could have multiples
11:13:50 [nikos]
... whether we go whole hog and do all that, but those are possibilities that this feature opens up
11:14:07 [nikos]
heycam: Jeremie Patonier wrote up spec text so that bit is done
11:14:31 [nikos]
krit: would help implementers to say how to calculate the offset path
11:14:50 [nikos]
cabanier: offsetting a stroke is very difficult
11:15:52 [nikos]
jwatt: so algorithms are difficult, how is performance?
11:16:14 [nikos]
krit: there's a noticeable performance impact
11:16:36 [nikos]
heycam: constructing a normal stroke is just two offsetting operations? in and out?
11:17:27 [nikos]
cabanier: issues that show up are more obvious - path sections may dissapear
11:17:52 [nikos]
cabanier: don't think the algorithm is that difficult, but it's very fiddly
11:20:34 [nikos]
heycam: if you can supply me some performant code I'd a lot happier with the feature
11:21:00 [nikos]
ACTION: Tav to look at algorithms for path offsetting to support stroke-position
11:21:01 [trackbot]
Created ACTION-3661 - Look at algorithms for path offsetting to support stroke-position [on Tavmjong Bah - due 2014-09-02].
11:21:40 [nikos]
11:40:45 [Zakim]
Zakim has left #svg
12:33:39 [Cyril]
Cyril has joined #svg
12:38:03 [jun]
jun has joined #svg
12:45:24 [tkonno]
tkonno has joined #svg
12:48:07 [Rossen_]
Rossen_ has joined #svg
12:49:14 [heycam]
Topic: Annotating the spec
12:50:03 [nikos]
nikos has joined #svg
12:57:31 [ed]
scribeNick: heycam
12:57:48 [heycam]
shepazu: [shows annotations of web audio api]
12:57:49 [heycam]
shepazu: this is something we've been working on for a while
12:57:59 [heycam]
... the produce is called Annotator, by a non profit group called Hypothesis
12:58:04 [heycam]
... the idea is that you can annotate documents
12:58:17 [heycam]
... over on the right you see a bar, the "3+4" means 3 comments and 4 replies
12:58:26 [heycam]
... on the bottom right it says "14+3" so 17 comments on the spec
12:58:36 [heycam]
... you can click to open up the annotations
12:58:44 [heycam]
... you can see where in the spec they're based
13:01:09 [heycam]
... we could use annotations to track testable assertions, and reply to them to say where the tests are
13:01:52 [heycam]
... we'll deploy a bunch of preset tags for commenting on a spec
13:01:56 [heycam]
... "typo", etc.
13:02:18 [heycam]
... you can search by tag
13:02:53 [heycam]
... when you leave an annotation it sends a mail to a mailing list
13:03:22 [heycam]
... could be integrated into an issue tracker, or it could be an issue tracker itself, depending on how much of a tracker you need
13:03:35 [heycam]
... bots can make annotations for us
13:04:07 [heycam]
... 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
13:04:13 [heycam]
... which often doesn't happen for days/weeks/months
13:04:22 [heycam]
... this would let them listen to replies to their annotation, and respond when that happens
13:04:34 [heycam]
... so they don't have to pay attention to the WG, or know much about how to present their case to the WG
13:05:08 [heycam]
... it encourages an annotation per issue, rather than a big email with a bunch of issues
13:05:16 [heycam]
... it helps people leave targetted comments on specific areas of the spec
13:05:21 [heycam]
13:06:01 [heycam]
... you can have owners for different sections of the spec, so individuals can get notifications for annotations in different areas
13:06:54 [heycam]
... we're planning on using this in the Annotation WG, others are welcome to use it too
13:07:05 [heycam]
... will be deployed in a month and a half or so
13:07:12 [heycam]
Tav: looks good
13:07:17 [heycam]
... what happens when you make big changes to the document?
13:07:22 [heycam]
shepazu: that's why we have the Annotations WG
13:07:26 [heycam]
... it will try to find the closest match
13:07:33 [heycam]
... if that fails, it'll become an orphaned annotation
13:08:11 [heycam]
nikos: have you seen a tool called Peer Review? similar sort of tool we use internally.
13:08:24 [heycam]
shepazu: right now we raise issues in the body of the spec. we could leave them as annotations instead.
13:08:34 [heycam]
heycam: is there a way to make them appear inline?
13:08:40 [heycam]
shepazu: not right now, but it could
13:10:09 [heycam]
heycam: so just add a <script src></script> to add this to our spec?
13:10:10 [heycam]
shepazu: yes
13:10:40 [heycam]
... one thing we're doing for is we want to annotate specs with the doc links
13:10:46 [heycam]
Rossen_: why doesn't it work in IE?
13:10:51 [heycam]
shepazu: it does but the robust anchoring doesn't work
13:11:06 [heycam]
... 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.
13:11:17 [heycam]
... but that's an issue we're trying to fix
13:12:14 [heycam]
shepazu: I'll give you all a status update at TPAC
13:12:24 [heycam]
krit: where's the databse for this?
13:12:35 [heycam]
shepazu: the annotations are stored on
13:13:35 [heycam]
... one last feature we want to have:
13:13:43 [heycam]
... often documentation is frequently out of date
13:14:09 [heycam]
... we're going to have each page in the documentation have a link to the spec that's defining the behaviour
13:14:15 [heycam]
... and watch for specification updates
13:14:38 [heycam]
... which then pings the documentation page with an annotation to get people to check what the spec changes are
13:15:40 [heycam]
shepazu: you can have private and public annotations too
13:15:51 [heycam]
... and you should be able to save them locally
13:18:43 [heycam]
Topic: Symbol reference position
13:18:49 [heycam]
Tav: I got feedback from Andreas and Konno-san
13:18:56 [heycam]
... and they both would like to have the "top", "left", etc. keywords
13:19:06 [heycam]
heycam: why?
13:19:37 [heycam]
Tav: it's typically how they indicate these attachment points in the mapping community
13:19:50 [heycam]
ChrisL: and it's simple to spec
13:20:22 [heycam]
krit: it's easier to spec than to implement
13:20:49 [heycam]
ed: if you have something that got promoted to a presentation attribute, can you put "center" instead of "50%"?
13:21:00 [heycam]
... those keywords are not part of length in CSS
13:21:19 [heycam]
heycam: I don't think it's a difficult thing to support
13:21:33 [heycam]
Rossen_: what is this for?
13:21:50 [heycam]
Tav: with <symbol>, you want to align a position of the symbol's content to somewhere
13:21:58 [heycam]
... that's allowed for <symbol> now (refX, refY)
13:22:12 [heycam]
... Andreas asked if we could also allow top/center/bottom, left/center/right as a way of specifying that point
13:22:18 [heycam]
... since that's the most common things
13:22:27 [heycam]
ed: we already have from the background syntax, left/right/center/etc.
13:22:42 [heycam]
krit: sure. it's css though.
13:22:59 [ed]
s/background syntax/background syntax (for the new fill/stroke properties)
13:23:41 [heycam]
ChrisL: given the community we're trying to reach here wants this, I think we should go for it
13:23:52 [heycam]
Rossen_: should the percentage refX/refY still exist then?
13:23:56 [heycam]
... or is this sufficient?
13:24:02 [heycam]
Tav: no that would already exist
13:25:10 [heycam]
heycam: I think the only question is what would the SVGAnimatedLength object reflect
13:25:56 [heycam]
heycam: we already decided to map new units to "unknown" SVGAnimatedLength values, so we could just do the same thing
13:26:49 [heycam]
... I think it's unnecessary but I won't object
13:27:21 [heycam]
RESOLUTION: We will add top/center/bottom, left/center/right keywords to refX/refY on marker/symbol
13:27:34 [heycam]
ACTION: Tav to add top/center/bottom, left/center/right keywords to refX/refY on marker/symbol in the spec
13:27:34 [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].
13:30:52 [heycam]
Topic: Test repository
13:31:13 [heycam]
ed: we were discussing moving the SVG test repo to either web-platform-tests or the csswg repo
13:31:17 [heycam]
... we had questions about which one to pick
13:31:37 [heycam]
jgraham: the long term goal I think is to consolidate everything under web-platform-tests
13:31:43 [heycam]
... I think the fact that css is separate is largely historical at this point
13:31:50 [heycam]
... they have some particular infrastructure they want to keep using
13:32:06 [heycam]
... but I think it makes more sense for the wider community to have exactly one place
13:32:18 [heycam]
... so you can say if you want to contribute tests, you put them here and follow this process
13:32:23 [heycam]
... rather than having different places/processes
13:32:29 [heycam]
... so it's convenient to put everything in one place
13:32:37 [heycam]
... it seems like the goal is to make that place web-platform-tests
13:32:49 [heycam]
... so I would definitely prefer that SVG uses that rather than using CSS'
13:32:55 [heycam]
... which would be something we need to transfer in the future
13:33:02 [heycam]
... we have some infrastructure that works better with web-platform-tests
13:33:07 [heycam]
... we have a test harness that can run the whole test suite
13:33:13 [heycam]
... it's set up to work with web-platform-tests specifically
13:33:29 [heycam]
... 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
13:34:55 [heycam]
heycam: we have tests we want to make reftests, plus scripted tests
13:35:06 [heycam]
jgraham: you can put reftests in web-platform-tests
13:35:22 [heycam]
... we have a small test runner that will open test/reference in different tabs
13:35:57 [heycam]
... we also have a way to use something like WebDriver (marionette, or selenium) to run reftests automatically
13:36:05 [heycam]
heycam: that works now?
13:36:25 [heycam]
jgraham: yes, in Firefox. and I think someone worked on it for IE (using selenium). so I think it should work in Chrome too.
13:36:41 [heycam]
krit: something we do in the FX specs is to get the test results in each section embedded in the spec
13:36:58 [heycam]
jgraham: there's no standard thing for that. we don't have any database of results, which css does have
13:37:11 [heycam]
... my goal for this is that we push a lot of the generating of results upstream to browser vendors
13:37:38 [heycam]
... once browsers are running these tests in the CI, we standardise a JSON format that web-platform-tests can fetch for each browser
13:37:43 [heycam]
krit: that's a plan for the future?
13:38:00 [heycam]
jgraham: yes, it's not something we've done yet. but certainly what we've done for Gecko we could produce this data trivially.
13:38:16 [heycam]
... yes if you want to allow third parties to contribute results that end up in the spec, you need more infrastructure
13:38:21 [heycam]
... some people have objected to that in other contexts
13:38:30 [heycam]
Tav: this would be how in INkscape we'd put our results in
13:38:45 [heycam]
jgraham: if we had a standard format, as long as you could write that file you could contribute the results that way
13:38:59 [heycam]
... we have a format, but we haven't done the part where it adds annotations to a spec
13:39:19 [heycam]
... 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
13:39:22 [heycam]
... so we've been avoiding that
13:39:31 [heycam]
... if you want to be included in the official test results you have to submit that
13:39:58 [heycam]
heycam: is it in your roadmap for the in-spec annotations for test results?
13:40:36 [heycam]
jgraham: not only CSS specs, I think XHR also has it too, but using another system
13:41:45 [heycam]
... 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
13:42:00 [heycam]
heycam: what's the review process for w-p-t?
13:42:16 [heycam]
jgraham: the process it the normal GH work flow. file a PR, then somebody reviews that.
13:42:24 [heycam]
... we've mostly been using an external review system called Critic
13:43:10 [heycam]
... 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
13:43:32 [heycam]
heycam: do you have specific people reviewing specific spec's tests?
13:43:43 [heycam]
jgraham: in theory anyone can review tests for any spec
13:43:54 [heycam]
... we let people review tests if we think they're going to be the right kind of person to review tests
13:44:04 [heycam]
... if you're a member of the WG we're happy to hand out review privs for the repo
13:44:11 [heycam]
... or if you're doing a lot of test work
13:44:44 [heycam]
... 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.
13:44:57 [heycam]
shepazu: I like the idea of using w-p-t
13:45:52 [heycam]
krit: the thing I would still like to know is that tests in the repo are bound to particular parts of the spec
13:45:58 [heycam]
... so they have metadata in there
13:46:02 [heycam]
... but w-p-t tests don't?
13:46:11 [heycam]
jgraham: one of the philosophies is to minimise the metadata people have to add
13:46:28 [heycam]
... for various reasons
13:46:44 [heycam]
krit: but there is a good side to having the metadata
13:46:49 [heycam]
... you know which parts of the spec are tested
13:47:12 [heycam]
ChrisL: it helps understanding the tests, reviewing them for correctness
13:47:29 [heycam]
jgraham: there is of course a cost. there's the option for adding metadata, if you want to add it.
13:47:37 [heycam]
... but we're not going to force test contributors to add it
13:47:55 [heycam]
... 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
13:48:17 [heycam]
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
13:48:28 [heycam]
... CSS tests do allow you to point to multiple parts of the spec
13:49:04 [heycam]
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
13:49:32 [heycam]
... 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
13:50:23 [heycam]
krit: I don't care where we put the tests. but I would like to know which parts of the spec are tested.
13:50:32 [heycam]
ChrisL: shepherd doesn't care where the tests live, as long as it has a pointer to them
13:50:49 [heycam]
... the CSSWG have metadata requirements which are generally onerous for fly-by contributions, but helpful for people actively working on it
13:51:01 [heycam]
... you can have a curated list of a subset of tests that have been reviewed, or have the metadata we want
13:51:30 [heycam]
... a way forward is to say we want to have a moderate level of metadata, tests in w-p-t, manage the results shepherd
13:51:39 [heycam]
... then we get the best of both worlds
13:52:17 [heycam]
heycam: does the metadata live inside the test?
13:52:25 [heycam]
jgraham: there are two types. explicit metadata, <meta name=...>
13:52:27 [heycam]
... in the test
13:52:44 [heycam]
... 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
13:53:01 [heycam]
... in HTML, we have each section in the spec down to 3 levels deep, and put the tests in those sections
13:53:17 [heycam]
... also things like git author information is in there. so you don't need to type in the author for every test.
13:53:35 [heycam]
heycam: that dir structure is common in w-p-t?
13:53:47 [heycam]
jgraham: yes. in html we use it. some smaller specs go flat.
13:54:28 [heycam]
... I think ther was some tooling around generating section boxes. I think robin was working on this a year or two ago.
13:54:55 [heycam]
heycam: I think that sounds like a good way to go
13:55:22 [heycam]
RESOLUTION: SVG tests will live in web-platform-tests, with Shepherd managing test results.
13:56:30 [heycam]
jgraham: the docs on is a little out of date now
13:56:38 [heycam]
ed: who handles who is a reviewer of tests?
13:57:04 [heycam]
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.
13:57:12 [heycam]
... then a few people concentrating on specs that they know
13:57:34 [heycam]
... two points to the review. is this test right per spec? and, is this using w-p-t features properly/
13:58:17 [heycam]
ACTION: Cameron to add a couple of SVG tests to w-p-t and mail the WG with those examples.
13:58:17 [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].
13:58:45 [heycam]
Topic: TPAC F2F
13:58:48 [ed]
13:58:54 [heycam]
ed: I created a wiki page for the meeting
13:59:01 [heycam]
... with pointers to the TPAC registration forms
13:59:57 [ChrisL]
registration here
14:00:35 [heycam]
krit: you wanted to have the meeting on Mon/Tue. did that not work out?
14:00:46 [heycam]
... it became Thu/Fri
14:02:06 [heycam]
ed: will we have people calling in? we need to request equipment if so.
14:03:02 [heycam]
birtles: not sure if I'll be there
14:03:16 [heycam]
ChrisL: if nobody will be calling in, we should indicate we don't need the polycom since it costs
14:06:56 [heycam]
ACTION: Erik to mail the list asking if we need the polycom for TPAC
14:06:56 [trackbot]
Created ACTION-3664 - Mail the list asking if we need the polycom for tpac [on Erik Dahlström - due 2014-09-02].
14:14:53 [ed]
trackbot, end telcon
14:14:53 [trackbot]
Zakim, list attendees
14:15:01 [trackbot]
RRSAgent, please draft minutes
14:15:01 [RRSAgent]
I have made the request to generate trackbot
14:15:02 [trackbot]
RRSAgent, bye
14:15:02 [RRSAgent]
I see 17 open action items saved in :
14:15:02 [RRSAgent]
ACTION: brian to write up a more concrete proposal for allowing html elements directly in svg (related to [1]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Rossen to discuss svg layout using CSS during the coming CSS F2F meeting [2]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Doug to inform the community why we removed tref and how to solve the use cases [3]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Tav to investigate blending for fill and stroke [4]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Dirk to add a note to the spec to clarify the use of viewport units versus the use of percentage of viewport [5]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: dirk to make the initial values for the svg layout properties dependent on the element, r on radialgradient is different than r on circle (auto?) [6]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Cameron to make foreignObject paint its box and be a CSS OMroot [7]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Cameron to look into whether and how animations should run in resource documents. [8]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Cameron to reword the smiley example text in SVG Integration [9]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: rossen to come up with hinting proposal for SVG [10]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Rik to review z-index addition to SVG 2 [11]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Dirk to review z-index addition to SVG 2 [12]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Rossen to review z-index addition to SVG 2 [13]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Tav to look at algorithms for path offsetting to support stroke-position [14]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Tav to add top/center/bottom, left/center/right keywords to refX/refY on marker/symbol in the spec [15]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Cameron to add a couple of SVG tests to w-p-t and mail the WG with those examples. [16]
14:15:02 [RRSAgent]
recorded in
14:15:02 [RRSAgent]
ACTION: Erik to mail the list asking if we need the polycom for TPAC [17]
14:15:02 [RRSAgent]
recorded in
14:31:20 [RRSAgent]
RRSAgent has joined #svg
14:31:20 [RRSAgent]
logging to
14:56:07 [heycam]
Topic: Units in path data
14:56:23 [heycam]
shepazu: there are two things
14:56:29 [heycam]
... one, the idea of units in paths
14:56:36 [heycam]
... second, just percentages
14:56:44 [heycam]
... I don't care about using px or cm, etc.
14:56:50 [heycam]
krit: vw/vh would still be useful
14:56:52 [heycam]
... maybe em
14:57:09 [heycam]
ed: we'd need to think about whether it clashes with the existing path syntax
14:57:21 [heycam]
... you'd need to change the parser. there might be cases where they clash.
14:57:24 [heycam]
krit: currently they don't
14:57:34 [heycam]
... all the length units have two letters
14:58:08 [glenn]
glenn has joined #svg
14:58:14 [heycam]
shepazu: my biggest frustration with doing things with paths is not being able to have part of them relative to other things
14:58:32 [heycam]
... we could have a path around some text
14:58:50 [heycam]
heycam: it's still an approximation
14:59:01 [heycam]
shepazu: will people want to change these via CSS?
14:59:21 [heycam]
krit: there is a proposal to make the d="" attribute a property
14:59:28 [heycam]
... which takes a path() CSS function value
14:59:32 [heycam]
... there are certain use cases in CSS as well
14:59:43 [heycam]
shepazu: what are the obstacles to this?
15:00:22 [heycam]
krit: the SVG DOM path reflections would need changing
15:00:40 [heycam]
ChrisL: if you have a 'd' property what does it mean when it's applied to other elements
15:01:19 [heycam]
... I can see benefit for CSS having shapes other than rectangles/ellipses
15:03:50 [heycam]
shepazu: we should start from the use cases here
15:04:09 [heycam]
krit: the use cases are most for SVG in HTML, where people want to have the path relative to the viewport
15:05:20 [heycam]
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.
15:07:04 [heycam]
ACTION: Dirk to gather use cases that might be solved by units in path data
15:07:05 [trackbot]
Created ACTION-3665 - Gather use cases that might be solved by units in path data [on Dirk Schulze - due 2014-09-02].
15:07:31 [heycam]
krit: but I am sure these use cases will be real once we allow paths in CSS (basic shapes)
15:08:07 [heycam]
shepazu: we have an opportunity to influence the alignment with CSS here
15:08:43 [heycam]
... by resisting this we could put off this change, but it will likely happen in CSS
15:09:44 [jet]
jet has joined #svg
15:12:05 [heycam]
... I think if we want to expose some units we should do all
15:12:22 [heycam]
Rossen_: how do the percentages resolve?
15:12:33 [heycam]
krit: you know whether it's an x or y coordinate, so against the viewport size in that dimension
15:12:39 [heycam]
birtles: that wouldn't work with turtle graphics
15:12:45 [heycam]
shepazu: let's look at the use cases
15:16:17 [jwatt]
jwatt has joined #svg
15:18:32 [ed]
RRSAgent, make minutes
15:18:32 [RRSAgent]
I have made the request to generate ed
15:33:41 [ChrisL]
15:42:49 [nikos]
nikos has joined #svg
15:55:04 [jet]
jet has joined #svg
16:02:18 [jwatt_]
jwatt_ has joined #svg
16:42:38 [jwatt]
jwatt has joined #svg
17:48:57 [thorton]
thorton has joined #svg
18:12:43 [heycam]
jwatt, we just arrived. dinner?
18:14:04 [birtles]
heycam: you beat me :)
18:14:12 [heycam]
19:47:34 [jet]
jet has joined #svg
20:09:36 [jwatt]
jwatt has joined #svg
23:03:24 [glenn]
glenn has joined #svg
23:04:47 [stakagi_]
stakagi_ has joined #svg
23:36:49 [jdaggett]
jdaggett has joined #svg
23:53:17 [stakagi]
stakagi has joined #svg