- From: Cameron McCormack <cam@mcc.id.au>
- Date: Mon, 28 Feb 2011 17:19:12 +1300
- To: public-svg-wg@w3.org
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 UTC