06:29:11 <RRSAgent> RRSAgent has joined #svg
06:29:11 <RRSAgent> logging to http://www.w3.org/2009/08/19-svg-irc
06:29:13 <trackbot> RRSAgent, make logs public
06:29:15 <trackbot> Zakim, this will be GA_SVGWG
06:29:15 <Zakim> ok, trackbot; I see GA_SVGWG()2:30AM scheduled to start in 1 minute
06:29:16 <trackbot> Meeting: SVG Working Group Teleconference
06:29:16 <trackbot> Date: 19 August 2009
06:29:34 <Zakim> GA_SVGWG()2:30AM has now started
06:29:41 <Zakim> +Doug_Schepers
06:30:22 <Zakim> +??P1
06:30:31 <ed> Zakim, ? is me
06:30:31 <Zakim> +ed; got it
06:31:00 <Zakim> +??P2
06:31:01 <heycam> Zakim, ??P2 is me
06:31:01 <Zakim> +heycam; got it
06:33:08 <Zakim> +??P3
06:33:28 <anthony> Zakim, ??P3 is me
06:33:28 <Zakim> +anthony; got it
06:35:23 <ed> Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0051.html
06:35:27 <ChrisL> ChrisL has joined #svg
06:35:51 <ed> Zakim, pick a victim
06:35:51 <Zakim> Not knowing who is chairing or who scribed recently, I propose heycam
06:36:04 <heycam> Scribe: Cameron
06:36:06 <heycam> ScribeNick: heycam
06:36:13 <heycam> Chair: Erik
06:36:30 <heycam> Topic: SVG Open F2F
06:36:35 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/SVGOpen_F2F_2009
06:36:37 <Zakim> +ChrisL
06:36:48 <heycam> ED: i was hoping jwatt would be here to get confirmation on having a meeting venue
06:36:54 <heycam> Zakim, who is on the call?
06:36:54 <Zakim> On the phone I see Doug_Schepers, ed, heycam, anthony, ChrisL
06:37:13 <heycam> ED: i would like to have some up to date information on the wiki page
06:37:21 <heycam> ... it's fairly soon
06:37:38 <heycam> ... is there a registration page?
06:37:52 <heycam> CL: no, we could go ahead and make one
06:38:32 <heycam> ED: agenda requests for the f2f would be good to have on that page
06:38:52 <heycam> ... i'm guessing that if we wanted to push out the second edition spec we'd spend most of the time doing that, but we'll probably have other things to talk about to
06:38:58 <heycam> CL: i'd like status reports on each of the modules
06:39:06 <heycam> DS: that's a good idea
06:39:47 <heycam> Topic: SVG 1.1 Second Edition progress
06:40:01 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition
06:40:05 <heycam> CM: i've written a few more tests
06:40:20 <heycam> CL: i see you've done my tests
06:40:28 <heycam> ... i've started reviewing the tests you wrote for my section
06:41:36 <heycam> CM: pink cells in the tables indicate what needs to be done next
06:42:29 <heycam> ... how about we review ones in our own sections if the tests have been written by someone else (e.g. me)
06:42:52 <heycam> AG: a few from my table shouldn't need tests
06:42:57 <ChrisL> I will take painting-stroke-09-t.svg styling-pres-02-f.svg 	script-elem-01-b.svg styling-elem-01-b.svg styling-elem-02-b.svg 	text-ws-03-t.svg
06:43:03 <heycam> ... i've also updated the 1.1 test template
06:43:11 <ChrisL> not sure about 	types-dom-05-b.svg
06:43:55 <heycam> CL: I also took the three in cameron's "other tests" section
06:45:00 <heycam> CM: there are four errata not yet merged
06:45:08 <heycam> ... one from jonathan and three from doug
06:45:15 <heycam> DS: they're all waiting on jonathan actually
06:46:03 <heycam> ED: think we're in good shape for publishing this at the f2f?
06:46:05 <heycam> CM: yes i think so
06:47:15 <heycam> Topic: SVG in text/html issue status
06:47:45 <heycam> DS: maciej has been going through open issues in the HTML WG and proposing to close the SVG in text/html issue if there are no objections within a few days
06:48:06 <heycam> CL: nothing in the spec says that svg has to be rendered, only parsed into a dom
06:48:11 <shepazu> http://lists.w3.org/Archives/Public/public-html/2009Aug/0706.html
06:48:24 <heycam> ... there should be sections talking about rendering of svg
06:48:45 <heycam> ... at least the basics of it, making a new block and rendering it
06:49:01 <heycam> ... if you had an implementation that merely stuffed the svg in the dom and did nothing else with it, it would be conformant at the moment
06:49:48 <heycam> CM: i wonder what other reservations we still have that we can remind them of
06:49:54 <heycam> ED: whitelisting of elements, case fixup tables
06:50:17 <heycam> DS: maybe we shouldn't talk about whitelisting until we finish the integration spec
06:50:23 <heycam> ED: could still keep the issue open though
06:51:06 <heycam> CM: they plan on going to LC in october, can we get the integration stuff there by then so that we can propose that as a solution?
06:51:09 <heycam> DS: it's doable
06:51:22 <heycam> ... maybe, maybe not
06:52:31 <heycam> ... all we have to do is have the integration spec in LC the same time as theirs
06:52:49 <heycam> CM: can we even have it in normal WD?  since that's one level before.
06:52:52 <heycam> DS: yeah, i think so
06:53:03 <heycam> ... even a CR can reference a WD
06:53:09 <heycam> ... but we should be close to being done nevertheless
06:53:48 <heycam> ... i spent some time today trying to find instances where there were inconsistencies in the browsers wrt various features
06:53:53 <heycam> ... i found some issues with foreignObject
06:54:20 <heycam> ... svg in xhtml is fairly consistent, when it's supported
06:54:45 <heycam> ... i don't think the behaviour's specified necessarily
06:54:58 <heycam> ... e.g. if you have a single html document and two different svg fragments in it
06:55:07 <heycam> ... one has a use that uses something in the other fragment, all three browsers seem to support that
06:55:16 <heycam> ... not sure if that falls out of the model or if it needs to be specified
06:55:29 <heycam> ED: I think it needs to be specified, i don't think SVG itself says anything about it
06:55:49 <heycam> CL: it's sort of an obvious thing, but in the spec we're fairly careful to talk about either our own tree or an external document
06:55:58 <heycam> ... in particular there's no same-origin stuff affecting that
06:56:25 <heycam> ... i could imagine an impl triggering security code despite the fact that it's in the same document, just a different svg fragment
06:56:33 <heycam> DS: there are open questions about where that stuff gets specified
06:56:56 <heycam> ... and it would be nice if we found an example of something that worked differently between browsers
06:57:12 <heycam> CL: also we should send in a bunch of examples that do work
06:57:37 <heycam> ... there are things that work differently in the html serialization
06:57:39 <heycam> DS: i'm not sure about that
06:57:49 <heycam> CL: once it's implemented it should be the same
06:57:55 <heycam> ... but currently it's not
06:58:21 <heycam> CM: so this will go in the integration spec?
06:58:24 <heycam> DS: it's a possibility
06:58:37 <heycam> ED: what kind of css box is created by an svg element?  is it specified?
06:58:44 <heycam> CL: no, could be a new block formatting context
06:59:13 <heycam> DS: i'm thinking two integration specs. one for svg in other specs, and the other for foreign languages in svg.
06:59:19 <heycam> ... an obvious example is html in svg
06:59:34 <heycam> ED: it'd be useful to clear up the things about foreignObject that are different between browsers
06:59:49 <heycam> ... some things sort of work but it's not the most tested or good working feature
06:59:55 <heycam> DS: opera has some strange behaviour with foreignObject
07:00:06 <heycam> ... but it's illustrative of the considerations we need to make
07:00:17 <heycam> ... one thing is that essentially foreignObject should be treated like a frame, and html should be rendered inside that space
07:00:31 <heycam> ... another is that it's getting rasterised at the wrong point
07:00:45 <heycam> ... and the third i noticed is that you can't really select text in opera in an html foreignObject
07:00:49 <heycam> ED: that might be a side effect of other bugs
07:01:04 <heycam> DS: but it made me think of other problems i could see with mixing svg and html, like occlusion/pointer-events
07:01:16 <heycam> ... we need to solve those for inline svg in html and vice versa
07:01:51 <heycam> CM: are these related things to the html issue?
07:02:00 <heycam> DS: yes we should point out there are many unresolved things, not show stoppers, but need to be defined
07:02:11 <heycam> ... it may be that the html wg says to define them in svg
07:02:22 <heycam> CL: which is fine, but html should normatively reference svg for that
07:03:25 <heycam> DS: we should mail the html wg about the issue
07:03:54 <heycam> ED: i think a normative reference to svg would be a nice thing to have
07:04:02 <heycam> DS: the spec does normatively reference SVG Tiny 1.2 at this point
07:04:08 <heycam> CM: interesting
07:04:17 <heycam> ED: last time i looked at the spec there weren't any references at all
07:04:20 <heycam> DS: they've been added recently
07:04:43 <heycam> CM: i wonder why it's a reference to 1.2T
07:04:46 <heycam> CL: it has better wording
07:04:51 <heycam> ED: but it doesn't cover all of the elements
07:04:54 <heycam> CL: it doesn't reference 1.1 as well?
07:04:55 <heycam> DS: no
07:04:57 <heycam> CL: hmm
07:05:05 <heycam> DS: we should probably ask for it to reference both
07:05:13 <heycam> ED: in 1.2T it's a bit more limited in how references work
07:05:20 <heycam> DS: 1.1 is what most browsers are doing anyway
07:05:35 <heycam> ED: that's what's working in XHTML atm anyway
07:06:37 <heycam> ED: so, the css box thing, limited external references with 1.2T
07:06:43 <heycam> DS: the occlusion/pointer-events too
07:07:02 <heycam> CM: and the parser table spec location
07:09:49 <heycam> ED: you can mention as well that we're doing the 1.1 second edition
07:10:18 <heycam> ACTION: cameron to mail the htmlwg
07:10:19 <trackbot> Created ACTION-2652 - Mail the htmlwg [on Cameron McCormack - due 2009-08-26].
07:10:45 <heycam> Topic: canvas breakout
07:10:47 <ed> http://www.w3.org/mid/4A89FB30.6090109@w3.org
07:11:01 <heycam> DS: some people thought it needed to be broken out for accessibility
07:11:13 <heycam> ... but this is something i suggested a few years ago
07:11:28 <heycam> ... it makes sense to me that svg should be able to use canvas, and to define stuff it one spec and reference it from both html and svg
07:11:51 <heycam> ED: i took a quick look, i guess for the most part it looked fine
07:12:06 <heycam> ... the only concern i had is that the canvas element api was inheriting from element
07:12:26 <heycam> ... if it's a complete separate interface with no inheritance i think it's easier to make other interfaces inherit from that
07:12:37 <heycam> ... e.g. HTMLCanvasElement inherits from HTMLElement which inherits from Element already
07:12:59 <heycam> ... unless you need to inherit it directly for some reason, i think each spec (svg/html) should be doing the inheriting to Element
07:13:14 <heycam> action: erik to mail public-canvas-api about inheriting from Element
07:13:14 <trackbot> Created ACTION-2653 - Mail public-canvas-api about inheriting from Element [on Erik Dahlström - due 2009-08-26].
07:14:15 <heycam> DS: one other thing, for pattern (and other uses) you can reference an html <video>, <img> or <canvas> element
07:14:23 <heycam> ... that should be made more generic, so you can use an <svg:image> element too
07:15:03 <heycam> ... this spec should probably just define that it can take any raster based image element as an argument
07:15:09 <heycam> ... and that the host language defines what types that can be
07:15:23 <heycam> ED: host language defines how you get the raster image that the canvas draws
07:15:31 <heycam> ... that'd be pretty simple to pull out urls from the svg:image element
07:15:53 <heycam> CM: was roc working on painting arbitrary html elements to a canvas at one point?
07:16:04 <heycam> DS: don't recall
07:16:38 <ChrisL> form at http://www.w3.org/2002/09/wbs/19480/SVG200909/
07:16:43 <Zakim> -Doug_Schepers
07:17:06 <heycam> Topic: Media Fragments use cases and requirements review
07:17:12 <heycam> http://www.w3.org/mid/20090813223118.GA26779@wok.mcc.id.au
07:17:19 <heycam> ED: assign actions for it?
07:17:25 <heycam> ... it's a pretty long document, might be useful for us to review it
07:17:34 <heycam> CL: i think we should review it, it will directly affect us since we have a video element
07:17:48 <heycam> ... it's not just a uc&r document, it's like a first draft -- ways to solve it as well as the use cases it's planning to solve
07:18:10 <heycam> ... there'll be lots of other opportunities to review, but we should do the review now
07:18:13 <heycam> ... i've started reading it
07:18:49 <heycam> ... when do they need comments by?
07:18:58 <heycam> s/.../CM: /
07:19:08 <heycam> CL: i think they're planning to publish a second version of this document soon
07:19:16 <heycam> ... maybe by the TP
07:19:23 <heycam> ED: says publish in september
07:19:37 <heycam> ... i notice some errors in their svg snippets
07:20:03 <heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Media_Fragments_Review
07:21:00 <heycam> action: cameron review media fragments uc&r document
07:21:00 <trackbot> Created ACTION-2654 - Review media fragments uc&r document [on Cameron McCormack - due 2009-08-26].
07:21:22 <heycam> action: erik review media fragments uc&r document
07:21:22 <trackbot> Created ACTION-2655 - Review media fragments uc&r document [on Erik Dahlström - due 2009-08-26].
07:22:44 <heycam> Topic: filterRes rounding [www-svg]
07:22:49 <heycam> http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de
07:23:37 <heycam> ED: i think olaf is probably right in his analysis
07:24:30 <heycam> ... the issue is how you're interpreting filterRes and how you apply it
07:24:55 <heycam> ... i'm wondering if he's saying that it's not really a pixel length, just a unitless value
07:25:13 <heycam> ... i have an action to write tests for filterRes anyway
07:25:33 <heycam> action: erik to investigate filterRes mail http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de
07:25:34 <trackbot> Created ACTION-2656 - Investigate filterRes mail http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de [on Erik Dahlström - due 2009-08-26].
07:26:37 <heycam> Topic: feGaussianBlur [www-svg]
07:26:41 <heycam> http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html
07:26:45 <heycam> ED: i think he's right here
07:26:49 <heycam> ... gaussian blur can depend on x and y
07:27:00 <heycam> ... so that you can blur it only one direction for example
07:27:33 <heycam> CM: does the formula in the spec only handle a single std deviation value?
07:27:36 <heycam> ED: yes
07:27:58 <heycam> ... but maybe you're meant to infer the formula for handling x/y std deviation
07:28:28 <heycam> CM: well it would be good to have the actual formula in there
07:28:35 <heycam> ED: yes it makes sense to split it into two parts like he provides
07:28:44 <heycam> CL: what he proposes seems reasonable to me
07:29:08 <heycam> CM: is this likely to be implemented un-interoperably?
07:29:19 <heycam> ED: we had a bug on it before that ignored the y component of the std deviation
07:29:29 <heycam> CL: i agree about his points on the discontinuity
07:30:01 <heycam> ... if you allow both negative/positive values you're squaring it so there's no problem
07:30:14 <heycam> ED: i could get this done for 1.1SE too
07:30:20 <heycam> s/too/ as well as the filter module/
07:31:20 <heycam> ED: i agree i think it's no problem allowing negative numbers
07:31:33 <heycam> CL: a zero value does result in no effect, it produces no blur
07:31:47 <heycam> ... i'd rather say a zero value results in no blur, and explicitly say that both negative and zero are allowed
07:32:12 <eseidel_> eseidel_ has joined #svg
07:32:52 <heycam> action: erik fix gaussian blur in 1.1SE and filters module per http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html
07:32:52 <trackbot> Created ACTION-2657 - Fix gaussian blur in 1.1SE and filters module per http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html [on Erik Dahlström - due 2009-08-26].
07:33:23 <heycam> CL: should have a test that goes through two positive values, and one that goes from negative to positive through zero
07:34:08 <heycam> action-2657: write test cases too
07:34:08 <trackbot> ACTION-2657 Fix gaussian blur in 1.1SE and filters module per http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html notes added
07:34:32 <heycam> Topic: Inheritance during SVG animation of CSS properties
07:34:39 <heycam> http://www.w3.org/mid/4A64F46A.6000900@mozilla.com
07:37:27 <heycam> CM: [waffling about the question, and what smil says about override style sheets etc. for property animation]
07:37:38 <heycam> ED: i'd like to investigate this further, look at bug, etc.
07:37:45 <heycam> ... and then i'll reply on www-svg
07:38:08 <heycam> action: erik investigate "Inheritance during SVG animation of CSS properties" and reply on www-svg http://www.w3.org/mid/4A64F46A.6000900@mozilla.com
07:38:08 <trackbot> Created ACTION-2658 - Investigate "Inheritance during SVG animation of CSS properties" and reply on www-svg http://www.w3.org/mid/4A64F46A.6000900@mozilla.com [on Erik Dahlström - due 2009-08-26].
07:38:18 <heycam> Topic: possible errata: SVG 1.1/1.2 tspan Element dx Attribute definition [www-svg]
07:38:24 <heycam> http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btinternet.com
07:38:47 <heycam> ED: he is finding differences in whitespace handling between nodes
07:38:51 <heycam> ... in text length calculations etc.
07:39:01 <heycam> ... no, this is a different thread sorry
07:40:52 <heycam> CM: in his test he has a <tspan dy="2.5em"/>
07:40:58 <heycam> CL: and another one with a space
07:42:04 <heycam> ... you could do it by putting a different font on the tspan, and then having a dot or something in the text content
07:42:13 <heycam> ED: the unicode spec forbids you from rendering spaces
07:42:20 <heycam> CL: you can say how wide a space is though
07:42:28 <heycam> ... so you could have a font with an advance of 50px for a space character
07:42:35 <heycam> s/in the text content/for the space glyph/
07:43:52 <heycam> CM: ken stacey's reply says that the one with the space should affect the position, while the one with no child content shouldn't
07:43:58 <heycam> ... and he quotes the spec
07:44:44 <Zakim> -heycam
07:45:13 <Zakim> +[IPcaller]
07:45:15 <heycam> Zakim, [ is me
07:45:15 <Zakim> +heycam; got it
07:46:01 <heycam> ED: so his reply is sufficient?
07:46:04 <heycam> CM: i think so
07:46:09 <heycam> ... be good as a test case
07:46:30 <heycam> action: cameron make a test for dx/dy like http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btinternet.com
07:46:31 <trackbot> Created ACTION-2659 - Make a test for dx/dy like http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btinternet.com [on Cameron McCormack - due 2009-08-26].
07:47:01 <heycam> Topic: CSS images module [www-svg]
07:47:07 <heycam> http://www.w3.org/mid/200907281206.29399.bert@w3.org
07:47:31 <heycam> CL: the csswg is looking at gradients at the moment
07:47:35 <heycam> CM: as part of the images module?
07:47:37 <heycam> CL: yes
07:47:51 <heycam> ... two syntaxes are proposed, one of which is supported by webkit and one by firefox 3.6a
07:48:00 <heycam> ... so they're working out which to use
07:48:18 <heycam> ... they're looking to canvas about how to do gradients
07:48:33 <heycam> CM: it'd be nice to know what differences there are between canvas and svg gradients
07:48:36 <heycam> CL: if there are any
07:49:05 <anthony> http://dev.w3.org/html5/canvas-api/canvas-2d-api.html#colors-and-styles
07:49:58 <heycam> AG: looks like you can do conical gradients
07:50:43 <heycam> The createRadialGradient(x0, y0, r0, x1, y1, r1)  method takes six arguments, the first three representing the start circle with origin (x0, y0) and radius r0, and the last three representing the end circle with origin (x1, y1) and radius r1.
07:51:41 <heycam> ... it doesn't sound like an svg radial gradient
07:51:54 <anthony> This effectively creates a cone, touched by the two circles defined in the creation of the gradient, with the part of the cone before the start circle (0.0) using the color of the first offset, the part of the cone after the end circle (1.0) using the color of the last offset, and areas outside the cone untouched by the gradient (transparent black).
07:54:52 <heycam> AG: will csswg will take on different unit sizes?
07:55:04 <heycam> CL: they'll probably allow you to use ems and so on, but not a coordinate system
07:55:49 <heycam> CM: in that mail bert mentions also image slices
07:56:09 <heycam> http://www.w3.org/TR/2009/WD-css3-images-20090723/#url
07:57:55 <heycam> CL: they could replace that example with logos.svg#viewBox(...)
07:59:56 <ChrisL> http://dev.w3.org/csswg/css3-images/
08:00:14 <heycam> ... they also define image sprites
08:00:18 <heycam> ED: i like the image fallback thing
08:01:13 <heycam> CM: the fallback syntax is different from svg's with paint servers
08:01:18 <heycam> ... might be good not to have it be different
08:01:47 <heycam> ED: the feature itself is something that would be nice to have, not sure about the syntax
08:01:51 <ChrisL> "Discussed adding gradients to css3-images. Straw poll indicates yes,
08:01:51 <ChrisL>      there is support for this in the WG. Several people sympathized with
08:01:51 <ChrisL>      Bert's argument argument against expanding the scope of CSS too much,
08:01:51 <ChrisL>      but none except Bert went so far as to object to the proposal for
08:01:51 <ChrisL>      gradients. Hyatt and roc will draft a combined proposal. fantasai
08:01:52 <ChrisL>      suggests simplifying the syntax.
08:01:54 <ChrisL> "
08:01:58 <ChrisL> http://lists.w3.org/Archives/Public/www-style/2009Aug/0128.html
08:06:31 <heycam> action: erik reply to bert's www-svg mail about css3-images
08:06:31 <trackbot> Created ACTION-2660 - Reply to bert's www-svg mail about css3-images [on Erik Dahlström - due 2009-08-26].
08:07:23 <Zakim> -ed
08:07:24 <Zakim> -ChrisL
08:07:24 <Zakim> -heycam
08:07:25 <Zakim> -anthony
08:07:25 <Zakim> GA_SVGWG()2:30AM has ended
08:07:26 <Zakim> Attendees were Doug_Schepers, ed, heycam, anthony, ChrisL, [IPcaller]
08:07:36 <heycam> RRSAgent, make minutes
08:07:36 <RRSAgent> I have made the request to generate http://www.w3.org/2009/08/19-svg-minutes.html heycam
10:15:31 <karl> karl has joined #svg
11:28:38 <heycam> heycam has joined #svg
12:11:54 <anthony> anthony has joined #svg