Theming
There are a few steps involved in this:
-
Define the first round of components that will be used by Collabra and eLife. -
Define a set of global variables that will affect the look and feel of the whole app. -
Define what the vanilla theme is and what design principles will govern it. -
Figure out what the appropriate technology to theme components is. Current candidates are react-css-themr
andstyled-components
. -
Adjust the current theme to work with whatever library we decide on. -
Refactor react components to work with the theme. -
Create two demo themes (Coko and eLife) that build on top of vanilla.
The technical use cases that need to be covered are the following (listed here in increasing levels of granular control): 1. Changing global variables should change all components that anticipate them. 2. You should be able to change the value of a global variable for a specific scope / context. 3. You should be able to add values to a theme that affect a specific component, as long as the component anticipates the theme. (eg. you could set that all `Button`s have `border-radius: 5px`). 4. Parent components should be able to affect the properties of specific types of children components. (eg. all `input`s within a container should have `background: orange`).
To put things into perspective, the theming side of the following user stories should be covered by the list above:
A journal could take an end-to-end solution defined by us that is based on a typical workflow and use it with no customisation (turn key style option)
Technical implications: None. They will just use the vanilla theme.
A journal could take set controls created by Coko and/or eLife and use them to match or create their own workflow
Technical implications: They could lightly or heavily edit the variables to adjust the look and feel of the application to exactly match their organisation's signature branding. (points 1 and 2 above)
A journal could take set controls created by Coko and eLife and use them to match or create their own workflow and create new bespoke controls of their own (these could also be contributed back to the project if desired)
Technical implications: Same as the previous story, but they could add custom CSS in their theme that targets these new controls. (point 3 above)
An individual or organisation may want to take a page control for use outside of xPub.
Technical implications: As long as this control is used within the pubsweet universe, it will be using the same theming mechanism. This means that the same control with the same theme (within pubsweet), will look the same in two different pubsweet apps (eg. a version of XPub and Editoria)