WDYT, Anne, Domenic?

That only works for enumerated attributes. sandbox="" is an unordered set of unique space-separated tokens.

Ok. I admit, I didn't actually read the definition, but it sounded right. :)

You're right that we'd need a new concept, but conceptually it'd be similar. That is, it seems reasonable to just drop unknown values on the floor during parsing, such that the following would hold:

```
var i = document.createElement('iframe');
i.sandbox = "allow-scripts lldshf";
i.sandbox.value; // "allow-scripts"
```

Well, the sandbox property also returns a DOMSettableTokenList so it's not really a string. And DOMSettableTokenList cannot enforce validity of strings at the moment. So it would require quite a bit more changes I think.

If modifying the attribute's behavior is more work than it's worth, I'm open to any other options. Put an inspectable enum of allowed values somewhere, done. :)

I think this would be a reasonable change to DOMSettableTokenList/DOMTokenList, to only reflect to the tokens that the browser recognizes. It would require some spec and implementation work to happen though, including a willingness to break back-compat.

(In reply to Domenic Denicola from comment #6)
> I think this would be a reasonable change to
> DOMSettableTokenList/DOMTokenList, to only reflect to the tokens that the
> browser recognizes. It would require some spec and implementation work to
> happen though, including a willingness to break back-compat.

Looking at IDL files, backwards compatability doesn't seem to be a big risk: there are only three DOMSettableTokenList attributes implemented in Chrome, for example.

Here is a potential plan for the required spec changes:

Modifications to DOM:

- Add an associated optional token validation algorithm to DOMTokenList.
- Modify DOMTokenList.prototype.{add,remove,toggle,contains} to either throw or ignore their input if it the token validation algorithm is present and running it fails on a given token. Be sure to define e.g. `i.sandbox.add("valid", "invalid", "valid2")` in a well-defined way. I can see pro- and con- arguments for either behavior.
- Modify DOMSettableTokenList.prototype.value's setter to run the token validation algorithm if present, before setting tokens to the result.

Modifications to HTML:

- Add such a token validation algorithm to HTMLIFrameElement.prototype.seamless, validating that the value is in the given set.
- If possible, find other specs that could benefit from this and add algorithms to them at the same time.

Anne, WDYT?

Sounds reasonable. And useful.

Throwing as a way to feature-detect seems more annoying than e.g. a return value. It seems to me that we don't necessarily want the API to reject invalid values, we just want to enable feature-detection. You might still want to add values that the implementation doesn't support if that makes the logic simpler. It also seems somewhat risky Web-compat-wise to start throwing.

To that end, I think the minimal change is to make DOMTokenList#add have a boolean return value where, if there is token validation defined and all values added are supported, it returns true; otherwise returns false.

var i = document.createElement('iframe');
var supported = i.sandbox.add("lldshf");

Alternatively introduce DOMTokenList#supports()

It still seems valuable to me to have the built-in ways of manipulating a DOMTokenList try to preserve no-invalid-tokens. That is, having add and toggle ignore invalid tokens seems like a good change regardless.

Why?

It would be more consistent with "limited to known values", an existing pattern, whereas you are proposing a new pattern.

OK. Consistency with that suggests not throwing. Let's try it.

I like the solution outlined and it seems like it would be useful for https://github.com/w3c/preload/issues/7 as well, when used on `relList`.

Having a boolean return value also has the added benefit of having legacy UAs fall into the "false" bucket for most cases, since their return value for `add()` would be `undefined`.

The solution that's most consistent with "limited to known values" would be to make `add` return true or false depending on whether the token(s) are supported, but add all passed tokens to the content attribute regardless of whether they're supported. I suspect this is also likely the most web-compatible change.

https://github.com/whatwg/dom/pull/103 fixes this issue for the DOM spec, but the HTML spec needs to use the new hook for <iframe sandbox> (this bug) and <link rel> (bug 28796).

This is now fixed: "The supported tokens for sandbox are the allowed values defined for the sandbox attribute that are supported by the user agent."