Style Guide

[tangjeff0]

• [x] Colors
• [x] Typography
• [X] import to project #125
• Breakpoints - we will let this emerge, as discussed below

Downhill Tasks (good for contributors)

Sorted easiest to hardest (as I perceive)

• [x] depths / shadows - seems like a very straightforward implementation. Just create various +box-shadow-X functions like [here].(https://github.com/athensresearch/athens/blob/master/src/cljs/athens/style.cljs#L45-L46)
• [x] Icons - #129 #133
• [x] colors & opacities. #148 Explained below

Colors & Opacities

06-08-18 Edit: @shanberg found stylefy lib and is refactoring relevant code in #136. This solves inline pseudoselectors, but not the opacity abstraction out of the box.

Problem

• Hexcodes are a poor way to identify colors because they are machine-, not human-readable.
• HSL is also not great because it doesn't use opacities directly the way rgba or Figma does.
• We want to stick to the design system's opacity levels: 0.1, 0.25, 0.5, 0.75, 1
• Defining a function for each (Color OR Cackground Color) x Opacity leads to many permutations, e.g. +primary-.1 +secondary-.5 +warning-bg-.75...
• Furthermore, with-styles also generates a style map, e.g. {:style {:key "val"}}. But oftentimes these different shades/opacities happen on the hover pseudoselector, which cannot be supplied through inline styles the way we've been doing with with-styles.

Solution?

• need to easily create any permutation of Color x Opacity and Background Color x Opacity
• need to easily merge into a flattened map to add to style-guide-css

Design Language / Style Guide:

[tangjeff0]

Colors

• [x] change colors to semantic names (i.e. confirmation-color rather than green) per @shanberg's recommendation
• [x] still thinking about when to use composable style functions like (+blue-bg) vs a CSS class like .blue-bg (https://github.com/athensresearch/athens/commit/4d0b5454c8aaba5df097e6019df5204fce88b9d3#r39553790)

Typography

• [X] 3 fonts: sans, serif, mono
• [X] h1, h2, h3, h4, h5, span, span.block-ref, span.small
• [ ] what should the top and bottom margin be for headers? HTML defaults to .67em I think, but I changed it to .2em.
• [ ] ~ font-weight is getting overridded by DevCards CSS, so the types are not 1:1 with Figma, but removing and re-implementing DevCards CSS is a separate standalone issue.

Icons

• [x] Not sure how to import Material UI Icons in CLJS (help wanted)

Breakpoints

• [x] designers need to specify how many and what values these are at @designers

[jeroenvandijk]

+1 one semantic names. I think things like green can be used internally (in the style.cljs file for instance). Maybe the designers can make some examples of how the html would be structured ideally. As developers, we can see how we could make this work for them? I think we can make everyone happy

[tangjeff0]

Discovered Tasks

• DevCards CSS
• Composable CSS styles: #113
• lein prod should build CLJS bundle for DevCards as well

[tangjeff0]

Opacity of highlight is 0.2, but the closest color ramp to that is 0.25. @jacobmorse

[jacobmorse]

@tangjeff0 You're not actually supposed to hold us to the system. Just kidding — I overlooked that discrepancy. I think we can actually push it down to 0.1. I'd prefer it be more subtle.

[tangjeff0]

Latest check-in

• [X] Colors - using semantic colors now
  • caveat: panel doesn't include border as it does in the Figma style guide. Doesn't need to, though. Trivially easy to implement a +panel class in a later PR.
• [X] Typography
  • caveat: using 0.2em for margin top and margin bottom for headers. Not sure if that works
• [x] Icons - haven't looked any deeper at this, would like help
• [x] Breakpoints ? @shanberg @jacobmorse

[shanberg]

@tangjeff0 @jacobmorse On breakpoints, from an earlier discussion:

I'm thinking we should describe the min/max-widths of the main content column, secondary content column, and expanded nav, and then a breakpoint will emerge whenever the text feels too cramped. I prefer that at least over picking favorite browser sizes and baking that into a system.

[jacobmorse]

I agree, with the possible exception of the Nav sidebar, which I think should be fixed width.