- From: Alexander Adam <alexander.adam@examotion.com>
- Date: Wed, 19 Aug 2009 10:44:57 +0200
- To: "'Cameron McCormack'" <cam@mcc.id.au>, <www-svg@w3.org>
Just a quick note -- we're currently finishing implementing <canvas> support into Renesis V3 including quite a few demos as well. We're currently inheriting it from Element though. mfG / Regards, Alexander Adam -------------------------------------------------------- examotion GmbH Ostendstraße 115, D-90482 Nuremberg Fon: +49 911 - 504901-11 Mob: +49 170 - 3073827 Fax: +49 911 - 504901-20 E-Mail: alexander.adam@examotion.com Web: http://www.examotion.com Amtsgericht Nürnberg HRB Nr.: 23803 Gerichtsstandort: Nürnberg -------------------------------------------------------- LEGAL DISCLAIMER: The information in this email is confidential and may be legally privileged. It is intended solely for the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. -------------------------------------------------------- > -----Original Message----- > From: public-svg-wg-request@w3.org [mailto:public-svg-wg-request@w3.org] > On Behalf Of Cameron McCormack > Sent: Mittwoch, 19. August 2009 10:10 > To: www-svg@w3.org > Subject: Minutes, 19 August 2009 SVG WG telcon > > Hello www-svg. > > The minutes from the 19 August 2009 telcon are available here: > > http://www.w3.org/2009/08/19-svg-minutes.html > > and below as text for tracker to notice. > > Thanks, > > Cameron > > ---- > > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > SVG Working Group Teleconference > > 19 Aug 2009 > > [2]Agenda > > [2] http://lists.w3.org/Archives/Public/public-svg- > wg/2009JulSep/0051.html > > See also: [3]IRC log > > [3] http://www.w3.org/2009/08/19-svg-irc > > Attendees > > Present > Doug_Schepers, ed, heycam, anthony, ChrisL, [IPcaller] > > Regrets > Chair > Erik > > Scribe > Cameron > > Contents > > * [4]Topics > 1. [5]SVG Open F2F > 2. [6]SVG 1.1 Second Edition progress > 3. [7]SVG in text/html issue status > 4. [8]canvas breakout > 5. [9]Media Fragments use cases and requirements review > 6. [10]filterRes rounding [www-svg] > 7. [11]feGaussianBlur [www-svg] > 8. [12]Inheritance during SVG animation of CSS properties > 9. [13]possible errata: SVG 1.1/1.2 tspan Element dx Attribute > definition [www-svg] > 10. [14]CSS images module [www-svg] > * [15]Summary of Action Items > _________________________________________________________ > > > > <trackbot> Date: 19 August 2009 > > <scribe> Scribe: Cameron > > <scribe> ScribeNick: heycam > > SVG Open F2F > > [16]http://www.w3.org/Graphics/SVG/WG/wiki/SVGOpen_F2F_2009 > > [16] http://www.w3.org/Graphics/SVG/WG/wiki/SVGOpen_F2F_2009 > > ED: i was hoping jwatt would be here to get confirmation on having a > meeting venue > ... i would like to have some up to date information on the wiki > page > ... it's fairly soon > ... is there a registration page? > > CL: no, we could go ahead and make one > > ED: agenda requests for the f2f would be good to have on that page > ... 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 > > CL: i'd like status reports on each of the modules > > DS: that's a good idea > > SVG 1.1 Second Edition progress > > [17]http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_ > Edition > > [17] > http://www.w3.org/Graphics/SVG/WG/wiki/Errata_in_SVG_1.1_Second_Edition > > CM: i've written a few more tests > > CL: i see you've done my tests > ... i've started reviewing the tests you wrote for my section > > CM: pink cells in the tables indicate what needs to be done next > ... how about we review ones in our own sections if the tests have > been written by someone else (e.g. me) > > AG: a few from my table shouldn't need tests > > <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 > > AG: i've also updated the 1.1 test template > > <ChrisL> not sure about types-dom-05-b.svg > > CL: I also took the three in cameron's "other tests" section > > CM: there are four errata not yet merged > ... one from jonathan and three from doug > > DS: they're all waiting on jonathan actually > > ED: think we're in good shape for publishing this at the f2f? > > CM: yes i think so > > SVG in text/html issue status > > 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 > > CL: nothing in the spec says that svg has to be rendered, only > parsed into a dom > > <shepazu> > [18]http://lists.w3.org/Archives/Public/public-html/2009Aug/0706.htm > l > > [18] http://lists.w3.org/Archives/Public/public- > html/2009Aug/0706.html > > CL: there should be sections talking about rendering of svg > ... at least the basics of it, making a new block and rendering it > ... 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 > > CM: i wonder what other reservations we still have that we can > remind them of > > ED: whitelisting of elements, case fixup tables > > DS: maybe we shouldn't talk about whitelisting until we finish the > integration spec > > ED: could still keep the issue open though > > 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? > > DS: it's doable > ... maybe, maybe not > ... all we have to do is have the integration spec in LC the same > time as theirs > > CM: can we even have it in normal WD? since that's one level before. > > DS: yeah, i think so > ... even a CR can reference a WD > ... but we should be close to being done nevertheless > ... i spent some time today trying to find instances where there > were inconsistencies in the browsers wrt various features > ... i found some issues with foreignObject > ... svg in xhtml is fairly consistent, when it's supported > ... i don't think the behaviour's specified necessarily > ... e.g. if you have a single html document and two different svg > fragments in it > ... one has a use that uses something in the other fragment, all > three browsers seem to support that > ... not sure if that falls out of the model or if it needs to be > specified > > ED: I think it needs to be specified, i don't think SVG itself says > anything about it > > 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 > ... in particular there's no same-origin stuff affecting that > ... i could imagine an impl triggering security code despite the > fact that it's in the same document, just a different svg fragment > > DS: there are open questions about where that stuff gets specified > ... and it would be nice if we found an example of something that > worked differently between browsers > > CL: also we should send in a bunch of examples that do work > ... there are things that work differently in the html serialization > > DS: i'm not sure about that > > CL: once it's implemented it should be the same > ... but currently it's not > > CM: so this will go in the integration spec? > > DS: it's a possibility > > ED: what kind of css box is created by an svg element? is it > specified? > > CL: no, could be a new block formatting context > > DS: i'm thinking two integration specs. one for svg in other specs, > and the other for foreign languages in svg. > ... an obvious example is html in svg > > ED: it'd be useful to clear up the things about foreignObject that > are different between browsers > ... some things sort of work but it's not the most tested or good > working feature > > DS: opera has some strange behaviour with foreignObject > ... but it's illustrative of the considerations we need to make > ... one thing is that essentially foreignObject should be treated > like a frame, and html should be rendered inside that space > ... another is that it's getting rasterised at the wrong point > ... and the third i noticed is that you can't really select text in > opera in an html foreignObject > > ED: that might be a side effect of other bugs > > DS: but it made me think of other problems i could see with mixing > svg and html, like occlusion/pointer-events > ... we need to solve those for inline svg in html and vice versa > > CM: are these related things to the html issue? > > DS: yes we should point out there are many unresolved things, not > show stoppers, but need to be defined > ... it may be that the html wg says to define them in svg > > CL: which is fine, but html should normatively reference svg for > that > > DS: we should mail the html wg about the issue > > ED: i think a normative reference to svg would be a nice thing to > have > > DS: the spec does normatively reference SVG Tiny 1.2 at this point > > CM: interesting > > ED: last time i looked at the spec there weren't any references at > all > > DS: they've been added recently > > CM: i wonder why it's a reference to 1.2T > > CL: it has better wording > > ED: but it doesn't cover all of the elements > > CL: it doesn't reference 1.1 as well? > > DS: no > > CL: hmm > > DS: we should probably ask for it to reference both > > ED: in 1.2T it's a bit more limited in how references work > > DS: 1.1 is what most browsers are doing anyway > > ED: that's what's working in XHTML atm anyway > ... so, the css box thing, limited external references with 1.2T > > DS: the occlusion/pointer-events too > > CM: and the parser table spec location > > ED: you can mention as well that we're doing the 1.1 second edition > > <scribe> ACTION: cameron to mail the htmlwg [recorded in > [19]http://www.w3.org/2009/08/19-svg-minutes.html#action01] > > <trackbot> Created ACTION-2652 - Mail the htmlwg [on Cameron > McCormack - due 2009-08-26]. > > canvas breakout > > <ed> [20]http://www.w3.org/mid/4A89FB30.6090109@w3.org > > [20] http://www.w3.org/mid/4A89FB30.6090109@w3.org > > DS: some people thought it needed to be broken out for accessibility > ... but this is something i suggested a few years ago > ... 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 > > ED: i took a quick look, i guess for the most part it looked fine > ... the only concern i had is that the canvas element api was > inheriting from element > ... if it's a complete separate interface with no inheritance i > think it's easier to make other interfaces inherit from that > ... e.g. HTMLCanvasElement inherits from HTMLElement which inherits > from Element already > ... unless you need to inherit it directly for some reason, i think > each spec (svg/html) should be doing the inheriting to Element > > <scribe> ACTION: erik to mail public-canvas-api about inheriting > from Element [recorded in > [21]http://www.w3.org/2009/08/19-svg-minutes.html#action02] > > <trackbot> Created ACTION-2653 - Mail public-canvas-api about > inheriting from Element [on Erik Dahlström - due 2009-08-26]. > > DS: one other thing, for pattern (and other uses) you can reference > an html <video>, <img> or <canvas> element > ... that should be made more generic, so you can use an <svg:image> > element too > ... this spec should probably just define that it can take any > raster based image element as an argument > ... and that the host language defines what types that can be > > ED: host language defines how you get the raster image that the > canvas draws > ... that'd be pretty simple to pull out urls from the svg:image > element > > CM: was roc working on painting arbitrary html elements to a canvas > at one point? > > DS: don't recall > > <ChrisL> form at [22]http://www.w3.org/2002/09/wbs/19480/SVG200909/ > > [22] http://www.w3.org/2002/09/wbs/19480/SVG200909/ > > Media Fragments use cases and requirements review > > [23]http://www.w3.org/mid/20090813223118.GA26779@wok.mcc.id.au > > [23] http://www.w3.org/mid/20090813223118.GA26779@wok.mcc.id.au > > ED: assign actions for it? > ... it's a pretty long document, might be useful for us to review it > > CL: i think we should review it, it will directly affect us since we > have a video element > ... 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 > ... there'll be lots of other opportunities to review, but we should > do the review now > ... i've started reading it > > CM: when do they need comments by? > > CL: i think they're planning to publish a second version of this > document soon > ... maybe by the TP > > ED: says publish in september > ... i notice some errors in their svg snippets > > [24]http://www.w3.org/Graphics/SVG/WG/wiki/Media_Fragments_Review > > [24] http://www.w3.org/Graphics/SVG/WG/wiki/Media_Fragments_Review > > <scribe> ACTION: cameron review media fragments uc&r document > [recorded in > [25]http://www.w3.org/2009/08/19-svg-minutes.html#action03] > > <trackbot> Created ACTION-2654 - Review media fragments uc&r > document [on Cameron McCormack - due 2009-08-26]. > > <scribe> ACTION: erik review media fragments uc&r document [recorded > in [26]http://www.w3.org/2009/08/19-svg-minutes.html#action04] > > <trackbot> Created ACTION-2655 - Review media fragments uc&r > document [on Erik Dahlström - due 2009-08-26]. > > filterRes rounding [www-svg] > > [27]http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > > [27] http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > > ED: i think olaf is probably right in his analysis > ... the issue is how you're interpreting filterRes and how you apply > it > ... i'm wondering if he's saying that it's not really a pixel > length, just a unitless value > ... i have an action to write tests for filterRes anyway > > <scribe> ACTION: erik to investigate filterRes mail > [28]http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > [recorded in > [29]http://www.w3.org/2009/08/19-svg-minutes.html#action05] > > [28] http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > > <trackbot> Created ACTION-2656 - Investigate filterRes mail > [30]http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > [on Erik Dahlström - due 2009-08-26]. > > [30] http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > > feGaussianBlur [www-svg] > > [31]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > > [31] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > > ED: i think he's right here > ... gaussian blur can depend on x and y > ... so that you can blur it only one direction for example > > CM: does the formula in the spec only handle a single std deviation > value? > > ED: yes > ... but maybe you're meant to infer the formula for handling x/y std > deviation > > CM: well it would be good to have the actual formula in there > > ED: yes it makes sense to split it into two parts like he provides > > CL: what he proposes seems reasonable to me > > CM: is this likely to be implemented un-interoperably? > > ED: we had a bug on it before that ignored the y component of the > std deviation > > CL: i agree about his points on the discontinuity > ... if you allow both negative/positive values you're squaring it so > there's no problem > > ED: i could get this done for 1.1SE as well as the filter module > ... i agree i think it's no problem allowing negative numbers > > CL: a zero value does result in no effect, it produces no blur > ... i'd rather say a zero value results in no blur, and explicitly > say that both negative and zero are allowed > > <scribe> ACTION: erik fix gaussian blur in 1.1SE and filters module > per > [32]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > [recorded in > [33]http://www.w3.org/2009/08/19-svg-minutes.html#action06] > > [32] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > > <trackbot> Created ACTION-2657 - Fix gaussian blur in 1.1SE and > filters module per > [34]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > [on Erik Dahlström - due 2009-08-26]. > > [34] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > > CL: should have a test that goes through two positive values, and > one that goes from negative to positive through zero > > action-2657: write test cases too > > <trackbot> ACTION-2657 Fix gaussian blur in 1.1SE and filters module > per > [35]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > notes added > > [35] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > > Inheritance during SVG animation of CSS properties > > [36]http://www.w3.org/mid/4A64F46A.6000900@mozilla.com > > [36] http://www.w3.org/mid/4A64F46A.6000900@mozilla.com > > CM: [waffling about the question, and what smil says about override > style sheets etc. for property animation] > > ED: i'd like to investigate this further, look at bug, etc. > ... and then i'll reply on www-svg > > <scribe> ACTION: erik investigate "Inheritance during SVG animation > of CSS properties" and reply on www-svg > [37]http://www.w3.org/mid/4A64F46A.6000900@mozilla.com recorded in > [38]http://www.w3.org/2009/08/19-svg-minutes.html#action07] > > [37] http://www.w3.org/mid/4A64F46A.6000900@mozilla.com > > <trackbot> Created ACTION-2658 - Investigate "Inheritance during SVG > animation of CSS properties" and reply on www-svg > [39]http://www.w3.org/mid/4A64F46A.6000900@mozilla.com on Erik > Dahlström - due 2009-08-26]. > > [39] http://www.w3.org/mid/4A64F46A.6000900@mozilla.com > > possible errata: SVG 1.1/1.2 tspan Element dx Attribute definition > [www-svg] > > [40]http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btint > ernet.com > > [40] http://www.w3.org/mid/8429F2BC-8CC3-4075-8096- > 793E02C1E6BD@btinternet.com > > ED: he is finding differences in whitespace handling between nodes > ... in text length calculations etc. > ... no, this is a different thread sorry > > CM: in his test he has a <tspan dy="2.5em"/> > > CL: and another one with a space > ... you could do it by putting a different font on the tspan, and > then having a dot or something for the space glyph > > ED: the unicode spec forbids you from rendering spaces > > CL: you can say how wide a space is though > ... so you could have a font with an advance of 50px for a space > character > > 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 > ... and he quotes the spec > > ED: so his reply is sufficient? > > CM: i think so > ... be good as a test case > > <scribe> ACTION: cameron make a test for dx/dy like > [41]http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btint > ernet.com [recorded in > [42]http://www.w3.org/2009/08/19-svg-minutes.html#action08] > > [41] http://www.w3.org/mid/8429F2BC-8CC3-4075-8096- > 793E02C1E6BD@btinternet.com > > <trackbot> Created ACTION-2659 - Make a test for dx/dy like > [43]http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btint > ernet.com [on Cameron McCormack - due 2009-08-26]. > > [43] http://www.w3.org/mid/8429F2BC-8CC3-4075-8096- > 793E02C1E6BD@btinternet.com > > CSS images module [www-svg] > > [44]http://www.w3.org/mid/200907281206.29399.bert@w3.org > > [44] http://www.w3.org/mid/200907281206.29399.bert@w3.org > > CL: the csswg is looking at gradients at the moment > > CM: as part of the images module? > > CL: yes > ... two syntaxes are proposed, one of which is supported by webkit > and one by firefox 3.6a > ... so they're working out which to use > ... they're looking to canvas about how to do gradients > > CM: it'd be nice to know what differences there are between canvas > and svg gradients > > CL: if there are any > > <anthony> > [45]http://dev.w3.org/html5/canvas-api/canvas-2d-api.html#colors-and > -styles > > [45] http://dev.w3.org/html5/canvas-api/canvas-2d-api.html#colors- > and-styles > > AG: looks like you can do conical gradients > > 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. > > scribe: it doesn't sound like an svg radial gradient > > <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). > > AG: will csswg will take on different unit sizes? > > CL: they'll probably allow you to use ems and so on, but not a > coordinate system > > CM: in that mail bert mentions also image slices > > [46]http://www.w3.org/TR/2009/WD-css3-images-20090723/#url > > [46] http://www.w3.org/TR/2009/WD-css3-images-20090723/#url > > CL: they could replace that example with logos.svg#viewBox(...) > > <ChrisL> [47]http://dev.w3.org/csswg/css3-images/ > > [47] http://dev.w3.org/csswg/css3-images/ > > CL: they also define image sprites > > ED: i like the image fallback thing > > CM: the fallback syntax is different from svg's with paint servers > ... might be good not to have it be different > > ED: the feature itself is something that would be nice to have, not > sure about the syntax > > <ChrisL> "Discussed adding gradients to css3-images. Straw poll > indicates yes, > > <ChrisL> there is support for this in the WG. Several people > sympathized with > > <ChrisL> Bert's argument argument against expanding the scope of CSS > too much, > > <ChrisL> but none except Bert went so far as to object to the > proposal for > > <ChrisL> gradients. Hyatt and roc will draft a combined proposal. > fantasai > > <ChrisL> suggests simplifying the syntax. > > <ChrisL> " > > <ChrisL> > [48]http://lists.w3.org/Archives/Public/www-style/2009Aug/0128.html > > [48] http://lists.w3.org/Archives/Public/www-style/2009Aug/0128.html > > <scribe> ACTION: erik reply to bert's www-svg mail about css3-images > [recorded in > [49]http://www.w3.org/2009/08/19-svg-minutes.html#action09] > > <trackbot> Created ACTION-2660 - Reply to bert's www-svg mail about > css3-images [on Erik Dahlström - due 2009-08-26]. > > Summary of Action Items > > [NEW] ACTION: cameron make a test for dx/dy like > [50]http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btint > ernet.com [recorded in > [51]http://www.w3.org/2009/08/19-svg-minutes.html#action08] > [NEW] ACTION: cameron review media fragments uc&r document [recorded > in [52]http://www.w3.org/2009/08/19-svg-minutes.html#action03] > [NEW] ACTION: cameron to mail the htmlwg [recorded in > [53]http://www.w3.org/2009/08/19-svg-minutes.html#action01] > [NEW] ACTION: erik fix gaussian blur in 1.1SE and filters module per > [54]http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > [recorded in > [55]http://www.w3.org/2009/08/19-svg-minutes.html#action06] > [NEW] ACTION: erik investigate "Inheritance during SVG animation of > CSS properties" and reply on www-svg > [56]http://www.w3.org/mid/4A64F46A.6000900@mozilla.com recorded in > [57]http://www.w3.org/2009/08/19-svg-minutes.html#action07] > [NEW] ACTION: erik reply to bert's www-svg mail about css3-images > [recorded in > [58]http://www.w3.org/2009/08/19-svg-minutes.html#action09] > [NEW] ACTION: erik review media fragments uc&r document [recorded in > [59]http://www.w3.org/2009/08/19-svg-minutes.html#action04] > [NEW] ACTION: erik to investigate filterRes mail > [60]http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > [recorded in > [61]http://www.w3.org/2009/08/19-svg-minutes.html#action05] > [NEW] ACTION: erik to mail public-canvas-api about inheriting from > Element [recorded in > [62]http://www.w3.org/2009/08/19-svg-minutes.html#action02] > > [50] http://www.w3.org/mid/8429F2BC-8CC3-4075-8096- > 793E02C1E6BD@btinternet.com > [54] http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html > [56] http://www.w3.org/mid/4A64F46A.6000900@mozilla.com > [60] http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de > > [End of minutes] > > -- > Cameron McCormack ≝ http://mcc.id.au/
Received on Wednesday, 19 August 2009 08:46:22 UTC