[csswg-drafts] [css-scoping] Support for CSS namespaces

ionas has just created a new issue for 
https://github.com/w3c/csswg-drafts:

== [css-scoping] Support for CSS namespaces ==
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-cssscoping 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 in the body, lazy loaded near to some DOM 
module) you should be able to do this:
```css
@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
```html
<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):
```css
@namespace('alphanumerical-dash-underscore-dot-namespace', exclusive) 
{
   /* 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. 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).


Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/270 using your GitHub 
account

Received on Tuesday, 5 July 2016 12:52:38 UTC