Re: Proposal: feHSL element (was Re: [filter-effects] hue-rotate() and saturate() filters)

On Fri, Oct 18, 2013 at 11:46 AM, Dean Jackson <dino@apple.com> wrote:

>
> On 19 Oct 2013, at 5:22 am, Dean Jackson <dino@apple.com> wrote:
>
> >
> > On 19 Oct 2013, at 3:59 am, Chris Lilley <chris@w3.org> wrote:
> >
> >> Hello Dirk,
> >>
> >> Friday, October 18, 2013, 6:25:29 PM, you wrote:
> >>
> >>> Hi Dean and Chris,
> >>
> >>> I would like to clarify if you are both on the same side.
> >>
> >>> So you both agree that we should have a new feHSL element?
> >>
> >> Not speaking for Dino but I do, yes.
> >>
> >>> You both agree that his primitive should operate in HSL regardless
> >>> of the specified value of the 'color-interpolation-filters' property?
> >>
> >> That is my proposal, yes.
> >>
> >>> And you both agree that you do not want to fix hue-rotate() but
> >>> create a new shorthand function for this new operation?
> >>
> >> I could go either way on that one. I think the shorthand is more
> >> recent, less widely deployed and there is less risk of breaking content
> >> that uses it, so it should be safe to redefine it.
> >>
> >> However, I would be persuaded by arguments that there is deployed
> >> content and that a new shorthand (such as hue-rotate-hsl() for
> >> example) should be created.
> >
> > ^^ This is what I meant: new feHSL and new shorthand hue-rotate-hsl.
>
> BTW - I’m looking forward to seeing the complete math of this new effect.
>

Yes. I wonder if the simple HSL conversion will satisfy the original
use-case where hue was rotated and rotated back with no loss of RGB values.


>
> (Crazy idea: wouldn’t it be cool if the spec had inline JS that
> manipulated a <canvas> element via ImageBuffer? The spec could also be
> the reference implementation.)
>
> Dean
>
>