[filters-effects] Allow nesting filters instead of using 'in', 'in2' and 'result' attributes

[SebastianZ]

Copying this over from w3c/svgwg#258 to continue the discussion in the right repo and to get some more eyes on the proposal.

Filter elements currently use the in and in2 attributes to specify their inputs and result for their output, which is somewhat hard to read, especially when the elements are in a different order than their inputs.

Furthermore, the <feMerge> element already has <feMergeNode> subelements, which makes it inconsistent to the other filter elements.

To improve readability and make the different filter elements consistent it should be possible to nest the different filters to define the inputs similar to how it was mentioned in w3c/svgwg#257 (comment).
That means, the children and their order define which is the first input and which the second.

Example:
Instead of

<filter id="example">
  <feGaussianBlur stdDeviation="4" in="SourceAlpha" result="blur" />
  <feOffset result="offset" in="blur" dy="5" dx="5" />
  <feTurbulence numOctaves="1" baseFrequency="0.05" result="turbulence" in="SourceGraphic" />
  <feComposite result="composite" operator="in" in2="offset" in="turbulence" />
  <feComposite operator="xor" in="SourceGraphic" in2="composite" />
</filter>

you could then write

<filter id="example">
  <feComposite operator="xor" in="SourceGraphic">
    <feComposite operator="in">
      <feTurbulence numOctaves="1" baseFrequency="0.05" in="SourceGraphic" />
      <feOffset result="offset" dy="5" dx="5">
        <feGaussianBlur stdDeviation="4" in="SourceAlpha" />
      </feOffset>
    </feComposite>
  </feComposite>
</filter>

For backwards compatibility, branching and re-joining and to keep the support for the different input types, the in and in2 attributes including their keywords would be kept.

If it's wished to stay consistent, the keywords need to be made available as elements as well, which would then look like this:

<filter id="example">
  <feComposite operator="xor">
    <sourcegraphic />
    <feComposite operator="in">
      <feTurbulence numOctaves="1" baseFrequency="0.05">
        <sourcegraphic />
      </feTurbulence>
      <feOffset result="offset" dy="5" dx="5">
        <feGaussianBlur stdDeviation="4">
          <sourcealpha />
        </feGaussianBlur>
      </feOffset>
    </feComposite>
  </feComposite>
</filter>

@AmeliaBR commented that the suggested syntax may not be much more readable, either and that it's not obvious how many children are allowed for the different filters.

Sebastian

[dirkschulze]

@SebastianZ It might get nasty but still a nice idea. However, in, in2, result are widely implemented and more powerful since you can partly reuse filter primitives or create multiple trees and switch between them with <set>.

We could keep this issue around as a proposal for level 2 of the spec but I do not see a chance that this makes it into a future level of the spec either.

[css-meeting-bot]

The Working Group just discussed [filters-effects] Allow nesting filters instead of using 'in', 'in2' and 'result' attributes.

The full IRC log of that discussion

<krit> topic: [filters-effects] Allow nesting filters instead of using 'in', 'in2' and 'result' attributes
<krit> GitHub: https://github.com/w3c/fxtf-drafts/issues?utf8=✓&q=is%3Aopen+label%3A%22Needs+SVGWG+Input%2FDecision%22++label%3AAgenda%2B
<krit> GitHub: https://github.com//issues/160
<krit> krit: I'd like to make an actual filter tree out of scope for filter effects 1 if we are even do it at all
<krit> Chris__: agree
<krit> Tav: I don't see how to reuse filter primiteves a couple of times.
<krit> Chris__: put a label filter-effects-2 and go on
<krit> krit: fine with me
<krit> Resolution: Defer proposal for a future version of the spec put filters 2 as label on issue.
<krit> Chris__: reminder to put Agenda+ on issues that shall eb on the agenda