20:28:38 <RRSAgent> RRSAgent has joined #svg
20:28:38 <RRSAgent> logging to http://www.w3.org/2013/08/08-svg-irc
20:28:40 <trackbot> RRSAgent, make logs public
20:28:40 <Zakim> Zakim has joined #svg
20:28:42 <trackbot> Zakim, this will be GA_SVGWG
20:28:42 <Zakim> ok, trackbot; I see GA_SVGWG(SVG1)4:30PM scheduled to start in 2 minutes
20:28:43 <trackbot> Meeting: SVG Working Group Teleconference
20:28:43 <trackbot> Date: 08 August 2013
20:31:02 <Zakim> GA_SVGWG(SVG1)4:30PM has now started
20:31:09 <Zakim> +[IPcaller]
20:31:12 <heycam> Zakim, [ is me
20:31:12 <Zakim> +heycam; got it
20:31:32 <Zakim> +Doug_Schepers
20:31:42 <ThomasSmailus> ThomasSmailus has joined #svg
20:31:53 <Zakim> +krit
20:32:16 <birtles> birtles has joined #svg
20:32:23 <Zakim> +??P7
20:32:32 <Zakim> + +1.425.373.aaaa
20:32:40 <TabAtkins> I'll be following along in IRC.
20:32:55 <Tav> zakim, ??P7 is me
20:32:55 <Zakim> +Tav; got it
20:33:25 <Zakim> +[IPcaller]
20:33:33 <birtles> Zakim: [IP is me
20:35:38 <birtles> Zakim, +[IP is me
20:35:38 <Zakim> sorry, birtles, I do not recognize a party named '+[IP'
20:35:43 <birtles> Zakim, [IP is me
20:35:43 <Zakim> +birtles; got it
20:35:50 <krit1> zakim, who is on the phone?
20:35:50 <Zakim> On the phone I see heycam, Doug_Schepers, krit, Tav, +1.425.373.aaaa, birtles
20:38:23 <heycam> Zakim, pick a victim
20:38:23 <Zakim> Not knowing who is chairing or who scribed recently, I propose birtles
20:39:14 <heycam> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2013JulSep/0040.html
20:39:16 <heycam> Chair: Cameron
20:39:34 <birtles> krit: I also added CSSMatrix item
20:40:11 <heycam> ScribeNick: birtles
20:40:23 <birtles> Topic: review of css-cascade-3
20:40:51 <birtles> heycam: this spec defines how the cascade works and values that can be defined to every property
20:41:14 <birtles> ... initial default etc. and also scoped styles etc.
20:41:22 <Zakim> +nikos
20:41:26 <birtles> ... it probably doesn't affect us a lot so probably not a lot of work
20:41:32 <birtles> ... anyone interested apart from me?
20:41:58 <TabAtkins> Nah, it should affect SVG only insofar as SVG uses CSS, and even then it's almost completely just a proper rewrite and clarification of what was already stated.
20:42:02 <birtles> ... it defines which rules win for each property etc.
20:42:22 <TabAtkins> Only real addition is the "unset" value, and clarification of how scoped styles and some newer things like transitions/animations interact with other origins.
20:42:32 <birtles> krit: we need the functionality from that spec
20:42:50 <birtles> heycam: yes, but it's unlikely they are speccing anything we will disagree with
20:43:04 <birtles> krit: I'll read over it
20:43:57 <birtles> ACTION: Dirk to review CSS3 Cascade by August 26
20:43:57 <trackbot> Created ACTION-3516 - Review CSS3 Cascade by August 26 [on Dirk Schulze - due 2013-08-15].
20:44:34 <Tav> http://tavmjong.free.fr/SVG/publish/text.html
20:44:39 <birtles> topic: rewriting Text chapter in SVG2
20:44:53 <birtles> Tav: I've made a start on rewriting this
20:45:00 <birtles> ... the goal is to move towards more CSS-framed layout
20:45:21 <birtles> ... I'm looking for some basic feedback as to if the direction I've been taking is something the group agrees with
20:45:28 <birtles> ... basically, the first step is to layout text using CSS
20:45:38 <birtles> ... then after that you apply SVG transformations like dx, dy etc.
20:45:56 <birtles> ... in order to layout CSS text you need a content area
20:46:00 <birtles> ... there are different ways
20:46:10 <birtles> ... if you don't specify a content area you get a rectangle with a width and height
20:46:29 <birtles> ... if you do specify a content area you get specify a rectangle with width and height or a shape inside or outside
20:46:36 <birtles> ... and then you apply CSS layout
20:46:41 <birtles> ... after that you apply SVG rules if any
20:46:57 <birtles> ... if you look at the reorganization of that chapter the most important sections are the text layout sections
20:47:35 <birtles> ... content area, direction, positioning
20:47:56 <birtles> ... then the SVG-specific rules: pre-formatted text, auto-wrapped text, text on a path
20:48:19 <birtles> ... I've reworked the introductions to each of those sections
20:48:27 <birtles> ... I've had trouble determining which CSS specs to reference
20:48:36 <birtles> ... there are a bunch of specs at different stages of development
20:48:53 <birtles> ... and there are various inconsistencies between the CSS specs and SVG 1.1 that need to put address
20:49:03 <birtles> ... I've put issues throughout the spec to mark those
20:49:05 <birtles> ... any comments?
20:49:30 <birtles> heycam: when do you think we should incorporate this into the main spec?
20:49:36 <birtles> ... do you want to resolve the issues first?
20:49:46 <birtles> Tav: I think the sooner we merge the better
20:50:00 <birtles> ... but I'd like to get some review of it first because it is a drastic change
20:50:06 <birtles> ... although the end result shouldn't change
20:50:17 <birtles> ... but the structure of the chapter has changed
20:50:43 <birtles> heycam: I'll have to set aside time for a proper review to give detailed feedback
20:50:48 <birtles> ... but in general I'm in favour of this work
20:50:59 <birtles> ... I had one question about wrapping with shape-inside
20:51:27 <birtles> ... in CSS you have your box you would normally put text in and then with shape-inside you'd put that inside the box
20:51:43 <birtles> Tav: one of the difficulties is the coordinate system is different
20:51:50 <birtles> ... we don't have the box, we have the viewbox and user coordinates
20:52:03 <birtles> ... CSS defines it relative to a float but SVG doesn't have floats
20:52:23 <birtles> ... at an implementation level you can just say you have a float the size of the content area
20:52:38 <TabAtkins> Yeah, that's not a big deal.
20:53:23 <birtles> Tav: in CSS you have a box to begin with, so your shape inside, what you wrap text into, the units are based on that box
20:53:32 <birtles> ... we only have a viewbox and user units
20:53:43 <birtles> ... if you have an exclusion it's defined using a shape inside
20:53:49 <birtles> ... and in CSS/HTML that is defined using a float
20:54:07 <birtles> ... and that float determines the units you will use for adjusting... essentially you're changing the shape of the float
20:54:11 <birtles> ... but SVG doesn't have floats
20:54:25 <birtles> ... so instead we need to the use the viewbox and user units to define the shape of the exclusion region
20:54:42 <birtles> heycam: does that mean you'd be required to put the width/height attributes on the text element?
20:55:00 <birtles> Tav: no, because you're not using the <text> to determine the exclusion
20:55:50 <birtles> ... there's a complete example:
20:55:51 <birtles> http://tavmjong.free.fr/SVG/publish/text.html#TextShapeInside
20:55:55 <Tav> http://tavmjong.free.fr/SVG/publish/text.html#TextShapeOutside
20:56:18 <birtles> Tav: so you see there are two rectangles and two text elements
20:56:36 <birtles> ... the first text element uses the first rectangle as a shape inside and the second rectangle as a shape outside
20:56:44 <birtles> ... it also shows the shape-padding and shape-margin
20:56:56 <birtles> ... the blue area is the resulting wrapping area
20:57:09 <birtles> ... does that make sense?
20:57:22 <birtles> heycam: so the default shape-outside is the shape-inside
20:57:35 <birtles> ... and then if you specify the shape-outside you're intersecting a rectangle with that?
20:57:47 <birtles> Tav: the default shape-outside is nothing because you're excluding something
20:57:56 <birtles> heycam: but the default area you're excluding from is what?
20:58:01 <birtles> Tav: the shape-inside
20:58:07 <birtles> ... the shape-inside defines the content area
20:58:20 <birtles> ... then you can exclude part of that using shape-outside
20:58:34 <birtles> shepazu: how does this apply to floats?
20:58:41 <birtles> Tav: it doesn't apply to floats in SVG
20:58:53 <birtles> ... in CSS/HTML it is defined using floats
21:02:36 <birtles> heycam: perhaps we could ask people to review it by a certain date and then look at merging it?
21:02:40 <birtles> Tav: ok
21:03:02 <birtles> shepazu: is this compatible with the current regions/exclusions stuff in CSS? or is this somehow different?
21:03:21 <birtles> Tav: it is compatible with shapes except Shapes Level 1 doesn't have SVG paths in it (that will be in Level 2)
21:03:42 <birtles> ... and shape-inside is not in level 1
21:03:54 <birtles> ... but it was agreed in Japan that it will go into level 2
21:04:10 <birtles> ... and the author is supposed to be preparing a draft of level 2
21:04:23 <birtles> shepazu: I see you included text auto-wrapping
21:04:32 <birtles> Tav: yes, we agreed to that
21:05:03 <birtles> ... the one issue there is whether you want to define a rectangle using both width and height
21:05:54 <birtles> heycam: so if we had 2~3 weeks to review, would that be alright?
21:05:56 <birtles> Tav: yes
21:06:28 <birtles> heycam: so how about we revisit it in the Sept 5 telcon
21:08:44 <birtles> shepazu: I think we need to review the definition of the width/height attributes on text element
21:09:22 <birtles> heycam: yes, I think CSS/HTML does something different here so I think we should look at it
21:09:58 <birtles> shepazu: do you specify what happens when text overwraps its container?
21:10:06 <birtles> Tav: yes, that's specified towards the bottom
21:10:23 <birtles> heycam: it falls off the edge of the page
21:10:45 <birtles> topic: Ideas for opting in to an improved SVG DOM
21:11:11 <shepazu> +1
21:11:15 <shepazu> q+
21:11:28 <birtles> heycam: a couple of weeks ago I thought about how we could radically change the SVG DOM
21:11:28 <TabAtkins> Also +1.
21:11:49 <birtles> ... it came about partly when trying to write up the new marker properties
21:12:00 <birtles> ... where we were trying not to add new integer constants to the IDL
21:12:04 <TabAtkins> Note: Per spec at least, createElement() *always* puts the element in the HTML namespace.  There's no need to say that SVG elements with no namespace have this behavior as well.
21:12:17 <TabAtkins> Just dump all the SVG elements into HTML and let that be the switch.
21:12:27 <heycam> http://people.mozilla.org/~cmccormack/improving-svg-dom
21:12:32 <birtles> ... I thought about the discussion we had about having a big switch which would let us change to an improved SVG DOM
21:12:42 <heycam> http://dev.w3.org/SVG/proposals/improving-svg-dom/
21:12:47 <heycam> (that link)
21:13:11 <birtles> heycam: I only sent it to the list yesterday so I just wanted to bring it up and briefly summarise it
21:13:35 <birtles> ... the basic idea is that to get the new interface on the DOM nodes you'd create the SVG nodes in the HTML namespace / no namespace
21:13:40 <birtles> ... that's the big switch
21:14:03 <birtles> ... it's critical that something about the creation of the element is what determines what interface is available
21:14:22 <TabAtkins> I just wrote up a blog post with my initial reactions, too: http://www.xanthir.com/b4RR0 ^_^
21:14:23 <birtles> ... and attribute on the other hand happens after the element is created and it would be difficult to switch interfaces on the fly
21:14:42 <birtles> ... the second point is how to make sure that works well with parsing in the HTML parser
21:15:54 <birtles> ... the existing behaviour of the parser--I would be worried that we can't change what currently parsed SVG in HTML is doing
21:15:56 <krit> TabAtkins: great! We can stop the discussion immediately: "I'm going to make sure that SVG and CSS evolve together"
21:16:26 <birtles> ... so I don't think we can just say that all <svg> in <html> get parsed in the HTML namespace
21:16:27 <TabAtkins> krit: I have no idea whether you're being sarcastic or not.  Regardless, it's not appreciated.
21:16:46 <krit> TabAtkins: I have no problem with that
21:16:50 <birtles> ... because then all existing content would end up in that category without the author opting into it
21:17:17 <birtles> shepazu: so why is that important?
21:18:03 <TabAtkins> If anyone's currently scripting at <svg>-in-HTML, they'll break if we just switch them over.
21:18:07 <birtles> ... perhaps I didn't get the nuance of the proposal, but I didn't see anything you proposed that people would likely to be relying on
21:18:20 <TabAtkins> And without something like a new root element, we can't switch over standalone <svg>.
21:18:22 <birtles> ... how often to people actually test interface names
21:18:36 <birtles> heycam: not so much, but they depend on the APIs themselves
21:19:03 <birtles> shepazu: this is a fairly radical proposal, specifically the <graphics> element
21:19:05 <TabAtkins> Yeah, these proposals are both additive *and* subtractive, so scripts expecting SVG1 stuff will break.
21:19:05 <krit> TabAtkins: we discussed allowing SVG elements in HTML directly and may change to SVG 1.1 mode if you use an <svg> root-element
21:19:21 <TabAtkins> krit: I know.
21:19:32 <birtles> ... there's going to have to be fallback for older content and older browsers
21:19:50 <birtles> heycam: yes I think that's the biggest problem with introducing a new root element (fallback for older browsers)
21:20:31 <birtles> shepazu: that's not a deal-breaker but we need to do an analysis to work out the cost given that it will take a long time for this to deploy
21:20:40 <krit> TabAtkins: I meant to switch from SVG.next to SVG1.1 you just use the <svg> element, and no root element at all if you don't want to (not even <graphics>)
21:21:31 <birtles> shepazu: if you did createElement now, you are proposing the element does get put in the HTML namespace
21:21:38 <TabAtkins> krit: That doesn't help when you *do* need a viewport element.  It also does nothing for the standalone case - svg-in-html is not an image.
21:21:42 <birtles> heycam: that's how it already works
21:21:49 <birtles> shepazu: so let's just dump the SVG namespace at all
21:21:53 <TabAtkins> Yeah, right now it'll just have the HTMLUnknownElement interface.
21:22:00 <TabAtkins> But it'll be an <html:svg> element.
21:22:02 <krit> TabAtkins: that is correct
21:22:28 <Zakim> -Tav
21:22:31 <birtles> shepazu: if we are going to change it radically, I don't think we should persist in having an SVG namespace
21:22:42 <TabAtkins> shepazu: How are you going to deal with legacy content?
21:23:14 <Zakim> +??P0
21:23:22 <krit> TabAtkins: he actually rasied this concern
21:23:31 <krit> TabAtkins: brian can't catch up :)
21:23:35 <TabAtkins> krit: Hah, kk.
21:23:44 <TabAtkins> krit: The perils of having a dead phone and a broken charger.
21:24:34 <krit> TabAtkins: :)
21:24:40 <birtles> shepazu: if someone created something in the SVG namespace explicitly, and we put in the HTML namespace for forwards compatibility reasons
21:25:35 <TabAtkins> That would break legacy code that expects elements it creates to be in the SVG namespace, and to have the SVG1 DOM.
21:26:02 <birtles> ... we should see what at what points a script is likely to break if we adopted Cameron's proposal from an interface perspective
21:26:14 <birtles> ... Cameron seems to be trying to prevent breakage by introducing a new root element
21:26:26 <birtles> ... and we have to see how disruptive that would be compared to simply introducing the new API
21:27:03 <TabAtkins> Lots of things would break, quickly.  Anything trying to get .baseVal, for example, since it's missing from the new DOM.
21:28:20 <birtles> krit: if we put SVG elements in HTML namespace and vice versa, it wouldn't matter which namespace they were in
21:28:27 <birtles> ... it wouldn't matter how you created them
21:28:41 <birtles> heycam: every element gets created in a given namespace
21:28:59 <birtles> ... every node will be in one namespace
21:29:32 <birtles> birtles: shepazu are you saying we could add Cameron's proposal in parallel to the existing interfaces?
21:29:53 <birtles> shepazu: I don't have a specific proposal, but I'm wondering how many scripts would break...
21:30:37 <birtles> krit: I don't think anything would break if we switched on namespace
21:30:50 <birtles> shepazu: I don't like the idea of having two different namespaces for SVG
21:31:02 <birtles> ... you're saying we'd have two different namespaces for SVG
21:32:03 <TabAtkins> No, we'd have the SVG1 namespace, for SVG1.  Then SVG2 would just be a part of Greater HTMListan.
21:32:38 <birtles> krit: now you have to specify the namespace if you want to create an SVG element
21:32:47 <birtles> ... if you don't do that it ends up as HTMLUnknownElement
21:33:38 <birtles> ... so new scripts could use the new interface...
21:34:21 <birtles> shepazu: I think it complicates implementations if we have to support both
21:34:35 <birtles> heycam: I think the proposal complicates it for implementations since they have to support both
21:34:47 <TabAtkins> We have to support both anyway.  You're just proposing we support both, merged into the same interfaces.
21:34:50 <birtles> shepazu: I think that's madness
21:34:57 <birtles> heycam: I think it's the maximally compatible thing to do
21:35:44 <birtles> shepazu: I'm trying to think of scripts that I've been writing where I've been trying to find the SVG root in an HTML document
21:35:57 <birtles> ... I just walk up until I find a different namespace
21:36:13 <birtles> ... when it comes down to it, what are we trying to preserve?
21:36:31 <birtles> ... the more complex the content is more likely to not work in browsers anyway
21:37:08 <birtles> heycam: It's not that I'm worried about, it's using the actual interfaces
21:37:52 <birtles> shepazu: so you're suggesting we use namespaces to switch interfaces but require browsers to support the old interfaces
21:38:38 <birtles> ... instead of having an implicit switch we just alias the new behaviour
21:39:01 <birtles> ... why do we need the extra step of opting into the new interface
21:39:13 <TabAtkins> Browsers only support the old interfaces on the old elements, for legacy compat reasons.
21:39:14 <birtles> heycam: so you're proposing we support the union of the two interfaces on the same element
21:39:28 <birtles> ... we tried to do that but we reached limits
21:39:52 <birtles> ... because we can't change, for example, rect.x to something more sensible because it's defined to return SVGAnimatedLength
21:40:22 <TabAtkins> Yeah, too many things are broken in ways that would require actually changing names, which breaks the language much more thoroughly (and ruins hopes of compat with HTML in things like <a>.href)
21:40:36 <birtles> shepazu: if we change that, how much will it break?
21:40:41 <birtles> birtles: I think it will break a lot
21:40:54 <TabAtkins> It will break literally *anything* that actually uses that attribute.
21:41:18 <birtles> shepazu: I think we need to analyze what will break and determine if we really need a switch, but I don't like the new root element
21:41:24 <TabAtkins> zcorpan over in #whatwg asks if we know usage numbers for the current DOM.  If they're low enough, can we just drop the old stuff straight up?
21:41:35 <TabAtkins> shepazu: We've already looked it through. >_<
21:41:37 <birtles> ... if it's just to do with the dom then maybe it's a new keyword
21:41:39 <krit> TabAtkins: shepazu doesn't read your comments :( Can't you call in?
21:41:45 <TabAtkins> No, I can't.
21:42:28 <birtles> shepazu: I think the distinction based on root element / namespace is going to be difficult for someone new to web development / svg
21:42:59 <TabAtkins> There's no distinction.  There's SVG, which has a <graphics> root and is part of Greater HTML, and then there's some weird legacy stuff you see occasionally.
21:43:26 <birtles> heycam: well this is a start to get people thinking about new SVG DOM ideas
21:43:38 <birtles> ... feel free to send more thoughts to the mailing list
21:44:20 <birtles> krit: please points from this discussion as issues to the proposal
21:44:28 <Zakim> -Doug_Schepers
21:44:28 <birtles> s/please points/please add points/
21:44:30 <Zakim> - +1.425.373.aaaa
21:44:31 <Zakim> -heycam
21:44:33 <Zakim> -nikos
21:44:44 <Zakim> -krit
21:44:46 <Zakim> -??P0
21:45:08 <nikos> RRSAgent, make minutes
21:45:08 <RRSAgent> I have made the request to generate http://www.w3.org/2013/08/08-svg-minutes.html nikos
21:48:44 <shepazu> TabAtkins, I find it pretty disruptive to have IRC conversations with people who aren't on the call interleaved with the minutes of the telcon participants, not least because you can't hear what we're really saying, in real time… so, if you want to join in these conversations, please join the call, or send your comments via email
21:49:16 <TabAtkins> Too bad? I can't always join, and part of the reason we live-minute into IRC is to *enable* this kind of thing.
21:49:26 <shepazu> TabAtkins, you're a member of the SVG WG, and if you're putting yourself into the critical path on dcisions, please join the telcons
21:49:46 <Zakim> disconnecting the lone participant, birtles, in GA_SVGWG(SVG1)4:30PM
21:49:47 <Zakim> GA_SVGWG(SVG1)4:30PM has ended
21:49:47 <Zakim> Attendees were [IPcaller], heycam, Doug_Schepers, krit, +1.425.373.aaaa, Tav, birtles, nikos
21:49:52 <krit> TabAtkins: does moving the call help you to attend?
21:49:56 <TabAtkins> We're not allowed to make telcon attendance a requirement to be involved in decisions.
21:50:14 <shepazu> says who?
21:50:17 <TabAtkins> No, the problem today was that my phone was dead and I don't have a headset to set up my laptop.
21:50:35 <TabAtkins> shepazu: I thought that was a W3C thing?  After all, telcons are excluding.
21:50:36 <krit> TabAtkins: ok
21:50:53 <shepazu> TabAtkins, no, that's not a w3c thing
21:51:18 <TabAtkins> Saying that I must attend the telcon via phone in order to interact with decisions means I'm SOL if I'm in a bad timezone, or I'm deaf, or a number of other things.
21:51:22 <shepazu> TabAtkins, but I'm not talking about decisions, I'm talking about discussions… decisions can always be revisited based on new info
21:51:50 <shepazu> TabAtkins, no, if you had those constraints, we'd help you work around them
21:52:36 <TabAtkins> I'm sorry it makes you uncomfortable having to catch my comments in IRC.  You're free to ignore them if that's too annoying for you, and read them afterwards.
21:52:46 <shepazu> you're not in a bad timezone for this call, you're not deaf, and I suspect google pays you enough to afford teh equipment and service to attend
21:52:54 <TabAtkins> That's basically the same as me holding all my comments until after the call anyway.
21:53:15 <shepazu> TabAtkins, no, I want your comments, because I want your insight
21:53:28 <TabAtkins> I'm not willing to have a conversation in which I justify my decision to follow the call via live-minuted IRC, when this works just fine elsewhere.
21:54:16 <shepazu> TabAtkins, you don't understand
21:55:40 <shepazu> your comments in IRC are disruptive because you aren't involved in the real conversation, so we end up duplicating explanations, catching you up to things that were said asnynchoronously to your reading of the minutes, etc
21:55:57 <shepazu> it's profoundly inefficient
21:56:28 <TabAtkins> No, you can just leave it alone, so I catch the minutes as they come around in a minute or so.
21:56:32 <shepazu> IRC conversations are fine, when all the participants are just doing IRC… but mixing IRC and telcons is oil and water
21:57:06 <shepazu> it's also confusin to people who read the minutes afterward, and try to make sense of them
21:57:09 <krit> shepazu: of course it would be great if everyone would call in. But Tab had an excuse why it didn't work for him. And of course IRC is a legitimated medium to participate.
21:57:14 <TabAtkins> I have experience with mixed conversations in many CSS meetings, and it works fine there.  SVG isn't special.  It's not *ideal*, but neither is it so disruptive as to provoke an attempted banning.
21:57:25 <krit> shepazu: in general I still agree it would be great if people call in
21:58:51 <shepazu> TabAtkins, I didn't attempt to ban you! I asked you to join the conversation! those are radically different things
21:59:16 <TabAtkins> You told me that my interaction in the call today was disruptive.  That's close enough for me. ^_^
21:59:45 <shepazu> TabAtkins, it was disruptive. that's just a fact
22:00:04 <shepazu> I'm sorry if you don't like that it was disruptive
22:00:39 <TabAtkins> I'm sorry you feel that SVGWG meetings are somehow special enough to not tolerate this kind of interaction, when I've successfully been on both ends of this many times in the past.
22:02:26 <shepazu> s/I'm sorry if you don't like that it was disruptive/I'm surprised you don't realize that it was disruptive/
22:02:35 <TabAtkins> Done here, thanks.
22:02:48 <shepazu> that was a bit passive-aggressive for me to say in the first place
23:02:44 <birtles> birtles has joined #svg
23:40:53 <Tav> Tav has joined #svg