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 http://www.w3.org/2009/04/06-svg-irc
- 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]
- +Doug_Schepers
- 06:32:33 [Zakim]
- +??P1
- 06:32:53 [Zakim]
- +[IPcaller]
- 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]
- Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0007.html
- 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]
- +??P3
- 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_]
- ...so 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]
- http://www.w3.org/mid/2E216A7B-066B-4996-91FE-562CA633F9C5@iki.fi
- 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_]
- ...in 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_]
- ...you 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_]
- ...it's about the load event in svg
- 07:08:16 [ed_]
- ...it differs a bit form the html load event
- 07:08:31 [ed_]
- ...to make things more similar svg <-> html
- 07:09:37 [ed_]
- ...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 [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_]
- ...it'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_]
- ...so '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_]
- ...in 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_]
- ...so setTimeout(0...)
- 07:29:43 [ed_]
- ...onrender might be cleaner though
- 07:29:53 [ed_]
- ...no spec really says when render happens
- 07:30:16 [ed_]
- ...there are conventions, but not really specified
- 07:30:31 [ed_]
- ...you 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_]
- ...is 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]
- http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0008.html
- 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 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 [trackbot]
- 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 [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_]
- ...as 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]
- -ed_
- 07:59:56 [Zakim]
- -anthony
- 07:59:56 [Zakim]
- -Doug_Schepers
- 07:59:57 [Zakim]
- -heycam
- 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 http://www.w3.org/2009/04/06-svg-minutes.html ed_
- 09:24:47 [heycam]
- heycam has joined #svg