00:01:01 stakagi_ has joined #svg 00:27:57 thorton has joined #svg 05:03:39 jun has joined #svg 05:38:14 Tav has joined #svg 05:40:15 jdaggett has joined #svg 06:10:43 jdaggett has joined #svg 06:27:53 tkonno has joined #svg 06:57:32 shepazu has joined #svg 07:57:26 nikos has joined #svg 07:57:35 knock knock 07:57:56 heycam 08:01:49 Cyril has joined #svg 08:02:06 tkonno has joined #svg 08:04:55 nikos_ has joined #svg 08:09:53 nikos__ has joined #svg 08:19:55 ChrisL has joined #svg 08:20:18 trackbot, start telcon 08:20:20 RRSAgent, make logs public 08:20:20 Zakim has joined #svg 08:20:22 Zakim, this will be GA_SVGWG 08:20:22 I do not see a conference matching that name scheduled within the next hour, trackbot 08:20:23 Meeting: SVG Working Group Teleconference 08:20:23 Date: 26 August 2014 08:20:37 Rossen_ has joined #svg 08:21:41 Meeting: SVG WG F2F London 2014 Day 4 08:21:51 Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda 08:21:55 chair: ed 08:23:01 present: cyril, brian, dirk, tav, chris, rossen, erik, cameron, nikos, konno 08:24:01 present+ doug 08:26:03 jwatt has joined #svg 08:26:58 nikos has joined #svg 08:27:02 shepazu has joined #svg 08:32:17 scribenick: ChrisL 08:32:32 topic: initial subpath implementation 08:33:03 https://github.com/moissinac/SuperPath 08:33:04 Cyril: a colleague has been working on a polyfil, its on github 08:33:34 ed: oh so it is a superpath 08:33:41 s/subpath/superpath 08:33:47 Cyril: yes, re-using paths and joining them 08:34:16 Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/London_2014/Agenda 08:34:20 Tav has joined #svg 08:34:47 Cyril: so to let you know this js impl exists,it expands the path references out into a full path 08:34:55 q+ 08:34:58 ... see examples at end of github page 08:35:25 ... does relative and abs coordinates in fwd and reverse order 08:35:38 present+ jet 08:35:42 Cyril: reusable sequence of commends 08:35:47 q+ 08:36:50 Cyril: shared paths referenced by ID 08:36:53 jet has joined #svg 08:37:48 ChrisL: a native implementation can avoid antialiasing bugs on the shared path when two filled shapes conjoin 08:38:35 nikos: (describes an inline named subpath) 08:38:52 shepazu: does proposal and polyfill deal with path direction? 08:38:54 Cyril: yes 08:39:26 shepazu: how does it deal with relative coords, are they normalized to absolute? 08:39:48 Cyril: it computes the reversed path which is not trivial 08:40:21 Cyril: already have action to add this to the spec. what letter shall we use now? 08:41:08 (discussion on separator to tell end of ID) 08:41:56 heycam: just use the hash? 08:42:02 Cyril: and for reversed? 08:42:42 ChrisL: doug are you wanting relative coords preserved? 08:42:49 shepazu: not necessarily 08:43:09 shepazu: need to define what the normalized path looks like 08:43:19 Cyril: yes 08:43:38 ChrisL: the normalized result 08:43:40 present+ jun 08:44:17 heycam: ussuming use of normalized pathseglist, need to define effect of hash 08:44:41 ed: does referenced path have to start with moveto? 08:44:52 ... to make relative commands meaningful 08:45:19 ChrisL: you won't know its valid until it is expanded 08:45:58 you can of course do "m0,0" as the start of the referenced path 08:46:12 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 Cyril: same with modifying a normalized path now 08:47:13 heycam: normPSL does not let you modify like that 08:47:21 jun has joined #svg 08:48:06 shepazu: (draws on board) retrieve the dom of the path 08:48:48 ChrisL: need to add a second dom method that preserves the hash unexpanded 08:48:58 shepazu: which letters 08:49:29 heycam: I and J? 08:49:35 I for insert 08:49:51 shepazu: can lowercase mean not normalize? 08:50:56 shepazu: need to consider use cases for explicitly normalizing to absolute 08:51:33 Tav: what about a minus to reverse -# 08:51:57 shepazu: makes a difference if relative and re-referenced 08:52:29 ed: referencing same path twice 08:52:51 shepazu: then the serialization is critical 08:53:17 ChrisL: yes its recalculating the coordinates of the path 08:54:30 present+ jwatt 08:54:58 ed: say there is a transform on the path does it apply? 08:55:08 Cyril: no, the ctm is not used here 08:55:37 Cyril: recursive path reuse should be forbidden 08:55:48 ed: whatabout reversing? 08:57:00 ChrisL: we have some spec language on detecting cycles 08:57:11 ed: common to declare a transform and apply it 08:57:19 Cyril: in different coord systems 08:57:54 ChrisL: so coords are reinterpreted for the place they are used 08:57:57 Cyril: yes 08:58:51 Tav: looks like a pathref and we just got rid of tref. can it link to other docs 08:59:01 ChrisL: ID not URI so restricted to same doc 08:59:18 ed: but cross fragments in same doc 09:00:04 ed: is it a string or does it have to use the path parser? eg html data-foo agttribute? 09:00:17 Cyril: must use ID of an element that has a path 09:00:39 ed: so it depends on the right underlying objects 09:01:15 ChrisL: do we want to exclude pulling data from html data-* attrs? 09:02:20 Tav: random path would not draw if it misses the m at the beginning. invalid standalone path 09:02:48 ChrisL: not clear we had a decision on requiring m 09:02:53 Cyril: m is not disallowed 09:03:36 ChrisL: better to wrap the subpaths inside defs 09:03:42 Cyril: authoring advice 09:04:53 ChrisL: need to explicitly say styling on original subpath are ignored 09:06:06 Tav: path reversing is a unique feature 09:07:05 Cyril: next steps, update polyfil more examples and multiple reusable relative subpaths 09:08:22 shepazu: (reversing catmull-rom gives same path?) 09:08:29 (we need to test this) 09:09:03 Cyril: computing path length is straightforward 09:09:44 Cyril: rendering is after the path substitution 09:10:09 Cyril: some apis it makes sense to do post substitution 09:10:24 ... itersating you want to know its a referenced command 09:10:48 ... but some apis like get pathsegindex you wasnt to count the referenced segments as well 09:11:05 ... simplest is not expand by default then see which to add new args for expanded or not 09:11:17 s/wasnt/want/ 09:11:50 action-3546? 09:11:50 action-3546 -- Cyril Concolato to Add piece commands to svg 2 specification -- due 2013-11-22 -- OPEN 09:11:50 http://www.w3.org/Graphics/SVG/WG/track/actions/3546 09:11:57 action-3422? 09:11:57 action-3422 -- Cyril Concolato to Specify shared-path segments -- due 2013-02-11 -- OPEN 09:11:57 http://www.w3.org/Graphics/SVG/WG/track/actions/3422 09:12:16 topic: hinting 09:12:50 Rossen_: feedback from people using svg as icons, they want hinting 09:13:29 ... 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 ... sothey ask where is the hinting 09:14:01 ... also level of detail for different sizes 09:14:13 ... unaware of anythingthat does the trick 09:14:15 q+ 09:14:42 Rossen_: sharp joins, shallow curves, hinting may not help there. but some cases it does help 09:16:28 ChrisL: this is the key differentiator between MS COLR font and SVG font - truetype hinting 09:16:43 birtles: hinting only on windows? 09:17:03 ChrisL: apple ignore hinting nowadays 09:17:20 birtles: hinting is now seen as a legacy thing in some circles 09:17:55 birtles: a school of thought says this will go away 09:18:06 krit: we say that about a lot of things but they persist 09:18:29 krit: even with retiina you see details differently 09:18:36 ... and contrast changes 09:18:48 q+ blue hints 09:19:40 krit: vertical lines in text you see hinting issues even on retina 09:21:33 ChrisL: (declarative type1 sttyle hinting, but hard to test) 09:22:00 Rossen_: could start from that 09:22:15 shepazu: think its worth pursuing, want to see a concrete proposal 09:22:37 birtles: is this about pixel alignemtn or level of detail as well 09:22:53 Rossen_: in terms of pixel grid, not @media rules 09:23:26 heycam: saw a blog post complaining about rendering of svg icons across browsers, impls differ 09:23:58 Rossen_: even no noun project, vast differences in way some simple icons appear, on same device different impls 09:24:24 https://twitter.com/kaelig/status/494805682848550912 09:25:12 rik: adobe has a shift by 0.5px export option "for web" 09:25:40 krit: still have aliasing in some cases 09:25:56 rik: flash player does that snap to 0.5 px 09:27:42 ChrisL: is it possible now to define where the pixel position is? 09:28:05 heycam: shape rendering allows some snap 09:29:04 rik: canvas says the coordinate is in the middle of the pixel 09:29:19 rik: you want the stroke to be crisp 09:29:42 jwatt: stroke crisp more important than fill 09:30:11 Rossen_: underlines we render on pixel boundary but lines, esp one pixel borders suck if not poixel aligned 09:30:35 krit: ios had scrolling issue with underlines getting thicker and thinner 09:31:08 ChrisL: can we define same as canvas 09:31:16 heycam: but that is the wrong way 09:31:33 ... can we define the right way but allow shape rendring to snap to grid 09:32:00 ... geometric precision means leave it on mathematical geometric position 09:32:36 heycam: if line starts at 0.2 then it touches more pixels 09:32:52 jwatt: browsers are consistent now 09:33:10 ... dont break content 09:34:45 jwatt: easier too now transform on svg element to add 0.5px 09:34:54 rik: what about with zoom 09:35:31 ed: would pixel snap preserve squares as squares not rectangles? 09:35:49 Rossen_: truetype has shape consistency regardless of pixel alignment 09:36:02 ed: shape rendering doe snot deal with that currently 09:36:17 Rossen_: and shape similarity musyt be [preserved 09:36:48 rik: browser zoom keeps snapping to pixels, but today in scg it all gets blurry 09:36:53 s/scg/svg/ 09:37:28 Rossen_: often on windows with higher dpi browsers go to higher zoom default but sacrifice image quality 09:38:30 Rossen_: even at 2x we sometimes have problems 09:38:48 Rossen_: wanted to put that ontable. will take an actin to get a proposal 09:39:09 action: rossen to come up with hinting proposal for SVG 09:39:09 Created ACTION-3657 - Come up with hinting proposal for svg [on Rossen Atanassov - due 2014-09-02]. 09:41:50 resolution: we will adopt a precision rendering mechanism for pixel-crisp SVG 09:42:06 ** break** 09:52:28 jun has joined #svg 10:06:36 jun has joined #svg 10:06:43 nikos has joined #svg 10:06:58 stakagi has joined #svg 10:09:35 stakagi has joined #svg 10:10:10 scribenick: nikos 10:10:15 Topic: z-index 10:10:45 jwatt has joined #svg 10:11:00 https://svgwg.org/svg2-draft/painting.html#ZIndexProperty 10:11:21 heycam: We've talked about z-index for a while - it's a requirement for SVG 2 10:11:33 ... jwatt wrote up some text on a wiki which I've now added to the spec 10:12:07 ... the text about stacking contexts was written a while ago before blending and compositing 10:12:20 ... so either the list needs to be updated - e.g. to include mix-blend-mode 10:12:26 ... or reference some other list if there is one available 10:12:44 krit: every property must define if it creates a stacking context or not 10:12:50 heycam: the list needs updating 10:12:59 ... are you saying we have already added the wording to the properties? 10:13:15 krit: in the specs that have properties that create stacking context we have 10:13:26 cabanier: it's not going to be the same list as blending 10:13:37 ... blending doesn't create a stacking context for clip 10:13:39 ... but you do 10:13:56 ... there's no reason clip should force you to do a stacking context 10:13:59 krit: it does in html 10:14:32 shepazu: how does this interact with 3d transforms? 10:14:39 krit: 3d transforms create a stacking context 10:15:08 shepazu: transform spec should define how it interacts with this z-index property 10:15:41 ChrisL: needs a few examples because the way it works isn't intuitive 10:16:03 stakagi_ has joined #svg 10:16:24 each 3d transform gets flattened and then the z-index happens 10:16:31 Cyril: can you explain the paragraph that talks about the rules of css 2.1 10:16:33 Rossen_ has joined #svg 10:16:38 ... there is one exception 10:16:55 heycam: in css z-index doesn't have any effect if element is static 10:17:04 ... that sentence is there to make z-index apply always 10:17:21 ... to avoid authors having to put z-index=something position:relative 10:17:39 Cyril: the exception is the outer svg element? 10:17:51 heycam: when you put z-index on the outer for inline content 10:18:00 "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 ... it's for the svg in the outer world 10:18:34 Tav: do others plan on implementing? 10:18:42 krit: how about performance in FF? 10:18:46 heycam: don't think there will be issues 10:19:17 konno has joined #svg 10:19:26 jet has joined #svg 10:19:48 (discussion on 2d transform not creating a stacking context in SVG) 10:20:11 krit: I'm not sure we want different definitions of a stacking context in svg and css 10:20:46 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 has joined #svg 10:21:51 krit: if you have html elements in svg then you have two models 10:22:25 jwatt: css talks about when laying out with box model and is very specific about that 10:22:40 cabanier: we've been talking about bringing box model into svg for some things 10:23:03 ChrisL: our use of box model is very simplified - not talking about reflow or anything 10:23:17 Rossen_: box model is just about margins, borders, etc. it's a very simple concept 10:23:31 Cyril: there's a list of conditions for establishing a new stacking context 10:23:39 ... 3rd bullet says ... 10:23:46 tkonno has joined #svg 10:24:12 3rd bullet point = the element is an outermost svg element, or a ‘foreignObject’, ‘image’, ‘marker’, ‘mask’, ‘pattern’, ‘symbol’ or ‘use’ element 10:25:00 heycam: that should mention that it is only if positioned 10:25:10 cabanier: I think that sentence should go away 10:25:42 jwatt: my intention was to say that element is part of the box model 10:26:02 Rossen_: z-index applies to flex items without position 10:26:12 heycam: should say position value other than static then? 10:26:41 Cyril: it's less error prone if you don't say positioned - say as defined in css 10:26:44 jwatt: yes 10:26:53 ed: in last paragraph of 13.9 it says ... 10:27:04 ... is it actually defined that it does what is described there? 10:27:24 heycam: we resolved it should be an initial containing block 10:27:42 Rossen_: initial containing block is the only one that can contain fixed position things 10:28:31 Cyril: I don't fully understand why fO behaves differently wrt back to front stacking order 10:28:54 cabanier: seems some text is missing or it's wrong 10:29:24 jwatt: should say the content of the fO 10:29:32 ... because 4 point list is simplified version of css 2 rules 10:29:46 ... it's saying for svg here's the simplified rules 10:29:49 ... but for fO the full rules apply 10:30:02 Cyril: can you rephrase it? 10:30:17 ... and explain why this is a simplified model 10:30:39 heycam: Doug, you 10:30:48 heycam: Doug, you'll need to add where the outline is renderered 10:31:00 shepazu: it would be immediately above the element, but before any other element 10:31:04 ... rendered after 10:31:19 heycam: can you add to last item in bullet list please? 10:31:44 shepazu: there is a consideration for outlines being rendered at the very to of the viewport 10:31:52 ... what if the item that has the focus is not actually visible? 10:31:55 ... if it's obscured 10:32:00 ... but you want to indicate it has focus 10:32:13 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 has joined #svg 10:32:20 ... but you can't do t hat at the moment 10:32:26 s/t hat/that 10:32:44 shepazu: we should do whatever css and html does for now 10:33:12 heycam: I just wanted to point out the section has been added and get reviews 10:34:06 heycam: going back to that list - where is the rendering of the element 10:34:22 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 ... it's also missing floats and inline blocks, etc 10:34:41 ... so the element itself has already been rendered 10:34:52 ... if you want to also say the object itself, e.g. a shape 10:35:12 ... 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 ... background, borders, negative z, content layer, regular z 10:35:40 shepazu: I will define background but we don't have it defined yet 10:36:02 krit: svg element would need to define a new stacking context to ensure it doesn't interact with html? 10:36:22 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 ... which would not be good 10:36:53 cabanier: except for blending we said an inline svg root is not a stacking context 10:37:02 ... it's implemented that way 10:38:45 krit: blending goes through the barrier of the stacking context? 10:38:48 cabanier: no that's not it 10:39:06 ... outer svg element is not a stacking context 10:39:36 krit: but you've defined it based on properties. You don't use the term 'stacking context' 10:39:54 cabanier: spec talks about stacking context for html - we blend through stacking contexts in html 10:40:09 s/we blend through stacking/we don't blend through stacking 10:40:32 s/flex items/grid items/ 10:41:00 ... 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 cabanier: isolated groups always force a stacking context, but not the other way around 10:41:49 "Everything in CSS that creates a stacking context must be considered an ‘isolated’ group." is what the spec says 10:42:02 heycam: Rossen, it sounds like you are expecting inline svg root to create a stacking context? 10:42:05 Rossen_: yes 10:42:34 heycam: but with blending this isn't compatible 10:42:48 ... it's a stacking context, but not a black box image 10:42:59 krit: it's confusing, but all works out 10:43:31 cabanier: is there a lot of demand for z-index? 10:43:33 heycam: yes 10:43:40 cabanier: how about performance? 10:43:47 heycam: it'll be as performant as html 10:44:06 jwatt: supporting for us, doesn't add overhead 10:44:08 ... if it's not used 10:44:16 Tav: anyone else interested in implementing? 10:44:23 krit: not in the short term, but long term we have to 10:44:27 ed: it's not going to be easy 10:44:38 krit: we would like to limit creation of stacking context as much as possible 10:44:47 heycam: not all use of z-index will need a stacking context 10:45:02 ... common case probably doesn't require additional stacking contexts 10:45:12 krit: I want to make sure current docs will make more stacking contexts than they do now 10:45:24 heycam: don't think the intention of the text is for that to happen 10:45:51 heycam: krit, if you could review dot points to make sure it matches up with other specs 10:46:00 Rossen_: does use create a stacking context? 10:46:04 krit: why would it? 10:46:11 ... by default it wouldn't 10:46:31 heycam: web components will cause stacking context for shadow trees? 10:46:34 ed: yes 10:46:38 heycam: use will as well then 10:47:15 ... I would be happy for list in z-index spec not being normative, point to other specs but give examples 10:47:42 ACTION: Rik to review z-index addition to SVG 2 10:47:42 Created ACTION-3658 - Review z-index addition to svg 2 [on Rik Cabanier - due 2014-09-02]. 10:47:47 ACTION: Dirk to review z-index addition to SVG 2 10:47:47 Created ACTION-3659 - Review z-index addition to svg 2 [on Dirk Schulze - due 2014-09-02]. 10:47:51 ACTION: Rossen to review z-index addition to SVG 2 10:47:52 Created ACTION-3660 - Review z-index addition to svg 2 [on Rossen Atanassov - due 2014-09-02]. 10:49:06 Topic: Web Animations 10:49:43 birtles: We published a new WD in June 10:49:52 ... that incorporates some feedback from the TAG 10:50:02 ... mostly fixing up API issues 10:50:14 ... since then we've changed the player interface to use promises instead of events 10:50:27 ... and also made it more asynchronous so that when you trigger an animation it doesn't always start straight away 10:50:42 ... by default it will leave it to the browser to start timing from the moment it first paints it 10:50:51 ... this avoids stutter at the start of the animation 10:51:01 ... in terms of future spec work there's some more TAG feedback to address 10:51:08 ... and the issue about defining animation tasks on the web platform 10:51:13 ... more generically and thouroughly 10:51:19 heycam: as in html task queues? 10:51:23 birtles: yes 10:51:36 ... interaction between web animations and other specs isn't well defined 10:51:49 ... there's interest from a few people regarding speccing that properly 10:51:55 ... order of taskss 10:52:04 ... we're also moving spec to github and bikeshed 10:52:15 ... Chrome is now shipping a very limited subset of the API 10:52:24 ... which lets you create animations from script 10:52:34 ... browser runs them on compositor in some cases 10:52:40 ... you can't interact with the animations at all yet 10:52:55 ... we're minimising surface area of API in first release 10:53:08 ... in Gecko we've started implementing 10:53:18 ... you can already see what animations are running and what they're up to 10:53:27 ... next I'll add playback control for css animations 10:53:48 ... 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 ... and some playback control 10:54:09 ... 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 ... adding and building on animations 10:54:34 ... plan is to split them out to next level 10:54:37 ... but under discussion 10:55:04 ... the other area we talked about yesterday is tying animations to scroll position and gestures 10:55:08 ... but needs more investigation 10:55:29 ... there's no official mapping between web animations and css. Google will work on it 10:56:19 Cyril: mapping from web animations to svg animations? 10:56:29 birtles: it exists but low priority at the moment 10:56:35 ... will do it when I implement next year some time 10:57:01 krit: do you think we could put fxtf repo under w3c? 10:57:12 ... how do you publish latest version to w3c? 10:57:21 birtles: we've yet to do that part of the transition 10:57:50 ... will look at adding fxtf under w3c 10:58:01 heycam: IDL now requires parameterised types 10:58:10 birtles: respec didn't allow that 10:58:16 ... we're moving off it 10:58:28 ChrisL: let me know when you have something ready to publish 10:58:32 ... will it be another WD? 10:58:48 birtles: yes 10:59:58 Cyril: where are we in terms of svg features (including Tiny 1.2) in web animations? 11:00:08 birtles: current feature set should be able to express everything from 1.1 11:00:19 ... there is some stuff beyond that, such as groups 11:00:29 ... but that might get split to a later implementation 11:01:01 s/parameterised types/parameterised Promise types/ 11:01:14 Topic: stroke-position 11:01:22 heycam: stroke-position was on list of requirements for SVG 2 11:01:27 ... it got cut 11:01:47 ... it lets you specify if stroke is on inside or outside or current half/half 11:01:52 ChrisL: that's a shame to lose that 11:02:00 ... helps with text 11:02:15 it hellps a lot with stroking text without deforming letter shapes 11:02:37 paint-order lets you do a lot of the stroke-position=outside stuff 11:03:07 heycam: to get stroke-position=inside you can clip the shape to itself and double the stroke width 11:03:16 krit: don't think that would work with overlapping paths 11:03:35 ChrisL: these are work arounds and not as good 11:03:56 heycam: dropping because of time and implementation difficulty 11:04:08 ... libraries currently don't support this 11:04:11 krit: you could use masking 11:04:14 heycam: that would work 11:04:18 ... might not be fastest solution 11:04:36