W3C home > Mailing lists > Public > www-svg@w3.org > August 2009

Minutes, 19 August 2009 SVG WG telcon

From: Cameron McCormack <cam@mcc.id.au>
Date: Wed, 19 Aug 2009 18:09:48 +1000
To: www-svg@w3.org
Message-ID: <20090819080948.GA14130@wok.mcc.id.au>
Hello www-svg.

The minutes from the 19 August 2009 telcon are available here:


and below as text for tracker to notice.





      [1] http://www.w3.org/

                               - DRAFT -

                   SVG Working Group Teleconference

19 Aug 2009


      [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


          Doug_Schepers, ed, heycam, anthony, ChrisL, [IPcaller]




     * [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

   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
   ... 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

   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

   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


     [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

   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

   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

   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

   DS: we should mail the html wg about the issue

   ED: i think a normative reference to svg would be a nice thing to

   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

   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

   <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

   <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

   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

   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

   <scribe> ACTION: cameron review media fragments uc&r document
   [recorded in

   <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

   ED: i think olaf is probably right in his analysis
   ... the issue is how you're interpreting filterRes and how you apply
   ... 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
   [recorded in

     [28] http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de

   <trackbot> Created ACTION-2656 - Investigate filterRes mail
   [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

   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

   ED: yes
   ... but maybe you're meant to infer the formula for handling x/y std

   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
   [recorded in

     [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
   [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
   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

   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

     [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


     [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

   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
   ernet.com [recorded in

     [41] http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btinternet.com

   <trackbot> Created ACTION-2659 - Make a test for dx/dy like
   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

   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


     [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

   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.

   <ChrisL> suggests simplifying the syntax.

   <ChrisL> "


     [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

   <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
   ernet.com [recorded in
   [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
   [NEW] ACTION: erik fix gaussian blur in 1.1SE and filters module per
   [recorded in
   [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
   [NEW] ACTION: erik reply to bert's www-svg mail about css3-images
   [recorded in
   [NEW] ACTION: erik review media fragments uc&r document [recorded in
   [NEW] ACTION: erik to investigate filterRes mail
   [recorded in
   [NEW] ACTION: erik to mail public-canvas-api about inheriting from
   Element [recorded in

     [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:10:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:18 UTC