W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2016

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

From: Jonas via GitHub <sysbot+gh@w3.org>
Date: Sun, 10 Jul 2016 12:34:41 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-231586786-1468154079-sysbot+gh@w3.org>
Thanks for considering the issue at hand that is being faced by any 
bigger CSS application, e.g. by thousands of developers day to day.

It is not about the suggested implementation or concrete syntax: I'd 
like to purpose this abstract list of priorities, and discuss their 
contents and priority:

1. **Simplicity**: The feature should be as minimal and simple as 
possible to make browser vendors want to implement it and common end 
users want to use it.
2. **Extensility**: The feature should be extensible in future 
iterations of CSS.
3. **Compatibility**: The feature should not render at all in browsers
 not supporting it. The feature should allow to be used with 
ShadowDOM/webcomponents not just ReactJS/Elm. 
4. **Encapsulation**: The feature should enable: A way to declare a 
block of CSS declarations to be applied after global declarations 
(e.g. with higher specificity) only to certain parts of the DOM by 
specifying an encapsulating style tag or an attribute applied to an 
element. That given element would already be considered part of the 
sub-tree. E.g. both, a section of CSS and a section of the DOM should 
be encapsulated and linked.
5. **Independency**: This linking (see 4.) should happen independend 
of where/how the CSS ressources are being loaded. E.g. requests could 
be bundled via HTTP2 or via combining multiple namespaces in one CSS 
document/ressource or loaded lazily whereever required.
6. **Cascading**: There should be a way to cascade namespaces by 
extending one by another, e.g. the css declarations would sit next to 
each other.
7. **Control**: There should be a way to `final` a namespace. However 
this might become difficult due to the order of loading of CSS 
ressources now being relevant over specificity. 

**Is this a good approach for you guys?** Do you feel anything is 
missing? Do you feel anything does not belong here? Would you see 
other priorities?

### Notes

* As for the syntax: The syntax probably has to be designed around 
constraints coming off 1., 2. and especially 3. E.g. if there is 
common ground, the first thing to do is making sure a suggested syntax
 does not affect current gen browsers rendering. Afterwards it needs 
to be made sure that it works with web components / shadowDOM and is 
extensible in future.

GitHub Notification of comment by ionas
Please view or discuss this issue at 
using your GitHub account
Received on Sunday, 10 July 2016 12:34:48 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:41:00 UTC