KEMBAR78
Should setting an enum IDL to an invalid value throw an error? · Issue #547 · w3c/svgwg · GitHub
Skip to content

Should setting an enum IDL to an invalid value throw an error? #547

@AmeliaBR

Description

@AmeliaBR

SVG DOM has many IDL properties represented as short-integer enumerations with matching sets of constants. All the enumeration constant sets define a XXX_UNKNOWN = 0 value.

The general rule for setting an invalid value via the DOM (from the old SVGDOM appendix) is:

If a script sets a DOM attribute to an invalid value (e.g., a negative number for an attribute that requires a non-negative number or an out-of-range value for an enumeration), unless this specification indicates otherwise, no exception shall be raised on setting, but the given document fragment shall become technically in error as described in Error processing.

The detailed setter algorithm for SVGAnimatedEnumeration, in SVG 2, also says:

If value is 0 or is not the numeric type value for any value of the reflected attribute, then set the reflected attribute to the empty string.

However, to confuse matters further, the setting algorithm for SVGPreserveAspectRatio (which encompasses two separate constants, so doesn't use SVGAnimatedEnumeration), says that setting to an invalid value or UNKNOWN should fail silently without changing anything.

Actual results, based on this test case: https://codepen.io/AmeliaBR/pen/0d981477f3832275f7313cbb1caacd9d/
(you'll need to check the real console, the codepen console doesn't show errors)

Blink (Chrome 69), WebKit (Safari 11), and Gecko (Firefox 63) all currently throw errors when you set an enum (SVGAnimatedEnumeration or SVGPreserveAspectRatio) to a value not in the enum OR to 0.

Edge (EdgeHTML 17) silently ignores the SVGAnimatedEnumeration set, but errors out for SVGPreserveAspectRatio (the opposite of the spec).

Edge also silently ignores setting a length attribute to an invalid negative value, while the other browsers all pass it through to the attribute (which is what causes the pattern to disappear, since it's now in error for rendering).

So…

Should we match the majority behavior here?

Relevant context: in #393, we agreed to add new enum values for new attribute values, so being able to catch an error could be a useful way of detecting support. But then, so could reading back the value to see if it was set correctly.

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions