meetuparchive/meetup-swatches

Cross-platform color configuration by design@Meetup

meetup-swatches's Issues

Deprecate $C_backgroundFooter

Assuming we standardize the footer background to be an inverted context (which was advised by AdamD on 2013-12-30), we should deprecate this parameter.

Colors need opaque alternates/fallbacks

Part of our set of primary colors (mostly just the shades of gray/black) are alpha-channel colors, which can work nicely on the site and give us rich semi-translucent shading and layering fun.

However, to be able to tap the same shades of gray for email designs or UI that cannot rely on RGBA colors, we need some opaque hex values for these, facsimiles of the tinted color over white (over black for the inverted colors).

2.1.0

Small fixes/additions to foundation-based palette

add "attention" yellow

for when we want to display something potentially negative (ie. "unpaid" status icon) without associating meetup red with bad things

repeated color values in SCSS should just use color names

Ideally the SCSS output should be explicit when it's applying color names (not just reusing color names in colors.yaml).

e.g.

// bad
$C_secondaryGray: rgba(0,0,0,0.65);
$C_textSecondary: rgba(0,0,0,0.65);

// good
$C_secondaryGray: rgba(0,0,0,0.65);
$C_textSecondary: $C_secondaryGray;

I realize colors.yaml is supposed to be the primary pre-processed color reference, but this update would make the SCSS cleaner.

Should backgroundFooter be the same as backgroundInverted?

Coming out of the nav specs, the BG footer color is a 25% gray, and the inverted color is a 20% gray.

We will probably want these to match, in case inverted sections get stacked on top of the footer components.

change or append to output files to use lists and/or maps of colors

for example, with a Sass list we could do something like:

/* swatches sass distribution */
$accent_swatches: $red, $blue, $green;

/* consumer */
@each $color in $accent_swatches {
     .backround--#{$color} {
          background-color: $color;
     }
}

I see some advantages to using maps or lists over a bunch of orphan vars for the distribution files...

make the rebuild.rb a propper gem

Idea:

an abstracted "swatch cutter" gem that you feed a color yaml, and it generates ios, andriod, sass, and less files

we can update our meetup-swatches gemfile to require this gem

Why:

because this would make a cool open source thing

Update $C_backgroundCollection to be blue shifted

Add inactive navigation icon color

Create swift app distribution

see app UIColor+Palette.swift

Switch overlayPressed to 0,0,0,.2

As part of normalizing pressed colors on Android, we had a chat about overlayPressed and if it's really going to get used on all elements, it needs to just be a shade. Transparent blue isn't going to play well with a red button.

As part of this, I'll look into where overlayPressed is already getting used and possibly split this color if it's getting used for things that aren't presses.

Modify swatches export script to include version information.

It would be useful for the exported android/colors.xml file to have two changes in particular:

• Include a comment containing version information, so that when an Android maintainer updates the colors, we can tell the last time they were updated.
• Change the name of the file from colors.xml to swatches.xml (or something similar.) Our Android project currently has a colors.xml file with older versions, so perhaps having a different file naming convention will help. [1]

---

[1] Also, feel free to open an issue on the Meetup Android repo if you think we'd be better served by making the modification on the Android side of things.

---

See also: #35, meetup/meetup-android#142

make sure cocoapods can deal with non-tagged 'latest' code

We would like to treat the master branch as "ready for production", meaning that we can eliminate the tag-versioning step whenever we make updates.

For sassqautch, this will be simple to set up with bower, but cocoapods might need some tweaking.

Fully-opaque rgba() in scss should be rgb()

using rgba color declarations in css when alpha channel = 1 is a little brutish. Let's be more refined.

Add `inverted` link color

in inverted color schemes, the link text becomes very low-contrast (especially with the light font-weights in SQ2). We can improve readability by tinting the $C_link to, e.g. 5EB4FF.

current:

proposed:

Create alias for error color

Right now we're just using $C_red.
In the rebrand, we're using our new yellow color almost exclusively for errors. Might be nice to alias this as something like $C_error

Add "accentDark" red color

Can we just rename this repo "swatches"?

"Meetup-swatches" seems redundant.

@extend instead of @mixin for colors with opaque fallbacks?

all of the opaque-color fallback mixins (e.g. color_textPrimary) are argument-free mixins, which means they would probably be more efficiently implemented as @extend %placeholders.

Filesize savings are probably pretty tiny, though, so this is a really low-priority issue - I think the only advantage to keeping the setup as-is is that the styles in the element inspector in browser dev tools will be a little easier to read.

consider generating an ase file for photoshop/illustrator/adobething

https://github.com/layervault/ase.rb

change C_money to a different green; add wepay blue

make documentation beautiful

It would be nice to make the swatches prettier; maybe an inline-block list of cards that mimic pantone swatches.

We should also look at calculating and printing hex codes with JS

add orange accent color from create sales page to swatches?

it's a pleasant orange, and fits well with C_red: https://secure.meetup.com/create/learn-more/

Add color for outlook.com

Needed for bug https://bugz.meetup.com/show_bug.cgi?id=50319. The color is #0072c6.

Note: in branch outlook_contacts_50319, this color was temporarily hardcoded in _social-buttons.scss.

Can this be renamed Swatchsquatch?

Semantic versioning

We should start using semantic versioning for this project instead of counting by tens.

version = <realease>.<bugfix>.<hotfix>

make a github page branch