Intent to Ship: Unprefixed CSS Filters
74 views
Skip to first unread message
Fredrik Söderquist
Jun 7, 2016, 7:27:30 AM6/7/16
to blink-dev
f...@opera.com, (no...@chromium.org [initiator; OOO])
http://dev.w3.org/fxtf/filters/
CSS Filters without the -webkit- prefix.
CSS Filters has been shipping prefixed, for HTML, since Chrome 19 (https://www.chromestatus.com/feature/5822463824887808), while also shipping as unprefixed for SVG content. This duality has lead to some weird behavior (244295, 535786, 550249; possibly more...) All other browsers ship unprefixed filters.
Firefox: Shipped
Edge: Shipped
Safari: Shipped
Web developers: Positive
Generally thought to be low, since an alias will be kept around, and because of the history of this property it often has fallbacks.
There could be a risk with fallbacks where the unprefixed property wouldn't apply before, but now will, and cause an error. (An example: might be: "filter: url('data:image/svg+xml,...#myFilter');" now overriding a -webkit-filter defining the same thing using non-url filter functions.)
Dimitri Glazkov
Jun 7, 2016, 10:52:48 AM6/7/16
to Fredrik Söderquist, blink-dev
LGTM
PhistucK
Jun 7, 2016, 12:10:16 PM6/7/16
to Dimitri Glazkov, Fredrik Söderquist, blink-dev
As far as I remember, one of the reasons for not sending an intent to implement or ship before, was that Blink does not support these filters (not the url one) on SVG elements. Has the situation changed?
Do other browsers support these filters on SVG elements?
☆PhistucK
LGTM
--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
PhistucK
Jun 7, 2016, 12:12:29 PM6/7/16
to Dimitri Glazkov, Fredrik Söderquist, blink-dev
Also, do the implementations interoperate in terms of the visual output?
(I assume that the syntax part already interoperates, or else you would not be sending this intent)
☆PhistucK
Fredrik Söderquist
Jun 7, 2016, 12:15:05 PM6/7/16
to PhistucK, Dimitri Glazkov, blink-dev
On Tue, Jun 7, 2016 at 6:09 PM, PhistucK <phis...@gmail.com> wrote:
As far as I remember, one of the reasons for not sending an intent to implement or ship before, was that Blink does not support these filters (not the url one) on SVG elements. Has the situation changed?
It hasn't. Yet.
Do other browsers support these filters on SVG elements?
Some do, some don't. (Gecko does, WebKit doesn't for instance.)
/fs
☆Phistu
On Tue, Jun 7, 2016 at 5:52 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:LGTM--On Tue, Jun 7, 2016 at 4:27 AM, Fredrik Söderquist <f...@opera.com> wrote:f...@opera.com, (no...@chromium.org [initiator; OOO]) http://dev.w3.org/fxtf/filters/ CSS Filters without the -webkit- prefix.CSS Filters has been shipping prefixed, for HTML, since Chrome 19 (https://www.chromestatus.com/feature/5822463824887808), while also shipping as unprefixed for SVG content. This duality has lead to some weird behavior (244295, 535786, 550249; possibly more...) All other browsers ship unprefixed filters.Firefox: Shipped Edge: Shipped Safari: Shipped Web developers: PositiveGenerally thought to be low, since an alias will be kept around, and because of the history of this property it often has fallbacks.There could be a risk with fallbacks where the unprefixed property wouldn't apply before, but now will, and cause an error. (An example: might be: "filter: url('data:image/svg+xml,...#myFilter');" now overriding a -webkit-filter defining the same thing using non-url filter functions.)
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
Fredrik Söderquist
Jun 7, 2016, 12:29:59 PM6/7/16
to PhistucK, Dimitri Glazkov, blink-dev
On Tue, Jun 7, 2016 at 6:11 PM, PhistucK <phis...@gmail.com> wrote:
Also, do the implementations interoperate in terms of the visual output?
I'm not aware of any major discrepancies. There used to be mixups with colorspaces for url(...) filters, but I haven't seen anything about that in a while (and no bugs on file AFAICS.)
/fs
PhistucK
Jun 7, 2016, 12:39:45 PM6/7/16
to Fredrik Söderquist, Dimitri Glazkov, blink-dev
Is there a test suite? Some actual pass rate reports that can be shown?
☆PhistucK
Fredrik Söderquist
Jun 7, 2016, 12:56:18 PM6/7/16
to PhistucK, Dimitri Glazkov, blink-dev
On Tue, Jun 7, 2016 at 6:39 PM, PhistucK <phis...@gmail.com> wrote:
Is there a test suite? Some actual pass rate reports that can be shown?
There's http://test.csswg.org/suites/filter-effects/nightly-unstable/ - which is not impressively large. It does have result data, but the age of that is not obvious.
/fs
☆Phistuc
PhistucK
Jun 7, 2016, 3:31:44 PM6/7/16
to Fredrik Söderquist, Dimitri Glazkov, blink-dev
Well, as outdated as they are, the results show differences... Can you verify that they no longer exist, or work with (well, notify) the other browsers in order to minimize them, in case Blink is correct in its implementation and try and fix the differences if Blink is incorrect?
☆PhistucK
Fredrik Söderquist
Jun 8, 2016, 11:02:37 AM6/8/16
to PhistucK, Dimitri Glazkov, blink-dev
On Tue, Jun 7, 2016 at 9:31 PM, PhistucK <phis...@gmail.com> wrote:
Well, as outdated as they are, the results show differences... Can you verify that they no longer exist, or work with (well, notify) the other browsers in order to minimize them, in case Blink is correct in its implementation and try and fix the differences if Blink is incorrect?
I ran through the tests for FF nightly and Edge 14.14(...) and the results were 1 and 6 fails respectively. In the case of Edge, two of those appear to be around using external filters.
For a content_shell with the unprefixing CL applied, we fail 4, two of which look like fairly simple and one (shared with Edge) that needs deeper analysis. Will file and fix those as appropriate.
And one of the fails appears to be due to a bug in the CSS WG test-runner/"compiler" - it appeared to work when run standalone though. So make that 0 and 3 as appropriate then...
/fs
Philip Jägenstedt
Jun 8, 2016, 11:14:13 AM6/8/16
to Fredrik Söderquist, PhistucK, Dimitri Glazkov, blink-dev
LGTM2, assuming you yourself judge the differences revealed by those tests to be small enough to be manageable. Given that everybody else has already shipped and that this will be an alias intended to stay an alias, the risk/difficulty of trying to make changes to the behavior seems about the same before and after unprefixing, while delaying shipping has a clear downside.
Rick Byers
Jun 9, 2016, 8:07:38 PM6/9/16
to Philip Jägenstedt, Fredrik Söderquist, PhistucK, Dimitri Glazkov, blink-dev
LGTM3. Thanks for the investigation into the test suite! I love to hear that that's actually finding interop bugs.
Elliott Sprehn
Jun 10, 2016, 1:58:38 PM6/10/16
to Fredrik Söderquist, Brenton Simpson, blink-dev
This is very exciting, I was working with a designer recently who was very confused why filter only worked on svg in Chrome but worked on html in other browsers.
Excited to see another wtf moment removed from the platform. :)
0 new messages