- From: David Dailey <ddailey@zoominternet.net>
- Date: Tue, 27 Aug 2013 23:54:21 -0400
- To: "'Dirk Schulze'" <dschulze@adobe.com>, "'Michael Mullany'" <michael@sencha.com>
- Cc: "'Jasper van de Gronde'" <th.v.d.gronde@hccnet.nl>, <www-svg@w3.org>, <public-fx@w3.org>
Dirk wrote: " Means there is no better time to talk about removing features that just do a little good and discuss alternatives that are better." Yeah maybe so. However, Michael's point is well-taken. Oftentimes browser makers seem to feel that if there is little content using it, then there is no value to a feature. I remember Microsoft using this argument about SMIL. Why didn't people use SMIL? Was it that it was a bad concept? Was it that people didn't understand it? Was it that declarative solutions are invalid since "programmers" are threatened by it? No, maybe not. Maybe it was because very few browsers had implemented it. If Opera and ASV were the only place that things worked for six to ten years, the rumor that it was a bad idea spread quickly. I remember in a workshop I gave at DevCon5 only two or three years ago hearing repeatedly from several folks that they thought SVG had died. Well, it almost did I suppose. And a few amputations seem to have been recommended by some backwoods surgeons. Expressive power rather than browser maker market-autonomics should ultimately drive specs. However, I am consistently reminded that this viewpoint is idealistic, antiquated, and unappreciated by those with the important work of the future in their hands. On the other, hand, Dirk, I do realize the merits of your argument. If there are better things that accomplish the same purpose, then such conversations should be had! In certain cases (for example SVG SMIL, SVG fonts) the expressive power of the language is harmed by removal. In other cases (markers come to mind, since they have no events attachable and the implementation overhead would appear to be large -- the syntax alone is about four times more complex than both <animate> and <replicate> combined!), maybe the implementation-effort-to-expressive-power ratio is small. I am not at all weighing in on the matter at hand. Not at all, either, am I objecting to the suggestion that scaling of filter chains (as distinct from filter primitives) may be unwieldy and of questionable expressive value. But rather I am just agreeing with Michael in my persistent objection to any argument (and I'm not even sure if someone is making such an argument) that "if few authors are using it, then it must not matter." Such arguments taste a bit like zinc oxide, and my own autonomic systems reply just as involuntarily as the WOFFia does to SVG fonts. SVG, upon a storytime, did build gracefully upon its primitives and it bore the mark of fine architecture. Regards David -----Original Message----- From: Dirk Schulze [mailto:dschulze@adobe.com] Sent: Tuesday, August 27, 2013 1:39 PM To: Michael Mullany Cc: Jasper van de Gronde; www-svg@w3.org; public-fx@w3.org Subject: Re: [filter-effects] resolution dependent filter primitives On Aug 27, 2013, at 7:22 PM, Michael Mullany <michael@sencha.com> wrote: > > Well, scaling of the whole filter chain or a single primitive was specified for 13 years. And yet I can't find any usage in the web beside tests of browser vendors. Again, it is extremely hard to determine the right scale level for the horizontal and vertical axis and chances are high that it does not work as expected on a different object. I assume that this is the reason why it actually was never used by authors. Implementations on the other hand already have these information. At the end both alternatives are reasonable for me. Giving the author a theoretically powerful but practical fragile tool like kernelUnitLength doesn't help IMO. > > > Well please remember that filter usage in general has been minimal because filters haven't been available cross platform until IE10 and Safari 6 (aka the last year). On Android browsers, they're still only available on Android 4 on the latest Samsung browsers. There have also been showstopper bugs on each browser (not to mention that light source positions are still not correct in Chrome and document fragments are still not supported as inputs on Firefox). Means there is no better time to talk about removing features that just do a little good and discuss alternatives that are better. Greetings, Dirk
Received on Wednesday, 28 August 2013 03:54:58 UTC