09:22:15 RRSAgent has joined #svg 09:22:15 logging to http://www.w3.org/2015/06/11-svg-irc 09:22:17 RRSAgent, make logs public 09:22:17 Zakim has joined #svg 09:22:18 Chair: Cameron 09:22:19 Zakim, this will be GA_SVGWG 09:22:19 I do not see a conference matching that name scheduled within the next hour, trackbot 09:22:20 Meeting: SVG Working Group Teleconference 09:22:21 Date: 11 June 2015 09:22:40 scribe: nikos 09:22:43 scribenick: nikos 09:23:00 Topic: defer in preserveAspectRatio 09:23:01 BogdanBrinza has joined #svg 09:23:01 http://mcc.id.au/temp/defer.svg 09:23:12 heycam: should be self explanatory 09:23:34 jun has joined #svg 09:23:46 heycam: works in FF. Not in Safari, Chrome, Opera or IE 09:24:46 ... but test shows that Safari and Chrome do support it 09:24:52 ... so maybe the test is wrong 09:25:02 ... will come back later with a better test 09:26:31 Topic: SVGSVGlement.currentView and SVGSVGElement.useCurrentView 09:26:38 https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals 09:27:24 heycam: this property is meant to reflect the current view, if you linked with a fragment then it reflects the closest ancestor values for preserveAspectRatio, transform, etc 09:28:01 heycam: if you link to a view element then it's supposed to expose attributes from the view element 09:28:17 ... and there's a few variations on where the values come from 09:28:42 http://mcc.id.au/temp/viewspec.html 09:29:03 heycam: FF doesn't support this at all 09:29:40 heycam: expected result is for viewbox string to have all values other than zero 09:29:54 ... if the first has zeros it may mean linking to view elements isn't supported 09:30:16 ... sorry, the first one should reflect viewbox on root svg element 09:30:25 ... when you don't link to anything in particular, that's what should be reflected 09:30:44 ... expected result should be 0,0,100,100 09:30:51 ... second one should be 25,25,100,100 09:31:01 ... third 0,0,2,2, 09:31:11 ... last 5,6,7,8 09:31:35 krit: first and third are zeros in webkit and blink 09:31:47 Rossen: IE doesn't support the object at all 09:32:09 heycam: so is this a useful thing to keep around? considering it's implemented a bit spotily and not everyone implements it 09:32:13 ... I've never seen it used 09:32:35 ed: there's some implementation details that need to stay, but exposing is not strictly neccessary 09:32:52 heycam: so remove .currentView and .useCurrentView? 09:33:29 ed: if we drop them, I'm sure implementation can be simplified 09:33:36 ... but don't know how high in priority this is 09:34:04 krit: it's just on SVGSVGElement 09:34:30 RESOLUTION: remove currentView and useCurrentView properties on SVGSVGElement and remove SVGViewSpec interface 09:35:22 ACTION: Cameron to remove currentView, useCurrentView and SVGViewSpec 09:35:22 Created ACTION-3800 - Remove currentview, usecurrentview and svgviewspec [on Cameron McCormack - due 2015-06-18]. 09:35:53 Topic: SVGLength/SVGAngle constructors 09:36:01 ed: what are we doing with the constructors in svg 2? 09:36:18 ... think for each object we have several constructors, some take unsigned short enums, but we decided also not to add new ones for new unit types 09:36:25 ... so I'm wondering if we should have those constructors at all 09:36:37 heycam: we don't implement them in FF yet 09:36:40 krit: nor in webkit 09:36:51 ed: do we want actual enums in idl, or domstring? 09:37:20 heycam: Amelia brings up the point that these objects aren't so useful if you can't resolve percentages with these things 09:37:24 ... by setting what they resolve again 09:37:31 ... is it useful to be able to create these objects? 09:37:44 ed: yes, right now you have to find SVGSVGElement and create all from there 09:37:52 ... it would be useful to be able to use new 09:37:57 heycam: what are people creating these objects for? 09:38:07 ed: transforming from user space to screen space and things like that 09:38:12 krit: dom matrix has a constructor 09:38:17 ... so that solves that use case 09:38:37 ed: question is can we drop this particular construct? 09:38:45 krit: I don't see value in the new constructors 09:39:04 ... geometry spec covers this 09:39:16 heycam: back to what people are using these things for 09:39:22 ... transforming points with matrices - I've done that a lot 09:39:28 ... so having an easy way to do that would be good 09:39:35 ... maybe geometry utils in css should be used instead 09:39:59 heycam: how do you transform a point with a matrix in the geometry interface? 09:40:07 krit: either DomMatrix or DomPoint 09:40:19 ... you can new a DomPoint 09:40:29 ... SVGPoint is an alias for DomPoint 09:40:48 heycam: I think the SVGLength and SVGAngle are a lot less useful than the point and matrix stuff 09:40:56 ... so I wouldn't mind if we didn't go ahead with their constructors for now 09:41:03 ... don't want to remove the create methods 09:41:10 krit: I suggest deprecating them 09:41:33 ... keep them in the spec but note that you should use the constructors - for the ones where constructors are available 09:41:51 heycam: do you have a view on the default constructor and the one that takes a string? 09:41:57 ed: don't have a strong opinion 09:42:05 krit: I'd prefer them removed 09:42:23 ed: just for those interfaces? or all that define constructors? 09:42:57 heycam: that would include SVGNumber, SVGTransform as well 09:43:11 krit: we hoped that CSSOM would go ahead with defining that, but it doesn't seem to be happening 09:43:40 heycam: Do you think that if we had constructors it would prompt people to use these and make it harder to switch to CSSOM later? 09:43:43 krit: no 09:43:55 heycam: Anyone else have a strong opinion? 09:44:04 others: no 09:45:46 heycam: the only use for SVGNumber is rotate on text element. SVGLength is probably the only one that provides extra functionality that you might want to create these objects for, that's unit conversions 09:45:50 ed: I'm leaning to keeping them 09:46:40 krit: I'd prefer remove - no one is likely to implement them in WebKit 09:47:07 heycam: since there's no strong opinion, the least work is to leave them in the spec for now 09:47:29 BogdanBrinza: why keep them, if we don't have a strong opinion? 09:47:40 heycam: thought people would use them 09:47:49 krit: new content doesn't rely on SVGOM usually 09:47:58 BogdanBrinza: so is there any value in keeping them? 09:48:10 heycam: in practice, it allows you to create objects without doing document.create blah blah 09:48:38 heycam: I think they have marginal utility 09:48:45 heycam: sounds like you'd prefer removal? 09:48:47 BogdanBrinza: yes 09:48:50 ed: I'm ok with removal 09:49:03 RESOLUTION: remove constructors from SVG data type interfaces 09:49:35 RESOLUTION: Deprecate createSVGMatrix, createSVGRect, and createSVGPoint and recommend the Geometry constructors are used instead 09:49:58 ACTION: Erik to remove constructors from SVG data type interfaces and note deprecation of create methods 09:49:58 Created ACTION-3801 - Remove constructors from svg data type interfaces and note deprecation of create methods [on Erik Dahlström - due 2015-06-18]. 09:50:17 Topic: Should the SVGAnimatedPathData interface be a [NoInterfaceObject] 09:50:24 heycam: think it shouldn't 09:50:31 ... the only time should be when they're mixin interfaces 09:50:34 ed: it's kind of a mixin 09:50:40 ... contains pathSeg accessors 09:51:05 heycam: then I change my mind - it should be 09:51:17 ed: it never was exposed on the window and this isn't new to svg 2 09:51:37 RESOLUTION: SVGAnimatedPathData interface should be a [NoInterfaceObject] 09:51:44 ACTION: Erik to make SVGAnimatedPathData a [NoInterfaceObject] 09:51:45 Created ACTION-3802 - Make svganimatedpathdata a [nointerfaceobject] [on Erik Dahlström - due 2015-06-18]. 09:52:05 Topic: What should image { width:auto } result in? 09:52:20 ed: if you put width or height auto on image element, what should happen? 09:52:26 krit: that's the default if you don't specify a width or height 09:52:31 ed: we wanted to use the intrinsic size of the iamge 09:52:35 krit: but would you break content? 09:52:37 ed: maybe 09:53:01 heycam: didn't we add auto sizing behaviour to the spec? My feeling was we were going to use the keyword auto in thea ttributes for that, which conflicts with auto in the property 09:53:13 krit: are you suggesting auto default to zero? 09:53:26 ... if you don't specify width or height it shouldn't render, so auto should default to zero 09:53:37 heycam: if we did plan auto to mean intrinsic size we couldn't do that 09:54:00 ed: we had resolution that size should be taken from the image 09:54:10 ed: I think risk it and see if we get feedback 09:54:17 krit: add a note asking for implementor feedback 09:54:50 BogdanBrinza: makes sense for auto to take intrinsic size as in HTML 09:55:03 heycam: there are rules when an image has no intrinsic size 09:55:21 ... there's a risk of content relying on no width or height disabling rendering 09:55:41 BogdanBrinza: I haven't seen that done 09:55:47 ... as a common technique 09:55:57 krit: do we also support max width and height? 09:56:09 BogdanBrinza: pretty common to specify that with no width or height - at least in HTML 09:56:27 heycam: is that for doing something like - I want image to be at least 200px wide but dont' want it to go wider than the viewport width? 09:56:31 BogdanBrinza: yes 09:56:37 heycam: I'm leaning to trying the change then 09:56:47 ... change no width or height on image to use intrinsic size of the image 09:57:13 ed: the spec currently suggests that 09:57:39 Rossen: we just spent some time re-implementing our intrinsic widths 09:58:07 ... I remember the last discussion we had in Seattle in 2013, we agreed that we are going to follow IEs behaviour for a lot of these cases 09:58:16 ... then a following discussion in Leipzig 09:58:28 krit: don't think this has anything to do with that - we're talking about the SVG image element 10:00:31 ed: this came from a bug report in chrome 10:00:44 ... someone thought that a css rule that set auto shouldn't apply - but it does in Blink 10:01:05 ... they were asking if they should pick the attribute value 10:01:16 http://mcc.id.au/temp/image.svg 10:01:17 ... but now there's presentation attributes for the properties it's clear 10:01:41 krit: we currently have the issue in illustrator/photoshop - what setting should we use for copy/paste the code into html 10:01:49 ... e.g. style classes may overwrite each other 10:01:54 ... same for presentation attributes 10:02:06 ... so safest thing would be to use the style attribute to set these values 10:02:15 ... but still doesn't protect against !important 10:02:30 heycam: so original question - the result is that we just need to explain how width auto works 10:02:49 ed: yes, and think there should be a note saying we've changed from SVG 1.1 which was zero default 10:03:04 krit: same for rectangle - should default to 0,0 10:03:25 heycam: so you want to point out that auto is intial value and how it relates to shapes and things with intrinsic size 10:03:40 Rossen: what about foreignObject? 10:03:52 heycam: interesting one - you could get dimensions out of the object 10:03:59 krit: foreignObject should be like iframe 10:04:03 Rossen: and video 10:04:08 heycam: if we keep it in svg namespace 10:04:35 heycam: do we think it's safe to change foreignObjects lack of width/height behaviour? 10:04:41 ... to shrinkwrap or whatever? 10:04:49 Rossen: I wouldn't do that - I'd default to 300x150 10:05:02 heycam: wouldn't shrink wrapping be more useful? 10:05:10 bogdan: it's unpredictable 10:05:27 heycam: I think of FO as like a div 10:05:32 Rossen: no, think of it as an iframe 10:05:45 ... there's a reason we don't have shrink to fit on iframes 10:05:56 ed: I'd say making it the size of the svg is more useful 10:06:10 heycam: you're not always going to have it at (0,0) 10:06:36 ed: 300x150 is a bit arbitrary and not that useful either 10:06:42 Rossen: but it's familiar to HTML users 10:06:48 ... and it's predictable 10:07:10 ed: but svg usually have viewboxes and 300x150 may not mean the same thing 10:07:15 heycam: same with image though 10:07:36 heycam: this is for inline content though - foreignObject with some child html things 10:07:41 ... I don't see it the same as an iframe 10:07:46 ... iframe is a contained thing 10:07:50 ... a completely separate document 10:08:00 ... i you implement foreignObject with href on it, it's like an iframe 10:08:07 ... but if you have inline contents it's much more like a div 10:08:33 Rossen: if I have a fixed position element in a foriegnObject - where would it be positioned? 10:08:58 heycam: talked about this in London - answer was to make a foreignObject initial containing block 10:09:03 krit: which would affect viewport units 10:09:10 ... did you test and did it work in all browsers? 10:09:26 Rossen: not in Blink - it's very buggy 10:10:43 krit: inline svg has same content units as parent. But foreignObject changes this 10:10:57 heycam: if you have inner svg and you use vw and vh, what does it get resolved against? 10:11:01 Rossen: the foreignObject 10:11:35 heycam: I wonder if people would be surprised if vw and vh resolve against something different in a foreignObject? 10:11:57 Rossen: I don't think so 10:12:09 ... otherwise you're taking dependency on something way up the ancestor chain 10:12:48 ... and you have to go and invalidate things that may be hidden inside some foreignObject - it's a broken model 10:13:46 ... I think 300x150 is the most consistent and easy to explain 10:13:54 ... people are not going to like it, but it's very easy to fix 10:14:19 krit: removes a lot of complexity regarding size negotiations 10:14:28 heycam: would there be any way to opt in to a shrink wrap type thing? 10:15:04 Rossen: we had an internal object that was like an iframe but did shrink to fit. It's an unstable model so we moved away from it. 10:15:32 heycam: ok. Guess there's other ways to get that behaviour if you want it 10:15:46 heycam: so 300x150 for foreignObject, video, iframe 10:16:08 krit: what is the css viewport for the foreignObject? The containing block defined by the foreignObject? 10:16:10 Rossen: yes 10:16:30 heycam: what happens if you have auto as one width or height and non auto for the other? 10:16:37 ... resolve against the aspect ratio? 10:16:46 Rossen: only thing with intrinsic ratio that we respect are images 10:16:53 ... everything else falls back to default value of one or the other 10:17:08 ... if one or the other is not specified it just uses the default - 300 for width, 150 for height 10:17:27 RESOLUTION: for width and height on foreignObject, video, and iframe - auto means 300x150 10:17:41 ed: do we want to special case svg images? 10:17:43 heycam: no 10:18:05 heycam: we want to behave just like html image 10:18:23 Rossen: what happens for SVG as an image? 10:18:33 heycam: if you don't have intrinsic info then you get 300x150 10:18:37 Rossen: you might want to check on that 10:18:55 ... we spent some time on this recently - had a giant table of all the permutations 10:19:11 krit: but that's a requirement for the integration spec 10:19:17 ... don't see any special behaviour for svg 10:19:27 heycam: those issues apply to HTML referencing SVG as well 10:19:43 ... presumably there's a term in a CSS spec that defines the algorithm for intrinsic size/ratio, etc 10:20:19 Rossen: Probably in css 21 Section 10.3 10:20:44 BogdanBrinza has joined #svg 10:20:48 ed: so the svg image element is not laid out by CSS so therefore we need to make sure it's handled the same way as if it was an image element in CSS 10:21:00 element in CSS/element in HTML 10:21:10 http://www.w3.org/TR/CSS21/visudet.html#inline-replaced-width 10:21:50 RESOLUTION: SVG image elements with no width or height is sized just like HTMLs image element 10:27:01 ACTION: Rossen to update spec to say what auto means for each element that uses it 10:27:01 Created ACTION-3803 - Update spec to say what auto means for each element that uses it [on Rossen Atanassov - due 2015-06-18]. 10:27:14 Topic: Testing 10:28:25 [Cameron presents how to create at test] 10:29:34 heycam: we'll use web platform tests repostiroy 10:29:43 https://github.com/w3c/web-platform-tests/tree/master/svg 10:29:44 ... I added all svg 1.1 test files to the repo 10:29:51 s/repostiroy/repository 10:30:24 ... they're in the import directory 10:30:47 ... I'd like us to convert these to the webplatform expected format - it's probably easier than writing new tests 10:30:53 ... that would be ref tests 10:31:03 ... so ideally chapter owners would work on the tests from their chapter 10:31:16 ... I've done a couple and I've got some PRs for those that haven't been merged yet 10:32:47 [shows old format vs new format] 10:32:59 ... these old ones are manual tests 10:33:23 ... I turned this one test into many smaller tests - thought it would be preferable 10:33:39 ... metadata is just like CSS repo metadata 10:34:23 ... here I've compared an SVG rect against a CSS rect 10:34:32 Rossen: not sure about that approach 10:34:45 ... theoretically if there's no match, you don't know if it's because HTML or SVG is wrong 10:35:04 krit: ref tests make the assumption that your reference is always working 10:35:14 Rossen: in CSS we always use images 10:36:22 s/always use images/depend on images for such basic features/ 10:37:00 heycam: there's no harness to run tests automatically 10:37:15 Tavmjong: this relies on HTML - what do I do? 10:37:22 heycam: if I change reference to a png, that would solve that problem 10:39:34 heycam: I added some html refs for rounded corners - but I'm not sure about that. Some browsers may not use the same shape for both 10:40:42 heycam: I also added a scripted test - SVGElement.ownerSVGElement-01.html 10:40:50 ... use the testharness.js framework 10:41:07 ... that framework has a test() function that you pass your testing function to 10:41:16 ... inside that you have lots of asserts 10:41:38 ... one issue is that testharness.js doesn't work if the outer document is an svg document 10:42:16 ... this is only for scripted tests should hopefully doesn't preclude any user agents 10:42:32 s/should hopefully/so hopefully 10:43:14 Tavmjong: would be nice to separate the types of tests so I can easily skip script tests? 10:43:39 Rossen: would like to separate by chapter, then within that by refs and dynamic tests 10:43:52 heycam: how do you distinguish between which are scripted and which are ref tests? 10:43:58 Rossen: that's why we have two different folders 10:44:23 heycam: so how about we do that at the top level? 10:44:34 Rossen: think putting them inside is better - you might have some that have only ref tests and not scripted tests 10:45:02 ... we should be vigorous in establishing the right patterns from the start 10:45:19 ... enforce naming and structure 10:45:41 heycam: how about e.g. shapes/reftests/rect-blah-01.html for ref tests 10:46:06 ... and types/scripted/SVGElement.ownerSVGElement-01.html for script tests 10:46:17 ... I'll write up an initial style guide and put it in the repository 10:46:41 ... think it's a good idea to have chapter owners in charge of the tests for that chapter 10:47:12 ... we're going to find a lot of deficiencies in our chapters as we write tests 10:48:06 tbah has joined #svg 10:48:50 Tav: reference pngs should be the same width and height as the svg image to make visual comparison easy 10:49:34 heycam: we need to take care when converting to ensure that tests are still relevant and correct for SVG 2 10:49:53 ... think only for fundamental tests like rectangle and path should we use png references 10:50:07 ... then once we've established the fundamental functionality, tests should be svg vs svg 10:50:24 ed: there's rel="match", is there a no match? 10:50:46 heycam: documentation for that is all on testthewebforward.org 10:52:31 ed: other question, is it possible to have two reference images and both must match? 10:52:45 heycam: apparently rel="match" means match against one thing, so if you want to test against more than one thing you need to duplicate the test 10:52:56 heycam: what about for text? I feel that could use html for the references 10:55:46 BogdanBrinza has joined #svg 10:55:56 you could use ahemfont 10:55:58 heycam: the procedure for submitting tests is to fork repository, make branch with changes, make a pull request and somebody will comment or merge. There's information about that procedure on testthewebforward.org 10:58:42 Topic: animVal and baseVal 10:59:23 heycam: think Brian felt there should be ways of getting values for things that aren't going to be CSS properties 10:59:32 ... but I don't want to make some API that is going to duplicate what web animations will cover 10:59:49 RESOLUTION: animVal will alias baseVal 11:00:10 krit: then animVal would not be read only anymore 11:00:22 heycam: I take it to mean it's the very same object 11:00:49 ... don't think it would be too hard to make one of them read only 11:01:06 krit: we need to change every chapter - it's spread out over the whole spec 11:01:18 ACTION: Cameron to make animVal change to all chapters 11:01:19 Created ACTION-3804 - Make animval change to all chapters [on Cameron McCormack - due 2015-06-18]. 11:02:25 Topic: Logical block-size and inline-size properties and svg/rect width/height 11:02:45 11:02:58 heycam: if you do that - you get a rectangle that is 10px wide and 20px high 11:03:08 ... because of the way logical properties are a way of setting the actual properties 11:03:15 ... it's a bit weird, but it's a result of having them as properties 11:03:27 krit: is rectangle even a block? 11:03:31 heycam: doesn't matter 11:03:47 ... it's what you'd expect, but maybe a bit funny 11:06:52 Topic: Changing attribute 'extent' to 'measure' 11:07:03 TabAtkins: Tab pointed out that extent and measure were once upon a time defined in CSS 11:07:17 ... they're no longer being used, but we were using extent where the proper print term is measure 11:07:30 ... shall we switch to measure? 11:09:56 Rossen: how about inline and block? 11:10:41 heycam: what happens if you specify inline and block size? 11:10:43 BogdanBrinza has joined #svg 11:10:58 heycam: answer is you don't do anything with the block size 11:11:17 http://dev.w3.org/csswg/css-logical-props/#logical-dimension-properties 11:12:03 heycam: we decided not to introduce any new presentation attributes for new properties that we invent or new css properties that we apply to svg content 11:12:08 ... this would be one of those cases 11:12:17 ... so you'd need to do style= 11:12:23 krit: we don't need to be so strict 11:12:33 ... for certain things we could have presentation attributes 11:12:50 heycam: I'd like to define the rules of when we do, which would be tricky 11:12:57 stakagi has joined #svg 11:13:06 Tav: this is a geometry thing, which could make sense for a presentation attribute 11:13:15 ... where as something like font-variant is completely a style thing 11:13:41 heycam: depends how you look at it - x,y,width and height are presentation attributes so inline-size could be 11:13:53 ... but they're only presentation attributes because they used to be properties 11:14:02 Rossen: for this particular one I feel favourable to making an exception 11:14:16 ... this is perhaps the first and maybe only case where SVG comes really close to CSS in terms of layout 11:14:19 ... of text 11:14:26 ... it's pretty much CSS 11:14:53 ... and making those closely bound by terminology and everything that is being specified will make it easier to bridge those two things 11:15:00 ... just for the naming 11:15:12 ... since these attributes already exist, I think this could be considered a rename 11:15:40 heycam: width and height already exist you're saying, so the logical equivalents should also exist as presentation attributes? 11:16:51 Rossen: use cases where people use SVG as the bullet image for list items (say an arrow), when writing mode changes the direction of the arrow usually changes as well 11:16:59 ... style is a nice way to modify that 11:17:07 ... using a logical property 11:17:24 heycam: there's no way to inherit writing-mode and direction from the outer document to your image document though yet 11:17:39 ... your general point of writing-mode agnostic graphics is a reasonable use case though 11:17:45 heycam: I'm happy having a presentation attribute then 11:18:34 RESOLUTION: Rename text attribute 'extent' to inline-size and it's a presentation attribute for that logical property 11:19:00 jun has joined #svg 11:39:56 Zakim has left #svg 14:52:30 RRSAgent has joined #svg 14:52:30 logging to http://www.w3.org/2015/06/11-svg-irc 14:52:46 RRSAgent: make minutes 14:52:46 I have made the request to generate http://www.w3.org/2015/06/11-svg-minutes.html heycam 14:53:16 RRSAgent: make logs public 14:53:23 RRSAgent: make minutes 14:53:23 I have made the request to generate http://www.w3.org/2015/06/11-svg-minutes.html heycam 14:53:56 Present: Rossen, Jun, Satoru, Tav, Erik, Dirk, Frederick, Cameron, Nikos, Bogdan 14:54:01 RRSAgent: make minutes 14:54:01 I have made the request to generate http://www.w3.org/2015/06/11-svg-minutes.html heycam 14:58:19 jun has joined #svg 14:58:38 stakagi has joined #svg 15:15:42 ScribeNick: heycam 15:15:45 Scribe: Cameron 15:15:48 Topic: lacuna values 15:16:05 Rossen: I don't know the history behind the term, but anyone I speak to is confused about the term 15:16:29 ... if we can agree on a more standard name 15:16:43 stakagi has joined #svg 15:16:51 ... so I know that there was a problem with using the term default 15:16:57 ... but initial would make sense 15:16:58 shepazu has joined #svg 15:17:04 tbah has joined #svg 15:17:07 ed has joined #svg 15:17:35 jun has joined #svg 15:18:00 fs has joined #svg 15:19:06 ... so I propose that we call these initial values 15:19:25 BogdanBrinza has joined #svg 15:20:08 ed: would initial potentially be confusing, especially if we promote properties later? 15:22:08 heycam: I am fine with initial 15:22:10 ed: met oo 15:22:12 s/met oo/ 15:22:13 s/met oo// 15:22:51 tbah has joined #svg 15:22:56 ed: me too 15:23:10 RESOLUTION: Replace "lacuna value" with "initial value" 15:23:18 ACTION: Rossen to update "lacuna value" to "initial value" 15:23:19 Created ACTION-3805 - Update "lacuna value" to "initial value" [on Rossen Atanassov - due 2015-06-18]. 15:25:32 Tav has joined #svg 15:28:24 https://svgwg.org/svg2-draft/coords.html#ObjectBoundingBoxUnits 15:33:56 trackbot, close ACTION-3805 15:33:56 Closed ACTION-3805. 15:55:07 http://www.bistrofolke.se/ 16:37:56 ed: heycam: Was it that that we discussed in Leipzig: file:///Users/dschulze/Documents/svgwg/build/publish/coords.html#IntrinsicSizing ? 16:37:59 oops 16:38:21 https://svgwg.org/svg2-draft/coords.html#IntrinsicSizing 16:40:11 krit: I remember that we discussed the sizing things in Leipzig, but don't quite recall all the aspects 16:45:35 ed: no, not talking about details 16:45:49 ed: did we discuss SVG as image or the embed case? 16:48:20 krit: I think we mostly discussed the inline svg case, but that it mapped well to the other cases 16:48:23 see https://docs.google.com/presentation/d/1POUiroOBbLmXYlQKf0pIR8zVkHWH9jRVN-w8A4aNsIk/edit#slide=id.g1e19b0d66_2126 17:05:37 RRSAgent: make minutes 17:05:37 I have made the request to generate http://www.w3.org/2015/06/11-svg-minutes.html heycam 17:22:26 stakagi has joined #svg