Tests are written and can be reviewed and commented upon at:
Chromium implementation bug: crbug.com/1169216
See also bug 198416, which is about the basic support (string) for the filter attribute. Or at least it was filed before CanvasFilter was added to the spec, so that's a reasonable interpretation of it.
I would love to use this in my app SVGcode (https://svgco.de/), since the alternative is to work with dynamically built SVG filter strings (https://github.com/tomayac/SVGcode/blob/ae0a3fbf616afee2accdbfaae1c2d79713f631c7/src/js/preprocess.js#L151-L205), which works if I force this execution path in Chrome, but which fails in Safari (tracked as https://bugs.webkit.org/show_bug.cgi?id=198416#c6). So despite being clumsy, it's not even a working work-around.
Long story short, having the new `CanvasFilter` would make my code a lot easier (https://github.com/tomayac/SVGcode/blob/main/src/js/preprocessworker.js#L89-L113).
Have you tried in Chrome Canary? The feature is launched there!
(In reply to Aaron Krajeski from comment #4)
> @Thomas Steiner
> Have you tried in Chrome Canary? The feature is launched there!
Never mind! I just re-read your comment. Glad you're using the new feature in Chrome!
> Never mind! I just re-read your comment. Glad you're using the new feature in Chrome!
Yeah, I use the new code path by default in Chrome, but what I meant with “forcing” the other code path in Chrome was to artificially fail my feature detection so Chrome takes the Safari/Firefox code path just to verify the approach works in theory (it doesn’t in Safari/Firefox in practice).
Resolving this as INVALID per https://github.com/whatwg/html/pull/7874.