Kleuren in CSS variablen

[StefanJanssen]

Ik zou persoonlijk graag zien dat de kleuren die tweakers gebruikt door middel van css variabelen gedaan worden.
De voordelen hiervan zijn het makkelijker maken voor de community custom styles te maken die daarnaast ook langer blijven werken.

Browser Support
https://caniuse.com/#feat=css-variables

Zoals je hier kan zien ondersteunen alle browsers, van welke je nog updates kan verwachten tenminste, de functionaliteit.

Ondanks het door de gehele codebase vervangen moet worden verwacht ik dat de benodigde tijd voor implementatie redelijk mee kan vallen als er nu in de LESS (daar draait tweakers op geloof ik?) ook variabelen voor worden gebruikt.

[Hahn]

StefanJanssen schreef op dinsdag 19 maart 2019 @ 17:48:

Zoals je hier kan zien ondersteunen alle browsers, van welke je nog updates kan verwachten tenminste, de functionaliteit.

Dit vind ik een beetje een makkelijke manier van wegwuiven dat IE11 het niet ondersteunt, terwijl die een groter aandeel heeft dan Edge en bijna net zo groot als de laatste paar versies van Firefox bij elkaar.

[ Voor 9% gewijzigd door Hahn op 19-03-2019 17:54 ]

[StefanJanssen]

Hahn schreef op dinsdag 19 maart 2019 @ 17:52:
[...]

Dit vind ik een beetje een makkelijke manier van wegwuiven dat IE11 het niet ondersteunt, terwijl die bijna net zo'n groot aandeel heeft als Edge of Firefox.

Is dat ook zo onder tweakers?
Moet je als tech site willen dat je geen nieuwe technieken kan gebruiken omdat je browsers wilt ondersteunen die door de fabrikant niet meer ondersteunt worden?

En daarnaast zit er binnen CSS ook nog een fallback waardoor er op IE niks kapot zal gaan al mist deze dan wel de functionaliteit voor makkelijker themes maken.

[Hahn]

StefanJanssen schreef op dinsdag 19 maart 2019 @ 17:58:
[...]

Is dat ook zo onder tweakers?

Dat weten we allebei niet, maar aangezien jij Can I Use als argument aandraagt, doe ik dat ook

Moet je als tech site willen dat je geen nieuwe technieken kan gebruiken omdat je browsers wilt ondersteunen die door de fabrikant niet meer ondersteunt worden?

Dat lijkt me vooral afhangen van hoe goed die nieuwe technieken al dan niet ondersteund worden.

2% van je bezoekers benadelen kan best wel wat centjes schelen uiteindelijk.

En daarnaast zit er binnen CSS ook nog een fallback waardoor er op IE niks kapot zal gaan al mist deze dan wel de functionaliteit voor makkelijker themes maken.

Ik vind het een leuke feature, maar ik gok dat er hooguit een paar honderd mensen zijn die custom styles gebruiken. Want het is best wel een die-hard functionaliteit waar je wel een beetje kennis voor nodig hebt om te gebruiken.

Mogelijk dat ik er compleet naast zit met hoeveel mensen custom styles gebruiken, als iemand er data over heeft, hoor ik het graag. Ik ben heel benieuwd hoeveel mensen het gebruiken

Waarmee ik overigens niet zeg dat het een slecht idee is, of dat Tweakers het niet zou moeten doen (daar ga ik sowieso niet over). Ik wou enkel wat nuance toevoegen.

[ Voor 6% gewijzigd door Hahn op 19-03-2019 18:08 ]

[StefanJanssen]

Hahn schreef op dinsdag 19 maart 2019 @ 18:02:
Ik vind het een leuke feature, maar ik gok dat er hooguit een paar honderd mensen zijn die custom styles gebruiken. Want het is best wel een die-hard functionaliteit waar je wel een beetje kennis voor nodig hebt om te gebruiken.

Mogelijk dat ik er compleet naast zit met hoeveel mensen custom styles gebruiken, als iemand er data over heeft, hoor ik het graag. Ik ben heel benieuwd hoeveel mensen het gebruiken

Als je kijkt naar het aantal topics over dark modes en dergelijke verwacht ik zelf dat het een gewenste feature is. Ik kijk nu al een tijdje naar een goede darkmode maar veel Tweakers updates breekt er wel iets in die designs, iets wat mensen dus ook wel afschrikt van dergelijke themes te maken (dat zeg ik dan weer uit eigen ervaring).

Daarnaast heb je er nou niet echt "kennis" voor nodig.
bv: Tweakers heeft onderstaande CSS staan (hier heb ik geen fallbacks in toegevoegd), nu ziet alles er hetzelfde uit als voorheen.

code:

#menubar{
  background-color: var(--tweakers-red-dark);
  background-image: linear-gradient(to bottom, var(--tweakers-red-light),  var(--tweakers-red-dark) 68px);
  background-repeat: no-repeat;
}
:root{
  --tweakers-red-dark: #9a0e36;
  --tweakers-red-light: #a41e39;
}

Als ik nu via mijn profiel custom CSS injecteer zoals hieronder is de rode balk opeens veranderd naar een blauwe(?) balk.

code:

:root{
  --tweakers-red-dark: #0F4D99;
  --tweakers-red-light: #2A5C99;
}

Maar laten we inderdaad maar eens kijken wat men vindt

[Marber]

Please niet de support voor ie11 droppen; sommige zitten hieraan vast zonder dat ze hier wat aan kunnen doen...

[Hahn]

StefanJanssen schreef op dinsdag 19 maart 2019 @ 18:23:
[...]

Als je kijkt naar het aantal topics over dark modes en dergelijke verwacht ik zelf dat het een gewenste feature is.

Oh het zal zeker een gewenste feature zijn. Door een kleine groep. Als je al die topics over custom styles bekijkt, dan zal je misschien enkele tientallen mensen erin zien posten, maar ik betwijfel ten zeerste dat het er vele honderden zullen zijn

Overigens is er een groot verschil tussen mensen die custom styles op Tweakers gebruiken, en mensen die dark mode aanzetten in bijvoorbeeld Android. Hebben we het over hetzelfde?

Daarnaast heb je er nou niet echt "kennis" voor nodig.
bv: Tweakers heeft onderstaande CSS staan (hier heb ik geen fallbacks in toegevoegd), nu ziet alles er hetzelfde uit als voorheen.

CSS is misschien wel één van de makkelijkste vormen van code, maar dat maakt niet per se dat iemand zonder enige kennis ermee overweg kan.

Mijn ouders snappen na 5 keer uitleggen nog steeds niet eens wat een 'browser' is, en hebben moeite om in Gmail te komen zonder dat ik erbij ben. Als je dat als basis ('geen kennis voor nodig') neemt, dan is CSS van een heel ander niveau

[ Voor 7% gewijzigd door Hahn op 19-03-2019 18:37 ]

[Hero of Time]

Ik wist niet dat CSS ondertussen zonder externe middelen zoals LESS met variabelen kon werken. Dat was iets wat ik nog in mijn eigen custom css wilde verwerken, want 10x een kleur opgeven en bij de 11e keer vergeten wat de waarde nou precies ook weer was is wel vervelend. Een hele lijst aan variabelen maken zal het beheren van custom css een stuk makkelijker maken.

[Yorinn]

StefanJanssen schreef op dinsdag 19 maart 2019 @ 17:58:
[...]

Is dat ook zo onder tweakers?
Moet je als tech site willen dat je geen nieuwe technieken kan gebruiken omdat je browsers wilt ondersteunen die door de fabrikant niet meer ondersteunt worden?

En daarnaast zit er binnen CSS ook nog een fallback waardoor er op IE niks kapot zal gaan al mist deze dan wel de functionaliteit voor makkelijker themes maken.

Dit is ook zo onder tweakers, ja. Zie de derde grafiek in reviews: Een gelukkig 2019: Tweakers kijkt weer terug in cijfers bijvoorbeeld. Internet Explorer heeft 3,8% terwijl Edge 'maar' 3,5% van de bezoekers heeft gebruikt.

[crisp]

We gebruiken SASS, geen LESS

IE11 kunnen we helaas nog niet negeren, en om alleen voor die browser alle *-color rules te dupliceren vind ik eigenlijk wel wat ver gaan.

Voor gradients gebruiken we overigens lighten/darken in plaats van een aparte kleur, dus dat gaat je ook niet helpen.

Overigens kan je in custom css natuurlijk prima zelf variabelen declareren en gebruiken

[Hero of Time]

crisp schreef op dinsdag 19 maart 2019 @ 21:39:
We gebruiken SASS, geen LESS

Dat was de techniek waar ik aan dacht, maar niet op kon komen!

IE11 kunnen we helaas nog niet negeren, en om alleen voor die browser alle *-color rules te dupliceren vind ik eigenlijk wel wat ver gaan.

Beetje flauw om dit te zeggen, als jullie al 3 regels gebruiken voor een simpele kleurdefinitie. Namelijk een algemene, een mozilla variant en een webkit variant. Met randen zie ik ook dubbele regels met de webkit specifieke zaken. Terwijl zowel de webkit engine (de browser die ik gebruik maakt gebruik van de QtWebKit engine) als de Gecko engine van Mozilla kunnen prima overweg met de non-specifieke ruleset.

Ik vind het persoonlijk erg jammer en lichtelijk hypocriet van browserbouwers om eigen 'tags' voor CSS regels te maken. En ontwikkelaars zijn semi-verplicht om hier aan mee te werken om hun bezoekers maar een degelijke weergave voor te schotelen.

[crisp]

Hero of Time schreef op dinsdag 19 maart 2019 @ 21:56:

[...]

Beetje flauw om dit te zeggen, als jullie al 3 regels gebruiken voor een simpele kleurdefinitie. Namelijk een algemene, een mozilla variant en een webkit variant. Met randen zie ik ook dubbele regels met de webkit specifieke zaken. Terwijl zowel de webkit engine (de browser die ik gebruik maakt gebruik van de QtWebKit engine) als de Gecko engine van Mozilla kunnen prima overweg met de non-specifieke ruleset.

Ik denk dat we een stuk meer gewone *-color rules hebben dan gradients Het wegwerken van inmiddels overbodige vendor-prefixed properties staat overigens (weer) op mijn ToDo...

Ik vind het persoonlijk erg jammer en lichtelijk hypocriet van browserbouwers om eigen 'tags' voor CSS regels te maken. En ontwikkelaars zijn semi-verplicht om hier aan mee te werken om hun bezoekers maar een degelijke weergave voor te schotelen.

Het is een logische manier om experimentele features die nog aan verandering onderhevig zijn toch beschikbaar te maken. Het wordt pas problematisch als het lang duurt voordat de standaardisatie is afgerond en browservendors deze hebben geimplementeerd zonder prefix. Ik heb het gevoel dat dat probleem overigens steeds minder speelt aangezien standaardisatie en implementatie van nieuwe features nu veel vlotter lijkt te gaan. Het verdwijnen van Trident en EdgeHTML zal uiteindelijk ook mee gaan helpen op dat vlak (maar is wel een verarming van de browserecologie).

[Hero of Time]

crisp schreef op dinsdag 19 maart 2019 @ 22:16:
[...]

Ik denk dat we een stuk meer gewone *-color rules hebben dan gradients Het wegwerken van inmiddels overbodige vendor-prefixed properties staat overigens (weer) op mijn ToDo...

Het verdwijnen van Trident en EdgeHTML zal uiteindelijk ook mee gaan helpen op dat vlak (maar is wel een verarming van de browserecologie).

offtopic:
IMO is het verdwijnen van de Trident engine niet een enorm gemis. Edge met z'n EdgeHTML heb ik te weinig ervaring mee, aangezien ik geen W10 draai. Vind het wel jammer dat MS zwicht en overstapt op Blink. De grootste verarming was het verlies van Presto, de engine van Opera t/m versie 12. Deze was echt goed in elkaar gezet en fouten in je code werden ook gewoon keihard zichtbaar. Ik blijf het enorm jammer vinden dat ze zijn overgelopen naar Blink. Had niet het idee dat de technical debt zo veel was.

[crisp]

offtopic:
Trident is inderdaad gewoon een verouderde engine, net als Presto dat was

[StefanJanssen]

crisp schreef op dinsdag 19 maart 2019 @ 21:39:
We gebruiken SASS, geen LESS

IE11 kunnen we helaas nog niet negeren, en om alleen voor die browser alle *-color rules te dupliceren vind ik eigenlijk wel wat ver gaan.

Voor gradients gebruiken we overigens lighten/darken in plaats van een aparte kleur, dus dat gaat je ook niet helpen.

Overigens kan je in custom css natuurlijk prima zelf variabelen declareren en gebruiken

Gelukkig zijn er, net als automatische vendor prefixers ook tools voor om de kleuren automatisch toe te voegen als fallback.

Het probleem van je eigen variabelen in css toevoegen lost het probleem van "elke UI update breekt wel iets in de stylesheet" niet op natuurlijk.

[crisp]

StefanJanssen schreef op dinsdag 19 maart 2019 @ 23:56:
[...]

Gelukkig zijn er, net als automatische vendor prefixers ook tools voor om de kleuren automatisch toe te voegen als fallback.

Het gaat mij meer om de onnodige vergroting van het aantal css rules. Het is lastig om de impact daarvan op performance te kwantificeren, maar CSS is sowieso lastig om 'in toom' te houden qua hoeveelheid met een snel veranderende codebase en incremental updates (ongebruikte CSS opsporen blijft een lastig iets)...

Het probleem van je eigen variabelen in css toevoegen lost het probleem van "elke UI update breekt wel iets in de stylesheet" niet op natuurlijk.

Hoe lost het gebruik van CSS variabelen dat dan wel op? Ik denk dat de meeste breaking changes niet in kleurgebruik zitten

Overigens voor de beeldvorming: we hebben op dit moment 131 SASS variabelen met betrekking tot kleurdefinities die een pallet van 24 basiskleuren en 22 grijswaarden gebruikt. Dat ziet er dan ongeveer zo uit:

Sass:

/* Text colors */
$text-color: $black;
$text-color-inverted: $white;
$text-menu-color: $grey-90;
$text-light-color: $grey-75;
$text-label-color: $grey-50;
$text-description-color: $grey-40;
$text-dark-color: $grey-25;
$text-dark-menu-color: $grey-20;
$text-highlight-color: $darkblue;
$text-error-color: $color-cardinal;
$text-error-dark-background-color: $color-wild-watermelon;
$text-notice-color: $color-orange;
$text-approved-color: $color-green;
$text-online-color: $color-bahia;
$text-tagcloud-color: $color-lavender;
$text-info-color: $color-pacific-blue;
$text-karma-score-color: $color-cardinal;
$text-sponsored-color: $color-grenadier;

Nu wil het geval dat we ook nog een flink stuk legacy hebben waar deze variabelen niet of mogelijk niet helemaal correct worden gebruikt. Puur het herdefinieren van variabelen geeft dus geen garantie op een goed resultaat.

Verder zijn er maar ongeveer 700 mensen die custom CSS gebruiken, en ik gok dat maar een heel klein deel daarvan CSS gebruikt voor een echt compleet ander color-theme (en dat zal dan meestal een soort van 'dark mode' zijn).

[ Voor 47% gewijzigd door crisp op 20-03-2019 08:30 ]

[ACM]

crisp schreef op woensdag 20 maart 2019 @ 00:04:
Hoe lost het gebruik van CSS variabelen dat dan wel op?

Als je een bepaalde selector alleen had om een specifieke kleur te veranderen. Dan kan ik me voorstellen dat het robuuster is om met variabelen een variabele-waarde te overschrijven, ipv de hele selector.

Als wij dan iets aan de css-structuur veranderen, verschuift die variabele hopelijk gewoon mee.

Maar tegelijkertijd zullen er vast weer nieuwe klachten komen. Want als wij een variabele op een andere plek gaan gebruiken, dan kan dat natuurlijk ook een onbedoelde effect opleveren voor die gebruiker. Of als we een variabele van naam veranderen, of er twee samenvoegen, of...

Wat mij betreft gaan we css-variabelen, als we ze gaan gebruiken, dan gebruiken met als doel ons eigen werk makkelijker te maken danwel om betere* css te krijgen. Maar dat het deze specifieke wens dan vervult is dan eigenlijk vooral een mooie bijkomstigheid.

* Beter kan zijn makkelijker onderhoudbaar, compacter, efficienter, etc.