SVG Working Group Teleconference -- 19 Aug 2009

<trackbot> Date: 19 August 2009

<scribe> Scribe: Cameron

<scribe> ScribeNick: heycam

SVG Open F2F

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

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> 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 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> 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 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 http://www.w3.org/2002/09/wbs/19480/SVG200909/

Media Fragments use cases and requirements review

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

http://www.w3.org/Graphics/SVG/WG/wiki/Media_Fragments_Review

<scribe> ACTION: cameron review media fragments uc&r document [recorded in 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 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]

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 http://www.w3.org/mid/200907091214.09818.Dr.O.Hoffmann@gmx.de [recorded in http://www.w3.org/2009/08/19-svg-minutes.html#action05]

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

feGaussianBlur [www-svg]

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 http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html [recorded in http://www.w3.org/2009/08/19-svg-minutes.html#action06]

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

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 http://lists.w3.org/Archives/Public/www-svg/2009Jul/0018.html notes added

Inheritance during SVG animation of CSS properties

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 http://www.w3.org/mid/4A64F46A.6000900@mozilla.com [recorded in http://www.w3.org/2009/08/19-svg-minutes.html#action07]

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

possible errata: SVG 1.1/1.2 tspan Element dx Attribute definition [www-svg]

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 http://www.w3.org/mid/8429F2BC-8CC3-4075-8096-793E02C1E6BD@btinternet.com [recorded in http://www.w3.org/2009/08/19-svg-minutes.html#action08]

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

CSS images module [www-svg]

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

http://www.w3.org/TR/2009/WD-css3-images-20090723/#url

CL: they could replace that example with logos.svg#viewBox(...)

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

- DRAFT -

SVG Working Group Teleconference

19 Aug 2009

Attendees

Contents