12:59:07 <RRSAgent> RRSAgent has joined #svg
12:59:08 <RRSAgent> logging to http://www.w3.org/2014/11/13-svg-irc
12:59:09 <trackbot> RRSAgent, make logs public
12:59:09 <Zakim> Zakim has joined #svg
12:59:11 <trackbot> Zakim, this will be GA_SVGWG
12:59:11 <Zakim> ok, trackbot; I see GA_SVGWG()8:00AM scheduled to start in 1 minute
12:59:12 <trackbot> Meeting: SVG Working Group Teleconference
12:59:13 <trackbot> Date: 13 November 2014
12:59:15 <Zakim> GA_SVGWG()8:00AM has now started
12:59:22 <Zakim> +Krit
12:59:36 <krit> ALONE
12:59:42 <ed> Agenda: http://lists.w3.org/Archives/Public/www-svg/2014Nov/0027.html
12:59:53 <Zakim> +[IPcaller]
13:00:02 <birtles> Zakim, [ is me
13:00:02 <Zakim> +birtles; got it
13:00:06 <Zakim> +[IPcaller]
13:00:15 <ed> Zakim, [IP is me
13:00:15 <Zakim> +ed; got it
13:00:26 <Zakim> +??P3
13:00:35 <Zakim> +[IPcaller]
13:01:14 <stakagi> zakim, ??P3 is me
13:01:14 <Zakim> +stakagi; got it
13:01:20 <stakagi> zakim, ??P3 is me
13:01:20 <Zakim> I already had ??P3 as stakagi, stakagi
13:01:54 <LJWatson> zakim, [IPcaller] is LJWatson
13:01:54 <Zakim> +LJWatson; got it
13:03:01 <Zakim> +??P8
13:03:38 <Tav> Zakim, ??P8 is me
13:03:38 <Zakim> +Tav; got it
13:03:40 <birtles> scribenick: birtles
13:03:43 <birtles> scribe: birtles
13:03:57 <birtles> topic: New telcon time for next week - proposal: 20.30 - 21.30 UTC
13:04:07 <birtles> ed: most people seem to be ok with the new time
13:04:14 <birtles> ... a few others are "ok" with it as a compromise
13:04:20 <birtles> ... so I think we should resolve on the new time
13:04:29 <birtles> ... I'll try to arrange for that to happen before the next call
13:04:32 <birtles> (no objections)
13:04:38 <birtles> ed: ok
13:05:03 <birtles> ACTION: Erik to update the telcon bridge to add the new time
13:05:03 <trackbot> Created ACTION-3687 - Update the telcon bridge to add the new time [on Erik Dahlström - due 2014-11-20].
13:05:17 <birtles> topic: [Filter Effects] feImage without valid image resource. What should happen?
13:05:20 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=27221#c0
13:05:33 <birtles> krit: this is a log to the bug report and I did an investigation
13:05:41 <birtles> ... so feImage can reference other images
13:05:49 <birtles> ... but if it's not available what should be done with the filter and the primitive
13:05:57 <birtles> ... I checked other browsers and identified three different categories
13:06:22 <birtles> ... 1) is the region is basically zero and the filter primitive doesn't have any effect on the filter chain
13:06:29 <birtles> ... 2) transparent black
13:06:36 <birtles> ... 3) the missing image gets painted in this area
13:06:45 <birtles> ... (these are described in the above bug report)
13:07:05 <birtles> ... looking further into this we mostly use transparent black for other error cases
13:07:29 <Zakim> +??P10
13:07:33 <birtles> ... therefore, given the three options, I think we should follow IE/Presto and use transparent black
13:07:38 <birtles> ... any other opinions?
13:07:51 <birtles> ed: so is one option to not render the filter at all?
13:08:00 <birtles> krit: yes, that's an option but it's not implemented anywhere
13:08:06 <birtles> ed: would it make sense to do that?
13:08:23 <birtles> ... I'm not sure which is more useful
13:08:26 <Zakim> +??P11
13:08:52 <birtles> 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
13:09:03 <birtles> ... the question is should we do that for feImage too
13:09:26 <Zakim> -??P10
13:09:26 <birtles> ... yes, I think not rendering anything is also an option
13:09:36 <birtles> ... but if that happens and we don't render the image entirely
13:10:04 <birtles> ... for example, we have a rectangle that we filter with a filter that doesn't exist then the entire rectangle doesn't get rendered
13:10:10 <birtles> ... do we want the same behavior for feImage?
13:10:24 <birtles> ... I kind of like this option, it makes it easier
13:10:28 <Zakim> +??P10
13:10:38 <birtles> Tav: that seems reasonable to me
13:10:57 <Zakim> -??P10
13:11:15 <birtles> birtles: I prefer the transparent black image option
13:11:49 <birtles> ... 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
13:12:02 <birtles> ed: I tend to agree with ransparent black
13:12:07 <birtles> ... and we have 2 implementations for that
13:12:19 <birtles> krit: do we have consensus on transparent black?
13:12:23 <birtles> Tav: that would be ok
13:13:17 <birtles> Proposed resolution: If feImage refers to a missing resource, it should produce transparent black such that it fills the filter region
13:13:32 <birtles> Tav: I think we would actually render the missing image behavior in Inkscape
13:13:47 <birtles> ... just looking at it, we render purple
13:14:06 <birtles> krit: ok, so that's more like Firefox
13:14:27 <birtles> ... Tav, are you willing to change Inkscape to follow the transparent black behavior?
13:14:34 <birtles> ... we know Max can update the Firefox implementation
13:14:54 <birtles> Tav: it might actually make more sense for an authoring tool to show some indication that the resource was missing
13:15:04 <birtles> krit: we could make it a SHOULD requirement
13:15:14 <birtles> ... would that be ok?
13:15:15 <birtles> Tav: yes
13:15:27 <birtles> RESOLUTION: If feImage refers to a missing resource, it should produce transparent black such that it fills the filter region
13:15:56 <birtles> krit: and note that authoring tools may differ by indicating that the resource is missing
13:16:03 <ed> s/filter region/filter primitive subregion/
13:16:31 <birtles> krit: related to that, error handling...
13:16:56 <birtles> ... if you have a filter primitive that references another filter primitive that doesn't exist
13:17:02 <birtles> ... should the whole filter not be rendered?
13:17:27 <birtles> ... basically all browsers currently don't render the element
13:17:32 <birtles> Tav: I wouldn't change that
13:17:34 <krit> <feOffset in=“notThere”/>
13:17:43 <birtles> krit: especially we have interoperable behavior
13:20:24 <birtles> Proposed resolution: If there are broken references within the filter chain, the filtered element should not be rendered
13:21:29 <birtles> Proposed resolution 2: If there are broken references within the filter chain, the filtered element must not be rendered
13:21:41 <birtles> ed: so not just the filter primitive but the whole chain?
13:21:54 <birtles> krit: yes, that's what's implemented pretty much everywhere
13:22:13 <birtles> birtles: if it wasn't so consistently implemented I would probably oppose it and suggest it only applies to the filter primitive
13:22:24 <birtles> ed: I'm ok with that then
13:22:45 <birtles> RESOLUTION: If there are broken references within the filter chain, the filtered element must not be rendered
13:23:10 <birtles> topic: [Filter Effects] Filter primitive input clipping or Filter region input clipping?
13:23:19 <krit> http://lists.w3.org/Archives/Public/public-fx/2014OctDec/0043.html
13:23:20 <birtles> krit: this has been brought up multiple times before
13:23:29 <birtles> ... we had someone at Adobe, Max, investigate this
13:23:49 <birtles> ... what we do in SVG 1.1 is that every filter primitive has input clipping to the filter region and output clipping to the filter region
13:24:24 <krit> s/filter region/primitive subregion/
13:24:26 <krit> s/filter region/primitive subregion/g
13:24:52 <birtles> ... but Max investigated what 4 browsers do is that they just do input clipping to the filter region, not the primitive subregion
13:25:18 <birtles> ed: I think it might depend on which primitives you use
13:25:29 <birtles> krit: it's not interoperable for some primitives
13:25:48 <birtles> ... Max identified which elements have this problem and I think it's just an implementation issue
13:25:53 <birtles> ... I think only IE had this issue
13:26:24 <birtles> ... do we want to revise this previous resolution and use filter region clipping?
13:26:33 <birtles> ... personally I think it's more powerful and also implemented
13:26:43 <birtles> ... so I don't think it's an issue to change the spec to match the implementations
13:27:03 <birtles> ... any objections?
13:27:18 <birtles> ed: so if you want to be able to clip to the subregions do you have any option to do that?
13:27:22 <birtles> krit: no, not at all
13:27:35 <birtles> ed: something to consider for a future level?
13:27:45 <birtles> krit: I don't think this is something that authors are looking for
13:28:11 <birtles> Tav: are those filter primitive regions just there as a resource area so that you weren't dealing with large areas
13:28:23 <birtles> krit: it's just a clipping region, I don't really think it's a performance issue
13:29:26 <birtles> ed: so suppose you split your filter region into four parts and you have a blur in each with different standard deviations
13:29:38 <birtles> ... it's not a great example but you might want to clip in that case
13:30:00 <birtles> krit: you're right, there's no attribute to choose between filter region and primitive subregion
13:30:13 <birtles> ... but you can emulate it in one direction
13:30:45 <birtles> ... so you have more power if clip to the filter region
13:31:15 <birtles> ... with feOffset you can emulate primitive subregion clipping
13:31:38 <birtles> ... Max wrote reference tests and uploaded them to Mozilla
13:32:05 <birtles> ... and he's now working on submitting them to W3C
13:32:42 <birtles> ... can we conclude to the use the filter region for input clipping?
13:33:34 <birtles> birtles: it sounds good, are you also proposing we drop output clipping?
13:33:52 <birtles> krit: actually SVG 1.1 is not clear about when clipping happens
13:33:59 <birtles> ... we tried to clarify that in SVG 1.1 SE
13:34:12 <birtles> ... I'm not proposing dropping output clipping
13:34:24 <birtles> ... that's easy to test and we have interoperable behavior in all browsers for that
13:34:32 <birtles> ed: I'm not hearing any objections
13:35:09 <birtles> Proposed resolution: SVG filter primitives should clip their input to the filter region, not the filter primitive subregion
13:35:28 <birtles> RESOLUTION: SVG filter primitives must clip their input to the filter region, not the filter primitive subregion
13:35:40 <birtles> topic: [Filter Effects] Resolve on last animation issues if needed
13:35:50 <birtles> krit: I've worked together with Brian on animations for filter effects
13:35:58 <birtles> ... and together we defined interpolation and addition
13:36:16 <birtles> .. and for accumulation we decided not to support it but to still define the behavior
13:36:23 <birtles> ... Brian reviewed the section again
13:36:37 <birtles> ... do you have any comments that would change that behavior?
13:36:50 <birtles> birtles: no, nothing substantial
13:37:07 <birtles> krit: I removed the section that talks about how animation elements interact
13:37:16 <birtles> ... if we define how addition etc. work, we don't need it
13:37:53 <birtles> ... I think it's enough to specify interpolation and how accumulation work
13:37:56 <birtles> birtles: I agree
13:38:06 <birtles> krit: the next step is specification
13:38:21 <birtles> ... I would like to propose publishing another working draft
13:38:36 <birtles> ... that should have happened last week but there were some complications
13:38:41 <birtles> ... I would like to get wider review
13:39:01 <birtles> ... so we should publicize it
13:39:07 <birtles> Tav: did you add comments about specular lighting
13:39:11 <birtles> krit: no I haven't
13:39:19 <birtles> ... I agree it is confusing but I'm not sure how to change it
13:39:26 <birtles> Tav: In my comment I had a couple of suggestions
13:39:37 <birtles> krit: in that case I must not have seen those comments
13:39:45 <birtles> ... in that case we should take that to the mailing list
13:40:06 <birtles> Tav: I think it's fine how it is but I think 1 or 2 more lines would make it clearer
13:40:09 <krit> https://www.w3.org/Bugs/Public/show_bug.cgi?id=25411#c2
13:40:55 <birtles> Tav: I think that will avoid this kind of confusion
13:41:07 <birtles> ... it's confusing to have two attributes of the same name that do different things
13:41:11 <birtles> krit: yes
13:41:28 <birtles> ... I think that was one of the most confusing parts of SVG 1.1
13:41:38 <birtles> ... having attributes of the same name that do different things
13:42:01 <birtles> Tav: particularly so in this case because it is a very specific name
13:42:06 <birtles> krit: good point
13:42:46 <birtles> ... I'm asking to the changes and do the publication with the changes from today
13:42:55 <birtles> ... we have already resolved to publish
13:43:03 <birtles> ed: I don't think that's a big problem
13:43:12 <birtles> ... I think it's mostly clarifications
13:43:28 <birtles> ... we can have another resolution if you like
13:43:41 <birtles> krit: I'm not sure what the CSSWG thinks but all these issues are SVG-specific
13:43:53 <birtles> ... so, official, can we have a new WD for Filter Effects?
13:44:24 <birtles> birtles: is it LCWD?
13:44:32 <birtles> krit: we updated the process so we don't have LCWD anymore
13:44:42 <birtles> ... but to my mind, it's like a LCWD
13:44:47 <birtles> ed: I don't hear any objections
13:45:06 <birtles> RESOLUTION: Publish another working draft of Filter Effects
13:45:30 <birtles> topic: [Filter Effects] Put no-composite attribute on at-risk list
13:45:46 <birtles> krit: the no composite attribute we added is not implemented anywhere
13:45:53 <birtles> ... so I would like to make it at-risk
13:46:07 <birtles> ... but we can defer discussing that since it's not important to publishing the next WD
13:46:27 <birtles> topic: [SVG2] Review of introduction sections. Feedback.
13:46:42 <birtles> krit: the introduction still has a strong reference to XML
13:46:53 <birtles> ... for SVG 2 I would not change that
13:47:55 <birtles> ... we should probably change that but probably not in the SVG 2 timeframe
13:47:58 <birtles> ... it also mentions DHTML
13:48:07 <birtles> ed: it should probably mention HTML5
13:48:15 <birtles> ... nothing normative but just to mention it
13:48:25 <birtles> krit: just to mention that it can be used inline in HTML etc.
13:48:28 <birtles> ed: yeah
13:49:06 <birtles> krit: I think we should have a section that just handles interactions with other specifications
13:49:14 <birtles> ... like CSS text decoration, HTML 5 etc.
13:49:42 <birtles> topic: [SVG2] Support blend mode for fill and stroke and be compatible with background property
13:49:52 <birtles> krit: this is a follow-up to our discussion in London
13:50:31 <birtles> ... so fill and stroke have different layers and I'm suggesting we have blending between these layers
13:50:42 <birtles> ... we discussed this in London but Tav wanted more time to think about it
13:50:54 <birtles> Tav: I think as long as it's isolated in the fill or stroke I think it should be fine
13:51:01 <birtles> krit: yes, that's what I'm proposing
13:51:29 <birtles> ... the fill and stroke properties will be something I pick up next week too
13:51:34 <Zakim> +??P12
13:51:48 <birtles> ... I added a bunch of stuff but I haven't finished yet
13:51:58 <birtles> Tav: I looked at the definition of paint in the spec and it's quite confusing
13:52:05 <birtles> krit: agreed
13:52:06 <Zakim> -??P12
13:52:23 <birtles> Proposed resolution: Support blending between fill and stroke layers
13:53:02 <birtles> Tav: how do you specify the blending mode?
13:53:16 <birtles> krit: you just reference the CSS compositing spec
13:53:22 <birtles> ... it will be a CR pretty soon
13:53:32 <birtles> Tav: that's the blending between elements
13:54:29 <birtles> krit: if you look at fill / stroke they have multiple layers
13:54:51 <birtles> ed: so the same syntax as background blending
13:55:03 <birtles> (code example: fill="red multiply blue")
13:56:11 <birtles> RESOLUTION: Support blending for fill and stroke properties as discussed at the London F2F 2014
13:56:24 <birtles> krit: just an organizational issue
13:58:04 <birtles> ... regarding upcoming F2Fs. We can talk about it next week when there are more people
13:58:53 <Zakim> -LJWatson
13:59:01 <Zakim> -Krit
13:59:02 <Zakim> -ed
13:59:02 <Zakim> -Tav
13:59:03 <Zakim> -birtles
13:59:05 <Zakim> -stakagi
13:59:19 <birtles> RRSAgent, make minutes public
13:59:19 <RRSAgent> I'm logging. I don't understand 'make minutes public', birtles.  Try /msg RRSAgent help
13:59:26 <birtles> RRSAgent, make minutes
13:59:26 <RRSAgent> I have made the request to generate http://www.w3.org/2014/11/13-svg-minutes.html birtles
13:59:41 <birtles> Zakim, we're done
13:59:41 <Zakim> I don't understand 'we're done', birtles
13:59:59 <ed> Zakim, end telcon
13:59:59 <Zakim> I don't understand 'end telcon', ed
14:00:14 <ed> trackbot, end telcon
14:00:14 <trackbot> Zakim, list attendees
14:00:14 <Zakim> As of this point the attendees have been Krit, birtles, ed, stakagi, LJWatson, Tav
14:00:22 <trackbot> RRSAgent, please draft minutes
14:00:22 <RRSAgent> I have made the request to generate http://www.w3.org/2014/11/13-svg-minutes.html trackbot
14:00:23 <trackbot> RRSAgent, bye
14:00:23 <RRSAgent> I see 1 open action item saved in http://www.w3.org/2014/11/13-svg-actions.rdf :
14:00:23 <RRSAgent> ACTION: Erik to update the telcon bridge to add the new time [1]
14:00:23 <RRSAgent>   recorded in http://www.w3.org/2014/11/13-svg-irc#T13-05-03