Re: [dom] Change DOMTokenList's add() return value. (#114)

[Per IRC](http://krijnhoetmer.nl/irc-logs/whatwg/20151125#l-298) @zcorpan and I have a tentative new plan.

- Remove validation from .add() and give up on the idea that we're trying to sync the token list to actually supported values (and thus help spec authors [keep the list of supported keywords and the actual support in sync](https://github.com/whatwg/dom/pull/103#issuecomment-153644790)). Hope test coverage carries the day here.
- Remove .add()'s return value
- Add .supports(token) with a boolean return value
  - We think we can get away with the boolean return value instead of a tri-state enum since .supports() is a new method.
- Put to bed any worries about whether we'll in the future upgrade a DOMTokenList to have supported values by, once and for all, deciding on which DOMTokenLists receive this upgrade, and which don't. So that means if we're worried about `<a rel>`, we need to figure out what the supported `<a rel>` tokens are right now, and not let vague worries about it shape API design.
- .supports() means "has an impact on browser processing," not "is specified". So e.g. `a.relList.supports("tag")` is false, despite "tag" being a specified rel. Whereas `a.relList.supports("noopener")` will be true, for UAs that implement it.
- Open question: what to do about DOMTokenLists that don't have a validation algorithm or a set of supported values? Like classList?
  - (A) split into two classes, e.g. DOMTokenList and DOMSupportedTokenList, with only the latter having .supports(). Use each appropriately.
  - (B) have .supports() always return true. "A classList supports all classes."
  - (C) have .supports() always return false. "specific classes do not have impact on browser processing."

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/pull/114#issuecomment-159623676