Re: [filter-effects] resolution dependent filter primitives

On Aug 28, 2013, at 5:54 AM, David Dailey <ddailey@zoominternet.net> wrote:

> 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.

Because there are always two sides of a coin. As you say, some features are fairly complex to implement and it needs to be considered if it gets implemented at all. In this case, the spec might have wanted to much from the UA.
On the other hand, if a feature is not supported widely enough, then it is not reliable at all for authors and not from interest. So if one has one of the fortunate UA supporting a feature, but others do not, the burden to maintain a feature may be too hard and of questionable manner. Or a feature is not implemented consistently maybe caused by spec bugs.
The feedback that UAs get from authors is the need of more performance and interoperability. That leads to some of the decisions that are done but unfortunate for a group of people. We all try to balance these decisions.

But this can be discussed in a different threat. For kernelUnitLength and resolution dependent/independent results I am happy to concentrate on the cons and pros of the feature.

Greetings,
Dirk

> 
> 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 05:01:08 UTC