You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Should setting an enum IDL to an invalid value throw an error? #547
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.
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.
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.
Relevant context. But WebIDL enumerations are somewhat different from SVG's legacy enumerations, which are actually short values in the IDL definitions.
The SVG Working Group just discussed Should setting an enum IDL to an invalid value throw an error?, and agreed to the following:
RESOLUTION: Setting a enum-like DOM property to a value that doesn't represent a valid attribute value should throw a TypeError
The full IRC log of that discussion
<AmeliaBR> Topic: Should setting an enum IDL to an invalid value throw an error?
<AmeliaBR> github: https://github.com//issues/547
<AmeliaBR> Amelia (describes issue)
<AmeliaBR> Chris: Blink, WebKit, Gecko throw errors: but what happens to the value?
<AmeliaBR> Amelia: It doesn't change.
<AmeliaBR> Chris: Well, that seems sensible.
<AmeliaBR> Amelia: I find it a bit confusing, as an author, to have an UNKNOWN constant that you can't use. But that's my only complaint.
<AmeliaBR> Chris: And we have three matching browsers.
<AmeliaBR> Amelia: And as Brian notes, it's consistent with behavior of WebIDL enum data type.
<AmeliaBR> Chris: So what needs to happen?
<AmeliaBR> Amelia: Need to find all relevant sections of the spec to update. I found three different bits of text.
<AmeliaBR> ... I can do that, eventually.
<AmeliaBR> RESOLUTION: Setting a enum-like DOM property to a value that doesn't represent a valid attribute value should throw a TypeError
Activity
birtles commentedon Sep 20, 2018
In WebIDL they throw: https://heycam.github.io/webidl/#es-enumeration
More updating of SVGDOM appendix
AmeliaBR commentedon Sep 20, 2018
Relevant context. But WebIDL enumerations are somewhat different from SVG's legacy enumerations, which are actually
shortvalues in the IDL definitions.No normative appendices! (#548)
css-meeting-bot commentedon Sep 24, 2018
The SVG Working Group just discussed
Should setting an enum IDL to an invalid value throw an error?, and agreed to the following:RESOLUTION: Setting a enum-like DOM property to a value that doesn't represent a valid attribute value should throw a TypeErrorThe full IRC log of that discussion
<AmeliaBR> Topic: Should setting an enum IDL to an invalid value throw an error?<AmeliaBR> github: https://github.com//issues/547
<AmeliaBR> Amelia (describes issue)
<AmeliaBR> Chris: Blink, WebKit, Gecko throw errors: but what happens to the value?
<AmeliaBR> Amelia: It doesn't change.
<AmeliaBR> Chris: Well, that seems sensible.
<AmeliaBR> Amelia: I find it a bit confusing, as an author, to have an UNKNOWN constant that you can't use. But that's my only complaint.
<AmeliaBR> Chris: And we have three matching browsers.
<AmeliaBR> Amelia: And as Brian notes, it's consistent with behavior of WebIDL enum data type.
<AmeliaBR> Chris: So what needs to happen?
<AmeliaBR> Amelia: Need to find all relevant sections of the spec to update. I found three different bits of text.
<AmeliaBR> ... I can do that, eventually.
<AmeliaBR> RESOLUTION: Setting a enum-like DOM property to a value that doesn't represent a valid attribute value should throw a TypeError
Tidying up, post-"No normative appendices" (#550)
Enum-like DOM properties throw TypeErrors on setting to unknown values
Enum-like DOM properties throw TypeErrors on setting to unknown values