IRC log of svg on 2009-07-01

Timestamps are in UTC.

06:30:21 [RRSAgent]
RRSAgent has joined #svg
06:30:21 [RRSAgent]
logging to http://www.w3.org/2009/07/01-svg-irc
06:30:23 [trackbot]
RRSAgent, make logs public
06:30:23 [Zakim]
Zakim has joined #svg
06:30:25 [trackbot]
Zakim, this will be GA_SVGWG
06:30:25 [Zakim]
ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start now
06:30:26 [trackbot]
Meeting: SVG Working Group Teleconference
06:30:26 [trackbot]
Date: 01 July 2009
06:30:53 [Zakim]
GA_SVGWG()2:30AM has now started
06:31:01 [Zakim]
+Doug_Schepers
06:31:32 [Zakim]
+??P1
06:31:38 [ed]
Zakim, ??P1 is me
06:31:38 [Zakim]
+ed; got it
06:31:39 [Zakim]
+??P2
06:31:41 [heycam]
Zakim, ??P2 is me
06:31:41 [Zakim]
+heycam; got it
06:33:04 [Zakim]
+??P3
06:33:09 [anthony]
Zakim, ??P3 is me
06:33:09 [Zakim]
+anthony; got it
06:33:31 [ChrisL]
ChrisL has joined #svg
06:33:51 [ChrisL]
rrsagent, here
06:33:51 [RRSAgent]
See http://www.w3.org/2009/07/01-svg-irc#T06-33-51
06:33:52 [Zakim]
+??P4
06:34:11 [ed]
Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009AprJun/0247.html
06:34:17 [jwatt]
Zakim, ??P4 is me
06:34:17 [Zakim]
+jwatt; got it
06:34:25 [heycam]
Chair: Erik
06:34:27 [heycam]
Scribe: Cameron
06:34:30 [heycam]
ScribeNick: heycam
06:34:43 [Zakim]
+??P5
06:35:36 [ChrisL]
agenda+ svg color
06:35:45 [heycam]
Zakim, take up agendum 1
06:35:45 [Zakim]
agendum 1. "svg color" taken up [from ChrisL]
06:35:50 [ChrisL]
http://dev.w3.org/SVG/modules/color/DoC/Tiny12DoC.html
06:36:09 [heycam]
CL: all of the commentors are in green now, they agree with our chnages
06:36:15 [heycam]
s/chnages/changes/
06:36:54 [ChrisL]
http://dev.w3.org/SVG/modules/color/master/SVGColor.html
06:37:02 [heycam]
[we agree to publish fpwd]
06:37:04 [ChrisL]
http://dev.w3.org/SVG/modules/color/master/SVGColorPrimer.html
06:37:21 [heycam]
RESOLUTION: We will publish SVG Color as a FPWD
06:37:53 [heycam]
CM: how about the syntax for icc named colours?
06:38:04 [heycam]
CL: i don't mind restricting it to XML Name (though you can't start with a digit there)
06:38:08 [heycam]
... same thing with IDs
06:38:19 [heycam]
... not sure what CSS has for ident, how restricted that is
06:38:28 [heycam]
... i'm happy to restrict it down
06:38:42 [heycam]
... what i put in was what erik suggested, which was anything that didn't clash with the other syntax
06:39:19 [ChrisL]
http://www.w3.org/TR/CSS21/grammar.html
06:39:58 [heycam]
http://www.w3.org/TR/CSS21/syndata.html
06:40:03 [heycam]
[-]?{nmstart}{nmchar}*
06:40:12 [heycam]
nmstart [_a-z]|{nonascii}|{escape}
06:40:19 [heycam]
nmchar [_a-z0-9-]|{nonascii}|{escape}
06:40:39 [heycam]
CL: so the same as an xml name, can't have digits at the beginning
06:40:53 [heycam]
... we should document that you can't start with a digit
06:40:57 [heycam]
... i can live with that
06:41:08 [heycam]
ED: that'll go in before publication?
06:41:08 [heycam]
CL: yes
06:41:14 [heycam]
... i'll respond to anne saying we agree
06:41:59 [heycam]
Topic: ISSUE-2287 - Consider clarifying empty clipPath behaviour
06:42:01 [heycam]
ISSUE-2287?
06:42:01 [trackbot]
ISSUE-2287 -- Consider clarifying empty clipPath behaviour -- RAISED
06:42:01 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2287
06:42:13 [heycam]
ED: this is an issue i can across from some test cases
06:42:23 [heycam]
... seems that implementations differ on how empty clip paths behave
06:42:30 [heycam]
... i made a ua test
06:42:37 [heycam]
... and tested the four cases i found
06:42:48 [heycam]
... i think we should consider adding this to 1.1 second edition spec
06:42:56 [heycam]
... i can go through each of the cases
06:43:09 [heycam]
... the first to agree on is what should happen if you have an empty clip path
06:43:18 [heycam]
... most impls agree that that would mean everything is clipped away
06:43:31 [heycam]
... not sure why batik thinks that it means nothing is clipped
06:43:42 [heycam]
CM: yes i think it should clip everything away
06:43:48 [heycam]
ED: the spec doesn't say anything about the case
06:43:53 [heycam]
... but it's logical
06:44:04 [heycam]
... if you have an empty area, you'll have nothing left
06:44:11 [heycam]
... we could consider adding a note there
06:44:27 [heycam]
... second case is similar to the first, when you have children that have display:none set
06:44:35 [heycam]
... third is visibility:hidden
06:44:41 [heycam]
... those are interpreted differently in safari
06:44:49 [heycam]
... where visibility:hidden objects contribute to the clipping path
06:44:56 [heycam]
... which i think is a bit strange
06:45:19 [heycam]
CM: does the spec say anything about display:none?
06:45:33 [heycam]
... i thought all objects contribute to the clip path regardless of display/visibility
06:45:42 [ed]
http://www.w3.org/TR/SVG11/masking.html#EstablishingANewClippingPath
06:45:42 [heycam]
ED: i think it's just talking about the <clipPath> element itself
06:46:12 [heycam]
"The 'display' property does not apply to the 'clipPath' element; thus, 'clipPath' elements are not directly rendered even if the 'display' property is set to a value other than none, and 'clipPath' elements are available for referencing even when the 'display' property on the 'clipPath' element or any of its ancestors is set to none."
06:46:20 [heycam]
ED: but it doesn't talk about children of the clipPath
06:46:29 [heycam]
... and sometimes it's useful to remove elements from the clipPath easily with display:none
06:47:12 [heycam]
"The raw geometry of each child element exclusive of rendering properties such as 'fill', 'stroke', 'stroke-width' within a 'clipPath' conceptually defines a 1-bit mask..."
06:47:22 [heycam]
ED: depends what rendering properties includes
06:48:00 [heycam]
AG: does 1.2T say something about this?
06:48:15 [heycam]
CM: tiny doesn't have clipping
06:48:21 [heycam]
AG: but i think we had some wording in there that relates to this
06:49:27 [heycam]
ED: there's a definition for rendering tree, but that's the closest i could find
06:49:52 [heycam]
CM: perhaps "rendering tree" is what we could reference
06:49:56 [heycam]
... if it's in 1.1
06:50:15 [heycam]
CM: what's your suggestion on which ones contribute to clipping paths?
06:50:24 [heycam]
ED: i'd prefer the more graphical sense of it
06:50:42 [heycam]
... it's intuitive to me that the things that show up and render (if not in a clipPath) would contribute
06:50:49 [heycam]
... and if you hide them in any way they wouldn't
06:50:58 [heycam]
AG: so visibility would affect it?
06:51:07 [heycam]
ED: i think visibility:hidden should contribute to the clip path
06:51:16 [heycam]
... but we could try to list all of the rendering properties
06:51:27 [heycam]
... if fill/stroke/stroke-width are not the only ones
06:51:36 [heycam]
CL: tends to trip us up if we list them all, harder to add new ones in other specs
06:52:33 [heycam]
CM: i would think intuitively that visibility:hidden wouldn't make a difference
06:52:39 [heycam]
... but that display:none would prevent contribution to the clip path
06:52:56 [heycam]
JW: i think visibility:hidden shouldn't contribute
06:53:10 [heycam]
... the only place i can think of it being useful is if you're referencing geometry that is the thing you're clipping
06:53:18 [heycam]
... trying to think of scenarios where it matters
06:53:46 [heycam]
DS: from the perspective of authoring, what's the most intuitive behaviour? what happens if for some reason that thing is not there.
06:54:00 [heycam]
... i think it would be easier to debug if it would be ignored
06:54:46 [heycam]
ED: when i debug clippath i find it easier to remove the clippath element and to draw it, to visualise how it gets applied
06:54:57 [heycam]
... so in that sense i think it's easier to understand what it does if it's the same as the rendering
06:55:02 [heycam]
... so visibility:hidden wouldn't contribute to the clippath
06:55:34 [heycam]
JW: the only time it would matter is if you're clipping something that's visually on the screen
06:55:38 [heycam]
... otherwise the author could use display:none
06:55:58 [heycam]
... maybe using visibility:hidden for some reason in referenced geometry
06:56:13 [heycam]
CM: ah so if you're referencing clippath geometry that has some visibility:hidden stuff already
06:56:30 [heycam]
AG: i'm leaning towards erik's side
06:56:41 [anthony]
http://www.w3.org/TR/SVGTiny12/painting.html#VisibilityControl
06:57:46 [ChrisL]
(message re IDENT sent ... http://lists.w3.org/Archives/Public/www-svg/2009Jul/0000.html )
06:59:27 [heycam]
ED: i think the first one we can conclude that empty clippaths mean everything is clipped away
06:59:53 [heycam]
... we can also agree that any children with display:none do not contribute to the clipping path
07:00:20 [heycam]
... and we're not concluded on visibility:hidden
07:01:00 [heycam]
AG: is it pain for implementations?
07:01:06 [heycam]
ED: just an if statement, not a huge deal
07:01:18 [heycam]
JW: all implementations other than safari do that?
07:01:30 [heycam]
ED: safari lets visibility:hidden contribute to the clipping path, batik too
07:01:34 [heycam]
... opera and firefox don't
07:02:54 [heycam]
JW: i'm struggling to think of a use case either way, and preventing visibility:hidden from contributing seems intuitive to me
07:02:58 [heycam]
ED: ok we'll go with that
07:03:15 [heycam]
... the last case is clip-path="url(#brokenlink)"
07:03:25 [heycam]
... would that mean everything is clipped or nothing is clipped?
07:03:36 [heycam]
... batik thinks a broken link there is an error, while the others don't agree
07:03:46 [heycam]
AG: IMO nothing should be clipped
07:04:13 [heycam]
ED: don't know what's meant to happen for other CSS properties with invalid urls in SVG 1.1
07:04:20 [heycam]
... such as fill="url(#bad)"
07:04:28 [heycam]
AG: i think it's intuitive that it doens't clip
07:04:36 [heycam]
... if it doesn't work, then it's obvious if everything renders
07:04:47 [heycam]
ED: for fill you would use the initial value
07:04:50 [heycam]
JW: as if it weren't specified
07:04:55 [heycam]
ED: so for clip-path that would be none
07:04:58 [heycam]
... so no cipping
07:05:00 [heycam]
s/cipping/clipping/
07:05:02 [heycam]
CM: i agree
07:05:54 [heycam]
ACTION: Erik to add these decisions to the 1.1SE spec, and make the clippath example into a test case
07:05:54 [trackbot]
Created ACTION-2628 - Add these decisions to the 1.1SE spec, and make the clippath example into a test case [on Erik Dahlström - due 2009-07-08].
07:06:59 [heycam]
Topic: ISSUE-2283 - Make it possible to get the bounding box of an element in a particular coordinate system
07:07:01 [heycam]
ISSUE-2283?
07:07:01 [trackbot]
ISSUE-2283 -- Make it possible to get the bounding box of an element in a particular coordinate system -- RAISED
07:07:01 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2283
07:08:30 [heycam]
CM: [essentially reads out the issue]
07:09:20 [heycam]
ED: suggestion on how to do this?
07:09:22 [heycam]
CM: three ways
07:09:33 [heycam]
... have SVGRect be transformable
07:09:53 [heycam]
... extend getBBox() with an argument
07:10:03 [heycam]
... or introduce a new getBBoxInAnotherElementsCoordSystem(elt)
07:10:11 [heycam]
ED: people have asked for transformable SVGRect before
07:10:57 [heycam]
CM: transforming an SVGRect might give you a quadrangle
07:11:02 [heycam]
... so the return type couldn't be another SVGRect
07:11:03 [eseidel]
eseidel has joined #svg
07:11:48 [heycam]
ED: you could return a rectangle but it wouldn't be the transformed rectangle
07:11:57 [heycam]
CL: you could return a path
07:12:52 [heycam]
JW: the first option, having SVGRect be transformable, i was dismissing out of hand
07:13:12 [heycam]
... you've no longer got tight bounds, if you want to still return a SVGRect
07:13:28 [heycam]
... for getBBox() i was hoping to pass in an argument for the different type of bounds (including fill, stroke, clipping)
07:13:37 [heycam]
... so i didn't want to pass in an Element argument to that
07:13:58 [heycam]
... i was thinking of something like the third option, but more like otherElement.getBBox(firstElement)
07:14:05 [heycam]
s/getBBox/getBBoxOf/
07:14:16 [heycam]
... that allows getBBoxOf() to have the type-of-bounds argument
07:15:33 [heycam]
CM: getBBoxOf() seems like the simplest solution
07:16:27 [heycam]
ACTION: Cameron to add a proposal for getBBoxOf() to the proposals directory
07:16:28 [trackbot]
Created ACTION-2629 - Add a proposal for getBBoxOf() to the proposals directory [on Cameron McCormack - due 2009-07-08].
07:16:55 [heycam]
Topic: ISSUE-2282 - Consider adding new path syntax for points on path
07:16:57 [heycam]
ISSUE-2282?
07:16:57 [trackbot]
ISSUE-2282 -- Consider adding new path syntax for points on path -- RAISED
07:16:57 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2282
07:17:21 [heycam]
ED: this is about new path syntax/interpolation
07:18:00 [heycam]
CL: patrick gave us a bunch of math, but not sure that's good to go with
07:18:07 [heycam]
... not sure it's helps us concretely enough
07:18:11 [heycam]
DS: yep
07:18:19 [heycam]
CL: otoh he does have some java code that implements it
07:18:39 [heycam]
AG: there is quite a bit to specify for it
07:18:56 [heycam]
... for example, when you have a bend in the curve where abouts in the curve does it go through the point
07:19:10 [heycam]
... or if you're trying to fit paths to points it can be tricky
07:19:25 [heycam]
CL: normally with this kind of thing you can allow an amount of error, because it's not always possible get a solution
07:19:43 [heycam]
... which might be ok for a new element, but to add into existing path syntax it's hard to add parameters
07:20:05 [heycam]
... if you want to say "go through these points within 0.1 units" it's hard to pass that in with the current path syntax
07:20:40 [heycam]
ED: anyone interested in looking at this? do we need to try to contact someone to make something from this?
07:21:02 [heycam]
DS: i think it's potentially interesting, but i don't have the math to make it interesting enough to myself
07:21:11 [heycam]
CL: too much conceptual gap between his math and what we need
07:21:19 [heycam]
... otoh i think he's quite interested in this
07:21:41 [heycam]
... so in general if you've got n points, what's the algorithm to produce the path?
07:21:49 [heycam]
... does it decompose into other curve segments?
07:21:56 [heycam]
... need to get patrick to explain what's entailed there
07:22:14 [heycam]
DS: if i could see the java implementation, that would give me a better sense
07:22:39 [heycam]
... want to see two things: one, what such curves look like visually, and two what the syntax might be
07:23:09 [heycam]
... so i'd like to see a bunch of points have a path go through it in a predictable way
07:23:18 [heycam]
... maybe the syntax would just be like a <polyline>, but i don't know that
07:23:41 [heycam]
CL: for a basic shape that's easy, we could have another attribute that says accuracy="whatever" with a default of 0, e.g.
07:23:52 [heycam]
... and other constraints, how tight the "cord" is pulled
07:24:03 [heycam]
... you could imagine floppy shapes and mostly straight line curves
07:24:10 [heycam]
... exactly the kind of thing the java testing app would help us see
07:24:34 [heycam]
DS: another aspect is that i don't know how it deals with shapes where the line crosses itself several times
07:24:41 [heycam]
... don't know if that would lead to funky behaviour
07:24:59 [ed]
http://www-personal.umich.edu/~pion/WebGeom/sketch-test5.html
07:25:17 [heycam]
ED: that app isn't showing any nice curves
07:25:27 [heycam]
DS: curves would be more interesting
07:25:45 [heycam]
... for a graph where you want to plot the points, for example
07:25:58 [heycam]
CL: if the java applet doesn't do it, but he thinks it's simple, we could ask him to do it
07:27:21 [heycam]
AG: this applet looks like the constraint stuff we were talking about, applying constraints to the movement
07:27:25 [heycam]
... and you get some sort of mechanical effect
07:27:55 [heycam]
ACTION: Chris to contact Patrick Ion for an applet that demonstrates these curves
07:27:55 [trackbot]
Created ACTION-2630 - Contact Patrick Ion for an applet that demonstrates these curves [on Chris Lilley - due 2009-07-08].
07:28:15 [heycam]
AG: you could do some cool stuff with constraints on these curves
07:28:27 [heycam]
Topic: ISSUE-2274 - Consider adding drag and drop functionality
07:28:29 [heycam]
ISSUE-2274?
07:28:29 [trackbot]
ISSUE-2274 -- Consider adding drag and drop functionality -- RAISED
07:28:29 [trackbot]
http://www.w3.org/Graphics/SVG/WG/track/issues/2274
07:28:49 [heycam]
ED: don't know if there's anything to discuss, but there should be an action to research what would be needed from svg
07:28:58 [heycam]
... this might be related to webapps work
07:29:32 [heycam]
DS: drag and drop has been added to html5
07:29:40 [heycam]
... but not exactly in the way we'd want in svg
07:29:47 [heycam]
... in html5 is like a special kind of clipboard
07:29:51 [heycam]
s/is like/it's like/
07:29:54 [heycam]
... so a copy/paste thing
07:30:13 [heycam]
... i'm thinking that the OP means (and i mean) is being able to drag and drop a shape around the screen
07:30:15 [heycam]
... moving it around
07:30:26 [heycam]
... two ways of doing it
07:30:33 [heycam]
... either have drag and drop attributes, e.g.
07:30:42 [heycam]
... or a constraints mechanism where they could say what to do with it
07:30:56 [heycam]
... pointer.x-5 and pointer.y-10
07:31:11 [heycam]
... enable people to do things based on the pointer position, not using script
07:31:27 [heycam]
... activation through smil
07:31:45 [heycam]
... so i think this is SVG specific
07:31:56 [heycam]
CL: if it's going to interact with smil, you'd want it to raise events so you can say onblah
07:32:03 [heycam]
DS: we could create drag and drop events
07:32:10 [heycam]
... that it would dispatch when it did that
07:32:11 [Zakim]
-heycam
07:32:39 [Zakim]
+[IPcaller]
07:32:43 [heycam]
Zakim, [ is me
07:32:43 [Zakim]
+heycam; got it
07:33:20 [heycam]
... we could have it triggered on regular events mousedown, mousemove etc.
07:33:33 [heycam]
... if we did that, what we would need to do is also define how it works with a keyboard
07:33:38 [heycam]
... or some alternate pointer device
07:33:55 [heycam]
... so the more semantic thing would be grab/drag/drop
07:33:58 [heycam]
... however that's actuated
07:34:15 [heycam]
... making it accessible isn't particularly easy, i think
07:34:25 [heycam]
JW: allowing drag&drop without script?
07:34:38 [heycam]
CL: yes
07:34:49 [heycam]
... though i worry that it might get in the way of other things trying to affect the position
07:35:01 [heycam]
DS: that could argue for real grab/drag/drop events
07:35:15 [heycam]
CL: if you provide hooks then people can write script to make use of them as needed
07:35:24 [heycam]
... but if it's automatic, then it might get in the way of other things like link activation
07:35:38 [heycam]
JW: that would be an issue, that it would need to set attributes x/y or whatever
07:36:10 [heycam]
... especially when we're just introducing calc() or more complex positioning, layout, it's going to become painful to define what happens when you have percentage plus pointer.x pixels
07:36:22 [ed]
<animate begin="rect.mousedown" end="dropzone.mouseup" ...> is possible already
07:37:28 [shepazu]
attributeName="cx" attributeValue="pointer.x+5"
07:37:35 [heycam]
<animateTransformToPointer offsetX="..." offsetY="..." begin="rect.mousedown" end="rect.mouseup"/>
07:38:24 [heycam]
CM: if it's a smil mechanism, it might make it easier to avoid competing things affecting the position of an object
07:38:33 [heycam]
ED: sometimes you want the object to stay at its end point, sometimes to return
07:38:37 [heycam]
DS: you could use fill="freeze" for that
07:38:49 [heycam]
... so this wouldn't solve all cases
07:39:06 [heycam]
... but for the cases where people want something really strange, i think that they could code something up
07:39:16 [heycam]
... would this cover say 50-70% of cases where people want to do dnd?
07:39:22 [heycam]
... my guess is yes
07:39:40 [heycam]
ED: i don't know, all the cases i've seen you need to do some scripting or trigger server side actions
07:39:45 [heycam]
... depends on the use case
07:39:48 [heycam]
DS: what use cases?
07:39:56 [heycam]
ED: e.g. sorting some objects in some way and then storing it
07:40:23 [heycam]
... putting orders in a basket in a web shop
07:40:32 [heycam]
JW: svg solitaire
07:40:56 [heycam]
DS: in my mind, if you just had svg solitaire or putting items in a basket, both of those cases aren't asking for anyhting much special
07:41:00 [heycam]
... just moving the cards or the items
07:41:04 [heycam]
s/anyhting/anything/
07:41:13 [heycam]
JW: you need to drop near the cards
07:41:20 [heycam]
DS: wouldn't say you wouldn't have to script the drag code
07:41:34 [heycam]
ED: but i think you'd want to have script callbacks for dnd
07:41:39 [heycam]
DS: you have those already for smil
07:41:45 [heycam]
ED: you have the mouse events but don't know that it's drag/drop
07:41:51 [heycam]
DS: could change that
07:41:52 [jwatt]
s/you need to/you want to be able to/
07:42:16 [heycam]
... in the past bjoern wanted to be able to use arbitrary events in smil begin/end
07:42:33 [heycam]
... i think for 50-70% of the cases, dragging to move it around and then hooking that into script would handle it
07:42:43 [heycam]
... hard to think of anything funkier with dragging
07:43:01 [heycam]
... another case is if we wanted to allow people to have connectors and move nodes/edges around
07:43:15 [heycam]
... and have the connectors follow the shape, then we should try to solve that problem at the same time
07:43:29 [heycam]
... and it would be solved, if we had a way of saying "this line connects between these two shapes"
07:43:41 [heycam]
... then you would be able to drag things around and have the connectors follow
07:44:03 [heycam]
... i do think that even though it gets a little specialised, having that kind of functionality built in to svg solves a large number of use cases
07:44:11 [heycam]
... and it would make the language a lot more attractive to use
07:44:19 [heycam]
ED: have you looked at the html5 dnd?
07:44:22 [heycam]
DS: no but i should
07:44:29 [heycam]
ED: i think that's also something that's in silverlight
07:44:36 [heycam]
... same type of specialised dnd events
07:44:52 [heycam]
... might be good to study those cases
07:46:16 [heycam]
DS: not sure we're in a position yet to do anything about it
07:47:18 [heycam]
... i'm interested in this but there's so much other stuff to do
07:47:30 [heycam]
... i think we should come back to this
07:47:58 [heycam]
JW: i think it's a fair bit of work to work out the events, how attributes get modified, etc.
07:48:10 [heycam]
... and since it's 10-20 lines to implement dnd in script, maybe we should be prioritising other things
07:48:22 [heycam]
DS: one way to make it easier would be the "get the real point" stuff we talked about
07:48:36 [heycam]
... get the x/y position i care about, with transformations/ctm taken care of
07:48:50 [heycam]
CL: that's more the kind of thing i was talking about. adding hooks to make it more easily implemented.
07:48:57 [heycam]
DS: that stuff we'd need to resolve anyway if we were to do this
07:49:03 [heycam]
... since that's the behaviour people would want
07:49:07 [heycam]
... the "absolute" value of the mouse pointer
07:49:14 [heycam]
... so let's solve that part first
07:49:51 [heycam]
Topic: SVG 1.1 test suite template conversion
07:50:06 [heycam]
AG: pretty much all the tests are converted
07:50:12 [heycam]
... i'm just going through and verifying that they're all good
07:50:18 [heycam]
... just 30-odd tests left to check
07:50:21 [heycam]
... then i'll commit them all as a batch
07:50:37 [heycam]
... 335 tests all done
07:50:47 [heycam]
... should be done by the end of this week
07:50:55 [heycam]
CM: sounds good
07:51:01 [heycam]
AG: made some minor fixes to the xslt, it's working properly now
07:51:14 [heycam]
... we can use this and the new template for the svg core tests when the spec is on its way
07:51:18 [eseidel]
eseidel has joined #svg
07:51:21 [heycam]
... and for modules
07:51:47 [heycam]
ED: if we make tests for modules we should use the 1.1F2 template?
07:51:57 [heycam]
AG: or some variant?
07:52:20 [heycam]
... the template we use now for those tests might be ported across to modules etc.
07:52:24 [heycam]
... so it'd be good to decide
07:52:35 [heycam]
... the one we're using the 1.1F2 is very close to the 1.2T one
07:52:42 [heycam]
... apart from a couple of extra fields
07:52:48 [heycam]
CL: it's using id instead of xml:id presumably?
07:52:49 [heycam]
AG: yes
07:53:13 [heycam]
CM: nothing specific to 1.1 that would prevent us from using that template for modules etc. would it?
07:53:24 [heycam]
AG: no, it's usable for all modules
07:53:41 [heycam]
... the TestCase element, the bit that has all the metadata for the test, that bit is using xlink:href to reference into the spec
07:53:45 [heycam]
... that's the only odd thing it's doing
07:53:51 [heycam]
... otherwise it's the same as the tiny template
07:54:23 [heycam]
CM: i don't know if it's useful to have xlink:href attribute named like that
07:54:33 [heycam]
AG: it's on the TestComponent element
07:54:48 [heycam]
... so when we generate the harness it can generate an <a>
07:55:00 [heycam]
CL: if it's being transformed anyway it doesn't matter what it's called
07:55:32 [heycam]
ACTION: Anthony to draft the template for SVG 2.0 and modules and present it at the next telcon
07:55:32 [trackbot]
Created ACTION-2631 - Draft the template for SVG 2.0 and modules and present it at the next telcon [on Anthony Grasso - due 2009-07-08].
07:56:26 [heycam]
Topic: RNG for 1.1
07:56:34 [heycam]
DS: berjon is willing to help us out and give us guidance
07:56:43 [heycam]
... but not to do the whole thing
07:57:05 [heycam]
... he's pretty busy with other stuff too
07:57:34 [heycam]
... he can't join as vodafone rep
07:58:05 [heycam]
... he sent me a fairly detailed email and i'll ask if i can forward it on to us
08:06:23 [Zakim]
-ed
08:06:24 [Zakim]
-heycam
08:06:24 [Zakim]
-anthony
08:06:26 [Zakim]
-Doug_Schepers
08:06:27 [Zakim]
-jwatt
08:06:28 [Zakim]
-??P5
08:06:29 [Zakim]
GA_SVGWG()2:30AM has ended
08:06:30 [Zakim]
Attendees were Doug_Schepers, ed, heycam, anthony, jwatt, [IPcaller]
08:23:27 [ChrisL]
Present: Doug_Schepers, ed, heycam, anthony, jwatt, ChrisL
08:23:45 [ChrisL]
rrsagent, make minutes
08:23:45 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/07/01-svg-minutes.html ChrisL
08:26:45 [shepazu]
shepazu has joined #svg
08:41:45 [heycam]
heycam has joined #svg
08:42:12 [heycam]
RRSAgent, make minutes
08:42:12 [RRSAgent]
I have made the request to generate http://www.w3.org/2009/07/01-svg-minutes.html heycam
08:44:37 [heycam]
heycam has joined #svg
08:44:49 [ChrisL]
cam, http://dev.w3.org/SVG/modules/color/master/SVGColor.html#syntax
08:45:40 [heycam]
ChrisL, thanks i'll take a look in a while
09:01:40 [ChrisL]
ChrisL has joined #svg
10:55:29 [karl]
karl has joined #svg