filter - Properties

[ddprrt]

I don't know how prefixfree works internally, but I noticed that the new 'filter' property doesn't get prefixed at the moment. Maybe this has something to do with the old style filters available in MS Browsers.

[chriscoyier]

You can put

self.properties.push("filter");

on line 322 (as of this date) and it will work.

Seems like a gnarly way to fix it though... there is probably a more elegant way to handle it. It might just start working eventually, as it seems Prefix free gets it's list of properties through iterating through the browsers own self-reported list of properties it stupports.

[achicu]

Looks like a bug in WebKit. I've logged the following bug: https://bugs.webkit.org/show_bug.cgi?id=113140

[LeaVerou]

The problem is that WebKit supports both filter and -webkit-filter, each with different functionality. Not sure how to solve this in -prefix-free without special casing filter and even then, how do I know what the user wants to do? E.g. it would be catastrophic to start prefixing filter in SVG contexts...

[dirkschulze]

@achicu I disagree here. The new property was prefixed for good reasons IMO. A lot new values were added and are just get finalized. When it get unprefixed, it will replace the old filter property.

@LeaVerou I agree. Special casing is necessary:

For WebKit: filter just works on SVG elements and just accepts SVG filter resources (<filter>). -webkit-filter just works on HTML elements, but supports the new syntax (short hands, <filter> resources).

For Firefox: filter works on all elements but accepts SVG filter resources (<filter>).

IE and Opera support filter but just on SVG elements and just SVG filter resources (<filter>).

Tools like modenizer would need a combination of browser engine identification and specific filter tests. Users should use something like this in the mean time to use the maybe faster shorthands:

-webkit-filter: blur(4px); /* use shorthand filter on current WebKit browsers */
filter: url(#blureFilter); /* Add a SVG resource filter with same functionality */
filter: blur(4px); /* force short hand usage if supported */

This would work on HTML and SVG elements for WebKit browsers and Firefox. It will just work on SVG for current versions of IE and Opera.

It should actually be very simple to automatically write the SVG Filter if a user passes the shorthands. The source code for that is even in the spec.

[achicu]

@dirkschulze My concerns were related to CSSOM. How can you safely read this property from JavaScript?

I think that filter and -webkit-filter should be consistent in regards to their computed value.

I agree that setting the shorthand version should only be possible using the -webkit-filter property, but the computed value should be usable from both properties.

For example: style["-webkit-filter"] = "blur(10px)" will also make style["filter"] == "blur(10px)".

The reason behind that would be that as soon as you use -webkit-filter you are already agreeing that you want experimental CSS syntax.

In that case your snippet would need to be updated, so that -webkit-filter comes second, after the url() version:

filter: url(#blureFilter); /* Add a SVG resource filter with same functionality */
-webkit-filter: blur(4px); /* use shorthand filter on current WebKit browsers */
filter: blur(4px); /* force short hand usage if supported */

[lmarcetic]

Well this is disappointing. A deal breaker for me, I must say.