Right now, when a user sets the style on an element via element.style.someProperty = 'some-value', the browser rewrites that element’s style attribute by a method that only serializes out the properties that the browser recognizes. (I think I might have discovered this in another thread on here, but I can’t remember where.)
In the absence of a more robust CSS access model in the DOM (which still looks to be a far ways off, even with the Houdini WG working on it), having a place to store experimental CSS properties to be used by an element is very useful, eg. the way the Pointer Events Polyfill is currently considering polyfilling the behavior of the touch-action property.
I propose specifying a new model of the style attribute (or its prototype / interface, especially if it would raise the bar for the return value of getComputedStyle), making it effectively work like the dataset property when it comes to portions that are syntactically valid but specify unrecognized property names or values (accepting any string and returning any unrecognized values as the unrecognized string, making them available as camel-cased properties on style, then re-serializing them out when setting the string value of the attribute).
I’m aware there might be some limitations to how extensible this property may be (ie. it’s not possible to let element.style.border = 'wing-a-ding cheese whiz' change the type of element.style.border from 'object' to 'string'), but I think, for the sake of polyfillability, it’s worth specifying around those limitations, rather than just throwing up our hands and keeping it un-extensible.