Closed Bug 911564 Opened 11 years ago Closed 11 years ago

DOMTokenList methods add/remove should not throw when arguments list is empty


(Core :: DOM: Core & HTML, defect)

Not set





(Reporter: andyearnshaw, Unassigned)


Currently, e.g. element.classList.add() and element.classList.remove() throw an error if the argument list is empty.  This behaviour is not specified in the DOM standard.

The WHATWG DOM Living Standard spec outlines the process of .add() as follows[1]:

  1. If one of tokens is the empty string, throw a "SyntaxError" exception.
  2. If one of tokens contains any ASCII whitespace, then throw an "InvalidCharacterError" exception.
  3. For each token in tokens, in given order, that is not in tokens, append token to tokens.
  4. Run the update steps.

There is no step that says if no tokens are specified, throw a "TypeError" exception.  There is a parity issue with at least one other engine (WebKit), which does not throw an error.

The issue I ran into with this is applying classes based on a filtered array, for example:

    classes = ['is-prop1', 'is-prop2'/*, ...*/].filter(function (cls) {
                  return someObj[cls.slice(3)] === true;

    someElement.classList.add.apply(someElement.classList, classes);

As a workaround, I implemented a check on the length of the resulting array first.

Can you please test this on a current nightly ? I think bug 814014 fixed this :-)
My bad.  My Nightly was a little out of date, you're right it's fixed.

Sorry everyone!
Closed: 11 years ago
Resolution: --- → INVALID
Perfectly valid, but fixed by another bug --> DUPLICATE.
Note that this is the problem with a "Living Standard" approach: an earlier version of the spec required at least one argument here, but that got changed... unfortunately changing the spec doesn't magically update implementations, or even let implementors know they need to change anything.  :(
(In reply to Boris Zbarsky [:bz] from comment #4)
Yeah it's a bit of a problem.  Hopefully web developers will be vigilant enough to keep an eye on the spec on post (useful) bug reports in the future.
I think this situation does not have to be described in the algorithm of the DOM. It stems directly from the Web IDL for the operations (

"The final argument of a variadic operation is also considered to be an optional argument. Declaring an argument to be optional indicates that the argument value can be omitted when the operation is invoked. The final argument in an operation MUST NOT explicitly be declared to be optional if the operation is variadic."
spiritRKS1910> and this is exactly what the patch in bug 814014 does :)
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.