20:22:27 RRSAgent has joined #svg 20:22:27 logging to http://www.w3.org/2011/03/03-svg-irc 20:22:29 RRSAgent, make logs public 20:22:31 RRSAgent, this meeting spans midnight 20:22:31 Zakim, this will be GA_SVGWG 20:22:31 I do not see a conference matching that name scheduled within the next hour, trackbot 20:22:32 Meeting: SVG Working Group Teleconference 20:22:32 Date: 03 March 2011 20:22:59 Team_(svg)20:22Z has now started 20:23:06 + +1.649.363.aaaa 20:23:19 OK, thanks. 20:31:06 Scribe: Anthony 20:31:11 ScribeNick: anthony_nz 20:31:16 AD has joined #svg 20:31:28 +tbah 20:32:26 Chair: Cameron 20:32:36 Topic: CSS 3D Object Position 20:32:51 ED: Ties into the discussion yesterday about images and aspect ratio 20:33:01 ... CSS 3 has the new object fit properties 20:33:14 ... they effect how images are hard positioned and extended in the image tag 20:33:22 ... it offers more than preserveAspectRatio in SVG 20:33:45 ... because you can position the image inside where ever you want 20:33:48 ... use Calc even 20:33:58 ... not sure how this will effect the decisions made yesterday 20:34:28 ... it will definitely effect the case for img 20:34:54 DH: In SVG there is the override for perserveAspectRatio if object fit is specified 20:35:04 http://testsuites.opera.com/object-fit/README 20:35:12 ED: This is what Opera is doing at the moment 20:35:25 ... this is how we've implemented it so far 20:35:30 ... There are two things here 20:35:37 ... do we want to have object fit and object position in SVG 20:35:55 ... and perhaps get rid of preserveAspectRatio 20:36:03 CM: Not sure about getting rid of 20:36:21 ... I mean we should have the properties apply to where preserveAspectRatio applies 20:36:45 ED: Positioning inside a viewport is nice 20:36:52 ... for other things it's mostly the same 20:37:02 ... the difference being it's a property and not an attribute 20:37:57 DS: Does it solve all the same cases that preserveAspectRatio solves or are there still uses for preserveAspectRatio? 20:38:28 CM: How you can specify preserveAspectRatio defer for an external document 20:38:50 ED: In most cases I think it is more useful to have it as a property and not an attribute 20:39:33 DS: That would let us deprecate an attribute that is not very well understood and not often used 20:39:51 AG: defer is not defined very well 20:40:00 ED: Yes, and I've hardly seen anyone use it 20:40:28 DS: So we can do everything with image-fit 20:41:00 ... except for defer behaviour in preserveAspectRatio 20:41:48 CM: We could ask the CSS Working Group if they could add this functionality into object-fit properties 20:42:41 http://dev.w3.org/csswg/css3-images/#object-fit 20:42:48 ED: For the image element in HTML it will have an effect because the default value for object-fit will be "fill" 20:42:52 tbah has joined #svg 20:42:57 ... That means it will fill the entire element 20:43:11 ... That is the same as preserveAspectRatio "none" 20:43:20 ... I don't think that is a change from the tests we did yesterday 20:43:35 CM: That's not the default behaviour of preserveAspectRatio 20:44:07 ED: If you have an HTML img element and you reference an image with preserveAspectRatio set 20:44:13 ... it's not clear what happens 20:44:28 .... I think that object-fit should override 20:45:04 CM: In your proposal it seems like you want to add a new value "auto" to preserveAspectRatio 20:46:02 JW: In CSS you don't have the knowledge that value is specified. The user should have to actively do something to say that the preserve aspect ratio is kept 20:46:06 ... by using defer 20:46:18 ... Without doing anything and saying that this overrides 20:46:37 ... All reference SVG content will have their preserve aspect ratio will be overridden 20:47:15 CM: You want existing content that doesn't have preserveAspectRatio defined to render the same as if "none" is specified 20:47:26 JW: Seems to me we might need a value of "auto 20:48:55 DH: We might have to insert something to say override object-fit 20:50:08 DS: There are circumstances that an author would want to change the original document 20:50:13 http://testsuites.opera.com/object-fit/ 20:50:32 ... It would be nice to override what the document thinks the display is 20:51:54 CM: Even without SVG this object fit could effect how raster images are sized 20:52:12 DH: Raster images don't react to their viewport where as SVG does 20:53:28 JW: Having object-fit work on the SVG element the interaction there are even more complicated 20:53:41 ... because you have an actual value and it is unclear when it would override 20:53:49 ... which is why you'd want an "auto" value 20:54:24 CM: I agree, I think we need an "auto" value 20:54:57 ED: The argument that was made was you can set different defaults depending on the context it was used 20:55:29 ... for the Video element it has one default value, where as the default is different for SVG 20:55:51 JW: It still doesn't solve the problem that I want to defer 20:56:06 DS: So "auto" would be "defer" or "fill" 20:56:41 CM: "auto" would mean just do whatever do what preserveAspecrRatio means in SVG currently 20:58:02 shepazu has joined #svg 20:58:54 DH: I'd like to have "auto" be like "fill" or preserveAspectRatio "none" 20:59:24 http://testsuites.opera.com/object-fit/ 20:59:55 ED: Here is the link to the test suite which has object-fit with SVG and some other test cases; Video, etc 21:01:37 ... if you have feedback on this, I'd be happy to hear about it 21:01:47 CM: Does that mean that "auto" should be proposed? 21:02:04 ED: If we think "auto" is useful we should go back to the CSS Working Group with that 21:02:38 ... The other issue I want to see resolved is to have the support for object-fit in SVG 2 21:04:25 JW: I still find some of these values not intuitively obvious about that they do 21:05:42 CM: Do we need to talk to them about "none" - was it dropped? 21:06:01 ED: It says it is controversial 21:06:10 ... would need a good argument about why it is needed 21:07:59 ROC: I'm a bit worried about it because image sizing is already complicated as it is. It is easy to see how to use it for raster images 21:08:13 ... but once you apply it to SVG images it starts getting complicated 21:09:07 ED: I'd say it's easier to use than preserveAspectRatio 21:10:00 ROC: If it's just an override it's not so bad 21:10:34 RESOLUTION: SVG 2 will require object-fit and object-position 21:11:32 ACTION: JWatt to Gather up issues regarding object-fit and it's applied to SVG and email CSS Working Group 21:11:32 Created ACTION-3001 - Gather up issues regarding object-fit and it's applied to SVG and email CSS Working Group [on Jonathan Watt - due 2011-03-10]. 21:16:01 -tbah 21:16:49 roc has joined #svg 21:16:51 roc, http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.svg 21:17:29 shepazu has joined #svg 21:27:00 disconnecting the lone participant, +1.649.363.aaaa, in Team_(svg)20:22Z 21:27:04 Team_(svg)20:22Z has ended 21:27:04 Attendees were +1.649.363.aaaa, tbah 21:44:17 pdengler has joined #svg 21:50:52 AD has joined #svg 21:56:10 Topic: Accessibility 21:56:41 DS: SVG should be accessible but is not accessible 21:57:07 ... problems are inconsistency between implementations and the lack of normative behaviour of content 21:57:28 ... There are different kind of accessibility needs 21:57:57 ... [Goes through presentation] 22:18:32 ... my proposal is that we undertake to have an SVG Accessibility document that talks about how SVG can be authored 22:18:40 ... for accessibility 22:19:50 ... We wouldn't be starting from scratch we will be engaging people that already have knowledge and are already working in the field 22:21:01 ... There is an Australian thing call NVDA who would be interested in working with us 22:21:30 CM: NVDA is open source 22:21:58 DS: It was installed on every library in New Zealand 22:22:15 CM: Do you see us collaborating with the accessibility groups on this 22:22:37 DS: We'd talk with the people doing ARIA 22:23:32 ... I think we should start a different mailing list for SVG accessibility 22:24:53 AD: If a lot of CAD drawings and other schematics go to SVG 22:25:00 ... they're going to need to be accessible 22:26:58 ROC: SVG is not semantic and HTML has that same problem with Canvas 22:27:53 DS: SVG is semantic in the sense withing the realm of mathematics. Outside that it's not. 22:28:22 CM: We should take the top 10 types of graphics - information graphics 22:28:40 ... and define ARIA roles for them 22:29:22 ... Also include guidelines to say when doing a certain type of document uses certain roles and don't do certain things 22:29:45 DS: It would be good to define how to make accessible graphics 22:29:59 CM: What sort of things? 22:30:07 DS: Colour choices 22:31:06 ... I feel making a general accessibility document would be good. Perhaps the first thing to do is make one for SVG 22:31:10 ... then extract that out 22:33:57 ... I've seen cases where different tones were played for the a bar chart to indicate the overall trend in the graph 22:34:03 CM: Sonification 22:36:00 RESOLUTION: We will start an accessibility document for SVG 22:36:07 AG: So you'll be the editor Doug? 22:36:25 DS: Yes, I can be one of the editors. I would like to bring in other people who know the field more deeply 22:36:39 CM: I would like to get in the expertise 22:38:44 Topic: z-index 22:39:09 AD: Your proposal solves some of the problems 22:39:23 ... if you do enable-background="new" what do with the z-index 22:40:03 ... the concept of the stacking context solves this problem 22:40:09 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/z-index 22:40:19 ... main problem is how it would fit in the rendering model 22:40:56 ... If you introduce a stacking context when a z-index is specified 22:41:02 ... it solves the problem just fine 22:41:11 ED: I haven't read all of the details 22:41:26 ... I think it makes sense to add z-index support rather than layered-g 22:43:13 AD: If you don't specify z-index then your performance impact is nothing really. Only if you specify z-index you need to walk the tree twice which isn't too bad 22:43:37 DS: It's better from an authoring perspective 22:44:22 AD: I wouldn't bother putting any note in until it's shown to be a problem 22:44:31 ... or a performance hit 22:45:22 ... but I wouldn't expect there to be a performance hit 22:45:29 DS: This is an SVG 2 thing right? 22:45:32 JW: Yes 22:45:51 CM: If there are technical details we can work them out when we are writing up SVG 2 22:47:08 RESOLUTION: We will add Jonathan Watt's z-index proposal to SVG 2 22:48:04 JW: From what I remember CSS talks about how to deal with the background 22:48:33 ... and we're not going to get stroke and fill on different levels 22:48:58 CM: The syntax of the property is just the same as CSS? 22:49:01 JW: Yes 22:49:13 ... same definition, but with simplified instructions of how it works 22:50:22 ACTION: JWatt to Add z-index proposal to SVG 2 22:50:22 Created ACTION-3002 - Add z-index proposal to SVG 2 [on Jonathan Watt - due 2011-03-10]. 22:51:12 DS: Would be good to have a diagram showing the layers 22:51:39 ... for example showing a document without z-index and then a document with z-index 22:51:53 ... this would be good for authors to illustrate how the layers work in the document 23:07:06 AD has joined #svg 23:07:42 JW: Filters create a new stacking context 23:08:25 Topic: Text over-flow 23:08:29 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Text-overflow 23:08:48 ED: Some proposed wording for text-overflow in SVG 23:09:11 ... It's basically saying if my text is too long clip it or flow it 23:09:24 s/Filters create/applying a filter to an element cause it to create/ 23:09:26 ... This property is defined in CSS 3 23:09:37 .. It's not defined there for SVG 23:09:46 ... but it is something we could apply to SVG elements 23:10:15 ... My proposal is to add to SVG text element and SVG textArea (in Tiny 1.2) 23:10:48 ROC: It wouldn't take effect if you just had a clipping thing that contains text 23:11:29 ... If it doesn't have a width it doesn't do anything 23:11:49 ... HTML 5 Canvas Text has something useful 23:12:12 ... What they do is they say here's the text and here's the width. If it's too big shrink the width 23:12:21 ... and increase the height 23:12:34 ED: You can already do that with text-length attribute 23:12:41 ... This is different 23:12:50 s/text-length/textLength/ 23:12:57 ... one of the differences is this is for blocks of text 23:13:29 CM: What would happen with tspans and absolute position of glyphs 23:13:33 ED: Good question 23:13:43 ... this proposal doesn't solve all of the issues 23:14:05 ... I have at least 10 that I could think of 23:14:06 ... So we would need to solve these 23:14:15 ... I don't have any strong opinion on how we solve these 23:14:48 CM: With the CSS one what happens when you get selection range? 23:15:13 ROC: Do you talk about the placement of the glyphs with BiDi 23:15:22 ED: Yes, I did 23:15:40 ... same as CSS 23:15:47 ROC: I'm not so happy with the behaviour, but it is the same between the two 23:15:52 ... CSS and SVG 23:17:00 ED: In order to get the ellipsis you need to specify overflow 23:17:35 CM: I still think that SVG does need some sort of layout things in it 23:17:54 ... SVG as it is don't need to worry about overflow property 23:18:07 ED: I think the ellipsis thing is the one thing people want 23:18:25 AD: There is high demand for it in the IPTV world 23:18:58 ED: textArea might be a bit simpler because it already has width and height 23:19:09 AD: It's really ugly to do this in script 23:20:04 CM: You can imagine all different types of ways squashing the text in 23:20:20 ... I would like to see font size adjustment to fit things 23:20:30 ED: That would be more a textLength thing 23:22:57 CM: What happens when you have both textLenght specified and width? 23:23:09 ED: If the textLength is longer than the width you'd get ellipsis I guess 23:23:18 CM: I was thinking the other way 23:23:24 ... to ellipsis replacement first 23:23:52 ... so you'll never get overflowing text using textLength? 23:24:00 ED: No, it will just squash it up 23:24:17 CM: In CSS what happens with styling of the ellipsis? 23:25:03 ROC: In CSS it's either you use the style of the block which declares the overflow but it may have changed 23:25:18 CM: It seems like you want to do closest common ancestor 23:25:27 ... but we don't need to solve these issues now 23:25:37 ED: I'd like to see if this can be place in SVG 2 23:26:26 AD: In textArea it should wrap so you don't show an ellipsis. But we've had feedback from editors that it is really ugly 23:26:37 ... they want a character by character horizontal scroll 23:27:21 ... For the simple case where you have a login box which just does a character by character scroll we never did that 23:27:43 ... We had to word wrap it and they had to live with it 23:28:01 ... It really restricts the textArea as an editable control 23:28:40 CM: Why not have the functionality on text? 23:28:52 AD: textArea was suppose to be flow container 23:28:59 ... that allowed glyphs etc. 23:29:07 ... The whole chapter is defined 23:29:22 ... we defined all the algorithms for it 23:35:07 ... and it was reviewed by the experts in Indesign and they liked the model 23:36:15 DS: This is something that alot of people want solved 23:36:23 s/alot/a lot/ 23:37:33 AD: I'm strongly in favour of text-overflow 23:37:45 AD has joined #svg 23:37:49 RESOLUTION: We will add text-overflow in SVG 2 23:38:33 ACTION: Erik to Add text-overflow in SVG 2 23:38:33 Created ACTION-3003 - Add text-overflow in SVG 2 [on Erik Dahlström - due 2011-03-10]. 23:39:32 CM: The whitespace property, does that have any effect on us? 23:39:37 ED: Not sure 23:40:00 CM: Can we move away from using XML whitespace and use the whitespace property? 23:40:03 ED: That would be nice 23:41:06 DS: How about we say that XML space doesn't do what it did in SVG 1.1 23:41:16 ROC: So drop support for xml:space? 23:41:24 ... how much content will break? 23:41:36 CL: None 23:41:46 ROC: Can we remove it from the test suite? 23:42:43 s/ED: Not sure/ED: No/ 23:43:19 RESOLUTION: We drop xml:space from SVG 2 and remove the relating tests from the SVG 1.1. test suite 23:43:52 ROC: Should warn authors that in SVG 1.1 that this is being deprecated 23:44:21 ACTION: Chris to Remove the tests from the SVG 1.1 tests suite that relate to xml:space 23:44:21 Created ACTION-3004 - Remove the tests from the SVG 1.1 tests suite that relate to xml:space [on Chris Lilley - due 2011-03-10]. 23:44:41 ACTION: JWatt to Draft a proposal to use CSS whitespace in SVG 2 23:44:42 Created ACTION-3005 - Draft a proposal to use CSS whitespace in SVG 2 [on Jonathan Watt - due 2011-03-10]. 00:13:20 homata has joined #svg 00:39:18 homata__ has joined #svg 01:34:12 homata has joined #svg 01:46:16 I haven't seen any activity here, are you still out to dinner 01:52:37 we just got back --- from lunch 01:52:42 AD has joined #svg 01:52:48 birtles has joined #svg 01:53:16 Zakim, room for 3? 01:53:17 ok, heycam; conference Team_(svg)01:53Z scheduled with code 26631 (CONF1) for 60 minutes until 0253Z 01:53:39 Team_(svg)01:53Z has now started 01:53:46 + +1.649.363.aaaa 01:55:56 Scribe: Cameron 01:55:59 ScribeNick: heycam 01:56:11 Topic: buffered-rendering 01:57:43 I booked nine single-person kayaks, the tide is in the morning so we need to be there at 9:30am : http://www.puhoirivercanoes.co.nz/puhoi_river_kayak_trips.htm 01:58:12 I told them it might only be eight people in the end 02:01:12 s/buffered-rendering/Next F2F/ 02:01:22 http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Next_F2F 02:02:39 CM: jun mailed the list about meeting at the same time/place as csswg in tokyo, in june 02:02:50 ... I think we should meet then 02:02:58 AG: google offered meeting space just on the same dates as the csswg meeting 02:03:05 ... for the remaining days, canon or kddi can host 02:04:19 DS: maybe some csswg people can stay on for extra days to have meetings with us, rather than eat into their meeting time 02:05:18 ACTION: Chris to tell CSSWG that we want to meet them! In Tokyo in June. 02:05:18 Created ACTION-3006 - Tell CSSWG that we want to meet them! In Tokyo in June. [on Chris Lilley - due 2011-03-11]. 02:05:34 DS: we have colocated in the past with LGM 02:05:38 CL: which is in montreal this year 02:05:43 DS: with SVG Open, which is in Boston 02:06:01 CL: SVG Open is late this year, and in Boston. 02:06:11 ... two weeks later is TPAC 02:06:15 AG: there's one week gap between them 02:06:46 DS: I think the Thursday is the workshop, for SVG Open 02:07:00 CL: maybe we could have part of the F2F before SVG Open, then part of it on Thursday/Friday after 02:07:11 ... so we can concentrate on feedback we get from SVG Open 02:07:58 DS: one other thing with SVG Open, is that W3C is thinking about having a night, like in Paris 02:08:07 ... where there'll be some presentations on teaching SVG, showcasing it, to the general public 02:08:13 ... so that's probably going to happen the evening before SVG Open 02:08:30 ... I imagine either MS or W3C would be able to provide meeting space there 02:08:50 ... while LGM is a good opportunity to touch place with the open source community, and is fun, I'm not sure is as critical as SVG Open 02:08:57 ... how many meetings are we planning on having? 02:09:55 CL: we are meant to attend TPAC 02:10:43 ... wht aabout Thursday Friday in Boston, after SVG Open 02:10:52 ... then 2 days at TPAC 02:12:55 [discussion about Tokyo meeting days] 02:19:20 CL: we could meet on Fri June 3 with CSS WG, take the weekend off, then have our normal 5 day meeting on the following week 02:19:44 ACTION: Anthony to coordinate with Fujisawa-san to organise hosting for Tokyo SVG F2F 02:19:44 Created ACTION-3007 - Coordinate with Fujisawa-san to organise hosting for Tokyo SVG F2F [on Anthony Grasso - due 2011-03-11]. 02:21:10 AG: how about the late year F2F? 02:21:36 CL: go to SVG Open, Mon-Wed, do Thurs-Fri SVG WG meeting 02:21:40 ... then the week in between is free 02:21:46 ... following week is TPAC 02:22:36 AG: I probably can't make the final Friday of the Tokyo F2F 02:22:44 DS: let's just make it Mon-Thurs on that week then 02:24:52 ACTION: Chris to liaise with MS for the F2F meeting around SVG Open 02:24:52 Created ACTION-3008 - Liaise with MS for the F2F meeting around SVG Open [on Chris Lilley - due 2011-03-11]. 02:32:23 AD has joined #svg 02:35:18 Could we consider the week of the 26th for the Face to Face in ENgland? 02:38:01 pdengler: we are planning to have 2 days after SVG Open, then the next 2 days at TPAC a week later 02:38:26 could microsoft host the F2F after SVG Open? 02:39:54 pdengler: the problem is, we really need to meet at TPAC 02:41:08 Topic: buffered-rendering 02:41:12 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/User_controlled_caching_of_rendering 02:41:48 JW: we discussed this a bit, roc alex and myself 02:42:08 ... everyone decided that some sort of user control of off screen caching would just end up being misused, or used improperly 02:42:14 ... and we'd need to disable it or not recognise it anyway 02:42:26 ... implementations can generally detect when things are moved around in a way that would benefit frmo caching 02:42:30 ... so caching would be automatic 02:42:34 s/frmo/from/ 02:42:52 I will look into hosting the f2f yes, 02:42:57 ... one thing that will be an issue is animations, where the start of the animation is immediate and smooth 02:43:14 ... that's always going to be a problem with an automatic caching mechanism that detects motion and decides to cache 02:43:30 ... if you do some gesture on a webpage that should animate things on the screen quickly, you want it to react immediately 02:43:40 ... the whole purpose of using offscreen caching is beause you need responsiveness 02:44:00 ... but you might have a couple of frames where it's sluggish 02:44:24 ... we used it in a previous job, but in that situation we were able to correct misuses of buffered-rendering 02:44:37 ... in general I think user control of offscreen caching we shouldn't do, at this stage 02:45:01 DH: sounds like your situation where it would be slow initially, on animation start, since it's declarative animation you could detect this 02:45:21 JW: sometimes, but if your begin is something.click, so in response to a user interaction, and if you have lots of these things in the document, and you don't want to cache them all, you still have this issue 02:45:25 AD: also if it's all script 02:45:55 DH: for declarative, you could render the offscreen rendering on the very first sample of the animation 02:46:00 ... we currently recompute the world on every sample 02:46:16 JW: there are two parts that make it slow 02:46:22 ... there are the first 1 or 2 paints, when you figure out it's moving 02:46:29 ... and the other one is the slow rendering into the offscreen buffer 02:46:51 CM: because these are complex objects you want to buffer? 02:46:52 JW: yes 02:49:09 AD: you could have a limit, say 1 or 2 buffered-renderings in the document, or a certain MB of cache 02:50:53 ED: we've implemented it, and already seen misuse of it 02:51:18 ... it says in the spec that if you update the subtree, it says you should rerender it, but it doesn't say when 02:51:25 ... there's a bit of free room there for experimenting 02:51:32 ... i think it will be hard to harmonize implementations there 02:51:48 AD: what was the motivation for proposing this? 02:51:55 JW: i occasionally hear people requesting it 02:52:06 ... I wanted it for one document I was writing 02:52:38 ED: I think it's fine for closed systems, but not sure it's good for the web as a whole 02:56:23 RESOLUTION: We won't add buffered-rendering to SVG 2 unless implementor feedback indicates that it is needed 02:56:43 ChrisL has joined #svg 02:57:51 Topic: Connectors 02:57:57 s/we were able to correct misuses of buffered-rendering/we were able to correct misuses of buffered-rendering because this was a closed system/ 02:58:01 disconnecting the lone participant, +1.649.363.aaaa, in Team_(svg)01:53Z 02:58:05 Team_(svg)01:53Z has ended 02:58:05 Attendees were +1.649.363.aaaa 02:59:21 s/you figure out it's moving/ou figure out it's moving, which you can avoid if the animation is declarative/ 02:59:45 DS: [presents some slides] 02:59:45 s/slow rendering into the offscreen buffer/slow rendering into the offscreen buffer, which you can't avoid even with declarative animation/ 03:03:09 DS: connectors would be a straight line between two nodes 03:03:16 ... you can style their appearance 03:03:23 ... there would be a list of connectors for navigation purposes 03:03:29 ... they wouldn't dynamically position nodes in the graph 03:03:34 ... no concept of weighting on edges 03:03:38 ... it wouldn't do line routing 03:03:51 ... it wouldn't allow automatic drag-and-drop 03:08:14 [rest of the presentation] 03:09:03 DH: seems useful 03:09:10 RO: it seems like a step towards graph layout 03:09:48 ... and edge routing 03:09:59 DS: you can draw the lines yourself, the straight line is the default 03:15:42 CM: the part I like the most is the automatic connection to the closest point on a shape 03:15:54 ... the semantic part I'm not sure about, without having a whole aria vocab 03:16:01 JW: regarding routing, how about having routing points? 03:17:20 ... yes you can have polylines 03:18:04 CM: would it be a separate connector element? how about just sticking some attributes on a ? 03:18:44 DS: i like the syntax of a separate element 03:19:15 Topic: SVG Integration 03:20:33 DS: I'll give you a brief overview of the document as it stands 03:20:39 http://dev.w3.org/SVG/modules/integration/SVGIntegration.html 03:20:41 ... we have "referencing modes for svg" 03:20:54 ... they are ways for specifications to say they are using svg in particular contexts 03:20:59 ... e.g. css might use a particular referencing mode for images 03:21:07 ... html might use one for image and another for iframe 03:21:21 ... it describes svg in terms of some specific capabilities -- animation, external references, [...] 03:21:38 ... we've talked about having one or two more, but i won't go into the individual referencing modes 03:21:57 RO: why not define those flags as independent things? you might want a combination of flags that's not one of the preset modes. 03:22:20 DS: we could. i did it this way because people in the past have asked "how do I reference SVG, what's a handy name for a set of common flags" 03:22:30 ... so we can say it's using "secure animated modes" 03:22:32 CL: you could do both 03:22:46 RO: or you could make the flags normative, and the modes informative 03:22:56 DS: yes, well the modes would be normative, but yes 03:23:43 ... network admins, once they understand animated script-less svg is safe for them, they don't have to think about it any more 03:24:13 [shows examples from the spec] 03:24:27 ... it also talks about foreign content in svg 03:24:40 ... how you can comine -- we don't explicitly talk about using html in foreignObject, in the svg spec 03:24:47 ... in SVG Integration we decided we'd actually talk about that 03:24:57 ... talking to implementors about considerations about that 03:25:03 DH: might be good to mention plugins and scripts 03:25:12