pluralsight / classic-design-system Goto Github PK

colocates dup gradient definition next to the first, css definition

makes sense to import this into icon for use as a fill override.

• x dead link
• x site heading spacing - h1 - 56px 0; h2 - 56px 0 0 0;
• x site - colors page code example

this line:
https://github.com/pluralsight/design-system/blob/master/packages/card/react/index.js#L115

needs to change to:
el.props.className

Card L

• Max: 680px
• Min: 440px

Card M

• Max: 440px
• Min: 240px

Card S

• Max: 240px
• Min: 120px

would have to run a 'gen site' command.
but would have to have live updates to dev env on localhost without running the gen cmd

auto
auto formatted
auto optimized

Label (Title Case): XSmall, XXSmall, XXLarge
Code (camelCase): xSmall, xXSmall, xXLarge, psLayoutSpacingXXLarge
Code (lowercase): xsmall, xxsmall, xxlarge
Code (dashified): x-small, xx-small, xx-large

Wanted to document the idea around exporting the configuration options for our components as part of the API.

Current

<Button
  appearance="stroke"
  size="tiny">Click me</Button>

Proposal

<Button
  appearance={Button.APPEARANCES.STROKE}
  size={Button.SIZES.TINY>Click me</Button>

Or

import Button, { APPEARANCES, SIZES}   from '...'
// Splitting hairs, the point is just to make it explicit/part of the interface.

While this API is more characters I think it has some valuable wins...

1. More "grep-able". A developer can find all TINY buttons while doing less work (or no work) to distinguish the context.
2. Available options are explicit and part of the API itself. This enables introspection and less need to jump to the documentation. It also diminishes versioning problems where the public documentation is a different version than the component in use.
3. For things like components knowing the magic string can in some sense be harder to guess than tooling that is made available by an API like this.
4. Typos can be caught for consumers by throwing on undefined. This could be done with the existing approach but then you would be making the options explicit which is what I'm proposing.

Happy to support if we want to continue down the current direction.

while applying the icon styles as best as possible

• x action icon spacing - add 4px from corner, space icons add 4px between
• x action icon hover - white; normal light gray from flat button
• x make image linkable
• x make link title same margin top as string title, weight
• x image heights
  96 for small
  144 for medium
  240 for large
• x metadata font size per card size
  S and M are 12px
  L is 14px

instead of skipping xLarge

popped up since the design system change #26

wrap something custom for the site.

@dborodyansky would you mind providing measurements for these? Or are they just the spacings that used to exist in the design system?

more consistent with other naming

• to support home 2.0 and channels integration

icon assets to download: https://pluralsight.slack.com/files/dmitry-borodyansky/F6F5AUW6T/ds-bg.svg

this class
ps-card__metadata__datum--link

only if element type is a, anchor

right now, all react elements get it.

carets, etc from comp

for sidenav and landing logo

• icons respond to sizes
• icons respond to transition
• square icon-only buttons

See how far we can take this. One CPT had a hard time with the config. It is a leap. And it is an effort to work it into an existing/different build config. Others matched up well, but mostly because the tech choice/familiarity was similar.

There will likely be tradeoffs in this direction, but let's get a feel for them before we scale out our building of component and do 10 more in a certain way.

1. Progress bar height should be 4px tall excluding the single pixel divider above it.

2. Progress bar would be better overlaid, aligned with the bottom of the card. Titles of cards with or with out progress would then align vertically.

waiting -- secondary nav

ensure matches styleguide
gather +1s

header differences - xl and l
options instead of serial

Have a discussion about:

• What the design guideline is
• What problem the guideline is solving
• What the developer experience should be

how do they package components?