SVG feCompositeElement operator="lighter" value incompletely implemented?
Reported by
jw...@jwatt.org,
Jan 7
|
||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:64.0) Gecko/20100101 Firefox/64.0 Steps to reproduce the problem: https://drafts.fxtf.org/filter-effects/#InterfaceSVGFECompositeElement There is no 'lighter' value specified, but Chrome supports that value. Or at least partially supports it in a strange way. If the 'operator' attribute is set to any truly unknown value in markup, feComposite.operator == SVGFECompositeElement.SVG_FECOMPOSITE_OPERATOR_OVER. When set via script using setAttribute(), an error is thrown. In other words if a content author tries to use an unrecognized operator then the default 'over' operator will be used. So as with other SVG_*_UNKNOWN values, it appears that SVG_FECOMPOSITE_OPERATOR_UNKNOWN can never be encountered in practice. However, if the 'lighter' value is set in markup, feComposite.operator == SVGFECompositeElement.SVG_FECOMPOSITE_OPERATOR_UNKNOWN, and when 'lighter' is set via script no error is thrown. It seems very strange that truly unknown values don't result in SVG_FECOMPOSITE_OPERATOR_UNKNOWN, whereas an apparently known value does... Is there a logic behind this behavior? And is there a spec for the 'lighter' value somewhere? What is the expected behavior? What went wrong? The behavior doesn't seem to make sense. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 71 Channel: n/a OS Version: OS X 10.14 Flash Version: Shockwave Flash 32.0 r0
,
Jan 7
The 'lighter' value is in the attribute definition for the 'operator' attribute: https://drafts.fxtf.org/filter-effects/#attr-valuedef-operator-lighter (also mentioned in the prose further up) My reading is that https://github.com/w3c/svgwg/issues/424 resolved on that an IDL constant should be added for 'lighter' (SVG_FECOMPOSITE_OPERATOR_LIGHTER presumably...), but it doesn't appear that that made it into spec edits... The behavior that Blink implements for this is - I believe - some previously resolved upon behavior[1] (which also may not have made it into spec text...) We also have the same for the 'orient' attribute. I guess we should raise an issue (or two) pointing out the missing edit(s). [1] With the aim of not adding any additional IDL constants.
,
Jan 7
I pinged the GH issue. |
||
►
Sign in to add a comment |
||
Comment 1 by susan.boorgula@chromium.org
, Jan 7