07:01:46 RRSAgent has joined #svg 07:01:46 logging to http://www.w3.org/2015/06/09-svg-irc 07:01:48 RRSAgent, make logs public 07:01:48 Zakim has joined #svg 07:01:50 Zakim, this will be GA_SVGWG 07:01:50 I do not see a conference matching that name scheduled within the next hour, trackbot 07:01:51 Meeting: SVG Working Group Teleconference 07:01:51 Date: 09 June 2015 07:04:13 Meeting: Linköping F2F day 1 07:06:36 slightlyoff has joined #svg 07:06:44 RRSAgent, remind me in 8 hours about something 07:06:44 I'm logging. I don't understand 'remind me in 8 hours about something', ed. Try /msg RRSAgent help 07:06:54 Zakim, remind me in 8 hours about something 07:06:54 ok, ed 07:08:14 Agenda: https://www.w3.org/Graphics/SVG/WG/wiki/F2F/Linkoping_2015/Agenda_proposals 07:10:59 pdr has joined #svg 07:16:58 stakagi has joined #svg 07:19:12 krit has joined #svg 07:23:12 cabanier has joined #svg 07:27:35 BogdanBrinza has joined #svg 07:30:18 BogdanBrinza_ has joined #svg 07:31:20 Zakim, room for 5 07:31:20 I don't understand 'room for 5', ed 07:31:24 Zakim, room for 5? 07:31:25 ok, ed; conference Team_(svg)07:31Z scheduled with code 26632 (CONF2) for 60 minutes until 0831Z 07:32:22 Team_(svg)07:31Z has now started 07:32:29 +[IPcaller] 07:32:41 Zakim, [IP is svgwg 07:32:41 +svgwg; got it 07:34:39 Scribe: Cameron 07:34:41 ScribeNick: heycam 07:34:48 Present: Cameron, Erik, Rossen, Bogdan, Tav, Takagi, Nikos, Fredrik Söderquist 07:35:50 Topic: Resolving on getting SVG 2 to CR 07:36:03 + +1.415.832.aaaa 07:36:05 BogdanBrinza_: last time we agreed that we want to take this to a stable spec, resolve the issues as fast as possible 07:36:09 ... we've made great progress on the issues 07:36:19 ... what I think we lost along the way is an understanding of where we are right now 07:36:27 ... are we close to this? 07:36:44 ... what are the steps we need to get to CR? 07:37:28 BogdanBrinza_: one of the things that might be useful in getting us there, is to ask chapter owners to present the current state of the chapters 07:37:37 stakagi_ has joined #svg 07:37:37 ... we have done a lot of changes, but more are expected 07:37:44 ... we should figure out what's remaining for every chapter 07:37:50 ... if any chapters are ready we could sign off on them now 07:38:45 ... let's look at each chapter 07:38:51 ... chapter 1, cyril, no issues; we can move forward 07:38:55 ... chapter 2, rendering model 07:39:03 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Chapter_Assessment 07:39:44 nikos: as far as issues go, there's nothing else that needs resolving on 07:39:49 ... it's just a case of making the changes that need to be done 07:40:01 BogdanBrinza_: how long do you expect those changes to be made? 07:40:18 nikos: I think Cameron was going to something about the overflow property 07:40:47 BogdanBrinza_: so nothing blocking? 07:40:49 nikos: no 07:41:16 +[IPcaller] 07:41:21 -svgwg 07:41:34 nikos: I think the most useful thing would be to get some feedback on the changes 07:42:14 BogdanBrinza_: maybe do that after this? 07:42:21 BogdanBrinza_: next one is types is Cameron 07:43:54 heycam: Issue 20, SVGViewSpec definitions, I made some progress on 07:44:00 ... have it on the agenda for discussion 07:44:12 ... Issue 13, getCTM, is awaiting Dirk's ACTION-3724 07:44:25 ... Issue 15 is waiting for use counter results, I think Erik was going to measure that 07:44:32 status of getTransformToElement - https://www.chromestatus.com/metrics/feature/timeline/popularity/692 07:44:46 ed: this probably hasn't hit stable yet 07:44:59 BogdanBrinza_: I think that's similar to most non-mainstream features 07:45:03 ... i.e. extremelty low usage 07:46:05 ed: we were measuring this to see if we can avoid defining how getTransformToElement works between separate SVG fragments 07:46:09 ed: this is in stable already actually 07:46:13 ... so the numbers should be good 07:46:46 BogdanBrinza_: we don't get different usage between intranet and public internet for web features, generally 07:46:51 ... I wouldn't expect this to be different 07:47:16 RESOLUTION: Drop getTransformToElement 07:47:22 ACTION: Cameron to remove getTransformToElement 07:47:22 Created ACTION-3793 - Remove gettransformtoelement [on Cameron McCormack - due 2015-06-16]. 07:48:17 Tav has joined #svg 07:48:25 heycam: I haven't looked into the getCTM issue 07:48:33 ed: it's related to other issues with adding transform to 07:50:01 To getScreenCTM: The intention was to get all transforms to the device coord space 07:50:14 Not sure if we want to do that. Should be clarified in the spec 07:50:23 (Especially for inline SVG) 07:52:47 heycam: I am a bit worried about lots of features in the spec being underspecified 07:52:59 shane has joined #svg 07:53:01 ... and we'll only really work out the gaps once we start building up the test suite 07:53:13 ... not sure whether people want to try to get everything nailed down exactly before CR 07:53:20 ... or to do that after CR while we work on testing 07:53:44 ... apart from that this chapter is close to being done 07:54:00 ... I added one new issues too, but we can discuss that later 07:54:18 BogdanBrinza_: next one, Document Structure, Erik 07:54:26 ed: I have quite a few issues in progress 07:54:31 ... most of them have actions assigned 07:54:36 ... so it's just a matter of getting to do them 07:54:48 ... some of the issues that are open are not on me, and some of them are on things that should move to other chapters 07:54:52 ... or are general, for the entire spec 07:54:57 ... I think there's not a whole lot to be done 07:55:05 ... the most complicated one is the element, and all the definitions around them 07:55:09 ... it's kind of loose at the moment 07:55:20 ... it depends how we want to specify that, and how much we want to refer to Web Components 07:55:23 ... and Shadow DOM 07:55:31 What about playbackorder on SVG element? 07:55:35 ... external is probably the most difficult one to nail down 07:55:46 It doesn't have an issue but do we still want that with WebAnim? 07:55:51 ... I think one way to solve that would be to not require external in this spec, but to lay down some requirements for it 07:55:54 ... as an optional feature 07:56:02 s/doesn't/does/ 07:56:20 ... some implementations support external use, some don't 07:56:24 ... should we require it? 07:56:32 ... that's not listed among the issues here, but just something I know is the case 07:56:43 ... I know people want to use external 07:56:47 ... for icon resources, etc. 07:57:12 heycam: what is the difficulty? just SVG Integration kind of issues? 07:57:24 ed: for example if you have @media rules, what's the viewport of the resource document? 07:57:29 ... the element may not define the viewport 07:57:46 ... whether that should be the same as the using document's viewport or not 07:58:09 ... for Blink, there's no frame for the external resources, and that causes issues for CSS cascading 07:58:23 ... it's kidn of why it doesn't work properly with external all the time 07:58:26 s/kidn/kind/ 07:58:35 ... it would be somewhat complicated to rewrite to use a frame there, though not impossible 07:58:39 ... it's what we used to do in Presto 07:59:08 BogdanBrinza_: do you have security concerns? 07:59:13 ed: for sure, which we haven't thought much about 07:59:24 BogdanBrinza_: a perfect user tracker? 07:59:33 ed: that's why I suggested having crossorigin attribute on 07:59:35 ... which is now in the spec 07:59:41 ... I have a prototype implementation for Blink 07:59:50 ... that could use some more review/feedback 08:00:00 ... so is the biggest slowdown factor in this chapter 08:00:07 ... the rest of the issues are mostly editorial or simple to do 08:00:15 ... the accessibility ones, I haven't looked at them yet 08:00:19 ... hopefully Rich is on top of those 08:00:59 Rossen: it's a bit of a catch-22; it's one of those applicable features that I can see people requesting a bit 08:01:04 ... at the same time, it's going to be the one that'll slow us down the most 08:01:16 ... working out security, perf, ... 08:01:38 ... the underlying implementation complexity is quite high for this 08:01:47 ... my suggestion would be, if we can, to peel it off from this chapter altogether 08:01:51 ... and then work on it on its own 08:01:57 ... as much as we can 08:02:07 ... I'm leaning toward your first suggestion, have something basic specified here 08:02:24 ed: I think the text at the moment is more or less the same as SVG 1.1 08:03:28 ... we can have this as an optional feature that have certain requirements -- such as scripting disabled 08:04:40 Rossen: how would you test it then 08:04:45 krit: don't need to test it if it's optional 08:05:21 Rossen: this is a really sought after and requested feature 08:05:26 ... it's going to require a lot of work speccing and implementation 08:05:35 ... in that respect, it deserves its own place 08:05:40 krit: I think more work to specify than implement 08:05:45 Rossen: I wouldn't go that far 08:05:58 ... but anyway, it would be easier if we peel it off in its own module, and work on it there 08:06:05 ... we're not going to slow down anything by doing this 08:06:24 ... we might give room for people to work on external resources an easier way to make progress, without having to be bogged down with the SVG 2 spec 08:06:30 ... and then we can spend the time iterating on that modules 08:06:33 s/modules/module/ 08:06:43 Rossen: I agree with Cam, specifying it half way is as good as not specifying at all 08:07:10 krit: if you make it an optional feature, say that we work on a spec later on, but implementations have to think about certain issues --- we know already what the big problems will be 08:07:31 ... otoh SVG 1.1 supported it 08:07:36 ed: it's there but it's not well defined 08:07:40 ... so it's not really something you can count on 08:07:47 ... there are lots of things that are undefined in SVG 1.1 08:08:33 heycam: I don't mind having a note in there to say it's planned for a module 08:08:44 Rossen: I would say that it should be read that we do indeed care about this feature 08:08:59 ... to the extent that we're dedicating a module to it, where it can be worked on in a focussed way 08:09:26 ... having a module like this is going to loop in a whole bunch of other depenencies 08:10:40 krit: I'm fine with adding a note, rather than it being optional 08:10:41 ed: me too 08:11:29 heycam: so we should create a new module and point to it from the SVG 2 spec? 08:11:31 Rossen: yes 08:13:23 Rossen: we don't need the document to be there now, we can see the feedback in response to this change 08:13:34 ... what Dirk says makes sense; let's see when someone has the time to work on it 08:13:46 ... until then, SVG 2 will be fine on its own, and will have the note mentioning the future work 08:14:22 heycam: so will this be disallowed or undefined? 08:14:40 krit: undefined 08:14:43 Rossen: I'm ok with that 08:14:53 ... if someone has an implementation, I don't want them to remove it 08:15:28 heycam: what does that mean for the crossorigin attribute that got added? 08:15:35 ed: I think that would get moved to the new module 08:15:46 ... attribute doesn't make sense without external references 08:15:51 ... I would remove that as part of undefining it 08:16:47 heycam: makes me feel we should have the module so we have somewhere to move it 08:17:37 RESOLUTION: SVG 2 will leave external as undefined and mention in a note that we plan to work on defining it in a future/separate spec 08:18:01 ACTION: Erik to make external be explicitly undefined and remove crossorigin attribute 08:18:01 Created ACTION-3794 - Make external be explicitly undefined and remove crossorigin attribute [on Erik Dahlström - due 2015-06-16]. 08:19:00 Bogdan: there is one issue for discussion, about requiring CSS? 08:19:10 heycam: we've already decided that, to require style sheet support 08:19:19 ed: I'll just drop the "if you support style sheets" wording 08:19:39 BogdanBrinza has joined #svg 08:21:11 next up: styling chapter 08:21:26 heycam: chapter not close to being done 08:21:52 heycam: some of the issues for discussion I have on the agenda 08:22:15 ... the only one I haven't made progress on is the UA style sheet 08:22:21 ... issue 18 08:22:34 ... most of the open issues are editorial/rewrites 08:22:37 ... I will overhaul the chapter 08:23:12 Rossen: an issue that come up at CSS is filtering propagation of property inheritance 08:23:28 ... let's say you have inline SVG, would a color property inherit in? 08:23:34 ... what about for inline SVG with a forignObject in it? 08:23:45 ... so there was a discussion about "filtering" property values 08:24:00 ... the CSS WG said that SVG has to deal with this, and define the boundaries and what propagates or not 08:24:21 ... my take is that we should make a stronger statement, and have it handled in HTML, in general, if we want to have any kind of value propagation filtering or not 08:24:41 ... and SVG would be one of the elements as part of that 08:27:00 [some discussion of examples] 08:27:34 Rossen: just want to bring that up from CSS WG 08:27:41 Rossen: let's discuss the issue later 08:29:33 http://en.wikipedia.org/wiki/Fika_%28culture%29 08:30:00 -- break -- 08:30:18 -[IPcaller] 08:36:01 disconnecting the lone participant, +1.415.832.aaaa, in Team_(svg)07:31Z 08:36:03 Team_(svg)07:31Z has ended 08:36:03 Attendees were [IPcaller], svgwg, +1.415.832.aaaa 09:00:05 Zakim, room for 5? 09:00:06 ok, ed; conference Team_(svg)09:00Z scheduled with code 26632 (CONF2) for 60 minutes until 1000Z 09:00:26 Team_(svg)09:00Z has now started 09:00:33 +[IPcaller] 09:01:20 Zakim, [IP is svgwg 09:01:20 +svgwg; got it 09:02:05 Bogdan: Geometry chapter 09:02:39 ... I think we did decide what to do with issue 1, which is what to do with text x/y properties 09:03:21 ... Dirk will remember for sure, but I think it was #2 09:05:13 Rossen: and we have a resolution on this already? 09:05:15 heycam: I believe so 09:05:36 Bogdan: next chapter, Coordinates 09:05:44 ... most of the issues listed there are actionable 09:05:50 ... two things need discussion with the WG 09:06:05 ... whether we should drop "defer", I have an action to create a test acse 09:06:33 http://www.w3.org/2015/02/12-svg-minutes.html 09:06:36 ... when we discussed it, we had trouble coming up with useful examples of it 09:06:49 BogdanBrinza has joined #svg 09:08:12 http://www.w3.org/2015/03/19-svg-minutes.html 09:09:39 BogdanBrinza: is it a compelling enough use case to keep this? 09:09:51 ... the meeting notes lead me to believe it is not 09:11:30 ... we were going to send a mail to the list asking if anyone has use cases for defer 09:12:44 ... next issue is issue #20, needs talking with dirk; let's wait until he's here 09:15:17 Tav: issue 17 in coords.html is on me 09:15:26 ... to define objectBoundingBox for mesh gradients 09:15:39 ... when it's not being used as a paint server, what does objectBoundingBox mean? 09:15:45 ... this is for x/y attributes 09:16:24 ... but for the mesh path syntax, that's always in user units 09:17:24 heycam: objectBoundingBox isn't that useful if the path syntax can't be interpreted as objectBoundingBox values 09:17:58 nikos_: one the primary use cases for mesh gradients is to make scalable complex fill textures 09:18:17 ... so being able to scale it is essential for that, to fit within the object being filled 09:18:39 Rossen: can you give a simple example? 09:18:46 nikos_: suppose you are making an icon, and the icon can be various sizes 09:19:19 ... the icon is a car. for different parts of the car, you define mesh gradient, but you want to be able to size that automatically to the size of the icon 09:22:54 BogdanBrinza: how can you transform the coordinates of a mesh? 09:23:00 Tav: you can put a gradientTransform="" on it 09:23:58 ed: patterns are an example of a paint server with x/y/width/height 09:24:02 ... and it's just a scaling factor 09:24:17 ... if you want to set up a coordinate space for the segments of the mesh, you could use that 09:24:26 Tav: still has to be mapped into the bounding box, though 09:24:34 ed: it's the same for patterns 09:25:30 nikos_: if you have a game, and tiles in the game, a grass texture defined with a mesh gradient, and you want to fill different shapes with that... 09:25:47 Tav: I think the most useful thing is for the mesh to follow the object around 09:26:42 https://svgwg.org/svg2-draft/pservers.html#PatternElementPatternUnitsAttribute 09:26:55 heycam: you can just use a transform="" on the shape for that 09:27:42 Rossen: why would you want the mesh not to follow the object? 09:29:35 s/Rossen/Bogdan/ 09:30:12 [discussion of paint server vs using mesh gradients themselves for rendering] 09:31:01 Rossen: when used as a paint server, you would expect to be able to map the gradient to the bounding box I think 09:31:33 Tav: OK, I will make path segments be interpreted as 0..1 bounding box values when objectBoundingBox is used 09:32:02 Rossen: what is better for mesh toolability? 09:32:07 Tav: don't think it makes much difference 09:32:40 Rossen: when the mesh is declared on its own, you still want to provide some editing experience for this 09:32:45 Tav: it'd be the same 09:32:56 ... you wouldn't put in a defs, though 09:33:03 ... right now in Inkscape it only works as a paint server 09:33:50 ... you can draw a mesh 09:34:07 ... but you can also start with a shape that you'll fill, and it can provide a mesh that fits the shape nicely 09:34:15 ... e.g. a conic shaped gradient for filling a circle 09:35:34 ACTION: Tav to make objectBoundingBox on meshes cause the path syntax to be interpreted as 0..1 bounding box values 09:35:34 Created ACTION-3795 - Make objectboundingbox on meshes cause the path syntax to be interpreted as 0..1 bounding box values [on Tavmjong Bah - due 2015-06-16]. 09:35:58 BogdanBrinza: next chapter, Paths 09:36:13 ... most of the open issues are Catmull-Rom, which are already being moved out 09:36:23 Rossen: I think we discussed all of these 09:38:16 ed: issue 12, the SVGPathSeg one, the minutes link talks about dropping the path seg interfaces 09:38:18 https://www.chromestatus.com/metrics/feature/timeline/popularity/568 09:38:18 http://www.w3.org/2015/02/11-svg-minutes.html#item10 09:38:45 ed: in the spec I dropped two of the synchronized lists -- normalized path seg lists, as they weren't implemented everywhere 09:39:04 ... the rest of them, they are used, but it's not very high 09:40:19 https://svgwg.org/svg2-draft/paths.html#issue12 09:40:22 ... if we're adding new path segment types, we need to resolve on this 09:40:43 ed: I'd like to see a better path api, and I did suggest one of those to www-svg 09:40:49 ... I don't think we resolved on anything there 09:41:01 ... but a more lightweight interface 09:41:32 https://lists.w3.org/Archives/Public/www-svg/2015Feb/0026.html 09:42:39 ed: definitely some resistance to just dropping it 09:42:44 https://lists.w3.org/Archives/Public/www-svg/2015Feb/0036.html 09:43:06 nikos: a lot of people in the thread weren't aware of the feature but said they would've used it if they did know 09:43:14 ed: in that mail I suggested a new simpler interface 09:43:41 ... I don't want two APIs 09:43:49 Rossen: if we have a chance to kill it, now is the time 09:44:16 ed: this API could exist in parallel to the existing one 09:44:24 ... so if an implementation wants to keep the old way for a time, it doesn't clash 09:44:38 BogdanBrinza: why would you want to keep the old one? 09:44:40 ed: compat reasons? 09:44:45 BogdanBrinza: there's no evidence that is a problem 09:45:01 ... even people interested in the topic have used these APIs 09:46:25 heycam: I agree with one commenter that we don't want to make people parse d attributes 09:46:58 ... we could add a new API like this in the separate Paths module 09:48:35 ed: so how about we drop the path apis from SVG 2, add this new proposal to the Paths module 09:48:40 Rossen: sounds good to me 09:50:49 ACTION: Erik to remove the SVG path list interfaces, and move the new proposed API to the Path module 09:50:50 Created ACTION-3796 - Remove the svg path list interfaces, and move the new proposed api to the path module [on Erik Dahlström - due 2015-06-16]. 09:51:14 BogdanBrinza: next chapter, Basic Shapes, Rossen 09:51:18 Rossen: it's basically done 09:54:20 BogdanBrinza: next chapter, Text, on Tav 09:54:24 Tav: this chapter needs some work 09:54:40 ... it's mostly straightforward, I'll sit down with Cameron for a few hours 09:55:15 Rossen: so there are 8 issues marked as needing discussion 09:55:18 ... is that the current state? 09:55:22 Tav: we've discussed some of these already 09:57:34 ... for baseline-shift, Inkscape uses this for super/subscript 10:01:49 Tav: for issue 34 not sure what that's about 10:02:03 heycam: I think it's describing how to apply x/y after CSS text layout, which is essential to have described in here 10:02:32 -svgwg 10:02:33 Team_(svg)09:00Z has ended 10:02:33 Attendees were [IPcaller], svgwg 10:04:12 https://svgwg.org/svg2-draft/text.html#issue38 10:06:19 Tavmjong has joined #svg 10:10:39 heycam: for issue 36, text-overflow:clip, I don't think we need to discuss it in the spec really 10:10:43 ... but I want to review the chaper first 10:11:11 Tav: issue 40 is about exposing the entire text when text-overflow applies 10:11:25 BogdanBrinza has joined #svg 10:11:39 Rossen: we've discussed things like ellipses etc. in CSS -- implied text -- in the ideal case, the ellipses would be a pseudo element you can style/address 10:11:46 ... hover, interact, etc. 10:12:02 ... so if this is the path forward, then my assumption is that all of the presentation level will be handled by CSS 10:12:08 ... so then there'd be nothing to do here in SVG 10:12:24 ... also, I would hate to be in a state where CSS would go defining something different, and then SVG has yet something different 10:12:59 ... so in the short term, one way to specify this would be to say that on hover, a tooltip will be used for displaying the text that is the additional text 10:13:08 ... again, we have to be careful because tooltips have limits 10:14:26 heycam: I'm reluctant to say SVG should have tooltips here, if not in HTML text-overflow:ellipsis 10:17:04 Rossen: this is a general thing that would apply to HTML as well, and I don't think this has come up in HTML/CSS contexts so far 10:20:35 nikos: I think text-overflow is for a visually pleasant rendering in constrained space 10:21:19 ... but I'm not sure if an automatic display of overflow text is going to be useful. it's going to be very case-by-case whether it's useful to show it in a particular way. 10:27:32 Rossen: you can have :hover rule to change it to overflow:visible 10:27:51 Tav: and if you want to hover just over the ellipsis? 10:28:01 Rossen: that's why the CSS WG wants to make the ellipsis into a pseudo 10:28:13 ... but for overflow:clip, you don't have the same solution, there's no pseudo element there 10:28:35 ... in the HTML case, when you have text which is overflowing based on layout, and clipped based on layout, then changing from clip to non-clip is tricky 10:28:48 ... you're not working with one element, but different text ranges, and they're dynamically changing 10:29:21 ... but if you want to create this visual effect of showing the text on hover, and then hiding it again, you can do that by setting the containg element, a div in HTML, do div:hover { overflow: visible; } 10:31:34 Rossen: we can bring back an issue to the CSS WG, but with the existing properties, what is it that you cannot do on :hover, so that you need a new mechanism? 10:31:44 [Rossen draws on board] 10:34:08 Rossen: so I think we can drop the issue 10:39:08 -- lunch -- 12:23:31 Bogdan: next chapter is Embedded Content, Bogdan 12:25:18 krit: first let's talk about one more issue in Geometry 12:25:30 ... the shouldn't be in the property definitions for x, y, etc. 12:25:37 heycam: I added that, but you're right it shouldn't be there 12:25:49 ACTION: Dirk to remove from geometry properties 12:25:50 Created ACTION-3797 - Remove from geometry properties [on Dirk Schulze - due 2015-06-16]. 12:26:15 BogdanBrinza has joined #svg 12:26:49 krit: I think the Coordinates chapter is very confused about canvas, viewport, etc. 12:26:59 ... rewriting the whole chapter would be ideal, but would be a lot of work 12:27:39 ... I'll look into it 12:28:02 ... there are some parts that can be removed, e.g. how CTM works, since it's in the Transforms spec 12:28:31 ... if there are deficiencies in the Transforms spec, then we should fix it there, and reference it 12:28:33 stakagi has joined #svg 12:29:00 krit: embedded content then 12:32:16 heycam: last time we discussed this we decided to allow HTML namespaced elements in the SVG document 12:32:23 ... and avoid duplicating the elements in SVG 12:33:54 krit: I think there's a problem, a request for users to support this, but not much implementation appetite 12:34:39 Rossen: why can't these people just use foreignObject? 12:34:52 ... I'm expecting foreignObject support to pick up speed 12:35:08 ... my point is that it's a well defined way to go between boundaries of HTML and SVG 12:35:19 ... why should we make exceptions for some elements to get around this? 12:35:47 BogdanBrinza: looking at foreignObject use counters on blink it's picking up in usage 12:36:51 Rossen: the only thing you get is not needing to write foreignObject 12:37:54 I would like to use embedded content's documentElement etc. 12:38:29 heycam: you do have to set the positioning of the child of the foreignObject 12:39:01 stakagi, that should still be possible, with