An idea just came to me for making color.module a little more straight forward and flexible for themers.

Here's how it works right now. And my proposed changes are this..

There's an option to set in comments to prevent color.module from changing rule sets in the current implementation. I think it would be more flexible if we could do the reverse of this and to explicitly *define* multiple chunks with comments. Based on the data within the comment, color.module should read that data and supply an extra color for the scheme. Anything not defined should be ignored except for relinking images.

For example:

/* @group colormatch[regions | #ff0033 | All block regions to color. ] */
.side-left, .side-right {
  background-color: #ccff00;
}
.side-left .block .title {
  color: #ffff00;
}
/* @end */

Have a predefined key such as "colormatch" so color.module picks it up and parses out the data following it. "regions" would be the name of the color, hex color for the base color so it can do its calculations and the description to present in the color form.

Once this is set, it basically defines *one* color of the whole scheme but it only affects the style rules defined in the comment. Let themers define as many or little as they wish instead of the hard coded 5 colors. It should do the color transformations the way the "base" colors work right now -relative color shifts. This way, us themers will not have to manage every single instance of a color inside the style sheet.

When the color picker is presented, it should parse through the style sheet and dynamically generate each form field for picking colors.

This would make it general enough for themers to define any part of their style sheets for color changes and they have more control on which rulesets it is affecting. The theme .info file should be able to define which styles to affect also. "color[all][] = mystyle.css"

With this in place, the color.inc file will not have to define a default set of colors --since they are defined in the style sheet. All that's needed from color.inc are the alternate color schemes.

For any gradient colors, it can be defined by setting one of the default colors set in the style sheet from color.inc.

I think this would be a big improvement for 2 reasons. The way the colors are affected is global and each color in the scheme treat the color changes differently. Localizing then treating each how each color is converted only a single way makes it easier to understand.

I can't code this myself but I'll be sure to play around with it. Any feedback would be appreciated.

Comments

hass’s picture

Subscribe

tstoeckler’s picture

Version: 7.x-dev » 8.x-dev

Bump.
I know color module got some overhaul in Drupal 7 and I tried to check the changes to see if this is still a valid issue. But there seems to be absolutely no documentation on that change on drupal.org and I can't be bothered to grep the git log right now.
So, just bump. :)

markhalliwell’s picture

Status: Active » Closed (duplicate)