W3C home > Mailing lists > Public > www-svg@w3.org > February 2011

minutes, SVG WG Auckland F2F, day 1

From: Cameron McCormack <cam@mcc.id.au>
Date: Mon, 28 Feb 2011 17:19:12 +1300
To: public-svg-wg@w3.org
Message-ID: <20110228041911.GF7682@wok.mcc.id.au>
Minutes from day 1 of the Auckland F2F:

  http://www.w3.org/2011/02/27-svg-minutes.html

and below as text:

   [1]W3C

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

                               - DRAFT -

                   SVG Working Group Teleconference

27 Feb 2011

   See also: [2]IRC log

      [2] http://www.w3.org/2011/02/27-svg-irc

Attendees

   Present
          +1.649.363.aaaa

   Regrets
   Chair
          SV_MEETING_CHAIR

   Scribe
          jwatt, Jonathan Watt, Anthony, Cameron

Contents

     * [3]Topics
         1. [4]1.1 2nd Ed.
         2. [5]animateColor
         3. [6]Starting SVG 2
         4. [7]SVG Masking
         5. [8]Testing framework
     * [9]Summary of Action Items
     _________________________________________________________

   <trackbot> Date: 27 February 2011

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

     [10] 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> [11]http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html

     [11] 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> [12]http://www.w3.org/Graphics/SVG/WG/track/issues/2334

     [12] 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> [13]http://www.w3.org/Graphics/SVG/WG/track/issues/2364

     [13] 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> [14]http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html#2334

     [14] http://www.w3.org/2010/09/SVG1.1SE-LastCall/dump.html#2334

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

     [15] 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>
   [16]http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Tests_with_fewer_
   than_two_passing_implementations

     [16] 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>
   [17]http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_
   matrix.html

     [17] http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

   <heycam>
   [18]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/filters-light-03-f.html

     [18] http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/filters-light-03-f.html

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

     [19] http://dev.w3.org/SVG/profiles/1.1F2/test/svg/animate-elem-46-t.svg

   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,
   [20]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/filters-light-03-f.html

     [20] 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,
   [21]https://bugzilla.mozilla.org/show_bug.cgi?id=619992

     [21] 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>
   [22]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/filters-overview-01-b.html

     [22] 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>
   [23]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/fonts-desc-04-t.html

     [23] 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
   [24]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
   [25]http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_
   matrix.html

     [25] http://dev.w3.org/SVG/profiles/1.1F2/test/status/implementation_matrix.html

   Next
   [26]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/fonts-desc-05-t.html

     [26] 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
   [27]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/fonts-glyph-02-t.html

     [27] 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
   [28]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/fonts-glyph-03-t.html

     [28] 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
   [29]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/painting-render-02-b.html

     [29] 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
   [30]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
   [31]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/painting-stroke-10-t.html

     [31] 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
   [32]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
   [33]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/struct-dom-15-f.html

     [33] 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:
   [34]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/text-align-07-t.html

     [34] 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
   [35]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/text-align-08-b.html too

     [35] http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMiniApproved/text-align-08-b.html

   Next
   [36]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/text-altglyph-02-b.html

     [36] 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
   [37]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/text-dom-04-f.html

     [37] 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
   [38]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
   [39]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
   [40]http://dev.w3.org/SVG/profiles/1.1F2/test/harness/htmlObjectMini
   Approved/text-text-05-t.html

     [40] 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:
   [41]http://www.w3.org/Graphics/SVG/WG/wiki/Full_11#Tests_with_fewer_
   than_two_passing_implementations

     [41] 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>
   [42]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Animati
   on_improvements#Issue:_.3CanimateColor.3E_isn.27t_needed

     [42] 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> [43]http://www.adobe.com/svg/dynamic/declarative.html

     [43] 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
   [44]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>
   [45]http://code.google.com/p/locationlogger/source/browse/trunk/src/
   svg/transitToMain.svg?spec=svn52&r=52

     [45] http://code.google.com/p/locationlogger/source/browse/trunk/src/svg/transitToMain.svg?spec=svn52&r=52

   RRSAgent: make minutes

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

     [46] 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>
   [47]http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

     [47] 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,
   [48]http://dev.w3.org/2009/dap/ReSpec.js/documentation.html

     [48] 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>
   [49]http://www.w3.org/People/Schepers/spec-conventions.html

     [49] 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
   [50]http://dvcs.w3.org/hg/svg2-tests/ to
   [51]http://dvcs.w3.org/hg/svg2/ ?

     [50] http://dvcs.w3.org/hg/svg2-tests/
     [51] 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
   [52]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
   [53]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
   [54]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>
   [55]http://www.w3.org/Graphics/SVG/WG/wiki/F2F/Auckland_2011/Luma-ma
   sk

     [55] 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> [56]http://kaioa.com/b/1102/svgjng/index.html

     [56] http://kaioa.com/b/1102/svgjng/index.html

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

     [57] 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
   [58]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
   [59]http://www.w3.org/Graphics/SVG/WG/track/issues/2401/edit .

     [59] 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:
   [60]http://mxr.mozilla.org/mozilla-central/source/layout/reftests/sv
   g/

     [60] 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> [61]http://www.opera.com/developer/tools/operawatir/

     [61] http://www.opera.com/developer/tools/operawatir/

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

   <ed> [62]http://watir.com

     [62] 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
   [63]http://www.spinetix.com/

     [63] 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/[64]http://test.w3.org/

     [64] http://test.w3.org/

   <ed> [65]http://test.w3.org

     [65] 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> [66]http://www.w3.org/wiki/TestInfra/goals

     [66] 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
   [67]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>
   [68]http://www.w3.org/Graphics/SVG/WG/wiki/Testing_Framework#Method_
   2_-_spot-testing_with_pre-defined_document-times

     [68] 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>
   [69]http://www.w3.org/Graphics/SVG/WG/wiki/Testing_Framework#Method_
   2_-_spot-testing_with_pre-defined_document-times

     [69] 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
   [70]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

-- 
Cameron McCormack ≝ http://mcc.id.au/
Received on Monday, 28 February 2011 04:19:58 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:47 GMT