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

Status: RESOLVED DUPLICATE of bug 814014

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

Description

[Andy Earnshaw]

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.

[1]: http://dom.spec.whatwg.org/#dom-domtokenlist-add

Comment 1

[Julien Wajsberg [:julienw]]

Can you please test this on a current nightly ? I think bug 814014 fixed this :-)

Comment 2

[Andy Earnshaw]

My bad.  My Nightly was a little out of date, you're right it's fixed.

Sorry everyone!

Comment 3

[:Ms2ger (he/him; ⌚ UTC+1/+2)]

Perfectly valid, but fixed by another bug --> DUPLICATE.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.  :(

Comment 5

[Andy Earnshaw]

(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.

Comment 6

[Arkadiusz Michalski (Spirit)]

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 (http://dev.w3.org/2006/webapi/WebIDL/#dfn-variadic):

"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."

Comment 7

[Julien Wajsberg [:julienw]]

spiritRKS1910> and this is exactly what the patch in bug 814014 does :)