- From: Michael Mullany <michael@sencha.com>
- Date: Sat, 12 Oct 2013 20:53:20 -0700
- To: "public-fx@w3.org" <public-fx@w3.org>
- Message-ID: <CABTYPJ==8FYsX1m9FDQztWDmPA-D0CKViR7y_yAGcScXiXhbsA@mail.gmail.com>
If this has already been discussed and resolved at some stage, I apologize for the duplication + noise in advance. Prompted by a stack-overflow question on css filters, I did an experiment comparing the results of CSS hue-rotate() and saturate() filters with their manual equivalent (explicitly changing hsl() colors). Hue-rotate experiment here: http://codepen.io/mullany/pen/fxsuE Saturate experiment here: http://codepen.io/mullany/pen/rpgHu As you can see, the hue-rotate does a poor job of conserving saturation and lightness, and the saturate does a poor job of conserving lightness. These are extreme examples using fully saturated colors - less saturated and lighter colors don't seem to diverge quite so much as these do. I do understand that because these filters are a linear matrix approximation and remain in RGB space, there will be inaccuracies when trying to do HSL ops, but these seem very extreme to me, and very unexpected. But they seem to be consistent between Firefox and Webkit/Blink - (when converted to SVG equivalents) - so I do not think this is a bug. Has there been any thought of converting content to HSL before applying these filter shorthands? Or adding true HSL primitives to the filter toolbox? (Something like an feFuncH or feFuncS). -- michael
Received on Sunday, 13 October 2013 03:54:17 UTC