johnalbin / chroma Goto Github PK

Trying out a zen 7.6 subtheme, so I wasn't sure whether to report this here or over there, but scss-lint/gulp-scss-lint seems to be choking on these lines:

// scss-lint:disable Comment
/*
#{chroma-kss-markup()}
*/

I had to run the gulp task in verbose mode and then run that output straight on the command line to track it down, the gulp error was 'internal software error'. This is the error i am seeing:

SCSSLint::Linter::SpaceBetweenParens raised unexpected error linting file /path//to/sass/style-guide/chroma-kss-markup.scss: 'undefined methodcount' for nil:NilClass'`

Here is a really strange one.

gulp-sass 2.3.1
node-sass 3.6.0
chroma 1.2.3
node 5.11.0

Sass is throwing a Segmentation Fault when the chroma-kss-markup() function is used.

I tracked it down to line 77 to 82:

        $markup: $markup
          + '<div class="#{$color-class}">'
          +   '<span class="#{$swatch-class}" style="background-color: #{$value}"></span>'
          +   '<code class="#{$variable-class}">#{$_chroma-spelling}(#{$color})</code>'
          +   ' <span class="#{$alt-text-class}">uses the #{$_chroma-spelling}:</span> '
          +   '<span class="#{$value-class}"><code>#{$value}</code>';

It seems node-sass doesn't like so many string concats being used in one line. Changing to the below allowed it to build normally.

        $markup: $markup
          + '<div class="#{$color-class}">'
          +   '<span class="#{$swatch-class}" style="background-color: #{$value}"></span><code class="#{$variable-class}">#{$_chroma-spelling}(#{$color})</code> <span class="#{$alt-text-class}">uses the #{$_chroma-spelling}:</span> <span class="#{$value-class}"><code>#{$value}</code>';

So almost certainly a strange bug in node-sass but an easy fix here.

What do you think John?

I removed a colour from the definition (or I misspelled a colour name) and I get this error:

Message:
    node_modules/chroma-sass/sass/chroma/_functions.scss
Error: The color "watermark" was not found.
        on line 170 of node_modules/chroma-sass/sass/chroma/_functions.scss
>>     @error 'The #{$_chroma-spelling} "#{$name}" was not found.';
   ----^

This does not tell me where the error was encountered - except some internal reference to the chroma code.

It would be nice if it said

"line 1234 of sass/components/yourfile.scss references colour 'watermark' but this is not defined."

or such.

I had a Ruby-based Travis integration file lying around, so I used it. But we should switch to mocha or another node.js testing framework.

http://codecondo.com/javascript-unit-testing-frameworks/

Looking at https://bugsnag.com/blog/sass-color-palettes, I realize that I need a convenience function that retrieves a list of color names from a scheme.

The color name vs. element name is described as "functional" vs. "descriptive" in http://sachagreif.com/sass-color-variables/

The API should use these more distintive terms

A key piece of Chroma's API depends on Sass functionality that is broken in libsass 3.2.5 and earlier.

Basically, Chroma requires being able to tell the difference between a color keyword like white and a string containing a color keyword like 'white'. And libsass thinks both of them are bare color keywords.

This bug in libsass is fixed, but hasn't made it to an official release yet. sass/libsass#1453

We need to test Chroma against libsass 3.3.0 after it is released.

We can already install Chroma with Gem, bower or npm. Do we add eyeglass too?

Currently, there's a hacky chroma-kss-markup() function which exports a chunk of HTML with the all the colors spit out as examples.

https://www.npmjs.com/package/sass-color-json will export a JSON object. That seems much cleaner. we should investigate. Or https://github.com/HugoGiraudel/SassyJSON Or https://github.com/ezekg/SassyExport

I'm trying to define colours using rgb instead of hex. Is this possible?

Whenever I do something like rgb(0, 0, 0) it works but when I try:

unquote('rgb(#{$color-black})')

($color-black being "0,0,0")

I get the error

Message:
    node_modules/chroma-sass/sass/chroma/_functions.scss
Error: The color "rgb(0,0,0)" was not found when adding the color "black".
        on line 401 of node_modules/chroma-sass/sass/chroma/_functions.scss
>>         @error 'The #{$_chroma-spelling} "#{$ref}" was not found when adding t
   --------^

Problem:

Currently, since the $chroma variable is a global variable, I've been adding all of my colors in a global _colors.scss file that gets imported by my _init.scss partial.

But, in reality, I've got a handful of global colors and a bunch of color names that are only used for specific components. e.g. footer-text is the text color only used in the site footer; and it depends on the global off-white color.

It would be nice to move the declaration of the component-specific color to the component's file.

If you do that now (and use the hacky chroma/kss module to output all the colors on the site by importing the _colors.scss and then using chroma-kss-markup() and chroma-kss-styles()), the style guide will only show you the global colors defined in _colors.scss and not in your individual component files. This sucks because each color in the style guide has a "Used by: some-other-color-name" section and we'd lose the ability to tell if the color is being used and by who. i.e. "Can I delete this color now because I'm no longer using it?" and "If I change this color value, which components do I need to check to ensure I don't screw anything up?"

Obviously, we'd need to solve #5 before we could fully solve this issue, but let's say #5 was fixed and our style guide shows all of our colors no matter where they are declared…

Now the issue becomes I can't tell which color names are globally declared in my _colors.scss and which are component-specific. And a developer could accidentally create a dependency on another component when they thought they were using a "safe global name". It is critical to know about dependencies because re-ordering component loading could mean that Component B would be requesting Component A's colors before Component A is loaded and defines it colors!

Solution:

Output which file a color declaration comes from in the style guide.

And, optionally, add a add-local-colors() function that defines colors that can only be retrieved from within the same file that defines the colors.

I'm not sure if either of these is possible, but it sure would be nice.

There are some funky work-arounds scattered around Chroma that should be removed once LibSass 3.3.0 is released. sass/libsass#1453

This will be a backwards-compatibility breaker, so it will force a major version tick in Chroma.

Sorry to bother you with this, but after a lenghty online research I still can't work out how Chroma's license affects the general license of a modular Sass project and the final stylesheets it produces ... and I'm about to release the project soon on GitHub!

I've created a project-documentation theme using Sass and various third party modules, including your Normalize.scss library, typey-chroma-kss fork:

https://github.com/JohnAlbin/normalize-scss/tree/master/fork-versions/typey-chroma-kss

All the Sass modules I'm using are MIT licensed, except for Chroma which is GPLv2.

I'm having some trouble figuring out how the GPLv2 lib affects the license of the project:

1. Does my Sass project need to be released under GPLv2? or can each module retain its license and I can declare my code in the project as MIT?
2. Does Chroma's GPLv2 license affect the final CSS stylesheet? ie: is the compiled css to be considered a derivative of Chroma?

I'm ok with keeping the Sass project under GPLv2, but I'd rather have the final CSS (which I'll be using/distributing separately, as a standalone file without the Sass files) under MIT license — if possible.

Thanks a lot for your precious time and help,

Tristano

When you define a color called white with:

$chroma: add-colors((
  white:       #eee,
));

you are supposed to be able to call it with color(white) or with color('white').

But color('white') is not working. Instead we're getting a Chroma error saying it can't find the 'white' color.

Many, many times you'll have one color set to another color. And, if you are about to change a specific color, it would be super handy to be able to get a list of all the other colors that will change if you change this color.

For example:

$body-text: #666;
// later in the page...
$button-text: $body-text;
$button-border: $button-text;
$more-link: $body-text;

If you were using Color Maps, it would be nice to have a function that returns a list of colors that are referencing the given color name. Something like gimme-referenced-color(body-text) would return a list ('button-text', 'more-link').

Currently, libSass has no way to access a global Sass variable from the JavaScript side.

So while libSass allows functions to be written in JS, the JS can only access the functions parameters and cannot access any global Sass properties, like variables, mixins, extends, etc.

So the only way the JavaScript side can access Chroma's variables is by explicitly passing the $chroma global variable into the Sass function.

There are open issues for this in the libSass and node-sass queues. sass/node-sass#1297 sass/libsass#1950

Until that is fixed upstream, Chroma must continue to require explicit use of the global $chroma variable in its code examples.

So I went to register Chroma on Bower now that it has a 1.0.0 release, but I got this:

$ bower register chroma [email protected]:JohnAlbin/chroma.git
? May bower anonymously report usage statistics to improve the tool over time? Yes
bower                          convert Converted [email protected]:JohnAlbin/chroma.git to git://github.com/JohnAlbin/chroma.git
bower chroma#*                 resolve git://github.com/JohnAlbin/chroma.git#*
bower chroma#*                download https://github.com/JohnAlbin/chroma/archive/1.0.0.tar.gz
bower chroma#*                 extract archive.tar.gz
bower chroma#*                resolved git://github.com/JohnAlbin/chroma.git#1.0.0
? Registering a package will make it installable via the registry (https://bower.herokuapp.com), continue? Yes
bower chroma                  register git://github.com/JohnAlbin/chroma.git
bower                       EDUPLICATE Duplicate package

It looks like @crazyrohila registered his old fork of Chroma on Bower 5 months ago. Sanjay, can you help me get the original Chroma URL registered in the Bower registry?

According to the Bower registry homepage, you can unregister your version of Chroma and I can then add it back with the proper URL. Just follow these steps:

bower login
# enter GitHub username and password
? Username:
? Password:
# unregister packages after successful login
bower unregister chroma

See http://johnalbin.github.io/chroma/

From http://blog.55minutes.com/2011/10/color-management-for-people-who-write-markup/

Wondering about those crazy color names? I got them using Color Name & Hue and Name That Color, tools that give you color names for hex codes. Now you can use “cerulean” and “azure” instead of “blue 15” and “blue 16”.
http://www.colblindor.com/color-name-hue/
http://chir.ag/projects/name-that-color/

Accidentally copied and pasted _normalize.scss into chroma's package.json. whoops.

I think the package.json should fix the compatible version for kss-node.

Something changed in kss-node that is breaking libsass for us and since it downloads the latest version everytime we do "npm install" the automated build broke without changing anything related to the theme.

Sometimes design and engineering requirements mean that we need to:

• output the colors for default color scheme and one or more additional color
  schemes into the same CSS file
• and to control which color scheme is used via a "global" CSS class name set
  on the web pages's html or body element.

For example, the .my-complexion component may output a blue text color on
most pages, but on pages with a <html class="skin-wicked-witch">, the
.my-complexion component will output a green text color.

The Skin module will help with this requirement.

Track sass/libsass#2205 and remove the work-around when the bugfix is released.

See https://www.npmjs.com/package/node-sass

Currently, compiling Chroma using Dart Sass produces these errors:

DEPRECATION WARNING: Passing a string to call() is deprecated and will be illegal
in Dart Sass 2.0.0. Use call(get-function(lighten)) instead.

node_modules/chroma-sass/sass/chroma/_internals.scss 146:11 -safe-call()

Just making a note that some many people like to manage color variations. I'm not there yet, but here's a few articles about that.

• Map of variations:
  • http://www.sitepoint.com/managing-color-values-with-sass/
  • http://www.sitepoint.com/using-sass-build-color-palettes/
• Nested colors:
  • https://bugsnag.com/blog/sass-color-palettes (Though this one could be thought of as schemes and colors)
  • https://medium.com/@ryanhavoc/clean-colour-management-with-sass-4d5e9bb4f1b2
  • http://erskinedesign.com/blog/friendlier-colour-names-sass-maps/#solving-issue-1-the-naming-of-things

Also, Scott and Mason have a Sass lib that focuses on creating variations. https://github.com/at-import/color-schemer

A map of variations looks very promising: http://www.sitepoint.com/managing-color-values-with-sass/

$chroma: add-color-variations((
  light: (
    function: lighten,
    parameters: 15%,
    // Optional tags to group color variations together.
    tags: (standard),
  ),
  shade: (
    function: mix,
    parameters: white 80%
    tags: (standard, alternate),
  ),
));

// A variation can be retrieved on the fly with color().
// Assuming the "primary" color has been added to chroma.
.rule { color: color(primary, shade); }

$chroma: add-colors((
  link: 'blue',
  link-visited: ('blue', shade),
));

It relies on the fact that the color is always the first parameter to Sass functions. http://sass-lang.com/documentation/Sass/Script/Functions.html#rgb_functions

Integration with Color Schemer would be trivial since its functions all follow the color-as-first-parameter convention. And scheme generation could be used with:

// First set various $cs-* variables. Then:
$chroma: add-colors((
  primary: cs-primary(),
  secondary: cs-secondary(),
  tertiary: cs-tertiary(),
  quadrary: cs-quadrary(),
));