RE: [filter-effects] resolution dependent filter primitives

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