Intent to ship: CSS Filters

[Max Vujovic]

As of September, we intend to turn CSS Filters on by default on all platforms. It has been developed behind the layout.css.filters.enabled preference.

== Summary ==
CSS Filters allow authors to apply graphical effects like blur, drop-shadow, grayscale, and others to DOM elements using a simple CSS syntax. For example, "filter: blur(3px);".

This feature was not previously discussed in an "intent to implement” thread. Some Mozilla and Adobe folks (Robert O'Callahan, Markus Stange, Bas Schouten, Dirk Schulze, and I) started working on it last summer at a hackathon at the Mozilla San Francisco office.

== Platform Coverage ==
CSS Filters work on all platforms. CSS Filters share the same rendering pipeline as SVG Filters. On Windows, filters use D2D. On other platforms, filters use software rendering. There are plans to accelerate filters on other platforms (https://bugzilla.mozilla.org/show_bug.cgi?id=869496).

== Test Coverage ==
Test coverage is good, with 82 new reftests written under the folders:
layout/reftests/svg/filters/css-filters
layout/reftests/svg/filters/css-filter-chains
layout/reftests/svg/filters/css-svg-filter-chains
layout/reftests/svg/filters/svg-filter-chains

The usual parsing and animation tests are in place as well, and the shared rendering pipeline is additionally covered by the 74 existing SVG filters tests in layout/reftests/svg/filters.

== Spec ==
Filter Effects Module Level 1 is a W3C working draft. Most of the new tests will be submitted to the W3C to support the standard.

== Interop ==
Safari, Chrome, and Opera currently ship an interoperable implementation of CSS Filters behind a -webkit prefix.

== Links ==
Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1057180
Meta bug: https://bugzilla.mozilla.org/show_bug.cgi?id=869828
Links to Standard: http://dev.w3.org/fxtf/filters/ (Editor’s draft), http://www.w3.org/TR/filter-effects-1/ (Working draft)

- Max

[L. David Baron]

On Tuesday 2014-09-16 21:29 +0000, Max Vujovic wrote:
> == Interop ==
> Safari, Chrome, and Opera currently ship an interoperable implementation of CSS Filters behind a -webkit prefix.

Do they have plans to ship without the prefix? It's not really
interoperable if it requires different syntax.

-David

--
𝄞 L. David Baron http://dbaron.org/ 𝄂
𝄢 Mozilla https://www.mozilla.org/ 𝄂
Before I built a wall I'd ask to know
What I was walling in or walling out,
And to whom I was like to give offense.
- Robert Frost, Mending Wall (1914)

[Max Vujovic]

On Sep 16, 2014, at 2:44 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Tuesday 2014-09-16 21:29 +0000, Max Vujovic wrote:
>> == Interop ==
>> Safari, Chrome, and Opera currently ship an interoperable implementation of CSS Filters behind a -webkit prefix.
>
> Do they have plans to ship without the prefix? It's not really
> interoperable if it requires different syntax.

I’m sure they plan to ship unprefixed at some point. I'll ask on webkit-dev and blink-dev about what they need to get there.

The syntax is interoperable after the property name, at least. If we ship CSS Filters, we’ll see code like this:
-webkit-filter: blur(3px);
filter: blur(3px);

And I’m thinking many web developers will be using an automated prefixing solution and simply writing:
filter: blur(3px);

Unfortunately, many of the CSS Filters examples I see on the web today are using the -webkit prefix exclusively:
-webkit-filter: blur(3px);

I’m hoping that Firefox shipping unprefixed will help break that habit.

- Max

[Rik Cabanier]

On Tue, Sep 16, 2014 at 2:44 PM, L. David Baron <dba...@dbaron.org> wrote:

> On Tuesday 2014-09-16 21:29 +0000, Max Vujovic wrote:
> > == Interop ==
> > Safari, Chrome, and Opera currently ship an interoperable implementation
> of CSS Filters behind a -webkit prefix.
>
> Do they have plans to ship without the prefix? It's not really
> interoperable if it requires different syntax.
>

Are you suggesting that we should add a '-webkit-filter' property so
Firefox is interoperable?
A cursory glance on GitHub [1] shows that roughly 2 out of 3 sites only use
the prefixed version.

1:
https://github.com/search?l=css&o=desc&p=22&q=-webkit-filter&ref=searchresults&s=&type=Code&utf8=%E2%9C%93

[L. David Baron]

On Tuesday 2014-09-16 16:31 -0700, Rik Cabanier wrote:
> On Tue, Sep 16, 2014 at 2:44 PM, L. David Baron <dba...@dbaron.org> wrote:
>
> > On Tuesday 2014-09-16 21:29 +0000, Max Vujovic wrote:
> > > == Interop ==
> > > Safari, Chrome, and Opera currently ship an interoperable implementation
> > of CSS Filters behind a -webkit prefix.
> >
> > Do they have plans to ship without the prefix? It's not really
> > interoperable if it requires different syntax.
> >
>
> Are you suggesting that we should add a '-webkit-filter' property so
> Firefox is interoperable?

No. I'm suggesting that we should try to ensure that Blink and
WebKit unprefix sooner rather than later.

[Dirk Schulze]

> On Sep 17, 2014, at 2:44 AM, "L. David Baron" <dba...@dbaron.org> wrote:
>
>> On Tuesday 2014-09-16 16:31 -0700, Rik Cabanier wrote:
>>> On Tue, Sep 16, 2014 at 2:44 PM, L. David Baron <dba...@dbaron.org> wrote:
>>>
>>>> On Tuesday 2014-09-16 21:29 +0000, Max Vujovic wrote:
>>>> == Interop ==
>>>> Safari, Chrome, and Opera currently ship an interoperable implementation
>>> of CSS Filters behind a -webkit prefix.
>>>
>>> Do they have plans to ship without the prefix? It's not really
>>> interoperable if it requires different syntax.
>>
>> Are you suggesting that we should add a '-webkit-filter' property so
>> Firefox is interoperable?
>
> No. I'm suggesting that we should try to ensure that Blink and
> WebKit unprefix sooner rather than later.

Shorthand filters are just supported on HTML content in WebKit and Blink. SVG content exclusively works with the unprefixed filter property which currently just supports a reference to SVG <filter> elements. Once that is fixed, both platforms will support the shorthand functions on unprefixed filter as well. However, it is unlikely that the prefixed property will be removed soon. Shipping CSS filters in Firefox is a strong signal to web developers. The specification is getting finalized and changes to the existing functions must be compatible to the current implementation in WebKit, Blink and Gecko and will not be accepted for level 1 of the spec.

Greetings
Dirk

[Max Vujovic]

On Sep 16, 2014, at 9:52 PM, Dirk Schulze <dsch...@adobe.com> wrote:

>
>
>> On Sep 17, 2014, at 2:44 AM, "L. David Baron" <dba...@dbaron.org> wrote:
>>
>>> On Tuesday 2014-09-16 16:31 -0700, Rik Cabanier wrote:
>>>> On Tue, Sep 16, 2014 at 2:44 PM, L. David Baron <dba...@dbaron.org> wrote:
>>>>
>>>>> On Tuesday 2014-09-16 21:29 +0000, Max Vujovic wrote:
>>>>> == Interop ==
>>>>> Safari, Chrome, and Opera currently ship an interoperable implementation
>>>> of CSS Filters behind a -webkit prefix.
>>>>
>>>> Do they have plans to ship without the prefix? It's not really
>>>> interoperable if it requires different syntax.
>>>
>>> Are you suggesting that we should add a '-webkit-filter' property so
>>> Firefox is interoperable?
>>
>> No. I'm suggesting that we should try to ensure that Blink and
>> WebKit unprefix sooner rather than later.
>
> Shorthand filters are just supported on HTML content in WebKit and Blink. SVG content exclusively works with the unprefixed filter property which currently just supports a reference to SVG <filter> elements. Once that is fixed, both platforms will support the shorthand functions on unprefixed filter as well. However, it is unlikely that the prefixed property will be removed soon. Shipping CSS filters in Firefox is a strong signal to web developers. The specification is getting finalized and changes to the existing functions must be compatible to the current implementation in WebKit, Blink and Gecko and will not be accepted for level 1 of the spec.

Thanks for the info, Dirk. I just asked the question on webkit-dev [1] and blink-dev [2], which might surface other blockers in those projects. At the least, I hope it draws some attention to shipping an unprefixed version.

[1]: https://lists.webkit.org/pipermail/webkit-dev/2014-September/026871.html
[2]: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/R2gCfHjNgKs

- Max

[Jet Villegas]

I see the r+ on https://bugzilla.mozilla.org/show_bug.cgi?id=1057180

Are we missing anything else to checkin+ and turn this on?

--Jet

_______________________________________________
dev-platform mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Max Vujovic]

Hi Jet,

The patch to turn CSS filters on is tripping over a filters parsing test on the B2G try bot. I added more details on the bug. It seems like a silly problem, but I’m not sure what’s going on yet. Maybe dbaron has seen something like this before? Otherwise, I’m trying to set up a B2G build to repro the problem.

Thanks,
Max

[L. David Baron]

On Wednesday 2014-10-01 22:03 +0000, Max Vujovic wrote:
> The patch to turn CSS filters on is tripping over a filters parsing test on the B2G try bot. I added more details on the bug. It seems like a silly problem, but I’m not sure what’s going on yet. Maybe dbaron has seen something like this before? Otherwise, I’m trying to set up a B2G build to repro the problem.

Comment in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1057180#c19