-
Notifications
You must be signed in to change notification settings - Fork 49
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[filters-effects] Allow nesting filters instead of using 'in', 'in2' and 'result' attributes #160
Comments
@SebastianZ It might get nasty but still a nice idea. However, 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. |
The Working Group just discussed 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 |
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
andin2
attributes to specify their inputs andresult
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
you could then write
For backwards compatibility, branching and re-joining and to keep the support for the different input types, the
in
andin2
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:
@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
The text was updated successfully, but these errors were encountered: