- From: Brian Birtles <bbirtles@mozilla.com>
- Date: Thu, 13 Nov 2014 06:06:06 -0800 (PST)
- To: www-svg@w3.org
Minutes as HTML:
http://www.w3.org/2014/11/13-svg-minutes.html
And as text:
[1]W3C
[1] http://www.w3.org/
- DRAFT -
SVG Working Group Teleconference
13 Nov 2014
[2]Agenda
[2] http://lists.w3.org/Archives/Public/www-svg/2014Nov/0027.html
See also: [3]IRC log
[3] http://www.w3.org/2014/11/13-svg-irc
Attendees
Present
Krit, birtles, ed, stakagi, LJWatson, Tav
Regrets
heycam, rik, TabAtkins, Smailus
Chair
SV_MEETING_CHAIR
Scribe
birtles
Contents
* [4]Topics
1. [5]New telcon time for next week - proposal: 20.30 -
21.30 UTC
2. [6][Filter Effects] feImage without valid image
resource. What should happen?
3. [7][Filter Effects] Filter primitive input clipping or
Filter region input clipping?
4. [8][Filter Effects] Resolve on last animation issues
if needed
5. [9][Filter Effects] Put no-composite attribute on
at-risk list
6. [10][SVG2] Review of introduction sections. Feedback.
7. [11][SVG2] Support blend mode for fill and stroke and
be compatible with background property
* [12]Summary of Action Items
__________________________________________________________
<trackbot> Date: 13 November 2014
<krit> ALONE
<scribe> scribenick: birtles
<scribe> scribe: birtles
New telcon time for next week - proposal: 20.30 - 21.30 UTC
ed: most people seem to be ok with the new time
... a few others are "ok" with it as a compromise
... so I think we should resolve on the new time
... I'll try to arrange for that to happen before the next call
(no objections)
ed: ok
<scribe> ACTION: Erik to update the telcon bridge to add the
new time [recorded in
[13]http://www.w3.org/2014/11/13-svg-minutes.html#action01]
<trackbot> Created ACTION-3687 - Update the telcon bridge to
add the new time [on Erik Dahlström - due 2014-11-20].
[Filter Effects] feImage without valid image resource. What should
happen?
<krit>
[14]https://www.w3.org/Bugs/Public/show_bug.cgi?id=27221#c0
[14] https://www.w3.org/Bugs/Public/show_bug.cgi?id=27221#c0
krit: this is a log to the bug report and I did an
investigation
... so feImage can reference other images
... but if it's not available what should be done with the
filter and the primitive
... I checked other browsers and identified three different
categories
... 1) is the region is basically zero and the filter primitive
doesn't have any effect on the filter chain
... 2) transparent black
... 3) the missing image gets painted in this area
... (these are described in the above bug report)
... looking further into this we mostly use transparent black
for other error cases
... therefore, given the three options, I think we should
follow IE/Presto and use transparent black
... any other opinions?
ed: so is one option to not render the filter at all?
krit: yes, that's an option but it's not implemented anywhere
ed: would it make sense to do that?
... I'm not sure which is more useful
krit: yes, that might be more useful but if you reference a
filter that doesn't exist then the whole filter doesn't get
rendered in Opera for example
... the question is should we do that for feImage too
... yes, I think not rendering anything is also an option
... but if that happens and we don't render the image entirely
... for example, we have a rectangle that we filter with a
filter that doesn't exist then the entire rectangle doesn't get
rendered
... do we want the same behavior for feImage?
... I kind of like this option, it makes it easier
Tav: that seems reasonable to me
birtles: I prefer the transparent black image option
... I think having disastrous failure behavior is not very nice
especially if the feImage resource is just unavailable due to
network issues -- we should render something
ed: I tend to agree with ransparent black
... and we have 2 implementations for that
krit: do we have consensus on transparent black?
Tav: that would be ok
Proposed resolution: If feImage refers to a missing resource,
it should produce transparent black such that it fills the
primitive subregion
Tav: I think we would actually render the missing image
behavior in Inkscape
... just looking at it, we render purple
krit: ok, so that's more like Firefox
... Tav, are you willing to change Inkscape to follow the
transparent black behavior?
... we know Max can update the Firefox implementation
Tav: it might actually make more sense for an authoring tool to
show some indication that the resource was missing
krit: we could make it a SHOULD requirement
... would that be ok?
Tav: yes
RESOLUTION: If feImage refers to a missing resource, it should
produce transparent black such that it fills the filter
primitive subregion
krit: and note that authoring tools may differ by indicating
that the resource is missing
... related to that, error handling...
... if you have a filter primitive that references another
filter primitive that doesn't exist
... should the whole filter not be rendered?
... basically all browsers currently don't render the element
Tav: I wouldn't change that
<krit> <feOffset in=“notThere”/>
krit: especially we have interoperable behavior
Proposed resolution: If there are broken references within the
filter chain, the filtered element should not be rendered
Proposed resolution 2: If there are broken references within
the filter chain, the filtered element must not be rendered
ed: so not just the filter primitive but the whole chain?
krit: yes, that's what's implemented pretty much everywhere
birtles: if it wasn't so consistently implemented I would
probably oppose it and suggest it only applies to the filter
primitive
ed: I'm ok with that then
RESOLUTION: If there are broken references within the filter
chain, the filtered element must not be rendered
[Filter Effects] Filter primitive input clipping or Filter region
input clipping?
<krit>
[15]http://lists.w3.org/Archives/Public/public-fx/2014OctDec/00
43.html
[15] http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0043.html
krit: this has been brought up multiple times before
... we had someone at Adobe, Max, investigate this
... what we do in SVG 1.1 is that every filter primitive has
input clipping to the primitive subregion and output clipping
to the primitive subregion
... but Max investigated what 4 browsers do is that they just
do input clipping to the filter region, not the primitive
subregion
ed: I think it might depend on which primitives you use
krit: it's not interoperable for some primitives
... Max identified which elements have this problem and I think
it's just an implementation issue
... I think only IE had this issue
... do we want to revise this previous resolution and use
filter region clipping?
... personally I think it's more powerful and also implemented
... so I don't think it's an issue to change the spec to match
the implementations
... any objections?
ed: so if you want to be able to clip to the subregions do you
have any option to do that?
krit: no, not at all
ed: something to consider for a future level?
krit: I don't think this is something that authors are looking
for
Tav: are those filter primitive regions just there as a
resource area so that you weren't dealing with large areas
krit: it's just a clipping region, I don't really think it's a
performance issue
ed: so suppose you split your filter region into four parts and
you have a blur in each with different standard deviations
... it's not a great example but you might want to clip in that
case
krit: you're right, there's no attribute to choose between
filter region and primitive subregion
... but you can emulate it in one direction
... so you have more power if clip to the filter region
... with feOffset you can emulate primitive subregion clipping
... Max wrote reference tests and uploaded them to Mozilla
... and he's now working on submitting them to W3C
... can we conclude to the use the filter region for input
clipping?
birtles: it sounds good, are you also proposing we drop output
clipping?
krit: actually SVG 1.1 is not clear about when clipping happens
... we tried to clarify that in SVG 1.1 SE
... I'm not proposing dropping output clipping
... that's easy to test and we have interoperable behavior in
all browsers for that
ed: I'm not hearing any objections
Proposed resolution: SVG filter primitives should clip their
input to the filter region, not the filter primitive subregion
RESOLUTION: SVG filter primitives must clip their input to the
filter region, not the filter primitive subregion
[Filter Effects] Resolve on last animation issues if needed
krit: I've worked together with Brian on animations for filter
effects
... and together we defined interpolation and addition
... and for accumulation we decided not to support it but to
still define the behavior
... Brian reviewed the section again
... do you have any comments that would change that behavior?
birtles: no, nothing substantial
krit: I removed the section that talks about how animation
elements interact
... if we define how addition etc. work, we don't need it
... I think it's enough to specify interpolation and how
accumulation work
birtles: I agree
krit: the next step is specification
... I would like to propose publishing another working draft
... that should have happened last week but there were some
complications
... I would like to get wider review
... so we should publicize it
Tav: did you add comments about specular lighting
krit: no I haven't
... I agree it is confusing but I'm not sure how to change it
Tav: In my comment I had a couple of suggestions
krit: in that case I must not have seen those comments
... in that case we should take that to the mailing list
Tav: I think it's fine how it is but I think 1 or 2 more lines
would make it clearer
<krit>
[16]https://www.w3.org/Bugs/Public/show_bug.cgi?id=25411#c2
[16] https://www.w3.org/Bugs/Public/show_bug.cgi?id=25411#c2
Tav: I think that will avoid this kind of confusion
... it's confusing to have two attributes of the same name that
do different things
krit: yes
... I think that was one of the most confusing parts of SVG 1.1
... having attributes of the same name that do different things
Tav: particularly so in this case because it is a very specific
name
krit: good point
... I'm asking to the changes and do the publication with the
changes from today
... we have already resolved to publish
ed: I don't think that's a big problem
... I think it's mostly clarifications
... we can have another resolution if you like
krit: I'm not sure what the CSSWG thinks but all these issues
are SVG-specific
... so, official, can we have a new WD for Filter Effects?
birtles: is it LCWD?
krit: we updated the process so we don't have LCWD anymore
... but to my mind, it's like a LCWD
ed: I don't hear any objections
RESOLUTION: Publish another working draft of Filter Effects
[Filter Effects] Put no-composite attribute on at-risk list
krit: the no composite attribute we added is not implemented
anywhere
... so I would like to make it at-risk
... but we can defer discussing that since it's not important
to publishing the next WD
[SVG2] Review of introduction sections. Feedback.
krit: the introduction still has a strong reference to XML
... for SVG 2 I would not change that
... we should probably change that but probably not in the SVG
2 timeframe
... it also mentions DHTML
ed: it should probably mention HTML5
... nothing normative but just to mention it
krit: just to mention that it can be used inline in HTML etc.
ed: yeah
krit: I think we should have a section that just handles
interactions with other specifications
... like CSS text decoration, HTML 5 etc.
[SVG2] Support blend mode for fill and stroke and be compatible with
background property
krit: this is a follow-up to our discussion in London
... so fill and stroke have different layers and I'm suggesting
we have blending between these layers
... we discussed this in London but Tav wanted more time to
think about it
Tav: I think as long as it's isolated in the fill or stroke I
think it should be fine
krit: yes, that's what I'm proposing
... the fill and stroke properties will be something I pick up
next week too
... I added a bunch of stuff but I haven't finished yet
Tav: I looked at the definition of paint in the spec and it's
quite confusing
krit: agreed
Proposed resolution: Support blending between fill and stroke
layers
Tav: how do you specify the blending mode?
krit: you just reference the CSS compositing spec
... it will be a CR pretty soon
Tav: that's the blending between elements
krit: if you look at fill / stroke they have multiple layers
ed: so the same syntax as background blending
(code example: fill="red multiply blue")
RESOLUTION: Support blending for fill and stroke properties as
discussed at the London F2F 2014
krit: just an organizational issue
... regarding upcoming F2Fs. We can talk about it next week
when there are more people
<ed> trackbot, end telcon
Summary of Action Items
[NEW] ACTION: Erik to update the telcon bridge to add the new
time [recorded in
[17]http://www.w3.org/2014/11/13-svg-minutes.html#action01]
[End of minutes]
__________________________________________________________
Minutes formatted by David Booth's [18]scribe.perl version
1.140 ([19]CVS log)
$Date: 2014-11-13 14:00:27 $
__________________________________________________________
[18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
[19] http://dev.w3.org/cvsweb/2002/scribe/
Scribe.perl diagnostic output
[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.140 of Date: 2014-11-06 18:16:30
Check for newer version at [20]http://dev.w3.org/cvsweb/~checkout~/2002/
scribe/
[20] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/
Guessing input format: RRSAgent_Text_Format (score 1.00)
Succeeded: s/filter region/filter primitive subregion/
Succeeded: s/filter region/primitive subregion/
Succeeded: s/filter region/primitive subregion/g
Found ScribeNick: birtles
Found Scribe: birtles
Inferring ScribeNick: birtles
Default Present: Krit, birtles, ed, stakagi, LJWatson, Tav
Present: Krit birtles ed stakagi LJWatson Tav
Agenda: [21]http://lists.w3.org/Archives/Public/www-svg/2014Nov/0027.htm
l
[21] http://lists.w3.org/Archives/Public/www-svg/2014Nov/0027.html
WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth
Found Date: 13 Nov 2014
Guessing minutes URL: [22]http://www.w3.org/2014/11/13-svg-minutes.html
People with action items: erik
[22] http://www.w3.org/2014/11/13-svg-minutes.html
[End of [23]scribe.perl diagnostic output]
[23] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
Received on Thursday, 13 November 2014 14:06:39 UTC