Re: name of 'filter' property and corresponding CSSStyleDeclaration property

Hi, Maciej-

Maciej Stachowiak wrote (on 11/16/08 8:59 PM):
> 
> On Nov 16, 2008, at 5:17 PM, Doug Schepers wrote:
> 
>> It's something to consider... I'm not going to jump to the conclusion
>> that renaming the 'filter' property is the right solution, since that
>> might be a bit drastic for legacy content, viewers, and authoring tools.
>>
>> Moreover, it's not clear that renaming 'filter' will, at this point,
>> solve anything... there will still be legacy SVG content out there, just
>> as there is (legacy?) IE-filter content out there.  A UA which wishes to
>> account for both will have to implement accordingly.
> 
> It's true that it is a little late to fix this problem completely.
> 
> I think there is sufficiently little SVG content on the Web that it's
> not too late for a new property name to help.

A possible alternate name, if it comes down to it, might be 'filters'
(plural), where a list of filters could be specified.  It would
essentially be an ordered list where the result of the first filter
would serve as the input for the second filter, as a sort of implicit
<feMerge>.  This is just brainstorming, though... I haven't thought it
through thoroughly.  Obviously, another scenario is to rename it with no
difference in functionality, if there is a suitable name short enough.

However, this is far from optimal.  SVG content is found not only on the
Web... I've spoken to many people in the Inkscape community for whom the
Web is simply not a target for their content.  They use SVG as an open
art medium, an alternative to Illustrator, and they tend to make heavy
use of filters.


>> It's possible that Maciej's use case is an aspect of the case that wasn't
>> discussed enough (use in HTML was discounted in that earlier
>> discussion), so I agree that we should figure out what the best strategy
>> forward is at this point.
> 
> The problem scenario is like this:
> 
> 1) WebKit implements the SVG 'filter' property, but not the Internet
> Explorer 'filter' property.
> 2) We will almost certainly never implement the IE proprietary 'filter'
> syntax, since it is so thoroughly tied to DirectX and we consider Mac OS
> X a tier 1 platform.
> 3) Some Web content tests the CSS OM for presence of a 'filter'
> property; if present, it assumes the browser is Internet Explorer, and
> uses the 'filter' property with IE-specific syntax to control opacity,
> instead of the standard 'opacity' property.
> 
> We ran into multiple sites where 3 was true.
> 
> Our solution was to have the 'filter' property present but undetectable
> to typical if statement checks, using similar techniques to what we use
> for document.all.
> 
>>  We should look at exactly how IE-filter is
>> being used, and see if we can come up with an effective hack that allows
>> both to exist in harmony.
> 
> We already have a hack that more or less does that. WebKit's hack is
> exactly what the ECMAScript working group complained about. I think it
> would be better to have a name that could be hack-free in the CSS OM.
> But the hack is not something that is all that hard to live with. It
> does interfere somewhat with the possibility of SVG content feature
> testing for filter support.

Thanks for the context (I hadn't yet followed up on reading the list
Cameron forwarded the email from, thought I'd guessed it was something
like that).

Your solution seems fairly sensible, though it's a shame you had to do
it.  Are the sites "dead" (unmaintained), or is there a possibility you
could ask them to fix their content?

What is the effect on sites that are broken in this way?  Just that they
use IE-specific opacity?  Would another possible solution be for you to
make a hack that maps that IE-opacity syntax to the standard 'opacity'
value, such that SVG's 'filter' could be exposed?

Regards-
-Doug

Received on Monday, 17 November 2008 03:52:24 UTC