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

> Why not Tab's & idea, which also matched preprocessor syntax more 
closely?

- **Where can I read about this idea?**
- Having support for how pre-processors do it is not nearly 
sufficient. Pre-processors can only do so much, namely whatever can be
 trans-piled to CSS. There should be exclusive namespaces that don't 
clash with IDs and classes. Else I can't see why you can assume that 
specificy will stop working as the sole instrument of determining 
which declaration block of properties gets applied to which selector.

Out of the proposed interface above, for example:

#### this combination would be default browser styles + whatever is 
declared within the namespace

```html
<section namespace="foo-namespace">
    <p>Hello World</p>
</section>
```

```css
@namespace('foo-namespace') {
    section {
        padding: 1rem;
    }
    section p {
        line-height: 200%;
    }
}
```

#### whereas this would explicitly inherit rules (and then go by 
selector specificity) from a base namespace

```html
<html namespace="base-namespace">
...
<section namespace="foo-namespace">
    <p>Hello World</p>
</section>
...
</html>
```

```css
@namespace('base-namespace') {
    html {
        font-family: 'Liberation Sans'
    }
}
@namespace('foo-namespace' inherits: ('base-namespace')) {
    section {
        padding: 1rem;
    }
    section p {
        line-height: 200%;
    }
}
```

#### This would inherit one after another

```html
<html namespace="base-namespace">
...
<header namespace="header-namespace">
    <form namespace="login-component-namespace">
             <label>Username</label>
    </form
</header>
...
</html>
```

```css
@namespace('login-component-namespace' inherits: ('base-namespace', 
'header-namespace')) {
    /* ... */
}
```
Here the question would be if inheritance works 'recursive' up the 
tree or not, e.g. if it would be sufficient to inherit 
`'header-namespace'` if that one again inherited `'base-namespace'`.

What I am trying to get to is a way to declare certain blocks to not 
take leakage from the parent DOM and not leak to the DOM.

Because of that there is also the idea to *final* certain 
declarations. This would make components, once loaded, save from other
 css declarations being loaded afterwards to not mess with them (be 
discarded).

#### Example

```css
@namespace('login-component-namespace' inherits: ('base-namespace', 
'header-namespace') final) {
    /* some declarations here that will be applied */
}
@namespace('login-component-namespace' inherits: ('base-namespace', 
'header-namespace')) {
    /* these won't be applied no matter what */
}
```

A DOM (sub)tree should be able to take multiple namespaces. When doing
 so things don't need to be nested through the DOM and CSS specificity
 is merged among the 2+ namespaces. Like

#### Example

```html
<html>
...
<header namespace="header-namespace, 
flat-corporate-identity-namespace">
    <form namespace="login-component-namespace, 
flat-corporate-identity-namespace">
             <label>Username</label>
    </form
</header>
...
</html>
```


### Open issues

- Is automatically merging namespaces that an inherited parent 
inherited a good idea?
- Is finalizing a good idea, especially because of load order of CSS 
affecting the output?
- What about the interaction between Javascript and finalized 
namespaces?
- What attribute name and feature name could be better, instead of 
namespace. Module? Scope? Block?
- What about Javascript support and reading out of these proposed 
namespace attributes?

# This seems to solve:

1. Developers can disable leaking of outside to inside: Declare a 
namespace, don't inherit from parent namespace.
2. Developers don't accidentially leak declarations from the inside to
 the outside: While css selector specificy is intact within a 
namespace, its declarations only affect elements where the namespace 
is declared to (including its declaring parent, e.g. *section* in 
`<section namespace="foo-namespace"`>.
3. There is both models supported: logical inheritance and logical 
aspects. E.g. you can give certain dom (sub) trees certain aspects or 
you use inheritance.

I am happy to discuss things like this on Freenode IRC (#css or 
whatever your prefer) and/or a wiki or in some other forms. I am also 
happy to learn about pitfalls. Please let me know how to get in touch.

#### I think there is a real need to be able to have css 
modules/scopes etc, that don't take leakage nor leak themselves but 
*can be made to* if desired.

A feature *similar* to this HERE would help every-day developers and 
it would help the web platform to mature even more and become more 
strict (if desired) and less error-prone, e.g. more reliable, better 
to maintain and extend.

-- 
GitHub Notification of comment by ionas
Please view or discuss this issue at 
https://github.com/w3c/csswg-drafts/issues/270#issuecomment-234116718 
using your GitHub account

Received on Wednesday, 20 July 2016 23:40:27 UTC