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

Minutes, 13 November 2014 SVG Telcon

From: Brian Birtles <bbirtles@mozilla.com>
Date: Thu, 13 Nov 2014 06:06:06 -0800 (PST)
To: www-svg@w3.org
Message-ID: <1977590627.43835203.1415887566014.JavaMail.zimbra@mozilla.com>
Minutes as HTML:


And as text:


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

                               - DRAFT -

                    SVG Working Group Teleconference

13 Nov 2014


      [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


          Krit, birtles, ed, stakagi, LJWatson, Tav

          heycam, rik, TabAtkins, Smailus




     * [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

   <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


     [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
   ... 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
   ... 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
   ... 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

   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?


     [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

   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

   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

   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

   birtles: it sounds good, are you also proposing we drop output

   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
   ... 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
   ... 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


     [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

   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
   ... 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

   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

   [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/

     [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

     [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:46 UTC

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