Stíluslap darabolása több CSS fájlra
Másik témához írt felvetés folytatódik itt, hogy ott ne térjünk el a tárgytól.
Függetlenül attól, hogy jó ötlet-e darabolni a CSS-eket vagy sem, a szóban forgó cikk noha javasolja azt, de igazán egyetlen előnyét sem említeni. (A "rendezettség" igen vézna kis lábakon álló érv.) Ha ezzel szembeállítod az egy CSS fájl egyszeri lekéréssel kiszolgálhatóságát, akkor nincs miről beszélni – gex hozzászólásában szerintem erre utalt.
■ Függetlenül attól, hogy jó ötlet-e darabolni a CSS-eket vagy sem, a szóban forgó cikk noha javasolja azt, de igazán egyetlen előnyét sem említeni. (A "rendezettség" igen vézna kis lábakon álló érv.) Ha ezzel szembeállítod az egy CSS fájl egyszeri lekéréssel kiszolgálhatóságát, akkor nincs miről beszélni – gex hozzászólásában szerintem erre utalt.
látogatottság
Ezzel együtt a probléma teljesen különválasztható: egy dolog, hogy hogyan érdemes a munka szempontjából tárolni a fájlokat, és másik dolog, hogy milyen formában történik a deploy. Egy pár soros scripttel élesítéskor egybe másolhatjuk az összetartozó CSS fájlokat, még tömöríthetjük is őket, és mindenki örül.
Üdv,
Felhő
kis látogatottság
Faster Page Loads - Bundle Your CSS and Javascript
Gábor, nem értek egyet azzal, hogy a rendezettség annyira gyenge lábakon állna az egyszeri lekéréssel szemben. Szvsz van, hogy fontosabb az első. Csak 1 szitu ami most hirtelenjében eszembe jutott:
honlapokat készít valaki, sok ügyfele van, de egyik munkája sem az a nagyobb honlap (akár terjedelemben, akár forgalomra stb.).. van, hogy vissza-vissza kell nyúlni későbbi fejlesztések miatt a saját kódjában. Abban gondolom egyetértünk, hogy felettébb hasznos, ha valami következetes a fejlesztés során és minden lapja esetében hasonló módon rendszerezi a kódokat.
Itt jön képbe a több css. Nem mondom hogy ez a legjobb megoldás, de egy lehetséges út a kódok rendbetartásához. Biztos vagyok benne hogy van olyan fejlesztő, aki így sokkal könnyebben vagy gyorsabban tudja végezni a munkáját.
Jómagam az 1 css híve vagyok és a kódot inkább kommentekkel tagolom kisebb/nagyobb egységekre, de nem merném azt mondani hogy a másik módszer rossz (te sem mondtad).
Most a fenti példára visszatérve: ennek a fejlesztőnek szerintem tökmindegy, hogy kispista bt bemutatkozó lapján ahol van napi 50 látogató, 1 vagy 5 css-t ránt be a lap letöltésekor. Sőt meg merem kockáztatni, hogy még a szerver rendszergazdájának is mindegy (azért ne kövezzenek meg a rendszergazdák, ha mégsem :D).
Neki sokkal fontosabb lesz, hogy a munkáihoz később visszatérve azonnal tudja hova kell nyúlni, mit hol talál. Ebben segíthet neki az, hogy pl. egy table.css-ben tartja az összes olyan formázást, ami a táblázatokra vonatkozik.
Felhő:
"szerintem pont ebben a kérdésben nincs jelentősége a látogatottságnak,"
én a látogattság - több css - szerver terhelés vonalat azért mondtam, mert remélem még emlékszel hogy az előző munkahelyünkön pont együtt ötleteltünk azon, hogy lehetne optimalizálni a lapot/csökkenteni a szerver terhelését/gyorsítani a megjelenést. Ott a lap(ok) napi több milliós egyedi látogatót generáltak. Én ekkor találkoztam ezzel a több css "problémával" először, erre utaltam az előző hozzászólásomban (hogy ezek összefüggnek).
más: Gábor a címhez kapcsolódóan ajánlott egy linket a lapról, de ez talán még inkább illik a témához:
CSS fájlok és tartalmak rendszerezése, avagy hogyan írjunk szép kódot
Lehet vele vitatkozni természetesen, örülök minden építő jellegű beszélgetésnek és szívesen tanulok másoktól.
nem a szerver terhelése a fontos
Üdv,
Felhő
példák
a weblabor.hu-n a firebug szerint beránt a böngészőm 7db css-t, 375ms alatt (52kb)
az index.hu-n 2db css-t húz be, 203ms alatt (69kb)
origo.hu-n 2db css, 422ms alatt (61kb)
firefox.hu-n 4db css, 797ms (26kb)
említett lapon 4db css, 937ms (92kb)
egy pici honlapot megnézve ahol alig van látogatottság, 1db css-t 62ms alatt (2kb)
Kövezz meg de szerintem ezek a ms-beli eltérés még a 2 véglet között sem óriásiak, látogatói szemmel nézve. Ha a lapokat meg kb nagyságrendileg teszem egymás mellé, akkor a különbség még inkább eltörpül, ms-okról beszélgetünk.
Ezek a letöltési különbségek elvesznek az átlag látogató számára, aki a lap letöltése közben nézi ahogy megjelennek a képek és egyéb tartalmak.
Nagyon fontos dolognak tartom én is, hogy egy lap jól optimalizált legyen, jelenjen meg minél gyorsabban, de abban a lépéssorozatban amely során az "optimalizáltságot" eléred, ezt az 1 vs több css kérdést huszadrangú dolognak tartom a többi teendővel szemben (gondolok itt akár a szerverre, sávszélességre, képek számára és méretére stb..).
Plusz erre te még el is oszlattad azt a tévhitemet, miszerint ez fontos a szerverek terhelését tekintve.
Épp ezért nem tudok neki akkora jelentőséget tulajdonítani, mint amit kihallani véltem a "(A "rendezettség" igen vézna kis lábakon álló érv.) Ha ezzel szembeállítod az egy CSS fájl egyszeri lekéréssel kiszolgálhatóságát, akkor nincs miről beszélni")" felvezetőből és továbbra is tartom, hogy a rendezettség lehet érv a darabolás mellett.
Gondolom csak nekem fontos a rendezettség, az átláthatóság egy fejlesztés során, hisz 1 vagy több ember munkáját nagyban befolyásolja.
Kérdés: a fentebb említett cikkben vázolt megoldást jónak tartod?
rossz példa
Rendezettség: CSS nagyon nem az én asztalom, ezért nem tudom eldönteni mi a jobb, de mint írtam szerintem a két dolog független egymástól, lehet deploy folyamat része a CSS-es és JS-ek összepakolása.
Bár pl. facebooknál is valami ilyesmi megoldás van, meg én is hasonló fele kacsintgatok. Amivel én megspékelném, hogy hozza be egy random paraméterként a fájlok közül annak a revízió számát, amelyik legutoljára volt commitolva, így tuti nem lehet gond a cachelésből.
Üdv,
Felhő
Az egy CSS előnye, hogy nincs hátránya
Továbbá még akkor is igazat tudnék adni a cikkírónak, ha ezt a CSS szervezési megoldást egyfajta újrafelhasználhatóság szellemében tálalja; például az általad felhozott példánál maradva kigyűjti a sok kis megrendelései során alapként használt stílusdefiniciókat, és elkülöníti a cégspecifikusakat (képbe jöhet a jobb verziókövetés). Azzal, hogy a táblázatok vagy fejléc stílusának leírását külön tárolod, ugyanazt éred el, mint ha ezeket egy fájlban tárolnád, csak meghagyod annak a veszélyét, hogy esetleg rossz gyakorlatok rögzülnek benned. (Igazából nem hiszem, hogy meggyőzhető vagyok atekintetben, mennyivel könnyebb, gyorsabb megnyitni a
table.css-t, mint rákeresni pl. a/* table.css */kommentre.)érvek/ellenérvek
Egyszerűen arról van szó, hogy a darabolás ellen/mellett szóló érvek esetében kicsit máshova helyeztük a hangsúlyt.
Ha egy picit én is...
dolgon változtatni új oldalak kreálásakor. Charles Wyke Smith által fémjelzett stylelib könyvtár is ezt hívatott követni, akit érdekel a téma (és nem zavarja az angol) szerintem érdemes belekukkantani.
Stylin'withcss
ezzel én is egyetértek
Deployment
output buffer filter trükk
Üdv,
Felhő
Fejlesztés vs alkalmazás
Ahhoz hasonlítható ez, mint amikor egy forráskódból futtatható állományt készítesz.
Nem volt kerek egész a cikk
templatek
default.css, news.css stb
sőt, tovább mentem:
default.js, news.js
Igy az egyes template-k funkcionalitását tudom szabályozni egyszerűen, átláthatóan. Nem igazán hiszem, hogy 2 új kérés olyan sokat számítana, hiszem egy átlagos oldalon úgyis van mondjuk 50.