I have been reading into https://drafts.csswg.org/css-scoping/ and into <style scoped>.

I am looking for client side namespace/module support for CSS.

CSS Files can be loaded in the head, in the body (defacto) and at the bottom of the body (deferred). In future multiple CSS files may get loaded by one request through HTTP2.

I think preprocessing is just an intermediate step and I'd love to see some support by clients themselves.

Correct me if I am wrong but csswg-css-scoping seems to be mostly about ShadowDOMs and scoped seems to be mostly about inline <style>-Tags. The issue with inline tags is that while @import can be used it will fire off another request. If you bundle requests in the head or at the very bottom of an HTML document the browser may be able to fetch all of these at once through HTTP2, thus saving request-operations.

While I do support ShadowDOMs there should also be ways to have namepaces/modules for DOM parts of your page (modules you could say) especially in the wake of ReactJS and Elm.

Take it with a huge grain of salt but this is what I came up with:

In some CSS file that is being loaded where you desire (eager loaded in the head, late loaded at end of the body, lazy loaded near to some DOM module) you should be able to do this:

@namespace('alphanumerical-dash-underscore-dot-namespace') {
    /* your regular CSS declarations here */
    h1 {
        font-weight: bold;
    }
}

Then where-ever you consider it to be right you should be able to say:

<style namespace="alphanumerical-dash-underscore-dot-namespace">
    <h1>This would be bold</h1>
</style>

There should also be an optional way to enforce that a namespace can only come from one CSS file (or style block):

@namespace('alphanumerical-dash-underscore-dot-namespace', final) {
   /* your regular CSS declarations here */
    h1 {
        font-weight: bold;
    }
}

This would mean that any declaration that comes along later would not take effect at all but instead browser vendors should be advised to throw an error similar to JS throwing errors.

Thus instead of going from ShadowDOM as an day to day application (and I like Shadow-DOM!) why not go from the common cases and issues people have every day. E.g. it would help the web - drive forward HTML5 vs non-accessible vendor specific apps. It could also be very well combined with browser side includes that the Google/Chrome team was working on (not a fan of Chrome but a fan of that idea).