Meeting minutes
chained filter support, aka href on the filter element
karlcow: Filter was removed from SVG 2 into its own spec as part of the CSS charter.
karlcow: There is a mechanism of chaining filters.
karlcow: This allowed multiple filter elements where href referencing the first filter element
karlcow: This is working in Firefox but not in Chrome or Safari
karlcow: In the Filter Effects spec there is a reference to SVG URI as a mixing for DOM. But it is not defined at all in the prose.
karlcow: Robert, from FF, would like to not remove the feature. So putting it on the agenda what we should do with it.
karlcow: Do we keep it? If we keep it, what is the interest of Chrome and Safari?
karlcow: Spec text needs to be added.
karlcow: The CSS spec has no reference at all of the DOM SVG URI mixing.
krit: This was a joined spec between SVG and CSS WG and requires approval from both groups.
karlcow: The CSS WG specifically asks for input.
nzimmermann: What is the definition of filter units in the case of chaining filter elements. IMO it is very unfortunate. You can do the same by shuffeling the elements in the document for browsers it is hard to do to keep the invalidation paths for multiple filter effects at the same time.
nzimmermann: I would be in favor of removing due to the complexity
dmangal: Robert mentions chaining gradients and patterns?
krit: there is for gradients but not for patterns AFAIK
<karlcow> https://
dmangal: I am leaning to agree with Niko that this is more work to do.
<karlcow> > A URL reference to a template gradient element; to be valid, the reference must be to a different ‘linearGradient’ or a ‘radialGradient’ element.
nzimmermann: There is another aspect to gradients and patterns: it is purely resolved on the DOM side for Chrome and Safari. For filters it is different.
<karlcow> https://
<karlcow> > A URL reference to a template element, which must be a different ‘pattern’ element to be valid.
<karlcow> > Refer to the process for using paint servers as templates, and to the common handling defined for URL reference attributes and deprecated XLink attributes.
nzimmermann: Webkit is not prepared for such reference chains. While for SVG we have to do these loops of masks, gradients, resources in general.
nzimmermann: I am still believe we should remove it.
nzimmermann: I don't see a use case for the chaining either.
Tav: We don't implement it. It might not be as useful but I don't think it would be to hard to implement for InkScape.
Tav: I'd rather like implementations to focus on other implementation aspects :)
dmangal: We have no users asking for it.
Tav: No opinion
nzimmermann: Remove it.
Vinay: We can remove it. We can not force FF to do it of course.
RESOLUTION: Suggestion to CSS WG: Remove possibility for filters to reference other filters. Remove the SVG URI DOM interface as well.
<karlcow> https://
nzimmermann: Filter is in the same category as masking and clipping which does not allow chaining.
krit: For clippath we do have chaining?
nzimmermann: I was specifically referencing to href
Clarify SMIL animation behavior when path 'd' value is an empty string
viralipurbey: About the behavior of SMIL animation on empty path string animations.
viralipurbey: It is not clear how to apply the animation from from to to.
viralipurbey: For from animations have discrete animations and by animations will not animate.
viralipurbey: For empty path it is not clear though. Firefox already implements it as discrete animations for from and for by they do not animate and use the base value.
viralipurbey: I believe that the FF behavior is the right way to go.
viralipurbey: In Chrome we just implemented empty string and did start from 0. I don't think that is correct and we reverted it.
RESOLUTION: For SMIL animation on empty path strings we use discrete animations for from animations and no interpolation and animation for by animation making it consistent with incompatible commands.
viralipurbey: Path length extending was discussed in CSS. This is about changing it from number to length. We agreed to first concentrate on presentation attributes. The CSS WG has a resolution to change the type from number to length.
nzimmermann: progression for authors.
RESOLUTION: Follow the suggestion of the cSS WG and let pathLength take a length value rather than a number value.
Status of animVal deprecation
nzimmermann: No update yet. Asked Robert but waiting for a response.
nzimmermann: We need to move in one or the other way.
krit: lets try contacting him again and wait for another 2 weeks before we get to a final decision.
nzimmermann: I'd like to get more understanding from the Chrome team as well: Are there use counters? What would we need to get to a resolution.
dmangal: We can add usage counter and that would be the better way before removing it.
<dmangal> w3c/
nzimmermann: We need to be careful as many might use animVal because it would give the same result on baseVal in case of no animation
Fix #1091 - Clarify the prose of Rendering order section
karlcow: Just suggesting to make the section easier to read... no change of normative behavior. I have a PR for it. Please review.
viralipurbey: I'll review it later.
RRSAgent: make minutes