SVG Working Group Teleconference -- 13 Nov 2014

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

- DRAFT -

SVG Working Group Teleconference

13 Nov 2014

Attendees

Contents