06:48:35 RRSAgent has joined #svg 06:48:35 logging to http://www.w3.org/2012/05/07-svg-irc 06:50:49 Zakim has joined #svg 06:52:04 Zakim, code? 06:52:04 sorry, heycam, I don't know what conference this is 06:56:20 nikos has joined #svg 06:57:55 Cyril has joined #svg 06:58:19 hi Cyril 06:58:25 hi Erik 06:58:28 g'day Cyril 06:58:31 dialing in today? 06:58:31 hi all 06:58:42 if possible? 06:59:16 we are still waiting on a couple of people, so let's aim to start in 15 minutes 06:59:22 I'll set up a bridge then 07:01:50 cabanier has joined #svg 07:01:57 or if one of you has Skype 07:02:26 there is a microphone system in the room here, not sure how easy it would be to hook skype up to it 07:02:50 then I'll call 07:03:04 I might have to call back every hour 07:04:53 Zakim, room for 5? 07:04:54 ok, heycam; conference Team_(svg)07:04Z scheduled with code 26631 (CONF1) for 60 minutes until 0804Z 07:04:57 Zakim, code? 07:04:57 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 07:05:28 what telcon is this? 07:05:34 oh! 07:05:41 are you starting the SVG f2f? 07:05:47 yes 07:06:15 Team_(svg)07:04Z has now started 07:06:23 + +33.1.75.06.aaaa 07:06:40 zakim, aaaa is me 07:06:40 +Cyril; got it 07:09:56 Tav has joined #svg 07:10:10 zakim, mute me 07:10:10 sorry, Cyril, muting is not permitted when only one person is present 07:10:12 Hi 07:13:17 yes 07:15:21 code? 07:15:26 Zakim, code? 07:15:26 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 07:16:28 + +49.403.063.68.aabb 07:17:11 +Tav 07:18:13 cabanier has joined #svg 07:18:22 vhardy_ has joined #svg 07:18:24 connect url: https://my.adobeconnect.com/_a295153/vhardy 07:19:31 jet has joined #svg 07:21:21 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Hamburg_2012/Agenda 07:23:05 yes 07:23:07 krit has joined #svg 07:27:20 tabatkins__ has joined #svg 07:29:01 ScribeNick: vhardy 07:29:08 Topic: SVG2 07:29:17 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Planning_Page 07:29:25 heycam: we are running behind on our schedule. 07:29:45 … we wanted to have subsections in the spec. for all the new things people had signed up for. 07:29:54 … I am guilty as well. But everybody is behind. 07:30:03 …. what can we do to make sure that we make progress? 07:30:14 tav: I have put 40% of them in. It takes time. 07:30:28 .. who is supposed to be responsible. The requirements, the link to the resolution. 07:30:41 heycam: a few of them are at the top of the chapter. 07:30:49 tav: some I can figure out. 07:31:04 heycam: I am getting the impression that people do not have a lot of time to allocate to spec. editing. 07:31:27 … this is the reason why I wanted to assign 1 or 2 people as primary editors of the spec. So that they can allocate more time. 07:31:33 … not just 1 or 2 features. 07:31:41 … we have not selected any people yet for that. 07:31:50 … anybody feels that they have the time to do that? 07:31:59 tab: I would love to, but cannot. 07:32:08 jet: who is there on the editor list now? 07:32:26 heycam: in the SVG 1.1 spec., we did not have a main editor. Everybody was pitching in. 07:32:42 … there was no primary editor. We need 1 or 2 main editors for this version. 07:32:48 tav: yes, it is very inconsistent. 07:33:10 heycam: tav you have already done a lot of work on the spec., can you become the main editor? 07:33:35 tav: I have asked Mozilla and Google for support, but this is not their current priority. 07:33:49 heycam: there is a lot of CSS high priority items. 07:34:50 +Doug_Schepers 07:35:20 ScribeNick: heycam 07:35:27 VH: this is close to my concern about the spec editing 07:35:32 … SVG 2 is large, rewriting it is a big effort 07:35:40 … especially if we have constraints on editorship, this is a question for the group 07:35:57 … should we focus on particular efforts that are critical? integration work, animation, etc.? 07:36:05 … we know there is a big issue on the web with animation, it's a big thing to sort out 07:36:13 … we know that better canvas integration in svg would improve things 07:36:23 … my question is shouldn't we focus on smaller specs 07:36:37 … even the web animation is going to be a large effort, but still much smaller than SVG2 as a whole 07:36:49 … since we have people motivated for these pieces, it's more likely we can pull it off 07:36:55 TA: modularisation like CSS 07:37:08 VH: we're still needing implementations to get up to speed with SVG 1.1 07:37:23 … we could have SVG DOM improvements as a separate spec 07:37:31 ED: some things would be easier to write up in modules than others 07:37:50 Dirk: paint servers could be split out 07:38:06 BB: I'm in favour of modularisation 07:38:15 ED: I think identifying small parts, standalone modules 07:38:23 VH: do we think the highest priority things can be done as modules? 07:38:43 heycam: we can have a look at the list of things we have signed up for and see what can be modularized. 07:38:52 … for example, SVG DOM improvements may be hard to split out. 07:38:58 … canvas integration can be easy to split out. 07:39:07 dirk: should we make a list now of what could be a module? 07:39:13 heycam: yes, we can do that list now. 07:39:23 … and we could get people to sign up as separate specs. 07:39:29 dirk: ok. 07:39:41 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments 07:40:11 heycam: let's look at the one for which someone signed up for. 07:40:22 z-index http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#z-index 07:40:28 could be good if the tick in the table had a link to the spec 07:40:36 dirk: that could be combined with something else. 07:40:46 heycam: this is fundamental, changes the painting model. 07:40:59 dirk: should it be in the new definition of the rendering model? 07:41:11 heycam: we could split out the rendering model in a separate spec. 07:41:20 q+ 07:41:35 .. I am concerned about splitting out because that was the plan for SVG Tiny where we were going to add modules on top of it. 07:41:44 … stitching specs together is going to be hard. 07:42:16 tab: what we have done in CSS, we have turned pieces of the core spec. into new modules of the spec. 07:42:33 brian: so you do not need a full SVG 2.0 spec. at all? 07:42:51 tab: yes, possibly. CSS 2.1 is still a reference for things that are not redefined in a module. 07:42:59 heycam: does that work well? 07:43:09 tav: yes, because we did not have to redo a lot of low level work. 07:43:24 … we still have to do things like the box model. 07:43:39 ScribeNick: vhardy 07:43:56 vhardy: I thnk that while not perfect, this is a pretty good option. 07:44:12 shepazu: I do not agree at all. It took CSS a decade to do that. 07:44:22 tav: it took a decade to get CSS 2.1 good. 07:44:48 shepazu: I think that trying to find the parts of SVG to split out and then doing their own spec is difficult. 07:45:00 … unless we see a plan to see which parts can be split out. 07:45:14 … we have already split out filters, transforms, etc… What is left is core functionality. 07:45:26 dirk: paint servers is something that could be done independent of SVG. 07:45:36 … it could be a module of its own. 07:45:54 ed: it was suggested as a module in the past. Andrew Emonds was supposed to take that module. 07:46:06 s/Emonds/Emmons/ 07:46:26 shepazu: the other thing is that we have individual people who might take on individual specs. All these things depend on one another. 07:46:42 … I do not think that we face the same problems as CSS faces. We do not have the same number of people. 07:47:00 tav: we can identify things that are independent and can be carved out as new modules. 07:47:16 shepazu: we already decided about what goes into SVG 2.0. 07:47:32 VH: I think it's clear it's hard to put together a big monolithic spec 07:47:37 … and we're behind schedule 07:47:56 … whereas I think the CSS experience shows when we have motivated editors for portions of the spec, it's more realistic to see those modules make progress 07:48:33 shepazu: I strongly disagree. We have made a lot of preparation work. I think we should just start on SVG 2.0 and get people to start doing the work. 07:49:02 tav: we do not need to do this top down. Let's pull off module as people have interest. No need to decide now for everything upfront. 07:49:07 dirk: how do we do that? 07:49:18 tav: we have a collection of things that are SVG. 07:49:22 s/tav/tab 07:49:35 if people don't have time to edit the current spec, I don't think they'll have time to edit modules 07:50:10 (discussion about how modules would be split out or not and what would constitute SVG 2.0) 07:50:47 tav: if the monolithic spec is not great yet, then the feature that is split out needs to be removed from the 'main' spec. 07:51:02 …. CSS modules just augment the CSS 2.1 spec. 07:51:10 …. we also collect errata for CSS 2.1 07:51:19 .. SVG 2.0 is not near that point. 07:51:31 … if someone wanted to pull a module out, we could do that. 07:51:42 q+ 07:51:43 … this could be decided piecemeal. 07:51:46 q- 07:52:00 cyril: I do not see how modules can help. 07:52:29 … there are already many chapters and they are quire independent. Looking at how annotations have been made, they are quite independent. Editing should be pretty straightfoward. 07:52:39 … I do not see how modules would help. 07:52:52 q- 07:52:54 heycam: what would make it easier to edit if things are independent specs. 07:52:56 q+ 07:53:01 brian: easier to find editors. 07:53:11 heycam: people own the separate features. 07:54:05 an editor of a module is the same as an editor of a part of the spec, no? 07:54:37 Cyril: Basically, yeah. It's just an organization/semantic thing. 07:56:20 heycam: originally, we wanted to do a lot of clean-up. I would still be happy if people just added their new features in the SVG 2 spec. and not needing to do clean-up of other things. The SVG 1.1 spec. is not terrible. I do not think we need to spend time doing clean up or rewriting to get new features in. I do not think this should be stopping us. 07:56:46 dirk: I think tab's proposal, we could increase our ability to split out modules as needed. 07:57:15 heycam: I am happy that if people want to have it in a separate spec., I am fine with it if the people doing the work want that. 07:57:23 dirk: can we agree that we want to use this model? 07:57:57 shepazu: do we need a new resolution on that? We have been doing this for years now. 07:58:24 … we should work on spec. and technical work. 07:58:27 +1 07:58:44 dirk: it seems that you just agreed to tab's proposal. 07:58:58 heycam: If people want to break things out, they can ask the group and we can agree to do that or not. 07:59:42 tav: we could annotate, along the way, what is solid and what is not, like in the HTML5 work. 07:59:46 heycam: that sounds right. 07:59:49 shepazu: yes 08:00:04 … and it should be backed up with tests. 08:00:16 … they'll ensure that we get interoperability. 08:00:30 … tests are needed before we can mark things as stable. 08:00:40 heycam: we do not need to go through the list at this point. 08:01:56 So if someone in the group who is working on the spec. and a particular feature wants to work on it as a separate module, they should bring that proposal to the group and ask for a separate module. Decisions will be made on a case by case basis. 08:02:26 heycam: there were mixed feelings whether we need somebody as a full editor of the spec. Perhaps we can consider that as another thing someone will sign up for? 08:02:58 … I think this mixes well with what Tab suggest to keep SVG 1.1 as the reference. We can keep the old text. 08:03:05 … as the reference. 08:03:23 dirk: don't we need a global editor to organize and keep the overall consistency? 08:03:28 shepazu: what would be the role? 08:03:52 heycam: coherence, bug fixing for things that do not fall into features, insuring the document as a whole is reasonnable. 08:05:20 vhardy: in the SVG 1.0 and 1.1 1rst edition, the editors did a tremendous amount of coherence checking etc.... 08:05:38 heycam: having to rewrite sections was an impediment to making progress. 08:05:46 … for SVG tiny. 08:06:22 shepazu: the spec. as it stands has holes and consistencies, we are continuing the inconsistencies. 08:06:35 heycam: I do not think it is completely terrible. 08:06:43 shepazu: I do not want to argue about this anymore. 08:06:54 heycam: realistically, nobody is going to put the time into this. 08:07:16 … we can just continue to aim at our milestone page and follow that plan. 08:08:04 tav: the list of requirements is not sorted. It is one long list. I'd like to sort it by chapter. 08:08:11 heycam: that would be fine. 08:08:23 cyril: the numbers would have to change. 08:08:30 tav: is that a problem? 08:08:38 heycam: I do not think people rely on those numbers. 08:08:46 … tav: go and do that if you want. 08:09:05 cyril: a long time ago, I sent an email with a sorting/categorization of the requirements. 08:09:22 heycam: would it be beenficial to do some work on the spec. during the F2F? 08:09:26 tav: yes, that would be good. 08:09:33 ed: +1 08:09:58 tav: requirements, resolution, etc… short summary and responsible person would help. 08:09:58 making sure everyone has the right environement for editing 08:10:19 tab: I am afraid some people will end up clocking out. 08:10:36 heycam: I think it might help getting people started if they have not done it yet. 08:10:41 agenda+ report on Web Components and 08:11:31 heycam: ok, we'll do that at the end of the day today. 08:11:41 (before 5:15pm) 08:12:04 heycam: we are done with the SVG 2.0 discussion then. 08:12:15 heycam: we can talk about the web components now. 08:12:45 Topic: Web Component 08:12:53 shepazu: it just happened last week. 08:13:08 … we have been talking for a while about the and the resulting shadow tree. 08:13:33 … pretty unpopular. We have been talking about using the Web component model that Dmitry Glaskov has been writing. 08:13:48 … at TPAC, when we talked, he was not sure how it would work with the element. 08:14:10 … the goal of having be an instanciation of the shadow DOM model would be easier. 08:14:27 … with SVG as it stands, it is more complicated and not very performant (as I understand it). 08:15:01 … at TPAC, he said that each instance of the component would be identical. There would be no way to style each instance. In the current element, you can inherit the fill color, for example. 08:15:07 … so there is some differnece. 08:15:22 … in his old model, that would not work. In the new model, it would work. 08:15:36 … you could have a separate styling for each instance of the component. 08:15:56 … so in other words, we can go ahead and use the component model to mimic the element. 08:16:07 dirk: that is what we do in WebKit now. 08:16:16 … was done in the last couple months. 08:16:27 tav: does that change anything, is it fully compatible? 08:16:37 dirk: the use element now works a lot better in WebKit/ 08:17:32 shepazu: there are some DOM methods for the element (like ElementInstance) that would need to be deprecated. 08:17:43 … not impelmented consistently. 08:17:52 … modern SVG content does not use that. 08:18:03 …. it was implemented in the ASV viewer. 08:18:30 tab: we would need to re-write the DOM. 08:19:09 shepazu: I will rewrite the section to describe the model in the shadow DOM model and rewrite the DOM model and/or deprecate APIs if/where needed. 08:19:16 -Tav 08:19:19 heycam: I have not looked at the shadow DOM for a while. 08:19:29 …. there are methods to get to the shadow tree? 08:19:35 tab: yes, the element.shadow. 08:19:42 heycam: is there event retargeting. 08:19:54 tab: it is a closer rewrite of the XBL2 event model. 08:20:53 The conference code has expired... can't call back in. 08:20:55 ACTION: shepazu to edit the section in terms of Shadow DOM model and rewrite the DOM model and deprecate / change APIs where needed. 08:20:56 Created ACTION-3271 - Edit the section in terms of Shadow DOM model and rewrite the DOM model and deprecate / change APIs where needed. [on Doug Schepers - due 2012-05-14]. 08:21:21 heycam: shepazu, can you explain how the style can be inherited from the element on the instance. 08:22:11 tab: I think this is a todo in the shadow DOM spec. to allow inheritance. 08:22:33 shepazu: the will be syntactic sugar for regular shadow tree. 08:23:42 (discussion about event retargeting, see the Shadow DOM proposal). 08:23:59 shepazu: there were only some classes of content that was doing this. I am not worried about breaking that content. 08:24:10 brian: would that be useful for markers as well? 08:24:40 shepazu: I think we could safely state that markers are instances and we could add functionality to markers. 08:24:59 heycam: we should be able to describe markers in terms of shadow tree. 08:26:29 vhardy: I think markers could be modeled with the shadow DOM, but they may have a memory footprint consequence. 08:26:41 heycam: implementations can be smart about it and lazily create the DOM. 08:27:34 vhardy: there was a discussion about shadow DOM and regions and memory was shown to be an issue. 08:27:48 shepazu: may be markers do not have to be modeled with the shadow DOM. 08:28:20 heycam: describing markers in terms of shadow tree may not be that useful. I have proposals for markers in the section about this in the afternoon. 08:28:42 shepazu: another problem with markers is simply that the ability to position them is very limited. 08:28:54 … I do not think it is a particularly good model. 08:29:02 heycam: I have proposals for that. 08:29:35 heycam: so the web component model will be good for the element. Anything else on this? 08:29:42 shepazu: done. 08:30:02 heycam: break for 15mn 08:30:16 -Doug_Schepers 08:31:25 Zakim, who is on the call? 08:31:25 On the phone I see Cyril, +49.403.063.68.aabb 08:32:00 - +49.403.063.68.aabb 08:33:27 -Cyril 08:33:29 Team_(svg)07:04Z has ended 08:33:29 Attendees were +33.1.75.06.aaaa, Cyril, +49.403.063.68.aabb, Tav, Doug_Schepers 08:58:52 Zakim, room for 5? 08:58:53 ok, heycam; conference Team_(svg)08:58Z scheduled with code 26631 (CONF1) for 60 minutes until 0958Z 08:59:43 Here's the Web Component Explainer, for easy explanation of several of the shadow dom concepts: http://dvcs.w3.org/hg/webcomponents/raw-file/tip/explainer/index.html 08:59:52 Explains the CSS and events interaction really easily. 08:59:55 Team_(svg)08:58Z has now started 09:00:01 +Tav 09:01:04 + +49.403.063.68.aaaa 09:01:53 ScribeNick: tabatkins__ 09:01:57 Topic: Painting order 09:01:59 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Paint_order 09:02:17 heycam: I wrote up a short proposal for something I wanted to do for a long time, which is change the order that fill/stroke get painted in for shapes. 09:02:32 heycam: Especially for text, you sometimes want the stroke *underneath* the text, rather than on top. 09:02:57 krit: How does this relate to Vector Effects? 09:03:15 jet has joined #svg 09:03:24 heycam: We originally thought to solve this with VE, but I don't want to have to wait for VE for this simple thing, and I don't want authors to have to write a big VE just for this simple effect. 09:03:44 heycam: Even if this is just a shorthand for VE stuff, I don't think the right effect is to jam it into the vector-effect property. 09:04:05 Zakim, who is on the call? 09:04:05 On the phone I see Tav, +49.403.063.68.aaaa 09:04:25 heycam: So I think it's better to have it as a separate property, and later define how it interacts with VE. 09:04:57 +Cyril 09:06:31 [somewhat confusing discussion about repeated use of keywords] 09:06:39 [resolved by explaining the syntax better] 09:07:15 birtles: How does this interact with stroke-inner/outer? 09:07:33 vhardy_: It adjust the shape of the stroke, not the painting order. 09:08:36 tabatkins__: One of heycam's usecases was a stroke outside of text by drawing the fill on top, which seems to be the same as just stroking outside. Are there other use-cases? 09:09:15 vhardy_: Ideally it would work the same for the text use-case, but seaming isn't good on this sort of thing in most applications. 09:10:12 birtles: fill-opacity makes a difference between the two cases, 09:10:51 tabatkins__: stroke-outside is what you want with partially-transparent fill. 09:11:13 vhardy_: I think that some rendering engines dont' do this well. 09:11:21 krit: You can just clip around the text. 09:11:30 vhardy_: Still potentially pixel-level rendering issues. 09:11:38 tabatkins__: So it's a QoI issue. 09:12:02 krit: So if we had good stroke-outside, is there still a good reason to have this? 09:12:19 ed: Moving markers around is still a useful effect, and can't be done otherwise. 09:12:41 heycam: It also lets you get the stroke-outside effect in opaque cases without us having to wait for stroke-outside. 09:13:19 krit: [discussion about offsetting strokes more powerfully with the proposals about stroke-outside/offset/whatever] 09:14:09 birtles: Is there a strong use-case besides the one that can be done with a stroke offset? 09:14:36 tabatkins__: Markers moving their painting order is still something else. 09:15:47 [discussion about spec path for stroke-offset, maybe just starting with inside/outside/middle, and later use more powerful stuff] 09:16:06 vhardy_: I'm in favor of this proposal. It's simple, and can be useful for authors. 09:16:23 ed: I'm not particularly happy with the name. 09:17:43 vhardy_: Yeah, 'paint-order' reminds me of z-order. 09:17:53 heycam: Naming suggestions welcome. 09:18:21 heycam: And if you don't specify all the keywords, presumably the rest get applied in the normal order, after the specified ones. 09:18:34 heycam: So if more layers show up in the future, it doesn't invalidate the existing content. 09:18:56 krit: What about controlling the order of clipping/masking/etc? 09:19:06 heycam: Not right now. That might be something to look at in the future. 09:19:18 heycam: It might be getting into the realm of something you want to write a whole VE definition for. 09:20:10 http://dev.w3.org/SVG/modules/vectoreffects/master/SVGVectorEffectsPrimer.html 09:21:01 birtles: I'd be happier if there was an explicit strong use-case, but I'm okay with the property. 09:21:52 vhardy__ has joined #svg 09:21:54 heycam: I think usually I've wanted something like this to make "stroke outside", but that's an incomplete solution. 09:22:03 krit: What about hit-testing? 09:22:49 ed: I think pointer-events defines how that should work, more or less. 09:23:37 vhardy: I think pointer-events is just about the geometry of the pieces. 09:23:41 http://www.w3.org/TR/SVG11/interact.html#PointerEventsProperty 09:23:47 vhardy: In which case the painting order doesn't matter. 09:23:48 https://developer.mozilla.org/en/CSS/pointer-events 09:24:55 heycam: If stroke is on top, and I say "pointer-events:fill", it still hit-tests on the part of the fill underneath the stroke. It's just geometry. 09:25:43 RESOLVED: Add heycam's "paint-order" proposal, though possibly with a different name. 09:27:25 http://www.w3.org/TR/SVG11/render.html#PaintingShapesAndText 09:28:40 tabatkins__: [mentioned that CSS now automatically includes the global keywords (inherit, initial, etc) in all properties, so it shouldn't be explicitly included in the definitions] 09:28:41 s/RESOLVED:/RESOLUTION:/ 09:28:53 [some naming discussion for 'paint-order'] 09:29:24 to which reqs does the paint-order proposal correspond ? 09:29:41 Cyril, none, it's a new one. (sorry!) 09:29:55 other options suggested: painting-order, draw-order, painting-operation-order, shape-order 09:30:24 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Stroke_position 09:31:14 Cyril: Maybe link to that requirement when talking about paint-order. 09:31:35 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Commitments 09:31:47 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/Stroke_position 09:32:01 http://lists.w3.org/Archives/Public/www-svg/2011Sep/0057.html 09:32:48 tabatkins__: The two aren't actually related, except that one use-case can be done with either. 09:32:58 krit: Note that stroke-position *would* affect hit-testing. 09:33:29 ScribeNick: heycam 09:33:33 Topic: SVG DOM 09:33:41 TA: we've discussed fixing the SVG DOM generally 09:33:52 … like throwing away animVal/baseVal, in favour of a way of retrieving those things separately 09:33:56 … obviously that's a breaking change 09:34:10 BB: we have a proposal for deprecating that at the same time as introducing compact syntax 09:34:16 TA: if we can do this compatibly, that'd be awesome 09:34:24 … but if not, we need to think about version switching 09:34:34 … we'd need to do this in such a way that's usable in SVG and HTML as well 09:34:51 … the version switch for example can't be based on doctype 09:34:58 … since that wouldn't work for inline SVG-in-HTML 09:35:28 Commitments page modified 09:36:11 TA: one thing I've been talking about is switch SVG over into the HTML namespace, so we don't have to care about namespaces any more 09:36:18 RC: so for inline SVG, all the APIs change? 09:36:26 TA: well you would use createElement instead of createElementNS 09:37:11 … one problem is style/script/font/a 09:37:24 … we want a context free parsing mode in HTML, but to do that properly it needs to know context 09:37:39 … we want that to work for SVG too 09:37:46 … if the markup string starts with "" then it should know it's SVG 09:37:57 … if the first element you see is style/script/font/a, then it'll think that it's HTML instead 09:38:09 … if we switched it all over to the HTML namespace it's ok 09:38:39 … the only sane way to do the parsing is to look at the start tag 09:38:42 … to determine the context 09:39:36 Dirk: there's also different DOM APIs for SVG/HTML script and style 09:40:01 TA: if there is a fragment that starts with then it's very likely to be HTML 09:40:12 ED: people have been suggesting innerSVG instead of innerHTML 09:40:19 … which is one way of switching, but it's not great 09:40:32 http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Input#Make_it_easier_to_read_and_write_to_attributes_in_the_DOM 09:40:38 http://www.w3.org/Graphics/SVG/WG/wiki/SVG_2_DOM 09:40:50 rectElt.x.px = 20 09:41:33 TA: className works differently between SVG and HTML, so that's weird 09:41:39 … it would be good to have no differences between these accessors 09:41:48 zakim, mute me 09:41:48 Cyril should now be muted 09:41:54 zakim, who is noisy? 09:41:55 zakim, who is noisy 09:41:55 I don't understand 'who is noisy', Cyril 09:42:08 zakim, who is noisy? 09:42:13 tabatkins__, listening for 18 seconds I heard sound from the following: Tav (97%), +49.403.063.68.aaaa (2%) 09:42:19 zakim, mute Tav 09:42:19 Tav should now be muted 09:42:29 Cyril, listening for 14 seconds I heard sound from the following: Tav (31%), +49.403.063.68.aaaa (62%) 09:43:38