Változók CSS fájlokban
Kicsit sántít a cím, ugyanis CSS-ben még nem lehet változókat használni, annak ellenére, hogy létezik ilyen irányú törekvés: http://disruptive-innovations.com/zoo/cssvariables/. Azonban létezik egy nagyon egyszerű módszer, hogyan tudunk mégis kényelmesen változókat használni, kis PHP segítséggel…
Miért érdemes változókat használni? Képzeljük el, hogy egy minális design-al rendelkező oldalon is, amely mondjuk csak 2-3 különböző színt használ. Egy biztos, ezek nem 2-3-szor fognakszerepelni a CSS fájlba, hanem sokkal többször. Tegyük fel, hogy meg szeretnénk változtatni ezeket a színeket. Tapasztaltak mondják: search&replace :). Na de ha mondjuk csak néhány dobozon belül szeretnénk ezt megtenni? Na ez már érdekesebb. Ha változókat használnák, és okosan csoportosítottuk és használtuk őket, a dolgunk nem lehet bonyolult. Nézzük miként tudjuk egyszerűen megoldani!
Első körben azt kellene elérnünk, hogy ha a szerver css állományt szolgál ki, lefuttassa rajta a PHP értelmezőt. Legegyszerűbb, ha .htaccess állományban megadjuk a következőt:
AddType application/x-httpd-php .css
Ez a sor mondja meg az Apache-nak, hogy a css fájlok típusa application/x-httpd-php, emiatt le fogja futtatni a PHP értelmezőt. Ezután szerkesszük a kedvenc CSS állományunkat, mintha egy PHP állományt szerkesztenénk. Példa kedvéért:
<?php /* A content-type headert beállítjuk. */ header("Content-type: text/css"); $hatterszin = '#e0e0e0'; $szovegszin = '#333333'; $fejlecmeret = '18px'; ?> body { background-color: <?=$szovegszin?>; color: <?=$szovegszin?>; } h1 { font-size: <?=$fejlecmeret?>; }
Az elején beállítjuk a tartalom típusát text/css-re, inicializálunk néhány változót. Ezeket a későbbiekben a PHP nyelv által biztosított módon bármikor felhasználhatjuk. Érdekességképpen megemlítem hogy teljes körűen használhatjuk a PHP nyelv előnyeit, tehát bármit, amit egyébként fel szoktunk használni (ciklusok, include-ok, stb.). Tehát nagyon könnyen tudunk, akár adminisztrációs felületről is skinnelhető weboldalt készíteni. Nagy forgalomnál azonban érdemes a kimenetet gyorsítótárazni.
RSS
19 hozzászólás, szólj hozzá Te is!
NeverGone
A dolog szépsége ott jön elő, hogy a CSS-t a böngészők előszeretettel gyorstárazzák - jogosan.
2009. 04. 29.
madbence
Nem az a lényeg, hogy dinamikus legyen a CSS, hanem hogy lehessen benne változókat használni :).
Meg amúgy sem nehéz kiüríttetni a júzer gyorsítótárát - amit max akkor kell megtenni, ha _változik_ valami.
2009. 04. 29.
Keygen
Élesben, főleg nagy forgalmú oldalaknál nem alkalmaznám. Sokkal tanácsosabb szerintem a design-készítés során ilyen php-változókat tartalmazó css fájlokat készíteni, amiket még a design végső testreszabása során áteresztenék a parancssori php-értelmezőn, és az így kapott végeredményt tárolnám konstans css fájlként.
Így nem vész el a változtathatóság, de nem terhelődik a szerver sem azzal, hogy az összes css lekérést is áteressze a php értelmezőn.
2009. 04. 30.
fabrik
KEYGEN-nel értek egyet, nem gondolom, hogy ez a megoldás (pláne ilyen formában) jól osztaná be az erőforrásokat.
Ilyesmit sokkal inkább a jQuery-re bíznék.
2009. 04. 30.
Polonkai Gábor
Nagy forgalomnál, ha a http-ben alkalmazható gyorsítótárazással kapcsolatos fejléceket (Expires, Last modified, stb.) helyesen alkalmazzuk, még arra sincs szükség, hogy a php kimenetét statikus állományokban tároljuk. Persze a legjobb megoldás az, ha parancssori értelmezőn átküldjük, a kimenetet statikus állományban tároljuk és lighttpd-vel szolgáljuk ki, de van itt olyan, aki azért használ ilyet, mert (havi jópár millió oldalletöltésig) EZ okozta a szerver terhelésének jelentős részét? Szerintem mindig ott kell tuningolni, ahol adott erőforrás befektetésével a legtöbb nyereséget kapjuk. Ez általában nem az a szkript amiben van pár darab változó :), hanem az adatbázis struktúra, a lekérdezések és a jóval bonyolultabb php kódok.
2009. 04. 30.
Brunner Ádám
@Polonkai Gábor: nálunk eléggé fontos volt az, hogy a statikus állományokat statikus file-okból szolgáljuk ki. A napi 10-15 millió oldalletöltés az, ami ezt indokolttá teszi. Jelenleg a statikus tartalmat 8 szerver szolgálja ki, ami csak az oldal design – tehát nem tartalmi – elemeit szolgálja ki. Ha ezeket az elemeket script-en keresztül szolgálnánk ki, indokolatlanul nagy erőforrás pazarlás lenne.
Igen, legtöbbször nem a script a “ludas”, hanem a mögöttes adatbázis tervezés, illetve cache-elés hiánya, viszont képes maga a script is – ha nem figyel oda az ember és nem profile-olja néha a futását az oldalnak – igazán szűk keresztmetszet lenni, még ha nem is használ semmi adatbázist az adott oldal. Én azt mondom, hogy ha valami statikus, akkor az legyen is statikus.
Ahhoz, hogy a CSS file-okban “változót” használjunk, fejlesztés alatt valóban megoldás lehet a PHP-n való átküldés, viszont publikáláskor az előgenerálás feltételnek kellene lennie!
2009. 05. 02.
Brunner Ádám
@MadBence: NeverGone helyesen említette meg, hogy egy jól beállított statikus file kiszolgáló szerveren szokás beállítani Expires header-t. Nálunk ez például ha jól emlékszem 2014 körülre van beállítva. Bár az is tény, hogy egy egyszerű query stringben elhelyezett verziószámmal ki lehet kényszeríteni, hogy a böngészők frissítsék a CSSt. Például a CSS verziókezelő-beli revíziójának a CSS-re hivatkozásnál utánaírásával.
2009. 05. 02.
Crystal
két dolog:
* ez elég triviális dolog, józan parasztésszel is ki lehet találni, ergo nem biztos hogy ennek van helye egy haladó webfejlesztői blogban…
* nem hiszem, hogy szerencsés lenne a webszervert úgy beállítani, hogy minden css fájlon fusson le a php interpreter, hiszen lehet, hogy csak néhány css fájlnál van szükség php változókra, a többi esetében meg csak fölöslegesen lassítjuk a kimenet generálását. Én inkább .css.php kiterjesztést adok a css fájloknak.
2009. 05. 02.
Brunner Ádám
@Crystal: és megszületett a .dcss kiterjesztés
Azt hiszem megyek és le is védetem…most!
2009. 05. 03.
Crystal
akkor már inkább pcss (a zend phtml mintájára :))
2009. 05. 04.
Polonkai Gábor
@Brunner Ádám: valóban igazad van, ezért említettem a hozzászólásomban a havi pár millió oldalletöltést. A napi 10-15 millió nagyságrendekkel nagyobb terhelés.
2009. 05. 04.
szabi
Egyrészt nem jó dolog minden css-t php-ba áttolni (Crystal), másrészt minden preprocesszoros megoldásnak megvan az ára. Ide kellene proper cache-elés + akkor figyelni, h. mi változott (rekurzívan ám, hékás, @import ugye) - máris elveszik a dolog szépsége/egyszerűsége.
Amúgy ezt gyakorlatból mondom, nálunk elég erős preprocesszor van (bár jávás környezetben) és észnél kell lenni, mi mit csinál.
2009. 05. 07.
yanchi
Persze, van az a terhelés, ami mellett OO-t is azért csak csínján használ az ember, mert gyorsnak kell lenni. Aki már dolgozott ilyen környezetben, az hajlamos máshogy nézni a világot, pedig a hazai weboldalak 99.5%-a nem ilyen. Azt a pár tízezer napi oldalletöltést meg kényelmesen kiszolgálja még egy virtuális gép is, 256MB RAM-mal, a sebességre optimalizálás meg nincs az első öt szempont között.
2009. 06. 06.
drbit
Nem kell, hogy minden CSS fájlon lefusson a PHP-értelmező. Ha .htaccess-ben az Addtype helyett a Files-t alkalmazzuk,
<Files “valami.css”>
ForceType application/x-httpd-php
</Files>
csak a valami.css-en fut a PHP-értelmerző, a többin nem.
2009. 06. 28.
Balázs
Van valamilyen hátránya, ha egyszerűen php kiterjesztésű a fájl? Én néhány oldalnál használom, működik.
2009. 08. 13.
Geri
@Balázs: Van. A cascading stylesheet szabványos kiterjesztése a w3c-ben css.
2009. 10. 05.
gH0StArthour
Minek a css-t babrálni, hogyha használhatunk több css-t is?
Az már php dolga legyen, hogy melyik css fájl-t hívjuk be.
Erre találták ki a “template” kezelést, ugye aminek az egyik fele a css behívása, a másik az oldal felépítés.
2009. 11. 21.
steel pipe
Van valamilyen hátránya, ha egyszerűen php kiterjesztésű a fájl? Én néhány oldalnál használom, működik.
2010. 01. 11.
tildy
Az en megoldasom, foleg nagyforgalmu oldalaknal a tobbfele stiluslap hasznalata, a valtast kezelem phpval.
Ahogy gH0StArthour is leirta jol.
steel pipe : elvileg nincs.
2010. 02. 24.
Hozzászólás írása: “Változók CSS fájlokban”