Color palettes

[David-Mulder]

The material design spec often talks about stuff like:

Use 50-value of secondary app color for background fill

which as far as I know the best way to go about is using something like --paper-pink-50 for the default app-theme.html, however it sucks that the consumer of an element next has to go through all elements to manually set the the respective values up. Wouldn't it be better to have palettes like

--accent-color-50: var(--paper-red-50);
--accent-color-100: var(--paper-red-100);
--accent-color-200: var(--paper-red-200);
--accent-color-300: var(--paper-red-300);
--accent-color-400: var(--paper-red-400);
--accent-color-500: var(--paper-red-500);
--accent-color-600: var(--paper-red-600);
--accent-color-700: var(--paper-red-700);
--accent-color-800: var(--paper-red-800);
--accent-color-900: var(--paper-red-900);
--accent-color-a100: var(--paper-red-a100);
--accent-color-a200: var(--paper-red-a200);
--accent-color-a400: var(--paper-red-a400);
--accent-color-a700: var(--paper-red-a700);

and then use the correct respective colors wherever we need them. Sure, I get that it takes a bit longer to set it up when you start off, but a simple element could help out a lot there in that case (<paper-theme primary="indigo" accent="red">) and that way you would be 99% done in seconds.

[notwaldorf]

That would be neat! After talking to @cdata I think an easy way to do this that (might) work is to make a style is=custom-theme extension that would automagically do this on the fly.

I'll try to take a look at this week! Thanks for the suggestion!

[bendavis78]

I'm actually a bit confused by the recent changes to default-theme.html. I see that the existing names have been deprecated (and I agree, some of them were confusing). But, as an element author, I'm not sure what to use between the --light-* and --dark-* variables. Shouldn't it be up to the app developer whether to use light vs dark theme? It seems that we still need a set of variables that are "preference agnostic" (unless I'm misunderstanding something).

[notwaldorf]

In the past, default-theme was basically just using the light theme (i.e. dark text on a light background). All I did was just rename them in a way for this to make sense.

So, in your code, if you want the text to be dark, because your backgrounds are light, you should use the --light-* versions. I think that's pretty agnostic -- it's just trying to be helpful so you don't accidentally use black text on your dark blue background. :)

[David-Mulder]

@notwaldorf But as a component consumer I will be deciding whether I want my site to use a dark or light theme, so if I want it dark yet the component creator made it light then I would have to set the --light versions with dark colors which makes no sense.

[notwaldorf]

Is the question just about the "deprecated" comment? I can remove it (it's really just --text-primary-color: var(--dark-theme-text-color); that needs to be cut out, so that you still have primary-text-color available and configurable everywhere

[notwaldorf]

Alright, let me know if #89 makes more sense

[David-Mulder]

@notwaldorf The point @bendavis78 correctly raised is that right now there are specific css variables for the light and dark theme which makes no sense whatsoever:

So, I produce a component, let's say a <paper-datatable>, of course I am not going to pick the dark theme as the light theme is the normal one. So I set my background as background: var(--paper-datatable-background-color, --light-theme-background-color). Next a consumer of my element shows up and he wants the paper-datatable - and all other light themed elements - to look dark, so what does he have to do?

--light-theme-background-color:  #212121;

auch

Either way, it would be best to deprecate things like background-color entirely and migrate to things like just primary-color-500, because then it's a true theme rather than mixing intention ('background') and palette ('light' vs 'dark') through each other. The only thing a theme should care about is what 'type' the color is and considering this is supposed to be inspired by MD the setup with just primary-color and secondary-color makes most sense. My proposal would be as follows:

--primary-palette: #3F51B5;
--accent-palette: #FF4081;
--base-color: #000000;

or

<paper-theme primary-palette="#3F51B5" accent-palette="#FF4081" base-color="#000000"></paper-theme>

which will automatically generate the following

--primary-color: #3F51B5;   
--primary-color-light: #C5CAE9; //take by default --primary-color-100, but allow overwriting
--primary-color-dark: #303F9F; //take by default --primary-color-700, but allow overwriting
--accent-color: #FF4081; //take by default --accent-color-a200, but allow overwriting

--primary-color-50: #e8eaf6;
--primary-color-100: #c5cae9;
--primary-color-200: #9fa8da;
// etc.

--accent-color-50: #fce4ec;
--accent-color-100: #f8bbd0;
--accent-color-200: #f48fb1;
//etc.

//the below takes the `base-color` and applies the MD transparencies based on whether 
//the base color is less or more than #888;
--text-color: rgba(0,0,0, .87);
--secondory-text-color: rgba(0,0,0,.54);
--disabled-color: rgba(0,0,0,.38);
--divider-color: rgba(0,0,0,.12);

what do you think?

[notwaldorf]

First of all, I understand your comment about having an element that automatically generates themes. I already said that's a good idea, and I've started looking into it. That element is orthogonal to providing the default light and dark Material Design themes, and is completely unrelated to @bendavis78;s question.

I think you misunderstood what I originally tried to explain. If you look at paper-input, it is using --primary-text-color as its text colour, and will continue to do so. That colour is by default the "light theme" colour, because that's how our elements are set up.

In your demo page, where you are using paper-input and many other paper-elements that also use --primary-text-color as their default color, to change the theme for all the elements at once, all you have to do is:

: root {
  --primary-text-color: red;
}

If you want to change everything from light to dark, then you would change the 5 values in the first section (https://github.com/PolymerElements/paper-styles/pull/89/files#diff-fba59d2899b10cb0edb072669a58ffd1R24) to their dark equivalents, and this would update all the elements.

I have never disagreed with generating a color palette is a good idea, and it will eventually happen. However, in the meantime I don't see a problem with giving people the set of values for the two default Material Design palettes. You don't have to use these properties unless they're useful to you, and they change absolutely nothing from what paper-styles did before this change.

[David-Mulder]

Wait, are you suggesting that the dark and light variables should never be used by element authors? Because if so that would kind of make sense, but that should be very clearly communicated!

And as far as generating the palette, the reason I went out of my way to outline those things was because I wanted to make clear which variables as a component author I need access to based on the MD spec. Importantly noting that dark and light are not terms anywhere I should as a component author encounter. Either way, if my understanding is right now that the dark and light variables should only be used by people setting up app themes then you should probably move those variables from default-theme.html to color.html.

[notwaldorf]

I am not suggesting that. You can use any variables as you please. Maybe you don't want an element to be themable, in the same way you can literally hard code any colour in your element. But generally, not, you as an element author would probably not use the light-* variables except as defaults, if anything.

I think default-theme was meant to be one of the material design themes used in a demo. I can see them being split maybe in light-theme and dark-theme, but probably not color.html

/cc @cdata

[David-Mulder]

So, I worked out a bit of a proposal both on the variable side (which variables should be exposed and why the idea of --light-theme-* and --dark-theme-* is totally inadequate) and a quick implementation of an element generating such a set of variables:

https://github.com/David-Mulder/paper-theme

[JosefJezek]

Check out the PSK+ default-theme
https://github.com/StartPolymer/polymer-starter-kit-plus/blob/master/app/themes/default-theme/variables.css
https://github.com/StartPolymer/polymer-starter-kit-plus/blob/master/app/themes/default-theme/variables.js

[notwaldorf]

@David-Mulder That's super neat!