Is this supposed to apply to CSS properties, or selectors, or both? (or value types, even, like the new 'q' unit?)

We'll also need to figure out what happens if a token for a css feature is applied via script after the document has loaded -- we'll probably have to do a full style recalc, if we can (unless we decide to just ignore script-added tokens)

We need to flush out the scope, desired behaviour and design. I was anticipating a design doc would be the best place to iterate on that, so I left the details sparse here.

With respect to the points raised:
- I expect any CSS feature exposed to web developers should be controllable via origin trial (i.e. "all of the above" to properties, selectors, value types, .etc). That assumes origin trial integration is technically feasible to implement, and there's predictable fallback behaviour for web developers.
- I'd say script-added tokens fall under the larger question of order/timing between reading/validating tokens and parsing/application of CSS. That is, we need to design predictable/explainable behaviour for web developers. If feasible, I'd like to see script-added tokens for CSS features handled as they are now. Currently, the web developer is responsible for adding the tokens as early as possible, before attempting to use the feature under trial. For CSS, I think we should avoid doing things like triggering full style recalc. 

Design doc: https://docs.google.com/document/d/1Lc3U2WV38GZ3ShTAm3-p6fbZeGJGkxL-KZfWIQ-p8GU/edit#