- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 25 Sep 2014 06:45:43 -0700 (PDT)
- To: www-svg@w3.org
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:11 UTC