design issueshttps://gitlab.coko.foundation/pubsweet/design/-/issues2018-08-03T09:44:46Zhttps://gitlab.coko.foundation/pubsweet/design/-/issues/33[RFC] migrating from this repo to pusbweet?2018-08-03T09:44:46ZJen Spencer[RFC] migrating from this repo to pusbweet?At the Pubsweet Meet, it seemed like a common theme that development was happening faster than design, which obviously isn't ideal for anyone! One of the many things that seems to be causing this is that designers and developers are ofte...At the Pubsweet Meet, it seemed like a common theme that development was happening faster than design, which obviously isn't ideal for anyone! One of the many things that seems to be causing this is that designers and developers are often having conversations very separately from each other.
Some developers weren't even aware that this repo existed. So some of the good discussion that has happened in issues on here hasn't necessarily translated into a reality for our applications. For example, we've each dealt with grid layout, hover states, etc, in whatever way feels appropriate for our apps.
At the Meet, I proposed that we raise issues about the creation of new components directly on the `pubsweet` repo, so that all 4 xpubs have greater visibility over what other xpubs are creating. But I would hate to see this turn into devs dominating the design decisions. So it's essential that devs don't end up discussing things on pubsweet's issues without designers weighing in. My hope is that pubsweet becomes a single source of everyone's contributions.
But at the Pubsweet Meet, it was also brought up that it might be daunting for designers, especially for new starters, to jump into the huge melee of issues on the pubsweet repo? Hopefully this can be solved via labels on the pubsweet issues, so that the huge number of issues can be filtered & only the relevant issues are shown.
Perhaps there are also things that designers would prefer to discuss with each other _first_, before being assaulted by developer's questions about implementation? So I would love to know what you all would think of moving the readmes in this repo into pubsweet's wiki pages & raising design repo issues directly in pubsweet instead?
Is there anything I'm misunderstanding about how this repo is being used, or why it's preferable to have these in separate places? Because I'm concerned that separating these 2 groups' discussions is negatively impacting designers' concerns & decisions actually making it into code.https://gitlab.coko.foundation/pubsweet/design/-/issues/32layout (grid?) - where should responsibility lie for the space between compon...2018-07-27T17:23:42ZJen Spencerlayout (grid?) - where should responsibility lie for the space between components on a page?Right now, the space between components on a page seems to be achieved by having `margin-bottom` on each of the individual atoms. (Is this correct?) Therefore each individual component bears the responsibility for how much space exists b...Right now, the space between components on a page seems to be achieved by having `margin-bottom` on each of the individual atoms. (Is this correct?) Therefore each individual component bears the responsibility for how much space exists between itself and the component below it on a page.
If a specific page calls for more/less margin than an atomic component has by itself, then the normal `margin-bottom` needs to be overriden. Having layout responsibility being shared across multiple levels of nesting makes it a little harder to reason about what needs overriding.
Also, how would we achieve spacing between the top of a page, or the navbar, and the first component on a page (e.g. a `TextField`)? The responsibility could lie with:
- the `TextField` on this specific page e.g. adding `margin-top` to this `TextField` only
- adding `margin-bottom` to whatever is above it (such as the navbar)
- use flexbox/grid/etc to wrap all components and use `space-around`
No matter which we choose, responsibility for the spacing between the navbar and the TextField lies at the page level, but spacing between the TextField and the component below it lies with the TextField itself. Would it not be easier to reason about, if the spacing between components lived on the same level?
What do you guys think of leaving margins off each individual component & therefore leaving the responsibility for spacing between each component to the page level (& molecule level)?https://gitlab.coko.foundation/pubsweet/design/-/issues/31Specify multiple gridUnits?2018-06-25T23:26:47ZJen SpencerSpecify multiple gridUnits?As I understand it, pubsweet is intending to change the `gridUnit` variable to `6px`? This has already happened in the eLife theme.
We also have [XXS, XS, S, M, L, XL & XXL for "vertical spacing"](https://projects.invisionapp.com/share/...As I understand it, pubsweet is intending to change the `gridUnit` variable to `6px`? This has already happened in the eLife theme.
We also have [XXS, XS, S, M, L, XL & XXL for "vertical spacing"](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926984), which have been added to [our theme's code](https://github.com/elifesciences/elife-xpub/blob/develop/client/elife-theme/src/index.js#L44-L50)
Just feeding info back up, in case others would like this type of sizing, rather than computing `gridUnit * 4` manually in each place in the code.
Personally, I'm unsure about XXS, XS, etc as variable names & would be more inclined to go with something like 1, 2, etc as we do with headings - see [this comment in the eLife issue](https://github.com/elifesciences/elife-xpub/issues/217#issuecomment-398738586) but perhaps this is a popular convention?
Relates #4, #10 & #24 https://gitlab.coko.foundation/pubsweet/design/-/issues/27Text Area2018-07-27T15:53:39Zjulientaqjulien@coko.foundationText AreaHere are the design for the text area based on @Nick's button (#19) and the already live [text input](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#!/TextField)
![textArea](/uploads/856e78d3021e3a8ad5bc8dac975a515f/textArea...Here are the design for the text area based on @Nick's button (#19) and the already live [text input](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#!/TextField)
![textArea](/uploads/856e78d3021e3a8ad5bc8dac975a515f/textArea.png)
- background: white;
- border-radius: $borderRadius;
- border-width: $borderWidth;
- border-color: $colorFurniture;
- border-style: $borderStyle;
- font-family: $fontWriting;
- font-size: $fontSizeBase;
- color: $colorText;
- line-height: $gridUnit;
- padding: $gridUnit / 2;
- hover: border-color: $colorPrimary, border-width 3px
- disabled: opacity 50%
- active: border-color: $colorPrimary, border-width 3px
- focus: border-color: $colorPrimary, opacity: 30%, border-width 3px
`:active` and `:hover` have a border with the primary color.
`:focus` get a lighter primary color for the border, in order to be less disturing while writing.
Did i miss some?
Thanks!https://gitlab.coko.foundation/pubsweet/design/-/issues/25Accessibility design guidelines2019-04-02T14:41:58ZYannis BarlasAccessibility design guidelinesShould we have a short guideline on how design can affect accessibility?Should we have a short guideline on how design can affect accessibility?Alex PricopAlex Pricophttps://gitlab.coko.foundation/pubsweet/design/-/issues/23Workshop ideas2018-03-21T18:12:52ZNick DuffieldWorkshop ideasIdeas board for our next stages in pubsweetIdeas board for our next stages in pubsweethttps://gitlab.coko.foundation/pubsweet/design/-/issues/21Components to be designed2021-05-05T20:39:31ZNick DuffieldComponents to be designed## Notes
* **Colors:** We should display these even though they are not components
* **Fonts:** Looks good. Are these atoms or just styles?
* **Typography:** We have headings and should also do p, label, ul, ol, li and other basic elemen...## Notes
* **Colors:** We should display these even though they are not components
* **Fonts:** Looks good. Are these atoms or just styles?
* **Typography:** We have headings and should also do p, label, ul, ol, li and other basic elements
## Components
| Category | Component | Comment | Non-var properties | Status |
|---|---|---|---|---|
| Atoms | Alignment box | What is this? || Clarification needed |
| Atoms | Attachment | What is this? | | Clarification needed
| Atoms | Avatar | | | To be done |
| Atoms | Badge | | | To be done |
| Atoms | Button | We have primary and secondary. Do the plain states need to be done? | min-width? | Review |
| Atoms | CenteredColumn | What is this? | | Clarification needed |
| Atoms | Checkbox | There is an animation on this. Have the variables been applied? | | Review |
| Atoms | Colorize | What is this? | | Clarification needed |
| Atoms | ErrorText | What is this? | | Clarification needed |
| Atoms | File | Deprecated: should we remove it? | | Clarification needed |
| Atoms | FilePicker | Where is this placed on the UI at the moment? | | Clarification needed |
| Atoms | Flexbox | Is this an atom? | | Clarification needed |
| Atoms | Heading | Do we have the other heading sizes? Some variables are incorrect | | Review |
| Atoms | Icon | | | To be done |
| Atoms | Link | Looks fine. Is this done? || Review |
| Atoms | Menu | Looks fine. Should we name this select menu. I think of menu as the header type patterns. || Review |
| Atoms | Radio | There is an animation on this. Have the variables been applied? || Review |
| Atoms | Section | What is this? || Clarification needed |
| Atoms | Spinner ||| To be done |
| Atoms | StateItem | What is this? || Clarification needed |
| Atoms | Tags | What is the difference between a tag and a keyword? || To be done |
| Atoms | TextField ||| Review |
| Atoms | UploadButton | How is an upload button different from a button? || Clarification needed |
| Atoms | UploadingFile | What is this? || Clarification needed |
| Atoms | ValidatedField ||| Review |
Molecules | AlignmentBoxWithLabel | What is this? || Clarification needed |
Molecules | AlignmentTool | What is this? || Clarification needed |
Molecules | AppBar ||| To be done |
Molecules | Attachments | What is this? || Clarification needed |
Molecules | CheckboxGroup ||| To be done |
Molecules | EditableValue | What is this? || Clarification needed |
Molecules | Files | What is this? || Clarification needed |
Molecules | FileUploadList ||| To be done |
Molecules | PlainButton | Is this a molecule? How is it different too the PlainButton in Buttons? || Clarification needed |
Molecules | RadioGroup | Do we have a vertical one too? || To be done |
Molecules | StateList | Are these breadcrumbs? || To be done |
Molecules | Steps | Where are the atoms for this?|| To be done? |
Molecules | Supplementary | This looks like a molecule made of files? The name doesn't suggest a connection || Clarification needed |
Molecules | Upload | Is this a molecule? How does it differ in use from UploadButton? || Clarification needed |
Molecules | YesOrNo | Isn't this just a RadioGroup? || Clarification needed |https://gitlab.coko.foundation/pubsweet/design/-/issues/19Button component defaults2018-04-18T16:21:30ZYannis BarlasButton component defaultsDuring the Athens meet, we discussed that the following variables should be connected to the Button component.
`borderWidth`
`borderRadius`
`colorPrimary` (if the button is primary)
`colorSecondary`
`colorText` (applied on text ...During the Athens meet, we discussed that the following variables should be connected to the Button component.
`borderWidth`
`borderRadius`
`colorPrimary` (if the button is primary)
`colorSecondary`
`colorText` (applied on text for secondary buttons)
`colorTextReverse` (applied on text for primary buttons)
Is there any more values (beyond variables that would go into this element?)
eg. `min-width` comes to mind
The output of this should be a list of defaults for this element, so that the devs can translate to CSS.
---
#### Outcome
##### Primary button
Reference image
![primary-button_2x](/uploads/c972426bde704cf61d0d87fb20fcc959/primary-button_2x.png)
Default non-variable values
* Non at present
Primary button values
* background: colorPrimary;
* border-radius: borderRadius;
* border-width: borderWidth: 0;
* border-color: none;
* border-style: borderStyle;
* font-family: fontInterface;
* font-size: fontSizeBase;
* color: colorTextReverse;
* line-height: gridUnit;
* padding: gridUnit / 2;
* hover: 30% darker
* active: 30% darker
* disabled: opacity 50%
* press: 50% darker
* focus: colorPrimary, opacity 30%, width 3px
##### Secondary button
Reference image
![secondary-button_2x](/uploads/4bbe0b65d26a0e2005294717509a95a3/secondary-button_2x.png)
Default non-variable values
* Non at present
Secondary button values
* background: colorSecondary;
* border-radius: borderRadius;
* border-width: borderWidth;
* border-color: colorFurniture;
* border-style: borderStyle;
* font-family: fontInterface;
* font-size: fontSizeBase;
* color: colorText;
* line-height: gridUnit;
* padding: gridUnit / 2;
* hover: 30% darker
* active: 30% darker
* disabled: opacity 50%
* press: 50% darker
* focus: colorPrimary, opacity 30%, width 3pxNick DuffieldNick Duffieldhttps://gitlab.coko.foundation/pubsweet/design/-/issues/16[RFC] How to implement a table in a world of atoms and molecules?2018-02-13T17:22:43Zjulientaqjulien@coko.foundation[RFC] How to implement a table in a world of atoms and molecules?By definition, an atom is something that can be reused in another molecule.
Looking at the examples from @jure and Alex P. we see that there can be action inside the table, like removing a line (deleting a user for example), or change t...By definition, an atom is something that can be reused in another molecule.
Looking at the examples from @jure and Alex P. we see that there can be action inside the table, like removing a line (deleting a user for example), or change the status of another one. Therefore, the table will import atom or molecules inside its cells.
![tableBis2](/uploads/d55643dacbdb165791a9dc8a4d4f4d91/tableBis2.png)
![Image_Pasted_at_2018-2-13_14-31](/uploads/856f17dce0cf70344cc36098870b2a41/Image_Pasted_at_2018-2-13_14-31.png)
Tables are made of cells, which can be looked at like the atom of the molecule table. The problem of doing so is that, unlike a `label` for example, a cell will not be usable outside of a table.
Therefore, a cell is not an atom in itself.
More, based on [MDN](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/table), tables can/should have:
- an optional `<caption>` element, *which is the title of the table*;
- zero or more `<colgroup>` elements *that let you describe the columns spanning of your table*
- an optional `<thead>` element *for the heading of each column*;
- zero or more `<tbody>` elements *which define the actual body of the table*;
- one or more `<tr>` elements *to define a row*;
- an optional `<tfoot>` element *for the footer rows of the table*
We can have a different atom for each type of cell. This would mean that we will have either an atom that will have all the styling for all the variants (aligned-right for numbers, background for the header cells), or we will have one atom for each need.
HTML is already well describing tables, using `thead`, `tr`, `td` and `th`. I believe that a well made set of css rules would be easier to use and maintain (even with responsible tables) than having all the options inside components.
More than that, the table are editorialized content, and therefore, will be harder to reuse amongst different applications.
That's why i would declare tables as a molecule that can use atoms inside it cells (like a `button` or a `link`).https://gitlab.coko.foundation/pubsweet/design/-/issues/15Vanilla theme variables2018-02-01T15:33:38Zjulientaqjulien@coko.foundationVanilla theme variablesHere are the chosen variables for a first draft of the variables.
Cf. https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md
## Colors
```css
colorPrimary: #205d86;
colorSecondary: #e7e7e7;
colorFurniture: #cccccc;
co...Here are the chosen variables for a first draft of the variables.
Cf. https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md
## Colors
```css
colorPrimary: #205d86;
colorSecondary: #e7e7e7;
colorFurniture: #cccccc;
colorBorder: #aaaaaa;
colorBackgroundHue: #f1f1f1; /*marginally darker shade of the app background so that it can be used to divide the interface when needed*/
colorSuccess: #005500;
colorError:#B50000;
colorText: #333333;
colorTextReverse: #ffffff;
colorTextPlaceholder: ##595959;
```
## Text variables
```css
fontInterface: "Noto Sans";
fontHeading: "Noto Sans";
fontReading: "Noto Serif";
fontWriting: "Ubuntu mono";
```
// scale is 1.125 with rounded values;
```css
fontSizeBase : 18px;
fontSizeBaseSmall: 16px;
fontSizeHeading1: 36px;
fontSizeHeading2: 32px;
fontSizeHeading3: 29px;
fontSizeHeading4: 26px;
fontSizeHeading5: 23px;
fontSizeHeading6: 20px;
fontLineHeight: 32px;
```
## Spacing
```css
gridUnit: 32px;
```
## Border
```css
borderRadius: 8px;
borderWidth: 1px;
borderStyle: solid;
```
## Shadow (for tooltip)
```css
boxShadow: 0 2px 4px 0 rgba(51,51,51,0.3);
```
## Transition
```css
transitionDuration: 2s;
transitionTimingFunction: ease;
transitionDelay: 500ms;
```https://gitlab.coko.foundation/pubsweet/design/-/issues/13Box sizing2018-03-19T09:51:47ZYannis BarlasBox sizingShould we use `box-sizing: border-box` on the themes by default?Should we use `box-sizing: border-box` on the themes by default?https://gitlab.coko.foundation/pubsweet/design/-/issues/12Animations2018-01-26T00:26:52ZYannis BarlasAnimations`styled-components` [lets us](https://www.styled-components.com/docs/basics#animations) easily store animations in js.
It's worth thinking about creating and exposing some common ones so that they could be reused by different component...`styled-components` [lets us](https://www.styled-components.com/docs/basics#animations) easily store animations in js.
It's worth thinking about creating and exposing some common ones so that they could be reused by different components and applications.https://gitlab.coko.foundation/pubsweet/design/-/issues/11Focused elements2018-06-27T15:19:28ZYannis BarlasFocused elementsWe still need to figure out what happens to elements that are focused (eg. buttons, inputs etc).
Potential solutions are a variation on the current color, or maybe an outline like bootstrap does to its elements.We still need to figure out what happens to elements that are focused (eg. buttons, inputs etc).
Potential solutions are a variation on the current color, or maybe an outline like bootstrap does to its elements.https://gitlab.coko.foundation/pubsweet/design/-/issues/10Padding variable2018-06-20T16:16:16ZYannis BarlasPadding variableShould we add a `padding` variable to the theme, that is separate from the `gridUnit`, but could use potentially use it?Should we add a `padding` variable to the theme, that is separate from the `gridUnit`, but could use potentially use it?https://gitlab.coko.foundation/pubsweet/design/-/issues/9Hover / Interaction colors2018-01-26T00:21:18ZYannis BarlasHover / Interaction colorsIt is very common to use a variation of the color of an element when hovering over it to indicate interaction.
It becomes hard though to be generic.
If we were to define a `primaryColor`, then we'd also need a `primaryColorInteracti...It is very common to use a variation of the color of an element when hovering over it to indicate interaction.
It becomes hard though to be generic.
If we were to define a `primaryColor`, then we'd also need a `primaryColorInteraction`.
We could do the same for a `secondaryColor`, but if one were to introduce another one, then you'd need yet another variable for interaction.
A smarter approach might be to use a function on the components along the lines of [this one](https://css-tricks.com/snippets/javascript/lighten-darken-color/) that would shade the current background color of an element.
An alternative approach would be to have one interactive color for all elements, regardless of their current color.
It goes without saying that any of the above could be overriden in a custom theme, so this is more of a question of what is a more sensible default approach.https://gitlab.coko.foundation/pubsweet/design/-/issues/8Scaling function2018-01-26T10:59:52ZYannis BarlasScaling functionAs discussed in the last meeting, we should build a scaling function for heading fonts.
The purpose for this would be to use the base font size (or another font size) and apply a specific scale on it to get the size of a specific head...As discussed in the last meeting, we should build a scaling function for heading fonts.
The purpose for this would be to use the base font size (or another font size) and apply a specific scale on it to get the size of a specific heading.
```
ratio = '4:5'
fontSizeBase = '12px'
fontSizeH3 = scale('h3', ratio, fontSizeBase)
```https://gitlab.coko.foundation/pubsweet/design/-/issues/4Spacing variables2018-06-20T16:14:57ZYannis BarlasSpacing variablesThe purpose of this issue is to come up with a common list of variables related to spacing for theming in pubsweet applications.
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|-...The purpose of this issue is to come up with a common list of variables related to spacing for theming in pubsweet applications.
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|Divider|`$border-width`, `$color-text-dividers`|
|Base spacing value (12px) || `$base-grid`
|Base spacing value x2 (24px) | | `$base-grid` * 2
|Base spacing value x4 (48px) | | `$base-grid` * 4
|Base spacing value x6 (72px) | | `$base-grid` * 6
|Line height spacing||||To be discussed
@Nick @julientaq https://gitlab.coko.foundation/pubsweet/design/-/issues/3Form variables2018-01-17T07:38:53ZYannis BarlasForm variablesThe purpose of this issue is to come up with a common list of variables for theming form inputs in pubsweet applications.
| Elife component name|Image of Elife component|Collabra component name|Image of Collabra component|Elife suggeste...The purpose of this issue is to come up with a common list of variables for theming form inputs in pubsweet applications.
| Elife component name|Image of Elife component|Collabra component name|Image of Collabra component|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|---|---|---|
|Button primary |[Button primary](https://drive.google.com/open?id=1HR9gkCFs7-0QR3pd7tvWE2H2R28uuQ56)|button|[Button](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#button) |`$border-radius`, `$color-primary`, `$primary-text-color`|`$button-background` ,`$button-borders`, `$button-border-radius`, `$button-border-color`
Button primary small|[Button primary small](https://drive.google.com/open?id=1vA2IEpBAxK6eYJGz1kNhqa81XONcwFlF)| *na* | *na* |`$border-radius`, `$color-primary`, `$primary-text-color` |`$button-background` ,`$button-borders`, `$button-border-radius`, `$button-border-color` | | the only change in the css would be the font-size (as every size should be in *em* for the atoms, so their size will be set by their parent)
Button secondary|[Button secondary](https://drive.google.com/open?id=1BEza2OI-iR1b1U0Y71LAVk3GjQD9ixmD)|Button secondary|[button](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#button)|`$border-radius`, `$border-width`, `$secondary-border-color`| `$button-background` ,`$button-borders`, `$button-border-radius`, `$button-border-color`
Text input|[Text input](https://drive.google.com/open?id=1nfPD9_QGnexMv5H_CnrMGrccHsIJUcGu)|Text field|[text-field](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#textfield)|`$border-radius`, `$border-width`, `$color-text-dividers`| `$border-color`, `$border-width`, `$background`
Text area|[Text area](https://drive.google.com/open?id=1TXdUuasJ50drfvy55XUg1f7WOA4uL0xr)|Text area| Not in the style guide yet|`$border-radius`, `$border-width`, `$color-text-dividers`
Select menu|[Select menu](https://drive.google.com/open?id=1rZc6Jz5ejI79iKNfQ6kOn7aGs4JEWs8i)|Menu|[Menu](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#menu)|`$border-radius`, `$border-width`, `$color-text-dividers`
Check box|[Check box](https://drive.google.com/open?id=1e4XVh1HJNeX8MXfOzAp9kDc7pjWb4RC2)|checkbox|[checkbox](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#checkbox) |`$border-radius`, `$border-width`|`$color-primary`, `$color-text`,|| checkboxes and radio buttons are a little tricky as it's using some specific css for collabra, and i think that elife ones relies on SVG. SVG could be a simple way to change element in the vanilla theme though.
Radio button|[Radio button](https://drive.google.com/open?id=1nDKOmjGgofqshe_sRqBugMj7YBnG1uX6)|radio|[radio](https://ui-staging-zpqsip.gateway.ps.semioticsquares.com/#radio)|`$border-radius`, `$border-width`|`$color-primary`, `$color-text`
https://gitlab.coko.foundation/pubsweet/design/-/issues/2Typography variables2018-01-26T00:02:06ZYannis BarlasTypography variablesThe purpose of this issue is to come up with a common list of typography variables for theming in pubsweet applications.
## Size variables
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|-...The purpose of this issue is to come up with a common list of typography variables for theming in pubsweet applications.
## Size variables
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|**Body**|`$font-size-base-in-px`|`$font-size-base`||Base measure to set hierarchy from |
|**Scale**||`$font-size-scale`|| This variable is used to calculate the font size of all elements. Check this link for example http://type-scale.com/|
|**h1**|`$font-size-h1-in-px`|`$font-size * 2`| | This font-size should be based on the scale and the font-size-base, meanwhile, the calculation here is a example of how it could work. (using rem should achieve the same result, but break if we use different font for the body and for other elements, as x-height is different -- check the ressource: https://iamvdo.me/en/blog/css-font-metrics-line-height-and-vertical-align
|**h2**|`$font-size-h2-in-px`| `$font-size * 1.6` |
|**h3**|`$font-size-h3-in-px`| `$font-size * 1.3` |
|**h4**|`$font-size-h4-in-px`| `$font-size * 1.0` |
|**h5**|`$font-size-h5-in-px`| `$font-size * 1.0` |
|**h6**|`$font-size-h6-in-px`| `$font-size * 1.0` |
|**p**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**li**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**ol**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**label (form)**||||inherited from the parent element. For example, if the p is part of an interface element, it will get the `$font-interface` value as it will be used by the parent.
|**a**|`$link-font-family`, `$link-color`, `$link-font-style`, `$link-font-weight`, `$link-underline-color` |||Link need some styling to be different from the content, let's add some variable that you can change for the link and see what's missing from there.
## Typefaces variables
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|**Primary font style**|`$font-primary`| | | Collabra font variables are named based on what the font is refering to. Check below.
|**Secondary font style**|`$font-secondary`
|**Contextual label**|`$font-contextual-label`
|**Date**|`$font-contextual-label-date`|||Treated as part of the label|
|**Section label**|`$font-section-label`
|**Teaser header**|`$font-teaser-header`
| *font family set for the whole app* |
|**Author font**| | `$font-author` | | This font will be used for all the element that the author work on: manuscript and form to submit.
|**Reviewer font**| | `$font-reviewer` | | This font will be used for all the element that the reviewer work on: reviewing draft and review letter.
|**Interface font**| | `$font-interface` | | This font is the one use for all the interface element
@julientaq @Nickhttps://gitlab.coko.foundation/pubsweet/design/-/issues/1Color variables2018-01-29T07:20:03ZYannis BarlasColor variablesThe purpose of this issue is to come up with a common list of color variables for theming in pubsweet applications.
The idea is to compare the ideas that elife and coko/collabra have on the subject and find a "vanilla" list that organi...The purpose of this issue is to come up with a common list of color variables for theming in pubsweet applications.
The idea is to compare the ideas that elife and coko/collabra have on the subject and find a "vanilla" list that organisations can build on.
| Elife asset name|Elife suggested variable|Coko suggested variable|Vanilla variable|Notes
|---|---|---|---|---|
|**Primary color**|`$color-primary`|`$color-primary`||This color is the branding main color|
|**Primary secodary**| |`$color-secondary`||This color is the branding secondary color|
|**Interation color**|`$hover-focus`|`$color-action`| | This color is the color used when hovering a button, a link.
|**Text color**|`$color-text`|`$color-text`| | Main color for the text, which should be inherited by all elements
|**Text secondary color**|`$color-text-secondary`| ||What is the use of this color?
|**Text placeholder / disabled color**|`$color-tex-placeholder`
|**Furniture color (dividers)**|`$color-text-dividers`
|**Background color hue**|`$color-text-background-hue`| | | Where is that variable used?
|**Success color**|`$color-success`|`$color-valid`
|**Attention color**|`$attention-color`| `$color-warning`|
|**Attention color**|| `$color-danger`
|**Attention color**|| `$attention-color`
|**light grey **|| || This color comes from editoria alignmentBox, need to be updated
|**grey **|| || This color comes from editoria alignmentBox, need to be updated
|**dark grey**||| | This color comes from editoria alignmentBox, need to be updated
|**whitergba**|| || This color comes from editoria alignmentBox, need to be updated (used for the inset of the alignmentBox)
@julientaq @Nick