Supporting progressively enhancing components that may or may not use shadow trees

We (Anaplan) are building some pure JS components that may be used in React apps, may be used in non-React apps. One of the approaches we want to take involves using Shadow DOM where the browser supports it, to discourage misuse of the internal structure of the component (a problem we've had in the past). At the same time, we need compatibility with Internet Explorer 11 and current versions of Edge, which don't support Shadow DOM. For the components to remain lightweight, we don't want to enforce the use of a polyfill, so we just need to degrade to using standard trees in MS browsers and provide a standardised API method for managing the content.

One of the great things I have noticed about CSS Blocks is the parallels with web component styling. `:scope` is similar to `:host`, for example, and you don't need to use BEM inside a component's CSS file because the styles are already scoped to the component root. Being able to simply import the CSS into the JS file is a big desire for us, and we're hoping the CSS Blocks can help here. Ideally, what we want is something that compiles block CSS to something where the selectors are determined at runtime. For example, if the runtime code detects that Shadow DOM is supported, `:scope` is transformed into `:host` and `.content` remains `.content`, but if Shadow DOM is not supported, `:scope` becomes `.my-block` and `.content` becomes `.my-block__content`. An object URL is created for the CSS where it is referenced from a `` element in the shadow tree, or an `@import` statement in a global `` element in IE11/Edge. The JS `import` would provide the class names at run time (we don't really care about transforming the template, which is just a HTML string parsed into a `DocumentFragment`).

Having read through the documentation for CSS Blocks, this doesn't seem like a trivial thing to do at all. Before I start getting my hands dirty, is it possible to do this?

The issue names no files, tests, or implementation entry points. Start by reviewing the CSS Blocks documentation and the requirements described here for runtime selector transformation and Shadow DOM fallback. Done would require establishing whether this behavior is feasible and defining its implementation scope.

Written by the indexing model from the issue text.