Live data from Hacker News

Building your color palette

refactoringui.com

111–118 of 118 posts

Re: Building your color palette

#111

Earlier quoted context omitted.

I'm happy to give them the benefit of the doubt, and I think many colour pickers wanted to do the right thing. HSL or HSV was a step up from RGB, so it made sense to use it to derive other colours quickly. Because if you're an underpaid freelance developer, the primary colour is usually set by the client, but they usually son't have a full colour scheme. Using a colour wheel based tool gave good enough results fast.…

> If you need them to "look good", well that's art, not science. I'm not so much interested in "look good" but in "look pleasing or harmonious together" and I think that's a question science might have an answer to. It's no coincidence that the palette generators borrow musical jargon. In music the definitions of minor second and perfect octave are completely uncontroversial. That these two intervals have different m…

> we call them dissonance and consonance, is uncontroversial too

haha, right... but only for western music. compare it to e.g. Gamelan or throat/overtone singing. babies to have some concept of pitch, but mostly what sounds good is very much cultural and not "scientific" at all (good post on this: https://blog.nationalgeographic.org/2013/11/12/the-emotional...)

Re: Building your color palette

#112
post #61

Earlier quoted context omitted.

I'm happy to give them the benefit of the doubt, and I think many colour pickers wanted to do the right thing. HSL or HSV was a step up from RGB, so it made sense to use it to derive other colours quickly. Because if you're an underpaid freelance developer, the primary colour is usually set by the client, but they usually son't have a full colour scheme. Using a colour wheel based tool gave good enough results fast.…

> Not only are perceptual uniform models like CIE Lab*, and the derived CIELCh or CIEHLC mindbending to understand and code Conversion from srgb to lab and back (through xyz) is a handful of functions, all under a dozen lines of javascript. Lab to lch and back are a pair of functions, about two lines of code each. If you're implementing a user interface with sliders, you might also want to clamp the values to avoid p…

I should have phrased it better. Teenage me struggled, but I haven't attempted it since. Having said that, HSL/HSV worked well enough, and monitors now have better colour accuracy and wider colour gamut. Back then, people were still using "web-safe" colours.

Re: Building your color palette

#113
post #12

Take this one step further and build the color palette into your stylesheets. If you're using Sass you can setup something like: $palettes: ( blue: ( lightest: hsl(201, 75%, 66%), lighter: hsl(201, 75%, 61%), light: hsl(201, 75%, 56%), base: hsl(201, 75%, 51%), dark: hsl(201, 75%, 46%), darker: hsl(201, 75%, 41%), darkest: hsl(201, 75%, 36%) ), red: (...), gray: (...) ) @function palette($palette, $tone: 'base') { @r…

> background-color: palette(blue, "light") Having never used Sass, this syntax strikes me as odd. Is there a CSS pre-processor similar to Sass but where you would instead write it as “background-color: palette.blue.light”?

I haven't used it in a number of years, but Stylus apparently lets you access hashes[0] using dots:

  palette = {
    blue: {
      light: hsl(201, 75%, 56%)
      base: hsl(201, 75%, 51%)
      dark: hsl(201, 75%, 46%)
    }
  }
  
  palette.blue.light
  // => hsl(201, 75%, 56%)
It was a fun preprocessor, even if you could go overboard with it (for instance, dropping colons). I used it in a few node projects, but didn't do much beyond that because it never really took off like Sass. Sass is, well, everywhere. Stylus, on the other hand, appears to be either dead or close enough to it. While I've got a list of issues with Sass--mainly because I prefer the SASS syntax over SCSS--none of them are dealbreakers.

0. http://stylus-lang.com/docs/hashes.html

Re: Building your color palette

#114
post #66

Earlier quoted context omitted.

More than you ever wanted to know, in one well-illustrated blog post: http://jamie-wong.com/post/color/

That's awesome. It makes me think, though, that we could do a lot better than RGB given accurate values for actual human cone sensitivity and better subpixel colors. We should be able to get a digital gamut that fully spans the visible spectrum.

Yes we could get much better results with more primaries in our displays. It would take some fancier digital signal processing, and more importantly would only be especially useful for images designed with the wider gamut in mind (or potentially even multispectral images), but is possible using current technology, and probably not impossibly expensive.

Personally I would love to see displays made grids of hexagonal pixels, and maybe 7 primaries. Since almost every image that goes to displays today already needs to be rescaled at runtime, the processing shouldn’t need to be impossibly much more expensive than current square-grid resampling.

I would also love to see digital camera sensors with more primaries in a better pixel arrangement.

Re: Building your color palette

#115
post #62

Earlier quoted context omitted.

> background-color: palette(blue, "light") Having never used Sass, this syntax strikes me as odd. Is there a CSS pre-processor similar to Sass but where you would instead write it as “background-color: palette.blue.light”?

You can use CSS variables, no preprocessor necessary for newer browsers: :root { --palette-blue-light: blue; } background-color: var(--palette-blue-light);

Great suggestion, but due to extremely poor support [0], it might be best to use a polyfill [1]

[0] https://caniuse.com/#feat=css-variables [1] https://github.com/aaronbarker/css-variables-polyfill (or https://github.com/jhildenbiddle/css-vars-ponyfill)

Personally, I don't like forcing JS to make things render properly on the client, but it depends on the project whether it's acceptable or not.

However, it kind of defeats the purpose, because if you're willing to use a polyfill, then you may as well use sass or less as a solution anyway (and get a range of benefits that they provide).

Re: Building your color palette

#116
post #74

Earlier quoted context omitted.

> Pink is not "light red". No adjustment of the saturation of red will ever make it pink. Can you tell us what you think one has to do with the other?

Pink is the hue between purple and red. You can't just saturate red, you also have to add a slight bit of blue. This is pink: https://static1.squarespace.com/static/53cdd3f3e4b09b69bef6e... You can't adjust the saturation of that color to make it red, just a lighter shade of pink. There are pink colors that are closer to red than to purple, but pink is a different part of the color space than red is. If you see the s…

Up until the last few decades, English speakers would not consider the color in your link to be “pink”. “Pink” was another word for “light red” (not the name of a hue), named after a flower that looks something like https://www.stauden-stade.de/img/artikel/full/823.jpg

“Hot pink” is a creation of the fashion industry / marketers from the 1980s (or maybe 70s?).

If you want to be unambiguous, you should call the hue of your link purplish red or similar. You could also use a word like fuchsia (named after a different flower) or magenta (a purplish red ink used in 4-color CMYK printing).

Re: Building your color palette

#117

Earlier quoted context omitted.

That's awesome. It makes me think, though, that we could do a lot better than RGB given accurate values for actual human cone sensitivity and better subpixel colors. We should be able to get a digital gamut that fully spans the visible spectrum.

Yes we could get much better results with more primaries in our displays. It would take some fancier digital signal processing, and more importantly would only be especially useful for images designed with the wider gamut in mind (or potentially even multispectral images), but is possible using current technology, and probably not impossibly expensive. Personally I would love to see displays made grids of hexagonal p…

7 seems like overkill, but ok. :D Is that helpful for being able to display the full gamut of visible color more than 4 primaries, or even just 3 that are closer aligned to our eyes?

Re: Building your color palette

#118

Earlier quoted context omitted.

Yes we could get much better results with more primaries in our displays. It would take some fancier digital signal processing, and more importantly would only be especially useful for images designed with the wider gamut in mind (or potentially even multispectral images), but is possible using current technology, and probably not impossibly expensive. Personally I would love to see displays made grids of hexagonal p…

7 seems like overkill, but ok. :D Is that helpful for being able to display the full gamut of visible color more than 4 primaries, or even just 3 that are closer aligned to our eyes?

I picked 7 because it works nicely with hexagonal pixels. :-)

But the primaries can be relatively close together in color. It’s fine if we have e.g. 2 reds, 2 blues, and 3 greens instead of 1 of each.

Or for an LCD, some of them could be broader-spectrum primaries which were brighter but less colorful, while others could be more intense narrow-spectrum primaries. This would make the display more color accurate for various observers (more robust against “observer metamerism”), and would make the display overall brighter for the same intensity of backlight.

Or I dunno.. I’m not an expert in display technology, I’m sure the engineers could come up with many ideas.

Post reply on HN