IRC log of svg on 2009-04-06

Timestamps are in UTC.

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