06:30:28 RRSAgent has joined #svg 06:30:29 logging to http://www.w3.org/2009/04/06-svg-irc 06:30:30 RRSAgent, make logs public 06:30:32 Zakim, this will be GA_SVGWG 06:30:32 I do not see a conference matching that name scheduled within the next hour, trackbot 06:30:33 Meeting: SVG Working Group Teleconference 06:30:33 Date: 06 April 2009 06:30:51 Zakim, code? 06:30:51 sorry, shepazu, I don't know what conference this is 06:31:12 Zakim, room for 8? 06:31:13 ok, shepazu; conference Team_(svg)06:31Z scheduled with code 26632 (CONF2) for 60 minutes until 0731Z 06:31:44 Team_(svg)06:31Z has now started 06:31:51 +Doug_Schepers 06:32:33 +??P1 06:32:53 +[IPcaller] 06:32:56 Zakim, ??P1 is me 06:32:56 +ed_; got it 06:32:56 Zakim, [ is me 06:32:57 +heycam; got it 06:36:22 Zakim, who is on the call? 06:36:22 On the phone I see Doug_Schepers, ed_, heycam 06:38:46 Chair: Cameron 06:39:11 Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0007.html 06:39:12 scribe: erik 06:39:16 scribeNick: ed_ 06:39:37 Topic: Additional value for image-rendering 06:39:50 CM: bringing this up since we discussed it last week 06:40:04 ...i think our conclusion was to use nearestNeighbor for it 06:40:33 ...but robert longson didn't get a response on www-svg, so they've renamed their value -moz-crisp-edges 06:40:38 ...not the one we chose in the end 06:40:59 DS: didn't feel that strongly about it 06:41:21 CM: me neither, just wanted to respond quickly to them 06:41:53 +??P3 06:41:55 ...crisp-edges makes some sense, it's used elsewhere 06:42:03 Zakim, ??P3 is me 06:42:03 +anthony; got it 06:42:12 ...so either we go for something like that or we go on with nearestNeighbor 06:43:29 ED: I'd prefer nearestNeighbor, but as long as crispEdges is defined to be nearestNeighbor that's ok, people might find it easier to understand crispEdges 06:43:48 CM: ok, so we'll leave it at that then 06:43:55 Topic: Selectors, getElementsByTagName() and camelCase SVG 06:43:59 http://www.w3.org/mid/2E216A7B-066B-4996-91FE-562CA633F9C5@iki.fi 06:44:11 CM: thread started by hsivonen 06:44:32 ..what getelementsbytagname should do, given that we'll have camelcased elements in the dom now 06:44:46 ...the practical effect is that it does case-insensitive matchinig 06:45:33 ...because the html parser does lowercase folding, and gebtn does lowercase folding of the element string argument that's passed to it 06:46:10 ...if it's left as it's defined now in html5, you wouldn't be able to match the camelcased elements that are in the dom 06:46:40 ...in practice I would expect most svg content to use 06:46:56 ...*NS methods, so wouldn't run into the problems with non-NS methods 06:48:25 DS: reviewing it, I do use getElementsByTagName in svg 06:48:36 ...and in pure svg too 06:49:24 ...because I know the content is svg, however if I wanted to use it in html+svg I would switch to use the *NS method 06:49:42 CM: I tend to avoid the non-NS methods 06:50:37 ED: I do use the non-NS methods sometimes, and would like them to work as well as possible 06:51:16 CM: there was a suggestion to use the parser algorithm (case-fixing table) for getElementsByTagName 06:51:29 ...which is probably ok 06:52:20 ED: that would make it a bit more consistent, so I'd prefer something like that 06:52:52 CM: so weird-case elements would not work, but such elements wouldn't be useful 06:52:58 document.createElementNS(svgns, 'ReCt') 06:53:30 CM: so that ReCT element wouldn't be matched by getElementsByTagName 06:54:04 DS: I don't see a problem with this 06:54:18 CM: another issue that was brought up is 'textArea' 06:54:57 ...because if you convert it to the canonical case you wouldn't know to which element to convert to, 'textArea' or 'textarea' 06:55:04 ...same issue in CSS selectors too 06:55:14 ...there's no context 06:56:06 ...the solution of using canonical case wouldn't work for textArea 06:56:22 DS: isn't it the actual name of the element? 06:56:53 CM: they want to work out the canoical case of the element 06:57:46 DS: not happy about the textArea element, but we're working out potential future issues with this 06:58:28 CM: do we want to decide something or just chime in on that thread? 06:58:37 ...the suggestions there seem sensible 06:58:53 ...if we're stuck with textArea, and want it to work 07:00:14 ...we should say that we want to be able to select either textArea or textarea 07:01:19 ...will test current browser behaviour with that 07:02:17 Topic: ISSUE-2255: Effect of modifying SVGSVGElement::useCurrentView unclear 07:02:37 CM: please get all errata-related actions done asap, so we can publish second edition 07:03:03 CM: not sure how useful the useCurrentView attribute is 07:03:08 ...you can modify it 07:03:22 ...but ti's meant to indicate if the iri had a fragment on it 07:03:35 ...not sure it makes sense to be able to modify it 07:03:53 ...I'd suggest to change it to readonly 07:04:30 CM: opera implements the view stuff? 07:05:17 ED: yes 07:05:44 ...I agree it should probably be readonly 07:06:21 CM: ok, leave it in there and make it correct 07:07:06 ACTION: heycam to make an SVG 1.1 erratum to make SVGSVGElement.useCurrentView be readonly, and to remove the exception on it 07:07:07 Created ACTION-2510 - Make an SVG 1.1 erratum to make SVGSVGElement.useCurrentView be readonly, and to remove the exception on it [on Cameron McCormack - due 2009-04-13]. 07:07:44 Topic: ISSUE-2254: Consider changing which elements have load dispatched to them 07:08:00 CM: haven't fully thought it through 07:08:07 ...it's about the load event in svg 07:08:16 ...it differs a bit form the html load event 07:08:31 ...to make things more similar svg <-> html 07:09:37 ...in svg all elements get a load event, but in html only gets load events if it's having an external resource 07:09:57 ...may be that dispatching load for all elements may be a performance problem 07:10:19 ...tested in opera and firefox, both dispatched load on every element in svg 07:10:28 ...may not be such a big issue 07:11:12 ...could be that it's already optimized 07:11:24 DS: not convinced that it's like the mutation events 07:12:03 CM: traditionally the mutation events haven't got good implementation/interop, but the load events in svg are 07:12:42 ...it's not common to have listeners on all elements in svg (for load) 07:13:00 DS: unless there's an event lsiterner, then it shouldn't be much of a burden 07:13:16 CM: I'd expect such optimizations yes 07:14:43 ED: Opera does have slight differences in 07:14:49 ...load and svgload 07:15:15 ...would prefer to align with the html behaviour 07:15:40 CM: svgload is dispatched to every element, but load is only dispatched to elements that have external resources 07:16:05 AG: don't see the usefulness of dispatching the event to elements that don't have ext resources 07:16:28 CM: right, so I usually put it on but not on other elements 07:16:42 AG: what's the impact on implementations? 07:16:56 CM: haven't tested the tiny implementations 07:17:08 AG: probably do the optimization for it mentioned before 07:17:41 CM: we have tests for it in the testsuite? 07:17:54 ...so 'onload' will listen to 'SVGLoad'? 07:18:07 ED: yes, you can listen for 'load' with addEventListener 07:18:35 DS: svg is different form html in that it can take longer to render svg 07:19:19 ...notable in firefox, for when boundingboxes are available (onload or otherwise)...could be solved by onrender event... 07:20:06 ...in html all references are external, but in svg they can be internal as well 07:21:08 ...having onload there, or onrender would be useful, for document-internal references too 07:21:22 ...e.g if you reference forward in the file 07:21:49 ...with larger files, we can use progress events 07:22:36 ...onload could be replaced by onrender and progress events, and then we could align onload with html 07:23:21 CM: in 1.1 there's no requirements on 'load' just for 'SVGLoad', so they could be different 07:24:10 ...the requirement for SVGLoad to be sent to an element when all its child elements are loaded, not sure how useful that is really 07:24:45 ED: probably only if using externalResourcesRequired 07:26:12 CM: if we're going to change this, do we want to change it in core-2 or in 1.1 errata? 07:26:25 AG: probably core-2, it's a rather large change 07:26:39 ...thing onrender idea is useful too 07:27:28 ED: onrender sounds like it might be resource-demanding, expensive...but depends on what you mean with it 07:28:03 DS: we already say something about getbbox 07:28:16 ...onrender would mean everything has been rendered to screen 07:28:44 ...mauybe you already know it's going to be expensive, moving many elements, you just want to know when it's rendered 07:29:07 CM: i think it would happen when the scriptblock has finished 07:29:24 ...so setTimeout(0...) 07:29:43 ...onrender might be cleaner though 07:29:53 ...no spec really says when render happens 07:30:16 ...there are conventions, but not really specified 07:30:31 ...you didn't want it for every render? or just the first one? 07:30:47 DS: just speculating, what do ppl want when they use onload 07:30:58 AG: might be something we could work out for core2 07:31:12 CM: yeah, what ppl use onload for would be useful info 07:31:34 DS: we could ask on svgdevelopers, are ppl relying on onload being different? 07:31:43 ...is there some advantage? 07:32:50 CM: should we leave this issue open? 07:32:59 DS: we should ask svgdevelopers 07:33:14 ...maybe we could get it into an errata 07:34:02 ACTION: DS to ask svgdevelopers / svgig about onload/svgload events and how they use it 07:34:02 Created ACTION-2511 - Ask svgdevelopers / svgig about onload/svgload events and how they use it [on Doug Schepers - due 2009-04-13]. 07:35:02 topic: ISSUE-2253: s should be allowed as children of container elements 07:35:42 CM: noticed while doing the 1.1 dtd, you're not allowed to put foreignObject anywhere but as a child of switch 07:35:51 ...though in tiny12 you can have it anywhere 07:36:43 DS: it was never really implemented in 1.1, not sure it matters, does it say anything in the spec? 07:37:25 CM: I'd understand if there was a reason for it in the spec, but you can still put conditional attributes on the foreignObject itself without switch 07:37:38 ...suggest allowing it in any container element 07:40:45 ED: yes, sounds good 07:42:04 ACTION: heycam to make an SVG 1.1 errata for allowing foreignObject in any container element (not just in ) 07:42:04 Created ACTION-2512 - Make an SVG 1.1 errata for allowing foreignObject in any container element (not just in ) [on Cameron McCormack - due 2009-04-13]. 07:43:01 Topic: ISSUE-2216: Not clear whether assigning to SVGLength.valueAsString can change the unitType 07:43:30 CM: what should happen with the unittype on the length object 07:43:57 ...I think that what's intended is that the unittype changes if you assign something with valueAsString 07:44:25 ...doesn't define exceptions to throw if something bad is assigned, e.g 'x' 07:44:35 ...probably should raise some exception 07:44:40 http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html 07:47:10 AG: what's the change for the newValueSpecifiedUnits/convert... methods? 07:47:27 CM: they throw on bad values, didn't say before what should happen in such cases 07:47:34 AG: ok, I'm ok with that 07:47:46 ED: looks ok to me too 07:48:01 CM: another issue is open how you resolve units on lengthobjects 07:48:08 ...wll address that separetely 07:50:20 ACTION: heycam to make an SVG 1.1 errata with the proposed changes in http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html and to test existing implementations (for exceptioncodes used if any etc) 07:50:20 Created ACTION-2513 - Make an SVG 1.1 errata with the proposed changes in http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html and to test existing implementations (for exceptioncodes used if any etc) [on Cameron McCormack - due 2009-04-13]. 07:51:22 Topic: f2f meeting 07:51:33 AG: could we move it one week later? 07:51:48 CM: chris had a css meeting the week before, right? 07:51:51 DS: yes 07:52:05 CM: I don't mind 07:52:09 DS: ok with me 07:52:22 AG: jwatt will attend? 07:52:28 DS: I'd expect so 07:53:23 ED: I'd prefer the 8-15, the week after is a bit worse for me 07:53:46 s/8-15/8-13 june/ 07:54:25 AG: ok, I'm fine with the week starting the 8th... 07:54:53 DS: slight preference to keeping it as it is 07:55:39 Topic: transforms 07:56:13 DS: AG you had an action to explain why a 3x3 is as good as a 4x4 matrix... 07:56:31 AG: 4x3 you mean? 07:56:34 DS: right 07:56:55 ...dean want's to have an explanation, perhaps on the wiki? 07:57:13 ...as a bonus we'd be compatible with openvg 07:58:15 ...helpful if this could be done soon 07:58:51 AG: regarding modules, are we go for publishing again? 07:58:55 DS: yes 07:59:54 -ed_ 07:59:56 -anthony 07:59:56 -Doug_Schepers 07:59:57 -heycam 07:59:57 Team_(svg)06:31Z has ended 07:59:58 Attendees were Doug_Schepers, [IPcaller], ed_, heycam, anthony 08:00:11 Zakim, bye 08:00:12 Zakim has left #svg 08:00:17 rrsagent, make minutes 08:00:17 I have made the request to generate http://www.w3.org/2009/04/06-svg-minutes.html ed_ 09:24:47 heycam has joined #svg