Skip to content

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

Closed

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.

Activity

  1. birtles commented on Sep 20, 2018

    @birtles
    Contributor
  2. added a commit that references this issue on Sep 20, 2018
  3. AmeliaBR commented on Sep 20, 2018

    @AmeliaBR
    ContributorAuthor

    In WebIDL they throw

    Relevant context. But WebIDL enumerations are somewhat different from SVG's legacy enumerations, which are actually short values in the IDL definitions.

  4. added a commit that references this issue on Sep 23, 2018
  5. css-meeting-bot commented on Sep 24, 2018

    @css-meeting-bot
    Member

    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
  6. self-assigned this
    on Sep 27, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions