From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van
Kesteren
> Perhaps we could support assigning an SVG filter directly (as an object)?
> Developers would be responsible to load them if they're external. Adding yet
> another network API that's a thin layer on top of some CSS syntax seems a
> little hackish. I'd prefer if we exposed filters at a lower level somehow.
I tend to agree. I don't like that the filter property is now sometimes a
string, sometimes a CanvasFilter.
Maybe something like `setFilter((DOMString or CanvasFilter) filter)` with the
readonly `filter` property returning a CanvasFilter all the time? This would
involve fleshing out CanvasFilter a bit. Strawman:
const filter1 = new CanvasFilter("contrast(50%) blur(3px)");
// filter1 looks like { value: "contrast(50%) blur(3px)", loadedFrom: null }
CanvasFilter.load("file.svg#blur").then(filter2 => {
// filter2 looks like { value: null, loadedFrom: "file.svg#blur" }
ctx.setFilter(filter1);
ctx.strokeText("Canvas", 50, 500);
assert(ctx.filter === filter1);
ctx.setFilter(filter2);
ctx.strokeText("Filters", 50, 100);
assert(ctx.filter === filter2);
ctx.setFilter(filter3);
ctx.strokeText("SVG", 50, 200);
});
This doesn't really solve Anne's concerns about a new networking API, but I am
not sure how to do that given that fragments are involved (which are not a
networking concept, really). Maaaybe you could do something like
fetch("file.svg").then(res => res.blob()).then(blob => {
const filter2 = CanvasFilter.fromSVG(blob, "#blur");
// ...
});
---
Alternately, is it possible to generically represent a loaded SVG filter as a
string? Browsing the linked thread it seems unlikely as it may involve further
external resource fetches etc. But that would help some design space.
