ugrás a tartalomhoz

Szerver oldali CSS változók

Hojtsy Gábor · 2005. Aug. 6. (Szo), 17.17
Sokan javasolták már a CSS fájlok szerver oldali feldolgozókon történő átvezetését annak érdekében, hogy különböző megnevezett változó értékeket használhassunk a stíluslapokban. Korábban is voltak már PHP-t használó megoldások erre, Shaun Inman azonban egy kicsit tovább viszi ezeket, bemutatva a CSS-SSV-t, azaz CSS Server Side Variables megoldást. Bár, mint a hozzászólásokból kiderül, szerencsésebb lenne konstansoknak nevezni a helyettesített értékeket, ráadásul ezesetben CSS-SSC lenne a módszer neve.

Erről szóló blogbejegyzésében Shaun ismerteti a legfontosabb alapelvet, azaz hogy kódszínezésben jártas programokban is jól működő megoldást szeretett volna készíteni, és ez késztette arra, hogy a CSS meglévő szerkezetét használja újra a cél érdekében, mégpedig a következőképpen:

@server variables {
    primaryLinkColor: #AB6666;
}

a {
    color: primaryLinkColor;
}
Ebből természetesen a böngésző csak a megfelelően feldolgozott, a @server nélkül előálló kész CSS kódot kapja meg, köszönhetően annak a feldolgozó szkriptnek, amit Shaun mellékelt. Érdemes a hozzászólásokat is elolvasni, melyekben rámutatnak, hogy nem minden esetben célszerű változókat használni, ám lehetnek olyan helyzetek, ahol ezek előnyösek. Ráadásul megfelelő gyorsítótár fejléc kiadásával a fájl tárolási idejét, azaz végső soron a szerver terhelését javíthatjuk.
 
1

RoR

Bártházi András · 2005. Aug. 6. (Szo), 21.51
Talán ennek hatására(?), a Ruby on Rails levlistán is volt egy hasonló hozzászólás ma: http://article.gmane.org/gmane.comp.lang.ruby.rails/17425

-boogie-
2

innováció

Hojtsy Gábor · 2005. Aug. 6. (Szo), 22.20
Na igen, csak a hírben említett megoldásnál az innováció abban van, hogy CSS szintaktikát használsz, változó helyettesítést sok nyelven könnyen be lehet ágyazni, mint ahogy már tették is korábban...
3

előrelépés

Bártházi András · 2005. Aug. 7. (V), 10.16
(Igen, a korábbi próbálkozásokról tudok, s ez tényleg innovatívabb.)

A kérdés, hogy ez gyakorlatilag előrelépés-e? Az előnye, hogy nyelvfüggetlen, illeszkedik a CSS formátumhoz, a hátránya, hogy többet kell gépelni, s annyira nem átláthatóbb. Ciklusokat, függvényeket és hasonló megoldásokat pedig nem is lehet vele kivitelezni, a CSS szintatktikája nem nagyon van erre felkészítve, ellentétben egy szerver oldali programozási nyelvvel.

Akkor lenne ez jó, ha valakinek eszébe jutna a W3C-nél, hogy a CSS-t egy kicsit fel kellene turbózni. Tudtommal tudatosan nincsen szándékukban.

-boogie-
4

minek is?

Hojtsy Gábor · 2005. Aug. 7. (V), 12.35
Miért is kellene elbonyolítani egy ilyen egyszerű leíró nyelvet? Az a cél, hogy minél több eszközben implementálva legyen, jól terjedjen, stb. Ezzel sokkal többet érünk, mint több szolgáltatással, amit nem implementálnak. Már így is sokminden van benne, amibe beletörik a megvalósítók bicskája, hátmég a CSS 3!

Nyugodtan meg lehet oldani szerver oldalon a dinamikus előállítást, és még kesselés is segít, hogy optimális legyen.
5

Összetett

Bártházi András · 2005. Aug. 7. (V), 12.44
Azért lenne jó, mert az összetettebb szerkezeteket (css sprites, stb.) könnyebben és hiba nélkül le lehetne írni. Nyilván ez már nem az a CSS lenne, ami most van.

Ha lenne egy egységes megoldás (bárkitől, bármilyen formában), az az innovációt, megoldások megosztását segítené elő, szemben a mostani mindenki kitalál magának egy formátumot vagy generátort 3-4 különböző szerver oldali nyelven.

-boogie-
6

<Nincs cím>

Anonymous · 2005. Aug. 8. (H), 10.10
Magamból kiindulva nem látom sok értelmét ennek az újításnak. Esetleg nekem szükségem lenne hasonlóra, akkor megoldanám magam:

<?php
$primaryLinkColor = "#AB6666";
?>

a {
color: <?php print $primaryLinkColor;?>;
}
7

egyszerűbb

kisstoth · 2005. Aug. 8. (H), 10.28
Nem kötekedni akarok, de így egyszerűbb behelyettesíteni:

a {
color: <?= $primaryLinkColor ?>;
}

Üdvözlettel,
Kiss-Tóth Marcell
9

Több helyen

Jano · 2005. Aug. 8. (H), 11.28
Nem feltétlenül jobb megoldás amennyiben egy értéket több helyen is fel akarsz használni! Pl egy oszlop szélességehez és a hozzá kihagyandó margóhoz.
10

Igen, több helyen

kgyt · 2005. Aug. 8. (H), 12.21
A fenti több helyen is alkalmazható... ;-)

--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
12

nem biztos :)

connor · 2005. Aug. 8. (H), 13.07
Abban az esetben jó ha a saját szervereden a saját beállításokkal megy a php.
Amint mozgatod a kódot és egy olyan helyre kerül ahol nincs a engedélyezve a <? máris hibát ad a kód.
Így érdemes minden környezetben működő kódot írni, az meg a <?php echo ... ?>

--
connor
8

érdemes lenne elolvasni a hírt

Hojtsy Gábor · 2005. Aug. 8. (H), 10.44
Érdemes lenne talán elolvasni a hírt, mert ott bizony le van írva, hogy a fenti miért nem megfelelő megoldás: nem CSS szintakszist használ, ami kizárja egy csomó szerkesztőprogram alkalmazását.
11

CSS szintaxis

kgyt · 2005. Aug. 8. (H), 12.33
A php fájlhoz egy kis CSS megjegyzést fűzünk és CSS-nek színeztetjük az editorban:

/* CSS stíluslap a bugybure.hu-hoz<?php
  $primaryLinkColor = "#ab6666";
?> */
a {
  color: <?=$primaryLinkColor?>;
}
ha PHP-ként színezem, akkor elkülönülnek a PHP részek, és jól áttekinthetőek:

/* CSS stíluslap a bugybure.hu-hoz<?php
  $primaryLinkColor = "#ab6666";
?> */
a {
  color: <?=$primaryLinkColor?>;
}
Változók definiálhatók a fenti fájlban is, de akár külön is

/* CSS stíluslap a bugybure.hu-hoz<?php
  include( variables.php );
?> */
a {
  color: <?=$primaryLinkColor?>;
}
<?PHP
  $primaryLinkColor = "#ab6666";
?>
Ez a kimeneten így fest:

/* CSS stíluslap a bugybure.hu-hoz */
a {
  color: #ab6666;
}
--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
13

nem rossz

Hojtsy Gábor · 2005. Aug. 8. (H), 13.10
Az ötlet jó! Mindenesetre nem csak kódszínezésre gondoltam, hanem vizuális szerkesztőkre is, bár igaz, hogy azokban a helyettesítendő értékek miatt amúgysem lesz élvezhető ez a fajta CSS. Úgyhogy nálad a pont.
14

Vizuális szerkesztők...

kgyt · 2005. Aug. 8. (H), 14.06
Szerintem a legjobb vizuális szerkesztő az, ha a helyi gépen fut az éles szerver ((majdnem) hű) mása, és egy böngészőben megnézed az eredményt...
:-)

--
Szeretettel: Károly György Tamás
kgyt(a)kgyt.hu - http://kgyt.hu
15

Részemről...

saxus · 2005. Aug. 8. (H), 19.30
Ennek az egésznek így nem látom értelmét. Ha a szerver dolgozza fel, akkor egyrészt a szerver kihasználtságát növelljük, másrészt a letöltendő adatmennyiséget is. Részemről a szerver oldali változók helyett jobban örülnék kliens oldali konstansoknak, amelyet hasonló szintaxissal tudnék elképzelni:

@const {
  név: érték;
}

...


Sokszor találkozok azzal, hogy egy-egy színt, szélességet több helyen is fel kell használni. Nagyon idegesítő tud lenni, ha nem jut eszembe egy érték, hogy meg kell nézni, hogy mi is volt az adott tulajdonságnak az értéke, és ha meg kell változtatni, akkor lehet átírni egy csomó helyen, és néha a csere nem jó megoldás, mert esetleg véletlenül egyezik egy másik értékkel.

És helyspórolás sem lenne utolsó szempont, mert pl a "1px dashed #121212;" helyett elég lenne csak pár karaktert beírni.

Esetlegesen lehetne ezeket a konstansokat globálissá tenni. Így meg lehetne oldani azt, hogy van egy fix, előre elkészített CSS fájlunk, és egy másik CSS fájlba (vagy az (X)HTML kód <style>...<style> részébe) elhelyezni a konstansokat. A konstansok feldolgozása (behelyettesítése) akkor történne meg, amikor az oldal renderelése történne.

Így nem szükséges külön CSS értelmezőt futtatni a szerveren, mindössze csak a PHP vagy ASP szkript-tel kell legeneráltatni a változó értéket.

Maximum annyival lehetne bővíteni, hogy ténylegesen változókként kezelődjenek, és például javascriptben lehetne velük operálni. Így ha egy változót módosítunk, akkor egyből módosulna az érintett érték. Például:

<script type="text/javascript">
  var alaplinksz = document.css.getCSSVar('alaplinkszin');
  document.css.setCSSVar('kiemeltlinksz') = alaplinksz;
</script>


Ha viszont ténylegesen "futtatható" kódot akarunk készíteni a CSS-ből, akkor be kell vezetni egy új nyelvi elemet a CSS-be. Például:

@code {
  /* CSSKód itt */
  if ($GET['szin'] == 'kek') {
    $szoveg = blue;
  } else {
    $szoveg = red;
  }

  $uline = 1px dashed $szoveg;
}

a {
  color: $szoveg;
  border-bottom: $uline;
  text-decoration: none;
}

a:hover {
  border-bottom-style: solid;
}


Ez csak egy példa volt PHP-s nyelvtannal. Persze ilyenkor lehet külön értelmezőt írni CSS fájlokhoz. Egyszerűbb és több értelme van ilyenkor már a PHP-t használni, ugyanis az már kész, régóta használják, és bevált.

Ha már a változóknál tartunk. Érdemes lenne még több érték egy blokkba való csoportosítását lehetővé tenni. Például így:

@block valami {
  tulajdonság1: érték1;
  tulajdonság2: érték2;
    ...
  tulajdonságN: értékN;
}

a {
  $valami;
}


Ilyenkor a CSS fájl értelmezésekor az értelmező úgy venné, mintha a $valami; helyén a valami blokk-ban szereplő tulajdonságok szerepelnének.

Természetesen ezek a saját ötleteim, nem kötelező velük egyet érteni. :)
16

<Nincs cím>

attlad · 2005. Aug. 8. (H), 20.36
Szerintem jó ötlet ha pl. egy szkript állítja elő a CSS-t több előnye is van, bár a szervert egy kicsit jobban terhelheti ahogy írtad, de ez vsz elenyésző az egész oldalhoz képest megfelelő gyorsítótárazás esetén. Az, hogy növelné a letöltendő adatmennyiséget nem gondolom, hogy igaz, mivel ha pl. egy PHP szkripten keresztül küldöm ki, akkor lehetőség van a CSS optimalizálására is.

Szerintem én fogom is használni a blogban írt ötletet, variables helyett constants-ot használva. Emellett a kimenet optimalizált CSS lesz, tehát space-ek, tabok és egyéb felesleges karakterektől mentes lesz. Így még csökken is a CSS mérete.

Mellesleg a változók használatára a Explorer jelenleg is lehetőséget biztosít, szóval ha esetleg bekerülhetne valami a CSS-be akkor az az Exploreres expression lehetne szerintem.

A ciklusok, feltételek, egyéb elemek CSS-be kerülése nem hinném, hogy szerencsés megoldás lenne, erre ott a most is használható JavaScript (JavaScriptből úgy állítod át a CSS-t ahogy akarod), feleseges lenne újra összekeverni a kettőt, ha eddig a szétválasztás volt a cél.

A @block-os megoldásod, meg a konstansok helyett, lehet használni legtöbbször az egyszerű szelektor felsorolást meg az érték felüldefiniálását:

#content a, #navigation a, li {
    tulajdonság1: érték1;
    tulajdonság2: érték2;
    tulajdonságN: értékN;
}

#navigation a {
    tulajdonság1: érték2;
}
Attila
17

egyszerű szelektor felsorolást

saxus · 2005. Aug. 8. (H), 21.07
Igen, én is ezt használom. De most akár vissza is léphetünk a legelejére. Ha egyszer mindenre van alternatív lehetőség, akkor miért kell továbbfejleszteni a CSS-t?

Mert eddig úgy láttam mindenre van valami módszer.

Azt, hogy a CSS-be rendessen beleépítsenek ugyanolyan nyelvi elemeket, mint pl a php-be, azt ellenenzem. Nincs értelme.
18

Nem kell

attlad · 2005. Aug. 8. (H), 21.42
Szvsz a CSS-t nem kell továbbfejleszteni, legalábbis ilyen szempontból. De az expression belekerülhetne, néha hasznos lehet, pl. egyenlő hosszú oszlopok létrehozása. Ez olyan, hogy HTML-be is használhatom a style paramétert, ez kötné össze a JavaScriptet a CSS-sel, ha valakinek éppen arra van szüksége.

Mondjuk már van egy ilyen is: http://www.w3.org/TR/becss

Attila
19

Egyszerü müveletek

Anonymous · 2005. Aug. 9. (K), 12.14
Én például nagyon örülnék, ha lehetne ilyeneket csinálni:

width:100%-25px;


Üdv

ProClub
proclub##kukac##karinthy.hu
20

Margin

Jano · 2005. Aug. 9. (K), 12.34
Erre például ennyi a megoldás:

#fooszlop {
 margin-right:25px;
}
Ugyanis minden blokk típusú elem 100% széles alapból!
21

<Nincs cím>

saxus · 2005. Aug. 9. (K), 14.27
Szerintem arra gondolt, hogy megad egy x %-kot méretnek, azután kivon belőle 25 pixelt. Nem feltétlen 100%-ból.
22

kifejezéskiértékelés

Balogh Tibor · 2005. Aug. 12. (P), 12.13
Ezt direkt nem tették bele, hogy könnyebben legyen implementálható a leírás. Ha lenne kivonás, akkor már összeadás, szorzás és osztás, zárójelezés, stb.
A te általad írt kifejezés sem olyan egyszerű, többféle mértékegységet tartalmaz.
De egy egyszerű konstans behelyettesítést valóban meghatározhattak volna.
23

Miért a szerveren?

Balogh Tibor · 2005. Aug. 12. (P), 12.35
Az ötlet nem rossz, de miért a szerveren kellene ezt alkalmazni miért nem a stíluslap szerkesztéskor, a szerkesztés végén a már behelyettesített fájlt elmenteni.

A cikk alapján írt php script:

<?php
class css_ssc {
var $file_name			= '';
var $content				= '';

var $constans_blocks	= array();
var $constans			= array();

function css_ssc($file_name){
	//Fájl megnyitása
	if (is_readable($file_name)){
		$this->file_name = $file_name;
		$this->content = file_get_contents($file_name);
		//A TexrPad vagy a Windows parancssor miatt konvertálni kellett.
		//Ha nem kell, akkor ez a sor kihagyható
		$this->content = mb_convert_encoding($this->content, 'ISO-8859-2', mb_detect_encoding($this->content));
		//@constans blokkok kinyerése
		$this->_get_constans_blocks();
		//A konstansdeklarációk kinyerése
		$this->_get_constans();
	}else {
		echo "A(z) '$file_name' fajlt nem lehet megnyitni!\n";
	}
}
function convert($with_declarations = false){
	return $this->_convert($this->constans, $with_declarations);
}
function deconvert($with_declarations = false){
	if (!$this->constans) return '';
	//A konstans tömb (név => érték) megfordítása
	return $this->_convert(array_flip($this->constans), $with_declarations);
}
function _convert(& $constans, $with_declarations){
	$find	 = array();
	$replace = array();
	//A konstans tömb kulcsok és értékek egyesítése külön-külön tömbökbe
	//az str_replace függvény számára.
	foreach ($constans as $name => $value){
		//Azért így, hogy  a részben megegyező constansrészeket ne cserélje le.
		$find[] 	= ' '.$name;
		$find[]		= ':'.$name;
		$replace[]	= ' '.$value;
		$replace[]	= ':'.$value;
	}
	$this->content = & str_replace($find, $replace, $this->content);
	//A konstans deklarációk hozzáfűzése, a tartalom elejéhez.
	if ($with_declarations){
		return $this->_get_blocks().$this->content;
	}else {
		return $this->content;
	}
}
function _get_constans_blocks(){
	preg_match_all("!@constans\s*\{\s*([^\}]+)\s*\}\s*!i", $this->content, $this->constans_blocks);
	$this->_delete_constans_blocks();
	return count($this->constans_blocks);
}
function _get_constans(){
	foreach ($this->constans_blocks[1] as $constans){
		preg_match_all("!([^:\}\s]+)\s*:\s*([^;\}]+);!", $constans, $matches);
		foreach ($matches[1] as $name => $value){
			$this->constans[$value] = $matches[2][$name];
		}
	}
}
function _delete_constans_blocks(){
	//A konstans deklarációt alapból töröljük.
	//Bárhol előfordulhat és több is lehet belőle a fájlban.
	foreach ($this->constans_blocks[0] as $block){
		$this->content = & str_replace($block, '', $this->content);
	}
}
function & _get_blocks(){
	$blocks = '';
	foreach ($this->constans_blocks[0] as $block){
		$blocks .= $block;
	}
	return $blocks;
}
}

if (isset($argv[1])){
	$dec = $with_decl = false;
	//Argumentumok kinyerése
	if ($argc > 2){
		for ($i = 2; $i < $argc; ++$i){
			switch ($argv[$i]){
			case '-dec':
				$dec = true;
			break;
			case '-with_decl':
				$with_decl = true;
			break;
			}
		}
	}
	//Konvertálás
	$css_ssc = new css_ssc($argv[1]);
	echo $dec? $css_ssc->deconvert($with_decl):$css_ssc->convert($with_decl);
}
?>
Hívás módja a php\cli könyvtárban lévő php fájllal:

php "proba.css"
php "proba.css" -dec
php "proba.css" -with_decl
php "proba.css" -with_decl -dec
A -dec kapcsoló dekonvertál, a deklarált konstansok neveit helyettesíti be. A -with_decl a konstans deklarációkat is visszaadja a fájl elején. A parancssoros hívási mód pl. a TextPad-hoz vagy a Jedit-hez minden bizonnyal hozzáadható.

Példa css:

@constans {
	betűszín: #ababab;
	narancs: orange;
	keret: 2px dotted red;
}
@constans {
	betűtípus: bold 10px monospace;
}
body {
...
}
24

Miért ne?

gerzson · 2005. Aug. 24. (Sze), 00.55
Az ötlet nem rossz, de miért a szerveren kellene ezt alkalmazni miért nem a stíluslap szerkesztéskor, ...
- valószínűleg azért, mert az kb. tök mindegy. Ha megfelelően univerzális feldolgozót írsz, akkor azt parancssorból ugyanolyan könnyen lehet használni, mint a "gyorstárazott" szerver környezetben. Szerintem.

testing can reveal the presence of errors, but never their absence. - Edsger Dijkstra