Why are we using Promises here?

[tabatkins]

I'm not certain why Promises are involved here. I understand that these are writing to what is likely an async storage, but that doesn't necessarily have to mean that the author-facing API is async, especially if it's solely used to track the overrides themselves.

That is, setting navigator.preference.colorScheme = "dark"; can be done synchronously; the preference object immediately reflects the "dark" value. But it will affect the actual MQ asynchronously, and authors can listen for that change with an appropriate async API.

This has several benefits:

1. It avoids race conditions with several things overriding the same preference. Each thing will be able to see the preceding override already.
2. It lets us give an immediate error if the value is set incorrectly, rather than requiring the author to handle a promise rejection.
3. It lets us cut out the entire method-based interaction mode, letting us just use attributes (as in Being Map-ish seems a little overkill #4).

If we want to allow authors to see the "real" value of the MQ, we could add an async method to this API. We could probably just bake it into the getSupported() method, adding a currentValue attribute, since that method is already async.

[lukewarlow]

Thanks for the feedback! I've hopefully addressed the issues you've raised and have opened #8 to discuss the iframe behaviour in more detail.