Make preferences framework's Sass files more modular, configurable and reusable by 3rd parties
Description
Currently the preferences framework uses Sass to generate CSS files. However, much of the features are not exposed in a way that can be easily manipulated by a 3rd party. In particular Enactors.styl should be completely modular similar to how contrast themes are broken out into Themes.styl. That way a 3rd party integrator that only wanted some of the enactor styling, or wanted to use a different class name for contrast themes could do so without having to fork the Enactors.styl file.
Environment
None
Activity
Justin ObaraFebruary 3, 2022 at 3:38 PM
With the work on and the Sass files were split into modular parts based on the preference they are enacting. They are also recommending into an Enactors file to simplify usage and support backwards compatibility.
Justin ObaraJune 8, 2017 at 2:11 PM
Consider also making all the stylus files as specific as possible, to make it easier to reuse. These can then be compiled into a single css file at build time.
Justin ObaraJune 8, 2017 at 2:07 PM
We should also consider making the stylus directory a sibling to css instead of nested under it, to keep things cleaner and better separated.
Currently the preferences framework uses Sass to generate CSS files. However, much of the features are not exposed in a way that can be easily manipulated by a 3rd party. In particular Enactors.styl should be completely modular similar to how contrast themes are broken out into Themes.styl. That way a 3rd party integrator that only wanted some of the enactor styling, or wanted to use a different class name for contrast themes could do so without having to fork the Enactors.styl file.