W3C home > Mailing lists > Public > public-svg-wg@w3.org > July to September 2014

Minutes, 25 September 2014 SVG WG telcon

From: Brian Birtles <bbirtles@mozilla.com>
Date: Thu, 25 Sep 2014 06:45:43 -0700 (PDT)
To: www-svg@w3.org
Message-ID: <902211904.28187399.1411652743249.JavaMail.zimbra@mozilla.com>
Minutes:

  http://www.w3.org/2014/09/25-svg-minutes.html

And as text:

   [1]W3C

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

                               - DRAFT -

                    SVG Working Group Teleconference

25 Sep 2014

   [2]Agenda

      [2] https://www.w3.org/Graphics/SVG/WG/wiki/Agenda

   See also: [3]IRC log

      [3] http://www.w3.org/2014/09/25-svg-irc

Attendees

   Present
          [IPcaller], ed, birtles, heycam, krit, stakagi, Tav,
          ChrisL, nikos_

   Regrets
          Rik, Thomas, Cyril

   Chair
          Cameron

   Scribe
          birtles

Contents

     * [4]Topics
         1. [5]Filters (implementation status, testsuite, next
            steps)
         2. [6]SVG charter
         3. [7]accessibility TF
         4. [8]text and CSS boxes
         5. [9]TPAC
     * [10]Summary of Action Items
     __________________________________________________________

   <trackbot> Date: 25 September 2014

   <scribe> scribenick: birtles

   <scribe> scribe: birtles

Filters (implementation status, testsuite, next steps)

   ChrisL: filters is obviously a widely-deployed technology in
   all the browsers and implementations
   ... so I expected the filters spec for CSS would be at a
   similar level of maturity
   ... I was looking at the testsuite and it only has 30 something
   tests
   ... presumably because they have to be reftests and have to be
   a certain style
   ... so it's not many tests
   ... and when I ran through them in different browsers there
   were so many failures
   ... it seemed like all failed in IE
   ... I was surprised to see that
   ... I wondered what's happenning, are the tests wrong? what's
   up?

   krit: many reference tests for filter effects test filters in
   HTML
   ... and IE doesn't support filters in HTML
   ... also similar for WebKit
   ... and we added some new filter functions that are currently
   only supported in WebKit and Blink and soon in Firefox

   <heycam> [11]http://status.modern.ie/filters "Under
   consideration" for IE

     [11] http://status.modern.ie/filters

   krit: you're right we don't have a lot of tests yet
   ... my colleague has been working on that as part of
   implementing in Firefox
   ... so hopefully those tests can be imported
   ... since they should be in the right format

   ChrisL: is there a repository for that?

   krit: it's in the Gecko repository
   ... I can ask him to send the link

   ChrisL: I know Opera released a lot of tests
   ... I wonder if any of those cover filters

   ed: there might be some filter tests for I don't think there
   would be any for CSS filters

   ChrisL: I remember that Presto did filters in HTML right?

   ed: no, only internal experiments

   ChrisL: well, that explains that
   ... Dirk you said there was something being working on?
   ... is this something we expect the browsers to do?

   krit: there's active development in Blink but not so much in
   WebKit right now (probably change in the next few months)
   ... we want to have the same feature set
   ... but we are missing from the specification the order of the
   regions
   ... I have no status report from Microsoft
   ... it is being worked on in Blink
   ... currently stagnating in WebKit
   ... hopefully enabled soon in Firefox
   ... already available in the Nightly versions

   ChrisL: that's better than I feared but still

   Tav: does the Firefox implementation handle shorthands?

   krit: yes

   Tav: how about webkit?

   krit: just for HTML

   ed: does the Firefox support shorthands for SVG too?

   krit: yes

   heycam: is that working now?

   krit: yes, it works

   ChrisL: I was only testing Firefox beta so that would explain
   some test failures
   ... I will do another run-through with nightly

   <heycam> layout.css.filters.enabled

   krit: there might be a flag

   <heycam> that is not enabled by default currently

   ChrisL: do I have to enable any features on Chrome canary?

   krit: it's enabled by default in Chrome canary but kind of
   broken
   ... same for webkit

   <heycam>
   [12]https://bugzilla.mozilla.org/show_bug.cgi?id=869828 -- the
   meta bug for CSS Filters in Firefox

     [12] https://bugzilla.mozilla.org/show_bug.cgi?id=869828

   ChrisL: is there any specific bugs I should track?
   ... should I report individual test failures on that bug? or a
   new bug?

   heycam: you can file a new bug and make it block this (the
   above) bug

   ChrisL: the other question is, how easy is it going to be to
   make tests for some of these filter functions?
   ... like the turbulence filter
   ... especially if we're trying to make it produce a green
   square
   ... maybe just a PNG image comparison

   krit: yes, that's difficult

   <ed> for blink: [13]http://crbug.com/109224 (tagging bugreports
   with "Cr-Blink-CSS-Filters" is probably good, or ping me and
   I'll set that tag on the bugs)

     [13] http://crbug.com/109224

   krit: I think Firefox has reference tests, I'm not sure how
   they do that

   heycam: I'm not sure we have reference tests for turbulence
   ... but the firefox reftest system does allow you to specify
   tolerance to account for anti-aliasing differences etc.
   ... but that might not be enough

   ChrisL: so it seems like there are a few outstanding spec
   issues
   ... might it go back to LC?

   krit: it's currently WD

   ChrisL: yes, you're right
   ... I just put out a new timeline for a our charter
   ... which is how I discovered that filters was less advanced
   than I thought it would be
   ... Dirk, you said there was an issue about the order of filter
   regions

   krit: currently we have a hard clipping region that is 10%
   around the object
   ... the proposal was to get rid of that and replace it with
   auto-computation of the bounds of the filter
   ... and I'm working on that auto-computation

   heycam: was there still and outstanding issue about the filter
   resolution

   krit: we removed filterRes but we still have the kernel units
   one
   ... but kernelUnitLength is needed
   ... it makes other parameters resolution-independent but they
   don't look good
   ... so there's still an issue but I don't think we can fix it
   with the current primitives we have

   heycam: is it an issue of how the filters are defined?
   ... working on physical pixels rather than logical pixels?

   krit: right, they work on physical pixels
   ... and if you make them work on logical pixels then you'd end
   up with pixelation

   heycam: so is the spec going to stay as it is?
   ... were you planning on making any more changes to this part
   of the spec?

   krit: no
   ... the primitives that are affected by that are
   feConvolveMatrix and fePointLight or one of the lighting
   filters

   ed: diffuse lighting I think

   krit: oh yes, that's right

   <ed> specularlighting too

   heycam: do you need any help/planning with regards to the test
   suite

   krit: help is always welcome

   heycam: do you need it?

   krit: the spec definitely needs tests
   ... occasionally I try to write tests but the specification is
   still much larger than the number of tests we have
   ... so if someone is willing, yes please

   ChrisL: I'm willing to do it but I'm trying to work out to make
   them into suitable reftests

   krit: it might be good to start by looking at Firefox's
   reftests
   ... can Firefox use pixel tests?

   heycam: you can always do that by putting a raster in the
   reference

   krit: in WebKit and Blink we definitely use pixel tests because
   it's easier but it's not cross-browser

   <heycam>
   [14]https://github.com/mozilla/gecko-dev/tree/master/layout/ref
   tests/svg/filters

     [14] https://github.com/mozilla/gecko-dev/tree/master/layout/reftests/svg/filters

   heycam: some filters are easier to test as reftests than others
   ... e.g. the color transform tests just do it on a solid color
   fill

   krit: but even that could differ on other implementations, by
   on RGB value

   heycam: so you can't specify pixel tolerances for the
   web-platform-tests setup?

   krit: you can exploit that pixels have to be clamped to within
   [0..255]
   ... and produce a test that puts you in that range

   ChrisL: I can see the advantage of automated tests but it makes
   writing the tests hard
   ... and boring

   Tav: I thought we agreed to have both (automated and manual)

   krit: but then how do you deliver the tests?

   heycam: we had that in the past, we asked people to eyeball the
   tests

   ChrisL: web-platform-tests doesn't allow multiple references
   like the CSS tests do
   ... it allows you to say it should match one or more references
   ... I remember that when we first did filters there were a lot
   of images exchanged and equations specced so that we had two
   implementations that were roughly pixel equivalent

   heycam: well ideally the definitions of the filter primitives
   are precise enough that you could say that
   ... the results should equal a certain image +/- a tolerance
   ... we could just add raster images and then work out what to
   do when it comes to automating
   ... since we don't have automation yet anyway
   ... maybe we don't need to worry about 1 pixel differences just
   yet

   ChrisL: well there are almost no tests at the moment so it
   would be better to have something people can argue over
   ... I thought of a way to test feDisplacement by covering a red
   rectangle

   heycam: some of the specs Adobe works on include a testing
   plan...

   krit: not for filters yet

   heycam: suppose you wanted to get help with testing, it would
   be helpful to have a list of what still needs testing

   ChrisL: when you look at the tests, the metadata in the tests
   tells you which section it covers

   heycam: so we could start by picking a section that doesn't
   have any tests

   ChrisL: we should also have tests to cover SVG, not just HTML
   ... thanks for the status update, that's helpful

SVG charter

   ChrisL: the charter went out just recently
   ... there's been a change in the W3C
   ... every charter that goes out needs to have positive
   responses from at least 5% of membership
   ... which equals about 20 members
   ... so please push your AC reps to respond

accessibility TF

   <ed> question: Should there be a Co-Facilitator? If so, I would
   expect the SVG

   <ed> Chairs would wish to nominate someone?

   ed: there was a mail about the accessibility TF asking who
   should lead this work from the SVG side

   heycam: so they're looking for a co-facilitator from our side?

   ed: yes

   heycam: if Rich is going to be heavily involved in the TF then
   I'd be happy for him to take it on if he feels comfortable with
   it
   ... I'll send a mail to Rich

   ChrisL: who else is going to be on it?

   heycam: I'll follow the mailing list

   krit: I'll be on the call and join the mailing list

text and CSS boxes

   Tav: CSS has blocks and inlines
   ... do SVG <text> elements behave as blocks and <tspans> as
   inlines?

   heycam: that's roughly how it works internally in Firefox

   <ChrisL> <text> is block, <tspan> is inline

   Tav: I was just wondering how to apply some of the CSS
   properties like line-height to SVG

   heycam: if you have specific questions about properties then
   they would be good things to bring up

TPAC

   ChrisL: I updated the wiki so we have a page for the TPAC now

   nikos_: do we know when the FXTF meeting is?

   ChrisL: no, but it seems like it might be during the SVG part
   of the week

   heycam: I recall something like that
   ... I'll send an email about that

   RRSAgent: make minutes public

   RRSAgent: make minutes

   apologies: Rik, Thomas, Cyril

   RRSAgent: make minutes

Summary of Action Items

   [End of minutes]
     __________________________________________________________


    Minutes formatted by David Booth's [15]scribe.perl version
    1.138 ([16]CVS log)
    $Date: 2014-09-25 13:42:47 $
     __________________________________________________________

     [15] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [16] http://dev.w3.org/cvsweb/2002/scribe/

Scribe.perl diagnostic output

   [Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.138  of Date: 2013-04-25 13:59:11
Check for newer version at [17]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/

     [17] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Default Present: [IPcaller], ed, birtles, heycam, krit, stakagi, Tav, Ch
risL, nikos_
Present: [IPcaller] ed birtles heycam krit stakagi Tav ChrisL nikos_
Regrets: Rik Thomas Cyril
Agenda: [18]https://www.w3.org/Graphics/SVG/WG/wiki/Agenda
Found Date: 25 Sep 2014
Guessing minutes URL: [19]http://www.w3.org/2014/09/25-svg-minutes.html
People with action items:

     [18] https://www.w3.org/Graphics/SVG/WG/wiki/Agenda
     [19] http://www.w3.org/2014/09/25-svg-minutes.html


   [End of [20]scribe.perl diagnostic output]

     [20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 25 September 2014 13:46:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:20:20 UTC