SVG Working Group Teleconference -- 27 Feb 2011

<trackbot> Date: 27 February 2011

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Agenda

<jwatt> scribe: jwatt

<scribe> scribenick: jwatt

<scribe> scribe: Jonathan Watt

1.1 2nd Ed.

CL: looking at the disposition of comments
... there are two that have not been responded to
... probably just because tracker has not been updated
... there are a few replies that we've not heard back from

<heycam> http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html

CL: 2 issues that we rejected have been accepted by the reporter

CM: so the two we haven't responded to are:

<heycam> ISSUE-2334?

<trackbot> ISSUE-2334 -- Last Call Comment: filter primitive subregion and feGaussianBlur, feTile and infinite filter input images -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2334

<heycam> ISSUE-2364?

<trackbot> ISSUE-2364 -- Last Call Comment: SVG 1.1 may be ambiguous about the root element acting as a proximal event target -- raised

<trackbot> http://www.w3.org/Graphics/SVG/WG/track/issues/2364

ED: the only remaining thing with 2334 is roc's comments on the filter boundaries

<ed> http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html#2334

<heycam> http://lists.w3.org/Archives/Public/www-svg/2011Jan/0067.html

ED: look at the top two emails
... or top one
... I think you (roc) agreed that the spec change was okay
... would you be fine with not making any more changes at this point?

ROC: yes

ED: let's just mark the issue as resolved in that case

<ed> RRSAgent: pointer?

RRSAgent: make minutes

CL: for 2364 Doug was really relaying from kevinar18, so the original commenter has not been contacted I believe
... it seems reasonable to me to say we'll clarify it in SVG 2, leaving it as is in 2nd ed for now

<heycam> http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Tests_with_fewer_than_two_passing_implementations

CM: for the tests that have fewer than 2 passing implementations, I've put up my comments and erik and chris did to
... see above
... we should go through these and decide what to do about them

CL: the test assumes that font-weight is continuously animatable, but it's not
... the subtest should be removed I think

CM: none of the tests use calcMode, so we could change it to discrete
... we would have to choose values that are multiples of 100, or else it won't animate

BB: it's already using keywords like 'bold'

CM: in than case we could leave the values alone

ED: Opera don't normalize keywords for font-weight so we probably treat the animation as discrete anyway
... adding calcMode would make it clearer though

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/filters-light-03-f.html

<ed> http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-elem-46-t.svg (done editing)

ED: filters-light-03-f.svg was for the change where we defined how primitiveUnits=objectBoundingBox computes the attribute values for some of the filter primitives that need that
... in particular the lighting filters with x, y, z

<ChrisL> could someone regen the test suite status? I have checked in the newly-passed abbra results

ED: and the cases where you have optional parameters, one or two values (<number-optional-number), and it wasn't clear how these were affected (expanded then computed, or computed then expanded)

CM: probably it's going to be hard to get two implementations passing

ED: Batik gets it half right, but doesn't seem to implement objectBoundingBox at all
... I put comments in the test saying how to compute the results

<heycam> roc, http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/filters-light-03-f.html

<dholbert> (quick mozilla-bugzilla search says we don't yet have a bug filed on that test, fwiw)

<scribe> scribe: Jonathan Watt

<scribe> scribenick: jwatt

<heycam> roc, https://bugzilla.mozilla.org/show_bug.cgi?id=619992

ROC: I should be able to fix that (filters-light-03-f.html) this week
... actually longsonr may have fixed that already

CM: we should aim to have these test issues fixed by the end of the week so that we can set up the transition call

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/filters-overview-01-b.html

ED: that's one of the old tests

CM: it's probably not a simple fix in Batik
... making it a solid color would make Batik pass

ED: using userSpaceOnUse didn't make any difference for Batik
... we could make the filters-overview-01 and 02 drafts and then create an 03 which uses solid color fills, then add new tests that are specifically testing FillPaint and StrokePaint with gradients
... we should create separate tests for fillPaint and strokePaint anyway

CM: I'll copy -01 to -03 and edit -01 to refer to a solid color
... using a solid color works in Batik

RRSAgent: make minutes

<heycam> http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/fonts-desc-04-t.html

CL: it's not clear what that's trying to test
... if it's testing the CSS font-style property, then we can make a WOFF version
... I think it is, and it would be fine to do that

<scribe> ACTION: Chris to convert fonts-desc-04-t.html to use WOFF [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action01]

<trackbot> Created ACTION-2962 - Convert fonts-desc-04-t.html to use WOFF [on Chris Lilley - due 2011-03-06].

<ed> i just checked in an updated http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/fonts-desc-05-t.html

CL: I'll convent that to WOFF too

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/fonts-glyph-02-t.html

CM: where we fixed up the text-anchor to use middle

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/fonts-glyph-03-t.html

CM: Chris was going to edit the text description

CL: I agreed to put something in the spec to explain what xml:lang is for

CM: probably not implemented

CL: we should maybe drop it - it was a good idea at the time, but maybe less so now

CM: we should unapprove the test for now

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/painting-render-02-b.html

CM: Alex says Abra passes this test now
... this test wasn't added because of a spec change, just because I noticed there wasn't a test
... everyone agrees it's a reasonable test although we don't have two implementations, so we could probably keep it

<scribe> ACTION: Cameron to email Jeremiah about fixing painting-render-02-b.html in Batik [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action02]

<trackbot> Created ACTION-2963 - Email Jeremiah about fixing painting-render-02-b.html in Batik [on Cameron McCormack - due 2011-03-06].

<ed> RRSAgent: pointer?

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/painting-stroke-10-t.html

CM: we should probably remove the subtest

<scribe> ACTION: Cameron to make the first subtest of painting-stroke-10-t.html render nothing [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action03]

<trackbot> Created ACTION-2964 - Make the first subtest of painting-stroke-10-t.html render nothing [on Cameron McCormack - due 2011-03-06].

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/struct-dom-15-f.html

ED: Safari 5 passes on the simplified tests

Next: http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-align-07-t.html

CM: the CSS stuff about baseline alignment is still in flux, and I want CSS and SVG to align on this
... we have different defaults
... I was going to email the XSL people, but haven't yet
... I've also changed my mind a few times on this
... that's why I think we should unapprove it for now

CL: presumably we'll errata SVG once CSS has settled on what they're doing

above comments apply to http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-align-08-b.html too

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-altglyph-02-b.html

ED: I haven't split this out yet - have an action to do that

CM: I'll take the action

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-dom-04-f.html

ED: I was hoping this would be easy to get to pass in another implementation, but I'm not so convinced
... some tests are testing index size exception
... it's important that the glyphs appear the same, and the advances are the same

<scribe> ACTION: Chris to make a WOFF font for font-desc-04 [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action04]

<trackbot> Created ACTION-2965 - Make a WOFF font for text-dom-04-f [on Chris Lilley - due 2011-03-06].

RRSAgent: make minutes

<scribe> ACTION: Erik to go through the minutes and unapprove tests as appropriate [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action05]

<trackbot> Created ACTION-2966 - Go through the minutes and unapprove tests as appropriate [on Erik Dahlström - due 2011-03-06].

Next http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-text-05-t.html

ED: I think we should unapprove the test for now

CM: we could leave the start one
... basically turns into a test of whether multiple x/y values are supported
... there's a WOFF in there already

ED: I will reword the action to be about splitting it

<dholbert> anthony / anthony_nz: http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Tests_with_fewer_than_two_passing_implementations

<dholbert> :)

animateColor

CL: historical background
... comes from SMIL
... which assumed animate could only work on scalars
... SVG 1.0 it said you can't use <animate> with color
... SVG 1.1 says you can
... SVG 1.1 2nd edition clarifies how you do it
... so now we are at the stage where we can just use <animate>
... but we have content out there that uses <animateColor>

ROC: what content uses it, and is it on the web?
... is it in walled gardens?
... I guess I'm just interested in whether we can say "use <animate> on the web"
... it's a no brainer to deprecate it at least

JW: since FF4 is going out with <animate> support from color, but without <animateColor> support, when people start expecting their SMIL content to work in FF we'll see if animateColor is common due to the number of complaints

<birtles> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animation_improvements#Issue:_.3CanimateColor.3E_isn.27t_needed

CM: the spec currently says what to do for color-interpolation on animateColor, but not yet for <animate>

<ChrisL> http://www.adobe.com/svg/dynamic/declarative.html

CL: there's an example using animateColor

<ChrisL> and lots of people will copy and paste those examples

CM: there are people that are coming up on the svg-developers list using animateColor

ED: and people do commonly refer to (and use) Adobe examples

CM: we could deprecate animate color and define color-interpolation in 2nd ed

<roc> those Adobe examples don't put the <svg> element in the right namespace :-)

<scribe> ACTION: Cameron to deprecate animate color and define color-interpolation on <animate> in 2nd ed [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action06]

<trackbot> Created ACTION-2967 - Deprecate animate color and define color-interpolation on <animate> in 2nd ed [on Cameron McCormack - due 2011-03-06].

<ChrisL> http://code.google.com/p/locationlogger/source/browse/trunk/src/svg/transitToMain.svg?spec=svn52&r=52

RRSAgent: make minutes

<ChrisL> http://commons.wikimedia.org/wiki/File:%E8%87%AA-animated.svg

<anthony_nz> Scribe: Anthony

<anthony_nz> scribenick: anhtony_nz

Starting SVG 2

<anthony_nz> CM: In CVS there is a start of SVG 2 which I think Doug you put together

<anthony_nz> DS: Yes

<anthony_nz> CM: It's good to have the document there so we can start putting in some of our ideas we've been putting off for a long time

<anthony_nz> ... some of the ISSUES we've put off for SVG 2

<anthony_nz> ... this session I'd like to discuss some of the ideas for writing the document up

<anthony_nz> DS: I'm the editor of the web events touch interface specification

<dholbert> http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

<anthony_nz> ... ReSpec.JS is a script library and set of conventions that helps author specifications

<anthony_nz> ... It's a JavaScript document system

<anthony_nz> ... creates references table. If you want to create an interface you summaries it simply as a definition list

<anthony_nz> ... and it converts it all in to WebIDL

<anthony_nz> ... You can make canonical definitions of something it will reference the correct instance

<anthony_nz> JW: Helps with book keeping and promotes consistency

<anthony_nz> DS: Having ReSpec may make it easier to write the spec

<anthony_nz> JW: Which groups are using it?

<anthony_nz> ... DAP, a few in Web Events and Web Apps

<anthony_nz> DS: HTML 5 is not using it

<anthony_nz> DS: I don't know how well it handles very large specs

<anthony_nz> CM: One of the things that annoys me about it is takes a while to do the reformatting

<anthony_nz> CL: Can't you do that in batch?

<anthony_nz> CM: The idea is to remove a special generation step

<anthony_nz> JW: Under which circumstances is it slow?

<anthony_nz> DS: Every time you reload it

<birtles> jwatt, http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

<anthony_nz> ... So the thing I'm think is we either use ReSpec.JS

<anthony_nz> ... or use something that consumes the markup and conventions of ReSpec.JS

<anthony_nz> DH: That sounds like reimplementing ReSpec.JS

<anthony_nz> DS: The advantages is having idiosyncratic specs is harder for people to read and review

<anthony_nz> ... it does things with IDL which our current system doesn't

<anthony_nz> CL: What's the input stored in?

<anthony_nz> ... there's alot of careful lot of wording and linking and I don't want to lose that

<anthony_nz> ... and going back to text and reforming it

<anthony_nz> CM: The idea of starting from a blank slate and take across things

<anthony_nz> ... that we want

<anthony_nz> ... means we have to examine things

<anthony_nz> CL: I'm not going against moving to a new system, just want to know the benefits it brings

<anthony_nz> DS: I think should talk to Robin Berjon to see if ReSpec.JS will scale up to a document size such as SVG

<anthony_nz> CM: I recently tried ReSpec.JS and one of the reason I wanted to go back to an XSLT style process

<anthony_nz> ... Styling choices, and the method for writing the IDL. I think the other way around, because I like to control the way the IDL looks

<anthony_nz> DS: The good thing about it is outputs consistent markup which makes it easier to style

<anthony_nz> CM: I didn't put much effort into looking at how difficult it would be to change

<anthony_nz> DS: If we decide to go with this and it turns out that we end up changing what the output looks

<anthony_nz> ... then we've lost the advantage of it

<anthony_nz> CL: The other thing is if we have our own system as long as it generates the final style markup that is specified by W3C

<anthony_nz> ... it is ok

<anthony_nz> CM: The other thing is how we are going to build it up

<shepazu> http://www.w3.org/People/Schepers/spec-conventions.html

<anthony_nz> ... the SVG 2 spec that is

<anthony_nz> DS: This is a set of conventions that I've used

<anthony_nz> ... and is no way is a mandated

<anthony_nz> CM: I think starting with a blank slate then examining the features as we port them across is a good idea

<anthony_nz> CL: We want to maintain backwards compatibility as we do it

<anthony_nz> ... otherwise people not adopt what we make

<anthony_nz> ... I kind of like the way we split it into chapters

<anthony_nz> ... having it one enormous file to edit is a pain

<anthony_nz> ... I also like having the examples in separate files

<anthony_nz> ... so they can be dropped into implementations

<anthony_nz> CM: It might be better to have the source document as a single file

<anthony_nz> ... which is then broken up into chapters

<anthony_nz> ED: It's kind of painful to edit

<anthony_nz> CL: At the end of the day we need both; a single document spec and one with chapters

<anthony_nz> CM: Various parts in the spec are quite wordy and flowery and just take up space

<anthony_nz> ... some parts are terse and under worded

<anthony_nz> CL: I like specs which explain things exactly. I think adding motivation as to why things are there helps out

<anthony_nz> ... I'm talking about summary about what the job is of something and why it is there

<anthony_nz> CM: I think a good way to progress is to start with a list of features

<anthony_nz> ... or something like that

<anthony_nz> ... of the language

<anthony_nz> ... so we can evaluate at the feature level what we want in the document

<anthony_nz> ... From there we can decide what wording we want to put in

<heycam> ted, thanks!

<anthony_nz> DS: I think that is a good idea

<anthony_nz> CL: Do we use CVS or do we use Mercurial

<ted> heycam, maybe you'll want to set the channel mode so anyone can change topic

<heycam> ted, ok cool

<ted> via: /mode #svg -t

<ted> right

<anthony_nz> JW: I would really strongly go against using CVS for the next version

<anthony_nz> ... You know a file changed for a version and you don't know what changed as well with that file

<anthony_nz> CL: I hate the fact you can't move files between directories without losing history

<anthony_nz> RESOLUTION: We will use Mercurial for our version system when writing SVG 2

<anthony_nz> CM: I'm happy to do the job of starting off the list of features that should be in SVG 2

<anthony_nz> JW: Should we create an SVG 2 repository for Mercurial?

<jwatt> should we rename the URL for http://dvcs.w3.org/hg/svg2-tests/ to http://dvcs.w3.org/hg/svg2/ ?

<anthony_nz> CM: What granularity do we have specs at?

<anthony_nz> ROC: Should avoid sub repositories

<anthony_nz> CM: So just one then

<anthony_nz> ... Mercurial doesn't deal well with binaries?

<anthony_nz> JW: I think it's if you change them a lot

<anthony_nz> ED: The best way to solve generating of images for the repository is generate them on the server

<anthony_nz> ... ultimately we'll use Ref Tests

<anthony_nz> ACTION: Cermon to Examine SVG 1.1 and derive a list of features to be considered for SVG 2 [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action07]

<anthony_nz> ACTION: Cameron to Examine SVG 1.1 and derive a list of features to be considered for SVG 2 [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action08]

<heycam> trackbot, help

<anthony_nz> ACTION: Cameron to Examine SVG 1.1 and derive a list of features to be considered for SVG 2 [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action09]

<trackbot> Created ACTION-2969 - Examine SVG 1.1 and derive a list of features to be considered for SVG 2 [on Cameron McCormack - due 2011-03-07].

<anthony_nz> CM: I'll send an email to Sysrec and get them to change the name of the Mercurial repository "svg2-tests" to "svg2"

<jwatt> RRSAgent: make minutes

SVG Masking

<anthony_nz> ED: It was raised on the mailing lists

<anthony_nz> ... masks override the color-interpolation property

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Luma-mask

<anthony_nz> ... That's the page describing the problem

<anthony_nz> ... what the spec is currently saying regardless of the value of color-interpolation

<anthony_nz> ... you still need to do your mask in linearRGB space

<anthony_nz> ... I wasn't sure why exactly

<anthony_nz> ... it seems that PDF and Postscript something similar

<anthony_nz> ... but it seems odd why it would override color-interpolation

<anthony_nz> ... My proposal for bringing this up is to respect color-interpolation for the calculation of the mask

<anthony_nz> CM: Maybe the idea was the idea originally that since linearRGB was more natural aspect to colors then maybe it was better to use

<anthony_nz> DS: Do you think there is content out there that would have any noticeable change?

<anthony_nz> ED: Not sure, but I think the change would be minor

<anthony_nz> ... and people can specify color-interpolation to fix the issue if it is a big problem them

<ed> http://kaioa.com/b/1102/svgjng/index.html

<ed> http://lists.w3.org/Archives/Public/www-svg/2011Feb/0023.html

<anthony_nz> ED: Would be good to change this for 1.1 2nd Edition

<anthony_nz> CL: If we did a test that had two masks one using each value and one using the default

<anthony_nz> ED: The problem is there is a performance penalty because the color space conversion

<anthony_nz> CL: I think it would be fine to put the wording in to the spec to say that color-interpolation applies

<anthony_nz> ED: It already says that

<anthony_nz> ... it's a matter of removing some of the wording

<anthony_nz> DS: I total understand why you'd want to do it

<anthony_nz> ... it's building towards SVG 2

<anthony_nz> CL: I think it's a better thing going forward

<anthony_nz> RESOLUTION: Proposal to allow color-interpolation to be honored by mask elements is accepted

<anthony_nz> ACTION: Erik to Change the tests and specification to adopt the proposal to allow color-interpolation to be honored by mask elements [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action10]

<trackbot> Created ACTION-2970 - Change the tests and specification to adopt the proposal to allow color-interpolation to be honored by mask elements [on Erik Dahlström - due 2011-03-07].

<heycam> ISSUE: Should have an alpha-mask property that can reference <mask>s (and maybe other elements) to mask based on alpha values instead of luminance

<trackbot> Created ISSUE-2401 - Should have an alpha-mask property that can reference <mask>s (and maybe other elements) to mask based on alpha values instead of luminance ; please complete additional details at http://www.w3.org/Graphics/SVG/WG/track/issues/2401/edit .

<heycam> Scribe: Cameron

<heycam> ScribeNick: heycam

Testing framework

ED: I wanted to discuss making a clear plan ahead for the existing test suite
... we should try to decide what to do with it: abandon it, convert some of the tests, write completely new tests, more minimal ones?

AG: one idea would be to get a list of the things we're trying to test in each test, from the description, and then either develop reftests around that or perhaps modify the tests themselves
... we have a lot of subtests in tests

ED: i think subtests isn't a problem, just test with script and verify it

CL: as long as you can watch them all at once. watching many animated things at once is not good.

CM: i don't think abandoning, but we need minimal tests

CL: like 400 different test with slightly different attributes?

ED: yes, but removing visual tests could also be bad if people are using them as examples for how to do things in svg

JW: we could start with mozilla's tests, get them into a state that the w3c framework needs, then start knocking off the old tests as we're happy they're covered by the old tests
... and where they're not, add a new test

CL: we don't know how many tests there are, and what their quality is

AG: does mozilla have reftests for each of the svg test suite tests?

JW: no, and certainly there are areas of the spec we don't implement, and parts of the spec that we don't have good test coverage for

CL: these are not visual tests

JW: they're reftests, so automatable

RO: not human readable. a lot of them have pass criteria like "the whole viewport is green"

JW: you have a test file, and a reference file, and you pass if they're pixel-by-pixel identical

ED: all of the reftests are for visual tests?
... what about script tests?

JW: we have mochitest framework for that. a large number of tests for that.
... don't know if the w3c framework supports mochitests

RO: there's a group working out a w3c framework for scripted tests, i heard discussion about it.

DH: i heard fantasai doing something like that?

RO: maybe webapps

CM: anything wrong with just setting a green rectangle on pass?

RO: you don't get good logging information about what subtests fails

ED: the testing framework form w3c is doing that, i think
... you server, different reposrt what you're testing and pass/fail
... i think that's in place, and we can start using it if we want to
... i converted a couple of tests from our test suite to see

<jwatt> mozilla's reftest tests: http://mxr.mozilla.org/mozilla-central/source/layout/reftests/svg/

ED: it's not that hard for tests that are, for example, totally scripted

<jwatt> look at the reftest.list file in each directory

ED: just where we check for the result, pass it to the testing framework
... what i was wondering then, if we go for that, is should we separate out the automated tests?
... separate directories for script automated reftests, and one for visual tests?
... it might make sense to make them separate

CM: what tests can't we automate?

ED: ones that require interaction
... there's Opera Watir, which allows a testing framework to control the browser
... that's open source and cross platform
... can be used for some automation of interaction tests

DH: could that be cross browser?

ED: yeah it gives you an api to implement
... the whole framework is open source
... the opera implementation of the driver is released
... i think that could be a third form of testing

<ed> http://www.opera.com/developer/tools/operawatir/

CL: browser automation would help with testing things that involve navigation

<ed> http://watir.com

RO: maybe window.open could help with that

JW: i'm reluctant about watir, mozilla has functionality to dispatch these kinds of events, maybe we could have addons for different browser to implement this API
... or a command line argument to use this api, so we can have these all in reftests or mochitests, so we don't require extra software to be run

AG: what about for non browser implementations?

JW: it still supports scripting

DH: but it probably wouldnt' support an addon

JW: but a command line argument to add extra apis to the window object could be done

CL: other classes of implementation to consider are embedded systems, for example one there's an svg implementation for display screens in hardware. that might be hard.
... another one is svg2pdf tools etc.

JW: for the latter one, is interaction an issue?

CL: not specifically for interaction, but the testing framework

JW: svg2pdf should be handled by reftests
... for embedded cases, it's probably easier for them -- if they support script -- to add extra stuff to the global object for testing purposes, than to port watir to work on their platform
... so i think it's still better even for them to use this framework
... can we implement this for opera as an addon?

ED: that's a good question

<ChrisL> embedded SVG implementation - Spinetix http://www.spinetix.com/

RO: the web page says watir already works for ie, firefox, opera, ...

JW: i'd like to keep a system where people can run tests with minimal effort, without installing 3rd party software

BB: you can still run the tests, but if you want to automate it...

JW: then you write the test differently if you want to do both

DS: otoh, doing it the way we're doing it doesn't scale
... i don't really want the svgwg to be doing a big project without coordinate with other wgs
... the idea of each group doing testing differently isn't scalable
... maybe we should discuss it in hcg

ED: the html testing tf framework probably would in general work for us, but there are some things that would -- e.g. standalone svgs, testing matrix values with epsilons, etc.

DS: is it worth converting old tests, or just making all new tests?

CL: could just use the old test suite as a pool of resources to help make the new tests

DS: i suspect we'll be changing bits of svg, we know when we've gone over tests and found that isn't really testing what it should be, or contradictory to the spec
... wrt reusing old tests, i'm making the argument that given the number of tests we have, it's not worth it
... using them as input, sure

AG: i think it's useful to know what all of those tests are testing, but not use them directly

DS: for web events i won't be publishing the documentt until we have tests
... "this is the specification and here are the tests for it"
... so I'd propose that we only publish an ED as a WD if we have tests

ED: what i'd like to see is a start using the, e.g., tests.w3.org framework for svg tests
... just as a starting point to see what we can do with it
... if we want to start by doing svg2 tests with that, that could be a starting point
... i don't mind if it's testing 1.1 functionality that way
... but just having something for evaluating the framework to see if it's suitable would be useful

<ed> s/tests.w3.org/http://test.w3.org/

<ed> http://test.w3.org

CM: I wonder what the html testing tf is using for interactive tests

MS: the plan we've been talking about for 1.5 years is to set up some common testing infrastructure to allow people to submit tests
... and have ana utomated test harness, automating as much as we can
... that's tsill the goal, it just is taking us a while to get to it
... we have a testing taskforce that has been working for quite a while now
... and we have been doing a lot work on getting test cases in for html5
... the biggest set of tests philip taylor made for canvas
... and probably another 100 or 150 from somewhere else
... MS submitted a good number
... using a testing framework jgraham put together
... we want to get a test case mechanism that allows for having reftests, and having things work across browsers
... what's happening with that is that frmo the team side, we've got some time freed up for myself and francois to help out with testing
... the other thing we've been talking about doing is a mechanism for producing a version of the canvas spec with links to all the test cases
... and the annotations are placed in the spec where there are testable assertions
... in the html spec i want to be able to scale that up from canvas to the whole spec
... that could potentially be useful for any spec we want to use it for
... i guess the priorities right now are for getting a harness we can all agree on, and this way of producing annotations for testable assertions in the spec
... then there's encouraing people to submit tests
... trying to figure out some way to get more test cases and more people to submit them

ED: [summarises earlier discussions]

<pdengler> slow to start here, but I will have some test cases toward the end of the week we can use as a launch point

<pdengler> i can keep looking for another optin, for now keep up the conversation, the IRC is working

MS: i don't know if jgraham's set up can support mouse events
... also ms2ger has been doing some work, and others
... part of what i need to do is take a look at what everyone's got so far and figure out how much of it is useful and ...
... seems like nothing we have so far is satisfactory to everyone
... might have to come up with something else
... but the talk of having a common format that everyone uses. we could have a common format, or set up the harness so it could run existing tests from other test suites, like reftests especially
... as far as details around interactivity, i'd have to have a look to see where it's at

DS: one of the things that occurs to me is that having a harness that runs tests in general is good, but one of the benefits of having a common format is that it might promote the submission of tests
... having a well defined way of creating tests that doesn't vary between wgs would be easier on implementors
... e.g. training their teams to create tests for w3c rather than for each group
... having it well documented and consistent, so people in the public who have made css tests then could make svg tests, etc.
... that's why we might want to have a common format. but i don't want to boil the ocean for theoretical benefits

MS: i don't think it's necessarily important to have everything in the same place
... but i think it makes more sense to have them on one server, one repo
... any individual can request a new repo set up on that hg server
... and then it's hg, so if you want to do the management elsewhere, and just use the w3c one as a mirror, or the other way around
... it makes it easier once we have an hg repo
... there are features on sites like bitbucket that are useful, not sure if it's a good idea to reinvent them on w3.org
... distributed vc allows us to use those features via those sites

DS: my concern is the added complexity of people knowing where to go to get all the relevant stuff
... and having someone making sure everything is up to date in all copies of the repo

MS: re interactive tests, it seems like we should do everything we can to make sure we have as few automated tests as possible
... including anything that has interactive requirements
... there are different ways to do that, we just need to have the framework enable some way of doing it that works across browsers
... we shouldn't have to write any manual test cases unless we really have to
... webperf wg started using the htmlwg framework, and they needed to make some changes to it and wanted to get them upstream
... it seems to be holding up that wg, which is moving quickly
... you don't want to block anyone's work
... i think we should take a look at what they've got
... but plh is impressed with what they've done

DS: what do implementors think about having these apis?

JW: i think we should have them

RO: we have apis that simulate events for tests, it'd be pretty easy to expose them in another way

JW: or have an addon...

DS: so, standardised

RO: did you decide exactly what apis you want?
... if you want to synthesise trusted input events, that's easy to do
... if you want to drive all of the browser's ui programmatically, that's harder

ED: that's what watir is trying to do

RO: dispatching trusted events would be a small extension
... i don't have a feel what's needed beyond that

DS: that sounds like something concrete we can attack

RO: i think we need to find out what apis we actually need
... for say everything needed in the svg test suite right now

<shepazu> pdengler, would MS be favorably disposed toward standardizing and implementing testing APIs?

BB: animation tests need snapshots or something
... how about implementations that don't support script, but do support animation?

CM: maybe we can forget about scriptless UAs for this testing framework

MS: i wanted to mention that we need to be getting down the requirements of what we need

<Mike5> http://www.w3.org/wiki/TestInfra/goals

MS: doug sent out an email earlier with a link to that page
... plh, fantasai, jwatt and i spent some time a year ago working on some of this common testing framework stuff
... the htmlwg test tf which also has a page
... one thing is to add a link there to specific requirements that you all have
... our plan is to have something useful, usable across different wgs, but this summer
... that's not a lot of time
... it's definitely achievable, it's not the time... but just to see what we really need
... and to get some level of agreement on it
... it's just software, and needs to be done
... first is to make sure we have all of the requiements

CM: we will gather interactive requirements for our test suite
... also, we would need to allow svg as a root document

DS: doesn't seem like anything we're doing here is going to conflict with what the html wg tf is doing
... i think we should just try to do what we need, and come to the html testing tf with that
... does that sound reasonable mike?

<Mike5> sounds reasonable

DS: [asks patd about testing apis, for automated browser testing]
... it'd be good to know if ms is interested in speccing out specific apis around testing
... so we can do automated browser testing

PD: standardising?

CL: not standardising, but coming up with an api for interaction simulation etc.

PD: i will ask kris about this

<pdengler> I will ask krisk about this

<pdengler> Doug asked whether or not we would be favorable toward standardizing and implementing testing API's

<pdengler> I will find out on our side and get back shortly

<pdengler> K :)

<pdengler> "Yes we already have secret api's...."?

MS: another thing i'm responsible for is i've written up a rough draft of the console api
... for the console object in browsers
... so listening to whate cameron was saying, long term it could make a lot of sense to have an object that browsers implement, but short term [...]

DS: what are the next steps practically?
... are you guys having telcons around testing that we should be joining?

MS: i think step 1 is requirements gathering
... you guys should write up a wiki page or email message with your requirements
... 2nd thing is having a f2f
... some times you just have to get in a room for a couple of days to get things done
... maybe we can get google accommodation sponsored
... and we can work out a more detailed plan on what we want to get done by the summer
... like august
... some time in may seems to make sense to have a f2f

DS: i think we should have some telcons around that

MS: let's do that and see how many people we can get involved
... we'll aim for the beginning of next week
... we'll figure out times

<pdengler> can we scribe that..?

<scribe> ACTION: Doug to coordinate with Mike about setting up a telcon about testing [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action11]

<trackbot> Created ACTION-2971 - Coordinate with Mike about setting up a telcon about testing [on Doug Schepers - due 2011-03-07].

<pdengler> i got dropped

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Testing_Framework#Method_2_-_spot-testing_with_pre-defined_document-times

ED: with smil tests, i'm suggesting that we decide on a strategy on how to test that in an automated fashion

<ed> http://www.w3.org/Graphics/SVG/WG/wiki/Testing_Framework#Method_2_-_spot-testing_with_pre-defined_document-times

ED: this is the method i'm suggesting we use
... it's pausing all animation in the document, then setting the current document time, then querying all the animated values to see what they are
... and reporting that to the testing framework
... and then keep doing that, setting a different time, and checking the value again

CL: a lot of the animation tests are just spot testing, like it has to pass the point at 3s

ED: yeah, we could move away from tests that take 30 seconds to run
... we use a similar method for our testing at opera
... so i suggest adopting method #2 going forward
... then we could test animation code just using script

JW: that's the method i think we resolved to use at the sydney f2f

ED: yeah that's possible
... and i think we should actually do it

DS: to be fair to us, svg 1.1 has really been distracting us

<pdengler> Would we want to do something similar if we adopt CSS animations and would it be the same?

ED: I could convert one or two tests as an example
... should i do that for existing tests?

CL: that'd be easier

<scribe> ACTION: Erik to convert a couple of animation tests to use the spot testing method [recorded in http://www.w3.org/2011/02/27-svg-minutes.html#action12]

<trackbot> Created ACTION-2972 - Convert a couple of animation tests to use the spot testing method [on Erik Dahlström - due 2011-03-07].

CL: will need a tolerance

BB: we mostly rely on snapshots, so we snapshot and compare to a reference image
... it doesn't do the dom

RO: but we do dom tests in other tests

JW: the only thing we need to be careful of is rounding
... differently implementations might round differently

ED: it's possible implementations will need to adapt to support the dom methods the framework uses
... i.e. extracting the animated values, pausing animations, setting the documen time

JW: the webkit bug for implementing these bugs isn't fixed yet

DH: would we use getComputedStyle for animation of css properties?

ED: it should work

CM: would pausing animations work for CSS Transitions/Animations?
... we should discuss that on thursday

<pdengler> There is no API in CSS that I know of for Transitions/animations

DH: so would we have no visual animations tests?
... or is it just a guideline?

ED: a recommedation on how to write future tests

RESOLUTION: We will use spot testing for animation tests going forward

<pdengler> Me ? No

trackbot, end telcon

- DRAFT -

SVG Working Group Teleconference

27 Feb 2011

Attendees

Contents

1.1 2nd Ed.

animateColor

Starting SVG 2

SVG Masking

Testing framework

Summary of Action Items

Scribe.perl diagnostic output