- From: Jonas via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jul 2016 23:40:21 +0000
- To: public-css-archive@w3.org
> 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