Default theme should not use grey text.

[diogocamposwd]

The spec says:

Use opacity for text, icons, and dividers

You can change the opacity of text to convey how important certain information is relative to other text.

Transparent black or white text behaves more flexibly than grey text because it remains legible and vibrant against background color changes.

[notwaldorf]

(I've left a comment on #98 about how I believe opaque colours are more expensive to paint than solid colours, and how this might not be a cost that is worth incurring)

[hotforfeature]

This is by no means a comprehensive test, but here are a couple of numbers in Chrome 51:

This test was done with the Polymer Project Shop demo by changing the --app-primary-color, --app-secondary-color, and --app-accent-color to rgba() values instead of hex values. These variables are used throughout the demo app as foreground colors for text and buttons.

First few rounds of testing were for hex. I ran through several short and long tests of the app, refreshing pages, scrolling, and entering information, trying to get the app to repaint as much as possible. I then took the profiled paint time and divided it by the test time. Here is a sample profile:

On average, hex color values painted from 9.243ms - 11.59ms per second

I repeated the process, but this time used the rgba() values for all the color variables.

On average, rgba color values painted from 10.869ms - 13.775ms per second

Interpretation

There is a performance hit, obviously, but it's only about 2ms-3ms per second on a modern engine.

The shop demo app is by no means an intensive application. Where would we see a greater performance hit in normal apps?

Well the performance hit comes down to repainting. When the background color changes, the text must be repainted to determine the correct value to display. This begs the question though of how often the background will change. One of the biggest and most common repainters will be animation.

However, it also helps to look at the common use case for rgba() values. They'll be used on body, title, and header text, and during transitions from text state, such as enabled to disabled. I believe they will rarely be used in cases where frequent repaints will happen. In those edge cases, individual app performance can be tweaked by using an opaque hex value on those high-repaint areas.

Suggestion

Personally, I believe that the performance hit is negligible compared to the benefit of having flexible text colors set by default. I am a huge believe in options though, and the documentation and themes could be modified to provide either a spec-compliant theme and a performance conscious theme.

CSS variables could be created that expose the material design dark/light text color options. From there, an app could integrate them into their own theme.

/* default-theme.html */
<style is="custom-style">
  /* other color variables */

  --dark-primary-text-color: rgba(0, 0, 0, var(--dark-primary-opacity));
  --dark-secondary-text-color: rgba(0, 0, 0, var(--dark-secondary-opacity));
  --dark-disabled-text-color: rgba(0, 0, 0, var(--dark-disabled-opacity));
  --dark-divider-color: rgba(0, 0, 0, var(--dark-divider-opacity));
  --light-primary-text-color: #fff;
  --light-secondary-text-color: rgba(255, 255, 255, var(--light-secondary-opacity));
  --light-disabled-text-color: rgba(255, 255, 255, var(--light-disabled-opacity));
  --light-divider-color: rgba(255, 255, 255, var(--light-divider-opacity));
</style>

/* my-theme.html */
<style is="custom-style">
  --primary-color: var(--paper-indigo-500);
  --light-primary-color: var(--paper-indigo-100);
  --dark-primary-color: var(--paper-indigo-700);
  --accent-color: var(--paper-pink-a200);
  --light-accent-color: var(--paper-pink-a100);
  --dark-accent-color: var(--paper-pink-a400);

  --primary-text-color: var(--dark-primary-text-color);
  --secondary-text-color: var(--dark-secondary-text-color);
  --disabled-text-color: var(--dark-disabled-text-color);
  --divider-color: var(--dark-divider-color);
</style>

This, along with better documentation explaining how to set up your own custom theme and the pros/cons regarding text color, would be an easy start on the process to determining what should be shipped out by default. It gives developers the option to use it (with the potential performance risk explanation in the docs), but does not make it the default option.

With more research into different use cases, if a decision can be made that the performance hit is negligible, then the default theme can be modified to use the spec-ready text colors.

[dantman]

Having paper-styles sit all this using material design violating and potentially design ruining opaque text just because a subgroup believes the small performance difference is worth it is rather annoying.

Polymer/paper-styles use css variables. Can we at least have an extra file we can import that will just override the opaque colors with rgba colors. Then all those of us who have a problem with the opaque colors can just add an import for that in our project.