Nightly builds van WebKit ondersteunen variabelen in css

De ontwikkelaars van WebKit hebben voor de laatste nightly builds code voorgesteld om css-variabelen te ondersteunen. Door het gebruik van variabelen moet css-code overzichtelijker worden en zou de kans op fouten verminderen.

De draft-specificatie van de W3C voor het toevoegen van variabelen aan css is nog niet goedgekeurd, waardoor WebKit genoodzaakt is zijn eigen prefix aan de nieuwe elementen toe te voegen, bijvoorbeeld @-webkit-variables. Desondanks kan er in de laatste nightly builds van de WebKit-engine geëxperimenteerd worden met het gebruik van variabelen in style sheets. Ook is een aantal testbestanden beschikbaar.

In de WebKit-implementatie kunnen variabelen in een css-bestand gedefinieerd worden. Via de functie var() kunnen de waardes uitgelezen worden, terwijl de css-variabelen ook via javascript zijn te benaderen door nieuwe functies.

Door de ondersteuning van variabelen in css kunnen waarden die vaak terugkeren, zoals font-instellingen of kleuren, aan een variabele gekoppeld worden, waarna deze waarden in declaraties gebruikt kunnen worden. Hierdoor moeten grote css-bestanden beter leesbaar worden, terwijl ook de kans op fouten wordt verkleind doordat de waarde van een variabele slechts eenmaal gewijzigd hoeft te worden.

Reacties (76)

[Peter]

CSS Variables zijn door de CSS werkgroep aangenomen, hier is dus weinig Google-specifiek aan, behalve dat het de eerste implementatie is. Andere browsers zullen vanzelf volgen.

Ik weet niet waar de tekst uit het nieuwsbericht zelf vandaan komt (waarschijnlijk van eerdere discussies), maar dit is niet wat er in WebKit geïmplementeerd is, noch wat er door de CSS werkgroep gestandardiseerd wordt. De syntax uit het huidige voorstel, waar verschillende browsers en groepen het redelijk over eens zijn, is namelijk als volgt:

:root {
var-text-color: red;
var-border-color: blue;
}
section {
color: $text-color;
border: 1px solid $border-color;
}

Hiernaast is ook de var() functie nog beschikbaar, maar deze heeft met name de mogelijkheid om standaardwaardes mee te geven indien de variable niet gevonden kan worden. WebKit wijkt hier op dit moment nog vanaf omdat de "$" prefix nog niet geimplementeerd is, en de var() functie daardoor verplicht gebruikt moet worden. De implementatie wordt echter via een iteratie-principe gedaan, wat inhoudt dat de functie nog volledig in ontwikkeling is.

Dit houdt tevens in dat de functie *uit* staat - het is voor Web ontwikkelaars nog niet mogelijk om ze te gebruiken. Totdat een andere browser vendors ook ondersteuning heeft toegevoegd zal dit zo blijven. Mensen die toch interesse hebben in het gebruik van CSS Variables, bijvoorbeeld om te kijken hoe toepasbaar het is voor eigen projecten, zitten nu nog vast aan een eigen WebKit build maken. Totdat er een run-time flag in Chrome beschikbaar wordt.

Verder is het ook noemswaardig dat de hoofdontwikkelaar van SASS actief heeft meegeholpen aan het ontwerp van de feature. Qua compatibility zal het nog een tijd duren voordat het algemeen ondersteund wordt, maar het moet natuurlijk ergens beginnen. Tevens wordt er nog nagedacht over mogelijkheden om variables aan de DOM beschikbaar te stellen, zodat je via JavaScript bijvoorbeeld waardes kunt opvragen of veranderen.

[Tielenaar]

Erg welkom dit. Het is ook gewoon nodig in het kader van zo weinig mogelijk dubbel werk doen. Hoe vaak ik wel niet op 20 plekken een color heb moeten aanpassen.. 't Is gewoon ouderwets.

Als je in een scripttaal een variabele ergens 2x hebt staan verlies je al efficientie en heb je meteen je medeontwikkelaars op je dak. Ik zou niet weten waarom dit bij CSS anders zou moeten zijn. PHP/HTML/CSS/Javascript, etc. horen als 1 grote groep bij elkaar en moeten in de hedendaagse wereld van complexe systemen gewoon zo efficient mogelijk zijn.
Als je naar extra tools moet grijpen zoals LESS of SASS om iets doodnormaals te creeren dan is het wat mij betreft toch duidelijk dat er iets ontbreekt.

[highmastdon]

Wat je zegt vind ik helemaal waar. Alleen vind ik niet dat PHP bij deze groep hoort.

PHP is een server-taal die juist die HTML CSS en (misschien niet of gedeeltelijk) Javascript produceert. De client-side languages zijn tot nu toe nog zo geweest dat het 'niet-compileerbaar' is. Interpreted dus.

[wjvds]

Mooi, dit zal CSS een stuk overzichtelijker maken.

[TvdW]

Niks moois aan, dit hoort niet thuis in CSS en het wordt niet ondersteund door andere browsers.

We gebruiken trouwens al langere tijd oplossingen als LESS.

Er is al jarenlang een discussie gaande over of variabelen wel in CSS horen. De algemene opinie is dat dat niet zo is, en het lijkt erop dat Google probeert dit toch te pushen door 't gewoon in de browser te zetten, om de standaard te forceren.

[beany]

Het hoort niet in CSS thuis, maar ondertussen wel oplossingen als LESS gebruiken wat eigenlijk op het zelfde neer komt

[Verwijderd]

Het hele idee van CSS was toch dat designers het gemakkelijk konden aanpassen? Als het nu een programmeertaal gaat worden, dan haken de designers af denk ik

Maar anyway, wat ik handig vind aan LESS is dat je een soort van classes kunt maken, waardoor je in 1 keer een hele set rules kan kopieren. Hopelijk komt zoiets ook in de standaard dan.

[harrald]

CSS is al veel langer te ingewikkeld voor iemand die slecht abstract kan denken. En het concept van een variabele is nou niet echt rocket science maar iets dat je met elke wiskunde/natuurkunde les krijgt.

Variabelen in css is een welkome toevoeging imo

[Verwijderd]

helaas lopen veel mensen te zwoegen met wiskunde/natuurkunde.

ik vind het zelf ook vreemd maar het is wel de realiteit.

en in het voorbeeld is de toepassing als variabele niet echt terecht. een constant zou beter zijn geweest.

[.oisyn]

Het is een programmeertaal omdat er variabel-substitutie inzit, waardoor het voor de designers makkelijker wordt om iets aan te passen omdat je nu nog maar op 1 plek de kleur hoeft aan te passen ipv op 300 verschillende plekken?

En als designers dan zo bang zijn voor variabelen, waarom maken er dan zoveel gebruik van LESS en SASS?

[Reactie gewijzigd door .oisyn op 31 juli 2024 19:48]

[Verwijderd]

omdat je nu nog maar op 1 plek de kleur hoeft aan te passen ipv op 300 verschillende plekken?

%s/fff/f4abc8/g ?

[BartOtten]

Voor de ontwerpers onder ons?

[Cartman!]

Ik weet niet hoe dat bij jou werkt maar hier zijn designers vooral aan het designen en zijn het frontenders die het bouwen. Bovendien ben je niet ineens verplicht om variabelen te gebruiken, het is optioneel.

[mokkol]

Ik vind het aardig krom. Dat die dingen niet in css hoort vind ik echt onzin. Standaarden moeten veranderen, dat je tools zoals SASS en LESS nodig hebt is naar mijn mening gewoon om de kromme dingen heen programmeren.

Ik gebruik zelf SASS met HAML en vind het echt geweldig, maar zoiets als variabelen moet echt wel native in CSS vind ik.

[watercoolertje]

Het hele idee van CSS was toch dat designers het gemakkelijk konden aanpassen? Als het nu een programmeertaal gaat worden, dan haken de designers af denk ik

Het gebruik van variablen is heus niet verplicht hoor, de oude code zoals we nu hebben werkt dus ook gewoon

[Reactie gewijzigd door watercoolertje op 31 juli 2024 19:48]

[Bullit1991]

Met variabelen (constanten) wordt het nog niet gelijk een programmeertaal. Daarbij komt dat het een designer vrij staat om het niet te gebruiken, mocht hij/zij dat niet wilen.

[Bauknecht]

Het hele idee van CSS is op markup en layout te scheiden van elkaar, niet om een soort "domme-mensensysteem" te hebben dat zelfs leken kunnen gebruiken. Die groep is trouwens blijven hangen in tables, en hebben geen degelijke notie van CSS.

[kikker81]

Houdt je browser zich aan de standaard en houdt je website zich aan de standaard dan is er niets aan de hand.

[Verwijderd]

Ja maar de standaard is zo ingewikkeld dat er een grote kans is dat je programma/site niet in 1 keer werkt op die browser, laat staan op alle browsers die de standaard "ondersteunen".

Als ze het web wat slimmer in elkaar hadden gezet, hadden ze die kans veel kleiner kunnen maken.

Nu lijkt het wel alsof we wat betrouwbaarheid betreft terug zijn in de prehistorie.

[Neko Koneko]

De algemene opinie is dat dat niet zo is, en het lijkt erop dat Google probeert dit toch te pushen door 't gewoon in de browser te zetten, om de standaard te forceren.

Webkit is niet van Google, maar ooit door Apple geforked van KHTML.

[BartOtten]

En het wordt nu ontwikkeld door onder andere (uit mijn hoofd):

- Apple
- Nokia
- Google
- KDE

Blijkbaar is mijn geheugen goed:
http://trac.webkit.org/wi...contributed%20to%20WebKit

[avdg-BE]

Binnen 10 jaar zijn we vergeten dat css geen variabelen had. En nu browsers iets regelmatiger geupdate worden, vind ik het wel kunnen dat er variabelen in css komen.
Al is dit idd niet zo vanzelfsprekend voor mensen die css al onder de knie hebben om nu te zeggen dat css weeral aan het veranderen is.

[TvdW]

Het probleem zit niet zo zeer in de variabelen maar in de vervolgstappen. Variabelen zijn ongetwijfeld heel erg handig, maar je kan er zo weinig mee - nu kan je bijv. alleen maar een kleurtje makkelijk eventjes als variabele zetten. Om er ook echt veel mee te kunnen heb je dingen als + en - nodig. Stapje verder en je krijgt methoden om kleuren te bewerken. Dan komen er later ook nog eens functies bij. Al deze veranderingen zijn niet backwards compatible (normale CSS-wijzigingen wel), en op een bepaald moment krijg je gewoon een complete programmeertaal in CSS.

En dàt is waarom LESS zo goed is: het kan gewoon geprocessed worden op de server, waardoor het altijd gewoon weer CSS wordt. Het klopt dat het een programmeertaal is, maar het hoeft niet backwards compatible te zijn omdat het op de server zelf draait.

Een ander argument is trouwens dat variabelen helemaal niks toevoegen aan de clientside-kant en alleen maar handig zijn voor de developers. Waarom dan moeilijk doen en ze ook niet gewoon aan de kant van de developers interpreteren?

[Reactie gewijzigd door TvdW op 31 juli 2024 19:48]

[Verwijderd]

Maar waarom moet je daar dan weer een nieuw taaltje voor uitvinden? Je kunt toch ook gewoon php of van mijn part javascript code schrijven die css uitpoept? Dan kun je het zo geavanceerd maken als je zelf wil.

[Verwijderd]

Idd, doen wij ook. Kan je het ook meteen strippen van dubbele spaties en enters. Ik heb echt helemaal niks met dat Less.
En deze support is leuk, maar ik denk dat iedereen zijn eigen workaround al heeft gevonden ervoor.

[Rutix]

behalve dan dat die php code of js code die CSS uit poept hoogst waarschijnlijk kut is om te onderhouden. LESS werkt gewoon goed, is schoner, makkelijker te debuggen ect. En het word onderhouden door een 3rd party die er langer aan kan werken dan jij aan je eigen css generator zou kunnen werken.

[avdg-BE]

Natuurlijk blijven tools zoals LESS nuttig zelfs wanneer css variabelen ondersteund. Zulke tools kunnen namelijk heel wat optimalisaties doen zodat browsers het niet moeten doen.

Ik zou zelfs zeggen dat deze tools even nuttig zouden zijn moest css ongeveer hetzelfde kunnen aanbieden. Er zullen dan wel minder mensen naar deze tool grijpen, omdat je dan enkel de css moet wijzigen zonder dat je aan de tools hoeft te prutsen.

[Reactie gewijzigd door avdg-BE op 31 juli 2024 19:48]

[robvanwijk]

Variabelen zijn ongetwijfeld heel erg handig, maar je kan er zo weinig mee - nu kan je bijv. alleen maar een kleurtje makkelijk eventjes als variabele zetten. Om er ook echt veel mee te kunnen heb je dingen als + en - nodig.

Niet alleen plus en min, ook een assignment; op dit moment doet het me veel meer denken aan "constanten" dan aan "variabelen".

[Durandal]

Inderdaad, Constanten was ook mijn gedachte.

Constanten ben ik voor, variabelen tegen; CSS is een opmaakbeschrijving en het argument om dit te gebruiken is altijd het scheiden van code en opmaak geweest. Moet je niet ineens CSS gaan codificeren.

[watercoolertje]

Jij denkt zeker ook dat iemand die wiet rookt binnen no time aan de harddrugs zit oid, want dat is de logische vervolgstap toch?

Beetje raar om te denken dat het meteen verder en verder moet gaan...

BTW wat is er zo speciaal een LESS, bovenstaande code (uit het artikel) is binnen 10 regels PHP om te vormen naar valide CSS, wat doet LESS voor speciaals dan allemaal...

[Reactie gewijzigd door watercoolertje op 31 juli 2024 19:48]

[Ramon]

LESS is nog veel meer dan dit voorbeeld, zie: http://lesscss.org/

[Verwijderd]

Mmm, als ik LESS bekijk is het eerste wat me opvalt, dat alles langer is wat code betreft en ik kan me voorstellen als je veel code hebt staan dat je de draad kwijtraakt wat variabelen betreft bij het ontwerpen van een site.

Bij alleen css komt duidelijk naar voren in de voorbeelden, dat je elke keer duidelijk kunt zien wat de instellingen zijn.
LESS is dus duidelijk voor een programmeur bedacht en niet voor een ontwerper, of het zo zinvol is dan vraag ik mij af.

[Leejjon]

Als ik PHP/JSP code tussen mijn css code zet om bijvoorbeeld kleuren uit een database te halen flipt de CSS validatie van mijn IDE. En die validatie vind ik fijn omdat ik niet vaak CSS edit. Maar je kan ook gewoon met JavaScript dynamische CSS rules toevoegen nadat de pagina is geladen.

[spellcoder]

Als je CSS genereerd verlies je:
- de mogelijkheid om direct vanuit de ontwikkel/debug-tools zoals Firebug te zien op precies welke regel iets foet is of aangepast moet worden
- de mogelijkheid om live CSS properties (zoals de variable) te veranderen om te zien wat het effect op de pagina is

Mij lijkt het handig om CSS variabelen te hebben, helemaal in het geval van sites die per sectie themakleuren willen hebben. In plaats van hele lappen CSS te kopieren en aanpassen per thema of gegenereerde CSS te gebruiken kan je dan op basis van een class op de body of door een thema-specifieke CSS file in te laden kleurenthema's implementeren. De normale CSS file kan dan specificeren of je b.v. een donkere, lichte, border, tekst of header kleur nodig hebt en de daarnaast ingeladen kleurthema CSS specificeerd de benodigde kleuren hiervoor.

CSS calculaties zitten overigens al in Firefox vanaf versie 4 met prefix:
https://developer.mozilla.org/en/CSS/-moz-calc
http://hacks.mozilla.org/2010/06/css3-calc/

Ik zie zie zelfs niet direct veel toegevoegde waarde in LESS, alhoewel het zo te zien leuke speeltjes heeft. Ik vermoed wel dat mijn baas gek ervan zou worden omdat hij met alle variabelen, kleurberekeninging, when's er niet meer uit zou komen waar nou welke instelling vandaan komt Dan moet er een 'echte' programmeur aan te pas komen om een stylesheet aan te passen.

[.oisyn]

Niks moois aan, dit hoort niet thuis in CSS en het wordt niet ondersteund door andere browsers.

Je bedoelt dat er niets mooi is aan de huidige CSS spec, waardoor je je moet vergrijpen aan dit soort extensies of opties zoals LESS om dingen mooi, duidelijk en maintainable op te zetten?

De algemene opinie is dat dat niet zo is

Sorry maar ik hecht niet zoveel waarde aan of iets algemene opinie is. Ik hoor liever argumenten. Het feit dat er vraag is naar iets zoals LESS spreekt daarentegen boekdelen.

[Reactie gewijzigd door .oisyn op 31 juli 2024 19:48]

[mokkol]

+1 voor deze reactie. Opties zoals LESS of SASS zouden niet zo heel erg nodig moeten zijn. CSS mag best wel iets meer van deze tijd worden.

[kamerplant]

Met dat argument kun je eigenlijk iedere ontwikkeling stop zetten. Het is er niet, dus het hoort niet.

[simplicidad]

Niks moois aan, dit hoort niet thuis in CSS... . De algemene opinie is

Heb je daar een bron van wat de "algemene opinie" is ? Aan de de populariteit te zien van LESS/SASS zou ik veel eerder het omgekeerde denken. En lapmiddelen - wat LESS is - zijn in wezen nooit echt goed.

Mijn opinie is dat ik al jaren met het idee loop dat variabelen een groot gemis is in CSS, zeker als ik - voor less - voor de tiende keer bepaalde zaken op x aantal plaatsen moest gaan aanpassen.

en het wordt niet ondersteund door andere browsers.

Ik verwacht dat de niet IE browsers dit snel zullen implementeren hoor. Maakt zaken zoals LESS/SASS overbodig. En m.b.t. IE zal er wel weer een polyfill oplossing bestaan of kun je een faillback implementeren tot zolang MS het in de volgende iteratie zal ondersteunen.

[Reactie gewijzigd door simplicidad op 31 juli 2024 19:48]

[NicoJuicy]

Ik snap niet wat het probleem is om dit te pushen, variabelen zijn al lang een gemiste functionaliteit in css... Een kleur op 200 verschillende plaatsen aanpassen is volgens mij minder gebruiksvriendelijk.

En LESS is gewoon een mogelijkheid om variabelen te implementeren, maar het er wel beter gewoon vanaf de eerste x inzitten (toch volgens mij)

[GamingZeUs]

CSS is een opmaak taal. Nu wordt het een completere taal. Ik zie geen probleem. Overigens zouden ook complexe dingen zoals die ook in LESS zitten van mij best mogen.

[Noctonix]

Less is idd zeer handig!

Maar sass Werkt naar mijn inzicht toch iets overzichtelijker!

[actionInvoke]

Ben ik het totaal niet mee eens. Variabelen zijn een groot gebrek in CSS. Met variabelen kun je immers nu makkelijk op 1 plek je kleuren instellen die in de classes gebruikt worden. Nu staat dat hardcoded in de classes wat gewoon slordig is.

[Marlinc]

Off-topic: Zover ik weet is WebKit niet van Google maar van Apple.

On-topic: Ik zie zelf de meerwaarde niet echt van variables in CSS aangezien je niet echt vaak (altans ik) de zelfde waardes gebruikt. Ik probeer vaak te zorgen dat een inherit goed genoeg is.

[mg794613]

Hehe ik wilde al bijna schuimbekkend reageren hierop.
Snapte wel WAAROM je vind dat variabellen niet in css thuishoren, maar niet dat het je het vervolgens met clientside javascript (nog meer?) oplost.

Na iets verder te lezen op LESS pagina dan mijn neus lang is, kom ik tot de ontdekking dat er een toolset bij hoort waarmee je LESS om kan zetten naar CSS.

In die vorm is dit best een elegante oplossingen; Geen variabellen in je compiled CSS, wel de voordelen van variabellen in LESS.

[Dreamvoid]

Ach ja, en zo wordt CSS vanzelf een scripting taal op zichzelf.

[RM-rf]

in 1996, nog voor de publicatie van de CSS-1 recommendation heeft netscape ook 'Javascript Stylesheets' ontwikkeld en W3C voorgesteld: JSSS..
effectief was het zelfs zo dat de visuele weergave van CSS in Netscape Navigator 4 gebaseerd was op JSSS, CSS-declaraties werden intern omgevormd tot JSSS (helaas ook de oorzaak van behoorlijke vee bugs én problemen metd e dynamische weergave van CSS-Styles binnen DHTML-toepassingen, dus HTML-layers welke dynamisch veranderden)...

Hét probleem is natuurlijk dat zoiets een extra belasting kan leggen op een visuele engine, er veel meer states én mogelijk inline berekeningen bijgehouden moeten worden voor, tijdens en na het renderen van een pagina.

[Reactie gewijzigd door RM-rf op 31 juli 2024 19:48]

[.oisyn]

Als je het concept van variabelen niet snapt (blijkbaar), heb je ook niet het recht om iets af te doen als scripttaal want dan heb je het dus gewoon niet begrepen. Iets declareren is iets anders dan iets uitvoeren. Laat dat laatste nou vooral het idee achter een programma (en dus script) zijn.

[Dreamvoid]

Dat weet ik ook wel, maar het is de eerste stap op weg naar het vervullen van Zawinski's Law. Let maar op, over 20 jaar kunnen we een emailclient in CSS schrijven.

[Reactie gewijzigd door Dreamvoid op 29 juli 2024 17:29]

[jurp5]

Aah, met de volgende iTunes kunnen we waarschijnlijk mailen, ideaal!

Maar inderdaad, het moet niet te bloated worden. Voor workarounds waren CSS behaviours handig in IE. Maar ergens moet natuurlijk wel een duidelijke scheiding tussen functionaliteit en opmaak blijven IMHO.

[Gomez12]

Iets declareren is dan weer niet perse een variabele voor nodig. Een constante voldoet daartoe ook.

En constantes hebben (imho) minder risico om uit te groeien tot scripting engines als variabelen.

Een variabele is namelijk over het algemeen variabel. Wat moet een browser doen als ik halverwege een css een variabele herdefinieer?

[.oisyn]

Iets declareren is dan weer niet perse een variabele voor nodig. Een constante voldoet daartoe ook.

Dat is ook precies waar het hier over gaat, alleen noemt iedereen het variabelen

[Reactie gewijzigd door .oisyn op 31 juli 2024 19:48]

[RM-rf]

Voorlopig is het hier voor slimmer een CSS-preprocessor te gebruiken;
SASS, LESS of Stylus... voordeel daarvan is toch ook dat het backwards compatible blijft werken.

[Eguna]

Je hebt gelijk wat backwards compatibility betreft, maar wat zou het toch ontzettend fijn zijn als we hier mee gewoon direct vooruit konden... Vrij logische stap dit voor CSS zou ik zeggen, meer dan welkom.

[mtlife]

Totdat dit een standaard is blijf ik gebruikmaken van LESS (naar mijn mening makkelijker dan SASS), wel een goede ontwikkeling dat ze dit al pushen in de browsers. Hopelijk komt het hierdoor in een stroomversnelling.

[Verwijderd]

Je bent mij net voor.LESS Blijft inderdaad een geweldig hulpmiddel!

[Rob Coops]

Eindelijk het zou eens tijd worden zeg, de W3C zou wat mij betreft wel iets sneller mogen werken aan het verbeteren van CSS aan de andere kant de meeste browser bouwer (en zeker Microsoft) kunnen ze nu al amper bijhouden. Maar dit is wel een goede ontwikkeling want het is af en toe zeker bij grotere pagina's nauwelijks te volgen welke kleuren waar en waarom gezet worden en zo...

[Verwijderd]

Het W3C kan helaas niet sneller omdat dit door diezelfde browserbouwers ontwikkeld/onderhandeld wordt.
Wat mij betreft hadden we in 10 jaar al op een veel hoger niveau kunnen staan, ik bedoel: Waarom moet ik een datepicker met Javascript maken? Waarom ondersteund een browser niet out-of-the-box een multi-upload feature (ipv met een swf op de achtergrond te werken)?
Al die zaken zitten standaard al ingebakken in de SDK's van notabene complete besturingssystemen (Android, iOS) die slechts enkele jaartjes bestaan.

Dus ja, ze zijn traag maar kunnen er eigenlijk niks aan doen omdat iedere partij haar eigen belangen heeft. Andere kant van het verhaal is dan Flash, dat is wel geavanceerd maar je bent wel afhankelijk van Adobe voor de performance ervan. Overigens heb ik wel een lichte voorkeur voor Actionscript: één taal voor alles en vector-based.

[Reactie gewijzigd door Verwijderd op 31 juli 2024 19:48]

[Defspace]

Css variabelen zijn gewoon erg overbodig. Als je 20x dezelfde kleur moet vervangen weet je zelf niet hoe je CSS moet gebruiken.
Kan namelijk op verschillende eenvoudige manieren

<sub>h2, .mijnclass, .andereclass, .nogeenclass
{
color: #fff;
}

/* of anders */
.huisstijlkleur
{
color: #fff;
}</sub>

en in je html: class="modulebox huisstijlkleur";

[Gomez12]

Veel plezier met het schrijven van een grotere css.

Wat jij noemt is een begin, css-constantes / LESS is simpelweg het vervolg daarop.

Op jouw manier maak je bij veel gebruik je css onoverzichtelijk en je html enkel maar groter.

Wat nu als ik de kleur van de modulebox wil wijzigen maar niet de huisstijlkleur, moet ik dan in de css (en waar) duiken of in de html.

Helemaal leuk wordt het als ik de modulebox net een tintje donkerder dan de huisstijl wil hebben.

Op deze manier wordt je eindresultaat niet meer bepaalt door het css, maar ook mede door de html (en dat ga je merken in het onderhoud)

[ultimasnake]

Dit zou veel 'engines' als SASS overbodig kunnen maken, natuurlijk zorgen deze vaak ook voor een snellere manier van css'en maar voor mij was de voornaamste reden (in dit geval in Ruby On Rails) toch wel het gebruik van variabelen zodat ik makkelijker thema's kon aanpassen @textcolor, @backgroundcolor etc etc kwam toch rete handig uit

[Cergorach]

Ik zie de voordelen wel van het gebruik van variabelen in CSS, maar maakt dit het niet onnodig complex en gezien de lengte van een hoop CSS bestanden, onleesbaar? Ook weer het probleem van dat sommige browsers het wel en andere weer niet (dan wel anders) ondersteunen, moet je de boel weer redundant maken waardoor de plus punten niet naar voren komen en je het dus beter niet kan gebruiken...