I would step away from using colours as names – if you do, for whatever reason, decided 'blue should be green', you have to do a mass find / replace of your whole project and hope you didn't break anything.
The way I've changed to working is to name them 'brand-colour', 'brand-highlight' and 'brand-shadow'. You can name them anything you want, but when it comes down to changing orange to yellow, I only have to change the variable in one place to change the whole project.
Yeah I get what you mean, in work I use accent, primary & secondary as my colour names but on personal projects I tend to use their actual names. It is frustrating if there is a change and you do have to do a mass find & replace, it defeats the purpose really.
Reading through everyones comments on this thread though I've thought of a better way to word and present the post, along with additional features to be included in the map. Will have to do a write up in the new year.
I've recently been using this tool to give colours a name in the map. I find it's really useful when you have more than one shade of a colour in the brand set. So - for example if there's two shades of blue in the brand it's much easier to reference them as 'ocean' and 'cornflower'.
It's helpful for brand colours - but I also find it helpful for grays - that way you don't have such a problem when you need to insert a new gray between gray-light and gray-lighter :)
Interesting idea, i'll have to look into this a bit more. It can be annoying at times working with different shades of the one colour - this may well be a good solution to the problem :)
I also use similar kind of SASS management for Palette, Typography and Viewports. I am using it for the last couple of years. And still it's very handy for me to manage and write. Here is the link samagri. This article points out a new option for my module to have a light-dark specifier. Good One. Thank's Conor!!.
Hi Jaison, thanks for the comment. I'm not sure about using a mixin for my colours though, seems like that is abstracting away too much from writing CSS, but whatever works for you I suppose :). I like the approach for your media queries, something I haven't really looked into yet, at present I am just writing them when I need them. For fonts, I have moved to an @extend with the names 'heading', 'sub-heading', and 'base', and then the relevant code inside. Feel again though that could be improved
I feel like you should also give credit to the original article from Erskine Design : http://erskinedesign.com/blog/friendlier-colour-names-sass-maps/
Yeah I probably should have actually, my bad. Didn't actually realise my article was broke down like his (stumbled across his months ago) when discussing how it works. Doesn't look great on my part now that he hasn't been referenced :-/
Will sort later
Not to worry chap!
What do you feel is the added value of using a Sass map function instead of variables? You could easily just do:
$blue: blue; $blue-dark: darken($blue, 10); $blue -light: lighten($blue, 10);
Which would mean that don't have to write a full function to return this while writing CSS, like this:
To be honest that is the way I used to do it. I'm not a fan of using variables in my Sass however, so I figured creating a function and writing it like so would make my Sass more readable. Whilst this might seem overkill to some, I've found it a nice way to do it.
Also, if someone takes over a project i'm working on and I have my colour palette managed that way, it should be easy for them to read through, whereas if its a bunch of variables its may be harder to follow.
So when saying you "found a nice way do do it", you mean you "read an article by Erskine Design and copied their way".
Why are you not a fan of using variables? This does not answer my question at all. I still do not see any strong arguments for your setup for using a function. I think that properly commenting or indenting variables is just as readable, or maybe even easier to read, than just a color.
The real value in saving colors in a map function is to be able to loop through them: http://thesassway.com/intermediate/if-for-each-while#each
Each to their own then isn't it Wes, you like variables, I like functions. That's the joy of working on the web, there are many ways in which we can write our code/markup.
To your point about copying, yes I "found a way nice way to do it", I never said I came up with the idea. I regret that I did not acknowledge Erskine in my post when it first went which has now been rectified. I'm being honest when I say this next part whether you believe it or not thats up to you - I read their post months ago and implemented his suggestions into my workflow - I did not once refer to his post when I was writing my own (for the main reason being I couldn't remember where I first read it).
Finally, yes I agree that being able to loop is the best use of maps - this is something I have implemented as well and was planning on writing as a follow up post - github.com/conormcafee/conormcafee.github.io/.
Yes, we can all have our own way of doing things, this was not my point.
My question, in response to your article, was: "What do you feel is the added value of using a Sass map function instead of variables?"
Your answer was: "I'm not a fan of using variables in my Sass.", which does not give any arguments as to why you like it better, and I'd like to learn what your motives are for changing from variables to functions.
I also said:
"Also, if someone takes over a project i'm working on and I have my colour palette managed that way, it should be easy for them to read through, whereas if its a bunch of variables its may be harder to follow."
In other words, I feel the structure of a map is easier to follow for myself and those who inherit my work/files.
Thats why I prefer them over variables
Real question: how often after initial setup do brand colors really change? Not trying to be a toot here, as I scope all my colors out as well, but I just realized I've never had to go back and massively update them (a common trope when talking about setting up colors like this).
Yeah it is something that rarely you do have to go back and change. The only time I would make a drastic change would be the times i'm designing in the browser - but most of the time I do work with a set of colours that doesn't change.
I guess for me, its the structure more so than the ability to change a colour that appeals to me.
Nice to see others getting on board with this concept of using functions over global variables. I've found it helps keep colours nicely organized and avoids confusion if a variable is accidentally overridden.
For those looking to give this setup a shot, I've created a library for managing colours as well as fonts that might be helpful. It follows what Conor has outlined very closely, with a few extra features. https://github.com/jaradlight/flask
That looks like a pretty good setup Jared, will have to look in detail at it later when I'm back at my desk