Olyan megoldásokra vannak példák IE alatt, hogy CSSben javascript számolásokat végzünk, de ezek természetesen nem szabványos megoldások, s mint ilyenek, nem feltétlenül működnek a többi böngészőben. Mások szerveroldali megoldásokkal definiálnak változókat a css-ben, pl ruby segítségével, de ez meg véleményem szerint sérti a rétegszemléletet, stíluslapokhoz ne nyúljunk szerveroldalon.

Nem, itt másról van szó, egy eszközről, amivel áttekinthetőbbé és kezelhetőbbé tudjuk tenni a stíluslapjainkat.

Pár css okítás megemlíti, hogy könnyebbé tehetjük életünk, ha bizonyos szövegformázásokat vagy oldal elemeket vázlatszerűen dokumentálunk a stíluslapokban, pl:

/**
 *	szöveg színek
 *
 *	link kék		:  #0099ff;
 *	cím piros		:  #cf1855;
 *	idézet szürke	:  #dedede;
 */
 
h1 {
	color: #cf1855;
}
p a {
	color: #0099ff;
}
blockquote {
	color: #dedede;
}

Ezt a logikát követi a most beemelt megoldás, csak igazi funkcionalitást ad az egésznek, az előző példa így nézhet ki:

/**
 *	szöveg színek
 */
@variables {
	link_kek:		#0099ff;
	cim_piros: 		#cf1855;
	idezet_szurke:	#dedede;
}
 
h1 {
	color: var(cim_piros);
}
p a {
	color: var(link_kek);
}
blockquote {
	color: var(idezet_szurke);
}

Látható, hogy segítségével apróbb, de következetes módosításokat végezhetünk a stíluslapjainkon, csak jól kell használni. A használata kiterjed az @import által beemelt stíluslapokra is, tehát nem szükséges fileonként beállítani. A @variables defíníciónál lehetőség van média típust is megadni, tehát nem szükséges komplikálni a nyomtatási stílusokat.

A WebKit nem egy elterjedt böngésző, viszont példaértékűen elöljár a szabványok beemelésében, és sok más böngészőnek a motorja. Innen már csak az a kérdés a többi böngészőfejlesztő mikor csatlakozik, illetve – érdekességképpen -  melyik Adobe AIR verzióban használhatjuk majd.

Aki kedvet kap hozzá, szerezzen be egy friss webkitet, és lesse meg a tesztoldalakat.

Az előbbi mód mellett érdekes módon a kód átláthaóságát hozzák fel fő érvként, hisz egymás alatt látjak a selectorokat, könnyű keresni.

Engem anno hagyományos módon tanitottak programozni, a logikai blokkok szépen elkülönítve, kódsorok egymás alatt. Hamar megtanultuk, hogy kódban – aminek makacs tulajdonsága, hogy egy idő után lefelé nyúlik a szerkesztőfelületen – vízszintesen scrollozni néha maga a pokol. Ugyanez vonatkozik a css kódokra is.

Az első érv pedig – a selectorok átláthatósága – nem sokat ér, ha egy rendes szerkesztőben egy outliner-el nézzük a kódot, ahol – legyenek a valóságban bármilyen sorrendben a selectoraink – általában abc sorrendben is megnézhetjük a kódunk szerkezetét.

Persze lehet, hogy nem a fejlesztő, hanem az általa megszokott eszköz a hibás, de vélemenyem szerint valahol jellemzi a fejlesztőt és munkamenetét az eszköz amit használ. Munkacsoportokban, ahol mindenki a saját megszokott eszközével dolgozik, a következő ember aki a kódhoz nyúl, lehet, hogy sorokra tördeli a kódot, ekkor – az eszköz hibájából – az előző fejlesztő már lehet, hogy hátrányban lesz.

Másik gyenge érv amit hallani lehet, a kód “tömörsége”, de ez rendes CDN-ekkel, szerveroldali cachelessel elegánsan megoldható, ettől a fejlesztőknek nem kéne a tömör kódot “visszafejteni”.