See also: IRC log
<trackbot> Date: 19 August 2009
<scribe> Scribe: Cameron
<scribe> ScribeNick: heycam
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
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
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].
<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/
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].
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].
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
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].
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].
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].
This is scribe.perl Revision: 1.135 of Date: 2009/03/02 03:52:20 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: s/.../CM: / Succeeded: s/too/ as well as the filter module/ Succeeded: s/in the text content/for the space glyph/ Found Scribe: Cameron Found ScribeNick: heycam Default Present: Doug_Schepers, ed, heycam, anthony, ChrisL, [IPcaller] Present: Doug_Schepers ed heycam anthony ChrisL [IPcaller] Agenda: http://lists.w3.org/Archives/Public/public-svg-wg/2009JulSep/0051.html Found Date: 19 Aug 2009 Guessing minutes URL: http://www.w3.org/2009/08/19-svg-minutes.html People with action items: cameron erik reply[End of scribe.perl diagnostic output]