- From: Jonas via GitHub <sysbot+gh@w3.org>
- Date: Sun, 10 Jul 2016 12:34:41 +0000
- To: public-css-archive@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 https://github.com/w3c/csswg-drafts/issues/270#issuecomment-231586786 using your GitHub account
Received on Sunday, 10 July 2016 12:34:48 UTC