07:06:28 RRSAgent has joined #svg 07:06:28 logging to http://www.w3.org/2014/04/09-svg-irc 07:06:30 RRSAgent, make logs public 07:06:30 Zakim has joined #svg 07:06:32 Zakim, this will be GA_SVGWG 07:06:32 I do not see a conference matching that name scheduled within the next hour, trackbot 07:06:33 Meeting: SVG Working Group Teleconference 07:06:33 Date: 09 April 2014 07:06:38 Chair: Cameron 07:06:52 Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Leipzig_2014/Agenda 07:10:30 Scribe: Cameron 07:10:32 ScribeNick: heycam 07:10:38 Topic: Automated filter regions 07:10:55 https://www.w3.org/Graphics/fx/wiki/Filter_effects#Automated_Filter_Region_calculation 07:11:05 krit: I'm currently working on automated filter region calculation code 07:11:11 ... I know blink did some work on that 07:11:19 ... to minimize the effected area as much as possible 07:11:33 ... I'd be happy if there would be some contributions on how this should work 07:11:52 ... the main problem is if you do not have limits at the beginning, and you use primitives like feTurbulence, that don't have bounds 07:11:56 ... or lighting effects 07:12:01 ... this could affect the whole canvas 07:12:04 ... which isn't necessarily what you want 07:12:11 ... currently we have the 10% bounds around the objectBoundingBox 07:12:16 ... getting rid of that for gaussian blur would be good 07:12:25 ... you can calculate the boundaries automatically 07:12:31 ... for displacement map, turbulence, etc., there's no bounds 07:12:34 ... what should we do for them 07:12:59 ... should we clip to the viewport -- possible, but a lot bigger than you need -- or take the old 10% filter margins? 07:13:24 heycam: did roc suggest getting rid of those attributes altogether? 07:13:34 krit: no, but he said if you don't specify them then the bounds should be calculated automatically 07:13:49 Tav: you can calculate the maximum displacement 07:13:53 krit: it could still be huge though 07:14:03 ... and for turbulence, there's no hint about how big it should be 07:14:12 Tav: it's only useful to have turbulence as input for something else 07:14:17 ... so you have to work backwards to work it out 07:14:27 heycam: you must be able to work it out 07:16:08 Tav: the filter is applied to the object. you have the object size. 07:16:15 krit: feTurbulence is not limited to the object size 07:16:43 cabanier: what about keeping the current behaviour but special casing blur, color matrix, etc.? 07:19:24 heycam: what about finding the maximum rectangle based only on the primitives that you can work it out for 07:19:42 ... and then use the union of those rectangles for the remaining ones like turbulence 07:20:02 Tav has joined #svg 07:21:38 krit: the 10% fallback might be easier, since implementations already handle that, but it's not good for authors 07:23:53 heycam: what is more useful for authors if they use only an infinite extent filter primitive? 07:24:00 ... I don't like the 10% 07:24:45 stakagi has joined #svg 07:25:01 krit: who prefers viewport and who prefers the 10% limit? 07:25:07 pdr: viewport, though that will be slower 07:25:19 Tav: if you have a flood fill, that will now go everywhere 07:25:23 ... could break content 07:25:35 krit: you can always specify x/y/width/height if you need to 07:25:41 ed: leaning towards 10% margin 07:26:10 pdr: how does CoreImage handle this? or other native APIs? 07:26:14 krit: don't know how CoreImage does it 07:26:19 cabanier: you have to set it up yourself right? 07:26:28 krit: you give the images as input, so you don't run into the infinite extent issue 07:26:39 cabanier: doesn't IE have all of these optimizations? 07:27:32 Tav: how does turbulence work, does the pattern shift? 07:27:35 krit: I think it would 07:29:39 davve: are users complaining about this? 07:29:49 krit: new users don't understand these 10% margins at all 07:29:57 ed: it's usually people using gaussian blur 07:30:56 heycam: would content break if we just said turbulence defaults to 0,0,100%,100% unless attributes are given on the primitive? 07:30:59 krit: I think it would 07:32:32 ... should we defer this decision, or can we come to a conclusion? 07:32:42 ... I'd be fine with using 10% margin for now, but at least for things that are unbounded 07:32:46 ... and try to be smart for other cases 07:33:06 Tav: if there is a primitive you cannot figure out, you use the 10% 07:34:37 heycam: are you able to write down in the spec exactly when we have to use the 10% then? 07:34:38 krit: yes 07:35:19 ... a lot of authoring tools in the past set the filter region to the whole viewport 07:35:24 ed: if you don't optimize it's going to be super slow 07:36:04 ... I know I saw some diagram with lots of little cloud shapes, and each had a filter applied 07:36:10 ... it was very slow 07:36:20 Tav: there is badly authored content out there 07:36:40 heycam: I think Omnifgraffle at one point was outputting large filter regions 07:40:07 RESOLUTION: For filter primitives that are unbounded, and the size cannot be computed automatically, the default filter region will be -10%,-10%,120%,120% 07:40:26 krit: next is the lighting filters 07:40:41 ... in Blink/WebKit, they are treated as infinite extent 07:40:43 ... but not in Gecko 07:42:34 [dirk shows an example] 07:43:19 SVGFEPointLightElement-svgdom-y-prop.html 07:43:28 ... in Firefox the output of the lighting primitive is limited to exactly the size of the input 07:43:41 Tav: I think that's wrong, and Blink/WebKit are right 07:44:09 Zakim, remind me in 8 hours to go home 07:44:09 ok, heycam 07:46:10 https://webkit.googlesource.com/WebKit/+/master/LayoutTests/svg/dynamic-updates/script-tests/SVGFEPointLightElement-dom-y-attr.js is what it generates 07:46:35 http://trac.webkit.org/export/167007/trunk/LayoutTests/svg/dynamic-updates/SVGFEPointLightElement-svgdom-y-prop.html 07:49:17 z="30"> 07:51:02 heycam: I think it is just a bug in firefox 07:51:14 krit: and IE11 matches Blink etc. 07:51:17 ... so I will leave the spec as is 08:00:10 Topic: animation of filter effects 08:00:19 krit: Brian wrote a good summary 08:00:24 ... we got one reply 08:00:27 birtles: we talked about it a bit further in Web Animations 08:01:28 some discussion here: http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0118.html 08:01:58 original discussion here: http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0063.html 08:02:15 stakagi_ has joined #svg 08:03:10 ... I'll summarise 08:03:16 ... there's different ways of adding things together 08:03:46 ... if you have two animations which are targetting the same element, and they're independent animations, and they're both applying a filter to the element, then visual result you expect is equivalent to building up a list 08:03:51 ... suppose they're both applying a blur of radius 2 08:03:56 ... the equivalent visual result is blur(2)blur(2) 08:04:00 ... so you append onto the list 08:04:09 ... but for SVG there's also cumulative animation 08:04:15 ... where the same animation builds on its own result 08:04:23 ... that should give you a different result after 2 iterations, blur(4) 08:04:29 ... this comes up with transforms as well 08:04:34 ... if you have skew(22) 08:04:40 ... if you accumulate that three times, you should get skew(66) 08:04:52 ... after three iterations 08:05:26 ... but if you have three indepedent animations with skew(22) and they're additive, you use post-multiplication to get skew(22)skew(22)skew(22) 08:05:31 ... so that's two different kinds of "addition" 08:05:40 ... that's something we've realised in Web Animations, we know two different ways to add 08:05:49 ... for most things they're identical, say for lengths 08:05:53 ... but for some types they're different 08:05:58 ... for filters that's an example where they're different 08:06:12 heycam: is it just when you have lists? 08:06:14 birtles: doesn't have to be 08:06:22 ... for transform lists you don't have to build up the list, you can use post-multiplication 08:06:26 ... the effect is the same there 08:06:40 heycam: do you have an exhaustive list? 08:06:46 birtles: so far it's just filters and transforms where this has come up 08:07:06 ... another reason it's important to make the distinction, with cumulative animation, the list gets longer each time you repeat 08:07:29 ... so it's advantageous to define the operation differently for filter lists 08:07:42 ... it's basically a component-wise addition rather than an independent combination 08:07:55 ... so we've defined this already in Web Animations 08:08:20 birtles: for any data type we define how to interpolate, how to compute distance, how to add, and how to accumulate 08:09:12 ... you don't have to define all of these operations 08:09:21 ... the definitions say if there's no cumulate addition operation for this type, use normal addition 08:09:31 ... if that's not defined, it uses "non-additive" addition, i.e. just use the RHS 08:09:38 krit: this relies on Web Animations defining the types 08:10:14 ... for filter effects, I don't want to have infinite lists 08:10:20 birtles: for filters we need to define how accumulation works 08:10:33 ... and I think we need to define that in terms of matching up filter primitives, starting from the rhs, and adding the component values 08:11:11 krit: another problem is that a lot of the values that pass are not linear 08:11:14 ... greyscale for example 08:11:21 ... and just adding these numbers would give a non-linear behaviour 08:11:26 ... for some of the filter functions it's not even computable 08:11:37 ChrisL: can the distance metric not linearise it? 08:12:39 birtles: it's up to the spec to define how to combine the numbers for the cumulative addition 08:12:52 krit: for some primitives I just don't know how to combine the numbers 08:13:03 Tav: if you apply a gaussian blur twice to something, it's not the same as doubling it 08:13:08 birtles: it's up to you to think for each one 08:13:19 ... if you were to make this animation, and run it twice and build on the result, what's the expected result of that 08:13:26 ... define the operation in those terms 08:13:38 ... it's up to the spec author who introduces a new animatable type 08:13:54 krit: I'd rather not allow the addition then 08:13:57 birtles: I think we should work it out 08:14:04 ... I think it's useful to have additive animations 08:14:18 ... as long as you're defining that additive animation, you should define the cumulative one as well, so you don't get longer lists 08:14:26 krit: additive is one part 08:14:34 ... if you have two blurs you add the two numbers 08:14:40 birtles: if they're independent animations you do append to the list 08:14:46 ... you don't have the problem of the list building forever 08:14:55 krit: I think that's what I specify at the moment 08:15:01 ... assume that all of the primitives are linear 08:15:13 ... not sure how to figure it out 08:15:21 birtles: might work just to add for blur 08:15:40 birtles: if you're animating a blur from 0 to 2, and then you say run it again and build on your result, going 2-4 is what you're asking for 08:16:00 krit: I think that's what we do right now. if you animate stdDeviation on the SVG filter, you have linear accumulation 08:16:09 ... therefore that's what you do at the moment with SMIL animations 08:16:18 ... so for blur and drop-shadow maybe you can do the same 08:16:25 ... so what about distance, for paced animations? 08:16:33 birtles: there are a bunch of definitions for different data types 08:16:48 ... if there's no meaningful sense of distance for a datatype, don't define it 08:16:58 krit: I don't think distance makes sense for filters 08:17:37 birtles: in the short term we can say there is no distance function for filters 08:21:31 -- break -- 08:26:36 shepazu has joined #svg 08:37:55 stakagi has joined #svg 08:40:45 nikos has joined #svg 08:41:43 https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_Gradients 08:42:14 Topic: Advanced gradients beyond SVG 2 08:43:00 ChrisL has joined #svg 08:43:13 nikos: I wanted to have a high level discussion on the possibility of extending the advanced gradients in SVG after SVG 2 08:43:26 ... it might seem premature to talk about that now, but the reason I bring it up is that Canon is willing to put some time towards this 08:43:35 ... and we want to get feedback from the group if they're interested in in the future 08:43:39 ... if it's a good way to spend our time 08:43:57 ... we think there are two ways to extend the advanced gradients 08:44:05 ... one is diffusion curves, which is something we're particularly interested in 08:44:12 ... we gave a talk at SIGGRAPH last year about our research 08:44:21 ... and I talked last year at Graphical Web about them in SVG 08:44:34 ... the other thing is a stepping stone, or maybe complementary, is to extend the mesh gradients 08:44:39 ... SVG 2 has the coons patch gradients 08:44:51 ... but there are some issues with those, and there are some other representations we might want to look at 08:44:59 https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Advanced_Gradients 08:45:07 ... to start with diffusion curves, there are some examples on the wiki page 08:45:25 ... I'm assuming everyone knows how they work 08:46:59 birtles: is the same as edge blends? 08:47:06 nikos: not totally sure 08:49:06 ChrisL: so diffusion curves, the curves are a boundary, and I was talking with some font designers getting interesting in coloured fonts 08:49:15 ... they wanted the center curve of the shape to be what constrained the gradient 08:49:24 nikos: see the tube example on the wiki page 08:49:54 ... see also the biharmonic model. both the inria people and we have a colour on the left and on the right, and you can also control the gradient along each curve 08:49:59 ... that lets you get a smooth profile through the curve 08:50:11 ... then you can conceptually assign one colour to the curve, and get a smooth gradient through the center 08:50:12 https://gist.github.com/mbostock/4163057 08:50:41 nikos: is that a linear gradient along the path? 08:50:42 ChrisL: ye 08:50:45 s/ye/yes/ 08:51:07 nikos: if you were to do that with diffusion curves, you would have the outside paths, and assign green at the control points at one end and red to the points at the other end 08:51:51 ChrisL: I was talking to John Hudson and said font designers were worried that linear and radial gradients weren't sufficient 08:52:48 nikos: diffusion curves and gradient meshes make the same sort of images 08:52:55 ... smooth transitions, and discontinuities 08:53:05 s/and said/and he said/ 08:53:14 ... the benefit of diffusion curves, and I think it fits well with SVG, is that it's a more compact representation 08:53:24 ... the initial motivation was to mimic what artists draw 08:53:30 ... outlines first, then fill between them with colours 08:53:52 ... and it also lends itself well to animation 08:55:07 nikos: inria have contacted me, and they're interested in collaborating on diffusion curves for SVG or some other kind of mesh for SVG 08:55:16 ... they'll be releasing a library soon that implements their method 08:55:20 ... so will be interesting to see performance of that 08:55:41 ChrisL: the coons patches have the property of smoothness within a patch, and no continuity between patches 08:55:55 ... is there a way to have a type of patch that you can specify a type of continuity between catches? 08:56:31 nikos: there are a few mesh formats that satisfy that 08:56:46 ... inria's solver generates a triangle mesh that does have those properties, since it follows that biharmonic model with smooth transitions across boundaries 08:57:13 ... illustrator's representation they show to the author have those properties, but they subdivide when exporting to patches 08:57:38 Tav: if you look at an output from Illustrator, you can see the lines 08:57:47 ChrisL: seems like an easier way than subdividing and bulking up the content 08:57:55 ChrisL: just have formulation of the patches that have the property you want 08:58:05 nikos: that's something the inria guys wanted to see in SVG 08:58:20 ... it's more general, better for vectorisation of images too 08:58:25 ... I think that could complement diffusion curves 08:58:39 ... diffusion curves for simpler gradients, and meshes for great big areas 08:58:50 ... I think we'd be interested in following both paths 08:58:56 ChrisL: I like the suggestion to rename the mesh gradient 08:59:01 ... either rename it, or put an optional type on it 08:59:14 ... since they'd have different content models etc. 08:59:57 Tav: I've thought about autosmoothing patches 09:00:09 ChrisL: not talking about hacking it in to the existing one, but adding a different type of patch that does have continuity 09:00:22 Tav: we know how illustrator does this, so we could just add that 09:00:36 ... one good thing about coons patch meshes is that PDF, postscript, etc. already support them 09:00:55 ChrisL: to some extent, it ties us to that one type since we've called it "meshGradient" 09:01:30 nikos: I don't see a strong case for having an attribute that specifies the type, rather than having a different element 09:01:39 ChrisL: if we end up with multiple elements, and they take the same list of attributes, that's not a problem 09:01:49 ... if we have one thing with type="", but that determines which attributes you use, that's messy 09:02:04 heycam: I agree 09:02:32 Tav: if we decide to have this smoothing, that's no longer a coon's mesh gradient 09:02:40 ... so the suggestion to rename it to coonsMesh might not be appropriate 09:02:58 nikos: I think you would keep the coon's mesh as is, and if you had a different type you'd name it smoothMesh or whatever 09:03:08 Tav: I think you can add smoothing to coons patch 09:03:13 ChrisL: what's it called in PDF? 09:03:16 nikos: "gradient mesh" 09:03:42 ... that's what it's called in illustrator 09:03:50 ... in PDF there's coons patch, and tensor-product patch 09:03:59 ... that doesn't give you full continuity 09:04:12 ... what's recognised as "gradient meshes" is the full continuity 09:04:24 ChrisL: we did look earlier at tri-mesh and we abandonded that 09:04:49 ... I suggested using Phong shading, since we already have that in filters 09:04:57 Tav: triangle meshes aren't easy to use for the artist 09:05:09 ChrisL: I had proposed using a scatter field of dots, and delauny triangulation 09:07:25 nikos: if the structure is not going to change, it's appropriate to call it "coons patch mesh gradient" 09:07:29 ... it's still based on an array of coons patche 09:07:31 s/patche/patches/ 09:08:35 nikos: I think it's safe to give the current SVG 2 representation a more specific name 09:08:39 Tav: not sure "coons" is the right name though 09:08:50 ... doesn't that describe how you fill it to? 09:08:52 nikos: no 09:09:07 ... the interpolation of the colours is what makes it a mesh gradient, but a coons patch mesh doesn't have to be filled in a particular way 09:09:49 ... you could change some parameters of the blending, and it would still be accurate to call it an array of coons patch 09:09:55 ... so calling it a coons patch mesh gradient would still be accurate 09:10:05 ... the issue is that it might not exactly match what's in PDF for example 09:10:09 ChrisL: a subset of it would 09:10:23 heycam: "coons patch mesh gradient" is quite long as a name 09:11:30 ChrisL: cmesh? cpmesh? 09:19:11 heycam: I don't really like coonsMeshGradient but I can live with it 09:19:19 ... feel like there might be a better name but can't think of one 09:22:45 09:23:08 ... might be ok to drop "Gradient" from the name, since it gets rendered directly (and also can be used as a paint) 09:23:49 ... I like coonsPatchMesh more than coonsMeshGradient 09:24:50 ... ? 09:24:56 Tav: we should add tensor products I think 09:24:59 ... it's not any harder 09:25:15 ... when you render the mesh, it's no hard to handle the tensor products 09:27:12 heycam: what about calling it patchGradient, and then the child elements indicate what kinds of patches are being used? 09:36:45 ... what about: 09:36:56 ... and the can be used for both regular coons patches and tensor-product patches, if we add that 09:37:09 ... any other non-coons patches we might add later would have a name different from 09:37:46 RESOLUTION: We will rename to . 09:38:09 ChrisL: you were also concerned about working on this in parallel, and working in a community group 09:38:15 ... would allow the inria guys to contribute 09:38:23 ... another possibility is a taskforce 09:38:48 nikos: community groups you have to keep things on track, and keep people contributing 09:38:53 ChrisL: seems like a reasonable way forward 09:40:38 heycam: I don't have a good sense of how difficult this would be to implement 09:40:55 nikos: we would hope to implement it in webkit, and probably provide a reference implementation / library 09:41:14 nikos: could demo stuff ~ at the end of the year 09:41:31 ChrisL: the group is not going to say definitely no at this stage, and not definitely yes 09:41:36 ... needs to be demonstrated and looked at 09:41:55 ... so it's not a total waste of time 09:42:11 ... I think with the existing stuff, people will want to get rid of the lines 09:43:43 ... concern with the gradient meshes was that you need this solver to calculate the pixel values which people would be scared about speed 09:43:53 Tav: inkscape's rendering of mesh gradients is fast 09:43:58 cabanier: it's also easily GPU implemented 09:44:48 heycam: acceptable to say to put in some more effort so we can make a better judgement with more data? 09:44:51 nikos: yes I think so 09:44:58 ChrisL: having regular updates from the CG would be good too 09:47:11 http://patate.gforge.inria.fr/html/ 09:50:36 RESOLUTION: SVG WG is happy for CG to be formed to begin looking into diffusion curves. 09:51:22 scribenick: nikos 09:51:35 Topic: Telcon time 09:51:55 heycam: all the daylight savings changes have been made now 09:52:01 ... it would be good to make a time that Chris can call in 09:52:19 ChrisL: I'm available 6am to 8 or 9 pm 09:52:28 ... 9pm finish 09:52:50 Tav: i have trouble before 9am 09:54:02 http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140409&p1=37&p2=152&p3=248&p4=224&p5=179 09:54:30 krit: Need to consider Rich as well 09:54:37 ... he's something like 2 hours after Seattle 09:55:24 http://www.timeanddate.com/worldclock/meetingtime.html?iso=20140409&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179 09:58:38 heycam: 6am Europe seems like a good spread 09:59:02 ... midnight in New York, 11pm in Austin 10:01:04 heycam: times that are possible but not present - 4pm paris, midnight Melbourne, 7am SFO 10:01:25 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=9&hour=14&min=0&sec=0&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179 10:01:39 Ignore the selected day, just look at the time 10:03:23 http://www.timeanddate.com/worldclock/meetingdetails.html?year=2014&month=4&day=9&hour=13&min=0&sec=0&p1=37&p2=152&p3=248&p4=224&p5=24&p6=179 10:07:24 RESOLUTION: new telcon is 3PM Thursday Euro time 10:38:17 nikos has joined #svg 10:52:21 nikos_ has joined #svg 11:07:01 Topic: Variable-width stroke 11:07:26 Topic: 'vector-effect' non-scaling features update 11:07:32 https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_effects_extension 11:07:52 stakagi: I had an action about non scaling object 11:08:14 action-3578? 11:08:14 action-3578 -- Satoru Takagi to Add the new transform(ref) functionality to svg 2 -- due 2014-02-07 -- OPEN 11:08:14 http://www.w3.org/Graphics/SVG/WG/track/actions/3578 11:08:32 ... I prepared this wiki page 11:08:48 ... it was also pointed out that the variation of the effect should be prepared 11:09:01 stakagi: At the Seattle F2F we decided that we should approach non-scaling effects not using transformRef but with vector-effect 11:09:06 ... such as non scaling size and fixed position or non rotating objects, etc 11:09:32 ... this wiki page shows an enhanced proposal for vector effects 11:10:00 ... one effect is non scaling size, another is non rotating, and last is fixed position 11:10:26 ... additional parameters is viewport, screen, device, number 11:10:40 ... I prepared a web application that emulates this 11:10:43 http://svg2.mbsrv.net/devinfo/devstd/non-scaling-objects-2/VectorEffectTest.html 11:12:33 stakagi: The demo is using the equivalent of the viewport keyword. The other options such as screen and so on are not part of the demo 11:12:45 ... each effect is also described as a formula 11:12:55 ... a transformation formula - see section 1.3 11:13:04 https://www.w3.org/Graphics/SVG/WG/wiki/Proposals/vector_effects_extension#Transformation_Formula 11:13:22 stakagi: my question is may I add this to the SVG 2 specification? 11:13:33 ChrisL: I've had a look and it seems generally good to me 11:13:48 ... I had one comment that non scaling by itself was a little odd. Suggested non-scaling-size 11:14:00 ... I've had a play with the app and it seems self explanatory 11:14:32 ... in general this seems to be the sort of stuff that the action covered 11:14:58 ... can't remember the url 11:15:41 ... is it like in svg 1.2 we had ref where you could transform relative to another element? 11:15:54 stakagi: yes, but bits in grey I may remove 11:16:08 heycam: what's the difference between screen and viewport? 11:17:25 birtles: I don't quite understand, but in the formula it's all split out 11:17:41 ... we have get screen ctm in SVG already and that's what screen refers to 11:17:44 ... viewport is a subset of that 11:18:17 ChrisL: viewport only goes one level up so if you have nested viewports... 11:18:49 birtles: if you have nested viewports, then viewport will give you the closest 11:18:54 ... while screen always gives the outermost 11:19:09 ... the third keyword device includes the transformations applied by the browser chrome and so on 11:19:13 ... such as pinch zoom 11:19:19 ... and device pixel ratio 11:19:41 ChrisL: it would be useful to put that in the explanation 11:19:52 ed: the equations have a division by the square root of the determinant of the ctm 11:19:59 ... is it specified what happens when that is zero? 11:20:18 stakagi: when that happens nothing should be displayed 11:20:24 ed: does that need to be stated somwhere? 11:20:33 stakagi: I haven't written the spec text yet 11:21:37 heycam: what was number? 11:21:41 ... goes this number of viewports up? 11:21:46 ChrisL: yes 11:22:27 .. we worked out the common cases were going one level up or all so there's keywords for that 11:22:45 heycam: don't know if there's features that let you reference things in the hierarchy 11:22:54 ChrisL: you mean by counting? 11:22:56 heycam: or by name 11:23:03 ChrisL: we have lots of things where you point to an id 11:23:13 ... sometimes we restrict but in general terms its a uri 11:23:24 heycam: but they're generally things that are downwards 11:24:31 ChrisL: this is basically what we had before with the ref where you might want to reference other svgs and have them pan together for example 11:25:39 ChrisL: what we've done in the past is to use a uri reference for pointing to things in the same or in other documents 11:25:48 ... and restrict to the same document if needed 11:26:30 heycam: if your containing document is a few levels up, where script would be restricted from accessing it, is it ok to get the ctm? 11:26:39 ChrisL: I was imagining it would always be on the same domain 11:27:36 reasonable to allow cross document but not cross domain. same restriction as with script 11:27:52 birtles: wonder how much number will be used 11:27:57 ChrisL: suspect it will be used the least 11:28:05 stakagi: I'm not fussed either way 11:28:39 heycam: is the use case of having the document you stop at being somewhere in the middle of the chain an important one? 11:28:47 stakagi: seems like it would be useful for tiles of maps, but it's hard to know 11:29:46 [Chris gives a use case example of a map where the size of symbols is fixed] 11:30:00 ChrisL: in some ways it's easier to track with an id 11:30:07 heycam: think numbers might be hard for an authoring perspective 11:30:19 ... especially with an adaptive number of levels - you'd have to update the numbers 11:30:47 ... if the use case is knowing where the top level of the map is then it's similar to screen 11:30:55