This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Now that the align attribute uses an enum type, AlignSetting, according to WebIDL [1] Section 3.5 Enumerations: "In the ECMAScript binding [of an Enumeration], assignment of an invalid string value to an attribute is ignored, while passing such a value as an operation argument results in an exception being thrown." Consequently, the spec describing align needs to change "If none of the values match, then the user agent must instead throw a SyntaxError exception." to "If none of the values match, then the user agent must ignore the attempt to set the attribute." Note that I've asked the editor of WebIDL if perhaps the "strict" mode in ES should cause an exception rather than ignore the attempt, but have received no response yet. [1] http://dev.w3.org/2006/webapi/WebIDL/
This isn't necessary. It's perfectly OK for an attribute to throw for invalid values. WebIDL doesn't prohibit doing so. It just doesn't do it itself.
(In reply to comment #1) > This isn't necessary. It's perfectly OK for an attribute to throw for > invalid values. WebIDL doesn't prohibit doing so. It just doesn't do it > itself. If the implementation of the getter throws for an invalid value which says it is ignored, then it is inconsistent with WebIDL. You can't have it both ways. In any case, in V8 bindings at least, the binding wrapper checks for invalid values and does an early return on an unknown value prior to invoking the native getter code, so it never sees the call.
(In reply to comment #2) > (In reply to comment #1) > > This isn't necessary. It's perfectly OK for an attribute to throw for > > invalid values. WebIDL doesn't prohibit doing so. It just doesn't do it > > itself. > > If the implementation of the getter throws for an invalid value which says > it is ignored, then it is inconsistent with WebIDL. You can't have it both > ways. > > In any case, in V8 bindings at least, the binding wrapper checks for invalid > values and does an early return on an unknown value prior to invoking the > native getter code, so it never sees the call. To elaborate this a little more, and show why invalid values must be ignored to conform with WebIDL semantics, take a look at the following text from WebIDL Section 4.5.7 [1]: [1] http://dev.w3.org/2006/webapi/WebIDL/#es-attributes <quote> The attribute setter is undefined if the attribute is declared readonly and has neither a [PutForwards] nor a [Replaceable] extended attribute declared on it. Otherwise, it is a Function object whose behavior when invoked is as follows: ... 4. Let idlValue be an IDL value determined as follows: (a) If the type of the attribute is an enumeration, then: 1. Let S be the result of calling ToString(V). 2. If S is not one of the enumeration’s values, then return undefined. 3. The value of idlValue is the enumeration value equal to S. (b) Otherwise, the type of the attribute is not an enumeration. The value of idlValue is the result of converting V to an IDL value. 5. If the attribute is a regular attribute, then perform the actions listed in the description of the attribute that occur when setting, with O as the object and idlValue as the value. ... </quote> As seen here in 4.(a).2., if S is not one of the enum's values, then early return. Consequently, step 5, "perform the actions listed in the description of the attribute that occur when setting" will not be performed, so these actions don't have an opportunity to raise an exception. The present specification in WebVTT about raising an exception are part of the "actions listed in the description of the attribute..." that are ignored.
Ah, I see. So WebIDL just returns for invalid values. That means the current text "If none of the values match, then the user agent must instead throw a SyntaxError exception." is dead code and should be removed completely.
(In reply to comment #4) > Ah, I see. So WebIDL just returns for invalid values. That means the current > text > > "If none of the values match, then the user agent must instead throw a > SyntaxError exception." > > is dead code and should be removed completely. Yes. Removing that text works as well.
Fixed in https://github.com/w3c/webvtt/pull/28 Thanks Glenn!