Add support for additional blend modes to SVGFEBlendElement

Add support for additional blend modes to SVGFEBlendElement

New modes to be supported are:

  overlay,
  color-dodge,
  color-burn,
  hard-light,
  soft-light,
  difference,
  exclusion,
  hue,
  saturation,
  color and
  luminosity

Since the new modes don't have any corresponding IDL constants exposed
on the SVGFEBlendElement interface, a mechanism is added to be able to
differentiate between "internal" and "exposed" enumeration values, and
reject those that are "internal-only" from being read or written
through SVGAnimatedEnumeration.

Test feBlend-all-modes.html evolved from test in WebKit commit
http://trac.webkit.org/changeset/170433 by Dirk Schulze.

BUG=389594

[Erik Dahlström (inactive), 2014-08-01 15:11:45]

Non-owner LGTM.

[krit, 2014-08-01 16:12:54]

On 2014/08/01 15:11:45, Erik Dahlström wrote:
> Non-owner LGTM.

Having that would be really awesome!

[pdr., 2014-08-01 21:58:22]

This is well implemented but I don't think this is the right approach. This
patch adds a lot of complexity to avoid exposing certain enum values, and by not
exposing these values we are creating an unnecessary discontinuity for authors.

Why are these not just exposed on SVGFEBlendElement?

https://codereview.chromium.org/435623002/diff/1/Source/core/svg/SVGEnumerati...
File Source/core/svg/SVGEnumeration.h (right):

https://codereview.chromium.org/435623002/diff/1/Source/core/svg/SVGEnumerati...
Source/core/svg/SVGEnumeration.h:68: static unsigned short valueOfLastEnum(const
StringEntries& entries) { return entries.last().first; }
Should this be private?

[krit, 2014-08-02 05:16:32]

On 2014/08/01 21:58:22, pdr wrote:
> This is well implemented but I don't think this is the right approach. This
> patch adds a lot of complexity to avoid exposing certain enum values, and by
not
> exposing these values we are creating an unnecessary discontinuity for
authors.
> 
> Why are these not just exposed on SVGFEBlendElement?
> 

It is a resolution of the SVG WG to not expose any new values to the SVG DOM at
this point. We want to deprecate SVG DOM and not encourage authors to write more
content for it. So it didn't seem to help the cause by adding new enumeration
values to the SVG DOM.

[pdr., 2014-08-02 20:05:25]

On 2014/08/02 05:16:32, krit wrote:
> On 2014/08/01 21:58:22, pdr wrote:
> > This is well implemented but I don't think this is the right approach. This
> > patch adds a lot of complexity to avoid exposing certain enum values, and by
> not
> > exposing these values we are creating an unnecessary discontinuity for
> authors.
> > 
> > Why are these not just exposed on SVGFEBlendElement?
> > 
> 
> It is a resolution of the SVG WG to not expose any new values to the SVG DOM
at
> this point. We want to deprecate SVG DOM and not encourage authors to write
more
> content for it. So it didn't seem to help the cause by adding new enumeration
> values to the SVG DOM.

We all agree with the SVG WG's decision to phase out the SVG DOM, but doing this
piecemeal on a single enum property will make removing the SVG DOM trickier. If
we are going to continue shipping an SVG DOM, why bend over backwards to ship a
half-working version of it?

It doesn't look like the WebKit patch implements the exposed and non-exposed
enumeration. Does WebKit not yet have this or was it implemented differently?

[pdr., 2014-08-05 07:38:14]

On 2014/08/02 20:05:25, pdr wrote:
> On 2014/08/02 05:16:32, krit wrote:
> > On 2014/08/01 21:58:22, pdr wrote:
> > > This is well implemented but I don't think this is the right approach.
This
> > > patch adds a lot of complexity to avoid exposing certain enum values, and
by
> > not
> > > exposing these values we are creating an unnecessary discontinuity for
> > authors.
> > > 
> > > Why are these not just exposed on SVGFEBlendElement?
> > > 
> > 
> > It is a resolution of the SVG WG to not expose any new values to the SVG DOM
> at
> > this point. We want to deprecate SVG DOM and not encourage authors to write
> more
> > content for it. So it didn't seem to help the cause by adding new
enumeration
> > values to the SVG DOM.
> 
> We all agree with the SVG WG's decision to phase out the SVG DOM, but doing
this
> piecemeal on a single enum property will make removing the SVG DOM trickier.
If
> we are going to continue shipping an SVG DOM, why bend over backwards to ship
a
> half-working version of it?
> 
> It doesn't look like the WebKit patch implements the exposed and non-exposed
> enumeration. Does WebKit not yet have this or was it implemented differently?

It looks like I am in the minority with this view. The downsides I listed aren't
big issues, at least not big enough to hold up progress in this area.

Lets go ahead with this and I can take my spec issues to www-svg.

LGTM.

[pdr., 2014-08-05 17:28:26]

The CQ bit was checked by pdr@chromium.org

[commit-bot: I haz the power, 2014-08-05 17:30:10]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/fs@opera.com/435623002/1

[commit-bot: I haz the power, 2014-08-05 21:46:11]

FYI, CQ is re-trying this CL (attempt #1).
The failing builders are:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

[pdr., 2014-08-05 22:08:57]

On 2014/08/05 21:46:11, I haz the power (commit-bot) wrote:
> FYI, CQ is re-trying this CL (attempt #1).
> The failing builders are:
>   blink_presubmit on tryserver.blink
>
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

I think this is just a failure to apply the patch at ToT due to
TestExpectations.

[commit-bot: I haz the power, 2014-08-06 00:08:04]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-08-06 00:08:05]

Try jobs failed on following builders:
  blink_presubmit on tryserver.blink
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

[Erik Dahlström (inactive), 2014-08-07 09:29:42]

On 2014/08/06 00:08:05, I haz the power (commit-bot) wrote:
> Try jobs failed on following builders:
>   blink_presubmit on tryserver.blink
>
(http://build.chromium.org/p/tryserver.blink/builders/blink_presubmit/builds/1...)

Since I can't push to this codereview (which is a bad limitation IMHO), I've
rebased this in https://codereview.chromium.org/447193002.

[fs, 2014-08-19 22:34:32]

On 2014/08/05 07:38:14, pdr wrote:
> On 2014/08/02 20:05:25, pdr wrote:
> > On 2014/08/02 05:16:32, krit wrote:
> > > On 2014/08/01 21:58:22, pdr wrote:
> > > > This is well implemented but I don't think this is the right approach.
> This
> > > > patch adds a lot of complexity to avoid exposing certain enum values,
and
> by
> > > not
> > > > exposing these values we are creating an unnecessary discontinuity for
> > > authors.
> > > > 
> > > > Why are these not just exposed on SVGFEBlendElement?
> > > > 
> > > 
> > > It is a resolution of the SVG WG to not expose any new values to the SVG
DOM
> > at
> > > this point. We want to deprecate SVG DOM and not encourage authors to
write
> > more
> > > content for it. So it didn't seem to help the cause by adding new
> enumeration
> > > values to the SVG DOM.
> > 
> > We all agree with the SVG WG's decision to phase out the SVG DOM, but doing
> this
> > piecemeal on a single enum property will make removing the SVG DOM trickier.
> If
> > we are going to continue shipping an SVG DOM, why bend over backwards to
ship
> a
> > half-working version of it?
> > 
> > It doesn't look like the WebKit patch implements the exposed and non-exposed
> > enumeration. Does WebKit not yet have this or was it implemented
differently?
> 
> It looks like I am in the minority with this view. The downsides I listed
aren't
> big issues, at least not big enough to hold up progress in this area.

Personally I do share your views concerning exposed/non-exposed enumerations
(constants really). I think krit's WebKit patch implemented something similar to
this scheme though (maybe less obvious though because of th differences in
enum-handling in general...)

[Erik Dahlström (inactive), 2014-08-20 07:17:11]

On 2014/08/19 22:34:32, fs (ooo) wrote:
> On 2014/08/05 07:38:14, pdr wrote:
> > On 2014/08/02 20:05:25, pdr wrote:
> > > On 2014/08/02 05:16:32, krit wrote:
> > > > On 2014/08/01 21:58:22, pdr wrote:
> > > > > This is well implemented but I don't think this is the right approach.
> > This
> > > > > patch adds a lot of complexity to avoid exposing certain enum values,
> and
> > by
> > > > not
> > > > > exposing these values we are creating an unnecessary discontinuity for
> > > > authors.
> > > > > 
> > > > > Why are these not just exposed on SVGFEBlendElement?
> > > > > 
> > > > 
> > > > It is a resolution of the SVG WG to not expose any new values to the SVG
> DOM
> > > at
> > > > this point. We want to deprecate SVG DOM and not encourage authors to
> write
> > > more
> > > > content for it. So it didn't seem to help the cause by adding new
> > enumeration
> > > > values to the SVG DOM.
> > > 
> > > We all agree with the SVG WG's decision to phase out the SVG DOM, but
doing
> > this
> > > piecemeal on a single enum property will make removing the SVG DOM
trickier.
> > If
> > > we are going to continue shipping an SVG DOM, why bend over backwards to
> ship
> > a
> > > half-working version of it?
> > > 
> > > It doesn't look like the WebKit patch implements the exposed and
non-exposed
> > > enumeration. Does WebKit not yet have this or was it implemented
> differently?
> > 
> > It looks like I am in the minority with this view. The downsides I listed
> aren't
> > big issues, at least not big enough to hold up progress in this area.
> 
> Personally I do share your views concerning exposed/non-exposed enumerations
> (constants really). I think krit's WebKit patch implemented something similar
to
> this scheme though (maybe less obvious though because of th differences in
> enum-handling in general...)

I'll bring this topic up in the SVG WG F2F next week. I think that we want to
drop all const enums from the SVG DOM IDL files, and to replace the enums with
plain DOMStrings going forward.