See also: IRC log
<trackbot> Date: 27 February 2011
<jwatt> scribe: jwatt
<scribe> scribenick: jwatt
<scribe> scribe: Jonathan Watt
CL: looking at the disposition of
... 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
CL: 2 issues that we rejected have been accepted by the reporter
CM: so the two we haven't responded to are:
<trackbot> ISSUE-2334 -- Last Call Comment: filter primitive subregion and feGaussianBlur, feTile and infinite filter input images -- raised
<trackbot> ISSUE-2364 -- Last Call Comment: SVG 1.1 may be ambiguous about the root element acting as a proximal event target -- raised
ED: the only remaining thing with 2334 is roc's comments on the filter boundaries
ED: look at the top two
... 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?
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
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
... adding calcMode would make it clearer though
<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
<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
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
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
CL: I'll convent that to WOFF too
CM: where we fixed up the text-anchor to use middle
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
CM: Alex says Abra passes this
... 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?
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].
ED: Safari 5 passes on the simplified tests
CM: the CSS stuff about baseline
alignment is still in flux, and I want CSS and SVG to align on
... 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
ED: I haven't split this out yet - have an action to do that
CM: I'll take the action
ED: I was hoping this would be
easy to get to pass in another implementation, but I'm not so
... 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].
ED: I think we should unapprove the test for now
CM: we could leave the start
... 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
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
CM: the spec currently says what to do for color-interpolation on animateColor, but not yet for <animate>
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].
RRSAgent: make minutes
<anthony_nz> Scribe: Anthony
<anthony_nz> scribenick: anhtony_nz
<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
<anthony_nz> ... ReSpec.JS is a script library and set of conventions that helps author specifications
<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
<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
<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?
<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
<anthony_nz> ED: It was raised on the mailing lists
<anthony_nz> ... masks override the color-interpolation property
<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
<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
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
... 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
... 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
... the whole framework is open source
... the opera implementation of the driver is released
... i think that could be a third form of testing
CL: browser automation would help with testing things that involve navigation
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
... 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
... 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
... 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
... 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
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
... 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
... 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
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
... 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
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
... are you guys having telcons around testing that we should be joining?
MS: i think step 1 is
... 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: with smil tests, i'm suggesting that we decide on a strategy on how to test that in an automated fashion
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
... 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
... 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