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/30separate line heights for each heading?2018-07-02T10:55:31ZJen Spencerseparate line heights for each heading?In the [latest eLife theme](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926983) we have line heights for each h1, h2, etc, as well as fontSizeBase & fontSizeBaseSmall.
This has now been added to [the code for the eLif...In the [latest eLife theme](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926983) we have line heights for each h1, h2, etc, as well as fontSizeBase & fontSizeBaseSmall.
This has now been added to [the code for the eLife theme](https://github.com/elifesciences/elife-xpub/blob/develop/client/elife-theme/src/index.js#L33-L40)
Is this something you would want to replicate in pubsweet?Yannis BarlasYannis Barlashttps://gitlab.coko.foundation/pubsweet/design/-/issues/29"boxshadow" or "dropshadow"? - 2 names for the same thing2018-06-28T15:52:36ZJen Spencer"boxshadow" or "dropshadow"? - 2 names for the same thingIn [`VARIABLES.md`](https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md#shadow) the shadow variable is called `dropShadow`, so this is the same name being used in [eLife's designs](https://projects.invisionapp.com/sha...In [`VARIABLES.md`](https://gitlab.coko.foundation/pubsweet/design/blob/master/VARIABLES.md#shadow) the shadow variable is called `dropShadow`, so this is the same name being used in [eLife's designs](https://projects.invisionapp.com/share/NZKXOQUV4P3#/screens/302926980).
But the name used in all the themes (e.g.[the Coko theme](https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/coko-theme/src/index.js#L59) & [eLife theme](https://github.com/elifesciences/elife-xpub/blob/develop/client/elife-theme/src/index.js#L44) is actually `boxShadow`.
It's [now being changed in eLife's theme](https://github.com/elifesciences/elife-xpub/pull/233/files#diff-b997819fc7f534ccbc7ed0f02dc3aa50R58) to `dropShadow`, to match our design document.
Which do you fancy? :smile:https://gitlab.coko.foundation/pubsweet/design/-/issues/28styleguide-demo.coko.foundation -- left hand frame does not work on Safari2018-04-20T14:42:54ZBrian Tinglestyleguide-demo.coko.foundation -- left hand frame does not work on SafariSafari Version 11.1 (13605.1.33.1.2) on OS X 10.13.4
Hi, When I try to browse http://styleguide-demo.coko.foundation on safari, when I try to scroll down on the left frame, as soon as I mouse over a link text, the left frame jumps back ...Safari Version 11.1 (13605.1.33.1.2) on OS X 10.13.4
Hi, When I try to browse http://styleguide-demo.coko.foundation on safari, when I try to scroll down on the left frame, as soon as I mouse over a link text, the left frame jumps back to the top, undoing my scroll. This makes it impossible to select the lower links (unless you filter for what you want)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/26Define values for Coko theme2018-04-10T09:47:33ZYannis BarlasDefine values for Coko themejulientaqjulien@coko.foundationjulientaqjulien@coko.foundationhttps://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/24Subgridunit variable2018-06-28T09:45:27ZYannis BarlasSubgridunit variableThere seems to have been a discussion that was not conclusive about including a `subGridUnit` variable in the themes.
This seems however, to already exist in the default theme's code (https://gitlab.coko.foundation/pubsweet/pubsweet/bl...There seems to have been a discussion that was not conclusive about including a `subGridUnit` variable in the themes.
This seems however, to already exist in the default theme's code (https://gitlab.coko.foundation/pubsweet/pubsweet/blob/master/packages/default-theme/src/index.js#L39).
Let's have a final discussion about this.
I think we should either standardize this or remove it from the themes.https://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/22Add a "warning" color2018-06-27T11:31:48ZAanand PrasadAdd a "warning" color`ValidatedField` display a _warning_, as distinct from an _error_:
![Screen_Shot_2018-03-12_at_14.34.41](/uploads/37fa05d95ccdb6e7e2eb7d3ba5022b7b/Screen_Shot_2018-03-12_at_14.34.41.png)
There's no color in `VARIABLES.md` for this, so ...`ValidatedField` display a _warning_, as distinct from an _error_:
![Screen_Shot_2018-03-12_at_14.34.41](/uploads/37fa05d95ccdb6e7e2eb7d3ba5022b7b/Screen_Shot_2018-03-12_at_14.34.41.png)
There's no color in `VARIABLES.md` for this, so @g-sam added one in https://gitlab.coko.foundation/pubsweet/pubsweet/commit/c2a1d54bc7f077f39ab5a932fc18783493dc4eff. We shouldn't have discrepancies between the official variables and what's in the default theme, so we should either remove the warning function or add `colorWarning` to `VARIABLES.md`.
Thoughts?Nick DuffieldNick Duffieldhttps://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/20Accessibility requirements2018-03-29T12:00:35ZYannis BarlasAccessibility requirementsIt was decided that a good first step here would be for each of the organisations to come up with their requirements with regards to accessibility, so that we can start a solid discussion of where vanilla should stand.It was decided that a good first step here would be for each of the organisations to come up with their requirements with regards to accessibility, so that we can start a solid discussion of where vanilla should stand.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/18[RFC] Sharing assets: workflow and tooling2018-03-07T18:57:24Zjulientaqjulien@coko.foundation[RFC] Sharing assets: workflow and toolingTo be usable for developers and designers, all our assets should be delivered as a react component and as a editable mockup.
For example, in the case of a button:
- a button component, that you can reused in the code by adding a `<Butt...To be usable for developers and designers, all our assets should be delivered as a react component and as a editable mockup.
For example, in the case of a button:
- a button component, that you can reused in the code by adding a `<Button>` element;
- a graphic version of the component with editable text and styles.
Our goal is too have a single source of truth that we can offer to newcomers and that let designers and developers collaborate with as a little friction as possible. To achieve that, we need:
- an up-to-date styleguidist instance that let you see components (states, styles, behavior and animations);
- an up-to-date library that can be use in any tools that someone may want: from sketch to photoshop, amongst various other (pencil app, invision creator, or whatever comes next)
The only theme that needs to be share between designers is the starter kit.
### Some use cases that comes to mind:
- a designer needs to create a mockups using our atomic system. She can select the atoms she wants, import it into her application of choice and start building a new component.
- a designer is sending the mockup for his new component to his co-working developer and she must be able to see how the design must be implemented in terms of styling
- two designers share assets to build two different components based on the same atoms and molecules, and both are using two different tools.
### Basics
- Inclusivity first: no option should be set as the only way to contribute to the project. We must avoid any solution that would let someone out of the project.
- There is no really working options to share proprietary formats betweens applications. For instance, Figma knows how to open sketch file, but it does not render it as good as it was in sketch (not even talking about font). Sketch is unable to render figma files. Invision Creator has not been tested yet, as all the future tools.
- The only graphic format that stay editable is SVG. With the issues that the way it's exported from different applications are not totally set. For example, figma export the text as shapes, which means that you can not edit it anymore, you need to delete the text to add the new one -- also, it seems to be a bug that figma is trying to solve on their next svg export tool.
### Options
For now, three options are on the table:
- A shared folder with all the assets, ordered by atomic level, as svgs.
- A different asset library for each different tool we'd like to use (for each tool, a designer has to maintain the library and make it accessible).
- A tool used as a hub so we can share mockups and specs from different toolset in the same environment (@AlexPricop talked about https://zeplin.io as a tool to share the mockups from sketch/adobe tools/figma and let developer inspect the code). Zeplin only works on OSX and Windows but the idea would be to have a tool that let you share the documentation of all design with your developer.julientaqjulien@coko.foundationjulientaqjulien@coko.foundationhttps://gitlab.coko.foundation/pubsweet/design/-/issues/17Design notes from the Coko meet up 26-28 feb2018-03-09T15:42:59ZNick DuffieldDesign notes from the Coko meet up 26-28 feb* Remaining xPub components on style guideist need to be brought into line with starter kit
* We have an agreed workflow from design to development
* Weekly design syncs between eLife, Coko and Hindawi for show and tells for work an...* Remaining xPub components on style guideist need to be brought into line with starter kit
* We have an agreed workflow from design to development
* Weekly design syncs between eLife, Coko and Hindawi for show and tells for work and new components
* New component designs are to be handed off to developers as gitlab issues. This includes a visual, description and spec annotations
* Accessibility requirements have been discussed for the xPub starter kit
* Checklist to be agreed at next design meeting
* We have an agreed tool set to measure accessibility
* Lighthouse by google
* A11YN
* We couldn't find a solution for file sharing after trying a number of approaches. This may not matter for now as it is unclear on what level we will share design assets
To do list for design
* Finish current component list as mentioned above
* Submit standard component values that are not part of customisation (width was referenced by yld)
* Agree accessibility check list for component contribution
* Review components/page layoutshttps://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/14Reset CSS2018-03-13T17:52:43ZYannis BarlasReset CSSThe theme should probably provide a `reset.css` file as well, removing browser default styles.The theme should probably provide a `reset.css` file as well, removing browser default styles.