01:07:43 RRSAgent has joined #svg 01:07:43 logging to http://www.w3.org/2013/11/14-svg-irc 01:08:01 chair: ed 01:08:21 Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda 01:09:23 nikos has joined #svg 01:10:12 scribe: nikos 01:10:28 scribeNick: nikos 01:10:46 Yo, we got polycom? 01:11:16 Rossen__ has joined #svg 01:11:32 TabAtkins, we're setting it up 01:11:37 Cool, thanks. 01:11:39 RRSAgent, start telcon 01:11:39 I'm logging. I don't understand 'start telcon', heycam. Try /msg RRSAgent help 01:11:41 regarding the agenda, I think it would make more sense to discuss "SVG streaming update" after Brian's "Web Animation" this afternoon 01:11:44 trackbot, start telcon 01:11:46 RRSAgent, make logs public 01:11:46 Zakim has joined #svg 01:11:48 Zakim, this will be GA_SVGWG 01:11:49 Meeting: SVG Working Group Teleconference 01:11:49 Date: 14 November 2013 01:11:49 I do not see a conference matching that name scheduled within the next hour, trackbot 01:12:01 Zakim, call huangshan 01:12:01 sorry, heycam, I don't know what conference this is 01:12:04 thorton has joined #svg 01:12:19 Zakim, room for 4 for 8 hours 01:12:19 I don't understand 'room for 4 for 8 hours', TabAtkins 01:12:20 scribe: nikos 01:12:32 Zakim, room for 4 for 600m 01:12:32 I don't understand 'room for 4 for 600m', TabAtkins 01:13:02 TabAtkins, we can't call out from here 01:13:19 Zakim, call huangshan 01:13:19 sorry, heycam, I don't know what conference this is 01:13:24 Zakim, this is SVG 01:13:24 sorry, heycam, I do not see a conference named 'SVG' in progress or scheduled at this time 01:13:30 Zakim, room for 4 01:13:30 I don't understand 'room for 4', TabAtkins 01:13:36 Zakim, room for 4 01:13:36 I don't understand 'room for 4', TabAtkins 01:13:40 Zakim, room for 4? 01:13:41 ok, TabAtkins; conference Team_(svg)01:13Z scheduled with code 26632 (CONF2) for 60 minutes until 0213Z 01:13:48 For god sakes, Zakim. 01:13:50 Zakim, call huangshan 01:13:50 ok, heycam; the call is being made 01:13:51 Team_(svg)01:13Z has now started 01:13:52 +Huangshan 01:14:05 Zakim, who is on the call? 01:14:05 On the phone I see Huangshan 01:14:07 Zakim, a goddamned thing 01:14:07 I don't understand 'a goddamned thing', TabAtkins 01:14:10 I know that, Zakim. 01:14:17 jun has joined #svg 01:14:23 We all know that. 01:14:56 I'll be here the whole time, so don't worry. 01:15:07 It's 5pm to 2am for me, and I've already done this for 2 days. 01:15:35 heycam has changed the topic to: Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda 01:15:45 heycam has changed the topic to: Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda code for today is 26632 01:17:02 astearns has left #svg 01:17:40 +TabAtkins 01:19:40 -Huangshan 01:20:15 Heh. 01:20:37 Zakim, dial huangshan 01:20:37 ok, heycam; the call is being made 01:20:39 +Huangshan 01:22:25 Topic: Numeric Precision for SVG 01:22:33 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/NumberPrecision 01:23:22 birtles: Takagi-san prepared this wiki page. You can read the issue yourself 01:23:31 ... SVG 1.1 only requires single precision floating point 01:23:40 ... but for mapping use cases it appears that double precision is neccessary 01:23:45 ... what are your thoughts? 01:23:59 heycam: We had a meeting recently with all our layout and graphics people 01:24:08 ... anytime graphics people heard double precision they cringed 01:24:12 ... GPU HW only works in floats 01:24:26 ... and it's going to me more and more likely we'll be restricted to floats as we move more into HW 01:24:39 ... currently changing graphics library layers and that uses floats 01:24:48 ... I feel it'll be difficult to require double precision 01:24:51 shepazu has joined #svg 01:24:55 krit: SVG 1 doesn't require double but allows it 01:25:05 heycam: SVG 1 spec has different performance class requirements 01:25:12 ... high quality viewer must support double 01:25:18 ... I'm wondering how realistic that is now 01:25:47 TabAtkins: Takagi-san made a wiki page that has a precision of 5 decimal places 01:25:50 ... floats have 7 digits 01:25:56 ... so why is this a problem? 01:26:33 s/has a precision/describes a requirement for precision 01:26:37 s/made a wiki page that has/said on the wiki page that he needs/ 01:27:20 birtles: I clarified with Takagi-san and if that's the case thats ok 01:27:29 ... but tests with IE show that it appears to use fixed point 01:27:33 jeroskim has joined #svg 01:27:37 ... with only 3 digits of precision 01:27:42 krit: that's true. Firefox is the same 01:27:59 heycam: 16.16 fixed point stuff comes from Cairo 01:28:09 ... I can't remember the exact plan for software rendering back end 01:28:17 ... but we are removing Cairo as the intermediate API layer 01:28:29 ... most of the back ends will use single precision 01:28:39 ... so perhaps for this use case it will get better in Firefox 01:29:17 krit: fixed point is coming from HTML 01:29:56 ... It's not a requirement for Skia but Blink is still using fixed point for that 01:30:04 heycam: you're talking about for CSS layout? 01:30:06 krit: yes 01:30:20 krit: Since SVG is using the same engine as HTML wouldn't it be the case for both? 01:30:39 heycam: I think it could be reasonable to use different code for layout of CSS boxes compared to 2d graphics APIs 01:30:44 dino has joined #svg 01:31:01 ... if IE uses fixed point for graphics stuff and CSS layout then perhaps there's some reason for linking the two 01:31:10 Rossen__: what were the tests? 01:31:30 krit: viewbox with 0.00001 will render differently 01:31:46 Rossen__: for CSS values we use fixed point. For SVG we use as much floating point as possible 01:32:01 krit: we parse all of CSS values to floating point 01:32:21 s/CSS values to floating point/CSS values to fixed point 01:32:35 Rossen__: we parse SVG to floating point 01:33:01 krit: I can write a test 01:33:14 heycam: one thing to clarify is whether single precision floating point is enough? 01:34:33 birtles: It may be enough to render with single precision but if you parse them as single precision, then by the time you apply transformation matrices you may lose precision 01:34:37 01:34:37 01:34:37 01:34:57 cabanier: PDF had the same problem 01:34:59 ... creating huge maps 01:35:16 ... they only had a certain position so edges of the map were rough 01:35:35 ... so to solve you translate 01:35:46 ... it's an internal engine thing 01:35:57 heycam: so the answer is to not have everything in the one co-ordinate system 01:36:51 birtles: I don't know how you'd specify it 01:36:54 MikeSmith has joined #svg 01:37:00 krit: it doesn't need to be specified. It's an implementation detail 01:37:11 cabanier: so when you zoom all the way out. fine details may not be right 01:37:17 ... it only matters when you zoom in 01:37:32 heycam: in reality you have different sources of data, different tiles that are merged 01:37:40 ... they're not going to be in the same co-ord system originally 01:37:50 ... some of the proposals we've seen before transform them into a common co-ord system 01:38:05 ... leaving the data like that and not having one co-ord system seems to be the right thing to do 01:39:04 heycam: when you combine global view and some fine detail - say if you have country path information that can be viewed zoomed out, but if you zoomed into a border town region and look at the roads there, then by the time you do that you have lost the precision of the global view 01:39:22 ... maybe different data sources should be used 01:39:43 stakagi: that's ok 01:40:08 krit: the test case I posted previous shows that IE does support floating point precision and Firefox doesn't 01:40:13 ... that will hopefully change in the future 01:40:32 ed: so we don't need to make any change? 01:40:56 heycam: something to think about when defining conformance classes 01:41:09 ... would people be amenable to removing the double precision requirement? 01:41:26 krit: for most things in WebKit and Blink we use single precision internally even if API uses doubles 01:41:31 ... exception is everything from CSS is still double 01:41:42 ... but it's converted to single at some point 01:41:51 heycam: I was considering changing webidl to float to match JS 01:42:02 ... but it makes sense to leave as float since APIs use that 01:42:59 heycam: I don't think it's a great idea to have different classes that give different results 01:43:10 ... especially for path positions 01:43:14 ... I'd rather remove it 01:43:16 birtles: the whole class? 01:43:33 shepazu: CSS resolved to use rfc6919 01:43:48 heycam: sothese are the things that high quality viewers are meant to do 01:44:14 https://svgwg.org/svg2-draft/conform.html#ConformingHighQualitySVGViewers 01:44:28 s/sothese/so these 01:44:40 heycam: this was written 12 years ago 01:45:05 shepazu: I don't think that these are modern constraints 01:45:09 heycam: they're the wrong level also 01:45:14 shepazu: let's remove this bit compeltely 01:46:39 krit: image rendering is specified in CSS 01:46:43 ... might not be a good thing to have in SVG 01:46:48 ... I would definitely remove point 4 01:47:03 ... I would remove it as a requirement to decide if you use high quality or low quality rendering 01:47:27 TabAtkins: are you saying people should always respect the image rendering property regardless of mode you're in? 01:47:30 ... if so I agree 01:47:32 krit: yes 01:47:59 shepazu: looking through these, I don't think they're meaningful in today's market 01:48:10 ... I don't know who this is written for 01:48:15 ... we should just remove it 01:48:26 ... if we decide we'll get better performance out of floats rather than doubles 01:48:37 krit: I don't think floats or doubles are a good criteria for quality 01:48:43 shepazu: all these requirements have that problem 01:48:56 ACTION: heycam to look at the performance class requirements and decide whether to remove points or move them into general requirements 01:48:56 Created ACTION-3535 - Look at the performance class requirements and decide whether to remove points or move them into general requirements [on Cameron McCormack - due 2013-11-21]. 01:49:34 RESOLUTION: Remove performance class requirements from SVG 2 01:50:01 Topic: Proposals/ResourcePriorities for SVG 01:50:04 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/ResourcePriorities_for_SVG 01:50:25 birtles: Takagi-san prepared this wiki page 01:50:35 ... this is about resource priorities spec from web performance working group 01:50:41 ... first issue is about the postpone attribute 01:50:47 nsakai has joined #svg 01:50:48 ... and it's currently defined in terms of bounding boxes 01:51:03 ... but Takagi-san has some feedback to suggest it would be useful if it could also be used in regards to zooming 01:51:18 ... currently says that things with bounding box outside current viewport don't need to be loaded 01:51:35 ... but it seems like that would be a good thing for conditionally loading tiles 01:51:51 ... We've sent feedback but I don't know if it's been taken on board yet 01:52:38 krit: This sounds like a previous discussion on www-svg 01:52:48 ... A thread about resource priorities and SVG 01:53:10 http://www.w3.org/mid/1383159383.2183.164.camel@chacal 01:53:42 birtles: that's [1] on the wiki page 01:54:18 http://lists.w3.org/Archives/Public/www-svg/2013Nov/0002.html 01:54:33 http://lists.w3.org/Archives/Public/www-svg/2013Nov/0003.html 01:54:39 krit: this was my reply 01:56:16 birtles: the proposal is that you would have different tiles (say several iframe elements in svg). For each you would have the postpone attribute 01:56:20 http://lists.w3.org/Archives/Public/www-svg/2013Nov/0021.html 01:56:28 ... you would only load the ones within the bounding box and at the right zoom level 01:56:35 ... it's not part of one image resource, it's several resource 01:57:14 ... the feedback here is that resource priorities only allows you to base the conditional loading on the viewport and the bounding box of the tile 01:57:25 ... so it doesn't take into account zoom 01:58:39 krit: doesn't the zoom level also influence the viewport? 01:58:43 birtles: it's not enough by itself 01:59:02 ... you could have several tiles that occupy the 2d space but are at several zoom levels. You don't want to load them all 01:59:16 ... the facility to achieve that might be to use media queries 01:59:28 krit: I think this discussion would have been better in FXTF 01:59:39 birtles: one piece did come up then - it's next on the agenda 02:00:03 heycam: If we did have a separate zoom media query, what things about the resource priorities needs to be changed to accommodate this use case? 02:00:19 birtles: the way postpone is currently described is purely based on viewport and bounding box 02:00:31 heycam: so you want to link it to this future zoom media query as well 02:00:38 birtles: I think that's Takagi-san's idea 02:02:41 birtles: I think this is something that we can't decide in this group 02:02:49 ... but at least it has helped to clarify the requirements 02:03:04 ... text in resource priorities spec doesn't quite align with these use cases 02:03:21 ... because it says tjat ot 02:03:42 ... that it's bounding box or display:none that defines whether resources are loaded 02:04:32 heycam: what about the fact that they're adding attributes to SVG without asking? 02:04:57 heycam: is that an issue? or do we just want to review their changes? 02:05:06 krit: I did and initial review but would be happy if others did as well 02:05:19 ... right now the spec has more issues with HTML than with SVG 02:05:42 krit: it's an easy spec to review 02:05:50 heycam: I'll have a look to see how it fits with SVG 02:06:34 ed: this is basically the same functionality as external resources required functionality of SVG 1.1 02:07:07 Topic: definition of 'zoom' for zoom media feature 02:07:16 http://www.w3.org/Graphics/SVG/WG/wiki/Proposals/zoom_media_feature 02:07:40 shepazu: did you see the email from Boeing about zoom and pan and load events? 02:07:47 birtles: I think that's a separate issue 02:08:02 ... this is something I don't think we need to discuss here because there was discussion in CSS on Sunday 02:08:13 ... Takagi-san, myself, and Dean spoke about this later 02:08:25 ... Ted from Apple has an action to look at different zoom media queries 02:08:38 ... the current ones available aren't sufficient for pinch zoom and such 02:08:58 ... Takagi-san has explored other ways a zoom media query could be specified and we've shown this to Dean to pass to Ted 02:09:12 TabAtkins: I notice all four of these definitions include scale transforms 02:09:19 ... do we have any clue how those work with media features? 02:09:35 heycam: so results of media query can't depend on property values because that's cyclic? 02:09:38 TabAtkins: yes 02:09:50 heycam: there is at least one type of zooming that isn't reflected in the styling 02:10:12 ... the pinch zooming and the dot current scale 02:10:53 TabAtkins: there might still be a use case for pinch zooming because you're going to want to tell when people are doing that 02:11:10 ... things that are trying to do resolution based stuff don't want to respond to pinch zoom but maps, etc would 02:11:43 dino: I think it's better they're all separated and individually queryable 02:11:53 TabAtkins: that might make sense 02:12:14 dino: I think step 1 is to define all the terms 02:12:31 TabAtkins: they're defined in CSS OM view and referenced from media queries 02:12:41 krit: it might make sense to see if the pinch zooming from SVG is different 02:12:59 krit: it might be different if you want to pinch zoom in a document without zooming the outer doc 02:13:08 Rossen__: how is that different to an iframe? 02:13:12 krit: just that SVG isn't an iframe 02:13:18 Rossen__: should generalise that behaviour 02:13:29 ... shouldn't apply just to SVG but to all elements 02:13:42 heycam: that was how I thought we might be able to do zoom and pan 02:14:23 shepazu: is SVG a special kind of content in HTML? A class that both SVG and iframe fall into? 02:14:27 krit: SVG has a viewport 02:14:35 ... makes it easier to define pinch and zoom 02:15:23 nsakai has joined #svg 02:15:31 birtles: Also when you have SVG loaded in an iframe and the parent doc is being zoomed that information also has to be available to the SVG 02:15:36 krit: should be possible with media queries 02:15:47 heycam: do you need to know individual transforms in the stack? 02:16:18 stakagi: probably yes 02:16:34 ... seems likely not not totally sure at the moment 02:16:59 actually, not the individual transforms, but the combined result 02:17:17 birtles: Next step is to see what Ted comes up with 02:17:21 ... and provide feedback 02:18:11 ACTION: heycam to review Resource Priorities specification 02:18:12 Created ACTION-3536 - Review resource priorities specification [on Cameron McCormack - due 2013-11-21]. 02:18:50 Topics: Should parsed unknown elements implement SVGElement? 02:18:56 https://www.w3.org/Bugs/Public/show_bug.cgi?id=23468 02:19:52 Yes. 02:20:09 ed: when you parse elements that SVG doesn't know about but that are in the SVG namespace 02:20:18 ... it seems that all browsers put SVGElement interface on those elements 02:20:24 ... rather than Element or SVGUnknownElement 02:20:33 ... which would be similar to HTML 02:20:46 krit: if we define one of these elements later it starts rendering for all content 02:20:53 ... I don't think this is an issue 02:21:21 krit: in this case since browsers already have behaviour, we should just specify it 02:21:46 ed: so just specify that SVGElement should be used in this case. 02:21:54 heycam: is there any advantage to doing things the HTML way? 02:22:11 shepazu: right now they're put in the SVG namespace 02:22:34 heycam: SVGElement has some things. e.g. nearest viewport 02:22:46 but SVGUnknownElement will inherit from SVGElement anyway 02:22:56 ... the only argument is for consistency with HTML 02:23:38 shepazu: the advantage I see is if you're trying to detect whether a browser supports a particular - say star 02:23:51 ... if the user agent doesn't know what to do with star, it might be nice to know that the UA doesn't know what to do with it 02:24:21 heycam: I think you can do that anyway because you can check object.getPrototypeOf the dom node 02:24:56 ... that would return a specific sub type 02:24:58 (el instanceof SVGElement) && (el.prototype == SVGElement.prototype) { /* Unknown element! */ } 02:25:07 dholbert has joined #svg 02:25:08 shepazu: what about if it's an element of another namespace? 02:25:28 krit: if we decide to put every element into the HTML namespace then SVG elements will use HTMLElement and HTMLUnknownElement 02:25:55 heycam: I think it depends on how we handle the parsing of that 02:26:04 ... as long as you get the outer thing - SVG or graphics in my proposal 02:26:10 ... if you're in that mode you can put the unknown ones in whatever 02:27:34 shepazu: seems to me the only element that I expect (besides new SVG elements) to add that might cause problems is the HTML element 02:27:55 +1 02:27:57 ... straw poll, who would like us to allow HTML root element without the foreignObject wrapper 02:28:03 +1 02:28:15 nsakai_ has joined #svg 02:29:12 shepazu: so will this cause problems in that context? 02:29:14 gcapiel has joined #svg 02:29:20 Rossen__: in this context inline content is treated how? 02:29:32 ... I mean text in SVG 02:29:43 foo? 02:29:55 Hello World 02:30:05 nsakai has joined #svg 02:30:05 More examples 02:30:07 Are you saying first example is different to second example? 02:30:11 Hellow World 02:30:18 Yes, different. 02:30:32 shepazu: yes that would be different 02:30:38 makes HTML element. Raw text is just ignored. 02:30:39 ... do we need the HTML root? 02:31:06 shepazu: All i was proposing was that the HTML tag be required to insert HTML content 02:31:10 Rossen__: I misunderstood 02:31:38 krit: I suggested HTML in SVG without the HTML tag 02:31:42 ... just needs a viewport 02:31:46 shepazu: who is going to do this? 02:32:07 TabAtkins: I'll do it 02:32:41 shepazu: the question is whether it causes us problems 02:32:48 heycam: depends how we do parsing and namespaces and so on 02:32:59 ... but should be able to test whether an element is recognised or not in any case 02:33:18 shepazu: I wonder if inserting SVG dynamically will behave different 02:33:33 ... currently in implementations you get different behaviour 02:34:00 krit: CreateElement doesn't trigger the parser 02:34:12 ... I think what Doug is saying is if you have inner html and you use a rect 02:34:19 ... you have to nest it in an SVG element 02:34:34 ed: I think we recently added inner html to SVG elements and it does use the context 02:35:02 shepazu: Currently if I put an HTML element it's treated as an SVG element 02:35:07 MikeSmith has left #svg 02:35:19 ... if we specify the HTML elements as things that go in another namespace 02:35:45 ... will there be a hack (not to be specced just to be considered) to allow developers to get what they expect in older UAs 02:36:00 ... I'll do some testing 02:36:15 ... my only concern is that specific case of what happens when there's the bare name HTML 02:36:38 shepazu: For the original question, let's specify what browsers are already doing 02:37:07 RESOLUTION: We will spec what browsers are currently doing - use SVGElement interface for unknown elements. 02:37:49 -- break until 11am -- 02:38:31 kurosawa_ has joined #svg 02:38:31 gcapiel1 has joined #svg 02:44:03 nsakai_ has joined #svg 02:54:23 myakura has joined #svg 02:58:10 gcapiel has joined #svg 03:00:48 -Huangshan 03:02:30 jun has joined #svg 03:03:59 Zakim, call huangsong 03:03:59 I am sorry, ed; I do not know a number for huangsong 03:04:20 Zakim, call huangshan 03:04:20 ok, ed; the call is being made 03:04:22 +Huangshan 03:05:01 -Huangshan 03:05:03 Zakim, room for 4? 03:05:04 ok, ed; conference Team_(svg)03:05Z scheduled with code 26631 (CONF1) for 60 minutes until 0405Z 03:05:09 Zakim, call huangshan 03:05:09 ok, ed; the call is being made 03:05:10 +Huangshan 03:05:15 ed has changed the topic to: Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda code for today is 26631 03:08:25 birtles has joined #svg 03:09:16 Zakim, code? 03:09:16 the conference code is 26632 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 03:10:00 -Huangshan 03:10:05 Zakim, call huangshan 03:10:05 ok, ed; the call is being made 03:10:07 +Huangshan 03:10:11 Zakim, code? 03:10:11 the conference code is 26632 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 03:10:26 The conf was only for 1 hour, maybe zakim doesn't want to let new people in? 03:11:34 -TabAtkins 03:11:35 Team_(svg)01:13Z has ended 03:11:35 Attendees were Huangshan, TabAtkins 03:11:44 Zakim, dial huangshan 03:11:44 ok, heycam; the call is being made 03:11:45 Team_(svg)03:05Z has now started 03:11:47 +Huangshan 03:11:49 Zakim, code? 03:11:49 the conference code is 26631 (tel:+1.617.761.6200 sip:zakim@voip.w3.org), heycam 03:12:07 +Rich_Schwerdtfeger 03:12:14 +TabAtkins 03:13:12 nikos has joined #svg 03:13:17 scribenick: birtles 03:14:44 topic: SVG accessibility 03:15:14 gcapiel: I lead engineering at Benetech 03:15:36 ... for Benetech we have a few projects were accessibility is a big projects 03:15:46 ... including bookshare 03:15:55 ... which is a very large library of accessible books 03:16:12 ... we also have a project which is in collaboration with DAISY and NCAM 03:16:23 ... we are working on "diagram center" 03:16:36 ... we are focussing on, "How do we lower the cost of creating accessible images?" 03:16:46 ... "What standards do we need to achieve that goal?" 03:17:00 ... we want accessible images in e-books and across the open web 03:17:12 ... I'm in the digital publishing group composed of people from the book publishing industry 03:17:19 ... we have some representatives around accessibility 03:17:23 ... and some w3c staff 03:17:37 ... as part of that we've been working to identify gaps in the open web platform that publishers need 03:17:42 ... I've been focussing on accessibility 03:18:04 http://www.w3.org/dpub/IG/wiki/UseCase_Directory#General_Accessibility_Use_Cases 03:18:06 ... it's tricky because you really need to accessibility for everything 03:18:12 ... not just ebooks 03:18:20 ... the link above is a set of use cases I'll walk through 03:18:32 ... the first use case is about rendering mathematics using SVG instead of MathML 03:18:38 ... MathML support is either missing or inconsistent 03:18:46 ... it's not clear when that issue will be resolve 03:18:57 ... so what publishers are doing is using images (esp. PNG and JPEG) 03:19:11 ... they do that because inexpensive devices like kindle don't support mathml at all 03:19:20 ... some of those devices don't support SVG either but some do 03:19:37 ... so we're not going to be able to get publishers to push out MathML in the near future but we can do better than bitmaps 03:19:53 ... so we've been looking at using MathJAX on the server using Node.js to convert MathML to SVG 03:20:12 ... that also lets us work with open-source technology and using ChromeBox, Google's screen reader technology 03:20:38 ... using that tool, you can feed it MathML and get back both SVG and a description of that math 03:20:53 heycam: is it a problem that Blink is dropping MathML support? 03:20:59 s/ChromeBox/ChromeVox/ 03:21:06 gcapiel: no it's not really since it's still in the DOM 03:21:12 ... even if it's not rendered 03:21:27 ... I've been thinking about how we can improve this situation and one thing we could do is add the source MathML in the SVG 03:21:37 ... that would allow screen readers to pick it up 03:22:01 q 03:22:05 q+ 03:22:07 ... the problem with the textual description is that the cognitive load of hearing it all is significant--you really need to be able to navigate the mathml 03:22:19 ... one more thing, Rich was involved in adding tabindex to SVG which is great 03:22:27 ... but I think there may be uses for that with math too 03:22:31 ... so you can navigate the tree 03:22:51 q+ 03:22:52 richardschwerdtfeger, one of the things I asked for was to have direct access to the mathml 03:23:04 ... are you suggesting embedding it in the SVG? 03:23:12 gcapiel: yes, that's what I'm suggesting 03:23:22 richardschwerdtfeger: makes sense 03:23:51 gcapiel: the last requirement I would add around that is that mathml that renders visually nicely, often doesn't have enough semantics for a screen reader 03:24:02 ... for example, you might need additional parentheses 03:24:18 heycam: is that because people generally write presentational mathml not content mathml 03:24:27 gcapiel: yes, content mathml hasn't really gone anywhere 03:24:55 ... we've been putting work into how to use crowdsourcing to improve the accessibility of existing math content 03:25:00 ... and have had a lot of success 03:25:15 ... but often they don't have access to the source or the web server 03:25:37 ... so we'd like to take an annotation approach where you can just, for example, add parentheses or overwrite the textual description 03:25:42 stakagi has joined #svg 03:25:56 ... the screen reader would notice this URI and pull down the additional annotations from the coud 03:26:17 ... so it would be great if there was a standard way for marking up those URIs 03:26:20 s/coud/cloud/ 03:26:36 wonsuk has joined #svg 03:26:40 q+ 03:26:46 heycam: I have some practical questions about how to markup MathML in the SVG spec so I might get your help on that later 03:27:04 richardschwerdtfeger: yes, of course. 03:27:15 ... aria-describedby might help with this 03:27:35 s/richardschwerdtfeger: yes,/gcapiel: yes,/ 03:27:45 richardschwerdtfeger: I could help with adding that 03:27:50 heycam: do we reference that properly yet? 03:27:54 richardschwerdtfeger: yes we do 03:29:10 ... is it a problem that ARIA 1.1 is only a FPWD? 03:29:14 heycam: I think it's fine for now 03:29:18 ACTION: Rich to reference ARIA 1.1 in SVG 2 03:29:19 Created ACTION-3537 - Reference aria 1.1 in svg 2 [on Richard Schwerdtfeger - due 2013-11-21]. 03:29:48 krit: putting presentation mathml into SVG, this should already be possible using foreignObject 03:30:01 ... with the limitation that you need to specify width/height which is not very convenient 03:30:15 ... it would be nice to allow mathml to be included directly but that would require changes to the html parser 03:30:33 heycam: might be good to keep in mind when we discuss HTML in SVG later 03:30:42 shepazu: that might just fall out of the HTML model 03:31:00 Rossen__ has joined #svg 03:31:08 heycam: I suspect that MathML names when you're parsing in SVG parsing mode will become SVG elements 03:31:23 shepazu: I wonder if that's the case since SVG elements are whitelisted 03:31:26 heycam: for case conversion 03:31:44 shepazu: in any case it's a kind of whitelisting... it bears investigation 03:32:44 krit: if we really want to move MathML names in to the SVG space... that might be a problem 03:32:53 heycam: we should consider this when we talk about HTML in SVG later 03:32:57 http://www.w3.org/dpub/IG/wiki/MathSonifyA11y and http://dl.dropboxusercontent.com/u/39156804/graph.html 03:33:01 gcapiel: I'll move onto the next use case 03:33:13 ... this concerns sonification using multi-modal delivery for SVG 03:33:29 ... I have a use case and a demo using Web Audio and Web Speec to sonify 03:33:44 ... the demo works with that specific SVG and similar ones but is not generally useful 03:33:57 ... since it needs semantic data like axes and tick marks 03:34:19 ChrisL: how do you find that data in the demo 03:34:35 shepazu: in this demo it works since the files have a consistent layout 03:34:41 ... it's something I'd like to aria 03:34:59 ... e.g. a "data-point" role or something of that ilk 03:35:12 ... it distinguishes that piece of information from the other graphics on the page 03:35:17 ... likewise for axes 03:35:30 ChrisL has joined #svg 03:35:31 heycam: how broadly do you want to look at semantics of diagrammatic content 03:35:35 ... there's quite a range 03:35:52 gcapiel: I guess it could be a wider range because not everything can be sonified 03:36:16 ... but some of this might apply to tactile output too 03:37:10 http://www.w3.org/dpub/IG/wiki/SVGStructDesc 03:37:22 gcapiel: the next use case (above) covers including HTML inside SVG 03:37:45 ... and the reason we care about that is [paused for demo] 03:38:29 (shepazu demos sonification) 03:38:41 shepazu: we want to distinguish sonification from vocalization 03:40:04 ... we can read out different values but that doesn't give the use the gist of the function 03:40:53 (demo makes sounds whose pitch varies with the y-value of the graph) 03:41:29 ... compare this to existing SVG accessibility features 03:42:01 ... there's also a Web Speech API that would read off text 03:42:13 ... so we can make it read out this chart as a list 03:42:37 ... it would be better if we could allow users to navigate around the chart 03:42:50 ... using the keyboard 03:42:59 q+ 03:43:15 q+ 03:43:36 richardschwerdtfeger: so you're looking at adding semantics to assist the textual description of the chart? 03:43:50 shepazu: yes, I don't want to boil the ocean, but for common items 03:43:54 q? 03:43:57 richardschwerdtfeger: I think I can help with this 03:43:58 ack 03:44:00 ack richardschwerdtfeger 03:44:00 masatakayakura has joined #svg 03:44:10 q- 03:44:38 ChrisL: often stuff which is for accessibility gets a boost when it also has some use in another context 03:45:31 ... this reminds me of an experiment where they sonified various properties of blood so you didn't have to switch between looking down a microscope and a chart 03:45:47 ... so it was a real benefit for sighted people as well 03:46:08 gcapiel: there is also research that you retain information better if you receive it in a multi-modal way 03:46:29 shepazu: yes, but we're not proposing adding sonification to SVG but to add the hooks for these alternative representations 03:46:38 ChrisL has joined #svg 03:46:43 heycam: and these hooks would be aria features 03:46:46 shepazu: yes 03:47:00 heycam: so then we don't need to do anything much accept allowing these new attributes 03:47:28 ChrisL: yes, you just need the hooks 03:47:29 cyril has joined #svg 03:47:55 shepazu: having the ability to markup in a commonly understood way allows easier extraction and re-use of the data 03:48:06 http://diagramcenter.org/standards-and-practices/content-model.html 03:48:13 gcapiel: now I'd like to talk about more general descriptions 03:48:19 ... this is an image and its description 03:48:30 ... it's an infographic really 03:48:42 ... it has a lot of information that would be hard to capture in an alt attribute 03:49:03 ... I guess you could use describedby but then the description might be separated from the image itself 03:49:18 ... this is where having HTML in SVG might be useful 03:49:26 heycam: how would you imagine this working? 03:49:56 shepazu: so currently the content model of is text 03:50:10 ... if that allowed markup we could have tables, lists etc. 03:50:19 ChrisL has joined #svg 03:50:47 ChrisL: putting bare-name elements inside is fine since it doesn't need positioning information etc. 03:51:02 ... seems reasonable to put bare-name HTML there 03:51:27 heycam: so I think the HTML parser already switches into allowing HTML content inside , , and <foreignObject> 03:51:34 <birtles> gcapiel: it's not in the spec though 03:51:47 <birtles> shepazu: we need to clarify in the spec and make test cases 03:51:56 <ChrisL> ChrisL has joined #svg 03:52:11 <birtles> heycam: one part is to make sure the HTML parser does the right thing and the other part is blessing that pattern in SVG 03:52:19 <birtles> ... and we only really need to do the second part 03:52:20 <richardschwerdtfeger> q+ 03:52:23 <birtles> shepazu: any objections? 03:52:36 <birtles> heycam: is that idea that you target that <desc> with an ARIA describedby 03:52:44 <birtles> richardschwerdtfeger: it's an API mapping issue more than anything 03:52:45 <ChrisL> ack ChrisL 03:53:07 <birtles> gcapiel: here's a use case: I'm a publisher and want to put some images in my text book 03:53:17 <birtles> ... I get a water cycle image from a site in SVG format 03:53:33 <birtles> ... I want the description to be packaged inside the SVG 03:53:46 <birtles> heycam: my question is more about how to refer to the <desc> 03:53:55 <birtles> ... currently <desc> applies to its parent element 03:53:59 <birtles> ... and that may or may not be appropriate 03:54:54 <richardschwerdtfeger> q+ 03:55:06 <ChrisL> ack richardschwerdtfeger 03:55:11 <birtles> ... sometimes you may want to have multiple elements targetting the same desc 03:55:33 <birtles> richardschwerdtfeger: one difficulty is you have HTML content that is not actually rendered 03:56:29 <birtles> ... I assume that stuff is in the DOM and an AT can navigate it 03:56:38 <birtles> ... a magnifier will have challenges if it's not rendered 03:56:47 <birtles> ... one way around that is to have it as an iframe 03:57:07 <birtles> ... but you want it all in the same document? 03:57:17 <birtles> shepazu: I see what you're saying but I think this is an implementation detail 03:57:20 <birtles> richardschwerdtfeger: ok 03:58:29 <birtles> RESOLUTION: <desc> should allow HTML markup and we should have tests for this and recommend this practice 03:59:09 <birtles> shepazu: we should cross-reference this when we talk about inline HTML in general 03:59:37 <birtles> ACTION: Doug to clarify HTML content in <desc> and <title> elements 03:59:37 <trackbot> Created ACTION-3538 - Clarify html content in <desc> and <title> elements [on Doug Schepers - due 2013-11-21]. 04:00:15 <birtles> heycam: I checked the HTML parsing and yes, for <title>, <desc>, and <foreignObject> parsing switches back to HTML 04:00:18 <heycam> http://www.whatwg.org/specs/web-apps/current-work/#html-integration-point 04:00:33 <gcapiel> http://www.w3.org/dpub/IG/wiki/SVGCrowdDesc 04:00:55 <birtles> gcapiel: the next use case is around post-production of descriptions 04:01:20 <birtles> ... I have an SVG in an ePUB and it has been shipped but it's not until it reaches a student that someone notices that the description is missing or incorrct 04:01:24 <ChrisL> q+ 04:01:26 <birtles> ... we want to have a way to fix that 04:01:31 <birtles> s/incorrct/incorrect/ 04:01:57 <birtles> ... the author might actually describe in the SVG a link to a point where those crowdsource improvements could be pulled in 04:02:07 <ChrisL> ChrisL has joined #svg 04:02:21 <birtles> ... after some content has been created how does someone annotate it 04:02:37 <shepazu> q+ 04:02:38 <birtles> ChrisL: so is this about forking or about having an extension point? 04:02:49 <birtles> gcapiel: the latter since there may be copyright issues 04:02:49 <heycam> q- ChrisL 04:03:02 <birtles> ChrisL: it opens up issues about an approval process 04:03:11 <birtles> ... it sounds similar to crowdsourcing captions for videos 04:03:21 <birtles> gcapiel: yes, it's similar to that which has been very successful 04:03:26 <heycam> q- shepazu 04:04:00 <birtles> shepazu: gcapiel and I talked about this and I think this is a general use case 04:04:15 <birtles> ... we might want to plug into the work going on in the open annotations world 04:04:34 <birtles> ... so perhaps you could hook your user agent into a particular open annotation framework 04:04:45 <birtles> ... so we just need the hooks 04:04:55 <birtles> gcapiel: so we need to look into whether that can be applied to SVG 04:05:05 <gcapiel> http://www.w3.org/dpub/IG/wiki/SVGMediaQueriesA11y 04:05:19 <birtles> shepazu: I spoke to the hypothesis folks and I'm confident it's possible 04:05:22 <birtles> gcapiel: here is another use case 04:05:29 <birtles> ... this SVG is very useful for a sighted user 04:05:59 <birtles> ... but a lot of the information is decorative and so if this was converted to a tactile format a lot of that information would actually obscure the information 04:06:10 <birtles> ... so currently the way this is handled is by creating a separate image 04:06:21 <birtles> ... but I'd like to make it so you could use the same format 04:06:43 <birtles> ... and going forward we might even use 3D printers for tactile output 04:06:47 <birtles> ... which might have slightly different requirements still 04:06:47 <shepazu> q+ 04:06:56 <birtles> ... so we might need media queries for this 04:07:06 <birtles> shepazu: I think this is actually a CSS questions 04:07:26 <birtles> heycam: I agree. It would be good to know if the kind of modifications you want to make can be all styled with CSS properties 04:07:46 <birtles> shepazu: I'm pretty sure they could be. e.g. hiding/displaying content, replacing a pattern with a fill etc. 04:08:08 <birtles> ... we'll look into this and come back with a proposal 04:08:20 <birtles> heycam: if there are things that can't be styled with CSS then we'll need to handle that 04:08:42 <birtles> richardschwerdtfeger: I'm editing media queries now 04:08:50 <birtles> ... just a note, we are deprecating media types nw 04:09:19 <birtles> s/richardschwerdtfeger: I'm editing/TabAtkins: I'm editing/ 04:10:23 <birtles> ACTION: Doug to work with Gerardo and Tab to come up with haptic, tactile and 3d media queries 04:10:23 <trackbot> Created ACTION-3539 - Work with gerardo and tab to come up with haptic, tactile and 3d media queries [on Doug Schepers - due 2013-11-21]. 04:10:26 <gcapiel> http://www.w3.org/dpub/IG/wiki/SVGReuse 04:10:49 <birtles> gcapiel: the final use case related to re-using the same SVG multiple times in the same page 04:10:53 <shepazu> q+ 04:10:57 <birtles> ... one idea was referencing it from an iframe 04:11:15 <birtles> ... the challenge with that is that from a useability point-of-view they are quite painful 04:11:25 <birtles> krit: can you repeat the use case 04:11:49 <birtles> gcapiel: I have an image of a basketball and it's going to appear three times on page 5, then page 8 and then in another text book 04:12:01 <birtles> ... I want to reference it as a file 04:12:16 <ChrisL> sounds like "fix the screen readers to not break on iframe" 04:12:28 <richardschwerdtfeger> q+ 04:12:32 <birtles> shepazu: you can use the <use> element for this 04:13:02 <TabAtkins> (Chrome, maybe others, don't allow external <use>, but otherwise yeah. <use> in-document is fine. <iframe> or whatever out-of-document is good.) 04:13:14 <birtles> gcapiel: we need to look at iframes for this 04:13:22 <birtles> krit: if it's a basketball and <img> is probably better 04:13:48 <birtles> richardschwerdtfeger: regarding iframes and JAWS is that we're getting to treat them basically like navs 04:14:11 <birtles> gcapiel: no that's fine. I'm just concerned about useability 04:14:28 <birtles> heycam: the seamless attribute on <iframe> might also be a hint here 04:14:43 <birtles> richardschwerdtfeger: people are using iframes more for mashups 04:14:47 <birtles> ... to isolate part of the content 04:14:57 <birtles> ... I can help work with the useability issues 04:15:04 <birtles> gcapiel: sounds good 04:16:09 <birtles> topic: z-index in SVG 04:16:15 <birtles> kurosawa_: my question is, is z-index a requirement for SVG2? 04:16:39 <birtles> heycam: I think Tab might have been assigned to this? 04:16:45 <TabAtkins> Was I? 04:16:59 <TabAtkins> Sure, okay. 04:16:59 <birtles> ... if he or somebody could start adding that to the spec before the end of the year then it will be in SVG2 04:17:13 <birtles> shepazu: is that good or bad for accessibility? 04:17:31 <birtles> kurosawa_: to make SVG content accessibility we need to care about reading order 04:17:43 <birtles> ... but SVG using forces a certain rendering order 04:18:01 <birtles> shepazu: so a z-index will allow to provide a different reading order to rendering order? 04:18:04 <birtles> kurosawa_: yes 04:18:35 <birtles> ChrisL: yes, that's right--sometimes that's how you'd do it 04:18:44 <ChrisL> ChrisL has joined #svg 04:18:46 <birtles> ... but sometimes you want to allow different reading orders 04:19:06 <birtles> ... and you wouldn't have to keep manipulate the document every time for each different reading order 04:20:10 <birtles> kurosawa_: I agree that are multiple reading orders but if we consider if I hover over some graphics and they move them to the front... we'd need to re-attach them at a different point of the document (without z-index) 04:20:28 <birtles> ChrisL: I agree that for that use case z-index is the appropriate way to do it 04:20:47 <birtles> shepazu: yes, we do want z-index in SVG2 because it also helps with accessibility 04:21:06 <birtles> topic: Using Bikeshed for SVG specs 04:21:45 <birtles> krit: I'd like to have the discussion with Peter first 04:21:50 <birtles> (deferred for now) 04:22:16 <Zakim> -Rich_Schwerdtfeger 04:23:01 <birtles> (break for lunch) 04:23:15 <Zakim> -Huangshan 04:25:15 <richardschwerdtfeger> richardschwerdtfeger has left #svg 04:28:15 <Zakim> disconnecting the lone participant, TabAtkins, in Team_(svg)03:05Z 04:28:17 <Zakim> Team_(svg)03:05Z has ended 04:28:17 <Zakim> Attendees were Huangshan, Rich_Schwerdtfeger, TabAtkins 04:29:20 <nsakai> nsakai has joined #svg 05:24:37 <nsakai> nsakai has joined #svg 05:27:18 <myakura> myakura has joined #svg 05:43:25 <stakagi> stakagi has joined #svg 05:49:30 <cyril> cyril has joined #svg 05:53:15 <dino> dino has joined #svg 05:55:59 <birtles> birtles has joined #svg 05:56:28 <krit> http://memedad.com 05:58:17 <stakagi> stakagi has joined #svg 05:58:50 <shepazu> shepazu has joined #svg 06:00:40 <kurosawa> kurosawa has joined #svg 06:01:06 <myakura> myakura has joined #svg 06:01:29 <krit> ScribeNick: krit 06:01:57 <nsakai> nsakai has joined #svg 06:02:00 <heycam> Zakim, room for 4? 06:02:01 <Zakim> ok, heycam; conference Team_(svg)06:02Z scheduled with code 26632 (CONF2) for 60 minutes until 0702Z 06:02:06 <heycam> Zakim, call huangshan 06:02:06 <Zakim> ok, heycam; the call is being made 06:02:07 <Zakim> Team_(svg)06:02Z has now started 06:02:08 <Zakim> +Huangshan 06:03:22 <krit> plinss: Shepherd has a couple of purposes 06:03:33 <krit> plinss: manager of test suite 06:03:42 <krit> heycam: yes, one part we want to use it 06:03:56 <krit> heycam: are interested in anchors 06:04:07 <krit> plinss: yes, shepherd does that as well 06:04:14 <krit> plinss: tries to clasify anchors 06:04:34 <nikos> nikos has joined #svg 06:04:36 <krit> plinss: but needs understanding what is defined and the relationship to element, attribute and values 06:04:42 <krit> plinss: in relies on markup in the spec 06:04:54 <krit> plinss: tab and I came up with different ways to do it 06:05:08 <krit> plinss: I don’t care which way, I ‘ll adapt to the spec style as well 06:05:19 <Zakim> +TabAtkins 06:05:21 <ed> topic: shepherd for svg repo 06:05:27 <krit> heycam: are there some standard rules to make it easy for us to adapt 06:05:42 <krit> plinss: there is documentation on shepherd as well 06:06:03 <TabAtkins> Documetnation: https://github.com/tabatkins/bikeshed/blob/master/docs/definitions-autolinks.md 06:06:03 <krit> heycam: we use combination of bike shed and sag pre-processor on some FX specs 06:06:10 <krit> cyril: what is bike shed? 06:06:13 <TabAtkins> (For the in-spec markup that Bikeshed recognizes.) 06:06:17 <krit> heycam: a CSS pre-processor 06:06:41 <krit> plinss: with automatic cross linking of specs based on data of shepeherd 06:06:56 <krit> plinss: bike shed calls shepherd and asks for anchors 06:07:05 <krit> plinss: and specs can link back as welll 06:07:09 <TabAtkins> krit, one word Bikeshed. 06:07:24 <krit> heycam: we have similar things in SVG pre-processor but data is in external XML file 06:07:28 <TabAtkins> s/bike shed/Bikeshed/g 06:07:50 <krit> plinss: we use Jsonx 06:08:06 <heycam> s/Jsonx/json/ 06:08:15 <krit> TabAtkins: sheperd watches changes on other specs, no need to manually update an XML file 06:08:52 <krit> heycam: if shepherd watch our specs as well would be great and having the right meta data in our specs as well 06:09:04 <TabAtkins> Bikeshed also does automatic IDL linking/defining markup, generates railroad diagrams, and a bunch of other things. 06:09:17 <krit> plinss: shepherd is watching all specs in FX already (with exception of ReSpec specs) 06:09:31 <TabAtkins> Big weakness for SVG right now is that Bikeshed doesn't know how to generate multi-page specs yet. 06:09:41 <TabAtkins> (I plan to do so, but haven't gotten to it yet.) 06:09:45 <krit> plinss: I do want to have SVG scanned daily as well, and do it already 06:10:08 <krit> cyril: shepherd is the server env that scans things? How is it related to bike shed? 06:10:23 <krit> chirs: Is checking the specs 06:10:33 <krit> s/chirs/Chris/ 06:10:37 <heycam> I sometimes wonder whether we should make SVG2 primarily a one page spec, but also to have generated multi-page version. 06:10:59 <danielkim> danielkim has joined #svg 06:11:01 <krit> Chris: you can do links by automatic cross linking between specs and tests can reference specs as well 06:11:25 <krit> Chris: [explaining some things of Bikeshed from the docs] 06:12:10 <krit> shepazu: Bikeshed does not yet support multipage steps 06:12:24 <krit> plinss: no problem for Shepherd at least 06:12:55 <krit> plinss: Shepherd can find specs where ever sections move within the spec 06:13:15 <krit> Chris: [Going crazy] 06:13:41 <krit> heycam: Is the markup sufficient in SVG spec? 06:13:56 <krit> plinss: no it is not, most of the things are not recognized at all 06:14:07 <krit> heycam: using propdef even for element and attribute defintions 06:14:18 <krit> plinss: that is bad for identifying things 06:14:32 <ChrisL> ChrisL has joined #svg 06:14:42 <krit> plinss: data-def type is a way to identify 06:14:44 <TabAtkins> <dfn attribute>foo</dfn> becomes <dfn data-dfn-type="attribute">foo</dfn> after Bikeshedding. 06:14:51 <krit> plinss: another way is a lot of short cuts 06:15:07 <krit> plinss: propdef is another one as is elementdef and attributedef 06:15:08 <TabAtkins> <div class="propdef"><dfn>foo</dfn></div> makes "foo" a property def. 06:15:27 <krit> plinss: Shepherd understands all IDL 06:16:06 <krit> krit: we can auto generate many things so we can change things easily with exception for attributes 06:16:35 <shepazu> q+ 06:16:40 <krit> TabAtkins: since propdef is used for styling purposes, there is a new class .defintion with the same purpose now 06:17:06 <krit> heycam: we want the big blue element definition tables 06:17:27 <krit> heycam: with content model and a lot more information and Shepher could use that in the future 06:17:55 <krit> plinss: they were defining elements in definition sections 06:18:07 <krit> plinss: so you could just link to the section headings 06:18:56 <krit> plinss: HTML spec does not have all id’s set correctly yet 06:19:21 <krit> shepazu: we adapted in the past already and adapting confincient the CSS WG is using makes sense... 06:19:29 <krit> shepazu: easier to maintain 06:19:53 <krit> shepazu: does SVG WG object to use convenients Shepherd is expecting? 06:20:13 <krit> ChrisL: depends.. on testing yes. Bikeshed? maybe not 06:20:40 <krit> shepazu: mean we should adapt spec styling so that Shepherd can pick things up more easily 06:20:48 <krit> ChrisL: yes, we should definitely 06:20:52 <Rossen__> Rossen__ has joined #svg 06:21:10 <ChrisL> bikeshed is fine if it could do a multi-doc spec like svg2 06:21:18 <krit> plinss: yes, Shepherd picks up tests already and don’t care about the markup as long as it is explicitly 06:21:35 <krit> shepazu: yeah, we do not care about the markup, we want things to work 06:21:45 <krit> ChrisL: and we don’t have the maintainance 06:21:58 <TabAtkins> SVG just splits up pages by chapter, right? 06:22:22 <krit> ChrisL: what is the minimal set for HTML5 so that we can adapt that? 06:22:34 <krit> plinss: I am identifying most attributes but not all elements 06:22:47 <TabAtkins> I think HTML tries to have the pages roughly balanced. 06:22:48 <SimonSapin> SimonSapin has joined #svg 06:22:57 <ChrisL> ChrisL has joined #svg 06:23:02 <ChrisL> s/adapt/auto link into/ 06:23:10 <krit> krit: you pick up attributes on HTML but not elements? what about the reference to elements from attribute? 06:23:12 <TabAtkins> <a element>filter</a>, or <a data-link-type="element">filter</a> if you're not Bikeshedding. 06:23:18 <krit> plinss: not sure if Shepherd does 06:23:20 <SimonSapin> FWIW, MDN also wants to parse spec to be notified when something changes that needs doc changes 06:23:40 <krit> shepazu: what is the best way to learn what is needed for shepherd 06:23:44 <TabAtkins> To mark up attributes for elements, <dfn attribute for="filter">x</dfn> (or whatever). 06:24:13 <krit> plinss: I can generate a document explaining it 06:24:24 <gcapiel> gcapiel has joined #svg 06:24:39 <krit> ACTION: plinss deliver document to adapt specs to Shepherd 06:24:39 <trackbot> Error finding 'plinss'. You can review and register nicknames at <http://www.w3.org/Graphics/SVG/WG/track/users>. 06:24:47 <krit> ACTION: Peter Linss deliver document to adapt specs to Shepherd 06:24:47 <trackbot> Created ACTION-3540 - Linss deliver document to adapt specs to shepherd [on Peter Sorotokin - due 2013-11-21]. 06:24:56 <ChrisL> ChrisL has joined #svg 06:25:36 <krit> plinss: so you have attribute def table, we have the same for properties but we do not analyze the table in detail 06:25:41 <krit> plinss: plan to do it 06:26:07 <krit> plinss: will be done soon and pick up values and relations automatically 06:26:26 <krit> plinss: what ever format you use, it must be machnine parable 06:26:31 <krit> parseable 06:26:49 <krit> cyril: how do you link back from specs and attributes? 06:27:08 <krit> plinss: in the past we have backinks from tests to the spec 06:27:53 <krit> krit: can we add anchor detections on tests and Shepherd will pick them up and auto link? 06:28:07 <krit> plinss: came up before, but doesn’t work right now 06:28:42 <krit> plinss: TabAtkins will probably discuss testable assertions and how Bikeshed can help in the future 06:29:33 <krit> plinss: one thing, the test suite and test suite generation is independent of Shepherd, but Shepherd is used to build it 06:30:38 <krit> ChrisL: prefer to have links to TR. If we send people to ED, then TR get irrelevant 06:31:01 <krit> plinss: Tim says we can host a TR spec somewhere else and have a link to TR form that spec 06:31:22 <krit> ChrisL: we have a rule against external script 06:31:53 <krit> plinss: all tools are open sourced, I do not care on which server they run on 06:32:28 <krit> ChrisL: [discussing publish policies of W3C] 06:33:16 <krit> topic: new SVG DOM proposal 06:33:29 <krit> heycam: want to make SVG DOM a bit saner 06:33:40 <krit> heycam: how could it be possible to opt in to this new DOM 06:33:49 <krit> heycam: otherwise existing script could break 06:33:49 <heycam> http://dev.w3.org/SVG/proposals/improving-svg-dom/ 06:34:27 <krit> heycam: to sumaries: key idea… not have SVG elements in a different NS than HTML elements 06:34:55 <krit> heycam: so we would use the NS of the element to decide to use new SVG DOM or old SVG DOM and element defintions 06:35:24 <krit> ChrisL: HTML parser parses a lot of staff. So what happens to this which adds elements ti SVG NS? 06:35:51 <krit> heycam: HTML parser would need to change to switch to new NS unless there is an foreignElment or other elements 06:36:46 <krit> s/an foreignElment or other elements/a new elements where the SVG content is used which will do the switch to the new NS/ 06:36:53 <krit> heycam: I called it graphics 06:37:13 <krit> heycam: <graphics>HTML NS of SVG elements</graphics> 06:37:38 <krit> heycam: problem is support for older UAs 06:37:56 <shepazu> q+ 06:38:00 <MichaelC> MichaelC has joined #svg 06:38:21 <krit> heycam: a new element would not help 06:38:24 <MichaelC> MichaelC has left #svg 06:38:52 <krit> krit: unless you wrap the SVG content in an extra <svg> element 06:38:55 <krit> heycam: yes 06:39:01 <ChrisL> ChrisL has joined #svg 06:39:07 <krit> krit: when we want backward compatibility then... 06:39:13 <krit> heycam: not sure if we want that 06:40:12 <krit> TAG: If I have an old school element and move it to and old school element what happens 06:40:31 <gcapiel> gcapiel has left #svg 06:40:39 <krit> TAG: what happens to import node, adapt node, appendChild and so on 06:40:50 <ed> s/adapt node/adoptNode/ 06:41:05 <ed> s/import node/importNode/ 06:41:07 <krit> heycam: most functionality would still work 06:41:22 <krit> heycam: didn’t thought about that 06:41:30 <krit> TAG: what about createElement 06:41:50 <krit> TAG: new SVGPath() which interface do I get? 06:42:00 <krit> heycam: there are no Ctors for SVG element yet 06:42:20 <krit> heycam: and createElementNS would give you old school element 06:42:50 <krit> heycam: now that they are in HTML, are they HTML*Element 06:43:11 <krit> heycam: but we can’t easily use the same interfaces if you have linking within the same document 06:44:28 <birtles> krit: so can't you just use an attribute instead? 06:44:36 <heycam> (TAG = Alex Russell) 06:44:50 <TabAtkins> Haha, I was wondering who TAG was supposed to be. 06:44:51 <birtles> heycam: well typically the prototype of an object is decided at creation time 06:45:20 <birtles> ... since you need to decide the interface of the object at object creation time 06:45:34 <birtles> ... I thought that if you document.createElement it, it can't start off with the old interface 06:45:45 <birtles> ... then you do .setAttribute and suddenly get the new interface 06:45:48 <slightlyoff> slightlyoff has joined #svg 06:46:02 <slightlyoff> OH HAI 06:46:13 <krit> s/TAG/slightlyoff/g 06:46:37 <birtles> TabAtkins: so in Custom Elements you can say what the prototype is but only at parse time 06:46:53 <birtles> heycam: do you agree that it would be weird to change the interface on a object after it start existing? 06:47:20 <birtles> slightlyoff: I think you can get there using some esoteric ways (ES6 proxies etc.) but none of them are attractive 06:47:33 <birtles> ... the downside is that in the transition period is that we double the surface area 06:47:44 <birtles> ... I'd like to find ways to reduce the surface area of the SVG DOM 06:47:56 <birtles> ... the number of interfaces created by the SVG DOM is a burden on implementations 06:48:09 <birtles> shepazu: to what extent could we trim them away from the existing DOM without harming existing content 06:48:27 <slightlyoff> heycam, sorry I wasn't in the channel before, can you link me to the proposal again? 06:48:37 <jun> jun has joined #svg 06:48:49 <krit> shepazu: q- 06:48:51 <nikos> http://dev.w3.org/SVG/proposals/improving-svg-dom/ 06:48:58 <cyril> http://dev.w3.org/SVG/proposals/improving-svg-dom/ 06:48:59 <ChrisL> ChrisL has joined #svg 06:49:06 <slightlyoff> thanks 06:49:13 <birtles> heycam: the section of reflecting attributes in the proposal gets rid of a lot of the interfaces (from the new world) 06:49:24 <birtles> shepazu: what is the goal of the proposal? 06:49:41 <birtles> ... making a new root element is an outcome not a goal 06:49:48 <birtles> heycam: right, it's not a goal, but a means to an end 06:50:07 <birtles> shepazu: I mean is putting SVG elements into the HTML namespace a goal or a means? 06:50:16 <birtles> heycam: it wasn't a goal per se 06:50:24 <birtles> shepazu: I'd like to see the goals be more explicit 06:50:35 <birtles> cyril: my experience of teaching SVG is that students gets confused by namespaces 06:50:48 <birtles> ... they are surprised that they can't create SVG elements in the same way as they can HTML elements 06:51:02 <birtles> krit: I also think namespaces introduce an implementation burden 06:51:18 <birtles> ... we should be able to assume people are just using the new DOM or the old DOM 06:51:33 <birtles> heycam: I'd love to drop the old DOM but unfortunately we can't given existing usage 06:51:55 <birtles> krit: what if we keep the existing naming, interfaces etc. and remove just the namespace requirement 06:52:03 <birtles> ... i.e. SVGElement inherits from HTMLElement 06:52:23 <birtles> heycam: my proposal includes SVGElement inheriting from HTMLElement 06:52:34 <slightlyoff> heycam, this proposal looks very good overall 06:53:26 <birtles> ChrisL: I don't think the goal is necessarily to move SVG elements into the HTML namespace as much as helping namespaces fade away 06:53:52 <birtles> ... but Dirk, how do you propose we fix existing problems such as getting rid of animVal 06:54:02 <ChrisL> the proposals for reflecting values and getting rid of animval and baseval is valuable 06:54:09 <birtles> krit: I don't think we can get rid of those now 06:54:52 <birtles> dino: but we should take the view that the future is bigger that the past so we should fix it now 06:55:19 <birtles> slightlyoff: I also agree that these old interfaces are creating drag that stops SVG from developing 06:55:59 <birtles> krit: but there are existing libraries like raphael and snap that rely on the current SVG DOM 06:56:04 <birtles> ChrisL: I don't see any removal of functionality... just expressing it in a different way 06:56:23 <birtles> krit: so what do you suggest? 06:56:32 <birtles> heycam: the proposal doesn't remove the old DOM 06:56:50 <birtles> ... there is duplication, but I think that's the only way we can move forward without breaking other content 06:57:16 <birtles> ChrisL: so this would double the footprint for SVG but then we hope the old footprint would fade away quickly 06:57:31 <birtles> shepazu: in terms of footprint... you have these reflectors in there 06:58:04 <birtles> ... is it possible they reduce the footprint of the new DOM by aliasing etc. 06:58:50 <birtles> slightlyoff: this is the Web, we have a transition period, add a suitable carrot for the new version then use data to determine when switch off the old version 06:59:03 <birtles> shepazu: I'm just wondering how we can reduce the footprint 06:59:12 <ChrisL> ChrisL has joined #svg 06:59:27 <birtles> slightlyoff: there are things you can do like turn off some of the optimizations from the old DOM as an incentive to move to the new DOM 06:59:33 <ChrisL> ChrisL has joined #svg 06:59:50 <birtles> heycam: Doug, you don't need two implementations, you can re-use code 07:00:16 <birtles> krit: can we remove the liveness of animVal? 07:00:25 <ChrisL> ChrisL has joined #svg 07:00:33 <birtles> ... i.e. make it an alias for baseVal 07:00:53 <birtles> ... that would be a big saving 07:01:25 <ChrisL> ChrisL has joined #svg 07:01:44 <birtles> heycam: we can probably discuss that separately 07:02:25 <ChrisL> ChrisL has joined #svg 07:02:32 <birtles> ... the basic strategy I've applied to these members is to expose attributes as strings... 07:02:43 <birtles> ... we have, for example, the polygon element that has a list of points 07:02:58 <birtles> ... in the old SVG DOM we have a live list of points you can manipulate 07:03:09 <birtles> ... in the new SVG DOM we have a pair of methods to set and get an array 07:03:21 <birtles> ... that makes it slightly more awkward to use 07:03:32 <birtles> ... if you just want to change one point, say, for animation, you have to set the whole thing 07:03:42 <birtles> ... but what do you think Alex? 07:03:51 <birtles> slightlyoff: lists in javascript are currently particularly painful 07:04:04 <birtles> ... in the post-ES6 world things might get easier 07:04:22 <birtles> ... currently you might use a proxying approach which is basically what the old DOM does 07:04:38 <birtles> ... but my suggestion for the time being is to do whatever is closest to current javascript which is arrays 07:04:53 <birtles> heycam: what will things look like in the distant future? 07:05:23 <birtles> slightlyoff: it's end-of-turn... I assume you're not doing synchronous layout? 07:05:36 <birtles> heycam: actually if you update stuff and do getBBox then I think you will get the updated result 07:05:52 <birtles> slightlyoff: that's problematic, we should try to fix that 07:06:06 <birtles> ... we should try to avoid that 07:06:25 <birtles> heycam: at least in SVG it's more contained since you don't have reflow, just absolutely positioned elements 07:06:37 <birtles> krit: can we take on some parts of the proposal 07:06:45 <birtles> ... the most important part is that we don't have many namespaces 07:06:53 <birtles> heycam: I agree, but I don't think we can do it separately 07:07:15 <birtles> ... since otherwise you'll have SVG elements in the HTML namespace with the old DOM then we could never change it 07:07:28 <birtles> ... so it would poison our ability to change things 07:07:46 <birtles> krit: I don't think the swapping works 07:08:17 <birtles> ... it's a huge mess... you add more code and it's unlikely that you can ever remove the old code 07:09:02 <birtles> slightlyoff: if you say "unlikely" then you're talking about probabilities--we can set it up so these features "could possibly" be removed or "can never" be removed 07:09:23 <TabAtkins> I suspect that, given replacements and aggressive metrics, we could trim out a bunch of the legacy right now. Not all, but a bunch. 07:09:44 <birtles> krit: I think we should change the namespace as a first step and then we fix things progressively in the future in a backwards compatible way 07:10:09 <birtles> slightlyoff, ChrisL: I don't think that gets you a lot 07:10:17 <birtles> slightlyoff: it means you have to keep the old interfaces forever 07:10:45 <birtles> heycam: I don't want to do things slowly, I want to add the new features at once 07:11:00 <birtles> krit: if we switch the namespace now what can you *not* do in the future? 07:11:13 <birtles> heycam: you can't use the namespace as the switch for opting into the new DOM 07:11:45 <birtles> krit: everything you want to add to the new DOM, you can detect this stuff 07:12:00 <birtles> slightlyoff: how does that work? 07:12:25 <birtles> ... this makes compatibility more difficult since you have to detect this stuff 07:12:30 <myakura> myakura has joined #svg 07:12:49 <birtles> ... I don't think we should give weight to implementation issues here 07:12:59 <birtles> TabAtkins: I think we could trim out a lot of stuff already 07:13:07 <ChrisL> ChrisL has joined #svg 07:13:13 <birtles> ChrisL: we're focussing too much on the impact on implementors 07:13:24 <birtles> ... we should focus more on authors and this proposal makes it easier for authors 07:13:44 <birtles> ... one way to introduce this is to say that all the new SVG2 stuff only works in this new method 07:13:55 <birtles> ... as an incentive to switch to this 07:14:06 <TabAtkins> +1 to carrot 07:14:10 <birtles> heycam: e.g. a method to get the stroke bounding box etc. 07:14:17 <shepazu> q+ 07:14:29 <TabAtkins> Old DOM freezes on the current set, and shrinks as metrics show we can kill things. 07:14:35 <birtles> ... krit, what do you think is the problem with this? 07:14:44 <TabAtkins> New DOM is better, and grows with new abilities as we think of them. 07:14:45 <birtles> krit: I think we'll never be able to get rid of the old interfaces 07:14:59 <birtles> ... it will be 10 years before we can start removing things 07:15:08 <ChrisL> ChrisL has joined #svg 07:15:20 <birtles> ... it will take 2~3 years until it is implemented properly 07:15:29 <ChrisL> ChrisL has joined #svg 07:15:47 <birtles> ChrisL: but you were saying we drop animVal? 07:15:54 <birtles> krit: it's not being used 07:16:03 <birtles> ChrisL: it is 07:16:32 <birtles> shepazu: there was a small but active community of SVG developers from 1999-2006 07:16:43 <TabAtkins> shepazu: Maybe 12 or so. 07:16:48 <birtles> ... (more background) 07:18:57 <birtles> ... there is lot of content out there that may not even work due to namespace issues 07:19:26 <birtles> ... in any case, I think we need to involve the community in this decision 07:19:34 <birtles> ... people like maintainers of script libraries 07:20:15 <birtles> krit: I don't think many people have reviewed it yet 07:20:39 <birtles> heycam: I just want to know (a) if I should keep driving this, and (b) what sort of timeframe? 07:20:48 <birtles> shepazu: I'm still uncomfortable about changing the root element 07:20:57 <birtles> ... it introduces confusion about what you should be doing 07:21:02 <birtles> ... there are definite risks 07:21:09 <birtles> ... but that may be ok 07:21:16 <birtles> ... I'd like to be explicit about the goals 07:21:46 <birtles> heycam: the 1.5 goals are, 1) changing to the reflecting of attributes, 1.5) changing namespaces 07:21:59 <birtles> ... the change of namespaces just happened to be a good way of opting into the new DOM 07:22:04 <birtles> ... the new root element is not a goal, just a means 07:22:13 <birtles> cyril: the goal to change the reflecting of attributes 07:22:29 <birtles> ... is it to make writing SVG easier? or reduce code size in implementations? 07:22:35 <birtles> heycam: for useability for authors 07:22:53 <birtles> krit: "is this something important enough for SVG 2?" is a good question 07:23:00 <birtles> ... is it worth delaying SVG 2 for? 07:23:27 <birtles> dino: if we delay it, it will only make the decision harder 07:23:30 <birtles> ... there will be more content to break 07:23:36 <ChrisL> ChrisL has joined #svg 07:23:49 <birtles> ChrisL: and by bringing forward the namespace change you'd remove one of the drivers for switching 07:23:57 <birtles> krit: so, should it be in SVG2? 07:24:03 <birtles> heycam: I feel like it should 07:24:33 <birtles> ChrisL: I don't think we could do this in SVG3 07:24:41 <birtles> krit: in which case we should prioritize this work 07:25:17 <birtles> ... we should focus on the details at the next F2F 07:25:43 <birtles> slightlyoff: I'd like to help set up a process for you all to talk to major library authors and get their input 07:25:46 <myakura> myakura has joined #svg 07:26:10 <birtles> ... are these meetings to do design work or just making decisions? 07:26:17 <birtles> heycam: we do both 07:26:30 <birtles> ... this is the first f2f where I've brought up the proposal 07:26:41 <birtles> ... so we could dedicate more time to it at the next f2f 07:26:49 <birtles> ChrisL: I think we can get new data before then 07:26:59 <birtles> krit: I think we should delay LC anyway 07:27:09 <birtles> heycam: I think January was a bit optimistic anyway 07:27:12 <birtles> ... but we will discuss that later 07:27:21 <birtles> krit: how do we reach out to developers from here 07:27:28 <birtles> heycam: I haven't really announced it yet 07:28:09 <birtles> shepazu: for svg developers there's the d3 list, svg-developers, we can tweet, etc. 07:29:14 <birtles> krit: if we want people to read the proposal I think we could rework it to make it easier to follow 07:29:27 <birtles> shepazu: does your document talk about the problems with the existing DOM? 07:29:37 <birtles> ... I think we should add that 07:31:34 <birtles> heycam: is there anything else to cover? 07:32:37 <dholbert> dholbert has joined #svg 07:32:46 <birtles> topic: SVGAnimatedBoolean 07:32:54 <birtles> ed: it's only used in one place 07:33:05 <birtles> krit: I doubt anyone uses it 07:33:16 <birtles> heycam: was externalResourcesRequired the only other use? 07:33:26 <birtles> ed: yes 07:33:31 <birtles> ... so can we remove it? 07:33:41 <birtles> ChrisL: let's remove it 07:34:19 <ChrisL> getAttr still works 07:35:09 <birtles> RESOLUTION: We will remove SVGAnimatedBoolean and SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM 07:35:50 <birtles> ACTION: Dirk to remove SVGAnimatedBoolean and SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM 07:35:50 <trackbot> Created ACTION-3541 - Remove svganimatedboolean and svgfeconvolvematrixelement.preservealpha from the svg2 dom [on Dirk Schulze - due 2013-11-21]. 07:36:42 <birtles> slightlyoff: I'll talk to Google folk about how they transitioned from the old DART DOM to the new DOM to get their advice 07:36:45 <ed> -- break time -- 07:36:48 <TabAtkins> Yay! 07:42:53 <Zakim> -Huangshan 07:44:24 <ChrisL> ChrisL has joined #svg 07:45:24 <ChrisL> ChrisL has joined #svg 07:47:54 <Zakim> disconnecting the lone participant, TabAtkins, in Team_(svg)06:02Z 07:47:55 <Zakim> Team_(svg)06:02Z has ended 07:47:55 <Zakim> Attendees were Huangshan, TabAtkins 07:48:03 <ChrisL> ChrisL has joined #svg 07:55:25 <ChrisL> ChrisL has joined #svg 08:06:21 <nsakai> nsakai has joined #svg 08:06:48 <heycam> Zakim, room for 4? 08:06:49 <Zakim> ok, heycam; conference Team_(svg)08:06Z scheduled with code 26632 (CONF2) for 60 minutes until 0906Z 08:06:58 <ed> ed has changed the topic to: Agenda: http://www.w3.org/Graphics/SVG/WG/wiki/F2F/TPAC_2013/Agenda code for today is 26632 08:06:58 <heycam> Zakim, call Huangshan 08:06:58 <Zakim> ok, heycam; the call is being made 08:06:59 <Zakim> Team_(svg)08:06Z has now started 08:07:01 <Zakim> +Huangshan 08:07:28 <kurosawa> kurosawa has joined #svg 08:08:01 <heycam> Scribe: Cameron 08:08:07 <heycam> ScribeNick: heycam 08:08:20 <heycam> Topic: SVG DOM continued 08:08:34 <jun> jun has joined #svg 08:08:39 <heycam> krit: any new SVG DOM should not have any reference to x/y/width/r/rx/ry/cx/cy 08:08:43 <heycam> ChrisL: because? 08:08:56 <heycam> krit: because they'll get presentation attributes, and it doesn't make sense to have a second way to access them, apart from the CSS OM 08:09:09 <heycam> heycam: I really want to do rect.x = 10 08:09:22 <heycam> ed: I'd like to be able to assign a full rectangle in one go 08:09:28 <heycam> ChrisL: rect.xywh = ... 08:09:39 <heycam> krit: happy if SVG WG to prioritise the DOM for SVG 2 08:09:42 <heycam> ... like heycam's proposal 08:09:45 <heycam> ... but up to the WG 08:10:16 <Zakim> +TabAtkins 08:10:28 <heycam> s/to prioritise the DOM/to ask the CSS WG to prioritise the CSSOM/ 08:10:37 <ChrisL> ChrisL has joined #svg 08:11:03 <heycam> Topic: SVGElement implementing global event handlers (onfoo) 08:11:06 <heycam> ed: should these be on Element? 08:11:07 <ed> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-October/040980.html 08:11:08 <ChrisL> ChrisL has joined #svg 08:11:26 <heycam> ed: I think in Blink recently there was some code reshuffling 08:11:35 <heycam> ... it was discovered that SVG elements did not have the global event handlers like HTML does 08:11:46 <heycam> ... so you couldn't do rectElement.onload = ... and have that assign a function 08:11:49 <nikos_> nikos_ has joined #svg 08:11:52 <heycam> ... so this is something that most SVG authors would like to have 08:12:01 <heycam> ... and the way it works in browsers, even if the SVG spec doesn't require it 08:12:07 <nikos_> nikos_ has left #svg 08:12:11 <heycam> ... I think we should have this in the spec 08:12:32 <heycam> ... in this thread, further down, we have feedback from Hixie saying we can't really put this on Element, as it would affect any XML dialect 08:12:39 <heycam> krit: and that would be bad? 08:12:40 <heycam> ed: yes 08:12:44 <heycam> ... but having it on SVGElement would be fine 08:13:06 <heycam> heycam: are all HTML event listener attributes defined on HTMLElement? 08:13:10 <heycam> ed: yes, apart from special things with <body> 08:13:17 <heycam> ... this is the way Gecko already does it 08:13:27 <maltman> maltman has joined #svg 08:13:28 <heycam> ed: it does mean we have some additional events supported automatically 08:13:35 <heycam> ... things which we don't require in SVG at the moment 08:14:28 <heycam> heycam: what if one day SVGElement inherits from HTMLElement? 08:14:35 <heycam> ed: we could still make both implement GlobalEventHandlers 08:15:08 <heycam> heycam: if we do have SVGElement inherit from HTMLElement one day, we can just remove the duplicated ones on SVGElement 08:15:23 <heycam> ed: any objections to this? : 08:15:29 <heycam> SVGElement implements GlobalEventHandlers; 08:15:46 <heycam> ... I think Cameron has an action already relating to this 08:16:01 <heycam> heycam: does SVG have onzoom or something that isn't in HTML? 08:16:08 <heycam> ed: a few, yes... not sure if that already works on an HTMLElement 08:16:16 <ChrisL> ChrisL has joined #svg 08:16:38 <heycam> heycam: if they aren't on GlobalEventHandlers, should they be? 08:16:39 <heycam> ed: yes 08:17:24 <TabAtkins> Ah, there's someone's voice. 08:17:39 <heycam> birtles: on HTMLElement, you have onfocus, but SVG has onfocusin/onfocusout 08:17:42 <heycam> ... is there some mismatch? 08:17:45 <heycam> Takagi-san noticed this 08:17:54 <heycam> TabAtkins: in HTML the focusout event is called blur 08:18:02 <heycam> ed: which already works in all browsers 08:18:13 <heycam> birtles: so would we end up with onfocusin/onfocusout/onfocus/onblur? 08:18:32 <heycam> heycam: how much do we really need to keep onfocusin/onfocusout? 08:18:41 <heycam> ed: we have a later topic on removing some SVG-specific events, discuss it then? 08:19:15 <heycam> heycam: is Ian alright with having any SVG specific ones on GlobalEventHandlers? 08:19:16 <heycam> ed: yes 08:19:35 <heycam> s/yes/I haven't asked him that/ 08:19:43 <dino_> dino_ has joined #svg 08:20:15 <TabAtkins> But, probably, yes. 08:20:18 <heycam> ACTION: Erik to ask in the thread about whether SVG specific event handlers should go on GlobalEventHandlers, or separately on SVGElement 08:20:18 <trackbot> Created ACTION-3542 - Ask in the thread about whether svg specific event handlers should go on globaleventhandlers, or separately on svgelement [on Erik Dahlström - due 2013-11-21]. 08:20:46 <heycam> RESOLUTION: We will have "SVGElement implements GlobalEventHandlers" in SVG2's IDL. 08:21:12 <heycam> ACTION: Erik to make SVGElement implement GlobalEventHandlers in SVG2. 08:21:12 <trackbot> Created ACTION-3543 - Make svgelement implement globaleventhandlers in svg2. [on Erik Dahlström - due 2013-11-21]. 08:21:37 <heycam> Topic: Is it future-proof to return SVGElement on nearestViewportElement and farthestViewportElement? 08:22:08 <krit> https://svgwg.org/svg2-draft/types.html#__svg__SVGGraphicsElement__farthestViewportElement 08:22:17 <heycam> krit: I have a question about these two 08:22:29 <heycam> ... farthestViewportElement, isn't that always SVGSVGElement? can we just use that? 08:22:37 <heycam> ... it's true, today at least 08:22:39 <Rossen__> Rossen__ has joined #svg 08:22:52 <heycam> ... is is true in the future? if we should ever allow SVGCircleElement to be an HTMLElement, what should it return? 08:23:08 <heycam> ... my question is should we rather replace SVGElement with just Element? 08:23:18 <heycam> ... or in this case, should it return null as in some other cases? 08:23:22 <ChrisL> ChrisL has joined #svg 08:23:44 <heycam> heycam: is this when you have say a <circle> with no ancestor <svg>? 08:23:49 <heycam> krit: I guess we return null currently 08:24:24 <heycam> heycam: I am ok with it being Element; the spec will still say what objects get returned 08:24:34 <heycam> ... we still would return null from <circle> when there is no ancestor <svg> 08:24:52 <heycam> RESOLUTION: We will make nearestViewportElement / furthestViewportElement be Elements, not SVGElement 08:25:27 <heycam> ed: I've rarely seen these used, could we not just remove them? 08:25:45 <heycam> krit: add UseCounters and see if we can remove it? 08:25:50 <heycam> ed: sure 08:26:04 <kurosawa_> kurosawa_ has joined #svg 08:26:12 <heycam> ACTION: Erik to add use counters to see if nearestViewportElement/furthestViewportElement are used 08:26:12 <trackbot> Created ACTION-3544 - Add use counters to see if nearestviewportelement/furthestviewportelement are used [on Erik Dahlström - due 2013-11-21]. 08:26:36 <heycam> ACTION: Dirk to change nearestViewportElement/furthestViewportElement to be Element 08:26:36 <trackbot> Created ACTION-3545 - Change nearestviewportelement/furthestviewportelement to be element [on Dirk Schulze - due 2013-11-21]. 08:26:56 <heycam> Topic: Animation Elements 08:27:10 <heycam> birtles: you all know about Web Animations, the model for animations and an API on top of that model 08:27:23 <heycam> ... the intention is to define CSS Animations/Transitions and SVG's animation features in terms of that model 08:27:43 <birtles> http://dev.w3.org/fxtf/web-animations/animation-elements.html 08:27:44 <heycam> ... so Animation Elements is what I've called the spec where I've started to describe how SVG animation features can be implemented in terms of the Web Animations model 08:27:56 <heycam> ... skeleton document I've made 08:28:09 <heycam> ... the only parts I've filled in are some use cases at the top, and describing how it relates to SVG 1.1 08:28:15 <heycam> ... and also some other specifications 08:28:32 <heycam> ... I can introduce briefly some of the changes, but today I just want to decide on is whether it's OK to work on this as an SVG Working Group work item 08:28:37 <heycam> ... it's an Unofficial Draft at the moment 08:28:48 <heycam> ... if you're OK with me working on this as an Editor's Draft, I'd like to decide on that 08:29:20 <heycam> cyril: does it cover the timing model and the animation model, or just the animation model? 08:29:31 <heycam> birtles: the 1st requirement of this is that it's backwards compatible with SVG 1.1's animation support 08:29:36 <heycam> ... so yes, it has to cover both of those things 08:29:45 <heycam> shepazu: to what extent is it backwards compatibel? 08:29:50 <heycam> ... you've documented the bits that aren't going to be? 08:30:09 <heycam> birtles: there are three exceptions, marked at the start of section 1.2, regarding backwards compatibility 08:30:18 <heycam> ... crazy frozen to-animation that nobody implemented won't be in here 08:30:39 <heycam> ... second point, I want to rewrite how cycles in syncbase dependencies are resolved, as these are implemented inconsistently 08:30:57 <heycam> ... might be some minor changes as to how that works, but I don't think people rely on the details 08:31:06 <heycam> ... third is animateColor -- waiting on use counters to see whether people use this 08:31:11 <heycam> ... and drop it if not 08:31:17 <heycam> cyril: is the shim you have already supporting this? 08:31:18 <heycam> birtles: no 08:31:22 <heycam> ... there's no shim for this markup 08:31:30 <heycam> ... there's fakeSmil, but that's the existing featureset 08:31:36 <heycam> ... you can see there's a list of new features 08:31:47 <heycam> ... some of them are exposing things which are already in the Web Animations model as markup 08:31:59 <heycam> ... there's also the <discard> element, which was in SVG 2 but I think it belongs in this specification instead 08:32:09 <heycam> ... timelineStart="" as well 08:32:23 <heycam> ... most of the new things are requirements we had for SVG 2, and I put them in this spec 08:32:46 <heycam> shepazu: for every feature of element-based SVG animation, there will be an equivalent API/model aspect? and possibly CSS syntax? 08:32:48 <heycam> birtles: roughly 08:32:53 <heycam> ... there are some things which only appear in one form 08:33:01 <heycam> ... e.g. timing groups, we don't know how yet to express that with CSS syntax 08:33:14 <heycam> ... likely that will be in the model, exposed here in element markup, but not exposed in CSS syntax, at least initially 08:33:22 <heycam> ... you don't get the full feature set across both syntaxes 08:33:34 <heycam> shepazu: one of my frustrations with SVG animation syntax was the lack of reusability 08:33:47 <heycam> ... the same animation for multiple elements, I had to repeat the animation 08:33:53 <heycam> ... is this now possible with element syntax? 08:34:00 <heycam> birtles: yes, you can use the select="" attribute to target multiple elmeents 08:34:14 <heycam> ... some examples in the use cases -- frame based animation use case, you can see that uses select="" to match on a class name, and repeat the animation 08:34:33 <heycam> ... it's also possible to define the animation with markup, and then with script to instantiate it on a different element, to say play this animation targetting a different element 08:34:38 <heycam> cyril: so you can put an animation in a defs? 08:34:42 <heycam> birtles: yes 08:34:45 <heycam> shepazu: that's great 08:35:15 <heycam> ... if I'm animating something with the element syntax, the CSS syntax and the script, what happens? 08:35:24 <heycam> ... I assume you have some order of priorities? 08:35:30 <heycam> birtles: that ordering is covered in the Web Animations model 08:35:45 <heycam> ... there are priorities based firstly on start time, but also on document order, and facilities for changing the priotity too 08:35:45 <ed> minor nit, "timelineStart" was actually called "timelineBegin" in SVG Tiny 1.2, was the change of name intentional? http://www.w3.org/TR/SVGTiny12/struct.html#SVGElementTimelineBegin 08:35:47 <heycam> ... but it is well defined 08:36:07 <heycam> birtles: that's an advantage to having a unified animation model 08:36:14 <heycam> ChrisL: but before it was undefined 08:36:37 <heycam> birtles: re timelineStart, that wasn't intentional 08:36:55 <heycam> krit: can I see a WD? 08:37:03 <heycam> birtles: I want permission to do that yes 08:37:24 <ChrisL> ChrisL has joined #svg 08:37:59 <heycam> dino: I enthusiastically support this 08:38:07 <heycam> ... I'm glad Brian is doing this 08:38:12 <heycam> ... wanted something like this for 18 months 08:38:26 <heycam> ... Apple is going to propose something like this in a few weeks anyway, so this is great 08:38:43 <heycam> ChrisL: MS said they wouldn't implement either of these, before there was a consistent model explaining how it works together 08:39:22 <heycam> dino: I have comments on the content, but i'll wait until the document exists 08:39:22 <ChrisL> ChrisL has joined #svg 08:39:46 <heycam> ... one is one of the first things people will do with this, is still write much their animation in CSS -- their keyframes, animation parameters 08:39:55 <heycam> ... and just use this as a way to do declarative timing separate from the animation 08:40:06 <heycam> ... in most cases you won't use <animate> elements, but toggling classes at particular times, or in response to particular events 08:40:35 <heycam> ... I said to Brian: it would be nice if the example using <set> on class="", we could have declarative forms of the class-list API; add class, remove class 08:40:54 <heycam> ... something not covered here, should we define a MIME type for a document like this? <link rel=stylesheet> 08:41:08 <heycam> ... you will want this inline in some cases, so in the document you could have a <timesheet> element in HTML 08:41:20 <heycam> ... adding elements to the <head> is difficult, but this could be in the <body> as well 08:41:23 <ChrisL> ChrisL has joined #svg 08:41:35 <heycam> birtles: one reason I called it Animation Elements, is it doesn't have to be just for SVG, but these kinds of use cases too 08:41:53 <heycam> shepazu: what namespace should they be in? 08:42:05 <heycam> birtles: I'd like to see what happens with Cameron's proposal 08:42:13 <heycam> dino: I want these to apply to HTML too, so the namespace doesn't matter 08:42:26 <ChrisL> ChrisL has joined #svg 08:42:30 <heycam> dino: it should follow HTML-like parsing rules as much as possible 08:42:42 <ChrisL> ChrisL has joined #svg 08:43:00 <heycam> birtles: perhaps for each element, we need to define the content model so that it can be used in either parsing mode? 08:43:26 <ChrisL> ChrisL has joined #svg 08:43:54 <heycam> heycam: it's difficult to add new empty elements in HTML, which don't have closing tags 08:44:08 <heycam> shepazu: we should consider how we can expose animations in an accessible way 08:44:21 <heycam> dino: I think this is the great thing about having the model, you can get at the animations 08:44:26 <ChrisL> ChrisL has joined #svg 08:44:27 <heycam> shepazu: I was thinking more of having a <title> for the animation 08:44:39 <ChrisL> ChrisL has joined #svg 08:44:55 <heycam> krit: there might already be a document describing accessibility of SMIL 08:45:09 <heycam> cyril: I had another comment 08:45:17 <heycam> ... one of the next steps is to synchronise animations with media elements 08:45:19 <heycam> birtles: yes 08:45:24 <heycam> cyril: that's something I'm trying to work on 08:45:25 <ChrisL> ChrisL has joined #svg 08:45:31 <heycam> ... the next topic is Streaming, and it's somehow related 08:45:34 <heycam> birtles: I think that's a common question 08:45:49 <heycam> ... just to reiterate the status there, we have left synchronisation with media out of the first level of Web Animations 08:45:54 <heycam> ... just in the interest of progressing it more quickly 08:45:59 <heycam> ... it's definitely intended to be part of that model 08:46:08 <heycam> ... we already have an idea of how it should work, and a polyfill to demonstrate that 08:46:24 <heycam> ... the current thinking is that we'll write a separate document just for that feature, to say to integrate media with the model 08:46:26 <ChrisL> ChrisL has joined #svg 08:46:26 <heycam> ... and the markup for it 08:46:34 <heycam> ... I think Cyril and Dean have shown some interest on working on that before 08:46:42 <heycam> ChrisL: how do you expect that to work? event based? 08:46:51 <heycam> birtles: you'd have another kind of timed item, which is a reference to the media element 08:47:06 <heycam> ... the <video> element needs to be in a particular part of the document for layout purposes 08:47:17 <heycam> ... you would set the timing parameters on the pointer object, and it would trigger the <video> as appropriate 08:47:31 <heycam> cyril: two aspects, controlling the media element, and using the media element to control the timing of other things 08:47:44 <heycam> birtles: wrt Web Animations, we only support the former, where the media is slaved to the timing groups 08:48:02 <heycam> ... but for the reverse, where you put the animations inside the media, I think the Streams stuff you've been working on is the way to approach that 08:48:21 <heycam> dino: are you saying you don't intend to have animations slaved to media unless they're inline in the media? 08:48:25 <ChrisL> ChrisL has joined #svg 08:48:40 <heycam> birtles: when you seek the video, you don't have the animations follow; rather you put them both in the group, and you seek the group 08:48:47 <heycam> birtles: if you need it the other way around, I suggest the Streaming approach 08:48:51 <heycam> dino: that use case is very important to us 08:48:59 <heycam> ... if the answer is put it in a group and seek the group, we can do that 08:49:08 <heycam> cyril: where's the right forum to work on this spec? 08:49:11 <heycam> ... FXTF? SVGWG? 08:49:29 <heycam> ChrisL: I think FX is an obvious home 08:49:43 <heycam> ChrisL: LC or before is a good time to get other people involved in reviewing it 08:50:20 <heycam> RESOLUTION: We will take on Animation Elements as an official WD. 08:50:37 <heycam> cyril: we talked about this in the past, the dur="" attribute, does the model cover that? 08:50:41 <heycam> ... on an SVG document? 08:50:46 <heycam> birtles: why on a document, not on a group? 08:50:50 <heycam> cyril: if you want to loop the document? 08:50:57 <heycam> birtles: you'd put it on a group 08:51:06 <heycam> s/a group/the root/ 08:51:13 <heycam> birtles: every outermost SVG element will act as a nested timeline 08:51:17 <heycam> ... it's like a simple group 08:51:20 <heycam> ... you can't repeat it, but you can seek it 08:51:21 <ChrisL> ChrisL has joined #svg 08:51:24 <heycam> cyril: can you put a dur on that? 08:51:25 <heycam> birtles: no 08:51:33 <heycam> ... just put a group around everything you want to repeat 08:51:56 <heycam> ChrisL: could you just construct groups as you want and point them to items to repeat them? 08:51:58 <heycam> birtles: yes 08:52:09 <heycam> ... in the use cases, typically I found it was easier to separate out the timing from the content 08:52:17 <heycam> ... only simple cases can you put them side-by-side 08:54:59 <heycam> Topic: SVG streaming update 08:55:04 <heycam> cyril: we have three types of animations 08:55:14 <heycam> ... [cyril reads out the slides] 08:55:37 <cyril> http://concolato.wp.mines-telecom.fr/2013/10/24/streaming-of-svg-animations-on-the-web/ 08:59:51 <kurosawa> kurosawa has left #svg 09:01:35 <heycam> cyril: I'd like to be able to use SVG in <video> and in <track> 09:01:49 <heycam> ... I implemented this with a shim 09:02:31 <ChrisL> ChrisL has joined #svg 09:03:55 <heycam> krit: regarding the same origin restrictions, what do you want to reference? svg documents? 09:04:07 <heycam> cyril: I think the same restrictions should apply as images 09:08:23 <heycam> RRSAgent, pointer 09:08:23 <RRSAgent> See http://www.w3.org/2013/11/14-svg-irc#T09-08-23 09:10:47 <Jirka> Jirka has joined #svg 09:24:42 <heycam> cyril: so what is needed for standardisation is: 09:24:45 <heycam> ... first, the guideline document 09:24:51 <heycam> ... support for SVG in the video and track elements 09:25:06 <heycam> ... and support for annotations either in the SVG document, or outside it, to give information about the streaming units 09:25:30 <heycam> ... we have everything else that we need from SVG, CSS, etc. 09:25:41 <heycam> ... the generation tool is open source 09:25:49 <heycam> ... the players aren't yet, but only because they're badly implemented 09:25:52 <heycam> ... I'll put them on GitHub soon 09:26:08 <heycam> krit: I don't have anything against working on that in the WG, but we might not have the expertise here 09:26:19 <heycam> cyril: first step is to apply it to SVG, since SVG works well, has a timeline per document 09:26:21 <heycam> ... HTML doesn't 09:26:40 <heycam> birtles: Web Animations defines a timeline per HTML document 09:26:51 <heycam> cyril: maybe the Guidelines for Streaming SVG is good for this WG though 09:27:12 <heycam> krit: I don't want to push the spec out of this WG, but it sounds like you need expertise from other people 09:27:20 <heycam> cyril: tomorrow we have a session on WebVTT, I hope to present at that 09:27:35 <heycam> ... the HTML Media TF has a lot of activity atm 09:27:49 <heycam> shepazu: I personally like to see this work go forward 09:27:59 <masatakayakura> masatakayakura has joined #svg 09:27:59 <heycam> ... I think Dirk raises good points about who needs to be involved 09:29:12 <myakura_> myakura_ has joined #svg 09:29:27 <heycam> heycam: for identifying the chunks in the document, can you just use IDs? 09:29:44 <heycam> cyril: when the client uses an ID, someone needs to convert that to a byte range 09:29:54 <heycam> ... in my case, I didn't do any server side processing to determine the byte range 09:30:14 <heycam> ... when it's packaged in WebVTT or MP4 you don't have this problem 09:30:56 <heycam> mohamed: what about if we want to use svgz? 09:31:06 <heycam> ... then the byte offsets changed 09:31:09 <heycam> cyril: I'm using Content-Encoding 09:31:13 <heycam> ... so the byte offsets remain the same 09:31:19 <heycam> ... IDs would require adding them to every frame 09:31:33 <heycam> ... when you concatenate two animations, you might have to rename IDs 09:31:46 <heycam> mohamed: how will you deal with the background that is preloaded? will you do complex like intermediate frames? 09:32:11 <heycam> cyril: you could imagine either it's an external resource, or you could data: uri embed it in the svg, or for an mp4 file, you could store it natively without base64 encoding it 09:32:51 <heycam> ... you can put the common elements in the "header" of the document 09:33:13 <heycam> dino: from the Apple part of WebKit, looking cool isn't enough to contribute impl resources 09:33:16 <heycam> ... we need demand from users 09:33:26 <heycam> ... then we have to balance that against what can you achieve currently int he platform without having to implement it 09:33:53 <heycam> ... comparing it to Brian's animation example, that's enabling a subset of developers that don't have as much experience with how to write animations to do something that they couldn't do before, in a nice declarative way 09:34:08 <heycam> ... every time you add a new declarative format to the web, there is a lot of maintenance, security, etc. overhead 09:34:12 <heycam> ... there's a good balance there 09:34:17 <heycam> ... with this proposal I am more concerned 09:34:22 <heycam> ... there's JS in there 09:34:32 <heycam> ... that's not me making a value judgement on the technology in any way 09:34:55 <heycam> ... if we looked at this and saw it could take a couple of person years of impl work, we have to prioritise against many other things 09:34:57 <heycam> cyril: I hear that 09:35:02 <heycam> ... not asking for any browser changes 09:35:09 <heycam> ... the purpose of this was to demonstrate that with a shim you can do it 09:35:26 <heycam> ... then if users want it, let them use it, and if they see perf problems, sync problems, then we might think about embedding that natively in the browser 09:35:28 <heycam> dino: yeah 09:35:40 <heycam> dsinger: what would you need the browsers to do natively? which bits are likely? 09:35:44 <heycam> dino: a great example of this is MSE 09:36:01 <heycam> ... the content distributors asked the browsers that we need to do this thing, and we can't do it unless we have this particular feature 09:36:06 <heycam> ... the ability to generate media streams from js 09:36:13 <heycam> ... that's the way you have to ask browser vendors to do things 09:36:18 <heycam> cyril: I'm not asking browser vendors to do things 09:36:28 <heycam> ... I'm asking agreement to publish guidelines on svg streamable content 09:36:37 <heycam> ... if authors want to stream their svg content, it would be better if they did it this way 09:36:47 <glenn> glenn has joined #svg 09:36:50 <heycam> ... any streaming tool would need some annotations 09:37:04 <heycam> ... but from the browser point of view, there's nothing to be changed, unless users demand it because perf is not there, or ... 09:37:08 <heycam> dsinger: where would that be? 09:37:31 <heycam> cyril: the sync you can achieve here is best effort 09:37:36 <heycam> ... if you need frame accurate ... 09:37:52 <heycam> dino: I think it sounds like a great CG effort 09:38:05 <heycam> cyril: if I'm alone in the CG... 09:38:11 <heycam> dino: if you're alone in the CG, maybe it shouldn't take WG time 09:38:15 <heycam> ... I don't think you will be though 09:38:39 <heycam> shepazu: I think the dedicated conversations you could have there wouldn't distract this group 09:38:45 <heycam> cyril: I think it's also relevant to this group 09:38:51 <heycam> ... not completely, but somehow 09:38:56 <heycam> ... it's related to timed elements 09:39:07 <heycam> ... if you want all these things to be synced, looped, then you could do it with web aimations 09:39:09 <heycam> *animations 09:39:23 <heycam> shepazu: I'd like to see SVG WG people in that CG 09:40:01 <heycam> ... speaking as a W3C person, I want to see smooth transitions from CG to Rec track stuff 09:40:21 <heycam> cyril: having a CG sounds ok 09:41:34 <heycam> RRSAgent, make minutes 09:41:34 <RRSAgent> I have made the request to generate http://www.w3.org/2013/11/14-svg-minutes.html heycam 09:41:56 <Zakim> -Huangshan 09:42:05 <ed> trackbot, end telcon 09:42:05 <trackbot> Zakim, list attendees 09:42:05 <Zakim> As of this point the attendees have been Huangshan, TabAtkins 09:42:13 <trackbot> RRSAgent, please draft minutes 09:42:13 <RRSAgent> I have made the request to generate http://www.w3.org/2013/11/14-svg-minutes.html trackbot 09:42:14 <trackbot> RRSAgent, bye 09:42:14 <RRSAgent> I see 12 open action items saved in http://www.w3.org/2013/11/14-svg-actions.rdf : 09:42:14 <RRSAgent> ACTION: heycam to look at the performance class requirements and decide whether to remove points or move them into general requirements [1] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T01-48-56 09:42:14 <RRSAgent> ACTION: heycam to review Resource Priorities specification [2] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T02-18-11 09:42:14 <RRSAgent> ACTION: Rich to reference ARIA 1.1 in SVG 2 [3] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T03-29-18 09:42:14 <RRSAgent> ACTION: Doug to clarify HTML content in <desc> and <title> elements [4] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T03-59-37 09:42:14 <RRSAgent> ACTION: Doug to work with Gerardo and Tab to come up with haptic, tactile and 3d media queries [5] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T04-10-23 09:42:14 <RRSAgent> ACTION: plinss deliver document to adapt specs to Shepherd [6] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T06-24-39 09:42:14 <RRSAgent> ACTION: Peter Linss deliver document to adapt specs to Shepherd [7] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T06-24-47 09:42:14 <RRSAgent> ACTION: Dirk to remove SVGAnimatedBoolean and SVGFEConvolveMatrixElement.preserveAlpha from the SVG2 DOM [8] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T07-35-50 09:42:14 <RRSAgent> ACTION: Erik to ask in the thread about whether SVG specific event handlers should go on GlobalEventHandlers, or separately on SVGElement [9] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T08-20-18 09:42:14 <RRSAgent> ACTION: Erik to make SVGElement implement GlobalEventHandlers in SVG2. [10] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T08-21-12 09:42:14 <RRSAgent> ACTION: Erik to add use counters to see if nearestViewportElement/furthestViewportElement are used [11] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T08-26-12 09:42:14 <RRSAgent> ACTION: Dirk to change nearestViewportElement/furthestViewportElement to be Element [12] 09:42:14 <RRSAgent> recorded in http://www.w3.org/2013/11/14-svg-irc#T08-26-36 09:42:24 <Zakim> -TabAtkins 09:42:25 <Zakim> Team_(svg)08:06Z has ended 09:42:25 <Zakim> Attendees were Huangshan, TabAtkins 09:43:42 <RRSAgent> RRSAgent has joined #svg 09:43:42 <RRSAgent> logging to http://www.w3.org/2013/11/14-svg-irc 09:43:52 <heycam> Present+ Eriik, Brian, Satoru, Fujisawa, Nikos, Doug, Chris, Dirk, Cyril, Rik, Dean, Cameron 09:43:59 <heycam> RRSAgent, make minutes 09:43:59 <RRSAgent> I have made the request to generate http://www.w3.org/2013/11/14-svg-minutes.html heycam 09:44:23 <heycam> Present+ Rich 09:44:36 <heycam> RRSAgent, make minutes 09:44:36 <RRSAgent> I have made the request to generate http://www.w3.org/2013/11/14-svg-minutes.html heycam 10:17:20 <myakura> myakura has joined #svg 12:02:52 <Zakim> Zakim has left #svg 12:13:53 <myakura> myakura has joined #svg 13:12:55 <nsakai> nsakai has joined #svg 13:15:45 <nsakai_> nsakai_ has joined #svg 13:46:30 <glenn> glenn has joined #svg 14:48:55 <dino> dino has joined #svg