Light and dark variants support

[amercier]

Hi @shuhei!

This PR adds Light and dark variants support on top of #22. Examples of light and dark variants can be found in the Material Color Tool:

Note: 49baf13 from #22 is included here, until #22 is merged.

[shuhei]

@amercier Thanks for another PR! Material Design evolved so much while I haven't checked it for a while...

Maybe I'm a bit paranoid, but I'm a bit afraid of inflating JS/CSS sizes as a web performance enthusiast. The files in dist are are already very big, and this PR triples them.

File sizes of the current master (less, sass, etc. are excluded because they just expose variables):

FILE	RAW	GZIP
colors.css	55.7412KiB	8.11719KiB
colors.es2015.js	5.48438KiB	1.7832KiB
colors.js	4.97852KiB	1.72852KiB
colors.json	6.44922KiB	1.63184KiB

What is your use case? If you use the colors with JavaScript, can't we just use JavaScript functions to create light/dark variants on the fly?

[amercier]

I agree, the need for light and dark variants doesn't really justify the 3x increase in payload for most users.

My use case is actually very simple: I'm making a tiny website that uses a React Library called React Material Web Components. This library - which uses material-components-web under the hood - expects theming to be defined as in Material Design Color Tool, by:

• a primary color, its variants (light and dark), and an accorded text color (black or white) for contrast,
• a secondary color, with the same variants.

My website, by its design, has to use multiple themes. I end up in my .scss file with something like:

$green-pink-theme: (
  primary: #4caf50,
  primary-light: #80e27e,
  primary-dark: #087f23,
  on-primary: #fff,
  secondary: #d81b60,
  secondary-light: #ff5c8d,
  secondary-dark: #a00037,
  on-secondary: #fff
);

@mixin apply-mdc-theme($theme) {
  --mdc-theme-primary: #{map-get($theme, primary)};
  --mdc-theme-primary-light: #{map-get($theme, primary-light)};
  --mdc-theme-primary-dark: #{map-get($theme, primary-dark)};
  --mdc-theme-on-primary: #{map-get($theme, on-primary)};
  --mdc-theme-secondary: #{map-get($theme, secondary)};
  --mdc-theme-secondary-light: #{map-get($theme, secondary-light)};
  --mdc-theme-secondary-dark: #{map-get($theme, secondary-dark)};
  --mdc-theme-on-secondary: #{map-get($theme, on-secondary)};
}

apply-mdc-theme($green-pink-theme);

Instead, I would like to be able to replace hard coded color values by color/shade names:

@mixin apply-mdc-theme($primary, $secondary) {
   // ...
}

apply-mdc-theme('green-500', 'pink-700');

Solution

What I could do here is:

• Option A: (this one) add light/dark variants, and "on" colors (later) to material-colors. Problem: 3x increase in css/js payload which is not required for most users.
• Option B: add light/dark variants, and "on" colors (later) to material-colors's pre-processor files only: dist/colors.{less,scss,sass}. Problem: divergence between languages, not ideal.
• Option C: add light/dark variants to separate files: dist/colors-light.{js,css,less,scss,...}, dist/colors-dark.{js,css,less,scss,...}. "on" colors can come up later as separate files as well.
• Option D: publish my fork as a separate npm module: material-colors-extended. Problem: fragmentation, I prefer contributing than forking whenever possible.

@shuhei Which option do you think is the best? (I will rewrite this PR accordingly). Personally I think Option C would be the best one.

[shuhei]

Sorry for this late reply. Thanks for the explanation and providing multiple options! Option C sounds reasonable. But I don't think we need to have separate files for pre-processor languages. How about combining Option B and Option C?

[amercier]

@shuhei Yes, that makes sense! Let's close this PR for now, I will implement that in a separate one later once I have made enough progress.