[SASS/LESS] best practice: kleuren beheren

[PdeBie]

Hoi allemaal,

ik ben wat aan het spelen met SASS (maar hetzelfde is ook toepasbaar in LESS) en zit een beetje te vogelen met kleuren. Hoe is dit nu het makkelijkste te beheren in een scss file.

Je wilt de naamgeving niet zo hebben dat je bijvoorbeeld letterlijk kleurnamen gebruikt. Dus geen:

SCSS:

$red: #FF0000;
$blue: #0000FF;
[...]

Dus ik zat meer te denken aan:

SCSS:

$primary-color: #000000;
$background-color: #FEFEFE;
$highlight: #00FFFF;
[...]

Maar ook dat lijkt me op den duur lastig onderhoudbaar. Bijvoorbeeld wanneer je meerdere kleuren "sets" gebruikt. Ik zou de footer van de website bijvoorbeeld anders kleuren dan de content van de website.

Dus hoe pakken jullie dit aan?

[ Voor 11% gewijzigd door PdeBie op 06-01-2016 14:56 ]

[jmxd]

Tenzij je bepaalde kleuren regelmatig veranderd (waardoor $blue ineens geel is) vind ik het benoemen van kleuren op die manier tot nu toe nog de beste benadering.

Mijn variabelen zien er vaak zo uit:

SCSS:

$blue-base:
$blue-light:
$blue-x-light:
$blue-dark:
$blue-x-dark:

Waarom wil je dit niet, het is namelijk imo de meest logische en duidelijkste aanpak die ook voor anderen makkelijk te begrijpen is.

Je kan hier naartoe gaan en je kleur invoeren om een "fancy" naam te genereren, bijvoorbeeld "astronaut-blue"

[PdeBie]

Nou, waar ik meer aan zet te denken. Stel je hebt een website met 3 thema's. En die kan de gebruiker zelf kiezen. Kan je dan niet beter bijvoorbeeld het thema-nummer opnemen?

SCSS:

$theme1-header: #FF0000;
$theme1-footer: #0000FF;
$theme1-main: #FFF;

Ik ben compleet newbie op dit gebied overigens hoor. Dus als ik echt totaal verkeerd denk hoor ik het graag

[RobIII]

Twylight schreef op woensdag 06 januari 2016 @ 15:13:
Tenzij je bepaalde kleuren regelmatig veranderd (waardoor $blue ineens geel is) vind ik het benoemen van kleuren op die manier tot nu toe nog de beste benadering.

Het hele idee om een waarde in een variabele(naam) te stoppen is nou juist dat je later bij een redesign o.i.d. eens wat kleurtjes kunt omgooien. Dan krijg je, in jouw geval: $red = #00FFFF; Dat is net zoiets als code die begint als const int three = 3 en na een paar maanden gerefactored wordt naar const int three = 7. Waarom niet gewoon const int maxplayers = 3? Dat kun je altijd veilig refactoren naar const int maxplayers = 7 (los van de inhoudelijke wijziging(en) die dat met zich mee zou brengen om meer spelers te ondersteunen natuurlijk ).

Het is juist ontzettend fout om je variabelen zo te noemen. Hoe dan wel? Precies zoals TS aangeeft: primary-color, background-color, highlight etc. En ja, dan is naming niet altijd even makkelijk. Maar je zou dan iets als content-primary-color en footer-primary-color kunnen gebruiken om zo bijv. onderscheid te maken tussen verschillende componenten op je pagina.

Als je werkt met verschillende theme's dan zou ik die variabelen naar een theme1.less, theme2.less etc. toe trekken en afhankelijk van de gekozen theme includen. Net zoals bootstrap dat bijvoorbeeld doet met variables.less en bootstrap.less alleen dan met variables-themeX.less / bootstrap-themeX.less, variables-themeY.less / bootstrap-themeY bijvoorbeeld. Uiteindelijk zorg je gewoon dat je voor elke theme een (complete) CSS genereert op basis van de less (of sass) en dan is 't een kwestie van naar themeX.css of themeY.css verwijzen om een complete andere theme te gebruiken.

---

Je zou hooguit nog een 'hybride' vorm kunnen gebruiken:

code:

$red = #FF0000;
$green = #FF0000;
$grey = #999999;

$header-background: $red;
$main-background: $green;
$main-primary-color: $red;
$footer-background: $grey;

In geval van een rebranding zou je dan zoiets kunnen doen:

code:

$red = #FF0000;
$green = #00FF00;
$grey = #999999;
$blue = #0000FF;  //New

$header-background: $red;  //Unchanged, still uses $red
$main-background: $green;
$main-primary-color: $blue;  //Changed
$footer-background: $grey;

Dan kun je je basispallet "herbruikbaar" in kleurnamen definiëren en bij je semantisch correct genaamde classes refereren aan de 'human friendly' kleurnaam. Maar ik zie er 't voordeel niet van en je hebt nog steeds kans dat iemand met een refactorslag doodleuk, zeg, $red de waarde #00FFFF geeft.

[ Voor 59% gewijzigd door RobIII op 06-01-2016 15:48 ]

[PdeBie]

Ja, daar zat ik dus ook mee.

Stel dat je de kleuren ineens om wilt gooien. Dan lijkt het mij handiger dat je alleen maar wat hexadecimaaltjes hoeft om te gooien i.p.v. dat je in de html overal alles aan moet passen naar andere klassen voor de divs etc.

RobIII schreef op woensdag 06 januari 2016 @ 15:23:
[...]
Als je werkt met verschillende theme's dan zou ik die variabelen naar een theme1.less, theme2.less etc. toe trekken en afhankelijk van de gekozen theme includen. Net zoals bootstrap dat bijvoorbeeld doet met variables.less en bootstrap.less alleen dan met variables-themeX.less, variables-themeY.less bijvoorbeeld.

Dus bijvoorbeeld een theme1.scss met daarin dit:

SCSS:

$header-background: #FF0000;
$main-background: #FFFFFF;
$main-primary-color: #000000;
$footer-background: #0000FF;

En dan een theme2.scss aanmaken met daarin dezelfde variabelen.

SCSS:

$header-background: <ander kleurtje>;
$main-background: <ander kleurtje>;
$main-primary-color: <ander kleurtje>;
$footer-background: <ander kleurtje>;

En theme2.scss inladen op het moment dat de gebruiker voor theme2 kiest etc.

[ Voor 68% gewijzigd door PdeBie op 06-01-2016 15:30 ]

[RobIII]

PdeBie schreef op woensdag 06 januari 2016 @ 15:24:
Dus bijvoorbeeld een theme1.scss met daarin dit:
En theme2.scss inladen op het moment dat de gebruiker voor theme2 kiest etc.

Jep.

[PdeBie]

Probleem dan is alleen dat je dus meerdere bestanden moet bijhouden op het moment dat er een variabele bij komt.
Maar goed, dat moet je ook als je $theme1-header-background doet. Dan moet je ook voor elk thema zo'n variabele aanmaken.

Voordeel ook van jouw methode is dat je heel makkelijk een thema erbij aanmaakt, omdat je gewoon een kopie kan maken van een thema-scss bestand en alleen maar wat hexadecimaaltjes hoeft aan te passen. Hmmm...Klinkt best logisch eigenlijk

[jmxd]

RobIII schreef op woensdag 06 januari 2016 @ 15:23:
[...]


Het hele idee om een waarde in een variabele(naam) te stoppen is nou juist dat je later bij een redesign o.i.d. eens wat kleurtjes kunt omgooien. Dan krijg je, in jouw geval: $red = #00FFFF; Dat is net zoiets als code die begint als const int three = 3 en na een paar maanden gerefactored wordt naar const int three = 7. Waarom niet gewoon const int maxplayers = 3? Dat kun je altijd veilig refactoren naar const int maxplayers = 7 (los van de inhoudelijke wijziging(en) die dat met zich mee zou brengen om meer spelers te ondersteunen natuurlijk ).

Het is juist ontzettend fout om je variabelen zo te noemen. Hoe dan wel? Precies zoals TS aangeeft: primary-color, background-color, hightlight etc. En ja, dan is naming niet altijd even makkelijk. Maar je zou dan iets als content-primary-color en footer-primary-color kunnen gebruiken om zo bijv. onderscheid te maken tussen verschillende componenten op je pagina.

Als je werkt met verschillende theme's dan zou ik die variabelen naar een theme1.less, theme2.less etc. toe trekken en afhankelijk van de gekozen theme includen. Net zoals bootstrap dat bijvoorbeeld doet met variables.less en bootstrap.less alleen dan met variables-themeX.less / bootstrap-themeX.less, variables-themeY.less / bootstrap-themeY bijvoorbeeld. Uiteindelijk zorg je gewoon dat je voor elke theme een (complete) CSS genereert op basis van de less (of sass) en dan is 't een kwestie van naar themeX.css of themeY.css verwijzen om een complete andere theme te gebruiken.

In mijn ervaring komt het maar zeer zelden voor dat een kleur in de gehele template ineens van blauw naar geel gaat (bijvoorbeeld). Het komt wel eens voor dat het blauw een paar tinten minder wordt maar dan is het nog steeds blauw.

Als je met verschillende templates werkt is primary een keuze maar als je dat doortrekt zit je wel ineens met een hele lijst (secondary, tertiary, etc etc) tot je er zelf ook niet meer uitkomt welke variable nou ook al weer de kleur was die je wil gebruiken.

In het geval van Tweakers zie ik geen reden waarom $tweakers-red geen goede keuze zou zijn, dat is voor iedereen direct duidelijk.

[RobIII]

Twylight schreef op woensdag 06 januari 2016 @ 15:48:
[...]
Als je met verschillende templates werkt is primary een keuze maar als je dat doortrekt zit je wel ineens met een hele lijst (secondary, tertiary, etc etc) tot je er zelf ook niet meer uitkomt welke variable nou ook al weer de kleur was die je wil gebruiken.

Als het goed is heb je sowieso hooguit een pallet van, zeg, 3 hoofdkleuren die een aanduiding a-la primary, secondary etc. verdienen. En daar kun je dan bijvoorbeeld een -dark(er), -light(er) variant van maken etc. Dan heb je, met 3 hoofdkleuren, al meteen 9 (3 + 3 dark + 3 light) of 15 varianten (3 + 3 dark + 3 darker + 3 light + 3 lighter) varianten. Dus een:

[list]
• $primary-color
• $primary-color-dark
• $primary-color-darker
• $primary-color-light
• $primary-color-lighter
• ...


Uiteraard gebruik je veel meer kleuren; je hebt dan variabelen die prima anders te namen zijn dan middels 'primary...' etc.:

code:

$error-background-color: #f2dede;
$error-text-color: #a94442;
$warning-background-color: #fcf8e3;
$warning-text-color: #8a6d3b;
$info-background-color: #d9edf7;
$info-text-color: #31708f;
...
$content-text-color: ...
$content-header-color: ...
$input-border-color: ...
...

Ik zie een 'tertiary' al niet snel gebeuren, laat staan nog (veel) verder dan dat. Ik zuig nu maar e.e.a. uit m'n duim, maar hier zie je prima voorbeelden. Daar komt nog geen secondary aan te pas.

[ Voor 57% gewijzigd door RobIII op 06-01-2016 16:13 ]

[jmxd]

een $error-text noem ik ook geen $red-text natuurlijk, en $footer-background-color is wmb veel te specifiek. In de footer class zou in dat geval gewoon een, zeg, $gray-x-dark gebruiken. Het lijkt mij namelijk dat je de grijze kleur in de footer wel vaker gebruikt. En een $footer-background heeft misschien wel de zelfde kleur als een of andere tooltip die je op je site gebruikt. Maak je daar dan weer een nieuwe variabele voor met de zelfde waarde? Lijkt me niet helemaal de bedoeling dat je voor elk element een unieke variabele gaat zitten maken.

En of jij verschillende tinten van $gray nou met een filter bereikt of handmatig doet er niet echt toe.

Zie ook: http://erskinedesign.com/...r-colour-names-sass-maps/

[PdeBie]

Twylight schreef op woensdag 06 januari 2016 @ 16:18:
en $footer-background-color is wmb veel te specifiek.
[...]

Zie ook: http://erskinedesign.com/...r-colour-names-sass-maps/

Wat is daar te specifiek aan? Het zegt toch precies waar hij voor gebruikt wordt?


Ik zal dat artikel eens doornemen. Kijken of ik er iets van opsteek en of ik er conclusies aan kan binden.

[jmxd]

PdeBie schreef op donderdag 07 januari 2016 @ 08:56:
[...]


Wat is daar te specifiek aan? Het zegt toch precies waar hij voor gebruikt wordt?

Dat is het probleem. Een $footer-background-color lijkt mij iets wat je eenmalig gebruikt. Persoonlijk gebruik ik liever variabelen die onafhankelijk van de content bruikbaar zijn. Als je namelijk nu een andere element dezelfde kleur wil geven heb je daar weer een nieuwe variabel voor nodig.

[Barryvdh]

Twylight schreef op donderdag 07 januari 2016 @ 10:07:
[...]
Dat is het probleem. Een $footer-background-color lijkt mij iets wat je eenmalig gebruikt. Persoonlijk gebruik ik liever variabelen die onafhankelijk van de content bruikbaar zijn. Als je namelijk nu een andere element dezelfde kleur wil geven heb je daar weer een nieuwe variabel voor nodig.

Je kan toch van belangrijk naar specifiek gaan?

Je begint met wat standaard kleuren voor leesbaarheid ($tweakers-red, $tweakers-grey, $grey = .., $grey-dark=..), en je basis kleuren voor de website ($brand-primary = $tweakers-red, $brand-accent = ..) en dan kan je dat verder uitbouwen naar specifieke items, dus bijv. $footer-background-color = $grey-light, $menu-background-color = $tweakers-red), of evt. met darken/lighten die kleuren verder gebruiken.

Als je alle kleuren alleen al bij elkaar hebt staan, lijkt me dat een stuk makkelijker toch? En je hebt waarschijjnlijk maar een paar huisstijl kleuren die echt vaststaan. Dat is dan zo aangepast als je net een andere kleur rood gaat gebruiken in je logo.

Als je dan overal een bepaalde tint wil vervangen door andere grijstint, pas je alleen je $grey-lighter aan. En als je specifiek die footer background-color anders wil maken, pak je de specifiek variabele..
Beetje zoals Bootstrap dus; https://github.com/twbs/b...-dev/scss/_variables.scss

[PdeBie]

Nou ja, dat is dus ook een mogelijkheid.

Maar volgens mij is het opzetten van (S)CSS dus heel erg verschillend per ontwikkelaar. De een doet het zus de ander doet het zo. Maar echt best practices?

[Ultimation]

Ik ben een backend developer, maar zie wel in projecten waar we SASS gebruiken het volgende gebeuren;

Sass:

// Grey
$grey-D1: #2D3537;
$grey-D2: #3A414D;
$grey-D3: #596473;
$grey-M1: #585F62;
$grey-M2: #9497A5;
$grey-M3: #B0B2BC;
$grey-M4: #A2A5B0;
$grey-M5: #BEC0CA;
$grey-L1: #A6A6A6;
$grey-L2: #CCCDD3;
$grey-L3: #D9D9D9;
$grey-L4: #EBEBEB;
$grey-L5: #E7E8EB;

Deze kleurcodes D/M/L komen overeen met de huisstijl van het systeem waar we SASS toepassen.

[OkkE]

Het verschilt ook per project, sommige zijn zo simpel dat je kunt volstaan met een $color-primary en color-secondary, maar wanneer er meer variaties/variabelen nodig zijn, vind ik dit nog steeds wel een fijne manier:
.

SCSS:

$blue: #00d;
$blue-dark: #000036;
// ... etc ...
$red: #f00;
$red-light: lighten($red, 10%);
// ... etc ...



$color-headings: $blue-dark;
$color-headings-aside: $blue;

$color-text-error: $red;
$color-bg-error: $red-light;

Maar elke manier die ik tot nu toe heb geprobeerd heeft zo zijn eigen voor- en nadelen...

[MueR]

Dit is ongeveer wat ik doe:

SCSS:

$m-white: #fff;
$m-black: #000;
// .. basiskleurtjes etc ..
$m-brown: #795548;
// grijstintjes zo:
$gray: #55595c;
$gray-light: lighten($gray, 15%)

// spul wat ik gebruik
$header-bar-bg: $gray-dark;
$pagination-active-color: $m-white;
$pagination-active-bg: $brand-primary;
$pagination-active-border: $brand-primary;

Dus ik maak veel specifieke variabelen, maar ben eigenlijk veel aan het kopieren. Mocht er dan iets specifieks gewijzigd moeten worden, is het zo gedaan zonder dat ik meteen heel m'n code door hoef om te kijken waar het allemaal mis gaat

[ongewoongewoon]

Ik probeer altijd een soort kleurenwaaier samen te stellen (als deze al niet door de designer wordt aangeleverd) neer te zetten die door het hele project heen gebruikt kunnen worden. De namen refereren niet naar kleuren of specifieke elementen.

Naamgeving kan bijv zijn

code:

@base1: *kleurcode*
@secondary2: *kleurcode*

Werkt voor mij prima

[TheNephilim]

Hier gebruiken we ook gewoon @brand-primary etc. Meestal hebben we aan twee kleuren genoeg, soms zijn het er drie.

Als je @red zou gebruiken, dan gaat dat heel lang goed, tot je een keer wat kleuren moet aanpassen en de variabelen nergens meer op slaan.

[Canaria]

Ultimation schreef op donderdag 07 januari 2016 @ 11:16:
Ik ben een backend developer, maar zie wel in projecten waar we SASS gebruiken het volgende gebeuren;

Sass:

// Grey
$grey-D1: #2D3537;
$grey-D2: #3A414D;
$grey-D3: #596473;
$grey-M1: #585F62;
$grey-M2: #9497A5;
$grey-M3: #B0B2BC;
$grey-M4: #A2A5B0;
$grey-M5: #BEC0CA;
$grey-L1: #A6A6A6;
$grey-L2: #CCCDD3;
$grey-L3: #D9D9D9;
$grey-L4: #EBEBEB;
$grey-L5: #E7E8EB;

Deze kleurcodes D/M/L komen overeen met de huisstijl van het systeem waar we SASS toepassen.

Dit vind ik zelf beter dan gebruikmaken van lighten() of darken(). Ik ben nog nooit een huisstijldocument tegengekomen waarin stond dat lichtblauw 15% lichter moet zijn dan corporate-blauw, of vergelijkbaar.

Voor eigen projectjes is het lekker makkelijk als bijvoorbeeld de hoverkleur automatisch berekend wordt, maar anders werk ik altijd met absolute waarden.

[Ultimation]

Is ook gepasseerd op de huisstijl guide van het project. ;-)