W3C home > Mailing lists > Public > public-fx@w3.org > April to June 2014

Re: [compositing-1] please move non-separable effects to Level 2

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 29 Apr 2014 21:04:16 -0700
Message-ID: <CAGN7qDAZw8hbfAs8V7Tu2+7ihqDXQusdWULF=a-zdYm-NAy8zg@mail.gmail.com>
To: FX <public-fx@w3.org>
On Thu, Apr 17, 2014 at 1:42 PM, Dean Jackson <dino@apple.com> wrote:

> As of https://trac.webkit.org/r167448 WebKit supports mix-blend-mode
> unprefixed.
> We did this knowing that we will be unable to implement the non-separable
> modes in the near future (hue, saturation, color and luminosity). We
> suggest these be moved to Level 2 of the specification.


WebKit requested that we take the non-separable blend modes out of the spec.
Mozilla and Blink have no problems with the current set and they are also
on track to release all the background blend modes.
In addition, Mozilla stated that they are OK with shipping their current
implementation of mix-blend-mode which includes the non-separable ones.

I think we have the following options:
1. Leave the spec as-is
2. Change the spec, making the non-separable blend modes optional
3. Change the spec and take the non-separable blend modes out and release a
level 2 version that puts them back in.

According to Roc, option 1 is reasonable since it's OK for a browser to
implement a subset [1] but Dean expressed unease.

I proposed option 2 as a compromise, but nobody seemed to like that.

I can see the advantage of option 3 because it means that we'll have a spec
that can be implemented by everyone and this should help us to get to PR
At this point, authors will have to feature test anyway if they want to use
non-separable blend modes regardless if we leave them in or put them in
level 2.

I mentioned in the thread that Adobe was involved in each implementation so
this wouldn't suffice to progress the spec. However, big parts (such as the
blending itself) were implemented outside of our team and all the code was
guided and reviewed by people from each browser engine.
Since there's no code sharing, this requirement should be relaxed.

I think that having a spec that can be implemented by everyone and that can
go to REC, are very strong arguments for option 3.
Does anyone have strong objections? If not, I will prepare to update the
spec and restart the CR process.

1: http://lists.w3.org/Archives/Public/public-fx/2014AprJun/0049.html
Received on Wednesday, 30 April 2014 04:04:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 22 June 2015 03:33:52 UTC